「ユーザビリティ」を含む日記 RSS

はてなキーワード: ユーザビリティとは

2017-10-08

ユーザビリティで「結果の一意性」を考える

ユーザビリティの分野で「結果の一意性」(「結果の予測やすさ」と言い換えてもいい)を考えれていない人が意外と多いようだ。

一例として、「メニューボタンを押してメニューを開く」「下キーメニューの2番目の項目に移動」「決定キー」という一連の操作を考えてみよう。ツール使用に慣れたユーザメニューボタンを押した後に、選びたい項目が2番目にあることをいちいち視認したりはしない。画面が切り替わるより早く下キーと決定キーを押す。画面のレスポンス待ち時間視覚から情報を取り出す処理時間がロスとなるからだ。さて、ここでツールに「以前のカーソル位置記憶する」という一見して便利そうな機能を加えるとどうなるか。そう、前回のカーソル位置ユーザ記憶していない場合、前述の時間ロスが発生するのである。これが「結果の一意性」が損なわれる例だ。重要なのは、このカーソル位置記憶機能が高い確率操作回数を減らしてくれているにも関わらずユーザは使いにくく感じる、という点である

ライブ変換機能邪魔に感じる人が多いことは「結果の一意性」に関して別の見地を与えてくれる。従来の変換形式場合ユーザ平仮名を打つ場合には結果の一意性が保障され、文字変換が必要な時にだけレスポンスを処理していた。つまり、「変換キーを押さずにEnter」or「変換キーを押して変換結果を選択」で一意な結果か否かを分離できていたのである。これに対してライブ変換機能は常に変換候補提示しており、レスポンスの正誤判断を要するタイミングが分離できていなくなった。ユーザとしては、操作は減ってもレスポンス判断する機会が増えているため、使いにくいと評されるに至ったのである。すなわち、「結果の一意性」を保障できないならできないで、そのタイミングを明確にすることでUIは使いやすくなる、というわけだ。

ユーザ操作に慣れるほど、次の操作判断にUIからレスポンスを用いなくなるため、結果が非一意であることのデメリットも大きくなる。単純に操作回数だけでUIの品質評価することを辞め、レスポンス必要となる場合判断コスト考慮すれば、世のUIはもっと良くなっていくことだろう。

2017-07-23

スシローネットでお持ち帰り注文スマホでできない

休日の昼前とか夜前とかに頼もうとすると絶対できないんだが

詳しく説明すると、注文しようとして店舗選択しようとすると「注文できる時間開店から閉店までの時間です」的な表示が出てそれ以降進めない

スシローおいしいからよく使うのにこれだけはまじ不便なバグ

バグじゃなかったら忙しい時間帯は予約できないようにあえてやってるとか?だとしたらユーザビリティ考えてもっと適切なメッセージを出してくれよ

もやもやする

2017-07-11

「今の子供にロボットアニメが売れない」はデマ

最近オッサンロボットアニメ好きやロボットアニメに関わっていたアニメーターなどが『今の子供にはロボットアニメが売れない 子供にはロボットの魅力がわからない』

などとTwitter投稿し それが「本当にそうですよねー」「僕らの頃と違ってー」と老人が承認しあう地獄が生まれている

では本当に今の子供にロボットアニメが売れていないのか?

答えはNOである

の子供にはむしろ巨大ロボットの変形合体おもちゃバカ売れしており売り切れ続出中なのだ

いったい何が売れてるのかというとこれである

トミカハイパーレスキュー機動救急警察ドライブヘッド

http://www.takaratomy.co.jp/products/tomica/drivehead/top.htm

『巨大ロボに変形するトミカ』として展開されてきたトミカハイパーレスキューシリーズ

これがめちゃくちゃ子供に売れており ついに今年2017年4月からTVアニメスタート

土曜日の朝7時というおそらくオタクは見ていない時間帯に放送されているが 子供は見ているのでやはり大ヒットである

アニメ化に合わせてアニメ版デザインリメイクされたロボットたちの玩具は飛ぶように売れ

タカラトミー公式アカウントは新商品の売り切れ情報を呟く

パトカー消防車が巨大なトレーラーに合体し 巨大ロボットに変形するというロボットアニメファンには夢のような展開

さら戦闘機ヘリコプターといったサポートメカシンクロ合体することによるパワーアップ

そしてそれらを玩具再現子供達が実際に遊ぶことができるユーザビリティが評判なのである

アニメ放送もついに1クールを迎え これまでレスキュー活動主体にしていたハイパーレスキューたちの前についに悪のロボット軍団が現れ

彼らとの戦いのために 主人公機がパワーアップするなどのお約束展開まで盛り込まれ

はっきりいって「僕達が子供の頃好きだったあのロボットアニメ」が今まさに放送されて しかも売れている状態なのだ




ここで本題に戻ろう

なぜトミカハイパーレスキューがこんなに売れているのに 彼ら老人たちはトミカハイパーレスキュー存在認知せずに

子供にはロボットアニメが売れない』と言い続けるのか

どうしてロボットアニメの今を嘆いてるように見せかけて今のロボットアニメを見ていないのか

彼らはもう本当はロボットアニメなんかに興味は無いのだ 昔ロボットアニメが好きだっただけの老人なのだ

から彼らが「ロボットアニメ子供に売れてない」とツイートするたびに『トミカハイパーレスキューバカ売れしてますよ!!』とクソリプをぶつけてやってほしい

彼らの腐った目を覚まさせてあげてほしい


