  |
はてなキーワード: Httpsとは
転売屋の情報をマップ上に表示したら面白くないか？と思って、「転売屋マップ」というサイトを作った。
マップ上にあるピンをクリックすると、転売屋の名前から住所から電話番号までが赤裸々になってしまう、そんなサイト。
Amazonに出品している業者は出品者情報を公開しているので、switchを転売していた出品者情報を全部取ってきて作った。
公開した日、明日目が覚めたらホットエントリに入っているかなと思いながら眠ったのを覚えている。
去年の11月のことだと思う。
このサイトを公開するためにドメインも取得した。新しくツイッターアカウントも作った。(@hoshikuzugawara)
面白いサイトを作ればホットエントリに上がるのではなかったのか、いやもっと面白い物を作らないとホットエントリにあがらない？
そんなことを最近悩みすぎて苦しい。
(投稿しようとしたら全然できなくて泣いた、リンク数でスパムフィルターって単純すぎるルールベースすぎませんか！)
水素水とかクレベリンとかNMRパイプテクターとか、いかにもエセ科学っぽいやつら、なんとなくエセ科学って判断してm9(^Д^)してる人が自分含めほとんどだと思うんだよ。結局「twitterで皆が言ってたから」レベルで、エセ科学/陰謀論信じる人と大差ないんじゃないかと思って、まずはクレベリンについて調べてみた。
調べたと言っても日本語の論文やらWebサイトを探しただけ、個人で実験するとか無理だし、僕は化学専攻だったわけじゃないし、英語苦手だし。
「こんな論文or調査があるよ」とか「いや、それはお前が完全に読み間違えてる」とかあれば指摘してくれると嬉しい。
公式サイト ttps://www.seirogan.co.jp/cleverin/
初っ端からtwitter引っ張ってきてたり、他のニュースへのリンク貼ってあったりして、既に怪しいキュレーションサイト感が漂っていて期待できる。
よく見る「空間除菌」をする「クレベリン」と、液体でアルコールや次亜塩素酸水のように使う「クレベ＆アンド」ってやつがあるらしい。アンド被ってんじゃん、クレベアンドアンドじゃん。
今回は「クレベリン」のほうだけ。
クレベリンのページ ttps://www.seirogan.co.jp/cleverin/cleverin/
特許取っているらしい。
特許は効果を保証するものじゃないってどっかで読んだな、特許の方の深堀りはしない。
「ウイルス除去・除菌の仕組み」のページ ttps://www.seirogan.co.jp/cleverin/cleverin/mechanism.html
深堀りしようかと思ったけど化学よくわからん。高校の時化学取ってないんだよね、ウソ取ってたかも、授業中モンハンしてたわごめん。
googleで検索かけた感じTOP5にwikipediaとか大幸薬品のサイトとか社団法人日本二酸化塩素工業会のサイトが出てくる。「社団法人日本二酸化塩素工業会」って大幸役品も正会員じゃん。てか大幸薬品の社長がこの会の会長じゃん。
「よくわかる二酸化塩素のはなし」のページ ttps://www.seirogan.co.jp/clo2/index.html
ウイルス除去
二酸化塩素ガス(室内濃度0.01ppm)を放出させた25m3(6畳相当)試験チャンバーに、ウイルスの一種を浮遊させた後攪拌し、180分後に空気中の浮遊ウイルスを捕集し、生存ウイルス数を測定しました。二酸化塩素ガスを放出しない条件(自然減衰、攪拌ファンのみ)で同様に測定した生存ウイルス数を100%とした時のウイルス生存率を求めました。
二酸化塩素ガス(室内濃度0.01ppm)を放出させた25m3(6畳相当)試験チャンバーに、細菌の一種を浮遊させた後攪拌し、120分後に空気中の浮遊菌を捕集し、生存菌数を測定しました。二酸化塩素ガスを放出しない条件(自然減衰、攪拌ファンのみ)で同様に測定した生存菌数を100％とした時の細菌生存率を求めました。
日本防菌防黴学会 第41回年次大会発表 研究発表プログラム ttps://www.saaaj.jp/conference/41th_pdf/conference_41th_14.pdf
低濃度二酸化塩素ガスの25 m3閉鎖空間における浮遊細菌と浮遊ウイルスに対する低減効果
(大幸薬品(株))
論文て末尾の人が一番えらいんだよ、知ってた？
学生のころ「自分」「教授」「助教」って順番で書いちゃって怒られたの思い出したよ。
ググって発見 ttps://jglobal.jst.go.jp/detail?JGLOBAL_ID=201502212674917241
JDreamⅢとかアクセスできないし、169Pも読んでらんないしどうしよ・・・
と思ったらなんか要約っぽいページ発見。
「二酸化塩素ガス室内濃度指針値（0.01ppm）での菌・ウイルスの低減を確認。大幸薬品、第41回 日本防菌防黴学会年次大会にて発表」 ttps://prtimes.jp/main/html/rd/p/000000029.000004917.html
[方法] 試験チャンバー25立方メートルを閉鎖空間とし、外部から二酸化塩素ガス発生装置を用いて発生させた二酸化塩素ガスを放出させ、撹拌ファンにて室内空気を循環させたところに、黄色ブドウ球菌懸濁液または大腸菌ファージφX174懸濁液を噴霧し浮遊させ、所定の時間後に浮遊細菌または浮遊ウイルスを捕集した。対照実験として二酸化塩素ガス発生装置を作動しない状態で同様の操作を行い、浮遊細菌と浮遊ウイルス数の自然減衰を測定した。
[結果] 0.01ppmの二酸化塩素ガスが室内空気中にある場合、浮遊黄色ブドウ球菌は120分後に99.8%、180分後に99.95%低減することが分かった。また、浮遊大腸菌ファージφX174は、180分後に99.2%低減することが分かった。
黄色ブドウ球菌ははたらく細胞で見たな、大腸菌ファージなんとかは初耳。
というか正直どっちもわからんわ。とりあえず「この2つで試験したこと」「25m3で試験したこと」「0.01ppmの濃度だったこと」「(この要約からだと)換気状況不明」「(この要約からだと)室温湿度不明」ということだけ覚えとく。
ppmって何？
二酸化塩素による除菌をうたった商品－部屋等で使う据置タイプについて－ ttp://www.kokusen.go.jp/news/data/n-20101111_1.html
詳細pdf ttp://www.kokusen.go.jp/pdf/n-20101111_1.pdf
あくまで「二酸化塩素が出てるか」という調査で、「二酸化塩素に空間中のウィルス・最近を除菌する効果があるか」という点には触れていない。
とてもちゃんと書いてある。
ちゃんと一部引用するのも大変だったので僕の主観で要約しちゃう。
気になる人はPDF参照。
ACGIH（アメリカ合衆国産業衛生専門官会議）の基準を引っ張り出している。日本に基準ないのかな？
TWA 0.1ppm (Time Weighted Average：毎日浴びてもほとんどの労働者に悪影響が見られないような～～～時間加重平均値)
STEL 0.3ppm (Short Term Exposure Limit: この値を超えて浴びてはならない15分間の時間加重平均値)
No.7がクレベリン、6畳でも1日後0.07ppm、5日後0.04ppmなので出てることは出てる。
この図に限らず、他の製品がヤバすぎてクレベリンがまともに見える。
見つからんかった。
厚生労働省とかコロナへの対応とかWebページ出してるけど二酸化塩素については全く触れてないのな。
あんま見つからんかった。というかググっても怪しいサイトが引っかかりすぎて悲しい。
ttps://ci.nii.ac.jp/search?q=%E4%BA%8C%E9%85%B8%E5%8C%96%E5%A1%A9%E7%B4%A0%E3%80%80%28%E3%82%A6%E3%82%A4%E3%83%AB%E3%82%B9+OR+%E7%B4%B0%E8%8F%8C+OR+%E9%99%A4%E8%8F%8C+OR+%E6%AE%BA%E8%8F%8C%29&range=0&nrid=&count=20&sortorder=1&type=1
CiNiiシャットダウンするみたいな話何年か前あったけどどうなったんだアレ。
いかにも空間除菌っぽいやつを探す。有料っぽいの多くて残念だけどいくつかは読めた。ありがとうJ-STAGE。
大幸薬品が出しているやつと西村秀一 氏(国立病院機構仙台医療センター臨床研究部ウイルスセンター)が出している論文が目を引く。
ウイルス不活化効果を標榜する二酸化塩素ガス放散製剤の実用性の有無の検証―冬季室内相当の温湿度での空中浮遊インフルエンザウイルスの不活化について―
ttps://www.jstage.jst.go.jp/article/jsei/31/5/31_16-020/_pdf/-char/ja
二酸化塩素ガス放散製剤のインフルエンザウイルス不活化および黄色ブドウ球菌殺菌能の検証―低湿度環境表面での検討―
ttps://www.jstage.jst.go.jp/article/jsei/32/3/32_131/_pdf/-char/ja
低濃度二酸化塩素による空中浮遊インフルエンザウイルスの制御―ウイルス失活効果の湿度依存性―
ttp://www.kankyokansen.org/journal/full/03205/032050243.pdf
ここまでで気が付かなかったけど大幸薬品は結構英語論文もだしてるっぽい、疲れたし英語苦手だから今回はそこまで追わない。ゆるして。
(西村氏には申し訳ないが)疲れてきたので僕の独断で主張をピックアップして要約。引用ですらない。気になる人はpdf
この要約だけだとわかんないけど、pdf中で西村氏クソ煽ってて笑った。
大幸薬品と西村氏の実験でそれぞれ違う結果がでてるっぽくて、どっちを信じるとかはよくわからんけど、再現状況不明 + 違う結果が出る時点で積極的にクレベリンを採用する理由はないよなぁと思ったり。僕はバイアスかかりまくりなので西村氏pushだけど。
というか論文少なくね？僕の探し方が悪いだけ？
まぁ健康被害にはならなそうなんで目くじら立てるほどじゃないかな。こういう根拠が怪しいやつが蔓延るのは将来を考えるととても悲しいが。最近陰謀論もよく見るしね。
でもこういうのに身近な人がハマったら悲しいよなぁ。
頭ごなしに証拠突きつけて否定しても駄目なんだってさ、ビハインド・ザ・カーブでみた。オススメだよ。
地球平面説を信じる人は勉強が足りないわけじゃないんだってさ、下手したら僕らより頭いいみたいよ。
ただググって文字起こすだけでも数時間よ数時間、怪しいのに反論するのもタダじゃないね、疲れた。ググって文字起こしただけとはいえ頑張って書いたので色んな人の目に触れると嬉しいな。
決済で使ってる三井住友銀行から、ロンダリング防止の確認のためのweb提出を求められたんだが、苦痛に耐えつつ8割くらい進んだ所でエラーが出て、入力分が全部喪失してしまったので、やめてしまった。回答いただけないと利用制限とか警告書いてあるけど、無視してやる。
https://infoweb.smbc.co.jp/hojin/
以下、ダメすぎてムカついた点
https://www.iseto.co.jp/company/profile.html
なんだか歴史だけは御大層な会社に依頼して作ってるらしいけど、学生サークルのイベント参加フォームだってもっと丁寧に作るだろ。金とっていい仕事じゃないよこれ。こんなの納品されてOKだしてる銀行のIT部門も相当クソ
infoweb.smbc.co.jpが、httpからhttpsにリダイレクトする設定がされてないから、ブラウザでアドレス打ち込むときに、しっかりhttpsから打ち込まないと、目的のページにはたどり着かないってのが原因だ。スマホのときは、QRコード使ってhttpsのほうにアクセスしたからつながったってことか。
SSL使ってるちゃんとしてるはずの企業で、こんなクソサイト初めてだわ。http→httpsのリダイレクトなんてSSL対応の基本の基本なのにな…SSL対応のお仕事は会社設立以来初めてやりましたって会社なのか？こんな素人感丸出しだと、もっと重要なところでもやらかしてそうで、金預けてて大丈夫か心配になるわ。
http://infoweb.smbc.co.jp/hojin/
ここ最近、Kyash社が提供する資金移動サービス「Kyash」の海外サービス手数料がTwitterで騒ぎになっている。
日本国外の加盟店で、日本円建ての取引をすると「海外サービス手数料」として3%が決済代金に加算されるというもの。
Kyashには2つの利用規約があり、アカウントの種類によって適用される規約が異なる。
Kyash送金サービス利用規約とKyashバリューアカウント利用規約である。
どちらの規約も、今回の手数料で問題となる部分は同じ文言である。
Kyash送金サービス利用規約第11条2項には以下の記述がある。
外貨建取引については、当該取引の事務処理のため、別途当社が定める「海外サービス手数料」がかかります。当該手数料については当社Webサイト上に掲載します。
外貨建て取引に手数料がかかる旨の記載はあるが、海外加盟店での日本円建て取引に手数料がかかるといった記載はない。つまり、今回問題となっている手数料は根拠がない。規約違反であり契約違反である。
規約にこそ記述はないが、公式サイトのヘルプページには記載がある。
しかし、このページは2020年12月ごろに書き換えられたものであり、Eメールやアプリのプッシュ通知などで利用者に通知されたものではない。不当である。
https://web.archive.org/web/20201123170556/https://kyash.co/legal/terms/value-account
全国の消費生活センター等_国民生活センター HTTPSが腐っているので注意
リプとかはてブの反応見てると、みんな増田にやさしく同情的だけど、残酷だなって思う。
増田は「それでいい」なんて言われたくないんだよ。
「それでいい」ってことは、「このまま一人で清いまま死んでいけ」って言われてるのと同じだからね。
増田は「正しさよりも、誰かと一緒に居たい」って言ってるのに、誰もくみ取ってあげていない。
「誰かと一緒に居たいけど、『正しさ』がどうしても捨てられなくて、相手に手順を求めてしまう」ってことを嘆いているだけなのにね。
増田の嘆きはよくわかる。小さいころから「間違ったことをしてはいけない」って押し付けられすぎて、人間の泥臭いところを飲み込めなくなっちゃってるんだよね。
みんなはどうやって正しさと、泥臭さの中間に折り合いをつけてるのか。そこがわからなないって文章に見える。
理屈とか全部忘れて、自分の一番欲しいもの以外はどうでもいいって思えないと、アラサーから自分を変えるなんてできない。
それで後から後悔するような何かがあるかもしれないけど、後悔するリスクを負わないと経験値は得られないんだよ。
自分の生活から半径数メートルですべてを捨ててしまうのはリスクが大きすぎるから、
せめてもの防衛として、ちょっと離れたコミュニティ（共通の友達や知り合いが全くいないところ）で馬鹿をやってみるといいよ。
うまくいったならそれでいいし、うまくいかなかったらコミュニティごと捨ててしまえばいい。
増田が今のぐるぐるした状況を抜け出せることを祈ってる。
－注－
この記事は「それでいい」という意見に対して、無責任で残酷であるというスタンスの文章です。
が、「それでいい」という言葉を否定したとして「セックスに応じろ」という意図は一切ありません。
といった声掛けが、個人的にこの場合のセオリーだと思っています。
本人的にも、現状に満足しているとはとても思えない文章なのに、「現状のままでいい」なんて言葉求めてないだろう。
という意味です。ここまで書かなくても読み取れるとおもうので最初は書いていませんでした。
－注・終わり－
女子っぽい文章だと思ったら「頭が悪そう」を頭につけてくるの、ただの自己紹介だからね。
だいたいの女子は「あ、馬鹿が来た」って思う言葉だからやめたほうがいいよ。
長文の追記がないと、本文に書いてないことで叩いてくるんだよ。
人気のコメント見てみ？言ってもいない「セックスに応じろと言うことか」ってコメントいっぱいあるから。誰もいってないっての。
onesplat こんなに人の増田でブチギレされて元増田もさぞ慄いているだろう 。個人的には増田の言ってることは支離滅裂だと思うしそれに気付いてないのが厳しい
支離滅裂とか、根拠なしで書いてもただの中傷にしかならないから、恥ずかしいしやめた方がいいと思う。
ledlizerd 男の人はそれでもいいかもだけど女の人は妊娠だとかいろいろ心配はあるから特に歳とってから失敗はダメージでかいよ。セックス絡めない失敗は経験だと思うけど。残酷なこと言ってるの増田の方だと思うよ？
注を読んでください。この本文から、「セックスに応じろ」と読み取るのは、斜め読みにも程があるので、批判したいならもう少しきちんと読んでからにしてもらえますかね。
shinonomen 何でいきなりセックスを求めてくる男とセックスをするか、一人で死ぬかの二択なんだよ。元増田の気持ちが高まるまで待ってくれる男と出会える可能性はそれほど低くないと思うが。
まさに無責任。元の文章から焦りが全然読み取れてない。この投稿にも「セックスしろ」とも書いてない。ぜんっぜん読み取れてない。読解力死んでるの？
「このままじゃだめだよな」という投稿に「そのままでいい」ってのは、そのまま死ぬってことでしょ。
なんで、「現状維持」か「誘いに応じろ」か二つしか選択がないの？恋愛経験ないの？なんで「二択なんだよ」はこっちのせりふだよ。誰だよ二択設定したの。あなたでしょ。
「そういうこと言うならちゃんと告白して」っていうだけでもいいじゃない。現状を打破する必要はあるでしょって話をしているの。
nankichi “増田は「正しさよりも、誰かと一緒に居たい」って言ってるのに、誰もくみ取ってあげていない。”やり捨てされるか紐にされて30代後半で捨てられるのが見えていないの？
いやー見えないな。自己紹介か何かなのかと思っちゃったよ。そんなひどい目にあったの？
kumpote 「正しさよりも、誰かと一緒に居たい」えっどこにそんなの書いてあるの？自分元増田の進化系みたいな奴だけどそんなん全然読み取れなかったわ。書かれていない行間読むマン怖…それこそ自己紹介では？
副アカ乙
tyawanmushi001 「正義を振りかざす」か「傾聴・受容・共感」か それでもブコメなんだからだれがなにを書いていいと思う
良いか悪いかの話はだれもしてない。ブコメに対して「残酷」と書いたの。ブコメにコメントするのも自由だよね。
msdrmgmg いや普通に、ヤリ目の不誠実な人にヤリ捨てされるよりはやらないで終わったほうが良くない？本当にその男性がヤリ目だったかは分からないが…
わかんないんだったら良くはないでしょ。少なくとも後悔はするでしょ。
greenbow 婚約するまでしない派は2018年時点でも４割ぐらい居る。セックスを拒否したぐらいで「一人で死ぬ」ことにはならないと思いますよ。 https://～
そういうことを30歳喪女になげかけるのが残酷って言ってるんだよ。言葉の最後に「しらんけど」ってついてるじゃん！そういうところだよ！
brightsoda"理屈とか全部忘れて、自分の一番欲しいもの以外はどうでもいいって思えないと、" その相手の態度に醒めたから断って帰ったんだろ？自分に正直じゃん。
自分の決断に後悔がなかったら増田に書いてないだろー！その程度読み取れー！
molmolmine 「別にヤリ目とは限らないから様子見推奨」的な事書いたし増田の言いたい事も解るけど、だからといって無責任な匿名の身で下手に「ヤッてもええやん」とか焚きつける方が怖いと言う気持ちも判るやろ、増田よ。
なんで無責任の反対が「ヤッてもええやん」なんだ！
「そこでなんで断るだけなのか」とか「付き合う前にそういうのは嫌だと言えばいい」とか、いくらでも言ってやりようがあるでしょってことを言ってるの。
ヤればいいなんて思ってたらこんな文章書いてないのわかるでしょ！
tk_musik セックスしたい＝ヤリ目も違くね？極端を指摘しながら極端を言うなよ
どこにそんなこと書いてあるーーーー！
むしろどっちかといえば、「ヤリ目」かどうかわからないから、聞きなよって立場だ！
ほんと、文章読んでる？どこにそんなこと書いてあった？
chikisio 誰だか知らんけど、「この増田はこう思ってる！！」と騒ぎ立ててて滑稽すぎる。あなたがそう言われたいというだけなんでしょ。あなたの増田を立ててよ。
本題から目をそらして、人を腐すことに一生懸命なのも十分滑稽だと思うよ。私の話なんてどうでもいいでしょ。
まあ、あえて言うなら、こんな感じ(anond:20210106111439)ですわ。悪いね！
kyo_ju レイプ後に"お前が変わるためにレイプしてやった"とか説教しそうな増田/元増田の"いい年して何を勿体ぶってるんだって話ですね""何を期待していたんだという感じですね"辺りは予防線としての自己卑下でしょ
なんでレイプの話がでてくるの？男側断られて引いてるよね？引かずに強引に犯そうとしたの？どこにそんなこと書いてあるの？
そうやって相手に悪いイメージを押し付けて自己正当化するのが予防線なんだ。呪い吐いてるみたいだね。
white_rose それほど好きでない、誠実さも感じられずセックスも下手そうな相手といたしたところで余計惨めな気持ちになるだけでは。
勝手に相手のことを悪く言って、関わらなくてよかったってことにするのなんて言うかしってる？すっぱいブドウっていうんだよ。あなたのコメントの方が惨めな気持ちにに見えるんだけど？
ああ、わからないんだ。元増田の投稿全体がそのもやもやした気持ちの表れなんだけど、読み取れないなら最初から終わってるわ。かわいそ。あなたには何も求めないからいいよ。無理だし。
あれを一番簡単に実現するのはソース送信だけどそれは無しとして他の方法を模索してみる。ちなみに解は出てない。
※想定問答 Q「サーバサイドでやれ」 A「石油王連れてきて」
レコメンド対象にしたいキーワード辞書をアプリに同梱してマッチした単語だけ送る。
本文丸ごとでは無いんで多少は忌避感下がるけど、いつ・誰が・どのURLでそのキーワードをブラウザで見たかは伝わっちゃう。
パーソナライズ不要なら「誰が」も落とせるけどそれだと精度出なかったからあの仕組みにしたんだろうしねぇ…
あと本当に本文だけ使ったレコメンド目的ならURLも不要だけどwww.muji.com→オサレみたいな特徴を加えたかったのかな。
--
最近はiOS(CoreML)にもAndroid(NNAPI)にも機械学習機能あるようで、
ネイティブアプリなんだからその辺触れるんだしクライアント側で完結しちゃえば?という発想。
レコメンド先のコンテンツ丸ごとスマホに持つわけにはいかんから、
コンテンツID?カテゴリ?的なものを出すとこまでやって中身はサーバに取りに行くんで本当にクライアントだけで閉じるわけじゃ無い。
パーソナライズ観点で一人一人特注のモデル作って配るとかはしんどそうだけど、
ある程度セグメント切った層ごとに事前にモデル作るぐらいなら何とかなるんでは。
ああでもレコメンド対象が日々増えるWeb記事だとモデル頻繁に更新するからデプロイが辛いか。
スペックもりもりのサーバでやる推薦が現代のスマホでそもそも代替出来るのかはわからん。
エッジAIなる名目で各社頑張ってて目的の一つはセキュリティだから、今は無理でも将来に期待?
--
分類にしろ推薦にしろ元データそのものをダイレクトに結果に変換するんじゃ無くて一度単なる数値の配列（特徴ベクトル）に変換して、
そのあとモデルに突っ込んだら中でこねこねヘイお待ち!と出てくるんだよね?
その特徴ベクトルに変換のとこだけクライアントでやってそれ送れば?という発想。
スペック問題はあるけどレコメンド全部やるよりはマシだよねと淡い期待を抱いている。
特徴ベクトルから元のデータに戻せるとアウトだけど可能なのかね。
文字列を数値にしててかつ情報量が落ちて結果が1対1にならないから、完全な復元は無理だと思うけどどうだろう。
ありとあらゆるキーワードを事前に変換しといて結果から逆引きすれば変換元候補を出すくらいはできるんかな。
--
いろいろ考えたけどソースそのものじゃ無くてもそれに近い情報はどうやっても送るんだから、
コールセンターに電話すると自動音声で「サービス品質向上のために通話を録音します」的なアナウンス流れたりするのと同じで、
おすすめ機能ってこういう情報送ります的な説明をアプリ内ですべきでそれ無しにやっちゃダメだったんでしょう。
アプリの実物触る前に終わったので実際には説明してたんならごめんなさい。
--
https://toolbar.rakuten.co.jp/mobile/rule.html
利用者が本アプリを利用した場合、利用者は、第6項の定めに従い、これを停止しない限り、本アプリがデバイスにインストールされているブラウザの全てのウェブ閲覧履歴（http（https含む。以下本条において同じ。）で始まる閲覧ページURL、アクセス日時（分秒）、表示されたウェブページのHTMLソース、クッキー情報（Cookie）, ウェブサイトの閲覧履歴、リファラ, ユーザーが使用しているOSやアプリのバージョン、位置情報をいい、以下「ウェブ閲覧履歴取得情報取得情報」といいます。）が当社によって取得されることに同意するものとします。
当社が取得するウェブ閲覧履歴取得情報には、ウェブページのURLを含み、当該ウェブページのセキュリティ環境によってはURLにIDやパスワード等の非公開、又は機密性の高い情報が含まれることがあります。よって、機密性が高い情報、または機密性が高い可能性のある情報を閲覧する環境において本アプリを利用される場合には十分にご留意ください。
ソースどころか脆弱性無い限り聖域のクッキーまで取る豪快さを見習おう。
--
ちなみにフェアじゃないので一応書いておくと「楽天ウェブ検索 規約」でググると出てくるこっちのブラウザ拡張機能版は微妙に内容が違ってクッキーは入ってない。
上のアプリ版はアプリストアの説明にURLが書いてある。なんでアプリとブラウザ拡張機能で2種類あるのかは分からん。
拡張機能じゃ取れないから? でもサイトごとのクッキー編集する拡張とかあったような・・・
https://toolbar.rakuten.co.jp/intro/rule/
２． 利用者が本機能を利用した場合、利用者は、第6項の定めに従い、これを停止しない限り、本機能がインストールされたブラウザの全てのウェブ閲覧履歴（http（https含む。以下本条において同じ。）で始まる閲覧ページURL、アクセス日時（分秒）、表示されたウェブページのHTMLソースをいい、以下「ウェブ閲覧履歴」といいます。）が当社によって取得されることに同意するものとします。
３． 当社が取得するウェブ閲覧履歴には、ウェブページのURLを含み、当該ウェブページのセキュリティ環境によってはURLにIDやパスワード等の非公開、又は機密性の高い情報が含まれることがあります。よって、機密性が高い情報、または機密性が高い可能性のある情報を閲覧する環境において本機能を利用される場合には十分にご留意ください。
あとこの規約についても先日malaさんが突っ込んでいるので第一発見者ではないです。
https://twitter.com/bulkneets/status/1339435587015639041
--
ソースどころかクッキーまで取ってますと堂々と書いてるほうが燃えずに、
はっきりとは書かずに取ってたほうが燃えてるの、
やらないと思ってたやつがやる・やると思ってたやつがやる、どっちもやってるけど燃えるの大抵前の方なの、
個人情報をポイントに変えるポイ活するためのアプリってちっともスマートではないな
国産ブラウザアプリSmoozはあなたの閲覧情報をすべて外部送信している
・デフォルトの設定では、設定・操作・閲覧情報がユーザーID、デバイスIDと共にアスツール社のサーバーへ送信されている
・検索窓に入力した文字は、検索ボタンを押さなくても、その内容が逐一アスツール社のサーバーへ送信されている
・検索内容がアダルト関連ワードかどうかがアスツール社のサーバーに送信され判定されている
・サービス利用データの提供設定をオフにしても、閲覧情報がアスツール社のサーバーに送信されている
[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というか、改造偽アプリで抜かれる可能性は、まあ、ある。
日本語における母集団を全部確認できないので、自分の観測範囲だけになってしまうが、
（炎上させない限り、まともな回答がつかないなど）
思いつくままに仮説を挙げてみる。
仮説①：Googleなど検索サイトが日本語の対応に熱心ではない。
仮説②：https対応できない、サービスが終了したなどにより、良質なサイトが消えた。
仮説③：記事の質よりもアクセス数を重視しているので、質が低下した。検索サイトは質を考慮しない。
仮説⑤：短い動画が主流になり、難しい話ができなくなった。
仮説⑥：検索サイトの機能はより洗練されているが、自分の検索能力が成長していない。
仮説⑦：今のWebの機能が、情報をまとめるのに適していない。もしくは機能不足。
仮説①について。
Googleが日本語をさぼっていても、bingやDuckDuckGoなど別の検索サイトを使えば、仮に母集団に良質な記事があるのであれば、見つかると思うがどうも見つからない。
Wikipediaは信用ならないと言われ、確かに怪しい所はあるが、まだマシだ。
もっとも一般に求められている情報が変わってきたというのもある。
いかにネット上で盛り上がっていることに乗るか、という使い方をする場合だと、Twitterを検索するだろうし、情報の出どころを確認する、反対の意見がないか確認するといったことはしなくてよい。
そもそもニーズがないのだから営利企業は対応しない。日本の大学から新しい検索エンジンが出てくるわけでもない。
仮説②について。
デザインが古いなどあっただろうが、昔のWebサイトの方が質が高かったように思える。
仮説③について。
有料の記事についても、特に質が劇的によくなっているかというとそうではない。有料メルマガも同様。
どうせWebで読まれる記事なんて1日経ったら他の内容に興味を持たれて忘れられるので、それほど質は必要ないのかもしれない。
営利目的ではなく、趣味でやっている人は質を良くしようというモチベーションはあるだろうが、営利目的で質が関係ないならKPIに入れない。
仮説④について。
Webライターと言われる人が、元は出版社に勤めていたということがあり、Webが次世代の人を育てられなかったのだろう。
過剰にWebと親和性が高い人は、炎上させるなどグレーゾーンを攻めるのが生存戦略となっているし、
ある段階から、身の回りの地位は低いが能力が高い人を使うことになっており、自身で情報をまとめていない。（本を出しても影武者が書くなど）
SNSが広まって、多くの人がテレビで嫌われていたコメンテーターになった。
仮説⑤について。
スマホに移行したこともあるだろうが、言葉を尽くして人に説明して納得してもらう、というのができなくなった。
仮説⑥について。
検索サイトのヘルプで新しい検索方法が解説されているわけではないので、どうやって成長させるのか疑問がある。
検索能力を上げるための検索も、能力がなければできないとなると、どうするのか。
SEO的な能力を上げるのはビジネスになっているのでできるだろうが、インテリジェンスに近い検索は個人の試行錯誤でなんとかなるものなのか。
仮説⑦について。
togetterやはてブのような、記事のリンクを集めるような機能はあるが、論理的な結びつきなどを示さない。
コンピュータの性能は上がったが、表記のゆれをチェックするくらいしか進化していない。
