ぶろゲ

現時点において、iOS系のブラウザSafariではFlashを再生することができない。そのため、Youtubeなどの動画を扱うサイトでは動画の再生においてHTML5を代替手段として用いている。このことをフォールバックと言うらしい。

それぞれのWebブラウザ上で動画コーデックに対応していかなければならないが、iOS側はH.264を推している。以前、ChromeがH.264への対応を打ち切りにする、と報道されていたが、ChromeはFlashを同梱している。FlashではH.264を再生することが出来るため、逆に、HTML5のフォールバックとしてFlashが利用されることになるのではないか、という憶測が存在していた。

以前、Webブラウザ上でリアルタイムなやりとりを実現するためにCometという手法が存在していた。この技術をより改善したものがWebSocketという技術であり、TCP上で動作する。昨今の最新ブラウザはほとんどが対応の兆しを見せている。旧来のIE8,9のようなブラウザでは対応をしていない。しかしTCPなのでJavaやFlash上ではSocketを用いて実装が可能であり、ネイティブに対応していないブラウザではFlashへのフォールバックが手段として用いられる。

ファイルアップロードにおいても似たような事例がある。HTML5ではDataTransferオブジェクトを用いることでドラッグ&ドロップにてファイルのアップロードを実現している。Flashではドラッグ&ドロップを行うことはできない。HTML5ではmultiple属性によって複数ファイルのアップロードに対応しているが、レガシーブラウザでは対応できないため、Flashにフォールバックして複数ファイル対応するようなライブラリが存在する。

最新の事例では、ニコニコ動画が動画再生とコメント表示部分のUIを残して、コメント一覧のUIをHTML+jsに分離した、という流れもあった。

動画再生においてiOSではFlashの代替にHTML5が用いられ、H.264ではHTML5の代替としてFlashが憶測され、WebSocketではHTMLの代替にFlashが用いられている。

Flashの代替がHTML5であったのに、最近はHTML5の代替がFlashであるような事例が増えているなあと思った。

他の人の感想を見る前にこれを書いておきたい。まぁ、きっと非難轟々だけれども。

第一印象

• 黒い
• でかい

でかい
大画面:908×486,中画面:672×486,小画面:908×150
大画面の場合、コメント欄が横幅1440～1600ないと欠けるようになった。マウスをコメント欄の上に載せれば動画の上にかぶさる形で出てくる。

あと再生ボタンもでかい。マイリストボタンが上部の大きいボタンになった。

このプレイヤーはとにかく、色々でかい。

情報整理
動画の概要（動画説明）が基本、収納されるようになった。再生数・コメント数が動画の下に落ちる。動画説明も下に存在している。動画説明を見ようと思えば、動画上部をクリックして展開するか、スクロールすれば良い。

ファーストビューで数字を見せないようにする工夫か。数字で動画を判断するまえに動画を見てもらいたい、という流れ？それとも動画を上部に持っていきたいから、か。

ソーシャル連携強化
動画レビューが出来るようになる。twitter・facebookと連携して紹介することもできる。目立つ。

twitterによる動画紹介と、その拡散を狙ったものか。今までの動画ページに比べて下方に伸びるようになる。紹介した文章がレビューとして載るので、それが投稿するインセンティブに。

Dock
「動画をもっと見る」あたりの動画がMacのDock風味で拡大されるようになる。html+js実装。

プレイヤー周り挙動
再生ボタンなど制御パネルが再生中は表示されなくなった。コメントも一度、クリックしなければ行えない。コメントしやすさ前提よりも動画閲覧しやすさ前提にシフトした。

再生終了後のおすすめがFlash上の実装ではなく、html側の実装でFlashにかぶせる形で実現されるようになった。というかFlash上の実装でおすすめ表示するのはFlash側の開発者のストレス半端無いので正解だと思う。

動画再生中は左右のコメント欄、ニコニコ市場が透明になる。透明になるのでグレーの背景に溶け込んで、目立たなくなる。

