  |
はてなキーワード: ストリームとは
その日に起こったことを順番に書く。
１. 開場1時間前である9時に入れる特典を提携ホテル宿泊でゲット、8:30に並んで結局入れたのは11:00時近く。すんごい列だった。最後尾までたどり着くのに30分くらい歩いたもん。入り口一つしかなかったし、ディズニーランドみたいな持ち物検査、セキュリティーチェックあったし。列が長くなるのはしょうがなかった。
2. 会場に入れても、アプリが落ちまくってゲームができない。会場でゲットしたポケモンはゼロ。レイド？なにそれ状態。ポケストップは2つくらいスピンできた。
3. インフォメーションセンターのテントに長蛇の列。ログインできない、繋がらない、もしくはイベント専用QRコードが読み込めないなどの苦情専用窓口となってた。（フードのテントはガラガラだったから、食に困ることはなかった）
4. ゲーム開発会社のCEO、メインステージに登場。ブーイングを受ける。このゲームなんとかしろ、みたいなチャントが。健気にハイテンションで進める司会の女性にペットボトルが飛んで行った。当たらなかったけど、これはいけない。
5. 入場して1時間くらいで諦めて会場を出た。近くのデリみたいなところでWifiをゲット、それでもアプリは落ちまくる。それでも会場にいる時よりはマシだった。
6. 午後2時くらい？、ホテルに戻って、Youtubeで会場のライブストリームを見ていた。運営元のスタッフが出てきて、チケット返金プラス100ドル分のポケコインを参加者全員に配るとアナウンス。観衆から喜びのイエーイみたいなどよめきが。全然嬉しくないわ。
7. ホテルの部屋になんとアンノーンが湧いた。ヘラクロスも。イベント会場でしかゲットできないレアポケモンが会場半径2マイルまで解放されたことを知る。
8. 午後4時以降、会場から離れたところであれば、なんとかプレイできるような状態にはなってた。街中を歩きまわっていくつかアンノーン、ヘラクロスゲット。
9. 19時、会場でイベント終了。ミステリーチャレンジはキャンセルされたみたい。ただそんなのはもうどうでもよくなってた。
10. 会場から半径2マイル内であれば、シカゴイベント終了後(終わってから48時間？どのくらい続いたのかは知らない）も会場と同等の特典（アンノーン、ヘラクロス、スペシャル２玉）が続いた。
11. 伝説ポケモンのレイド始まる。ジムにすごい人だかり。アプリのクラッシュに苦しみながらも、なんとかフリーザーゲット。イベント参加者は、100%の捕獲率。緑の輪っかで一発でゲット。
色々端折ったところ、書き損じてるところが多いと思うけど、こんな感じでした。
一言で言えば、災難。初めからフェンスで囲われた公園なんかでイベントやんないで、街全体でやればよかったのになぁと。
今までいろんな野外イベントやフェスに参加したけど、こんなことに遭遇したのは初めてでした。
これって、ホテル代くらいは請求できのかな？ いい勉強にはなったけど、授業料高すぎ。
優秀な(売上げが多い)営業マンに非常に多いのはニコポン営業と言われるタイプ。
「この2017年に⁉︎」という感じですが、そうなんです。
別にラジオに限らず営業職では、コミュ力が重要な要素ですが、ラジオの場合は最たるものだと思います。
というのもラジオ媒体は効果・効率を定量的に出すのが難しいメディアでして。
webはもちろん細かい費用対効果を測れますし、TVも毎日発表される視聴率でリーチなどはこまめに取れます。
対してラジオはと言うと、
首都圏ですら、
(radikoのストリーム数を諸々制約があり勝手に出せないのです)
私自身、「ラジオに広告効果がない」とは全く思いませんが、効果検証がしにくいメディアであることは確かです。
web広告がこれほど普及したなかクライアントとしても、効果を評価しづらいメディアはクライアント社内で承認を得るのも一苦労で、よっぽど刺さる企画じゃないと実施は難しいわけです。
それを何とか企画性やら新規性、話題性なんか組み込んだ提案に仕立てて売ってるのですが、相手も人である以上、最後に効くのはやっぱり人と人との関係性みたいで。
しょっちゅう会合やったり、ゴルフやったり、プライベートで趣味に付き合ったりで関係性作って、細かいフォローで最終的には「困ってるので助けてください」で決めてくるまでに仕上げるんですよね。
ちなみに会合なんかは高級店とかじゃなく、わりと普通のお店ですね。お金ないんで。
その代わり優秀営業は気遣いはすごいです。支払いやらタクシー手配やらはもちろん客が気づきもしない手際ですし、お土産なんかも、客1人1人の趣味、趣向、家族構成、出身地諸々を雑談から拾っといて全部頭に入れたチョイスしてきます。
とまあ、長々書いてますが、どれも基本的だったりよく言われることですね。
だけど、それを全て完璧にやれるかと言われると、少なくとも私にはできないです。
そしてニコポンが多いのもう1つの理由が社内環境にもあります。
基本的に放送局は編成サイドが営業サイドより力関係は強く、基本ディレクターがNOと言ったらNOです。
(それが「番組に合わない気がするから」という感覚論で、子どもの言い訳みたいでも)
編成が強いのは、公共の電波を預かるものとして「まず第1はリスナーの利益に」という点で正しいと思います。
しかし、民放として収益を上げるということを全く理解していない外部制作会社の雇われディレクターの感覚論でも全てがNOにされることもあるので営業としては堪ったもんじゃありません。
ディレクターはじめ社内各所と良い関係性を築き、私がデータや論拠を示しながらも拒否された企画を「ひとつよろしく頼むよ！」で通してくるんですよね。
要はできる営業マンは社内外問わずコミュニケーションが潤滑って当たり前のことなんですが、
これだけ「主観的な」環境にあるラジオだと際立っているというお話でした。
「Ubuntu」とは、「他者への思いやり」のことです。この単語自体が、人間としての精神を体現しています。
我々は、生産的で、幸福で、複雑な領域における新しい発想を歓迎できる柔軟性を持ち、また、あらゆるプロセスを常に改善し、さらに、各々が全く異なる要求や関心、能力を持つグループの間の協力を促進するコミュニティを希求します。
我々は、メンバーの多様性によってコミュニティを強靱なものにするために、多様な参加者を活発に探します。このUbuntu行動規範は、多様なグループがお互いの利益と喜びのために協調することを確実にするために存在しています。我々は、誰であっても、プロジェクトへの参加に障害がないよう努力します。
行動規範は一般的に、公的であれ私的であれ、我々がどのように振る舞うべきかを統率します。我々は、プロジェクトの代表者（公式・非公式を問わず）、関係者、そして直接の参加者が、このUbuntu行動規範を尊重することを望みます。
我々は、下記に真剣に努めなければなりません。
我々の成果物は他者によって使われるでしょうし、また逆に他者の成果物にも依存しています。いかなる決定であっても、利用者や関係者に影響を与えることを頭に置いて、決定をするときにはそのことを考慮する必要があります。
意見に相違があるからといって、無礼な振る舞いをとってはいけません。衝突を解決するために協働し、他者が善意で行動していると仮定し、親身になるよう努力しなければなりません。苛立ちが個人攻撃に発展することがあってはなりません。不快感を覚えたり脅威を感じるコミュニティは、生産的ではありません。
間違いを犯すことは誰にでもあります。そのときには、責任を取らなければなりません。もし誰かが傷つけられたり攻撃されたときには、注意深く、そして思いやりを持って意見を聞き、間違いを正すよう行動しなければなりません。
我々が作り上げようとしているものは複雑で、それぞれに想いが込められたたくさんのパーツでできています。各々が違ったゴールとビジョンを持つチームの間での協調は不可欠です。ただのパーツの組み合わせ以上の成果物を作り上げるには、各々のパーツが全体を理解するよう努力しなければなりません。
協調して取り組むことで、冗長な作業を減らし、品質の向上につなげることができます。プロジェクトの内外を問わず、協調することは大切です。可能な限り、アップストリームのプロジェクトと共同で作業し、フリーソフトウェアのコミュニティと協調することが必要です。透明性を確保し、その作業に関心を持つ人とはなるべく早期から協働するのが良いでしょう。
社会的な、あるいは技術的な意見の不一致はよくあることです。しかし、意見をまとめずそのままにしたり、何を合意したのかを不明確なままにして他の人を悩ませることがあってはなりません。
プロジェクトの参加者は、意見の不一致を建設的に解決することが期待されています。もしも合意に至らなければ、あらかじめ決められたリーダーに仲裁を依頼し、透明性 (clarity) と指示を求めます。
誰であっても、完璧であることを求められてはいません。誰かに質問することは、後で発生するであろう問題を回避できるので推奨されます。ただし、適切な場所で質問してください。質問を受けた人はすぐに反応し、手助けしてあげてください。
プロジェクトを離れるときには、与える混乱を最小限にするよう動くことが求められます。プロジェクトから離れることを他の人たちに伝えて、離れる人が作業を中断した地点からほかの人たちが再開できるようにしてください。
我々は、実例と議論と行動によって動かされます。新しく参加した人は、もしプロジェクトの改善につながる新しい考えがあれば、ぜひ人々を率いて、行動を起こしてください。リーダーシップは、行動を起こすことだけで誰でも実践できます。その機会があれば、誰かの許可を待つ必要はありません。
プロジェクトに関する責任は「慈悲深い独裁者」を頂点として、そこから特定の範囲について責任と権限を委任されたコミュニティ・カウンシル、その下にいるチームや委員会 (councils) 、個人に委任されていきます。コミュニティ・カウンシルまたはその代表者が、争いごとの解決を行います。
我々は実力主義に基づいて、意思決定や統率、リーダーシップを、長く参加している人から、能力があって関心の高い候補者に委任していきます。
評議会 (boards) や委員会 (councils) への任命は、コミュニティ・カウンシルが決定権を持ちます。ただし、事前にコミュニティに対してインプットを求めるものとします。
リーダーシップは、表彰や権利や肩書きではありません。リーダーシップは権限であり、そこには責任が生まれます。リーダーシップはコミュニティから委任されたものです。リーダーの権限は、委任するコミュニティから支持されている間だけ得られるものです。
我々は何かものごとを決める前に、意見やデータ、関係者からの意見表明を集めます。リーダーの役割として、チームが決定を遅滞なく行う手伝いをし、ガイダンスを与え、合意に至らなかったときに決定をし、決定の実施に責任を持つことが期待されています。
何かを決めないことには、先に進めません。明確な指示には価値があります。ときには、データが足りなかったり、合意が得られがたいこともあるでしょう。それでも、何らかの決定を下さなければなりません。いつでも完璧な決定を下せる保証などないのです。決定を先延ばしにするより、失敗して、失敗に学び、将来の役に立てることが大切です。
我々は、問題をより把握しているチームを信頼して決定を下してもらうことで、プロジェクトはよりよいものになると認識しています。もし決定に不満があれば、それを下したチームと調整します。調整が付かなければ、その決定についてレビューする統治機構 (governance structure) があります。つまるところ、責任を持つ人が決定を下し、それがプロジェクトの統治 (project governance) に支持されていれば、その決定は有効であるとします。我々はある決定について納得しないこともあるかもしれませんが、それでもプロジェクトを信用し、たとえ内心では違うほうがよいと思っていたとしても、プロジェクトとしてその決定が実施されることを支援します。
誰であっても、どの組織に所属していようとも、どのようにプロジェクトに関わろうとも、我々は参加を歓迎します。コミュニティは開かれたものであり、能力や適性を持っていることを示せれば、職責を負うことができます。
「名演奏家はその演奏によって評価され、リーダーはチームの行動で評価される」リーダーは、行動すべき・身を引くべきときを知っています。チームは、リーダーに権限を渡したりそれを取り戻すべきときを知っています。
良きリーダーはスポットライトを浴びようとせず、他のメンバーの活躍をたたえます。リーダーはチームメンバーの中で目立つ存在でしょうが、良きリーダーはその注目を他のメンバーの優れた活動に対してスポットを当てるために使います。
リーダーはときに、理解されず、合意に基づかず、一般的ではない冒険的な決断を下す必要があります。我々は、完全な合意を得るよりも物事を進めることを優先し、勇敢にもそのような決定を下すことを評価します。とはいえ、冒険的な決断には十分な検討が必要です。ある人にとっては頭の痛いことになるかもしれないことを肝に銘じ、影響を抑えるようにしなければなりません。変更について、その理由を明確にして、そして早めにコミュニケーションをとることは、その変更を実施するのと同じくらい重要です。
もしもリーダーが自身の雇用関係や他のプロジェクトとの関わりによって利益相反状態になっている場合には、それに気がつくことが期待されています。そして、私利私欲のためとみなされることのないよう、棄権したり決定を誰かにゆだねたりすることが期待されています。リーダーに限らず全てのプロジェクトメンバーにも、私利私欲のためではなく、ユーザーの暮らしをよりよくするために決定を下すことが期待されています。
もしも利益相反が疑われる場合には、誰かにセカンドオピニオンを求めてください。利益相反状態にあることを明らかにすることが、解決への道筋にとって重要です。リーダーは、たとえ一般的ではない、あるいは特定のグループに有利・不利となるように思われるものであっても、決定が信用できるものとなるよう行動すべきです。
このUbuntu行動規範は、網羅的でも、完全なものでもありません。ルールブックでもありません。協調的で共用の環境 (a collaborative, shared environment) とゴールに関する、我々にとっての共通の理解を引き出すためのものです。
このUbuntu行動規範は、クリエイティブ・コモンズ 表示 - 継承 3.0 非移植ライセンスのもと配布されます。あなた自身のプロジェクトにこれを再利用することができます。また、好きなように改変することもできますが、あなたの改変を他の人が利用することも許可し、Ubuntuプロジェクトの著作権表示を付けるようにしてください。
キュレーションの件でDeNAやCAが炎上してるけど、似たような話でトヨタ自動車も相当に酷いと前々から思っている。
一昔前、ホンダが「ストリーム」というミニバンを出してヒットさせたことがあったが、トヨタはそのストリームとなんと全長全幅全高が全く同じ「ウィッシュ」というミニバンを出してストリームを見事に潰してしまった。そして今年、今度はスズキの「ソリオ」というコンパクトカーのサイズ感やコンセプトをほぼ丸ごと真似て「ルーミー」「タンク」という車を出してきた。トヨタには圧倒的な販売力があるので、サクッと他社の後追い車種を出すだけであっさりとライバルを駆逐できてしまう。
資本力を背景にしたモラルのない商いのやり方って、まんま今回のDeNAやCAの話と同じなのではないかと思う。トヨタは世界最大級の自動車会社だし、ハイブリッドカーを世界で初めて実用化して普及させたことなど本当にすごいなと思うポイントも沢山ある。でも、だからこそ「他社の売れてる車種を訴えられない程度に真似して、国内で小銭稼ぎしちゃおう」というDeNAパレットのようなズルい商売のやり方はいい加減やめてほしいと思うのだ。世界を引っ張る自動車会社なのだから、誇りを持って車を作ってほしい。
カプコンカップ(CC)2016が12月3日(土)、12月4日(日)の２日間開催される。
1年間を通して、世界中を飛び回って大会ポイントを稼いできた選手たちのうち上位32人の集大成。
種目：ストリートファイターV
ストリーム配信：https://www.twitch.tv/capcomfighters
日本時間 12月3日（土）03:00～ | 32人から8人まで絞り込むトーナメント開始
INFILTRATION：[韓国 / ナッシュ] 累積ポイント1位。EVO2016優勝、他プレミア2大会優勝。シーズン初期から無類の強さ。も、シーズン後半から追い上げられ気味。
Humanbomb：[香港 / 春麗] アジアランキング大会で安定した成績を残す。
Luffy：[フランス / ミカ] 2つの欧州ランキング大会を制す。EVO2014優勝者。
マゴ：[日本 / かりん] アジア地区優勝。スト4オンラインポイント最多。スト5では強豪集まるアジア各大会での優勝が印象的。
MOV：[日本 / 春麗] アジア地区2位。ランキング大会優勝4つ。現時点の春麗では最強か。
Brolynho：[ブラジル / ネカリ] 南米ランキング大会で2度の優勝。
ウメハラ：[日本 / リュウ] ストリートファイター3rdの連続ブロッキング動画で世界的に有名。今シーズンは後半の伸びが目覚ましい。が、対ガイル戦に不安が残る。
K-Brad：[アメリカ / キャミィ] 南米地区決勝大会で準優勝。他大会でも安定した成績を残す。
NuckleDu：[アメリカ / ガイル] 若手の注目株。プレミア2つ優勝。さほど警戒されていなかったガイルへの対策研究が、この選手の存在の脅威により巷で促進される。
XsKSamurai：[アメリカ / リュウ] 印象として少ない北米のリュウ使い、の強豪。
Xian：[シンガポール / ファン] 初期はなかばネタ扱いだったファンというキャラを開拓した、現状最強のファン使い。
ChrisTatarian：[アメリカ / ケン] 若手ケン使い。2つのランキング大会で優勝。
Xiaohai：[中国 / キャミィ] ノッてる時は誰にも止められない最強キャミィ使い。2つのプレミア大会を制す。ESL優勝者。
ProblemX：[イギリス / アレックス] 欧州ランキング大会で上位成績残す。CC唯一のアレックス使い。
ももち：[日本 / ケン] EVO2015、CC2014優勝者。最強ケン。耐えるケン。プレミア優勝者。他プレミア大会でも上位成績残す。ESL準優勝。
MisterCrimson：[フランス / ララ] 欧州強豪。ランキング大会で上位成績。CC唯一のララ使い。
ときど：[日本 / リュウ] 現時点リュウでは最強との呼び声。北米地区決勝でNuckleDuのガイルに敗れ2位。プレミア大会で常に3位以上という驚異的成績。
DRRay：[ドミニカ / バルログ] 南米地区決勝で優勝。CC唯一のバルログ使い。
えいた：[日本 / ケン] ももち選手とはスタイルが対照的とも言われる、暴れ型のケン使い。法律事務所ほか3社からのスポンサードを受けCCに挑む。
GO1：[日本 / 春麗] 過去、ストリートファイターシリーズ以外の格闘ゲームで結果を残してきたプレイヤー。スト5でも今シーズン各大会で上位成績残す。
GamerBee：[台湾 / ネカリ] 現状最強ネカリか？シーズン後半から頭角を現し、プレミア大会を立て続けに制す。
RickiOrtiz：[アメリカ / 春麗] アメリカ強豪春麗。北米ランキング大会で安定した成績残す。
JulioFuentes：[アメリカ / ケン] 強豪ケン。北米ランキング2つ優勝。
ゆかどん：[日本 / ナッシュ] EVO3位の強豪ナッシュ。アジアランキング大会でも上位成績。
JustinWong：[アメリカ / かりん] ウメハラ背水の逆転劇の相手だった選手。スト５でプレミア優勝はないものの、7つのランキング大会で優勝している実力派。
sako：[日本 / 春麗] シーズン後半からついに覚醒か。EVO2016でINFILTRATIONに完敗も、後の大会で見事に雪辱を果たす。コンボの鬼。
ハイタニ：[日本 / ネカリ] アジア地区決勝3位。プレミア優勝逃すも常に上位成績。
FilipinoChamp：[アメリカ / ダルシム] 唯一ダルシム。2つのランキングで優勝。北米南米で上位成績残す。
ふ～ど：[日本 / ミカ] 最強ミカ使い。不利な状況でも、一瞬のチャンスを与えられれば一気に戦況をひっくり返す実力を持つ。EVO2016準優勝。
RyanHart：[イギリス / ケン] ストリートファイター関連ギネス記録を複数持つ。スト５ではシーズン大会優勝は逃すも安定成績。
Phenom：[ノルウェー / ネカリ] シーズン初期にプレミア優勝。欧州決勝準優勝。プレミア大会のカナダカップでも3位、と上位で安定した結果を残す。
かずのこ：[日本 / キャミィ] CC2015優勝者。今シーズンはアジアランキング大会で上位成績残す。
以上32名で鎬を削る。
※
種目：2016年からストリートファイター５。前年はストリートファイター４。新作に伴い種目が変更になっている。
大会：年間70大会以上。世界各地で開催された。ランキング大会とプレミア大会がある。順位に従ってポイントが加算される。
ポイント：グローバルポイントとリージョナルポイントがある。累積ポイントがカプコンカップ(CC)と地区決勝大会への出場権に直結。
EVO：シーズン半ばにある中間決算的な大会。長い歴史が有る。巨大オープントーナメントで、数日を掛けて戦う。EVO2016のスト５部門では5000人が参加。
プレミア：特別に指定された一部の大会では、優勝すると累積ポイントに関係なくカプコンカップへの出場権を直接獲得できる。優勝は通常のランキング大会より厳しい。
地区決勝大会：各プレミア大会の一つ。地区決勝大会への出場にはリージョナルポイントが必要。
もう誰が優勝してもおかしくない状況。
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ダブルラチェット・アルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。
受信ラチェットはメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化やメッセージ認証に使う対称鍵の生成に用いられる。
送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。
ここで注目すべきは、メッセージを送信するために送信者が待つ必要は一切ないということだ。いつでも送信の第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイス上のものであっても、過去に送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)
登録は、クライアントに言って、連絡用の電話番号をサーバに教えてもらうことから始まる。また同時に、トークンを通話とSMSどちらで受け取りたいかの希望も登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報を登録できるようにしてくれる。
クライアントはメッセージ認証と暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。
また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。
他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。
クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントがSMSを受け取りたいかデータだけにしたいかの情報も含まれる。
TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリントを比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。
送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報をルート鍵と呼ぶ。
このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化とMACの鍵を生成するのに使われる。
最後にAESカウンターが初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターはメッセージ送信ごとに増える一方で、pctrカウンターは、最後の既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。
これらを使って相手にメッセージを暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイクを完了できるだけの必要情報が含められている。
SignalサーバはGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージの送信元を知らずにいることが保障される。
受信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイクを完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。
相手が返信する前に、もとの送信者から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。
受信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵と自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化と認証の鍵を得る。これを使ってメッセージを暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。
TextSecureは、サーバとクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロードを認証する。これは送信メッセージの認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージの送信も鍵アップもそのユーザになりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップはデバイスのSDカードに置かれていたので、他のアプリから読むことができたのだ。
この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティの問題ではなく、現実の問題であり、それに対する後ろ向きな対策なのである。
この攻撃は偽配送の一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃者から別の人(標的)へのメッセージとして送信される。
これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分の公開鍵を、標的の公開鍵に変えればいい。これは自分の電話番号を再登録すればできる。送信者はQRコードを使って、相手のフィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである。
それから、今度は送信者のアカウントを再登録して、その検証SMSか確認通話が送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージを送信できるようになる。
この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。
できることがあるとすれば、送信者と受信者の双方がメッセージの暗号化された本文内で言及されるようにすることなどだ。
TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵が安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破は限定的な時間範囲にしか有効でないとする。新しいラチェットのそれぞれに公開鍵が必要であることから、これは達成されている。
完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質と定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイス上にのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットのステートに対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェットを使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージの暴露である。
否認性(アリバイ)はさらにあやふやだ。ある特定のメッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバは認証とメッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。
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/
第一に、それは、ストリーム（FRPの値の定義）の問題であって、ユニットテストすれば良い。もしくは単にFRPのログを取れば良い。
グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリも特にそうだけど、基本的にミュータブルな値同士が関数でリアクティブに連携されて常に整合性を保っているのだから、グローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという（テスト自体困難な）問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。
使用する関数の問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数の問題と一緒というのはまったく違う。
いや、それがそもそもの発端であるとブログの経緯には書かれている。説明されている方式でGUIアプリまで書けるのか？と疑念が呈されたことがきっかけ。
この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？
原理的に可能かという議論ではなく、実用的な範疇か？という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRPと状態渡しは同じ複雑さだという主張も崩されている。そこが重要。
段階を踏んだ上で、非FRPのHaskellのIOモナドのコードを誰かが書いたらいんじゃない？当面、最初はOCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたから制限されたんでしょ。実際には、OCamlの関数型では冗長でしか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。
関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、
定数って、プログラム中で更新不可能で、いつ読みだしても同じ値が出てくるから、グローバルでも問題無いんだよ。
ストリームは定数だ、って言ってみたところで、プログラム全体から更新可能なんじゃ、グローバル変数と同じでしょ？
バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ？
なんで伝わらないんだろ。
複数人でプログラム開発したり、他人のプログラムをデバッグしたり、したこと無いんだろうか。
「純粋関数型」とは何か、という話と、とOCamlでそれが推奨スタイルか、って別の話だよね？
岡部氏との争いって「OCamlでGUIアプリを純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね？
純粋関数型とは何かといった時にHaskellのように、IOも含めて引数と戻り値で表現する、関数のふるまいが関数の外の状態に依存しない、関数に副作用が伴わないとかの性質をいうと思うんだけど、岡部氏はFRPで状態を関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね？
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？
Haskellで書けて、OCamlで冗長になっても、書けるなら「書ける」、「可能」だよね？
その発言が事実か確かめる術はないし、ここで岡部氏攻撃しているのは君ひとりなのか？他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か？
俺の書き込みが他人といきなり結び付けられたから、電波だな、と思ったの。
否。ストリームに限らず、定数は引数で与えなくても純粋関数型である、という見解はごく普通。
つまり、GUIになればもはや関数型では書けない、というのが推奨スタイルだ、って言ってるようなもので、OCamlベースでいくら関数型の講義やっても、最終的にはその関数型でまともなGUIアプリすら書けない、という批判でしょ。その批判が岡部氏からされたら、あたかも関数型で書ける、という強弁から生まれたのが「状態渡し」理論。それが無理筋だ、ということが今回実証された。
その発言が事実か確かめる術はないし、ここで岡部氏攻撃しているのは君ひとりなのか？他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か？
あのね、グローバル変数の欠点とは、それが「変数」だからなの。
ストリームを関数の外部に持つFRPを純粋関数型っていうのは少数派でしょ。
ユーザからの入力をリアルタイムに処理するプログラムにはFRPは有効だよね。
「OCamlでは」じゃないの？
全部純粋関数型(引数と戻り値に収める、状態渡し)にするのを良しとするHaskellと違って、OCamlは副作用も部分的に使うのが普通で、IOモナドみたいな入出力までも純粋に書くための道具立てが揃ってない、それでちょっと冗長になる、ってことでしょ？
OCamlの元々の推奨スタイルならもっと短く書けるんでしょ？
俺はそう読んだけど。
それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ？
だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの。
いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。
関数型という枠組みを拡張しているのではなく、関数型という枠組みの中にミュータブルな時間要素が純粋に収まるようにしているのがFRPだろ。「関数型を拡張してるから」というのは、また独自拡張だ、という批判を許すし、FRPが関数型の拡張だというのは誤解を招くし、語弊もある。
いやそもそも岡部氏が複雑なアプリになるとFRPが必要だ、と批判すると状態渡しで充分だ、という反発があった。それが誤魔化しだとして、今に至るし、否定されているから一連のブログでの徹底的なまでの反撃がなされている。
事実、「駱駝」は「状態渡しはむしろ異常」って書いた上に、岡部氏のコードの倍の分量の複雑なコードしか示せなかった。あの無理して書いたのが第三者にもまるわかりの状態渡しの実装って間違ってるんじゃないの？
これまでのアンチ岡部のやり方を眺めていると、被害者の岡部氏の分析には一定の信ぴょう性が認められるよね？
しかも、それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ？という素朴な疑問がある。当事者だから否定してるんだろ、と誰が見てもおもうだろ。
ストリームだから定数とか、過去の値保存してるから定数とか言ってみたところで、プログラム内の色んな関数から読み書きされる可能性があって誰が書き換えたか中身読まないとわからないんじゃ、グローバル変数使ってるプログラムの欠点をそのまま持ってるじゃん
いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。
FRPライブラリのサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか？
拡張なら「関数型的じゃない」っていわれたら「関数型を拡張してるから」って答えればいいだけの話
「これが正しい関数型でお前らの状態渡しは間違ってる」みたいに言うから荒れる
間違っている電波だ
個人的に電波だと思うのはこういう匿名の書き込みを住井だ駱駝だ言い出すところ
ストリームだから定数とか、過去の値保存してるから定数とか言ってみたところで、プログラム内の色んな関数から読み書きされる可能性があって誰が書き換えたか中身読まないとわからないんじゃ、グローバル変数使ってるプログラムの欠点をそのまま持ってるじゃん
FRPライブラリのサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか？
https://www.npmjs.com/package/timeengine
IOモナドをDisってるのかどうかまでは知らない。しかし、すでに出たサンプルからはFRPの効力がまざまざと見せつけられている。
荒れるのは自由だけど、両方正しいとかそういうのじゃなくて、間違っている電波だみたいな叩きしかなくて、要するに感情論で反対派は反発しているだけでOK?
あるよ。
関数がどのパラメータに依存して、何を結果として返すのか明確になる。
グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。
短いプログラムならそれでもいいけどね。
別の誰かが書いてたように、上位スコープ内に定義されてるDOMでも、数学ライブラリでもなんでも、引数で関数に渡すのか？
グローバルな値を参照したり書き換えたりして
いやだから、定数なんだから書き換わらないんだよ、FRPのストリームはconst 定数なんだから。
オブジェクト指向と対比して考え方をまず学ぶって、岡部路線、住井グループはそれを目の敵にしていて集団的に攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。
FRPを純粋を理想とする関数型+時間で変化するストリームを値にマップして扱うリアクティブプログラミングの組み合わせっていうなら、別に誰も反論しないと思うけど。
HaskellのIOモナドみたいな別の抽象化をDISりつつ、FRPこそ正しい関数型みたいに言うから荒れるんじゃないの？
あるよ。
関数がどのパラメータに依存して、何を結果として返すのか明確になる。
グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。
短いプログラムならそれでもいいけどね。
「岡部氏のFRP」ではなくて、FRPっていうのはそういうもの。
俺も岡部氏のコード見ながら、この点考えてみたが、時間依存のFRPの値を__TIMEVALUEのようなひとつのオブジェクトにまとめて、逐一すべての関数の引数に加えれば？と思ったが、全部の時間依存の関数にそういうことをする意味はない、岡部氏のコードは、反対派ブログに書かれているコードよりも可読性が高く、コード量も半分とか圧倒しているし、「状態渡し」ではアプリは作れない、というのも岡部氏が正面切って批判するまで誰もはっきりと言わなかったことも反対派の信用性がない理由。それに「岡部氏のFRP」とか文句言う反対派の理解が怪しいと俺も思うようになった。
