「メッセージング」を含む日記 RSS

はてなキーワード: メッセージングとは

2020-07-02

簡単ドロップアウトできて驚いている

会社に行かなくなって、そろそろ二週間近くなる。この二週間、本当に何もせず、布団のなかにいる。

働いている間は、一分一秒とまではいかないけれど、つい動画を見てしまったりして三十分ほど経過していると「ああ、まずい。とても時間無駄にしてしまった」という感覚があった。いまは、丸一日寝ていても何も感じなくなっている。一時間という時間に対する価値がこうも変わるのか、と驚いている。

気持ちの変化は突然だった。納期が迫った案件があるなかで、風邪を引いて二日ほど休んだ。体調不良考慮して、納期を少し後ろにずらすようチームメンバーが頑張ってくれた。(ありがたい。)

復帰後、さあ遅れを取り戻してやろう、と思ってデスクに就いたが、アプリケーションを起動することが出来なかった。いま思い出しても不思議説明しづらい。アプリケーションを起動させようとすると思考が停止し、そのまま画面を見つめて気づいたら十分、二十分と経過している、ということが起きた。ハッとして、ちょっとお茶をいれてからやろうと思い席を立ち、戻ってまた同じことを繰り返す…という日が一日続いた。スポーツにはイップスと呼ばれる症状があるが、あれと同じような事象だろうか。そのうち、マウスを握ることやタイピングすらできなくなり、焦りが全身から滲み出てくるのを感じていた。

当然進捗は何もなく、進捗を報告することもできず、帰宅し、そしてすべての連絡を絶った。

会社からの連絡だけでなく、友人や恋人からの連絡も含めて、すべてのメールメッセージングサービス無視した。もっといえばスマートフォンの電源はもう何日も切ったままだ。

「このままではまずい」という気持ちがありながらも、社会と何ら接続のない状態は心地よく感じられた。このまま誰にも何も気にされない存在になりたい…と思った。もしかして自分は既にこの世にいない存在で、霊魂のような状態人間社会を眺めているのかもしれない…という感覚にも陥った。

しか貯金があるわけでもなく、働かなければこの生活だってひと月と続かない。自分人生がここから華々しいものになるとは思えないし、正直いつ死んでしまってもいい。逆縁は避けたいので、両親が生きているうちは生きていたい…という程度の消極的生存願望がある。

とりあえず出来事感情を書き出すことが、平時生活を取り戻すことに繋がるのではないかと思って、増田を書いてみた。

こんなことをして今から会社に戻れるのかも分からない。メールメッセージングサービスはまだ開いていない。開けるのかも分からない。いまはただ、パソコンキーを叩く感覚を得ることで、自分がまだこの世に存在していることを確かめている。

2020-02-11

anond:20200211115757

諸行無常なので、GAFAそのままかはわからない。

でもGAFAのような企業体じゃないかと思う理由として、

1.これら企業研究開発費は併せたら国家より大きい(たしか。気になったら調べて)

2.インターネット的なもの本質的にボーダレスで、国単位統治と馴染まない(たとえは悪いが、ウィルス国境を越えるように)

日本は、殆どするところが無いと思うよ。企業政府も。

世界的潮流(GAFA的な)を落とし込んでいく。

から日本IT界隈の人の自意識として、

1.自分未来を作っている、というほど作っていない自覚があって、

2.でも、自分らの知っているGAFA的な潮流が抗いようもなく入ってくる、とよく理解している。

と思う。

日本の非ITの人に対するメッセージングとして、「どう足掻いたってそうなっちうから」てのが本音では。

てか俺はそう。

2019-09-09

LINEを使いたくない

私はもともと韓国についてはなにも思っていなかったが、最近の動きから韓国という国が本当に嫌いになってしまった。

そこで気になるのがLINEだ。

というのも私はエンジニアの端くれで知り合いにLINEエンジニアがいる。

その彼が「LINEはよくLINE日本会社だ、と言っているがそうとは言い切れない」と言うのだ。

アナウンスメール日韓併記でくるし、重要判断には必ず韓国側の意向が含まれる。もちろん韓国人のエンジニアも沢山いる」と彼は言った。

これを聞いてLINEを使いたくないと思った。

しかし、メッセージングアプリ自分一人だけで乗り換えることができない。代替アプリはいくつかあるのにLINEを使わざるを得ない。