あと、「動画をもっと見る」にて動画を遷移すると、url移動したように見せて、実はjson読み込みによる遷移。つまり、戻るボタンを押した際にhtmlの再読み込みを行わずにFlashプレイヤー側で前回の動画を読み込む処理を行い、それに伴い、動画情報の切り替えも行う。

これの利点は、ページの再読み込みが必要ない、すなわち「jsとflashの再読み込みが必要ない」という利点があり、その中でも「flashの再読み込み」を回避したのは動画ページ遷移のスピードと快適性を高めている。

しかしながら、現時点ではプレイヤーが存在しないページに戻ろうとすると、Flashプレイヤーを放棄してしまうため、そのようなページをはさむ遷移では利点が得られない。「動画をもっと見る」場合にのみ利点が得られる。

将来的には、flashプレイヤーをロードしたまま、検索を含む全てのページをpjaxで遷移することで、動画ページの動画読み込みまでの待ち時間を格段に短時間にすることが出来ると期待できる。それを実現するとなると、動画ページのあり方、検索ページのあり方を含めてドラスティックな変化になる。やり方はあると思う。

flashプログラム側が複数の動画を遷移してもメモリーリークしないように色々と見張る必要があって大変だろうなぁという印象。今まではページ遷移すれば、ゼロからの読み込み、なので特にメモリーリーク周りについては考える必要はなかった。これからは同じFlashプログラムでいくつも動画＋コメントを読み込んで再生する形になるので、どこかで迷子になるObjectが出やすそう。

通常、

http://www.nicovideo.jp/watch/sm00000000

というURLだが、「動画をもっと見る」のサムネイルをクリックしたときに、json情報を読み込むために

http://www.nicovideo.jp/watch/sm0000000?mode=normal&playlist_token=0000000000000000000000000000000000000000000

という形にてjsonリクエストを行う。そのjsonを公開しようかと思ったら、userAge、userPrefecture、userSexなどの情報が入っていて、ビビる。何に使ってんだ、その情報。アカウント情報を見たところ前述の情報は非公開設定になっている。

プレイヤー設計方針
コメント周りのギミックもhtmlに逃がしている。ということで、Flashによるニコニコプレイヤー、nicoplayer.swfの機能を動画再生とコメント表示とコメント投稿に切り出して、それ以外のUI部分（コメント一覧[設定]、再生終了画面）をhtmlに逃がした。逃がした部分はhtmlなので設定画面やコメント一覧は気分で変えられる。externalなんたらでjsとflash部分が繋がれて反映される。

たぶん、ブラウザ側のjsがもたつくとかあると、影響は大きい。

この設計方針はむしろhtml5とflashの双方で利用できる画面構成を考慮した結果であり、PC向けにはflashの方が適しており、flashが使えない場合にはhtml5にフォールバックすることを目的としたものであると推測する。

flashを使った場合の利点は動画再生の際のバッファ管理と滑らかなコメント表示部分であり、それをflashに残したという印象。仮にhtml5にフォールバックしても不満足ながら再生できる状態に持っていった、と。んでコメント一覧などのUIはflashだろうとhtml5だろうと共通部分なので使いまわせる、と。将来的にhtml5がflashと同等の能力を持った時点でflash捨てるつもりだな、と。

そのような推測を仮定すると、ボタンが大きいのは、おそらくタッチ端末で利用することを想定してのもの。

今のところ分からないのは、コメント投稿部分をflash側に残している点。なぜ、そこは共通化しなかった。

総評

でかい
くろい

UIも変わったけれど、プレイヤーの中身がかなり変わった。flashでもhtml5でも再生できる形に持って行っている。その変更はよく思い切ったと思う。これに皆が慣れてくれれば、html5移行は楽。

html側にデザインがひっぱられているので、既存のflashに慣れたユーザーには違和感あると思う。

flash側とhtml側の担当者が別々だったら、色々と大変だろうなー。apiの策定とか。一人でやっていたら、それはそれで大変だけど。

