  |
はてなキーワード: ウェブブラウザとは
山登りが趣味の友人がいるのだが、ある日「俺が遭難した時のために君のメールアドレスをYAMAPみまもりに登録させてもらえないだろうか？」と言われて二つ返事でOKをした。
ここでYAMAPみまもり機能を知らない人に軽く解説をすると、これは山を登っている相手の位置情報がわかるサービスだ。
YAMAPアプリの特定の機能を登山者が起動すると、自動的に登録した相手に位置情報が送られてくる。
受け取り手は好きなタイミングでいま、相手がどこにいるのかウェブブラウザなどで確認できる。
またそれだけではなく、最後に記録された位置情報から動きがしばらくないと警告のメールが届いたりする。
とまあ山登り愛好家なら最高の機能なんだが、この友人、職場の近くに山があってそこに毎日の様に昼休みに登ってアプリを使いタイムアタックしたりと色々している。
そしてその度に俺のもとに「活動開始」と「活動停止」のメールが届くのだ。
これが最近かなりウザくなってきたのだ。
安全に関わる話だし、ここは一つ大人として我慢しなきゃいかんのかな？と思いつつまあまあうざいな、と思い愚痴として書かせてもらった。
ちなみに活動が終わると「⚪︎⚪︎さんは活動を終了しました」と逆に遭難して動けなくなったかの様なメールが届くのでそれだけが唯一少し笑える点かな。
迷惑メールにも入れられないし困ったもんだ。
第２回 Larabelチュートリアルを参考にログインするだけのWebアプリケーション(?)を作る
composer create-project laravel/laravel example-app_20240131
続いて、Composerを使用してLaravel Breezeをインストール
composer require laravel/breeze --dev
php artisan breeze:install
いろいろ聞かれる。わからん。とりあえずBlade/Yes/PHPUnitを選択。
すると「・・・・installed successfully.」と表示されたので何かが成功したっぽい。
続いて
php artisan migrate
するとエラー。
Illuminate\Database\QueryException SQLSTATE[HY000] [2002] Connection refused
そもそもデータベースの準備を何もしてなかったので、エラーが出るのは当たり前だった。
サンプル用にデータベースを作成し、それに合わせて.envファイルを修正する。
再度、
php artisan migrate
すると「DONE」と表示。成功したっぽい
チュートリアルに従い、「ウェブブラウザでアプリケーションの/loginか/register URLへアクセス」。
すると、Laravelが出してるっぽいエラー
Illuminate \ Foundation \ ViteManifestNotFoundException PHP 8.1.27 10.43.0 Vite manifest not found at: /******/example-app_20240131/public/build/manifest.json Run npm run dev in your terminal and refresh the page.
npmとやらが「not found」だったので手順を飛ばしたのがやはりダメだった。
さくらインターネットでnpmを使うにはnode.jsをインストールしてnpmをコンパイルする必要がある？
次回があれば「さくらインターネットのスタンダードプランの環境にnpmをインストールする」である。
早くHello Worldとか書きたい。
FirefoxのサポートやめたとかニュースでChrome一色になることにブラウザの多様性がどうこういう言ってる人がよく出てくる
それよりもChromium内蔵系しか新規参戦がほぼ無理な状況をどうにかすべきじゃないのって思ってる
MDN見てるとdeprecatedって書かれた、いわゆる廃止された関数とかが多くある
しかしウェブブラウザは互換性を重視するせいで廃止されても何年も残ったまま
たぶんこのまま行くとずっと残るんじゃないかな
実装済みブラウザはいいけど新規で作ろうとしたらこういう大量にある変な仕様で廃止された関数の山まで作らないといけない
しかし、互換性重視で削除されることはほぼ無いのをいいことに気にせず使い続けるユーザーは少なくない
単純に置き換えられる関数があるならいいが、そういうのがなく手間がかかる手段に置き換えるしかない場合は廃止されてようが使えるものは使う人が多いだろう
●●が廃止になったみたいなブログ記事のブクマで知らなかったとか言ってる人はかなり多い
そのせいで廃止済み機能を実装しないブラウザが出てきたとしても多くのページでは動かない
Chromium系ブラウザならそういう部分はすでに実装されてるからちょっとだけカスタムだけして新規ブラウザとして出せる
だから新しくなにか出てきてもChromium系ブラウザばっかり
今はIE が死んだなんてめったにないよい機会なんだからこのタイミングで廃止機能は完全に削除したり歴史的経緯でイマイチな挙動になってる部分を一新してもらいたい
スマホが普及して、芸能人でもなんでもない人のInstagramやtwitterその他ブログ等を見る機会が多くなっている。
これにはiPhoneからAndroidに変えて、ウェブブラウザを変えたこにより、アクセス上位の記事がトップに表示されることも理由の一つかもしれない。
そして世の中的にも、ＳＮＳのアカウントを持つことがが当たり前のになっているし、いわゆるバズった一個人の意見や体験記を見る機会はこれからも増え続けるだろう。
カメラロールにもインスタ映えする写真はないし、行列グルメには並ばないし日常にこれといったドラマもない。
過激な主張もなければ、社会問題に鋭く意見し、人の共感を集めることもない。
たまにnoteかなにか書いてみようかな〜と思うけど、大したものは書けないのでやらない。
、、、、こんなふうに考えると自分の社会的影響の小ささがなんだか恥ずかしいであるかのように思えてくる時がある。
フォロワー〇〇人います！！とか、SNSコンサルで起業しました！みたいなやつ、かっこいいよね。
でも、この世に生きているほとんどの人に大したドラマはないし、非日常の連続なんてない。
けれど私は毎日幸せに、自分の人生を自分なりに、楽しんでいると思う。
例えばカメラロールはかわいい我が子の写真で溢れているし、毎日妻が温かいごはんを作ってくれているし（毎日ありがとう）、職場の人もいい人ばかりだ。
あれ、、、
なまじ一般人の影響力が強い時代で、発信力の強い人が目に付きやすい世の中だけに、足元の自分の幸せに気づいてない人が多いんじゃなかろうか。
スマホ画面に映る高嶺の花ばかり見ていると、足元に咲く現実の野花の美しさに気が付かないことがあるよね。
自分のことも認めてあげましょう。
Floorp ウェブブラウザと名乗るブラウザが最近出てきて、開発が終了したKinzaのパッチが公開されたら取り入れると宣言してKinzaの後釜を狙ってるらしい。中の人は学生(中学生？高校生？)らしく、使っていくうちにチャラさ、痛々しさが目立ってきたのでこき下ろしていきたい。
このブラウザが気になってしょうがない人はTwitterアカウントに行けばダウンロードリンクがあるのでダウンロードして確かめればよい。
※以下の話は、断りのない限り8/28に公開された公開ベータ版(v1.1.3)のことである。
---------------------------------------------------------------------------------------------------------------------------------------------
1.Floorpをお選びいただき、ありがとうございます。高速で軽量なブラウジングをお楽しみください。
2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、Chromiumのライセンス「BSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。
3.Dev Previewエディションの場合、TwitterなどのSNSにスクリーンショットなどをアップグレードしないでください。
4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。
5.Ablazeの利用規約に沿って本ソフトをご利用ください。
6.以下に表示されている利用したオープンソースソフトウェアに感謝しましょう。Floorpはこれがなければ実現しませんでした。
7.開発者はあまりすごいことをしていないことに気づきましょう
8.ソースはこちらhttps://github.com/Ablaze-MIRAI/Floorp-Browser
---------------------------------------------------------------------------------------------------------------------------------------------
利用したオープンソースソフトウェア
[※以下略]
さて、どこから突っ込もうか。
---------------------------------------------------------------------------------------------------------------------------------------------
あああああああああああああああああああああああああああああああ開発つかれた
1.Floorpをお選びいただき、ありがとうございます。高速で軽量なブラウジングをお楽しみください。
2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、Chromiumのライセンス「BSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。
3.Dev Previewエディションの場合、TwitterなどのSNSにスクリーンショットなどをアップグレードしないでください。
4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。
5.Ablazeの利用規約に沿って本ソフトをご利用ください。
6.以下に表示されている利用したオープンソースソフトウェアに感謝しましょう。Floorpはこれがなければ実現しませんでした。
7.開発者はあまりすごいことをしていないことに気づきましょう。後眠いんだけどどうしよう？癒してください！彼女ください（）
8.Floorpは有志によって無料で提供されています。寄付は受け付けますのでダイレクトメッセージ https://Twitter.com/Floorp_Browser へお越しください
9.ソースはこちらhttps://github.com/Ablaze-MIRAI/Floorp-Browser
[※以下略]
利用規約をなんだと思っているんだ。「利用規約は楽しく、ユーモアにありふれさせたい」とか「Floorpの利用規約の最後に・彼女になることに同意しますか？って書けば同意させられんじゃん」とかつぶやいてる時点でなめてるしふざけてる。
Ablaze-MIRAI/Floorp-Browser: Chromiumで一番軽量なブラウザの大部分のソースコードです。
というタイトルなのに、実際に公開されているのはブラウザコンポーネントに比べてかなり少ない。これのどこが「大部分」なの？
あと何の根拠もなく「Chromiumで一番軽量」って言い切ってるだけで相当痛い。一番軽量かどうかは知らんが、メモリ使用量が少ない=軽量と思い込んでる節がある。ほか、
という文は誤解を生むから今すぐ止めろ。これだとBSDライセンスに違反するぜ！と宣言してるような解釈もできるから。利用規約でOSSに感謝しましょうとか言っておいてこの扱いひどくないか？
このブラウザの自己紹介記事(https://blog.ablaze.one/573/2021-08-16/)が先週公開されていたが、ここに書かれてる内容も相当痛々しい。
ブラウザをインストールするとメモリカスタマイザーなるものが同時にインストールされる。これが動作することでFloorpブラウザのメモリ使用量が劇的に減ってるから軽い、ということらしい。
しかし、ブラウザを起動したまま放置してみてから、実際のWindowsタスクマネージャーの様子をよく見てほしい。メモリ使用量が数MBとありえないぐらいまで減っているのがわかるだろう。Windowsタスクマネージャー上ではメモリ使用量が減っているように見えるが、ブラウザのタスクマネージャーで表示されるメモリ使用量はそれほど減っていない。では何が起こっているのか？
メモリカスタマイザーの正体はFireminである。名前の通り元々はFirefox用で、仮想メモリにページアウトさせて物理メモリ使用量を減らすものらしい(実際の動作は細かく見てないのでよくは知らない)。Fireminの名称変更、起動時にFloorpを自動的に対象にするといった改造を施している。FireminによってWindows10の途中の大型アップデートから搭載されたメモリ圧縮がより積極的にかかるようになり、物理メモリ使用量も減らせるメリットはあるようだ。YouTubeのトップページを開いてしばらく待った時、メモリカスタマイザーの使用時と未使用時で約0.1GBの差はあるのは確認できた。ただし、メモリ圧縮の代償はパフォーマンスの低下。特にページアウトによりディスクI/Oが増える。ディスクI/Oが足を引っ張って重くなる場合があるので、必ずしも軽いとは言えない。
結局の所、Chromiumを改造するなどの根本的な解決策を取っているのかは疑問である(もししているならTwitterなりに書いているだろう。技術的アピールができるし)。Floorpブラウザの作者はWindowsのタスクマネージャーに出てくる見せかけの数値だけを見て「えっ、Floorp軽っ、、、、、」とか言ってるのだから、実に恥ずかしい。いつ気がつくか見物である。
500ms単位でメモリ節約機能が動作するせいで、Speedometer 2.0のベンチマーク結果がさえない。未使用時と比べて7%ぐらいスコアが落ちてる。Edgeよりもスコアが良くない。メモリ使用量のことばかり気を取られて、速度のことには関心がないのかもしれない。
Chrome Web Store外から拡張機能(Deepl翻訳と同期機能)をインストールさせるためにレジストリを使用した結果、他のChromium派生ブラウザ(SRWare Ironで確認済)でも拡張機能がインストールされたという通知が表示されるようになってしまう。
Cドライブ直下にフォルダー作ってそこに入れるとか、いつの時代のソフトだよ。Program Filesに入れてやれよ。
https://ja.wikipedia.org/wiki/Wikipedia:%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC/Floorp
https://twitter.com/surapunoyousei/status/1431961462734352385
作者から依頼されて書かれた記事に客観的な証明なんてどうやってするんだろうね。
まあKinzaのパッチが出てからが本番っぽいし、それまではこれぐらいにしておこうか。
Uniant Browser → Floorp Browser? UniantとAblazeの関係がよくわからん。個人で開発してるのか寄り集まって開発してるのかもよくわからん。
中の人のTwitterで中学生と書かれていたことがあったので、高校生ではないかもしれない。高校生の表記から「学生(中学生？高校生？)」に変更した。
元増田だけど、伊藤穰一は自分で何か作ったりはしないけど、テクノロジーの目利きとして他人がまだあまり注目していないサービスやカルチャーを紹介したり投資してきた人。
ウェブブラウザ、検索サービス、WoW（ネトゲ）、ブログ、ツイッター、食べログ、TEDやオープンソースやクリエイティブコモンズみたいなシェアカルチャー、メディアアートなんかに関して国内での火付け役と言っていいくらい貢献した。
一方でディープラーニング以降のテクノロジーやカルチャーはそれほど追えてるようには見えず、組織運営やお金を集める役目にシフトした感じはする。それはそれで誰か優秀な人がやらなくちゃいけない仕事だけど。
SNS（ソーシャル・ネットワーキング・サービス）で提供され、不特定多数の参加者同士が相互に交流し、競争や協力をしながら遊ぶオンラインゲーム。ソーシャル・ネットワーク・ゲームsocial network gameともいう。アプリケーションプログラムを使用機器にインストールする必要がなく、ウェブブラウザー上で動作する。
おまえらかーちゃんには「ガンダムじゃなくてダイターン3だよ！」とか厳しいくせにアプリゲーム（主にガチャがあるゲーム）をソシャゲっていうのやめーや。
これいうと「もう実際ソシャゲで定着してるから」とかいうドアホウがいるけどじゃぁダイターン3もガンダムアンテナみたいなのあるしガンダムアイみたいになってるからかーちゃんの細かい間違いぐらい許したれや！
もっといい方法があるのかも知れないけれど、自分がやるならウェブブラウザのデベロッパーツールとか開発者ツールとか呼ばれる機能を使う。はてブのページを開いておいてWeb StorageのLocal Storage内にある"bstn.ignored_users"というキーの中身をコピーする。
デベロッパーツールの使い方はブラウザによって違うので調べて。
ググってみたがここを見とけば簡単みたいなページは無いな。ここは割とまとまってた。
各ブラウザでWebStorage（LocalStorage）を確認する方法 - Qiita
「ブラウザ 重い」とかで検索するとキャッシュ削除してタブ閉じろ、みたいな内容のページばかりが山ほど引っかかる訳なんだけど、そもそもブラウザ自体がすごく重いソフトだよな。
古いマシンのOS交換での再生で「ブラウザくらいなら十分」とか書かれてる事が多いけど、ブラウザが楽に動くマシンならオフィス系のソフトは全部楽勝で動くよなと思うんだわ。 「ゲームは無理」「動画エンコードは無理」「ブラウザは動くけど重い」「オープンオフィスは快適」みたいな状況が多いんじゃねえのかと。
使ったことないからわからんけど、エディタでは重いと言われるAtomとかVisual Studio Codeだって、ブラウザほどは重くないんじゃないの？
[B! セキュリティ] フェイスブックの暗号化、日米英などが見直し要求へ （写真=AP） 日本経済新聞
平文に一定のアルゴリズムに従って暗号鍵から生成したノイズデータを掛け合わせ、意味が読み取れない暗号文を作るのが暗号化である。逆に意味が取れない暗号文から平文を求める操作を復号と呼ぶ。アルゴリズムがよく知られていながら暗号鍵が無ければ復号できないものがよい暗号と言われる。一般には256bitAESでも使っておけばまずパッと見ても聞いても数学的にもほぼ乱数と区別できなくなる。
ノイズデータの生成方法には色々あり、事前に送り付けた乱数表を使い使用後は破棄するもの、事前に送り付けた共通鍵や公開鍵を使うもの、都度生成するものなどがある。掛け合わせる方法も色々あり、乱数表に書いてある数字と暗号文を足し合わせると平文になるもの、共通鍵を暗号文に使うと平文になるもの、公開鍵を使うと平文になるものなどがある。
共通鍵を平文に使うと暗号文になり、共通鍵を暗号文に使うと平文になるものを、対称暗号とか共通鍵暗号と呼ぶ。
公開鍵を平文に使うと暗号文になり、暗号文に秘密鍵を使うと平文になるものを公開鍵暗号と呼ぶ。非対称暗号ともいう。
共通鍵暗号でも公開鍵暗号でも「平文が、暗号文になり、平文に戻る」というところは同じだが、
共通鍵では「平文→ 鍵→暗号文→鍵 →平文」と同じ鍵を使い、
公開鍵では「平文→ 公開鍵→暗号文→秘密鍵 →平文」と二種類の鍵を順に使う。
なお、この二種類の鍵は順に使えば順序はどっちでも良い。先に秘密鍵で処理して公開鍵で処理することも可能だ。とにかく2種類両方を使えば良い。
共通鍵暗号は分かりやすい。zipのパスみたいなもんだ。Wi-Fiのパスワードも同じだ。だが公開鍵暗号については、二種類の鍵を順番に使うと何が良いのかと思う人も多いだろう。どうせ暗号で読めないのだからいいじゃないかと思うだろう。実は名前の通り鍵を公開しても全くノーダメージというところがメリットなのだ。書かなかったが公開鍵から秘密鍵を数学的に求めることは不可能である。逆も不可能である。そして処理する順番もどっちでもいい。つまり適当な暗号文と鍵の片割れを公開しておくことで、もう片割れの所有を証明できるのである。これが公開鍵暗号の醍醐味である。
この技術はHTTPSの証明書に使われている。というかすべての公開鍵基盤で使われている。.pemとか.cerとかid_rsa.pubはこの片割れであり、ウェブブラウザの「証明書の検証」とは、ネットを見てる時にサーバが送ってくる「適当な暗号文」として"*.hatena.ne.jp"のハッシュを知らん鍵で暗号化したもののハッシュを知らん鍵で暗号化したもののハッシュを暗号化したものに対して、事前にWindowsをインストールした時に付いてきたHatena-Masuda Ultra Global Root CAとかいったけったいな鍵の片割れを使ってみてちゃんと復号出来てるかチェックしているのである。
暗号化通信を行うには、暗号鍵でデータを暗号化すればいい。暗号化には共通鍵暗号を使うのが高速で便利だ。公開鍵暗号は原理的に計算量が多く低速である。しかし、どうやって共通鍵を事前に知らせればいい? 公開鍵暗号で共通鍵を暗号化すれば、受け取り手は自分の秘密鍵で復号できるだろう。しかし、秘密鍵は本当に秘密か? 暗号文と秘密鍵が手に入れば、公開鍵暗号でも解読できてしまうのではないか? 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というか、改造偽アプリで抜かれる可能性は、まあ、ある。
元エントリーの人がどこまで理解しているか不明だけど、自分が初心者だったときこういう説明がほしかったという話をしてみる。
暗号方式、特に公開鍵暗号の理解が難しいのはいくつか理由がある。
②素朴な利用例が少なく応用的な利用がいくつもある
また、ざっくりした概念以上のものをきちんと理解しようと思うと
④何がどのくらい安全で何がどのくらい危険かセキュリティ的な概念の説明
ここでは自分的にこういう順番で概念を把握していったという流れを書いてみる。
まず、物理的な錠前や書留郵便をイメージするのはあきらめてほしい。
あくまでもデジタルデータを別のデジタルデータに変換して再び元に戻すためのものだ。
公開鍵暗号登場以前は、パスワードを使って変換（暗号化）して、同じパスワードを使って元に戻す（復号化）という共通鍵暗号の時代が長く続いた。
それが暗号化のパスワードと復号化のパスワードで異なるものを使うという技術だ。
・特殊な数学的アルゴリズムでパスワード１から、それと対になるパスワード２を生成する
・パスワード１で暗号化したものがパスワード２で復号できるだけでなく、その逆つまりパスワード２で暗号化したものがパスワード１で復号できる（※）
今はその数学的アルゴリズムまで理解する必要はない。ただそういうことが可能になったというだけでいい。
パスワード１（秘密鍵）を自分以外が見られないように保管して、パスワード２（公開鍵）を通信相手に渡せば暗号通信ができそうということは理解できると思う。
ちなみにこのパスワードの長さは、プログラムで生成した100桁以上の数字が使われることが多く、それを定型的な千文字程度のテキストにして使われるのが一般的。
ツールで生成すると千文字程度のテキストファイルが秘密鍵用と公開鍵用の2個できる。
これだけの桁数なので暗号化復号化の計算はそれなりに時間がかかる。（※）
（※） このあたりは一般的な公開鍵暗号というよりRSA公開鍵暗号特有の話も混ざってます。詳しくは専門書参照
次にこの発明を使ったらどういうことができるだろうか、応用できる先を考えてみよう。
誰でも最初に思いつく例だけどシンプルすぎて共通鍵と変わらなくありがたみがない。
(b)僕にメッセージを送るときは僕の公開鍵で暗号化してね（いわゆる公開鍵暗号）
メッセージの送信先を間違って別人に送ってしまっても他人は読めないし、経路のどこかで盗み見や内容の一部を改竄されたりすることがない。
メッセージに返信するときは今度は「僕」ではなく相手の公開鍵を使って暗号化する。
(c)本文を毎回全部暗号化すると時間がかかるから共通鍵を君の公開鍵で暗号化したものを送るね。それを君の秘密鍵で復号したら以降は高速な共通鍵暗号で通信しよう（鍵交換）
共通鍵暗号の高速性というメリットを利用できて、かつ生の共通鍵がネットに流れるリスクを排除した良いとこ取りの方式。
(d)暗号化しない本文と、本文から計算したハッシュ値を秘密鍵で暗号化したものを送るね。公開鍵で復号化したハッシュ値がそっちで計算したハッシュ値と同じなら本文は改竄されてないよ。
それからこの暗号化は僕しかできないから確かに僕から送られた文書、僕から送られた内容であると保証できるよ。（電子署名）
この「電子署名」の実現により、さらに次のような応用が可能になる。
(e)ログイン時に毎回パスワードを打つと見られたりして危険だからユーザ名等に署名したものを送るね。公開鍵で復号（検証）OKならログインさせて（公開鍵認証）
(f)僕は信頼できるよ。これがAさんの署名入りのお墨付き。検証してみて。
Aさんは信頼できるよ。これがBさんの署名入りのお墨付き。検証してみて。
Bさんは信頼できるよ。これが世界一信頼できる人の署名入りのお墨付き。検証してみて。
（サーバ証明書）
前項のようなやりとりはほとんどアプリが自動的にやってくれるので、コンピュータ技術者以外の人が公開鍵や秘密鍵を直接扱う機会は現状ほとんどないと思う。
ウェブブラウザのアドレス欄に鍵マークが表示されていたらそれは鍵交換やサーバ証明書技術が使われていて、鍵マークを右クリックすると証明書を表示できる。
メールアプリでも最近は自動的に鍵交換やサーバ証明書が使われている。
もしメールアプリにPGPの設定オプションがあればそこで公開鍵と秘密鍵を設定すると特定の相手と本格的な暗号化メールがやり取り可能になる。
サーバ操作するコンピュータ技術者だと公開鍵認証もよく使われていて、ツールで生成した公開鍵をサーバに登録してログインに利用してる。
当社は、個人情報保護の重要性について認識し、個人情報の保護に関する法律(以下「個人情報保護法」といいます)を遵守すると共に、以下の利用規約(以下「本利用規約」といいます)に従い、適切な取扱い及び保護に努めます。なお、本利用規約において別段の定めがない限り、本利用規約における用語の定義は、個人情報保護法の定めに従います。
利用規約において、個人情報とは、個人情報保護法第2条第1項により定義される個人情報を意味するものとします。
美容医療アプリその他の当社のサービス（以下総称して「当社サービス」といいます）の提供のため
当社サービスを円滑に利用できるようにするため
現在提供しているサービスまたは今後提供を検討しているサービスに関するアンケート実施のため
当社サービスに関する情報等または当社以外の事業者が広告主となる広告情報等をメールマガジン等により告知するため
お問い合わせ時など、本人確認を行うため
当社の契約する病院へ予約した際、予約やその後の診察が円滑に進むようにするため
当社サービスに関する当社の規約、ポリシー等（以下「規約等」といいます）に違反する行為に対する対応のため
その他当社サービスに関する重要なお知らせなど、必要に応じた連絡を行うため
株主管理、会社法その他法令上の手続対応のため（株主、新株予約権者等の個人情報について）
当社のサービスに関連して、個人を識別できない形式に加工した統計データを作成するため
当社は、個人情報の利用目的を関連性を有すると合理的に認められる範囲内において変更することがあり、変更した場合には個人情報の主体である個人（以下「本人」といいます）に通知し又は公表します。
当社は、個人情報保護法その他の法令により許容される場合を除き、本人の同意を得ず、利用目的の達成に必要な範囲を超えて個人情報を取り扱いません。但し、次の場合はこの限りではありません。
人の生命、身体又は財産の保護のために必要がある場合であって、本人の同意を得ることが困難であるとき
公衆衛生の向上又は児童の健全な育成の推進のために特に必要がある場合であって、本人の同意を得ることが困難であるとき
国の機関もしくは地方公共団体又はその委託を受けた者が法令の定める事務を遂行することに対して協力する必要がある場合であって、本人の同意を得ることにより当該事務の遂行に支障を及ぼすおそれがあるとき
5. 個人情報の適正な取得
5.1 当社は、適正に個人情報を取得し、偽りその他不正の手段により取得しません。
5.2 当社は、次の場合を除き、あらかじめ本人の同意を得ないで、要配慮個人情報（個人情報保護法第2条第3項に定義されるものを意味します）を取得しません。
当該要配慮個人情報が、本人、国の機関、地方公共団体、個人情報保護法第76条第1項各号に掲げる者その他個人情報保護委員会規則で定める者により公開されている場合
本人を目視し、又は撮影することにより、その外形上明らかな要配慮個人情報を取得する場合
第7.1項但書によって第三者提供にあたらないものとされる態様にて要配慮個人情報の提供を受ける場合
5.3 当社は、第三者から個人情報の提供を受けるに際しては、個人情報保護委員会規則で定めるところにより、次に掲げる事項の確認を行います。ただし、当該個人情報の提供が第4項各号のいずれかに該当する場合又は第7.1項但書によって第三者提供にあたらないものとされる態様でなされる場合を除きます。
当該第三者の氏名又は名称及び住所、並びに法人の場合はその代表者（法人でない団体で代表者又は管理人の定めのあるものの場合は、その代表者又は管理人）の氏名）
当社は、個人情報の紛失、破壊、改ざん及び漏洩などのリスクに対して、個人情報の安全管理が図られるよう、当社の従業員に対し、必要かつ適切な監督を行います。また、当社は、個人情報の取扱いの全部又は一部を委託する場合は、委託先において個人情報の安全管理が図られるよう、必要かつ適切な監督を行います。
7.1 当社は、第4項各号のいずれかに該当する場合を除くほか、あらかじめ本人の同意を得ないで、個人情報を第三者に提供しません。但し、次に掲げる場合は上記に定める第三者への提供には該当しません。
当社が利用目的の達成に必要な範囲内において個人情報の取扱いの全部又は一部を委託することに伴って個人情報を提供する場合
合併その他の事由による事業の承継に伴って個人情報が提供される場合
また利用者が当社の契約する病院へ見積もりや予約、問い合わせをした際に、当該病院に情報（氏名、性別、年齢、メールアドレス、電話番号、カウンセリング希望日、当該病院への来院歴の有無、生年月日、診察券番号、施術部位の写真、相談内容等）の提供を致します。
7.2 第7.1項の定めにかかわらず、当社は、第4項各号のいずれかに該当する場合を除くほか、外国（個人情報保護法第24条に基づき個人情報保護委員会規則で指定される国を除きます）にある第三者（個人情報保護法第24条に基づき個人情報保護委員会規則で指定される基準に適合する体制を整備している者を除きます）に個人情報を提供する場合には、あらかじめ外国にある第三者への提供を認める旨の本人の同意を得るものとします。
7.3 当社は、個人情報を第三者に提供したときは、個人情報保護法第25条に従い、記録の作成及び保存を行います。
7.4 当社は、第三者から個人情報の提供を受ける場合には、個人情報保護法第26条に従い、必要な確認を行い、当該確認にかかる記録の作成及び保存を行うものとします。
8. 個人情報の開示
当社は、本人から、個人情報保護法の定めに基づき個人情報の開示を求められたときは、本人ご自身からのご請求であることを確認の上で、本人に対し、遅滞なく開示を行います(当該個人情報が存在しないときにはその旨を通知いたします)。但し、個人情報保護法その他の法令により、当社が開示の義務を負わない場合は、この限りではありません。
当社は、本人から、個人情報が真実でないという理由によって、個人情報保護法の定めに基づきその内容の訂正、追加又は削除(以下「訂正等」といいます)を求められた場合には、本人ご自身からのご請求であることを確認の上で、利用目的の達成に必要な範囲内において、遅滞なく必要な調査を行い、その結果に基づき、個人情報の内容の訂正等を行い、その旨を本人に通知します(訂正等を行わない旨の決定をしたときは、本人に対しその旨を通知いたします)。但し、個人情報保護法その他の法令により、当社が訂正等の義務を負わない場合は、この限りではありません。
当社は、本人から、本人の個人情報が、あらかじめ公表された利用目的の範囲を超えて取り扱われているという理由又は偽りその他不正の手段により取得されたものであるという理由により、個人情報保護法の定めに基づきその利用の停止又は消去(以下「利用停止等」といいます)を求められた場合、又は個人情報がご本人の同意なく第三者に提供されているという理由により、個人情報保護法の定めに基づきその提供の停止（以下「提供停止」といいます）を求められた場合において、そのご請求に理由があることが判明した場合には、本人ご自身からのご請求であることを確認の上で、遅滞なく個人情報の利用停止等又は提供停止を行い、その旨を本人に通知します。但し、個人情報保護法その他の法令により、当社が利用停止等又は提供停止の義務を負わない場合は、この限りではありません。
11.1 当社は、匿名加工情報（個人情報保護法第2条第9項に定めるものを意味し、同法第2条第10項に定める匿名加工情報データベース等を構成するものに限ります。以下同じ）を作成するときは、個人情報保護委員会規則で定める基準に従い、個人情報を加工するものとします。
11.2 当社は、匿名加工情報を作成したときは、個人情報保護委員会規則で定める基準に従い、安全管理のための措置を講じます。
11.3 当社は、匿名加工情報を作成したときは、個人情報保護委員会規則で定めるところにより、当該匿名加工情報に含まれる個人に関する情報の項目を公表します。
11.4 当社は、匿名加工情報（当社が作成したもの及び第三者から提供を受けたものを含みます。以下別段の定めがない限り同様とします）を第三者に提供するときは、個人情報保護委員会規則で定めるところにより、あらかじめ、 第三者に提供される匿名加工情報に含まれる個人に関する情報の項目及びその提供の方法について公表するとともに、当該第三者に対して、当該提供に係る情報が匿名加工情報である旨を明示します。
11.5 当社は、匿名加工情報を取り扱うに当たっては、匿名加工情報の作成に用いられた個人情報に係る本人を識別するために、(1)匿名加工情報を他の情報と照合すること、及び(2)当該個人情報から削除された記述等若しくは個人識別符号又は個人情報保護法第36条第1項の規定により行われた加工の方法に関する情報を取得すること（(2)は第三者から提供を受けた当該匿名加工情報についてのみ）を行わないものとします。
11.6 当社は、匿名加工情報の安全管理のために必要かつ適切な措置、匿名加工情報の作成その他の取扱いに関する苦情の処理その他の匿名加工情報の適正な取扱いを確保するために必要な措置を自ら講じ、かつ、当該措置の内容を公表するよう努めるものとします。
当社サービスは、Cookie及びこれに類する技術を利用することがあります。これらの技術は、当社による当社サービスの利用状況等の把握に役立ち、サービス向上に資するものです。Cookieを無効化されたいユーザーは、ウェブブラウザの設定を変更することによりCookieを無効化することができます。但し、Cookieを無効化すると、当社サービスの一部の機能をご利用いただけなくなる場合があります。
当社では、当社サービスに第三者から配信される広告を掲載する場合があります。その際、当該第三者が、当社サービスを訪問したユーザーのCookie情報等を取得することがあります。取得されたCookie情報等は、当該第三者のプライバシーポリシーに従って取り扱われます。Cookie情報等の広告配信への利用は、停止することができます。Cookieによってユーザーを特定したり、プライバシーを侵したりすることはありません。
当社は、個人情報の取扱いに関する運用状況を適宜見直し、継続的な改善に努めるものとし、必要に応じて、本利用規約を変更することがあります。
14. お問い合わせ
本利用規約に関してご不明な点がある場合、本サービスにおける個人情報の取り扱いに関するご質問・苦情・ご相談等がある場合は、お問い合わせフォームよりご連絡ください。
以上
