  |
はてなキーワード:https化とは
2006年9月24日、京都発のIT企業・はてなの実験場「はてラボ」からはてな匿名ダイアリーがひっそりと産声を上げた。
当初は単なる試みの一つに過ぎず、誰もが自由に匿名で日記を書ける――いわゆる「匿名ダイアリー」、通称「増田（ますだ）」がこうして誕生したのである。
ちなみに「増田」という呼称はanonymous diary（アノニマスダイアリー）を日本語読みした際に「アノニ“マスダ”イアリー」と聞こえるダジャレに由来する。
サービス開始直後、匿名性を守るための施策が次々講じられた。リリース翌日の9月25日には投稿者のプロフィールページ（マイハテナー）へのリンクが早くも削除され、9月29日には画像貼り付け機能も禁止となっている。
テキスト主体で完全匿名を貫く方針が、最初の一週間で明確に示された形だ。初期の増田にはユーザー有志による「匿名ダイアリーならではの遊び」がいくつも提案されたものの定着はせず、10月上旬には投稿数も落ち着いた過疎期に入った。
しかし10月下旬になると様相が一変する。匿名ダイアリー発のエントリが徐々にはてなブックマークの「注目エントリー」（ホッテントリ）に顔を出し始めたのだ。
たとえば「はてなブックマークで話題になるブログとならないブログの違い」といったメタ考察の記事が注目を集め、増田発の長文論考がちらほらと人気入りするようになった。
サービス開始初日に投稿された記念すべき最初の増田のタイトルが「はてなの名でやるような事でもない」だったことも象徴的だ。
冒頭からして手厳しい内部批評であり、いかにも「はてならしい」船出と言える。
しかし、この小さな匿名ブログが後に国会で言及されるほどネット世論を動かす存在になるとは、当時誰が予想しただろうか。
サービス開始から数年、はてな匿名ダイアリーは着実に投稿数を伸ばし、技術ネタから社会批評まで多種多様な記事が日々生まれてきた。
匿名ゆえに過激な表現や内部告発（怪文書）、果ては明らかな釣り投稿まで玉石混淆だが、その一方で思わず涙ぐむような人情話や腹筋がよじれるほどの笑い話まで幅広く揃っているのがこの文化の面白いところだ。
たとえば2006年の増田人気記事には「JASRAC伝説」のようなネット業界の笑い話や、「プログラミング用のフォントを探してたら一日が終わってた」といったオタク的自虐ネタがランクインしている。
一方で「就職できない学生」のように現実の社会問題を吐露するエントリも早くから登場し、匿名という気軽さを武器に時に鋭い社会批評が行われた。
2010年前後には、増田は既にはてなユーザーコミュニティ内で話題の火種として定着していた。
とはいえ爆発的に脚光を浴びる転機は2013年に訪れる。この年の4月、はてなブックマークのトップページ刷新によって匿名ダイアリーへの導線が強化され、多数の増田がホッテントリ入りする事態となったのである。
事実、2013年以降は匿名ダイアリー全体の月間ブックマーク獲得数が急増している。
アクセス増に伴い投稿も活発化し、増田は技術系・生活ハック系から時事ネタ・人生相談まであらゆるジャンルのネタが飛び交う一大プラットフォームへと進化していった。
2016年にはサービス開始10周年を迎え、それを記念して公式Twitterアカウント（@hatenaanond）が開設された。
投稿のHTTPS化やスマホからの投稿機能検討などもアナウンスされ、実際2017年には全ページ常時SSL対応が実現している。
また同2017年には「人気記事アーカイブ」機能が追加され、過去の名作エントリを月別・日別に人気順で振り返ることができるようになった。
蓄積された匿名ダイアリーの膨大な記事群は、もはや日本ネット文化のアーカイブとも言える存在感を帯び始めている。
匿名ダイアリー（増田）は、日本のネット言論史の中で匿名掲示板とブログ/SNSの中間的ポジションを占めるユニークな存在だ。
巨大匿名掲示板（2ちゃんねる/5ちゃんねる）では多数の名無し達が雑然と議論を交わすが、増田では一人の匿名ユーザーがブログ形式で思いの丈を綴る。
いわば2ちゃんねる的な「名無しさん」の文化を受け継ぎつつ、ブログ的な長文表現とパーソナルな語り口を可能にしている点が特徴である。
そのため「公式」と「名無しさん」の隙間とも言えるポジションに位置づけられ、「実名では波風が立つが、完全匿名の掲示板よりは自分の言葉として語りたい」――そんなときに選ばれる場所となっている。
実際、ある著名人（川上量生氏）がNHK番組での騒動について心中を吐露した際、自身のブログではなく増田に「最後の書き込み」を残したケースもある。
彼は立場上「公式」に発信すると面倒が大きいが、匿名ダイアリーなら「詠み人知らずだった」と言い張ることもできると判断したのだろう。
このように増田は内部告発や本音の告白をしたい人々にとって格好の受け皿となってきた。
増田発のエントリが2ちゃんねる住民に発見されスレッドで引用・議論されることもあれば、逆に「今現在2ちゃんねるで起こっていること」を増田がまとめてホッテントリ入りするような例もある。
また、増田の内容が面白いとまとめサイトやTogetterに転載・紹介され、そこからさらに拡散する二次的な波及も起こる。
匿名掲示板、まとめサイト、増田はそれぞれ文体や文化は異なるものの、互いにネタを供給し合い日本のネット言論空間を賑わせてきたと言える。
一方、Twitterとの関係も緊密だ。Twitter全盛期以降、ニュースやトレンドを見たユーザーが詳細な議論や感想を増田に書き、それをまたTwitterで共有するというサイクルが生まれている。
140字（現在は拡張）の制限があるTwitterでは語りきれない本音や体験談を増田に綴り、そのURLがTwitter上で拡散されるケースは少なくない。
象徴的なのが2016年に匿名ダイアリー上に投稿された「保育園落ちた日本死ね！！！！」という怒りの叫びである。
このエントリは瞬く間に数百件のブックマークを集めてホッテントリの頂点に躍り出ただけでなく、Twitterでも大拡散し、ついには国会で野党議員が引用するまでに至った。
増田発のフレーズ「日本死ね」は2016年の流行語大賞候補に選ばれるなど、ネット世論がリアル政治を動かした一例として語り草になっている。
Twitter上では当該エントリへの賛否や共感が渦巻き、「#日本死ね」のハッシュタグが飛び交った。
増田で火が点いた匿名の声がTwitterという拡声器を得て社会現象化した典型と言えるだろう。
このように増田のエントリははてなブックマークを起点に各所へ波及していく。
匿名ダイアリーに投稿された記事は誰が書いたか分からないぶんタイトルと内容のインパクト勝負になる。
面白い／有益／刺激的だと感じた読者がブックマークしてコメントを付けることで評価が可視化され、一定数のブックマークが集まればホッテントリとしてトップページに露出する。
結果、さらに多くの読者が押し寄せてブクマが雪だるま式に増える。
この明確な評価システムゆえに、増田投稿者の中には「如何にブクマを稼ぐか」を意識して釣り気味のネタや炎上覚悟の過激な持論を投稿する者も現れた。
実験的に一ヶ月間で13本もの釣りエントリを投下し、4本をホッテントリ入りさせた強者もいるという。
ブックマーク数という指標があることで、匿名とはいえ投稿者は観客の反応を強く意識するようになり、増田は単なる独白の場から「ウケる文章」の競演の場へと文化的に洗練されていった面もある。
では実際、Hatenaブックマークで多数の反応を集める増田とはどのようなものだろうか。その傾向をいくつか具体例とともに分析してみる。
自身の子どもが保育園に落選した母親（と推測される）が、日本の子育て環境への怒りをストレートにぶちまけたこの文章は、多くの親世代の共感と怒りに火を付けた。
ブックマークコメント欄は賛同や政府批判の声で溢れ、大量のブクマが付くだけでなくメディア報道にまで発展した。
そして何よりも、この匿名の叫びが国政レベルの議論を誘発した意義は大きい。
他にも「民主党支持者としての愚痴」（民主党政権への苦言）や「東京都心の求人状況がヤバイ。はよ移民入れろ…」といった景気や労働問題への提言など、タイムリーな社会問題を扱った増田はブックマークが伸びやすい傾向がある。
匿名ゆえに本音で社会批判ができる点が、読者の溜飲を下げ「よく言ってくれた！」という反応に繋がるのだ。
個人のユニークな体験談や、役立つアドバイス記事も人気を博す。
例えば2014年の年間ブックマーク数1位となった「部下がくれたアドバイス」は、ある上司が部下から教わった貴重な助言を紹介したエントリだ。
具体的な内容は伏せるが、職場での人間関係改善につながる示唆に富む話で、多くの社会人読者の心を打ち大量のブクマを集めた。
また「1人暮らしのための料理の豆知識50」のように実用性の高い生活ハックも人気だし、「メールで使える英語のつなぎ言葉」のようにすぐ役立つ知識の共有は安定してブックマークが付く。
恋愛や結婚、離婚といった人生の局面に関する赤裸々な語りも注目されやすい。「離婚序章からの帰還」というタイトルの連載風エントリが話題になったり、「本当に悲惨な独り身の最期」といったショッキングな孤独死レポートが議論を呼んだこともある。
この種の投稿は読者の感情を強く揺さぶり、同情や驚きのコメントとともに拡散していく。
増田発のネタの中にはネットならではのオタク文化やサブカル的話題も多い。
例えば「( ・3・)クラシック好きの上司がジャズを聴きたいと言いだして」という2015年の人気増田は、音楽趣味の異なる上司と部下のユーモラスなやり取りを描いたもので、多くの読者の笑いを誘った。
他にも「Yahoo!チャットって場所があったんだよ」のように懐かしのネットサービスを語るノスタルジー系や、「無課金で数年続けていたソシャゲをやめて分かったこと」のように現代ネット文化（ソーシャルゲーム）に関する内省などもバズりやすい。
こうした記事は特定クラスタには刺さりやすく、はてブのコメント欄でも「わかる」「懐かしい」「自分も経験した」と盛り上がる傾向がある。
増田は匿名ゆえに自由な創作の発表の場にもなっている。ショートショート風のフィクションや、一発ネタ的なジョーク文章が投稿されることもあり、出来が良ければしっかりブクマを稼ぐ。
「家事は、レベルを上げて物理で殴れ」は家事のコツをRPG風に比喩したユーモア記事で、多くのユーザーの爆笑を誘った。
また、一部では増田発の優れた文章を「増田文学」と称し、ファンが選ぶ賞を作る動きまである（増田文学大賞など）。
このようにエンターテインメント性の高い文体やオチの効いた話も増田ならではの楽しみであり、はてなブックマーク常連のネタ枠として機能している。
総じて、はてなブックマークで大きな反響を呼ぶ増田には「共感・有用・驚き」のいずれか、もしくは複数が備わっていると言えよう。
強い共感や感情を喚起するもの、実生活や知的好奇心に役立つ情報を提供するもの、あるいは純粋にネット民を驚かせ楽しませるものが、人々の目に留まりやすい。
そして匿名という特性上、その内容が事実かフィクションか判然としない場合もあるが、それすら含めて読者は一種の物語として増田を消費している節がある。
だからこそときに釣り記事に踊らされることもあるが、それもまた増田という遊び場の醍醐味であり、読者も「ネタかもしれないが面白いからヨシ！」と受け止めているのだ。
何にせよ、「増田」はネットの深層心理を映し出す鏡のような存在だ。
喜怒哀楽、嫉妬や独白、叫びと祈り――匿名の影に人間の本音が渦巻いている。
ネット言論の文化史において、はてな匿名ダイアリーは2ちゃんねる的匿名文化を継ぎつつブログ的表現力を与えた場としてユニークな地位を占めてきた。
そしてその魅力は今も色褪せていない。
これからも誰かが増田にそっと心情を綴り、それが思いがけず何万もの人々に届いて共感を呼ぶことだろう。
匿名という仮面を被った本音のドラマは、きっとこの先もインターネットという舞台で上演され続けるに違いない。
ブコメでも指摘されてるけども。
ある時を境にスターの集計先になるURLが切り替わっているので、すべてのスター数を知るためには2回APIを投げる必要がありそうだ。
たぶんはてブがHTTPS化された2019年5月あたりが境目だろう
https://bookmark.hatenastaff.com/entry/2019/05/28/141208
自分のはてなIDと昔使ってたIDで試した限りではこうなっているはず。
①ttps://s.hatena.ne.jp/blog.json?uri=http://b.hatena.ne.jp/はてなID/
②ttps://s.hatena.ne.jp/blog.json?uri=https://b.hatena.ne.jp/はてなID/
| 2019年5月以降に作ったアカウント | ②の結果しか返らない。①を投げると403エラー |
| 2019年5月以前で消えたアカウント | ①の結果しか返らない。②を投げると403エラー |
| それ以外（2019年以前から今まで現役） | ①と②の結果を合算する |
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript),pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
[B! セキュリティ] フェイスブックの暗号化、日米英などが見直し要求へ （写真=AP） 日本経済新聞
平文に一定のアルゴリズムに従って暗号鍵から生成したノイズデータを掛け合わせ、意味が読み取れない暗号文を作るのが暗号化である。逆に意味が取れない暗号文から平文を求める操作を復号と呼ぶ。アルゴリズムがよく知られていながら暗号鍵が無ければ復号できないものがよい暗号と言われる。一般には256bitAESでも使っておけばまずパッと見ても聞いても数学的にもほぼ乱数と区別できなくなる。
ノイズデータの生成方法には色々あり、事前に送り付けた乱数表を使い使用後は破棄するもの、事前に送り付けた共通鍵や公開鍵を使うもの、都度生成するものなどがある。掛け合わせる方法も色々あり、乱数表に書いてある数字と暗号文を足し合わせると平文になるもの、共通鍵を暗号文に使うと平文になるもの、公開鍵を使うと平文になるものなどがある。
共通鍵を平文に使うと暗号文になり、共通鍵を暗号文に使うと平文になるものを、対称暗号とか共通鍵暗号と呼ぶ。
公開鍵を平文に使うと暗号文になり、暗号文に秘密鍵を使うと平文になるものを公開鍵暗号と呼ぶ。非対称暗号ともいう。
共通鍵暗号でも公開鍵暗号でも「平文が、暗号文になり、平文に戻る」というところは同じだが、
共通鍵では「平文→ 鍵→暗号文→鍵 →平文」と同じ鍵を使い、
公開鍵では「平文→ 公開鍵→暗号文→秘密鍵 →平文」と二種類の鍵を順に使う。
なお、この二種類の鍵は順に使えば順序はどっちでも良い。先に秘密鍵で処理して公開鍵で処理することも可能だ。とにかく2種類両方を使えば良い。
共通鍵暗号は分かりやすい。zipのパスみたいなもんだ。Wi-Fiのパスワードも同じだ。だが公開鍵暗号については、二種類の鍵を順番に使うと何が良いのかと思う人も多いだろう。どうせ暗号で読めないのだからいいじゃないかと思うだろう。実は名前の通り鍵を公開しても全くノーダメージというところがメリットなのだ。書かなかったが公開鍵から秘密鍵を数学的に求めることは不可能である。逆も不可能である。そして処理する順番もどっちでもいい。つまり適当な暗号文と鍵の片割れを公開しておくことで、もう片割れの所有を証明できるのである。これが公開鍵暗号の醍醐味である。
この技術はHTTPSの証明書に使われている。というかすべての公開鍵基盤で使われている。.pemとか.cerとかid_rsa.pubはこの片割れであり、ウェブブラウザの「証明書の検証」とは、ネットを見てる時にサーバが送ってくる「適当な暗号文」として"*.hatena.ne.jp"のハッシュを知らん鍵で暗号化したもののハッシュを知らん鍵で暗号化したもののハッシュを暗号化したものに対して、事前にWindowsをインストールした時に付いてきたHatena-MasudaUltra GlobalRootCAとかいったけったいな鍵の片割れを使ってみてちゃんと復号出来てるかチェックしているのである。
暗号化通信を行うには、暗号鍵でデータを暗号化すればいい。暗号化には共通鍵暗号を使うのが高速で便利だ。公開鍵暗号は原理的に計算量が多く低速である。しかし、どうやって共通鍵を事前に知らせればいい?公開鍵暗号で共通鍵を暗号化すれば、受け取り手は自分の秘密鍵で復号できるだろう。しかし、秘密鍵は本当に秘密か?暗号文と秘密鍵が手に入れば、公開鍵暗号でも解読できてしまうのではないか?HTTPS化しているウェブサービスでも、TLSをロードバランサで終端してデータセンタ内は平文だったりするのではないか? そこで鍵交換、セッション鍵生成の議論が登場する。
Diffie-Hellman-Merkle(Diffie-Hellman)鍵交換方式とは、ディッフィー君とヘルマン君が下宿で階段をドタドタやってる時に天啓のように降ってきたと言われる、ネット上に数字そのものを公開することなく、2者間で同じ1つの乱数を得る方法である。
送信者と受信者の間で共通の1つの乱数を得ることができ、その乱数を第三者に知られることがない。
上で何度か「公開鍵暗号の秘密鍵と公開鍵は、平文に対して両方使えば平文に戻り、順序は関係ない」と書いたのを覚えているだろうか。Diffie-Hellmanはこれに似た方式だ。まず、AさんとBさんは送信者がお互い本人であることを証明できるようにする(公開鍵基盤を使う)。そして、それぞれ手元で乱数AとBを生成する。次に、鍵用の乱数Aを適当な乱数で暗号化した鍵Aと、鍵用の乱数Bを適当な乱数で暗号化した鍵Bを計算し、お互いに送り付ける。この暗号Aと暗号Bは盗聴されているものとする。
AさんとBさんはそれぞれ鍵Bと鍵Aに対して暗号化を行う。すると鍵BAと鍵ABが生まれる。このとき数学的な都合により鍵BA == 鍵ABである。
では、暗号A、暗号B、適当A、適当Bのみから鍵ABや乱数Aを求めることはできないのか?可能だが式変形などで「解く」ことができず、総当たりになるため計算量が膨大になる。従って実質的にはできない。
或は、暗号A、暗号Bを掛け合わせれば、鍵ABになるのではないか? これもできない。暗号AまたはBと掛け合わせるのは生の乱数AまたはBでなければ意味がない。第三者が乱数Cを作って暗号AやBと掛け合わせても、鍵ACや鍵BCになってしまい、鍵ABと一致しない。
これにより、手元で生成した乱数以外のすべての情報が公開で既知で盗聴されているにもかかわらず、2者間で秘密の暗号鍵用乱数を得ることができる。
原始的なDiffie-Hellman鍵交換の実際の計算は非常に簡単であり、この「暗号化」は事前に決めた別の方法で生成する既知の2つの整数X, Yと乱数A, Bに対して、
暗号A = XをA乗してYで割った余り、
暗号B = XをB乗してYで割った余り、
鍵AB =暗号BをA乗してYで割った余り、
である。
なお、くれぐれも簡単と聞いてPython 2.7とかで実装しようとしないように。算数の上手い人が作ったライブラリを使え。暗号処理の自作は絶対バグらせて割られるのがオチだ。ちなみにDiffie-Hellman-Merkleの三人目のマークル氏というのは両名と何のゆかりもないので普通は名前に入れないのだが、Merkle氏の先行研究が直接の元ネタなので入れるべきだと主張する派閥もある。俺はどっちでもいいと思うが折角なので入れておく。
ここでやっとE2E暗号化が登場する。上のセクションでしれっと書いたが、DH鍵交換が完了した時に送信者と受信者が得る共通の乱数は、各々ローカルで都度生成する乱数を元にしている。身許保証は公開鍵によるが、鍵は公開鍵に縛られないのだ。つまり、SNSやメールサーバその他、身許を保証する機能と文章をやり取りする機能があるツールと、そのツールで間違いなく本人にDH鍵交換の暗号を送れるクライアントアプリがあれば、その経路で本人同士の間だけで共通の乱数を生成し、それを「セッション鍵」として共通鍵暗号方式による通信経路が設定できる。
この「公開鍵認証基盤で本人確認し、DH鍵交換でセッション鍵を設定し、鍵を端末に出し入れすることなく、受信側端末のメモリに入るまで暗号化を解くこともないまま、共通鍵暗号で通信する」のがいわゆる「End-to-End暗号化」である。
E2E暗号化を行うと、鍵はDH鍵交換で生成され、端末の外に出ないし書き出す必要もなく、通信の中で割り出す事もできず、通信が終われば破棄してもよい。好きなだけ定期再生成してもよい。認証に使う公開鍵と数学的な関係もない。一度設定してしまえば、SNS運営にチャットログを出させても鍵交換した意味不明な履歴と意味不明な暗号文が出てくるのみで、盗聴者をなりすまさせて鍵を再設定させても前の鍵と何も関係のない新しい鍵が出てくるだけで、意味不明な暗号文の解読の助けにはならない。ちょっと量子コンピュータめいているが、端末となりすましの両方で鍵を一致させることもできない。
ざっくり言えば送信側端末と受信側端末に残っている平文か鍵をバレる前にぶっこ抜く以外に解読方法がない。
これは盗聴関係者にとって非常に大きな問題で、米国のFBIなどは盗聴能力を維持するには法規制以外に策がないと考えている。DH鍵交換のアルゴリズムは上に書いた剰余以外にも楕円曲線を用いた数学的に更に複雑なものもあり、ソースはネットにいくらでも転がっているし、電子計算機アルゴリズムの常でやたら強力な癖に計算量的には全然負担にならない。NSAなどは数学者を揃えて最高のアルゴリズムを提供する振りをして、規格書で事前に決めた一定の数学的特徴を備えているべき定数に備えていないものを指定するとか、実装でミスが出やすい関数を選ぶなど小細工を入れているが俺は二次関数も分からんので詳しいことは知らん。しばしば政府の陰謀にキレた若いITキッズが小細工を抜いて差し替えた再実装を公開したりして揉めている。
実際にSNSなどでE2E暗号化を実装する上での問題点は、本人確認、機種変とマルチデバイス、嫌がらせ対応がある。まず本人確認がコケればMITMは可能だ。E2Eでは鍵を外に出さないのがメリットなので複数端末ログインができず(鍵が変わって別端末で書いたメッセージは解読できなくなる)、運営で常時メッセージを監視できない(したら意味がない)ので嫌がらせ対応が多少困難になる。またMITBというか、改造偽アプリで抜かれる可能性は、まあ、ある。
をクリックすると
http://b.hatena.ne.jp/ID/2019xxxx#bookmark-xxxxxxxxxxxxxxxxxxxxxx
ところが、今日気づいたんだが
://b.hatena.ne.jp/ID/2019xxxx#bookmark-xxxxxxxxxxxxxxxxxxxxxx
に飛ばされる通知がたまにある
（ただ、実際にはてブのhttps化が完了したわけではないので、httpsの方をクリックしてもhttpにリダイレクトされるだけだが）
「イエロースターがまとまらない問題」（この増田のやつ）もこれが原因かもしれない
httpd.confが初期設定に戻ってた
localhostをhttps化してたのだが、OSを入れ直したらオレオレSSLの設定をし直さなきゃいけない
ブラウザで動作確認するときはスーパーリロードをしないと、サーバーエラーの表示がキャッシュから表示されて、余計に混乱する
11.0を使ってたのだが、12.0にアップデートしたら、キーボードの認識で右シフトの一つ左キーのところで、先に進まなくなる
認識のウィンドウを閉じると、キーボードが英語キーボードと認識されてしまう
これが原因かcomplex_modification.jsonの読み込みでエラーが出る
よく使う項目の順序がリセットされてて面倒