ちなみにトミカハイパーレスキュードライブヘッド機動救急警察ドライブヘッドのYouTube公式チャンネルで毎週見逃し配信をしている

今回は公式がアップしている ドライブヘッドの3体のメカの変形シーン集のURLを貼ってお別れしよう

https://www.youtube.com/watch?v=uwJeQUgUyEs

それではみんなも ゴー!レスキュー

2017-07-02

https://anond.hatelabo.jp/20170702091356

ユーザビリティ考慮されたサイトでは、矢印キーで次のページに進む が可能だよ。

ブラウザ実装されるのはあと数年かかるんじゃないかなぁ

2017-04-26

ニコニコは金払ってるユーザーユーザビリティ還元しろ

栗田穣崇Shigetaka Kurita‏ @sigekun 1時間1時間

その他

ドワンゴマストドンに貴重なエンジニアリソースを割いてニコニコをないがしろにしているように思われているようですが、マストドン静画チームを中心としたエンジニア数名の取り組みで、ニコニコバージョンアップには全く影響ありません。

という発言

いやいやお前らニコニコ静画だってまったく仕事できてないだろうが

並みいるマンガアプリの中

なんなのあのニコニコ静画アプリサムネ画像の汚さは

使いにくいインターフェース

マジでとにかくサムネの汚さはなんとかしてやれよ

他のアプリで見てみろ

サムネキレイに作ってるだろうが

あたりまえだよ、それでユーザーは読む読まない決めてんだよ

そのサムネをお前らニコニコ静画はずっと汚いままで放置しやがって

お前らはライバルアプリを使ってないのかよ

他のアプリ無料なのに、お前らには月500円払ってんだぞ

どういうことだ

2017-03-06

スマホの画面下部に半透明で降りてくる広告バナー

こんなもん作って喜んでる広告業界ほんと糞すぎんだろ

ユーザビリティを殺すのはいだって広告のやつらだ

意図的バグ仕込んでるのと何が違うのか。

わざわざユーザー不快な思いさせて広告的な意味があるとでも思ってんのか

まじでウザすぎる 絶滅しろ

2017-01-22

モラル崩壊意識高い(笑)エロサイト管理人面白すぎる

http://megalodon.jp/2016-1224-1118-40/masturbate.io/

ここに来る方は皆さまムラっとされているでしょうが、少し我慢して読んで頂けると幸いです。

ちょうど4年前、

「新しくてキレイエロの形」

を追い求めて授業をサボって全力で打ち込んだのがこのmasturbate.jp(io)でした。

シニアSEという設定でしたが当時、二十歳のクソ大学生でした。嘘ついてすみませんでした。

現代的なデザインユーザーが同士のキュレーションタグユーザーフォローを通して、

みんなが"最高の動画"を発見できる。

なぜでしょうかね、こんな事、人に誇って言える事じゃないんですけどこのサイトの開発をしている時は本当にアツくなれました。

もっと勉強して速度改善ユーザビリティの向上に努めないと、、って本当に思いました。

当時エロサイトというのは古臭いデザインや偽リンクがはびこり快適な時間を送るのには大変難し状況にありました。

そんな状況を変えるべく、ユーザーに喜んでもらうために僕は4年間全力で駆け抜けてきましたつもりです。

お陰様で月間200,000,000PVという偉業も成し遂げ

エロサイト検索で一位を長らく獲得していました。

まあその数字もそうですが、やっぱりマスターベーターを中心とする皆さまとのコミュニケーションをする時間は本当かけがえの時間でした。

「おいおいエロサイトとき何を熱く...」などと言われそうですし、僕も時々そう思う時もありますが、

フィードバック意見下さる方や、アド職人タグ職人女優コメント職人の皆さん本当にアツいんですよ。

アユーザーとは一回くらいお茶でもしたかったですね。

2016/12/22 藤代まこと

一人お茶をすする...

クリスマスくらいはマス禁(マスタベ禁止)してみると良いことあるかも。

2016-12-15

http://anond.hatelabo.jp/20161215123844

>でも「自分入力するのヤダヤダ私が欲しい結果をエスパーしてくれないとヤダヤダ」とか言ってるお子様にはお似合いじゃねえの。

え?

それがGoogleが目指す先なんじゃなかったの?

究極のユーザビリティってユーザ個々にとって最適な情報結果を同じキーワードでも出してくれることだろ

それやらなかったら何のために情報ひっこぬいてんだよ(※広告のためです)

それ自体は今の時点でもある程度やってるけど、その精度がエスパーどころか痴呆老人レベルなわけなんだが

その痴呆エン人の徘徊がもたらしたのがウェルク問題であり未だ放置されてるパクリサイト問題だろ

誰がどうみても不特定多数に対して情報価値の低いパクリサイトビッグワード検索上位に挙げているのは

ヤダヤダレベル問題じゃないんだけど

巨人ビッグワード食うたびに糞尿垂れ流しまくってたらため息ついて言葉を失います

検索下手である圧倒的多数利用者が糞を食ってるんですよ

世の中俺やお前みたいに最適な詳細検索設定できるマニアなやつなんて世界人口全体の数%程度しかいねから

やってることは全くかっこよくなくて大量のクソの中から使えそうなやつを金塊のように探ってるに過ぎない

使いにくい道具を使わされて、その糞の掬い方を知ってるというだけで

クソまみれの顔と体で得意げな顔をしてドヤ顔して悦に浸って骨の髄までクソ教育された優等生がお前(これでヒョロガリノッポ眼鏡ならビジュアルばっちり)