本当に恐ろしくなった。日本人のコミュニケーションは完全に韓国に握られてしまっている。

LINEを使いたくない。みんなWhatsAppかに移ってくれればいいのに

2019-07-01

株式会社ドワンゴ新卒採用落ちました(非エンジニア編)

https://anond.hatelabo.jp/20190701083530

企画職」枠の一次面接で少し気になったこ

・「最近注目してるサービスは?」という質問で「web業界セキュリティプライバシー蔑ろにしてきた揺り戻しとして業界全体がピリピリしてることもあり、メッセージングアプリSignalに注目している」と答えたら「僕はSignalやTelegramとかについてはテロリストが使ってるイメージしかないっすねぇww」みたいなコメントが返ってきた。「この流れで出てくるコメントがそれ?」とは思った。

・「ドワンゴ(特に企画側)に対しての不信感を持っている」と伝えたら「そういう人も社内にいるか安心していいっすよw」と返ってきた。自分意図としては、批判と「問題を抱えているあなた達が今後改善されるのか」という疑問を投げかけたつもりだったのだが会話が噛み合わなかった。

全体的な感想

別にハラスメント的なことがあったわけではないが、流石ドワンゴ企画職だなという印象だった。

受験料3000円取るくらいなのだからと心構えしていたが、面接含め一般的無難新卒採用だった。

エンジニア職」枠では二次面接までお世話になった。そちらでは会話が噛み合わないなんてことはなく、概ね普通に真摯対応して下さった。

終わった後に気付いたのだが、両枠共に「利用しているniconicoサービスはあるか」という質問はされたのだが「niconicoサービス投稿者側に立つことがあるか」という質問をされなかったのは改めて考えてみるとおかしな話だと思った。

こちらの現場からは以上です。

追伸:ついでに私見を述べると、エンジニアチームは個人裁量が大きいだけでなく個人SNSでの発信に対する検閲をしていないこともあり悪目立ちしてるだけであって、特別残念なチームではないように思う。ドワンゴ企画ディレクター職と経営側に深刻な問題を抱えている印象がある。

そうした中で元増田のように「自分niconico衰退要因の1人だ」と素直に認め、去っていく姿勢普通に偉いなぁと小学生並の感想になるが思った。

2018-12-10

WeChatかいうダークウェブなんとかした方が良い

中国ではWeChatが人気だ。

WeChatLINEのようなメッセージングアプリだがそれだけではない。

特に情報発信機能が広く使われている。

着目したいのは、プライベート日記機能だけではく、パブリック情報伝達の手段として広く使われていることだ。

例えば先日のドルガバ騒動も、WeChatで爆発的に広まり炎上した。

でも中国事情に詳しい日本人Twitter話題にするまで我々はその事を知らなかった。

それはなぜか?WeChatを持ってないとそれらを閲覧できないからだ。

そう、WeChat一種のダークウェブだ。中国はダークウェブ情報発信の主要な手段になっている国なのだ

それら情報にはURLなんて無いかWeChat外にその情報を気軽にシェアすることは出来ない。

しかWeChatなんて中国人くらいしか使ってないんだから、そこはもう中国パラダイス

言い換えれば中国政府プロパガンダ増幅器のようなものだ。

金盾なんて使わなくても中国人は勝手に外部から遮断されてくれる。

中国政府にとってこれほど楽なことはない。

そしてそれは実は中国人の利益になっている。

なぜなら政府外国人の主張かき乱される事なく国内生産性を最大化できるからだ。

政府中国世界最強の国にしようと動いてる。

国民もそれを承知だ。国が増幅したいプロパガンダは国の将来のためになると刷り込まれている。

WeChatをなんとかした方が良いというのはあくまで我々外国人から視点だ。

彼らのコミュニケーションを表の世界に出し、翻訳ソフトを使ってでも相互コミュニケーションを図らないと、彼らはダークウェブ危険思想を増幅するだろう。

2018-11-26

anond:20181126090305

これからは遊びの約束仕事の連絡も、基本テキストメッセージングで音声通話のほうが良いときだけ通話するという使い方になっていくでしょ。

今まではテキストによるメッセージングという方法がなかったから何でもかんでも通話してただけで。

2018-10-11

昨日ガッキードラマ見たんだけど

