CROSS 2013レポート(1)
1月18日に行われたCROSS 2013に行ってきました。
昨年、風のうわさには聞いていたものの参加できなかったので、今年はぜひと思っていました。
800人以上が集まったという会場はすごい熱気でした。プレモルも美味しかったし、すごく楽しかったです。来年もぜひ開催してほしいと思います。
さて、メモが長くなってしまったので、セッションごとに分割してみました。Ustreamから書き起こし、とかしていないので、間違いや「そんな意図で言ってない」などということがあると思います。ご指摘いただければ幸いです。
HTML5×セキュリティ(Shibuya.XSS)
- http://www.cross-party.com/programs/?p=143
- @takesako(以下T), @Hamachiya2(H), @bulkneets(M), @hasegawayousukeさん(欠席)
@takesako
- 「HTML5テクニカルレビュー」2012年3月、リックテレコム
- 15年前、1997年サイボウズ設立
- Webアプリ(インストール不要) → すごく流行った
- サポート対象のブラウザ → Firefox 1.0と
- Android端末: 機種数が多すぎて開発が難しい
- 画面の大きさ、プロポーションもマチマチ
- HTML5: 様々なAPI
- fullscreen APIのセキュリティー
- ブラウザを全画面表示できる
- 悪用するとフィッシングできる
- 全画面表示でブラウザの外観をまねる
- ブラウザを判別してそっくりに作る
- ブラウザの対策「全画面表示モードです。このサイトで許可しますか」と聞く
- デスクトップの色をピンクにすると、そこまでは真似られないw
@Hamachiya2
@bulkneets
- (先月報告したのにまだ直ってないXSSの紹介なので割愛)
サニタイズの話
アドレスバー偽装
イタズラ公開のタイミング
- T: はまちちゃん、最近イタズラ減ってきた?
- H: ノーガード戦法が広まってきている。一昔前のブログはみんな技術者ってカンジだった。いまはそんな流れではないからなー
- M: 自分も見つけたときによくガマンしてるなーと思う。投稿できるサイトにはあまりXSSない。大手のおカタいサイトでお問い合わせフォームからイタズラ送れても面白くない
- T: 「こんにちはこんにちは」はすごく気にいってて、昼の業務時間に出してくれる分には対応できるから助かる
- H: 実は対策まで時間がかかるように狙って金曜深夜とか、はてななら土曜出勤するはずだから日曜に出すとか、やってるんですよ
- M: 前にイベント中に直ったことありましたね
クロスドメイン
- T: robots.txt を見るとひみつのURL教えてもらえたりとかは今でもある
- H: その他には、.svn/entriesというのがたまに見えるよね
- M: cross_domain.xmlはドメイン単位なので、間違ってキャッシュすると取り消せないのが困る
- T: IE10はいいですよ。みなさんWindows8でIE10使いましょうみたいな
@takesako: IE10のJITセキュリティーについて
- Chrome以降、JITの高速化戦争勃発
- セキュリティー対策も進んでいる
- 脆弱性の例
- https://speakerdeck.com/takesako/javascripthaji-jie-yu-tonaru
- JSの整数論理演算 → 機械語に落として実行
- 問題点: 定数のたたみ込みが動かない
- ずれたアドレスに飛んでくるとNOP列になってしまう
- ASLR (Address Space Layout Randomization)
- Linux kernelなど
- JIT-Spray
- JIT結果を置く場所は実行許可されているので、そこにコードをしきつめると攻撃に有利
- 定数のたたみ込みをすればしきつめることはできない
- IE10のJITセキュリティー
- codebase alignment randomization → うめ草としてnopではなく割込命令を使う → バスエラー
- random nop insertion
- constant blinding (定数をmovするのでなく、xorも使ってわからないようにする)
- 結論: IE10/Windows8が世界最強のJITセキュリティ
Q&A
- スマートフォンのWebViewはこわくないのか?
- M: こわいですよ! iPhoneアプリで多い。アドレス帳のSQLファイルのpermissionがゆるゆる。WebView内のfile://スキームで動いていると読めた
- M: iOSはJSからできることが多すぎて困る。JSからOSの機能たたけるようにブリッジしてると、任意のJSが実行できるような穴があったときに被害が甚大になっちゃう
- T: 標準ブラウザの問題? アプリも?
- M: Androidだとアプリ一覧見れたりする。どこまで公知なのかもわからない
- M: 端末がいつまでもアップデートされないので困る
- M: PhoneGap使ったアプリもネイティブとブリッジできるので、JSに穴があるとマズイ
- M: 内部用のAPIは認証が甘かったり、みんなたたかれないと思ってるけど結構見えるもの
- H: CSRFもアブない
- T: ぼくはアプリごとに別々の端末持ってる。LINE専用端末とかw
- M: 携帯まるごとシークレットモード(友達に貸すモード)とかほしい
CROSS 2013レポート(2)
CROSS 2013レポートパート2です。次世代Webセッションのメモ。
間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。
次世代Webセッション前半〜プロトコル編
- http://www.cross-party.com/programs/?p=138
- http://www.ustream.tv/recorded/28598269
- 司会 Jackさん(@Jxck_) 以下J
- 大津さん(@jovi0608) SPDY関連 以下jovi
- 小松さん(@komasshu) Websockets 以下koma
- 清水さん(@kazubu) HTTP/2.0 以下kazubu
HTTP2
- 2012/11最初のドラフト。絶賛議論中
- どんなところが問題?
- kazubu: 前回のIETFの続きのトピック。crimeアタックに関して圧縮回り見直しとか
- jovi: SPDYはSSLの上でやってるから気にしてくていいという話だった。crimeの衝撃。chromeは3ではdisableにした(クライアント側からの圧縮率を下げる)
- kazubu: 対応: 圧縮のコンテキストを分ける。headerとbodyとか。最近は圧縮方式を変える。
- crimeはhuffman木の再構成によって発生する。huffman木を変える方法が考えられている
- googleは前回と同じ物が来たときにだけフラグをつける。クッキーだけわかればいいという発想
- kazubu: 対応: 圧縮のコンテキストを分ける。headerとbodyとか。最近は圧縮方式を変える。
- HTTP2が出てきたときにどうupgradeするか
SPDY
- jovi: LINEの特徴
- koma: スマートフォンにはプライベートアドレスが払い出されてる
- マルチプレクシング
- SPDYでできちゃうのでWebsocktsでやらなくてもいいんじゃね的な
- per frame compression
- レスポンスを上げる → テキスト→バイナリ → 圧縮 → などとなっている
- J: SPDY: bandwidthよりRTTが重要という流れだと思うんですけど
- J:デバッグ大変ですよね!? → jovi:大変です!!
- HTTPのときはheaderのparseができればという話だったけど、SPDYのparserは個人でできる範囲をこえてしまった
- J: prioritizationというのがある。HTMLの世界でやっていたドキュメント読み込み順をSPDYに持ってきたときにどうなるかを考える必要がある
- 「ハイパフォーマンスWebサイト」は書き直さなきゃね!
- SPDY4ってどんなカンジなの?
- koma: layer violationがはげしくなってきて、階層どおりになっていない
SPDYとHTTP2とTLS
Websockets
- J: WebsocketsはHTTP→HTTP2に横からささってきた感じですが、これからはどうですか?
- koma: IE10でもWebsocketsがサポートされて、非常にいい実装になっている
- WSがこのまま世の中に普及するかというのは難しい。明日世の中のIEが全部10になるとかであれば使われるんでしょうが。IE678がいつなくなるかという話で、じゃあやっぱりsocket.ioでHTTPポーリング、ってなるでしょ。ああ、socket.ioは使われますよきっと
- koma: IE10でもWebsocketsがサポートされて、非常にいい実装になっている
- J: ブラウザ以外のWSのカベは?
- J: WSが切られちゃう件ってどうなんでしょ
- まあ、わけわかんない接続が残ってるの切るのは正しい対応なんでしょうけども
- 2本つないでみて試し、wsが使えるならupgradeしようみたいなのが出ているんですが、そのへんが難しい
- kazubu: IETFでも話題になっている。LBが作りにくい。SPDYでもpriorityをさばくのはLBなのにコンテンツはWebサーバーにあるというギャップがある
- J: WSもSPDYも接続を保持しないといけないからバランスしにくいのでは?
- koma: いままででもクッキーでセッションを考える必要はあった。data by data, frame by frameでLBしようとするとキツイという面はある
- jovi: chromeのgoogle map見ると、ひとつのTCPセッションに複数のホストが入っている。ワイルドカード証明書使ってDNSが同じアドレスになっているから、同じTCPセッションに入る。これは外から見てたらぜったいにわからない
- koma: シングルTCPに入れるのがいいかっていうと、回線品質が悪いときに急に悪くなったりというのがある。パラレルも使っていく工夫が重要
- kazubu: TCPいっぱい使うと間のNATがきびしくなるんじゃない?
- koma: HTTP時代の発想で20本も30本も張ると大変。でも1本にする必要はないんじゃない
- jovi: SSLのslow startから最高速が出てきたところでなんで切らなきゃいけないのって話。googleはこのへんもすごくやってる。half-close使ったりwindowサイズを3→10にしたり、SSL false startしたり
- こういうのがlinuxにも入っていて、みんな知らずに使っている
- J: イニシャルを速くするのと、つないだ後を速くするって話があって、つながっちゃえばやりようはあるんだろうけど、initialはなかなか難しいということか。3-way handshakeはどうしても必要だし
v6
- J: v6はどうなの?
- kazubu: 流行るといいですねーwww
- FBもgoogleも対応しているけど、v6で生活するというのは難しいよね
- kazubu: 流行るといいですねーwww
Webのこれから、どこに向かっていくのか
- kazubu: 効率化が進むけど、問題も引き起こすのでバランスが重要
- komasshu: ホームネットワークのTV・家電とクラウドの関わりが気になる。クラウドはSPDY,WSなどが進んでいくと思うが、ホームネットはHTTP以外のプロトコルでもガンガン動いている。シームレスにdevice - browser - serviceというトータルで考えないといけないと思う
- jovi: 過去から来ていたのはリアルタイム性、RTT。マルチプレクスがもうできた。本当の本当のリアルタイムはこれから先は劇的に伸びるものはもうない。これから先、どんな新しいパラダイムが出てくるかを見ていかないといけない。光はまだまだ遅いw
- Jxck_: みんなこういう話をするとすぐHTTPをdisったりする。HTTPにdisを持っていれば、いままさしくそれを検討する段階なので、どんどん出していくべき。もっとIETFに持っていくなどしていく必要がある。日本人の貢献がもっとできるはず
次世代Webセッション後半〜アーキテクチャ編
- http://www.cross-party.com/programs/?p=138
- http://www.ustream.tv/recorded/28599028
- 司会 Jackさん(@Jxck_) 以下J
- 和田卓人さん(@t_wada) 以下wada
- 山本陽平(@yohei) 以下yohei
- 佐々木庸平(@yssk22) 以下yssk
- 江島健太郎(@kenn) 以下kenn
Websockets
- J: LingrはWSにはならないのか
- kenn: ぶっちゃけよくわからない。互換性が失われる分があるので、サービスとしては採用にふみ切れない。ancientなCOMETを使っている。メリットは永続的なconnection。チャットはアイドリングの時間が長くてTCP接続のコストは高くない。生きたconnectionを使いまくるようなアプリでWSが生きてくるのだろう
- J: 結局COMETでよかったんじゃね?という話
- yssk: メリットが見えない。インフラ屋としてはconnection使い回すというのと、違うアプリが同じLBに入っている場合にどうやってLBのキャパを確保するのかが難しい。アプリがセッションを持ったまま永続してしまうと、バックエンドでサーバー再起動できなくなって困る。バックエンドが同じサーバーで動いていることを前提とされるとつらい
- J: HTTPはステートレスであることが良さだが、それが失われるとどうなります?
- J: statelessだったHTTPの上で信じるに値するRESTだったと思うが、そうもいかなくなってきた今、何をよりどころにすればいいでしょう
- wada: これまでのWeb、実はこうなっていたという説明がようやくストンと落ちたところだと思う。Webがドキュメントをやり取りする世界から、ストックのwebとフローのwebに分断された。twitterは過去が見られなくなったとか
- J: 自由なwebが失われた、みたいなブログがあったけどどう思いました?
- yohei: そのとおりだと思った。テクノラティーあったねーどこ行ったとか。ストックとフローの問題だと、世の中はフローに行ってるから、ゆり戻しがそのうち来るんじゃないかと思っている。タイムラインで流れていく情報をストックで扱う技術とか出てくるんじゃないか
- J: 文書をどう取ってくるかという点をよりどころに技術が進んできたと思う。バイナリになったり、始まりはあるが終わりのないストリームになったりということじゃないかと思うのだが
- yohei: 「インターネットになったな」と思う。ちょっと前はwebをインターネットと呼ぶな、とえらい人が言ってたりしていた。いまやweb==インターネットで、いかにその上でインターネットやるかというのでストリームになっていったんだろう。TCPの上にHTTP乗せてその上でTCPやるのがWSだったりする
- yssk: ゲームのようなHTTPベースじゃなかったものがHTTPでできるんじゃね、というのが今の流れ。WSはTCPの再実装じゃね、とは思っていて、少し懐疑的に見ている
- J: TCPに回帰していくと?
- yssk: そうではない。プロキシないと仕事にならない。HTTPの上にSOAPって言ってたけど、あれ?ということがあったよね
- yohei: HTTPをtransfer protocolとして考えないでsemantics考えろってのがRESTだと思う。結局みんなRPCやりたいんですよね
- kenn: textかバイナリかというのがハテ、と思うところで、テキストの扱いやすさがいい。圧縮してバイナリというのはどうかあと思う
Realtime
- J: 人がボトルネックになるというとそんなにリアルタイム求められてるのかな、と思う
- J: おととしくらいにWSのはしりが話題になってきて、キラーアプリが出るかと思ったけど、結局出てきたのってゲームとチャットだけだった。メッセージングが必要なキラーアプリ感がない。アプリとなると必要とされてないのか
- kenn: いいカンジに次世代webをdisる回になってきましたねw。エンジニアはすぐに効果が得られないものは採用しないと思う。にわとりとたまごではぜったいにたまご(新技術)が先。そこは悲観的には考えていない。時間の問題で出てくると思う。
- J: WSという仕様自体が求められて実装が進んでいて、それを使って何をするかは置いてけぼりになっている
- kenn: low latencyでリアルタイムというのは長く言われている割にようやく今だ!となってきた。時間がかかりますね。
歴史はくり返す
- J: 長い間見ているとよせては返すみたいな話がよくあると思うけど、それをふまえて、今よせているものはどこへ返っていくのか興味がある
- yohei: 今まで死んだスペックってすごくたくさんある。xsltとかw。仕様作っている人達はスペック先行で行っちゃう、楽しいし。しかしそれでうまくいかない。HTTPとかHTML5はうまくいってる? バランス取りながら進められるのがいい。いまだとIETFに行って合議制になった瞬間に終わるんじゃないかみたいな。IETFで仕様が出るよりgoogleでSPDYが234といくようなのがいいんじゃないか
- wada: 技術の歴史が螺旋状になっているよって話をよくする。テキスト/バイナリとか。前の周期を見ると、シンプルなものが生き残ってるのがわかる。やんなきゃいけないルールが多いものが死ぬ。SOAPとか。大きなものは自重で死んでいく。分散・集中だけでなく、自分の言葉をしゃべれるものが使いたいのかどうか。RPCやりたいというのは自分の語彙で話したいということ。なんで動詞が4つしかないんですかってPATCHもあるけど。自分のサーバーなんだし。他人の語彙を話すとなると急にやりたくなくなる
- LISPはマクロで言語を作るための言語だった。その結果みんなオレオレLISPを作ってしまってLISPの人同士で話ができなくなった。
- J: SOAPからRESTに行ったのもできることも少なかったが、覚えるルールが少ない分、よかったってこと?
- wada: ルールが少なければ納得できる。リンクを張ると使えるというおそるべきシンプルさ
TLSは前提?
- J: webはTLSを前提にしていいのかという話がある。プロトコル視点からは都合がいいのだが、web的視点からはどう考えたらいい?
- yohei: ビジネスではTLS前提が大歓迎でそうなるべきと思うが、個人としては受け入れ難い。web=internetと言っているが、internetのあり方としてどっかの会社から証明書を買ってこないと使えないというのは許せない。ハッカーとして自由でオープンなinternetが残ってほしい。テキスト/バイナリはどっちでもいいかな
- kenn: HTTPは実のところバイナリプロトコル。性能とかレイテンシというとTLSは明らかに落ちる。光の速度は越えられないw。それがどこに効いてくるかというとRTT。ハンドシェイクで一往復増えるというのはdrawback。CPUも食うし。フロントエンドnginxの負荷ってスケールさせにくい。オレオレプロトコルならAESかなんかにしてバックエンドでほどくなどやりようがいろいろある。それをフロントのTLSに限定するのはどうなのか。あとSSLも完璧ではなくて、ゲームを作っているとクライアントが信用できない場合もある。ローカルのプロキシで点数を書き換えるチーターもいるので、SSLだからと言って役に立つわけではない。役に立たないものに払うコストとしては見合わない
- yssk: webというモノが何かを考える。SSLにしてレイテンシがありますとかね。CDNが効いていて、遠くてもstatelessなら誰かが取ったcacheが効く、ということをbreakしてまでRPC指向でやる必要があるかというのは疑問。RPCは使いようがあるとしても、web全体でどうかというと、それだけではない
break the web
- J: 検索できるのはドキュメントがテキストベースでURLが固定だからというのが前提になっている。いまあるcacheの仕組みが使えなくなるとどうなんだ。break the webと言われますが、そのwebってどうなんだと思いますか
- yohei: 合わないものはこわせばいいと思う。cacheに代わる技術を作ればいい
- J: こわすだけのメリットがbreakした後のwebにあるのか
- kenn: 例えばスマホはwebなのかどうか
- yohei: あれは、むしろネットですよね
- yssk: 従来のロボット型検索エンジンは、Y!の登録型がうまく回らないところから出てきた。今後pubsubが広まっていくと、webの検索に登録するためにpubする、そのためにリアルタイム使うってのはあるんじゃないかな
- J: 登録型に戻る! そこへ行きますか
- kenn: pushは一発。一方pullは空振りがある。pubsubモデルになるとムダがなくなるよね
- yssk: cloud foundryが使いにくい、herokuが使いやすいのはgithubにpushするという操作があるから
- J: 出していただかないとgoogleに入らないよ、publishしてね、なんかの流れになるんですかね。facebookみたいにデータを囲い込んでる人達が検索するような、そんな世界ですか?
RESTに代わるパラダイム
- J: リアルタイムなwebを作りたい、でも従来型のrailsのwebを共存させようとしたとき、クライアント側にはajaxなど変わる必要があった。サーバー側APIはあまり変わっていなかったと思うが、今後WSでpushします、URLベースでないAPIが出てくると、RESTだけわかっていれば困らなかった時代は終わったんではないでしょうか。何をよりどころに生きていったらいいでしょう?
- wada: 道自体は自然発生的にできると思ってる。リアルタイムwebでは、アーキテクチャでは上に乗ってるのはnodeが引っぱっている。herokuはthinでeventmachineが動いているから、リアルタイムはできる。たくさん出てきているライブラリの中からどれがのびてくるか、思考のバッファにおさまるものが勝つのではないか。覚えることが少ない方が勝つ。プログラマの頭に入る量は決まっていて、そこにおさまり切るかどうかで生産性が決まってくる。nodeのasyncを使わないと非同期プログラミングできない。callback hellを見ると、あれはframeworkではあるけど環境ではない。あれを減らすためにasyncが出てきた。そんな風に、上に次が出てきて、大多数が暮らす主戦場ができると思う
- J: パラダイムシフトなのか、エコシステムがまだできていないということか。DOMで言うjQueryのようなものの登録が必要?
- wada: jQueryって言語内言語。一段抽象度の高い言語クエリー言語なんですよ。そこへ来てはじめてやりたいことの記述量が十分小さくなった。覚えられたのがjQueryの良さ。多くの人が「ああこれなら行けるわ」と思ったところがキーになるだろう
- J: 去年流行ったmeteor, socket streamみたいなものの流れだと思うがキラーなものはまだない。WSでやろうとしていることはネイティブアプリでやってたことが近くなる、XMPPでやってたのと同じじゃんみたいな話がある。swing、xmppのノウハウをいまこっちに持ってくることはできないのか?
- kenn: これから勉強する人は難しいことに押しつぶされそうな世界なので、オレオレでいいから作ってみることが大事じゃないかと思う。古い世代の人ほど新しいものが昔のモノに見えるので、逆に若い人ほど新しく作ったつもりが昔の物に似ている、と思えるんじゃないか。やりたいこととしてぜったいゆずれない部分を守るためにオレオレやればいいんじゃないかな
- yssk: 標準にのっかってWSやるなどは動機としてあると思う。うまく乗っかれればうまくいく。自分は乗れると思ってないんだけど。WSうまくいかなかったときに「ほーらね」って言えるw
- J: ysskさんのやりたいことがいまのweb技術で足りてるということ?
- yssk: APIとの接続として、zeromq, rabbitmqでやるかWSでやるかという選択だとは思う。やってみる価値はある。firewallをbreakできるチャンス?
Layer7のさらに上
- J: generalな世界でやるには課題も多いし、まだWSというには早いんじゃという時期だと思う、でも進んでるからやってみたい、この先どう進んでいくんですかね
- kenn: computerって放っとくとインフラは進んでいく。変わらないのは人間。一日に集中できる時間も決まっている。その中で開発をするなら楽をしたい。ソフトウエアの進化。下を改善するより上を良くするほうがいいと思う。TCPを作り直そうという人はあまりいない。UDPの上でreliableやったりはしないではないけど、HTTPってgood enoughだと思う。その上に何かを乗せ込んでいく。HTTPの上にfacebook、その上にアプリのようにどんどん上に行くし、それが人間の抽象度に合っていると思う。人間が瞬時に判断できる帯域は7bitという説があるんですよ
- J: 収束できるレイヤは4とか7ではなくその上にあるという話?
- wada: 人間のspecだけが変わらない。そこを直視する。何かのフレームワークが一瞬で頭に入るかどうか、と考えると、直観に頼るというのはいい指標ではないか。railsって結局、やることを減らしたからプレイヤーが増えた。何が流行るか流行らないかは、一瞬で制約に気づけるかにかかっている。足り算は流行らない。何かと何かを足すのではなく、何かができないかわりに何かができますという風になる。その「できないこと」を瞬時に理解できるか、判断できるかということだろう。その判断ができればみんながやりたいことに近づいていける
- wada: やりたいことがある、でもやりたい人の脳は変わらない。じゃあ何かができなくなる。同じかより高い抽象でプレイヤーがそろうところにアンテナを張っておくべき
- J: 抽象化の行き先って単純なRPCを定義できるかというところになるんですかね? 抽象化の先ってどこに向かうと思います?
- J: 今本当に何が起こっているかを出そろわせて、じゃあ次の一歩で自分が何ができるかってことを話すのは難しいと思う。自分で考えられるような人間を呼んできて聞く、というこの場はよかったと思う
- J: 自分で考えたこれからのwebについてブログに書くまでがこのセッションということで
感想
考える材料をたくさんもらったセッションでした。自分のものにするには時間がかかりそうです。
Jackさんの話の振り方は本当に上手でしたね。名司会だったと思います。
追加
セッション終了後、@yoheiさんからこんな提言がありました
CROSS 2013レポート(3)
CROSS 2013レポートパート3です。malaさんのセッション
間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。
安全な利用規約の作り方
- http://www.cross-party.com/programs/?p=131
- @bulkneets(mala) NHN ライブドア方面
なぜ利用規約
- エンジニア方面の話をします
- 炎上したり、海外だといきなり訴訟
- 利用規約やプライバシーポリシーの無理やりな解釈
- 個人がさわぐ → メディアとりあげる → 取材に応じる前に広まる
- そんなつもりじゃないのに炎上する
- 作る側、使う側の視点から
- 無理やりなイチャモンでサービスの印象を落とすのは本意ではない
- 本当にヤバイものがわからなくなってしまう
- 利用規約が「評判リスク」であると扱われてしまう
- エンジニアができそうなこといろいろあるんじゃないの
- 「利用規約はgithubに置け」
- やってるのはtumblrくらい
- 変更履歴 〜 ユーザーに不利な変更などもわかる
- 普通の企業の法務はぜったいにやらない → エンジニア発想
前提知識
- 個人情報保護法
- 種類・利用目的
- 特定電子メール法: オプトイン
- プロバイダ責任制限法
- 不正アクセス禁止法
- あずかったパスワードを別目的で使ってはいけない
- 不正指令電磁的記録に関する罪
- 「意図に反する動作」+「故意」=ユーザーをだましてやるという意志が必要
- 例: HDDフォーマットツール
- だまして実行させることを意図して配布すると有罪
- バグ → 意図がないので罰されない
- じゃあ、利用規約のバグは?
- ソフトウエアの挙動と利用規約の説明がくい違う場合がある
- ユーザーが「そんな動作をするとは思わなかった」「だまされた」と主張するかも
- バグは処罰されないはずだが、「本当にバグなのか」
- 絶対にユーザーの意図に反することがない ← 幻想
- どうすればいいのか
- 解釈のぶれの範囲がプログラムの挙動と一致するように
- 心理学などが必要。人間は仕様書どおりに動いてくれない
- アプリの実行環境
- permissionモデルの欠陥
- アドレス帳使います、ネット使います → 送信するかどうかわからない
- Adobe Air → ネットとローカルは排他だった
- → いまは現実的ではない。ネットのないアプリなんか考えられない
- スマホアプリ → webアプリのfront endにすぎない
- サーバーのコードとローカルのアプリの組ではじめて仕事になる
- コードを見せたくない人 → 解析されずに動作が制限される仕組みが必要
- 逆にコードを見せてもかまわない人は見せればいい
- 法律面の変化
- 不正指令電磁的記録
- 今まさにソフトウエアの信頼を技術的に担保しようとしている時期に出た
- ユーザー側に害を与えるのは多くはサーバー側
- 不正指令電磁的記録
- 残念な運用
- どうしてこうなった
- ガチのマルウエア作者はつかまらない
- 完全匿名
- backorifice → 正当な目的もあるので堂々と配布されてる
- プログラムの信頼 != サービス全体の信用
- 実際のサービスの信頼が必要
- 社員が信頼できるのか
- 法だけが規制ではない
- 法律による規制はどうせ無法者には役に立たない
- アーキテクチャによる規制・技術的に悪用できない仕組みが必要
- 市場原理 → 悪用することによる利益よりも、バレたときの不利益を大きくする
- 取得できる情報は様々、確認ダイアログがあったりなかったり
- ブラウザ履歴、アプリ一覧、プラグイン一覧など
- フォント一覧は描画してみればわかる → どんな年賀状ソフトが入ってるかわかる
- iOS
- canOpenURLでカスタムスキーム登録状況がわかっちゃう
- 自分の電話番号は公式には取れない → アドレス帳から推測
- Android
- アプリ一覧は誰でも取れる(package一覧)
- 保護されるべき情報とそうでない情報
- 境界は曖昧
- 実行環境によって多種多様
- CSSのvisited linkの取得問題
- 訪問済みリンクの色でわかっちゃう
- プライバシー侵害の問題が正当な利用より大きく評価された
- 取れちゃマズイ情報 → ユーザー許可
- 現状、許可なく取れる情報は使っていいの? → 判断が難しい状況
- 画面の解像度とか
- アドバイス
- 情報の質、ユーザーリスク、悪用・漏洩した場合の被害規模を考える
事例
- スクエニの会員制サービス
- 本サービスへの不満を流布する行為を禁止
- 他サービスでも「その他当社が不適切と判断する行為」があるから、スクエニの方が正直
- 元々、解釈次第でなんとでもできる → エンジニア視点ではバグのようなもの → 運用でうまく
- googleの通話履歴利用問題
- Instagramの例
- 写真を売るはずはないのだが
- ビジネスモデルに無理解だと、無料サービスだから個人情報売ってると誤解される
- 典型的な間違い
- 売ってしまったら継続的に利益が出ないので、そんなサービス作るはずはない
- 使う権利を売っている
- ビジネスモデルの知識欠如、無理解から、「悪いことしてるんじゃないか」という憶測が生まれる → 根拠のないまま流布される
ケーススタディ 〜 よい事例
- Mozilla
- 潜在的個人情報: 単体では個人を特定できないが他の情報と組み合わせると特定できるもの
- 収集している情報は後天的に個人を特定できる情報となり得る
- 「個人情報ではありません」という間違った表示をして回避しようとしてしまう
- Siri: リンクしないポリシー
- URLにはsensitiveな情報が含まれることが多い
- 個人情報かどうかってはっきり決まるものではない
- 個人情報です → 取扱いに制約
- 個人情報ではありません → うそになってしまう
- アドバイス
- 楽天の生メールアドレスをショップに渡すかどうか問題
- 委託 → 楽天に監督義務
- 提供 → 義務はない
- 「業務に必要な範囲」かどうかすぐにはわからない
- そもそもメアドって個人情報?
- 総務省: 組織名、個人名が入ってない記号は違う → えええぇ?
- アドバイス
- ユーザーがコントロールを失うタイミングで警告するのがよい
- 誤解を招きそうなときは別途補足すべき
- 暗号化・ハッシュ化
- 通信経路だけなのか、保存状態なのか。社員でも復号でなくなっているのか
- Dropboxの例
- 技術的に不可能なのか、就業規約としてダメなのかがわからない
- 著作権管理
- リンク
- 電話番号自体はひみつじゃない。「誰が持っているか」が秘密の情報
- メアドも
- 公開/非公開の中間状態があるだろう
- googleの予備のメールアドレス
- 予備のメールアドレスでプロフィール検索できる
- パスワード再発行専用で非公開のものと区別される
- FBのソーシャルグラフ
- ユーザーが許可しても、アプリ外にexportは禁止
- livedoor.comの画像
- クッキーからセッション見ると、Web行動履歴を取ることはできる
- だけど静的情報なのにわざわざセッションデータベース見たりしないよ
- google+
- +1ボタンのポリシー: 統計には使えると表示
- やらないことを明示しているにもかかわらず炎上
まとめ
- サービス提供側とユーザー側の認識のギャップが無視できない
- 経営者、法務、技術者の利解も違っている
- リスクマネジメント → 悪循環
- 透明性確保
徳丸さんとの対談
ここでPCが電池切れとなったので、自分のツイートから発掘