このプレイヤー作った人は大変だったと思うのでお疲れ様です。

色々な声を無視してがんばって下さい。

周りほどプライバシーに詳しいわけでもない。ので、話半分に受け取って欲しい。

「Google Driveは規約が問題だからDropBoxを使い続ける」という意見が多い。その意見にどうかな、と思う所がある。そういった思考ルートについて最近考えている。

NAVERまとめの「Google Driveの利用規約がヤバ過ぎる」という記事などが例に挙げられる。「NAVERまとめ」のこのようなまとめにリンクを張って編集者に金が入り、そのような情報の拡散に寄与するのは悲しいので、リンクは張らない。

—-

規約がどうであれWebサービス・ストレージサービスに「平文のデータを渡す行為」は、「その平文のデータが漏れる危険性が著しく高くなる」ことであると考えている。一度相手に渡したデータは、利用しているサービスの社員に意図せずアクセスされる可能性がある。加えてサービスが瑕疵や不正アクセスによってお漏らししてしまう可能性もある。

だから機密のある文章、社内秘、秘密にしておきたいプライベートの情報などは、そういったストレージサービスに預けることは危険である。にもかかわらず、そのようなデータを預けている人が少なからず居るのだろうと予想する。

Google Apps for Businessというサービスが存在しているし、sales forceというサービスが存在している。正直なところ、このようなサービスが普及することが信じられない。社内機密を扱う便利サービスは、全て各々の社内で運用されるものなのだろう、と。

思えば、この概念は初めから成立していなかった。プロバイダメールがあったからだ。プロバイダのメールは、メールサーバをプロバイダが立ち上げており、（何が起こるのかを想像しなければ）見ようと思えばプロバイダは利用者のメールの内容を見る事ができる。にもかかわらず、その意識なしに私自身もメールが安全なものだと考えている。麻痺しているからだ。

Gmailなどのメール本文を参照して広告を出すサービスを利用することは、そうした麻痺が成せることでもある。Gmailは広告モデルで運営されているので、GmailはPGPなどの仕組みは導入できない。しかしメール上でPGPでやり取りをする、という選択肢は許されている。しかし、PGPを使ったメールが少ないからこそ、広告モデルで成り立つ。

過去に暗号化した添付ファイルを送付して後からパスワード送る行為について考えたときにも、その麻痺した感覚に疑問を持った。PGP上でやり取りをすればどのプロバイダのメールサーバを使おうとも、より安全な環境が手に入る。かなり前のメールソフトでもPGPは出来るが、広まっていない。

メールサーバと同じように、インターネットを走るデータ、IPパケットすらネットワーク管理者は取得可能である。その問題を解決し、終端でしかデータの中身が分からないように暗号化できるSSLは広く利用されている。SSLはSSLを利用者が使っていると（あまり）意識させていない（本当は意識させなければならない）。その成功要因からすれば、意識せずにセキュアなメールが行えるシステムを考える必要があるのだろう。

ストレージサービスに類するサービスにおいても既にそのような試みは生まれている。かつて2008年ごろにFirefox 3 Beta 4とWeaveの感想という記事においてMozillaのWeaveに触れた。このサービスは今はFirefox Syncと呼ばれている。この記事内では触れていないが、このサービスはローカルのマシンで鍵を生成し、その鍵で暗号化された内容をサーバに送信する。そのためサーバの管理者はデータを参照することができない。

詳しくはSync のデータを保護する方法に書いてある。

あなたの リカバリキー は、このデジタル金庫を開けることが可能な世界でただ 1 つの鍵であり、他にこの金庫をこじ開ける方法はありません。誰かが Sync サーバにあるあなたの Sync データにアクセスしたとしても、あなたのデジタル金庫自体を見られるだけでその中身が見られることはありません。リカバリキー は、同じキーを作成して金庫を開けるには数千台のコンピュータを同時に何年も動かさなければならないような方法で作成されます。