もはや検索エンジン意味を成してない 鼻が曲がる

ユーザー全体の質とそれに対する影響力の大きさを考えろ

事実問題になってるけどそれについても眼をそらしてお前らが悪い設定が悪いとか言い出すの?

もはや思考停止領域に両足突っ込んでるんだが

ゲームバグ残してユーザーが発生したらお前の遊び方が悪い!ってクリエイターいたら口がふさがらんだろ

パクリサイトバグよりも酷いわ

もう5年越しに放置してる問題

5年間もバグ放置してるゲームとか普通クソゲーとしてしか認識されんが

残念ながらこの世界には出来の悪いインベーダーゲームしかなかったな

みんなインベーダーゲームの謎(SEO対策)を解いて小銭稼いで

それに対して愚痴りながら嫌々パンダってるのがGoogle

アップした後にお決まりのように「ユーザーにとって価値あるコンテンツ評価する」動画ブランディングを忘れない

SEO業者・悪VS正義Googleという信者聖書に記された二元論作ってまた自分のやりたいことやるためにアルファベットに引っ込む

そしてまた始まるバグ探し

それらが出すクソに巻き込まれ情報弱者ユーザーコンテンツ

この関係性をもう何年も繰り返してる

検索エンジンはただの集金ボックス

2016-12-09

G○○gle検索エンジンはただの集金ボックス

SEO対策意味が無い淘汰される

ガッツリ影響しています

対策意味が無いと言えるのは対策存在しないアルゴリズムGoogleが用意していないと成立しない

けど実際は対策があってそれをすることで上位に食い込むことができる

完全に大嘘

単にSEO対策されるとユーザビリティ下がるのでこういって無知情弱予防線貼っていただけ

その状況で

 

本当に価値のあるコンテンツさえ作っていれば自然評価される

されません

あんたらは自然に淘汰されるような設計で作っていません

自分らが一番分かってるのにトップが平気でこういう嘘をつく

その結果生まれたのがキュレーションサイトです

キュレーションサイト絶対になくなりません

姿形を変えて第二、第三のキュレーションサイトが必ずや現れるだろう

 

ぶっちゃけ広告を貼れる大手けが理解して得すればいいし、分かってない金持ってない情弱個人サイトことなんてどうだっていいわ、金さえ集まればどうでもいいんだよ。お前らに真実情報とか不要でこっちはカモとしてしかみてないから。でもカモを信者にしておいたほうが都合がいいからこういうわ(笑)「本当に価値のあるコンテンツ評価する」)

これが真実

自分らが用意したSEO対策さえ紐解けない金持ってない層は最初から相手にしてないし

情報価値なんてどうだっていいとすら思っている

対策しないという事実意思表示のもの

いつも対策したといっても取り繕ってるだけの中身の無い対応

結局用意した問題を解かれたら新たなSEOが開始されるだけ

まり時間稼ぎでしかない

GoGo検索エンジンはただの集金ボックス

これまでのやってきたことを振り返ればそう結論づけざるを得ない

2016-11-23

自己投影女子に告ぐ

   11/24 長すぎて入らなかった部分を別記事で追記

腐女子こそ夢小説を書くべき論」が話題になって「よくぞ言ってくれた」と喜んでいる人と記事自体に怒っている人がいた。

記事自体に怒っている人、とりわけ「腐女子こそ夢小説を書くべき論」を読んで欲しい層として想定された(と思われる)「腐女子」以外の人について考えてみた。

腐女子こそ夢小説を書くべき論 - 模索中

腐女子以外で、この記事に対して怒っている人たちに、自分たちを「自己投影勢」と自称している人たちがいる。

自己投影勢」とは?

夢小説を愛好する方の中で、主にガチ恋勢などと言われる人たちのことだ。

彼女らは、夢小説に出て来る名前変換が可能な「主人公」に自分だと思いながら、夢小説を読む。

私は怒っているので、キツイ言い回しになっているかもしれない。

この記事を書いている私は、彼女ら「自己投影勢」の「腐女子こそ夢小説を書くべき論」に対する反応に怒っている。

私が怒っている対象は「自己投影勢の肩身が狭くなるから、こういった記事を書いて腐女子が書く夢小説を増やしてほしくない」と言っている人たちだ。

自己投影全般に怒っているわけでもないし、嗜好について私の理解が及ばないと思っていても馬鹿にもしていないし、気持ち悪いとも思っていない。

彼女らに私の嗜好を貶され、排除しようとされない限りは、はっきり言って、彼女らがどう思っているかは興味がない。

嗜好を名指しして「布教をするな」と言われたのでなければ、この記事を書くことはなかった。


上記の自己投影勢の説明ではあまりにいい加減なので、ある程度、前提条件を絞りたいと思う。そのために私の自己投影名前変換に対する考えを記述する。

私と同じ考えだと自信のある方は飛ばしていいと思う。

目印として本題に入る部分に矢印をいっぱい付けておくのでそこまでスクロールして欲しい。


私のスタンスとしては、他人が書いた小説主人公自分だと思いこむことは特殊技能であると思っている。


これは、キャラ恋人自分だと妄想することとは別の話であることを留意してもらいたい。

誰かの恋人になった自分空想すること自体は、誰もが抱くことのある欲求ひとつであると私は思う。空想し、それを作品アウトプットすることもまた、ありふれた行動であると思う。

しかし、小説という作品媒体になったものを読むとき登場人物が「自分だ」とはっきり信じることのできる人は多くないだろう。