メッセージングアプリとか、ドラマ内のオリジナルアプリ作ってるのはなんでなんだろう。

わざわざださいUIアプリにしなくてもLINE使えばいいじゃんって思うんだけど。

現実世界にあるアプリとかを出してはいけないみたいなルールがあるんだろうか。

一方で、パワーポイントはそのままパワーポイントだった気がするのだが、パワポLINEの差はなんなのか。

さらにどうでもいいが、提供の一番最初Tik Tokが出てたのが時代を感じた。

2018-03-24

Tinderの違った楽しみ方

もし英語が出来るなら、Tinderの違った楽しみ方がある。

Tinder世界No.1マッチングアプリだ。

自分の近辺に居る異性(もしくは同性)の顔写真スワイプしてマッチングし、その後チャット(メッセージング)が出来るというもの

スワイプ回数が制限される無料プランと、無制限スワイプの有料プランがあるのだが、有料プランオプション面白い

そのオプションの一つが、自分場所世界のどこにでも変更する事ができるのだ。

まりは、顔写真のある世界中の女性簡単チャットできるのだ。(当方男です。)

実際にリトアニアタイ女性マッチして、英語チャットしながら一人ニヤニヤしている。

純粋に異性とのチャット楽しいし、英語勉強にもなるし、文化全然違うのが面白いし、性格が分かるとお互い普通人間なのだと感動するし、会えない事が前提というなんだか切ない感じもいい。

別に無理して日本人に会わなくてもいいのだ。

こんな面白い事が、究極に手軽に出来てしま時代Tinder感謝している。

2018-03-09

anond:20180309231235

ズルい話だけど、メッセージング系は相手にじっくり考える時間を与えるから落とすと思うなら絶対に対面が有利

LINEの時点で戦略的ミスを犯してる

2018-02-28

大学サークル内のIT

大学に入った流れでサークルに入った。

そのサークル自体にはとても満足し楽しんでいるのだが、一つだけつい口を出したくなってしまう点があったので書く。

凄く雑に言うと、ITである

活動内容はメッセージング資料管理重要になってくるもの。つまりIT重要事項となる。

一方で当サークル情報系でも何でもない。(自分の専攻もそう)

結果、使われている手法は先人たちの努力によって結構キメラ的な進化を遂げている。

現在使われているサービスは3つ。

LINEと、メーリングリストと、ビジネスチャットツール(あまりメジャーでない)。

おそらくメーリングリスト最初に使われ始め、時代の流れでLINEが取り入れられ、ネット経由のファイルの共有という案が挙がり、LINEの保存期間の問題を克服するため、ある程度保存容量のあるチャットツールが選ばれたのだろう。

重要な連絡はメール、軽いやり取りと画像の長期共有はLINE(のアルバム)、ファイル共有はチャットで。

疑問が浮かぶファイルを共有したいならクラウドストレージではないか

が、改めて考えると、クラウドストレージでのファイル共有というのは、多くの人にとって結構難しい概念なのかもしれない。

まずネットの向こうにストレージがあるという感覚が分かりづらい。

そもそもストレージって何?USBメモリみたいなやつ?USBメモリネットの向こうに?どういうこと?漏れたりしない?大丈夫おっぱい揉む?

ここまでの説明が何とかなったとしても、

アカウントを作って、招待を送り承認してもらって、アップロード方法確認する、とやることはまだまだある。

問題は、これら全てがたいていの人にとって初めての概念であるということだと思う。

LINEっぽいおしゃべりツールに入会し、LINEグループ的なものに入り、LINEに近いやりとりでファイルを共有するほうが余程受け入れ易く、楽だ。

ファイル共有以外の点についても同じようなことが言える。

LINEのやりとりは一覧性が無くて気に入らない。

LINEアルバムは画質イマイチで気に入らない。

今のメーリングリスト下品広告が気に入らない。

今のチャットツールスマホアプリが低クオリティで、エクスポート機能も皆無で気に入らない。

今のやり方だと数年後はすごくごちゃごちゃして見づらくなるであろうことが気に入らない。

もっとかっちょいいナウいツール自分が知っているだけでもたくさんある。

でも、自分一人が気に入らない程度で取り換えることに意味は無い。