Mozillaは既にストレージサービスに関する不安を払拭している。素晴らしい取り組みだと思う。鍵を無くしたら永久にアクセスできなくなるデータであることが正しい。だからこそ、データはリモートとローカルで冗長化されなければならないし、鍵はバックアップしておかなければならない。

だが「鍵を無くしたら永久にアクセスできなくなる」サービスは昨今は相手にされない。そうなると利用の可否の判断はどうなるのか。相手の会社を信頼するか否かになる。その信頼のよりどころは規約が正しいか、今まではどうだったか、などの要素なのだと思う。
仮にインターネットからアクセスできるファイルサーバが欲しい場合、自分でファイルサーバやるのとGoogleのストレージサービスとどちらが安全だろうか、考えるのかもしれない。

DropBoxが切り開いたストレージサービスの道にGoogleという大企業が入り込んできたからオリジナルを守らなきゃいけないという意思なのかもしれない。

これが、
それ以前に「漏れて困る機密情報は暗号化もしないでオンラインストレージに入れるなよ」、と、思う訳である。

漏れて困るから別のストレージサービスを使うという話ではない。漏れて困るなら安全ではない方法で使うべきではない。コストが上がっても、OCRかからなくても、検索できなくても、良いというのであれば、Firefox Sync式のデータアップロード方法を取るようにGoogleに要望すべきである。（しかし、便利なサービスを実現するにはローカルに全ファイルを展開してインデックスする仕組みになるので、計算量が大きく、例えばGoogle Desktopのようなものになるだろう）

漏れて困る情報をスマートフォンアプリが勝手にアップロードする件とは違い、自分からデータをアップロードして、自分から危険に晒している。さらにはメールも同じ状況下にある。その点を考慮して、漏れて困る情報は日頃からPGPと暗号化を行うか・そのような技術を利用しないのであればアップロードしない。

機密情報をそのようなサービスに預けて、万が一、漏らしたサービスが存在したとして、社会的制裁と（微妙だろう）損害金で帳尻が合うのであれば、そのようなサービスを活用すべきである。その帳尻が合わないのであれば、やはり、機密情報はアップロードするな、と言わざる得ない。

「今までも漏らしていないし、これからも絶対に漏らさないだろう」、という考えは、ここでは引用したくないけれども原発神話であり、お漏らししたときの影響範囲と対処が分かった状態でなければならない。

Google Apps for Businessも同様で、そのような不安を抱えたものだと思っている。

これは自分でVPSや自宅サーバでファイルサーバを立てても同じ話で。ネットワークに常時接続されている限り、自分でお漏らしした場合も考えなければならない。となると、ネットワークから分離されたUSB-HDDが良いという話になるのだけれども。…紛失とか、盗難とか。その場合に備えて暗号化ドライブにしておくとか。

結論

お漏らしが怖いなら機密情報を置くな、あと社内秘置くな
機密情報置きたいなら暗号化しろ、どの暗号化すればいいのか分からない場合はやめておいた方がいい

金をタブレット上のアプリに費やした。電子書籍に対して、2,3万払った気がする。

その結果、分かったことがある。参考になるかどうか分からないが書く。

体験版商法は割と当たる

体験版商法は割と当たる。1巻は無料でその後の続巻は有料、などのサービスがあるが、そのようなケースでは、続きを今すぐ読みたいという欲望と戦うことになる。…これに勝てない。本屋なら立ち読みすれば買わずに済むのだが、電子書籍の場合、楽して家で読んでいるので、外に出るのがダルイ。本屋が営業していない時間でもある。

電子書籍の利点として24時間営業であることを忘れてはならない。実店舗の場合、買って積んで読みたいときに読む or 電車に乗っている間に時間があるからその前に買う というスタイルで本を読んでいた。それに加えて寝る前に本を読むか、となった場合に、タブレット端末で読んで気に入ったら買う、というスタイルが出来た。