これは感情移入とは異なるものだと私は思う。

映画や本を読むときに、話者となる登場人物感情移入してストーリーを疑似体験する。これは基本的エンターテイメントだと思う。

感情移入する登場人物主人公に限らない。幼少の頃に見ていた映画大人になって見ると、幼少の頃に思い入れ登場人物とは別の人物気持ちになって泣いてしまった、ということはよく耳にする話だ。

さて。このとき観客あるいは読者は、登場人物登場人物であって、自分とは別の個体であることを認識している。境遇自分に重ねることはあっても、自分ではないと分かっているはずだ。

ここでいう感情移入共感意味だと思う。

腕にひどい怪我をした人物を見て、自分の腕が痛い気がして顔をしかめる。怪我一つない自分の腕を押さえる。これが共感だ。多かれ少なかれ、誰しもが持っている感覚だといえる。

共感」は人間社会生活を円滑にする上で欠かせないものだ。一説では、サイコパス共感的な感覚先天的に欠いているのだという。共感が出来ないからと言ってその人がサイコパスであるとは限らないことに気をつけたい。

この共感が強すぎることで、映画テレビを見るのが苦痛だという話が、しばらく前に話題になったと思うので、「共感」というものがピンとこない方はそっちを覗いてみるのがいいかもしれない。

"恥をかくシーン"が苦手な人たち

話は戻って、名前変換によって、いくら登場人物自分名前を冠しているからといって、主人公自分だと思い込む、ということは「共感」ではなく「同一化」に当たるのではないだろうか。

サイコパスの話を持ち出してしまったが、専門用語としての話ではないのでその点はご理解いただきたい。

自己投影と称している人の中で完全な「同一化」ができる人はそう多くないのではないだろうか。多くの人が、夢小説の中で恋愛をしているのは小説の中の「わたし」であって、今この世界にいる「わたし」でないものだと折り合いをつける。

自己投影ってなんだっけ - めもかん。

この記事を書いた方も、おそらくそうだろう。

2は、1よりちょっとだけ現実の私と切り離されている。 なんというか、原作世界二次創作世界パラレルワールドだと認識しているのはこの層が多いんじゃないかなあ。 その世界の「私」となって、キャラと接するのがこれに当たる。

「同一化」と書いたものをこの方のいう1とするならば、2は「折り合いをつけている」人たちのことだろう。3の話はここではしない。

この折り合いが付けられた状態は、映画を見て登場人物共感して涙することと差がないように私は思う。


余談 コンピュータ名前変換 ゲーム夢小説

夢小説は、コンピュータインターネット回線の普及によってもたらされたジャンルであると思う。

それまでは小説といえば紙の書籍主体で、印刷物として市販されている小説主人公たちの名前は変えることができなかった。

それが、コンピュータの普及によってテキストの一部を自分名前に変えることができるようになった。これを女性向けとして利用した人が現れる。これが夢小説のはじまりだと思う。

夢小説の出現よりもひと足早く、ゲームでも主人公名前自分名前に変えることができることが「普通」になっていった。その片手で、インターネット上に公開された名前変換可能テキスト群が夢小説と呼ばれることになった。

一見違うもののように見えるが、双方デジタル化によって生まれユーザビリティの結果であり、本質的には同じものであると思う。

そこで、ゲームをしているユーザー自分名前のついた主人公を「自分だ」と思い込むことができるだろうか?

これは、できる人もいる、が正解だと思う。自分選択によって動きを変える主人公が、自分であると思う人もいれば、画面の中で動く人型のイラストを、自分が操っている操り人形だと思う人もいるだろう。

後者については、海外に多い「プレイヤー視点が画面になるタイプゲーム」のユーザー間では減少する可能性がある。ゲーム内のアバターアバターだと認識することは、ゲームプレイヤー自身アバター俯瞰する形になる、多くの日本産ゲーム特有感覚かもしれない。長くなりそうなので、ゲームでの視点の話はこの程度にしたい。

余談の余談

余談の最後に、私が思うゲーム夢小説の違いをまとめて、話を「自己投影」についてに戻していこう。

ゲームには操作性の問題がある。主人公の行動を自分で操る事ができる。この点が、ただ与えられたテキストを読むだけの「夢小説」とは大きく異なる点だろう。

夢小説の中に出てくる登場人物の行動を、読者は変えることができない。

夢小説の中に出てくる登場人物セリフを、読者は変えることが出来ない。

繰り返しになるが、自分意思とは違う行動を取り、違うセリフを喋る主人公に「共感」するのではなく、「自分だ」と思い込む、「同一化」する事ができるということを、私は特殊技能であると思う。

私の一歩先を行っているのかもしれない、とも思う。


同担拒否」を自称する方たちに対して、いくつかの疑問がある。

まず、私が思うのは彼女らは何を読んでいるのだろう?ということだ。

人が書いた小説を読めば、必ず違和感が生じるだろう。お母さんが枕元で、主人公名前子供名前に置き換えて読んでくれることとはわけが違う。クラスメイト貴方主人公小説を書いてもらい、プレゼントしてもらうのとも違う。

ただ、スクリプトを使って文字列自分名前に置き換えているだけだ。

好きな食べ物も、癖も、言い回しも、得意な教科もすべて変換するわけにはいかない。そんなに違う「わたし」とどのようにして「同一化」するのだろうか。

そして、彼女らは自分で書いた小説を公開するのだろうか?