実際LINEは素晴らしい仕事をしているし、先輩が発見したツールは皆きちんと使いこなしているし、なんだかんだで平均すればとても恵まれている方なのだろう。

所詮パソコンの大先生しかない自分が出る幕は無いし、これから社会人になっても似たような感じで出る幕はないんだろうなと感じた。

おわり

2018-02-24

Googleが普及に注力 新しいメッセージング規格「RCS」って何?

って記事LINE憎しはやく潰れろ的なコメントを見かけるけど、嫌韓厨だよね。

まあでもどっちでもいいけど支持する動機としては不純だよね。

LINEが潰れたらそれでいいだけだから

2017-11-23

もっと撤去していいよ

俺はアラサー男だけども、男性向け成人誌だけじゃなくもっとやればいいと思う。どの事業者も。

世の中の表側からアダルト(性的かつ下品淫蕩的なもの)はぜんぶ撤去するべき。ティーン誌とか青年コミックも含めてね。厳しすぎるくらいでいい。

対象商業誌だけじゃない。

コミケなんかのイベントでもエロ同人での参加は禁止して、エロ通販DL販売に完全移行したらいいと思う。

同好の士との触れ合いの場がほしいならまず外で話せるレベルの、健全ものも作ってから話してくれ。エロしかコミュニケーションが取れない人間ネットから出てくるべきじゃない。

店舗を持つ同人ショップからエロ同人アイテム撤去公共の場には存在しちゃダメだ。

はいえ、厳重にゾーニングされ、入店時にピピっと成人認証されるアダルト専門ショップ、といった感じなら商業同人わず店舗もあっていい。あと現状のように歓楽街隔離された形の風俗店問題ない。

要するに、現実世界では非エロエロが混在する空間があってはならない。健全ものを求める人間(未成年含む)がアダルト方面に迷い込むのが問題

ただし、ネット上ならそういった類の迷い込みがあってもいい。もちろんフィルタリングなどの必要性否定するわけではないが。

根本的にネットというのは、ほとんど精神世界だ。精神に歯止めは掛けられない。だから強い意志があれば未成年でもフィルタリングを抜け出せるくらいで構わない。

そういう空間と、現実空間との区別は厳格であるべきだし、その分別を誰もがつけられる国民性志向するべきだと思う。

昨今は、ネットリアル混同しすぎているのだ。

 

誤解されそうだが、成人向けコンテンツ流通を縮小させる意図はない。むしろ、厳格に分ける一方で萎縮が起きないように気を配るべきだ。

アダルトを含めたあらゆる表現を手厚く守って、エロアイテム流通は倍増させるくらいの勢いでいいとすら思う。

ただしその流通は、パブリックとは隔離された場所で、プライベート空間に直送される感じでやってください、という、一言で言えばそれだけの話だ。

中国じゃないんだから、アレなモノからソレなモノまで、公共空間にごっちゃ混ぜで陳列する必要はもう無い。

日本はもうカオスでいられる時期を過ぎた。もっと洗練されたスマート社会のありようを本気で考えて、変えていかなくちゃならない。

平たく言うとみんなネット通販活用しろって事だ。ついでにドローンとか無人トラックの認可を急げってね。

既存流通からの変化を促すと、それについていけない人への配慮を~という批判が来る。

だが思うに、ネットも使えないような、コンピュータ音痴の年配というのは、大概知ろうとしない、学ぼうとしない。

必要に迫られてもできるだけ避け続ける。たとえば高性能なスマホを息子に見繕ってもらい、教えてもらっても、

難癖をつけるばかりで最低限の通話メッセージング以上のことを断固としてしようとしない。興味を持とうとしない。

使っているモノの事をなにも知らないまま使い続けるような、恐ろしい感覚を持っている。

コンビニエロ本を買っていた人間のうちで、撤去されたから焦って他の入手手段を調べ出せる能力のある人はまだマシだ。

そうでない人はきっと先に述べたような気質の人だ。入手を諦めてまた別のもの(風俗とか)に流れるのかもしれないが、

いずれにしても、自ら賢くなろうとしない人間が取り残されることまで配慮していては、人間ダメにし、社会ダメにする。

何か事情があって取り残されてしまう人の保護ならともかく、健常な人間は生きている限り常に賢くあろうとし、学び続ける姿勢がなければならない。