ちなみに体験版の無い電子書籍は買ったことがない。Amazonで書籍をレビュー参考にして買うことはあるけれど。電子書籍についてはない。

買いにくい本が買える

携帯向けの電子書籍でよく売れているのが、実店舗で買いにくい本だ、という話は聞くが、確かにそのとおりだ。それが買える利点はある。

それは実店舗の人間に対して顔などの情報を閲覧されることが嫌だからだ。同じように電子書籍の場合、電子書籍やっている業者にクレジットや氏名などの情報を渡したくない、という個人的思想がある。いや、漏れたら嫌だし。電子情報は漏れるし。

その場合、iOS系の場合は、アプリやアドオンで処理される場合、Appleが決済を中継してくれる。Appleになら情報閲覧されてもいいけれど、得体の知れない電子書籍業者には情報渡したくない、という思想を満たしてくれる。

いや、一度、電子書籍のサイトに登録して買ってみようかな、と思ったのだが、個人情報とクレジット入力の時点で躊躇してしまう。いいのか、と。他の決済代行業者が仲介してくれるのであれば、例えリスクが同じであろうと、さらっとポチってしまうのだが。心理的な抑制だろうか。

捨てる手間がないのがいい

いや、捨てないけれど。例えば紙の書籍の場合、場所を取る。本を入れてそのままのダンボールが２，３積まれている。本棚に入りきらなくて。このまま本を買い続けると、読み終わった本が増えていくんだろうな、と思うと、対処しなければ、と思う。思うが、積極的に何かしようとは思わない。

電子書籍によって流通が最適化されてコストが安くなるので安い価格で売れよ、という気持ちになることはあるが、電子書籍だと場所とらないからそれはそれで新しい価値はあるよね、という気持ちにだんだんなっている。前述の買いにくい本を仮に買った場合、それが部屋にあるのは嫌だ。いや、別にあってもいいんだけどね。何か嫌だ。

んで、いつでも読めるといえば読めるので、それはそれで価値があるかな、と。

関係ないけれど

デジタルデータなので、本の権利者は電子書籍の販売業者に売り上げ誤魔化されることあるんじゃないの、という心配がある。電子本が売れたら売れたで、本の権利者に1度でもping（特典ダウンロードなどの形で）が飛ぶようにしないと、マズいんじゃない。

タブレット端末で外で電子書籍を読んだことはない

生活スタイル的に、外で読まないな、と。読もうと思うのは、ほぼ寝る前。メールチェックと共に。

IT連携型の体重測定。WBS01は除外。

BC-309
約10,000円
50g
SDカード記録
アプリケーションにて分析
自動認識機能
CSV出力（らしい）

HBF-208IT
約8,000円
100g
USB/FeliCa携帯連携
ウェルネスリンク（Webサイト）に情報送信
ユーザーごとに1から4のボタンを押す必要がある
説明書が読みやすい

両方
どちらも色々計れる。
一定の情報を溜められる。
繋げないとグラフ化できない。

検討
BC-309はFlucardと連携できる可能性がある。可能性があるだけで無理かもしれない。SDカードを差し替えて計るのは正直つらい。CSVなので加工が楽しそう。flucardとの連携が上手くいけば、データ送信部分をサーバで処理できるので可能性は広がる。

HBF-208ITはウェルネスリンクとの連携が前提で手元にデータが残ることがない。ウェルネスリンク自体は良くできている。AndroidとFeliCaを使った連携が特に良い。良いがAndroidを持っていない。ファイルが残らないかと思ったらCSVでダウンロードできるようだ（ファイル出力）。USBデバイスサーバーでLAN対応できる可能性がある。ウェルネスリンクを用いる場合は自立してデータ送信できない。その気になればUSBプロトコルの解析。ウェルネスリンクは手動によるデータ入力にも対応する。

その気になればBC-309+ウェルネスリンクも可能。

BC-309+flucardはギャンブル。HBF-208ITは安定。

ぐぬぬ。