自分恋人の話を綴った物語を公開して、自分と同じように彼を恋人だと思いこんでいる人が読んで、自分体験他人のものにされることが不愉快ではないのだろうか?

このあたりの感情の処理が、私には理解しがたい。

↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

本題にうつる前に周りくどく鬱陶しい話をしたのは、前提条件をはっきりさせておきたから、と断っておく。

本題はその「自己投影勢」がなぜ「腐女子こそ夢小説を書くべき論」に怒っているか

なぜ、私が「自己投影勢」が怒っていることに対して怒っているか

という話だ。

私がTwitter観測した限り、怒っている理由には大きく分けて2つあったように思う。私が見かけた2つの理由について話をしたい。

怒っている理由その1

自己投影勢」が馬鹿にされたと感じたか

だそうだ。

これは見当違いな怒りであると私は思う。「腐女子こそ夢小説を書くべき論」の中で、たしか

夢小説ってキャラ×自分なんでしょう」「わたし夢小説自己投影しないし」

など書かれている部分はある。

しかし、これは、この記事を書かれた方の意見ではないのだ。少なくとも私にはそう読める。

私が読むところによると、これは、世間から夢小説」に対して向けられている一般的感想だ。

偏見としてあげられる言葉を持ち出すことすら許さないならば、許さない人が偏見を持っている人にやめてくださいと訴えるべきだ。怒りを持っていく場所が違う。

誰が発言するかによって怒りが違うならば、それは貴方の心にある差別が原因だろう。胸に手を当てて心当たりを探ることをおすすめする。

そういうのもあるけどそれだけじゃないよ!


としているが、自己投影的な考え方を否定しているわけではない。むしろ、全体を通して自己投影は誰もが持ち得るものだと書いているように私には読める。

そもそも、「それだけじゃないよ!」は嫌っている人に嫌いなものをそのまま食わせる馬鹿はいないので「夢小説あなたが嫌いだと思っているものよりもずっと多様なものですよ」と話しかける言葉だ。自己投影を貶めることは書いていない。

行間から書いていない言葉を読み取るのはやめたほうがいいと、老婆心ながら言わせていただこう。

そのうち行間から呪詛を感じ取ってこの記事のせいで呪われたなんていい出しそうだ。

ちなみに今わたし貴方呪詛をかけている。嘘だけど。

怒っている理由その2

夢小説から自己投影勢が追い出される、

というものだ。


はっきり言おう。私にはこの感覚がまったく理解できなかった。そして、これを理解したことによって怒っている。

夢小説のはじまりは、自己投影にある、と言っている人がいた。これは当初のことがわからないので、間違っているかあっているか問題にしない。

私がこれに対していうことがあるとすれば「だから何?」だ。

から? 幼稚園児が遊び場の権利を「すべり台わたしが先に使っていたのでわたしのものです」と主張するくらいにどうでもいい。

余談としてゲーム夢小説の部分で触れたが、主人公名前を変えるという考え方自体は珍しくない。それを二次創作に使うことは、誰にでも思いつく可能性があったことだと私は思う。

夢小説流行り始めた当初、このスクリプト自分で書くことのできる人は少なく、多くの人が他人からこれを借りた。

その借りた先の人が「夢小説」あるいは「ドリーム小説」と読んでいたのなら、これは自己投影云々についていた名前ではなく、名前変換というシステム自体につけられた名前であると私は思う。

異論はもちろんあると思うが、自己投影がたしか原初であったとしても「だから何?」と私は返すだろう。

夢小説ルーツでの幼稚なマウント以外に、私は「追い出される」という感覚理解できなかった。なぜなら、10年以上も前から自己投影勢もあったし、オリキャラ勢もあった。共存していたのだ。

古の超大手夢小説検索サイト「ワンドリサァチ」さんのキャッシュからも、当時から細かく別れていた傾向のチェックボックスを見るとわかるのではないかと思う。

ちなみにワンドリサァチさんがページ消失したのはかなり昔のことだ。ワンドリサァチさんの消失夢小説界隈を、まるで神に言語を乱され方方に散ったバベルの塔逸話のように、引き裂いた。

夢小説史はさておき。なぜ突然、オリキャラ勢が押し寄せてきて……なんていいはじめたのか。

しかに数年前から「夢主はオリキャラです」と発言やすくなったことは感じているが、これはオリキャラ夢主で夢小説を書く人たちが、仲間を募り、自身創作を楽しんだ結果であると思う。彼らは自分たちで、自分たちの楽しむ場を作った。これに嫉妬しているとしたら、理解に苦しむところだけれど、同担拒否です!この小説は私じゃないので読めません!なんて言って、他人牽制しまくっている人がいるのなら、仲間が増えないのは当然だろうと思ったのでこの点は言及するのはやめておこうと思う。

私にとっては、自分の好みではない作品が増えたところで、自分の好きなもの絶対数が変化しなければ、どうでもいいことだったのだが、彼女らにとってはそうではなかったらしい。

問題になった「腐女子こそ夢小説を書くべき論」では、腐女子BL主題として扱った夢小説を書くことを勧めている。

このことに対してアレルギーを起こしたように反応している人たちがいた。

腐向け」という言葉が目に入るだけで、不愉快なのだそうだ。

そもそも、オリキャラ夢主と自分の推しが恋愛しているという情報自体が気に入らないのだそうだ。

腐女子が参入することによって、腐向けでもあり夢小説でもあるものや、彼女らにとって不快ものが増えることによって、住処を追われるのだそうだ。