さもないと、資本主義自由主義経済下の社会ではうまく生きていけないのが当然だし、なんならカモられハブられるの致し方ないことだ。

2017-09-22

支払い遅延はよくない、と感じた話とビジネスマナー

フリーランス個人事業主、いや会社経営をしていても、「支払い遅延」には遭遇してしまものなのか。会社より、フリーランス個人事業主のほうが支払い遅延をやられてしまいがち、とおもうのは私が視野狭窄に陥ってるからなのか....。

最近、支払い遅延があって、もやもやもやもやしている。「〇〇を盛り上げる副業フリーランサーの集まり自称クリエイティブ集団イェーイ!」みたいな組織のヘッドAさん。業務委託契約を結んでいて、継続的報酬が支払われる関係にある。

最初は「こっちが請求書送り忘れてるのかな?」と思ったけど、そうでもない。メッセージングアプリの添付機能でも送付していることが確認できた。

相手に悪気はないだろう、と思いメッセージングアプリで、でもすごく言葉を選びながら「30日入金予定ですが、きょう5日になっても確認できていないです。お手数ですが、一度ご確認いただけますか」というような、なるべく下手に出る感じに問い合わせてみた。カジュアルに「おっけ~」と返信がきた。だけど待つこと一週間、音沙汰なし。また問い合わせるのも、「カネカネカネ!!」って言ってるみたいで抵抗があった。

結果的に、その自称クリエイティブ集団の士業の人に「請求書の書き方の相談」というでっちあげの相談のテイでそれとなく伝えて、Aさんに支払ってもらえた。

Aさんから、入金したことについての連絡もなければ、入金が遅れたことについてのお詫びの言葉も一切なかったこちからは「入金確認しました、ありがとうございました」とは伝えた。

それから2週間、もやもやしっぱなしである

学生の頃にバイトしていた名古屋会社では、システムトラブルかなにかで取引先への支払いが3日遅れ、男性社員2人が菓子折りもって詫びに行くというシーンがあった。支払いが遅れるというのはそれくらいするものだと思っていたので、支払いが遅れたことに対する詫び皆無なのはびっくりした。それともあれはローカルルールなのか、名古屋って無借金経営企業が多いから、支払い遅延に対しても厳しいのかな。菓子折り云々は額が大きいからかもしれないが、それでなくとも詫びナシってどうなんだ、「ごめんね~~」でもいいんだよ。こっちに回収コストを負わせたっていうことを意識してほしいんだよ。

そんな具合にAさんへの不満が見えたら、相手およびその自称クリエイティブ集団への不信感がすごく募ってくる。そういえば集団のBさんは私との打ち合わせ3回中3回とも場所を間違えたり時間を間違えたりしたな....とか、Aさんとの打ち合わせの時もたいてい前の打ち合わせ長引いて30分はロスするんだよな、これってわたし時間ないがしろにしてるよな...とか。そのときは「いいよ、いいよ」で済ませていた不満とも思っていなかったことが、ふつふつと不満という形に変わり、集まって、大きな不満に姿を変える。

で、はたと自分を振り返ってみる。

自分はいまのところ支払い遅延をしたことはない。だけど、支払い遅延をやらかしたら、おんなじようなモヤモヤ相手に抱えさせるかもしれない。

私の場合の信頼毀損トリガーが「支払い遅延」と「謝らない」ことだったけど、そのトリガーは人によって、「しょっちゅう遅刻すること」だったり「メールの返信が遅い」ことだったりする。

私、メールの返信が最近ちょいちょい遅くなっている。もしかしたら誰かをモヤモヤさせたりしてるかもしれない。看過してもらえた小さなミスが、信頼毀損トリガーにより大きい不満になってるかもしれない。

このAさん支払い遅延は、自分の気が引き締まる出来事だった。

ビジネスマナーって、めちゃくちゃ大事だ。この件は、相手の考えるビジネスマナー自分の考えるビジネスマナーが違って、それで不快な思いをしたってことなんだけど、自分絶対的正しいビジネスマナーができているていう自信がないんだもの

だったら、ひとつひとつ丁寧に。この丁寧さ、最近欠けてる気がするな....。気がするっていうか、欠けてるな。意識しよう。

2017-09-20

anond:20170920120500

あとからLINEを思い出した。

メッセージングアプリだと海外だけどsnapchatとか。

これも海外だけどUberとかAirbnbみたいに社会インフラを直接的に担っているサービス

あるいはTwitchみたいなエンタメ系。

2017-03-02

LINE世界で負け続ける理由は、ニュースタブのことじゃねえよ、馬鹿

http://blogos.com/article/212112/

----------------------------

僕はLINEを愛してる。

愛してるがゆえにLINEをどんどん駄目にするLINE経営層が許せない。

はっきり言うが、彼らのやってることはグダグダだ。他社のチャットサービスが成長してる中、LINEが初めてユーザー数が減少したと言うがそれは当然だ。

説明しよう。

----------------------------

微妙にバズっているこの記事

多分に自己愛思い込みの強い著者が、アプリってのはこうグロースさせるもんなんだからそれをやれてないお前ら間違っている

一方的断じているもので、共感できるところは各タブに名前が入っていないことくらいのぶっちゃけ大して価値のない記事であった。

そもそもニュース領域twitterと違い、LINE株式会社側にLivedoor由来の編集チームがいてリソースが確保されている点、すでにLINENEWSという

基盤が存在している点で突然何の前触れもなくニュースを始めた日本twitterとはわけが違うだろう。

さら噴飯ものタイムラインについての評価で、まず誰も見ていないと断じているが、

リサーチベースではこんなものも出ている(http://gaiax-socialmedialab.jp/post-1891/

大体、広告事業としてのLINE ADS Platformは、このタイムラインベースにしたインフィードアドが中心であり、それで十分にマネタイズできている

ということは、タイムライン一定使われていて、広告インプ一定以上発生していることの証左だろう。

まり、この著者自体が、自分の見ている物事からしか評価判断のできない典型的な「マーケティング知らない人間なのだろう。

何をしてきた方かは存じ上げないが、いわゆるユーザーグロースのみをマーケティングであると思い込んでいるIT野郎

LINEニュースタブは、すでにユーザー一定以上グロースしている国内LINEユーザーに対してより多くの広告インプを発生させるためのレベニューグロース

としての側面が強いわけで、それも含めてマーケティングであるのだから、十分LINE現場も、経営陣もマーケティングを、経営理解していると言っていいだろう。

あ、後ユーザー数が減少と書いているけど、これはニュースタブを追加していない国についての話であって、そもそもの前提からしてもうめちゃくちゃ。調べずに書いてる感満載。


からこそ失望したのが、これなわけで。僕もLINEを愛しているけど、これはマジでないんじゃないか

http://jp.techcrunch.com/2017/03/02/line-clova/

----------------------------

スペインバルセロナで開催中のモバイルカンファレンスMobile World Congress(MWC) 2017」。そのキーノートにも登壇したLINE3月2日クラウドAIプラットフォーム「Clova(クローバ)」を発表した。

今後はClovaを搭載したアプリ「Clova App」を提供するほか、初の自社デバイスとなるスマートスピーカーWAVEウェーブ)」を今夏にも日本韓国で発売する予定だ。

今冬にはスマートディスプレイ「FACE(フェース)」の提供も控えるという。

----------------------------

要はAmazon Echoとか、Google Homeとか、スマートスピーカー領域(というか、音声会話をベースにしたインターフェース領域)に打って出るというわけだ。

これは一面ではすごく合理的に見える。つまりチャットサービスとしてユーザー間、ユーザー企業間でのコミュニケーションインフラ提供しているLINEが、textingから音声を介した

コミュニケーションインフラに舵を切るということ。事業の成長の向く先としてわかりやすい。

が。これ。マジで間違いなくうまくいかない。頓挫する。てかこれこそ、挑戦の美名に酔いしれてマーケティングを忘れた経営判断だろ、と思う。

何が問題か。答えは明白だ。 言語である

音声インターフェイスの要は、自然言語処理であり、発話された音声を正確に理解する技術にあるはずだ。

この点、AmazonGoogle基本的に「英語」という話者が圧倒的に多い言語に優先して開発を進めればよかった。現に英語自然言語処理はめちゃくちゃ進んでいる。

しかし、LINEは違う。英語圏ではまったく使われていないサービスなのだ。それどころか、LINEが浸透している主要国は日本台湾タイインドネシアの4カ国である

もうおわかりだろう。どの国も公用語がバラバなのだ

サービスを普及させるためには、地の利を生かすほかない。そういう意味英語圏は端から勝負しようがない。一方中華圏、圧倒的人口を誇るメインランドにはWeChatという

巨人存在し、市場に入ることすらできていない。

であるからして、浸透している主要4カ国で普及させる、という選択肢にせざるを得ないだろう。しかし、この4カ国ぶっちゃけ日本インドネシアしか1億を越える人口の国はない。

その上、GDPベースで考えてもスマートスピーカー短期的に人口膾炙するほど普及させられるマーケット日本と台湾しかない。

さらさらに、R&Dの視点からいって、4カ国それぞれの言語にあわせて自然言語処理一定水準まで高めるには、英語1つに絞って開発するのと比較して単純に4倍のコストと労力がかかる。

典型的な、労多くして実り少ない状況なわけだ。

どう考えても八方塞だ。

コミュニケーションプラットフォームである以上「言語」は避けて通れない問題。これを攻略する方法は正直、僕にはわからない。

からもはやLINEは、チャットサービスとして浸透している国の中で、その土台の上で、ニュースタブとかその他もろもろで、

きちんとレベニューグロースを続けるのであれば、ぜんぜん負け続けることなんてないのになーと僕は思います

事実世界でこんなに儲けているメッセージングアプリはないのだから、その時点で十分世界で勝ってんじゃん、と思うわけで。

経営陣には、熱病に浮かされることなく、着実に一つ一つできることを勝負して行っていただきたい、そう思う限りです。

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-08-09

golang半年近く使ってみて

後なんかweb系の企業golang採用多いので、ある程度詳しくなっておけば就職困らなそうという予防線

今のところが成功しなかったらeurekaとかmercariとか雇ってくれませんか!

どっちもユーザーです!(ペアーズでは3名ぐらい逢った、メルカリではバイクMacbook Air売ったなー。)

ポケモンGoとかやんねーし、地味に自分がよく使っているアプリサービスから成功パターンを得るのがいいのかなぁ

なんか、人との接点がうまくできているCtoCサービスがうまくいっているような感じが(CtoCなんだから当たり前か、何いってんだ)

人とコンバージョンしたいです。

2016-04-26

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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 Permalink | 記事への反応(3) | 12:44

2016-03-22

震災マーケティング利用について

最近よく見るYahoo! JAPANアプリCM

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

これ見る度に「Yahooアプリを使わせる為に災害に対する不安を利用してる」様に若干感じてしま

災害や天候情報だけを伝えるアプリだったらそうは思わないし、実際Yahooアプリ以前にそういうアプリ存在してるのに、まるでYahooアプリを入れないと災害情報が得られないかのように煽ってる様に感じる

Androidだったらアプリ入れなくてもGoogle Nowが教えてくれるし

まあiOS使ってるスマホに不慣れな人で、緊急速報以外も自動通知して欲しい、けど自分でそういうアプリ探す能力は無い、って人も実際いるだろうから特段文句つけるような話でもないんだけど

もっと鼻につくのはこのLINE記事

http://headlines.yahoo.co.jp/hl?a=20160312-00000006-asahi-bus_all

"誕生きっかけは大震災だった。ライン運営会社は、電話がつながりにくい中でも「大切な人と連絡を取れるサービス必要だ」と判断急ピッチで開発し、3カ月後にサービスを始めた。 "

・いやいや、WhatAppのタイムマシン経営でしょ

twitterインフラとして機能してたんだから、本当に震災時の事考えるならわざわざ利用者分散させる必要は無い

メッセージング機能を持ってるアプリWebサービスは大抵、2011年のあの空気に当てられて「震災時に使ってもらえたらいいね」って話はしてただろうから、そういう会話を盛ったのかな?

"こだわりは、相手メッセージを読んだか分かる「既読機能をつけたこと。相手に返信する余裕がなくても、既読と分かれば安心する。そんな思いを込めた。"

・さすがに無理がある。既読はつくのに返信来ない状況って不安しか生まないし、何も解決しない

震災ビジネスにするのは悪い事ではない。まともな防災グッズを売ったりするのはもちろん公益性が高い(適正価格なら)。

ただ、便乗商法は格好悪いし、それが人の不安心理に付け込んだものなら尚の事。

 
ログイン ユーザー登録
ようこそ ゲスト さん