先述の通り、昔からオリキャラ主人公とする夢小説存在していた。

夢小説を愛好する人の中には「腐向け」を嫌う人は多い。しかし、夢小説の中には「腐向け」の夢小説BLDと呼ばれるものもある。BL夢小説彼女らが何を思うことにも関係なく、すでに存在する。

はっきりいいたい。「何様のつもりだ」

インターネット上は公共の場所だ。不愉快ものを見ることもあるだろう。しかしながら、貴方にとって不愉快ものは、誰かにとっての大切なものだ。それを見て貴方が気分を悪くするだけならいい。

気分が悪くなるから、遠慮しろ、肩身を狭くしていろ、というのは傲慢がすぎるのではないか

腐女子も好きなジャンルで、自分が好きなカップリングとは受け攻めが逆のカップリングが増えてしまうこともあるだろう。逆CPは見るだけでイヤだという人も多いだろう。しかし、だからといって自分の気に入らないCPをの悪口を言ったり、そのCPが増えてほしいという人に、私の地雷から布教活動をしないで下さい、と訴えることを考えて欲しい。

私なら人混みで鳩尾に肘を入れるし、靴を踏む。(暴力はよろしくないと思うがそれくらい腹立たしい)

貴方自身の当然の権利と思って言っているそれは、これと同じことだ。恥を知るがいい。


マナーやら何やらで加工して訴えようと、本質は変化しない。貴方自分不愉快からと、他人活動制限しようとしているのだ。いかなる理由をつけようと「布教活動するな」と訴える行為正当化されないことを覚えておくべきだ。


腐女子の人が「自分の好きなものではないので書かない」ということとは、わけが違う。

自分の好きでないものに増えてほしくない、という権利貴方にはない。

そして、自分の好きなものが数で負けるなら、その分は貴方がかけばいい。貴方布教して増やせばいい。貴方夢小説を読んで楽しいと思った人が、同じような小説を書くように努力すればいい。

他人の足を引っ張るだけの行為生産性がない。

あと、検索で引っかかって云々とか言うな軟弱者。心を鍛えろ。

自分の行動の責任自分で背負え。

蝗に怯えて耕作を怠るな。実りのない田畑では人も増えない。

心優しい私は、対処法をあなたに教えてあげようと思う。心して聞くがいい。

Web ブラウザ上の文字列検索して非表示にするNGワード導入しろ。それくらい自分で調べろ。

最後に、そんな発言をしている人が存在するのか疑問に思う人もいるだろう。それでもツイート引用することは控えたことの意思は汲んでいただけたらと思う。

この長ったらしい文章攻撃目的ではない。軽はずみな発言をした人に自分発言を省みてもらうことが私の望みだ。

2016-11-14

今なら飲食店スマホ注文システム標準化して天下取れんじゃね?

なぜ飲食店は食券システムを標準にしないのか?

などとよくネットでは声を出すのに不自由している勢から疑問の声が上がるのだが

こんなことはちょっと頭を1/2回転させれば答えが出ることだ

しかし世の中は時々刻々と次のステップに以降しようとしている

それが飲食店での注文をスマホ一つで出来るようにしちゃおうっていうプロジェクト

現代は一人一台どころか一人四、五台は当たり前の超スマホ所有時代である

皆が持ってるスマホで注文から会計ポイント割引や汁多めや白飯少な目や「ごちそうさま~」まで

どんなお店でも一つのアプリで出来ちゃったらもう初めて入るお店でも大丈夫だし痛くもないだろう

ということで気概あるメーカーよさっさと天下を取ってくれ

電子マネーみたいにせっかく便利なシステムも何社も乱立したらユーザビリティ零もいいところだ

全国の声を出すのに不自由している勢が一斉に街に出る未来を作るのは君の会社だ!

2016-10-22

前もあったけど、メール配信停止設定で

外国 メールリンククリックするだけ

土人ジャップ リンククリックして、ログインして、停止します はい・・・

 

普段Web社会が~UIが~デザインが~ユーザビリティーが~パンティーが~とか行ってる割にこれ

 

英語勉強して、外人システム真似しろ

2016-10-17

How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂英語なんだが。

----

TextSecureの目標は「経路末端までのセキュリティ否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評分析を羅列してある。実装構造研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているか評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コード文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話ハンドシェイク必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイク遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である

ダブルラチェット:

TextSecureの暗号化エンジン中心部はAxolotlダブルラチェットアルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化メッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージ送信するために送信者が待つ必要は一切ないということだ。いつでも送信第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイスのものであっても、過去送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号サーバに教えてもらうことから始まる。また同時に、トークン通話SMSどちらで受け取りたいか希望登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報登録できるようにしてくれる。

クライアントメッセージ認証暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントSMSを受け取りたいかデータだけにしたいか情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリント比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初メッセージ送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報ルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化MACの鍵を生成するのに使われる。

最後AESカウンター初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターメッセージ送信ごとに増える一方で、pctrカウンターは、最後既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手メッセージ暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイク完了できるだけの必要情報が含められている。

SignalサーバGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージ送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイク完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージ送信

相手が返信する前に、もとの送信から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化認証の鍵を得る。これを使ってメッセージ暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロード認証する。これは送信メッセージ認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージ送信も鍵アップもそのユーザなりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップデバイスSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティ問題ではなく、現実問題であり、それに対する後ろ向きな対策なのである

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分公開鍵を、標的の公開鍵に変えればいい。これは自分電話番号を再登録すればできる。送信者はQRコードを使って、相手フィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである

それから、今度は送信者のアカウントを再登録して、その検証SMS確認通話送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージ送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージ暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破限定的時間範囲しか有効でないとする。新しいラチェットのそれぞれに公開鍵必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイスにのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットステート対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェット使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージ暴露である

否認性(アリバイ)はさらあやふやだ。ある特定メッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバ認証メッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

2016-10-16

ユーザビリティを考えれば、スマホ専用サイトなんてものが一番の癌であることは明らかなのに、Googleはどうしてああなのかねえ。

手間かけてますアピールすればユーザーが喜ぶってわけじゃないんだぞ。電通かよ。

2016-09-28

2chニュー速釣りタイトルスレばっかりになってるな

すげー分かりづらい。

ユーザビリティ下がりすぎ。

2016-09-01

チケット転売問題に関するニュース

そろそろ落ち着いた感じですが。

今年の2月にマドンナ来日公演行ったんですよ、25000円。

自腹で払いました。めっちゃお財布に痛かったですがそれ以上の興奮を頂きました。

VIPというかそれ以上の席もあって、10万とかしてたんですよ。

安月給サラリーマンには払えるはずもなくて、席についてくるスペシャルプレゼントとか夢のまた夢ですよ。

まぁ、その席に座っている方々は私より一世代上なマドンナ直撃世代な人たちなわけで、

マドンナ様に対する思い入れも、年収も、何重にも上なわけで、ははーってひれ伏すしかないわけです。

で、最近話題になっているチケット転売問題

5000円のチケットが、10万円になっても、それは市場が求めてるんだから仕方ない。

というロジック、わからないわけでもないです。

一方で、アーティスト運営???興行???)の、無駄価格釣り上げた転売を阻止して、一定価格サービス提供したいというのもわからないでもない。

(いや、正確に言うとわかりづらい……もうちょっとクラス分けしてもいいものかなーって思う)

ものすごく入手しづらいアーティストで、正規10万円のVIPシートゲットした人と、

転売10万円になったA席(8000円)の人が、同じ『10万円』のサービスを受けられるかって言うとそれはない。

見る側が「10万円でも見れてよかったわ!!!」って思うかもしれないけれど、

本来10万円で売られているチケットの席の距離感とか、おまけ(パンフとかミーグリとか)はついてこない。

8000円の席には8000円のサービスしか提供されない。

アーティスト一定クオリティ担保するけれど、非合法でできたバッファの分の価値担保できない。

だっていくら転売されてるなんて知らないし、それはルール上アウトってことになってるから見ない知らない(建前上)。

買うほうがいくら10倍、20倍の価値をつけたとしても、提供されるコンテンツは同じなのです。

でも、見る方は10倍の価値を払った。

から不公平を感じてしまう。

ファンクラブで入手するチケットとかはすでにキャンセル対応、定額トレードの動きに入っています

知らない人は検索してみてください。ファンクラブとかクローズ情報なので、知れ渡りにくいかもしれないです。

欲しい人が8000円のチケット10万払うのは自由です。

でも提供されるのは、8000円分のサービスです。

公式10万円払って得られるサービスは、求められないんです。

公式が掲げるルール違反は、そのチケットにどれだけ払っていようとも排除される可能性がバリ高なんです。

キャンセルしたらブラックに載るというような不安感とか、

手に入らなかったか転売サイト使うという情弱とか、

そんなものを一掃してくれるような、ユーザビリティの良いサービスを望むのが一番かなーと

今年度内くらいになんとかしてくれ!!!

LとかEとかPとか!!!!!!

本日も「お席をご用意できませんでした」メールを受け取り、憤りのあまりチケキャン違反報告をポチポチしながら)

2016-07-01

SFA営業支援)・CRM顧客管理)って本当に上手くいくの?

SFA営業支援)・CRM顧客管理)って頭でっかち机上の空論に思えるんだけど上手くいくの?

 

例えば、営業の全員が見込み顧客入力すれば、全体の見込み数値が出ますっていうけどさ、

見込み顧客いないからって馬鹿正直に申告する営業なんているの?

ほぼ受注可能性が無い名刺の中から適当に見繕って見込みAとかBとかって申告すると思うんだよな

 

ちなみに、昔勤めていた会社セールスフォースを導入したけど使いづらい意味がないと営業から強い反対はあって半年ぐらいで無くなった。

あの使いづらいユーザビリティソフトが有名な意味がわからない。

2016-05-22

http://anond.hatelabo.jp/20160522003506

http://anond.hatelabo.jp/20160522003506

ども。

この辺りの一連の発言特に後二者)を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAWeb APIといったフロントエンド世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます

ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データ配信DB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリレベルに追いつき、同じやり方ができるようになった、というだけの話です。

とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。

具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドリアルタイム集計が登場する勤務予定表的なものを、1人でjQuerySPAで作った際、数百行のHTMLと数千行のJSスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代ベスト」として自信を持って残せますJSX局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません(私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います)。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。

「変な独自拡張を入れてまでJSを使い続ける理由わからん」についても、まるでJS生来嫌われ者で、クライアント側でもPythonRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね? たぶんES6は人々から積極的に愛されています。現状、クライアント側にPython進出するのではなく、逆にデスクトップモバイルサーバ側にどんどんJavaScript進出する流れが起きています

速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね(mustache使うよりは速いよね)ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通JS技術者普通に触れる程度の成熟はしています(枯れたとまでは言いませんが)。

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリ認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げますさらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベース認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなもの設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分プラットフォーム自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的スクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークン予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまます。筆者は、fortune 500 クラス大企業による OAuth ベースサービス一種の単調増加 ID (おそらくデータベースフィールド?) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在トークン ID を見て、その後の ID を予測すれば、続く任意ユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラス攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意OAuth ベースサービスが外部レビューセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通実装における」OAuth がよくやる使い方ではサーバ信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベース実装乱数必要性クライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイトリクエストフォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ CSRF トークン指定するようにと、オプショナルな state パラメータ定義していますしかしながら、OAuth ベースサービス一般的state の長さや文字種を制限し、要求どおりそのままでさないことがあるようです。そこで、おかし互換性問題が起こるため、多くの OAuth ベースサービス利用者リダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されていますstate パラメータの別の懸念は、EVS 側で stateアクセスのある人はだれでも、リクエスト改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分アプリサービス登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的危険の伴うアイディア姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効パラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険ものstate パラメータに詰めこもうとし始めたり、浅薄システムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザ不適切なページに誘導する危険性が出てきます。これは「10.15. オープンリダイレクト」に分類されます

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザ大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通実装における」OAuth の低品質設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベース利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります

章のまとめ

セキュリティに関して言えば、「普通実装における」OAuth仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースサービスの中には、種々の攻撃に対して無防備でいることを利用者公然要求するものがありますサービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要セキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質プログラミング習慣を招いていますOAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティ提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所OAuth に使っているのを見たまま開発者コピーした結果というものもあります

OAuth ベースサービス開発者もその利用者側の開発者も、OAuth ベースプラットフォーム実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラス攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装仕様書セキュリティガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます

ユーザビリティ関連

(略: ふつう実装では、サービス側がプラグを引き抜くようにして自由利用者出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービスからは API 利用者という大きすぎる単位しか見えないので、たとえばビデオカメラアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位対策としてユーザ開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつう実装SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリcURL 的なもので API を叩こうとしても、JavaScript必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新メタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバlocalhostで立てるとかアホか。)

(略: オープンソースしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2016-01-27

今のGoogleスパム対応チームの

ジョンミュラーはマット・カッツより情報の出し方が現実的な気がする。マット・カッツはひたすらグーグル理念言葉にして代弁する事だけをしていた印象だけど、結果ネットはそうならなかった事をミュラーはよく知っていて、コメントを落としているので好感が持てる。

マット・カッツであればリンクを貼ることは一つも利益にならない、ユーザビリティを落とす、Googleの考える良いコンテンツではない可能性である、みたいな発言だけを繰り返していたが、ミュラーは「いや現時点でリンクなっちゃうのはしょうがないっしょ」て気軽に言っちゃう感じとか。

2016-01-02

ブログ広告を載せるのが嫌いなので「Adblock」は滅びてほしい

私は広告を載せるのが嫌いだ。だから一切のマネタイズをせずにブログ運営している。

ところが、当ブログが「嫌儲」「広告ウザい」と声高に叫んでいる人から評価を得ているかと言えば、決してそのようなことはない。

なぜならば、広告が嫌いな人はすでに「Adblock」を導入しており、広告非表示にしているからだ。ゆえにバナー広告を貼りまくっているブログであっても、私のように一切の広告を貼っていないブログであっても、彼らには「同じようにみえしまう」。すなわち"差異"が見えない、"アドバンテージ"が得られない、"違い"が分からない。これでは「ブログマネタイズしないメリット」というのは何一つ無くなってしまう。マネタイズしているブログ嫌悪している人たちは、Adblockを入れているので、広告を貼っていないブログを見つけることができない。

はて、パラドックスではないのか。Adblockが、広告を表示させているブログとそうでないブログとの"差異"を奪ってしまった。Adblockが「広告を貼らないメリット」を消してしまっている。広告を貼らないメリットがまったくない以上、それはもちろんグーグルアドセンスブログに3個貼り付けてマネタイズした方がお得である

最近では「Adblockを入れている人に対して、記事を見せなくする」"Adblockブロック"という手法流行っているようだが、是非ともマネタイズブログにはこの"Adblockブロック"を導入してほしい。そうすれば再び、"差異"が生まれる。なぜ私がそこまで差異にこだわるかって? 当然ですぞ。「すべての価値は"差異"によって生まれる」のだから。すべてのブログから広告を消すだなんてトンデモナイ! そんな恐ろしいことをすれば、元からユーザビリティを考えて広告を貼っていない私でも「なーんだ。どうせAdblockで消されるならみんな同じじゃないか。そんなら私も記事中に【スポンサーリンク】を入れて小銭稼いじゃお♪」と誘惑されてしまう。いやまぁ、収益報告しているブロガーさんに嫉妬しているだけなんだけどね。ルサンチマンルサンチマン自分の浅はかな思慮を恥じ入るばかり。

なーんてことを考えながらブログ運営しているとつらいよね。頭を真っ白にして、モッチモッチ、のびーん!と生きていこう。

2015-12-29

ユーザビリティーってさ

ユーザビリティーって、そのプロダクトを何ヶ月〜何年使ってみて初めて分かることだから最初から設計なんてできないんじゃないの?

2015-12-19

増田の文中キーワード自動リンク

金にならないからてをつけないんだろうけど、SEOとか最悪だしユーザビリティも最悪だからやめてくれないかな。。。。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん