  |
はてなキーワード: ウェブブラウザとは
＊はてブは一つの記事や話題に対して様々な意見が集まるページがメイン。個人のページはサブな感じ。
＊ツイッターは個人のページがメインで、一つの記事や話題に対して様々な意見が集まるページはハッシュタグやキーワードで検索した場合に生まれる副次的なもの。
＊はてブには「非表示」という機能はあるがブロックに相当するものはない。
はてブはかつては先進的な言論が集まる面があった。しかしその後ネトウヨが流入して言論の質はツイッターと変わらなくなった。そうなると、脳が腐っているとしか思えないネトウヨが大嫌いな自分にとっては上記の特徴は不快でしかなかった。そのほか、
＊はてブは100文字だがツイッターは150文字、話を続けたければ自己返信や自己引用で続ける事が可能。
正真正銘の貧乏人なので数年前にNMP一括ゼロ円プラスキャッシュバックでゲッツしたiphone6の16GBモデルをつこうております。
バッテリーとかコネクタの交換とかで延命させてたんだけど結局それがとどめを刺すことになり挙動がやばくなってきたのでPCへバックアップを取ることに。
16GBとかいう容量では対してなにか入れたつもりでなくてもアレで、ストレージに余裕を持たせるためにicloudに写真をあげるようにしたのが数ヶ月前。
よくわかんないんだが撮った写真がいちいちクラウドに上がって、なにか使おうと思ったらいちいちダウンロードしてこないといけない。めんどくさい。
appleが悪いのか俺のPCが悪いのかよくわからんが、書いてあるとおりにやろうとしてもできない率の高さは異常
icloudとかなんなんだよ
iphoneのストレージが足りないから写真をicloudにアップしたんだけどPCに保存しようとしたら
icloud photoは有効ではありませんとかでてきて、ダウンロードが選択できない
ネットに書いてあるとおりやろうとしてもダウンロードっていうボタンが出てこない
しょうがないからウェブブラウザからicloudにアクセスした
ctrl+Aで全選択できなくてctrl+Alt+ひとつひとつクリックでちまちま何百枚も選択しないといけない
前提として私は女で漫画が好きなんだけど
twitterとか見てるとバンバン漫画とかスマホゲーとかの広告が出てくるわけ
それがかなりの確率（主観）で女の性的なところが強調されてる画像なんだよ
女の尻どアップだったり、それどころかセックスしかけだったりしてたりした後だったり
いやもーーー勘弁してくれーーーーー
女向け漫画も男向け漫画も女の性的なところを強調する広告出してくるのやめてくれ
マンガアプリとかでも、実際使ってるやつの広告が出てくるときあるんだけど、
いやおめーー女の乳や尻がメインじゃないすげーいい漫画いっぱいあるのになんでそのシーンだけチョイスしたっていうやつ多くてしんどい
分かるよ、エロは人を惹きつけるよ。私もエロは好きだよ。こないだエロ漫画買ったし
けどそれを心構えしてない時にドーーーンバーーーーーンって出してくるのが心に負担なんだよ
それが何度も何度も繰り返されてしんどいんだよ
なんで「女といえばエロだよね！！！」って感じで女のエロい画像を広告に使いまくるんだよ
見ててつらいよ、女が性的に搾取されてたりいじめられてたりする漫画の広告つらいよ
誰が最初に潮を吹くかゲームとかそういうの、いきなり広告で出すのやめてくれよ
誰かがそういうのを好きなのは分かるし誰かに需要があるのは分かるから、嫌いな人がそういうのを一括で拒否できる公的なやり方が欲しいよ
話がずれるけど、男の性的な部分が強調された広告ならいいのかっていったら、それはそれでしんどいんだろうなと思う
なにせこっちは性的なこと考えてない時に「はーーーーいセックスでーーーーーす！！！！！！！！」っていきなり広告ぶち込まれててさ
いや私のテンション的にいまセックス匂わす系はお呼びじゃねえんだわってかんじなのさ
だから女でも男でも組み合わせがヘテロでもホモでも性的なのをいきなり流されるのがしんどいんだろうけど
実はそこに更に「性的なのは女に偏ってる」っていう私の観測が入って、なんで女だけなんだよっていう主観的なムカつきが混ざってて、今はしんどいんだろうなと思う
あと私の性的なことを常に求めているわけではない性質とか混ざってさ
うーーんこのあたり支離滅裂でごめんね
更にずれるけどギスギスした追い詰められてる系漫画の広告もしんどいよ
人類みんなバトルロイヤル系漫画やいじめ復讐漫画が好きなわけではないんだよ
何かのつらさを全面に押し出す広告ばかり流れてくるのはしんどいんだよなあ
追記
twitterのクライアントについて提案してくれてありがとう。twitter好きだからさ、「広告で金稼いで長生きしてくれよな！」と思って公式のアプリを使ってたんだわ。けどなんかもうこの広告見続けるの限界かなって思ったので教えてもらったやつに乗り換えようと思う。
あとウェブブラウザに関してはアドブロック入れてるんだ。けど広告はすり抜けて表示されるし、cookie制限？とかで通販とか色々やりづらくてさ、それも難儀してる。アドブロックを提供してる会社のウェブブラウザも入れたよ。あれ9割広告非表示にしてくれてありがたいよ。けど望ましい広告まで制限かけちゃうからさ、それはそれでどうかと思うんだよね。広告すること自体は悪くないじゃん。自サイトに広告載せることで頑張ってるサイトはどーなんのかなーとかさ、利用者として申し訳なさあるんだよね
なんていうかさ、個人の努力で嫌な広告ガードするのもいいんだけど、それって結構疲れるし知らない人はノーガードになっちゃうじゃん。いろんな人がネット使うわけだしさ、もっと楽に「ごめんこの広告無理だわ」ってやつを見たくないボタンみたいなの押したらそれに類似した広告大体現れなくなるみたいなの欲しい。好きなものを見てる時に突然現れる苦手なものから逃げる方法が欲しい。私インターネット広告の仕組みよくわかってないから馬鹿なこと言ってるんじゃねーかなと思うけどさー
再追記
文中に出した「ホモ」って単語についてなんだけど、「組み合わせがヘテロでもホモでも」って書いてる通り、ヘテロ（異なるもの同士）ホモ（同じもの同士）って意味でさ、高校の生物の授業で出てくるヘテロ接合ホモ接合と同じ感覚で使ったんだわ。
別に誰かを貶めたいわけじゃないんだよね
けどもしかしてこういう使い方も今ってだめなのかな？ホモって単語使った時点でだめなのかな。不勉強でわからないから今度本とか読んでみるわ。指摘してくれてありがとね
昔のホームページにしろブログにしろ個人が好きなもの載せたり書いたりするところで、何を置くかはその人の好みで好きにすればいいところだ
来る人に優しいコンテンツでも一見さんお断りな感じでも好きにすればいい
怖い画像のブラクラみたいなのだって見る側の自己責任で作る人には問題ない
脆弱性ついてPCを壊すとかになれば別だけど通常のウェブブラウザで許可されてるもので何しようが自由だ
そうしたウェブページを公開してるのは、自分の部屋を一般公開して見に来る人に見せてるようなものだ
見に来る人はわざわざ訪問してきて部屋の中を見てるわけで見たくなければ帰ればいい
わざわざ見に来て文句つけるような人は筋違いだし相手にする必要もない
独り言で言ってる分にはどうでもいいけど正式にクレーム出してるとかまである
PCの知識のないライト層まで使うことになったせいで前述のような考えがなくなってる気がする
ウェブサイトは自分の気に入るコンテンツを提供するためにあって気分を害するものは全て許されないものとでも思ってるのだろうか
昔はもっと一般に普及して当たり前のようなものになったらいいなーとは思っていたがその結果がこれなら、面倒なライト層のいない昔のアンダーグラウンド感もあるくらいのウェブのほうが居心地のいいものだったと思う
この１，２か月、仮想通貨界隈の盛り上がりと、暴落後の阿鼻叫喚を眺めながら、不思議な既視感にとらわれていた。
10年以上前、オートサーフが流行し、急速に凋落した頃の雰囲気にそっくりだったからだ。2005年から2006年頃にかけての話だ。
オートサーフとはなにかというと、
インターネット界隈で、オートサーフは、広告を掲載したウェブサイトをウェブブラウザー上で回転させるトラフィックエクスチェンジのことである。したがって、オートサーフは広告を掲載したウェブサイトに大量のトラフィックを呼び込むことができる。メンバーは閲覧するサイト毎にクレジットを稼ぐことができ、このクレジットは、オートサーフの回転に追加することで、メンバーのサイトを広告することができる。オートサーフ業者に料金を支払う外部の広告掲載者は、サイトを追加することができる。
一見して、よくわからない説明かもしれない。あたりまえだ。その理由は後ほど。
ようするに、投資にうとい人間にとっては、オートサーフとは、業者にお金を預けて、ブラウザー上で広告を表示させて放っておくと、預けたお金がたちまちのうちに何倍にもなるという、きわめて魅力的な「投資」話に見えたのだ。
オートサーフ業者のなかで最大手は12 DailyProというアメリカの業者で、ユーザーが$6から$6,000の金額を預けると、12日間で144%の利益が得られると公言して、多数のユーザーを集めていた。
今から見ると、じつにあほらしい話に見えるが、当時はこれがもっともらしい投資話に見えるようなネット上の光景があったのだ。その話も後ほど。
2005年の末頃には雨後の筍のように多数のオートサーフ業者が乱立し、高利率をうたってユーザーを集めていた。
特に利率が高く、リスクも高いサイトはHYIPと呼ばれていたのだが、そのリスクとはどういうものかよくわかっている人はあまりいなかったように思う。
（HYIPの公言する利率がどのようなものであったかの例として、本エントリーの末尾に当時受信したスパムメールを貼っておく）
実際、運営開始当初は高い利益分配報告をしていたHYIPのサイトが、やがて運営を停止し、ドメインごと消滅するという事態は珍しくなかった。
そのようなことが続くと、オートサーフは広告業者からの出稿料金をユーザー間で分配しているのではなく、ユーザーが預けたお金を分配しているだけのねずみ講ではないか、と危惧する人が出てくるのはもっともなことだった。
そしてその危惧は的中した。
2006年2月、SEC（アメリカ証券取引委員会）は12 DailyProを恒久的に営業停止とした。
SECの捜査により、12 DailyProは世界中で30万人以上の投資家から5000万ドル以上を集めた巨大なねずみ講であることが明らかになった。
12 Daily Proの運営者カリス・ジョンソンは逮捕され、12 DailyProは運営停止後、法定管財人の管理下に置かれた。
当然、12 DailyProにお金を注ぎこんでいたユーザーは大混乱に陥った。
法定管財人はその後数年間にわたり、12 DailyProの清算状況をユーザーにメールで報告しつづけたが、ユーザーに戻ったお金はほとんどなかったと思う。
日本のインターネット界隈では、2005年にはオートサーフに関する話題が盛り上がりを見せていた。
各種掲示板では有利なオートサーフ業者に関する議論が行われ、ブログ上で収益報告をする記事が相次いだ。
「楽して高収入」をうたいながら、オートサーフ業者への登録手順を解説し、アフィリエイト収入を得たり情報商材を販売する者が現れた。
そういった人々は、オートサーフのことを、まだそれほど世の中に広がっておらず、知っている者（情報強者）だけが得することのできるおいしい「投資話」だとしていた。
このような「投資話」で読者を煽った人びとは責任を取らず、消えた。
昨年から仮想通貨への投資話がネット上で盛り上がりを見せていたとき、自分にはオートサーフのことが思い出されて、投資する気にはなれなかった。
もちろん、仮想通貨とオートサーフでは、技術的な背景も、行われている投資の規模も全く違う。それはわかる。
だが、仮想通貨が盛り上がりを見せたときの、日本のインターネット界隈での反応、うごめいている人々の素性が、オートサーフ騒ぎの時と、あまりにもよく似ていた。
今回、仮想通貨の暴落を受けて、筋の悪い「投資話」に共通する日本のインターネット界隈の反応を、自分自身の経験則としてまとめておく。
New and Good HYIP!! Auto-Withdrawals!
125% after one day (Auto-Withdrawal)
Plan Spent Amount (US$) Daily Profit (%)
68% daily for 2 days(Auto-Withdrawal)
Plan Spent Amount (US$) Daily Profit (%)
Plan 1 $1 - $100 65.00
Plan 2 $101 - $5,000 68.00
165% after two days (Auto-Withdrawal)
Plan Spent Amount (US$) Profit (%)
Plan 1 $5 - $100 160.00
Plan 2 $101 - $5,000 165.00
攻略wikiっぽくない「自称攻略wiki」を見かけるようになった - シロクマの屑籠
http://p-shirokuma.hatenadiary.com/entry/20171221/1513820193
最近据え置きゲーをやっておらず、スマホゲーとブラウザゲーばかりの増田です。
ウィキペディアをwikiと略すな、は十分周知されているとは思いますが、wiki的な編集過程でない普通の
攻略サイトを攻略wikiと呼ぶな、というのは言われてみるに確かにそうね。
wikiとは何か。
多くのウィキに共通する特徴を以下に掲げる。
・ネットワーク上のどこからでも、いつでも誰でも文書を書き換えることができる。
・文書の書き換えに最低限必要なツールはウェブブラウザのみである。
・ウィキ特有の文書マークアップはHTMLなどと比べて簡潔なので覚えやすい。
・同じウィキ内の文書間にリンクが張りやすくなっており、個々の文書が高度に連携した文書群を作成しやすい。
・大抵は、変更の事前許可を必要とせず、ウィキのあるサーバに接続できる人に開かれている。実際、ユーザアカウントの登録を必要としていないところも多い。
と言われているんやで
２．従来の出版社系ゲーム攻略サイトがwikiを名乗っている系
３．特に増えている新興ゲーム攻略サイトがwikiを名乗っている系
それぞれについて少し語る。
個人のマニアが立ち上げた攻略サイト。新声社や電波新聞社といったプレイヤーもいた攻略本界隈。
友達の兄ちゃんに嘘テク教えられたり、実際は小数点以下の確率で盗める。
こんなゲームにマジになってどうすんの。
企業のネットが星を覆い、電子や光が駆け巡っても、個人攻略できるレベルを超えたボリュームのゲームを
一人で無理ならみんなで情報を持ち寄ろう、ネットは匿名で平等で集合知でウィンウィン。
2chのゲーム本スレのテンプレに貼られているのがこういう攻略wiki。
wikiに貼ってある広告のアフィってwiki開設者に入ってるんじゃね？
真偽は定かではないが、ゲーム攻略wikiは儲かる、他サイトのデータをコピペして作成し、ライバルの方には
デタラメや煽りを書き込んだりして評判を落とす。トップ攻略の地位をもぎ取ればウハウハ、という手法を
世はまさに大嫌儲時代、モンキーDアフィの五武海はちまjinやらおんハム速ニュー速VIPが追放されたり
2ch政府の内紛分裂があったり。
そんな嵐が過ぎて見回してみれば、１型攻略wikiは凋落して、３型の全盛期。
ゲーム単体の攻略も大変だが、リリースされるゲームの数も膨大。
世はまさにガチャゴールドラッシュ、だけど一攫千金でゲーム開発するより、シャベルとジーンズのテンプレで
儲ける方が固い商売だよね。
２．WARNING!! A HUGE BATTLESHIP KADOKAWA IS APPROACHING FAST
そうボスはカドカワなんだ。たつきは帰ってこないんだ。君も人生と向き合うときなんだ。
これが、アレでしょうね。出版社系の。攻略wikiの。なれそめ？初出？元凶？根源？大丈夫？
Wikiサイトっぽい外見してますがライター執筆記事やファミ通企画の攻略動画へのリンク盛り盛り。
一般人はツイッター連携で掲示板とかコメント欄には書けるけど記事編集は無理そう？
基本的にライターに書かせているであろう攻略サイトをwikiと呼ぶのは、SEO有利・プレイヤーに
親しみを持たれるからではないかと思う。が、外注ライターの個別記事をいちいち社内で検収して
からアップロードといっただるいスタイルを取らずに実際にwiki形式で登録ライターが直接編集
しています、ってことかもしれない。
ファミ通WikiはGzbrainが運営。カドカワ傘下で浜村編集長の会社です。
で、出版社系言いますけども１．でちょっと触れたようなかつて攻略本出してた系の出版社は死に体で。
お家騒動で分裂した電撃ＭＷも、富士見書房もファミ通文庫もオタク系は軒並みカドカワの軍門に降り、
時々絶妙なインタビュー記事などを載せる電ファミニコゲーマーもドワンゴ運営。
電ファミWiki
https://wiki.denfaminicogamer.jp
これwikiシステムの貸し出しやってますよ。って形式ですね。
あとは出版社でゲーム関係出してるってなるとVジャンプとかスクエニとかですかね。
本屋行ってもあとはアプリのシリアルコード載ってるような奴と、晋遊舎や三才ブックスのようなのと
wikiを紙に落としこんだ素性のわからない出版社の完全攻略本くらいしかない。
というかね、FF7あたりから10年くらいの、攻略本が売れ行きランキングに載ってきてしまうほどの時代、
アレが攻略本バブルだったんですよ。攻略本の対象ゲームもバンバン売れてたわけですよ。
CDがカラオケBOXブームとかもあってめちゃくちゃ売れてたのと概ね同じ。経済バブルの残り香的な。
３．攻略は再び名人の時代へ
古の昔、連射こそがすべてであり、鋼の定規と16連射が支配する、高橋名人の時代があった。
実際にはハドソン社員の高橋名人はゲーム自体もそれほど上手いわけではないらしいが。
そのハドソン出身の山本大介が作った（※）パズドラがヒットしたけれども、アプリ内には外部の
攻略サイトへのリンクがあったんですよ。ファミ通とAppbank。
これね、パズドラが初めてじゃないとは思うんですけどね、衝撃でした。増田には。
※全くの余談。ゲームは１日１時間という標語はハドソン由来でパズドラでもランダムTIPSで表示される。
ほならね、ペアレンタルロックで１時間制限させてみろって話でね。
ゲームを作ったのは誰か論争、これ法隆寺は誰が建てた、みたいな話になるので難しい。
パズドラは山本Pが手動して作ったが、あのドロップが吸い付く操作性・移動に伴うクリック感ある音と
コンボエフェクトの快感、を実装したコアプログラマーはアプリリリース後に抜けてしまい穴を埋めるのに
２年位かかっていたのではないかと増田は増田は勝手に思うのです。なんでかつうと、パズル操作盤面内へ
の改修がその間ほとんど行われず、イラストとステータス変えたモンスターの追加だけで２年間過ぎて
いったから。間を持たせるためにイベントとか生放送で盛り上げてごまかすぞ、ってニコニコみたいな話。
いや、それでガチャ回るんだから美味しい話だし、ゲーム的にも余計なことしないでくれて平和で良かった
と今は思うけれども。その間に、W、チャレンジ、3DS版、アーケードなどパズドラアプリの再発明で繰り返し
修行してようやく操作に違和感もたせないレベルで盤面システム（十字消し・立て追い打ち・雲・帯・
ルーレットなど）いじれるようになったのかなと。３マッチパズルだけど何か納得いかない消え方（ワロス消し）
についても修正されたのその後なんだよね。
コアプログラマーが重要ってのは拡散性ミリアサの終了事由のインタビュー記事を参照されたし。
指導的地位といえばパズドラのエグゼクティブPであるガンホー森下社長、わしが作ったと言っておりパズドラは
こうして産まれたとのマンガでもそう描かれている。消費者庁コラボhttps://anond.hatelabo.jp/20170719231854
での謝罪の責任者名は森下、それ移行の山本Pの対外的露出自粛も、作った男の主導権争い的な面もあるのでは
ないかとはゲスの勘ぐりですね。極み極み。
閑話休題。
攻略リンクの話に戻ると、ファミ通はわかる、みんな大好きマックスむらいのAppbankは何もんだ？
iPhoneケース販売とかアプリ紹介とかやってるんだって、へえ。
アプリリリース当時はAppストアの規制もぬるく、ダウンロードランキングの売買アプリ（他のゲームインストール
するとゲーム内通貨発行）とか、シリアルコードとかセーフだったんで、単純に攻略データへ誘導すると便利だね、
以上の素敵なサムシングの期待があったのかな。
Appbankはwikiを僭称せずに攻略記事を書いてるようです。
後にパズドラのアンケートでは、攻略の際の参考にするサイトとしてどういうところを利用しているかの問に
ファミ通アプバンの他に、appmedia、gamewith、game8などが選択肢に上がっていた記憶がある。
こういう攻略サイト系、幅広くゲーム攻略してまして、運営は会社組織でやってまして、攻略ライター募集してまして、
ライターには石購入補助金も出まして、何それガキの小遣いじゃないか。
ゲームアプリは随時更新され日々攻略必要、またリリースされる数も半端じゃない。
どれがヒットするかわからないからツバつけておかないと後発では攻略覇権取れない。
きららファンタジアだってぐだぐだから離陸したFGOのように羽ばたくかもしれない。
あるゲームでは充実した攻略情報が載っているサイトでも、他のゲームではテンプレ作って終わりだったりするのは
ライターの層の厚さの違いによるものなんだろうねえ。
そして栄枯盛衰、他サイトにどうしても勝てそうもないとなれば撤退やむ無し。
【FGO攻略wikiからのお知らせ】
2017年8月25日を持ちまして、FGO攻略wikiの更新を停止いたしました。短い期間でしたが、これまでのご利用ありがとうございました。
https://game8.jp/fate-go/144602
これね、一つの攻略サイトは適当でも複数横断して集計すればまともな結果でるんじゃね、と星4鯖配布の時に調べてて
みつけた。ニトクリスもらいました。
https://anond.hatelabo.jp/20170921034548
ああ、終わりってこういう風に来るのか、って微妙な気持ちになったね。
さらに話題転換。
Appbankといえばユーチューバーマックスむらい。ユーチューブの前はニコ生のガンホー公式放送でのメインプレイヤー
もやっていました。彼はそこそこ上手い程度ですがAppbankからはユーチューバーとしてコスケとかが出てきたようです。
ヒカキンもヒカキンゲームズやってますし、先述の攻略サイト運営会社の中にもユーチューブやAbemaTVのタレント事業
手がけてる会社もあり、サイバーエージェントやらGMOと取引あるところもあり、界隈ですなあ。
時代は上手いプレイヤー個人やゲームプレイ動画の攻略に移っていこうとしてるのかなあ。
プロスポーツとしてのeゲームも業界団体が統合？して来年から本格始動みたいですしどうなるんでしょうね。
情熱あるゲーマー有志がボランティアで攻略してどうこう、っていう集合知の善性は容易に横から収奪されて熱量が失われる。
上手い個人はプロゲーマーとか、ユーチューバーとしてマネタイズできる。
ゲーム上級者の増田があったけれども我々凡人は商業の攻略wiki見て満足すればいいんじゃないか。
攻略本は出版社がライターに金出して作って、プレイヤーが金払って買った。
攻略サイトは運営がライターに石援助して、プレイヤーPVで金を稼ぐ。
「そこに何の違いもありゃしねえだろーが。」「違うのだ！」
どこに線をひけばいいかわかる人いる？それ、はあちゅうに教えてあげてね。
増田としては資本がどうであれ有用なデータがあるサイトが検索上位に来てくれればいい。
WELQのように信頼できない情報や、はてなキーワードの未作成ページにランディングすると
いちいちnaoyaは嫌いだけど、と前置きつけながら告訴したくもなる。
嫌儲の問題とか村上隆の金の話https://anond.hatelabo.jp/20170925233933とかしようと思ったけど時間がなくなった。クエスト回さねば。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
僕は、毎日インターネット上の情報を閲覧する。スマホからも、パソコンからも、時にはタブレットからも。ニュースアプリを使ったり、はてなブックマークを使ったり、普通にブラウザーを使ったりなど、情報の入手の仕方は様々だ。
去年か一昨年くらいの話だが、友達がPCで困ったことがあるから助けてほしい、と言われた。実際友達の家に行って助けようとしたのだが、内容の覚え具合が曖昧だったので、友達の家のPCを使って情報を調べることにした。その時に言われたのが、
「え、(タブを)めっちゃ開きすぎやん」って。
当時は8個くらい開いていたのだと思いますが、中学生にとってはおかしいのかな。
情報収集するときは、なるべく様々な視点からの情報を得たいので、1つの話題に最低でも4個はタブを開く。そこに調べた情報の中に書かれている付帯情報も調べようとするので、さらに2個はタブを開く。そして、「あ、じゃあこれはどうだろう」と別の事柄を調べるために、またタブを開く。
ブログの記事を書くときは、情報収集を含めて10個ぐらいはタブを開くことが多い。この記事も、情報収集やこのブログのデザイン変更をしている時に、ふと思いつきで書いたものなので、執筆時にはタブは12個開いていた。
そこに現れた「Vivaldi」というウェブブラウザは、タブをひとまとめにすることができるため、現在愛用している。
GmailやOutlookのようなウェブメールサービスを利用すれば、すべてのデバイスで簡単にメールアクセスとモバイルアプリを提供できますが、それらのメールサービスはあなたのデスクトップでの動作を保証するでしょうか？
今は、多くの人が複数のメールアカウントを持っている。これらのアカウントが異なるプロバイダを使用している場合は、一度に複数のブラウザタブを開く必要があります
便利な場所にすべてのメッセージを集約するだけでなく、優れた電子メールクライアントは、暗号化やカレンダー、RSSフィード、VoIPアプリケーションとの統合などの機能を追加できます。
デスクトップクライアントはメールをローカルに保存することもできるため、オフラインのときにアーカイブされたメッセージにアクセスしたり、貴重なバックアップを提供することができます。
さまざまな電子メールプロバイダと統合されたチャットをサポートする最高の電子メールクライアント
eM Clientは10年近く前から始まっています。その長い開発により、Windows用の最高の電子メールクライアントに発展することができたんや。
無料版は非営利目的の使用と2つの電子メールアカウントに限定されますが、それ以外の場合は有料版とおんなじ。
eM Clientには、Gmail、Exchange、iCloudおよびOutlook.com、タッチコントロール、高速検索、統合カレンダーおよび連絡先のサポートが含まれてん。JabberやGoogle Chatなどの一般的な標準をサポートする統合されたチャットアプリもあり、Outlookのような重量のあるアプリには良い選択肢ですわ。
あなたのメッセージを補う機能が満載されたすばらしいメールクライアント
Mailbird Liteは単なる電子メールアプリではなく、スケジューリング、チャット、ファイル同期、チームワークのためのアプリケーションを追加できるコミュニケーションプラットフォーム全体です。
Mailbirdをダウンロードした後は、Proバージョンの30日間試用版に対処されます。このバージョンは、月末にアップグレードしないことを選択した場合、限定版Light Editionにダウングレードされます。フリー・クライアントには時間制限はありません。
無料のユーザーは、速読、電子メールのスヌーズ、添付ファイルのクイックプレビューなどの機能を忘れていますが、Mailbird Liteは依然として優れた選択肢です。最大3つの電子メールアカウントをサポートし、スピードに合わせて最適化され、起動時に最適です。
セットアップは簡単です。電子メールの詳細を入力すると、Mailbird Liteは必要なPOPまたはIMAPの設定を自動的に見つけ、メッセージのインポートを開始します。あなたのFacebookアカウントに接続することができるので、あなたの連絡先のプロフィール写真であなたの受信トレイを活性化し、Whatsapp、Googleカレンダー、無料のタスクマネージャMoo.do、teamworking app Asanaにリンクすることもできます。
Claws Mailのシンプルなインターフェースは、より自信を持ったユーザーに適した強力な電子メールツールです
Claws Mailは使いにくくはありませんが、独自のメールフィルタリングに耐え、無制限の電子メールアカウントをサポートしたい経験豊富なユーザーに最適です。
ここの他のクライアントとは異なり、ClawsはユーザーにPOP3 / IMAP設定を手動で設定する必要があります。 Gmailを使用している場合は、Googleアカウントの設定を調整して、安全性の低いアプリケーションのアクセスを許可する必要があります。
古くは現代の電子メールクライアントでは、HTMLメッセージを送信するオプションはありません.Clawはプレーンテキストのみですが、不要な機能を省略することで、Clawは驚異的なスピードで動作します。その検索機能は特に優れており、プラグイン経由でも拡張できます。
それは最も美しい電子メールアプリケーションではありませんが、Clawsはあなたがスタイルを超えて物質を評価するならば、素晴らしい自由選択です。定期的に更新されているため、バグはすぐに除かれます。
すべてのデバイスでメールを管理するためのワンタイム設定の無料メールクライアント
Inkyの無料版はWindows、Mac OS X、およびAndroidで利用でき、ワンタイム設定は3つのプラットフォームすべてで使用するのに最適なメールクライアントになります！
電子メールクライアントをダウンロードしてインストールしたら、Inkyアカウントを作成するよう求められます。これにより、すべての電子メールアドレスがリンクされ、POPおよびIMAP設定を設定することなく、Inkyがインストールされた任意のデバイスからアクセスできるんです！
一度登録すればセットアップは簡単カンタン♪ 各アカウントのユーザー名とパスワードを入力すると、残りの部分をInkyが処理してくれちゃう。
日常的に使用されるInkyは優れた自動タグ機能、メッセージタイプ（個人、定期購読、ソーシャル、ノートなど）のインテリジェントなフィルタリング、デバイス間の非常に高速な検索とクラウド同期でわんだふるん♪。
Windows 7以降を使用していて、特定のメッセージやスレッドを見つけようと多くの時間を費やしている場合、Inkyは膨大な時間を節約できちゃうの！
優れたOperaウェブブラウザの背後にあるチームからの柔軟なオープンソース電子メールクライアント
Operaの開発者は、電子メールを常に優れたブラウザの重要な機能とみなし、無料の電子メールクライアントであるOpera Mailの開発に多大な努力を払ってきました。
その機能には、メッセージテンプレート（特に業務用に便利）、メッセージのフィルタリングとソート、タイプ別のメッセージソート、さまざまなカスタマイズオプションがあります。
クライアントはRSSフィードもインポートするので、Feedlyや欠けているGoogleリーダーなどのWebアプリケーションの代わりになります。
Mozillaから期待されるように、たくさんの機能があり、無料の拡張機能を利用することもできます
Firefoxと同様に、無料の電子メールクライアントThunderbirdはMozilla Foundationによって作成されました（しかし、2つの開発はそれ以来分離されています）。 ウェブブラウザと同様に、その機能は、サードパーティのアドオンの膨大な範囲で拡張され、強化されます。
優れたビルトイン機能には、電子メールには大きすぎるファイルと、電子メールと一緒にRSSニュースフィードを読む機能があります。
セットアップは簡単です。 ほとんどの現代の電子メールクライアントと同じように、必要なのはあなたのユーザー名とパスワードだけで、Thunderbirdは残りのものを処理します。
Windows Live Mailは、Windows 8および10のMailアプリケーションに取って代わられた2012年に最後に更新されました。ただし、Live Mailの比較的昔ながらの外観にもかかわらず、2つのプログラムはほぼ同じです。
Windows Live Mailは、私たちを含む多くの電子メールユーザーがより現代的ですが、最小限のデザインを好む3ペインのレイアウトを提供します。 RSSとクラウドベースの電子メールとPOP3をサポートし、添付ファイルを送信したり、複数のアカウントで作業したりすることが容易になります。
マイクロソフトのやり方が気に入っても、ウルトラスリムなWindows 10アプリケーションがあまりにも制限されているのを見つけたら、従来のWindows Live Mailは賢明な選択肢です。
*
freeeがマネーフォワードを訴えた事で、その特許自体を批判するコメントが多く見られる。
これは、ニュース記事などでも「文字列を元に自動仕分けする技術なんて世の中的にはもう何十年も前から存在するでしょ…」
といったように発明でもなんでもないとする論調が多い為だと思う。
http://cards.hateblo.jp/entry/freee-moneyfoward-saiban/
しかし、本当にこれが当たり前の技術なのか、特許審査官は当たり前の事に簡単に特許を認めるのか。
そもそも、「文字列を元に自動仕訳する特許」という広範囲に権利が及ぶ基本特許が取れたというのは正しい認識なのか。
http://astamuse.com/ja/granted/JP/No/5503795
請求項1
クラウドコンピューティングによる会計処理を行うための会計処理装置であって、ユーザーにクラウドコンピューティングを提供するウェブサーバを備え、前記ウェブサーバは、ウェブ明細データを取引ごとに識別し、各取引を、前記各取引の取引内容の記載に基づいて、前記取引内容の記載に含まれうるキーワードと勘定科目との対応づけを保持する対応テーブルを参照して、特定の勘定科目に自動的に仕訳し、日付、取引内容、金額及び勘定科目を少なくとも含む仕訳データを作成し、作成された前記仕訳データは、ユーザーが前記ウェブサーバにアクセスするコンピュータに送信され、前記コンピュータのウェブブラウザに、仕訳処理画面として表示され、前記仕訳処理画面は、勘定科目を変更するためのメニューを有し、前記対応テーブルを参照した自動仕訳は、前記各取引の取引内容の記載に対して、複数のキーワードが含まれる場合にキーワードの優先ルールを適用し、優先順位の最も高いキーワードにより、前記対応テーブルの参照を行うことを特徴とする会計処理装置。
この請求項を見ればこの特許が権利を主張している範囲がざっくり分かる。
特許の仕組みは、請求項に記載されている事が全て満たされた場合のみ自分の特許範囲だと権利主張できる。
これだけ特許範囲が限定されると、「文字列を元に自動仕訳する」仕組みがあればどんなシステムにでも権利主張できるものではない。
つまり、これはfreeeがコア事業としているクラウド型会計サービスが最大の強みとする「自動仕分け機能」に特化して特許取得したものと言える。
そして、この特許が出願されたのは「2013年10月17日」。
この時点で、クラウド型会計サービスで自動仕分けを行うという事が当たり前の仕組みだったのか、前例があったのかという事になる。
当然、審査官はその出願日を起点として過去に同一または類似の公知文献が無いかを調査している。
まだクラウドで会計処理をするという事が一般化されていない時期に、ベンチャー企業がクラウド型会計サービスで最もメリットとなりえる
「自動仕分」を知財化し、後追いサービスを牽制する戦略を取るのは当然とも言える。
むしろ、もしこの特許が国際出願されており、海外に対しても権利化できるのであれば、今後海外展開した時に海外のクラウド型会計サービスと
クロスライセンスを契約する際のカードにもなると思うので、取れる範囲はどんどん取っておくべきだと思う。
が大きいと思う。
もしこの特許が当たり前だというのであれば、出願日時点より前に公知となっていた文献やサービス・システムを明示し訴える事で
特許を無効化できる手続き手段も用意されている。取得できた特許の権利は絶対ではない。
何十年も前からある当たり前の技術だと言う人は、是非出願日以前に遡ってこの特許範囲と同一または類似する文献を明示してみて欲しい
（非公式）二次創作について検索避けを部外者から強要されて従ういわれはない。ナマモノについては、わたし（筆者）のメインジャンルではないうえ、少々ややこしくなるので、保留とする。
「配慮」という言葉が、「検索避け」の強要の理由として使われているように思う。アダルトなエログロや、原作にない性愛の関係などを描いた二次創作物を見たくない「だれか」への配慮だ。
なるほど確かに、見たくない人もいるだろうな。ウンウン。そうかそうか、不快な思いをさせてしまうのか。
いや、待て待て。つまりそれはアレか？ 「だれかが不快な思いをするから検索避けをしてくれ」と言うのか？ 「だれかに不快な思いをさせたくないから検索避けをしてくれ」？
冗談じゃない。キリがない。万人に受け入れられるものはない（そんなものがあるなら教えてほしい）。これがまかり通るとき、検索しうるあらゆるものが検索避けをさせられているわけだ。
「刀剣乱舞」知ってる？ 略してとうらぶ。伝説の刀剣やらが付喪神になって（擬人化して）男性の姿をとって、刀剣男士となったんだ。わたし「実在したものを題材にしている作品の二次創作だから云々」と検索避けを押しつけるのを山ほど目にしてきたけれど、それなら、そもそも「刀剣乱舞」自体に検索避けをさせるべきじゃない？ 「加l州l清l光」って。もちろん、DMMのブラウザゲームのページにはアクセス制限もさせてさ。だって、刀剣を勝手に擬人化して、あんなことやこんなことを言わせて、あまつさえ戦わせている！ 不快な思いをするひと、いると思うんだけどな。
「家庭教師ヒットマンREBORN!」は？ ごく普通の中学生だった沢田綱吉ことツナの前に殺し屋リボーンが現われて「おまえはマフィアの十代目だ」なんていう。かれに家光という父親がいることからわかるように、名前の元ネタは徳川家なんだ。どう？ 徳川綱吉のことを調べようとしたのに、沢田綱吉ばかりが出てくる！ なんていうことを不快に思うひとは、絶対にいないの？ 名前を変えさせるべきじゃない？ あの主人公。
いやいやいや。キリがないよね。田中、鈴木、佐藤。（申しわけないが）このありきたりな姓の持ち主はありふれていて、創作物に登場することも、ままある。一郎、太郎、幸子。いるぞ。
言っとくけど、違わないからな。これは「アダルトなエログロや、原作にない性愛の関係などを描いた二次創作物を見たくない」のと違わないんだぞ。根底には「不快感」があるんだ。この配慮の点で検索避けを求めるということは、「嫌な思いをするだれかのために検索避けをしろ」ということと、違わないからな。
この「配慮」の面から検索避けを強要するひとたちは、世界のあらゆる人の不快感を解消するため、あらゆるところへ検索避けを呼びかけてくれ。ぜひに。
トランプを探しているの。カードゲームよ。でも、あら、なんということかしら。わたしの大嫌いなドナルド・トランプばっかり出てくるわ！ 嫌だわ。不快だわ。
「二次創作は実質違法行為なので、公式に見咎められないよう隠れて活動しなければならない」というアレ。
著作権。二次創作とのことで、TPPとともに話題になった。TPPに参加すると、著作権の親告罪がどうのこうのというあれそれ。まあ今のところ、公式が突きつけるまで、それは罪ではないということになっている（はずである）。
はい終了。
公式に見咎められないように……そうだね。公式の利益を損なうのはよくない。
でも、判断するのは公式だ。「見咎められないよう隠れて」など、まるでやましいところがあるようではないか。
公式の指示に速やかに従う。これだけでよいだろう。
ところで、アダルトとの境目にはのれんがある。物理的なフィルタだ。わたしたちは、物理フィルタのないところに、フィルタを見ることはできない。
まだ、その技術は普及していない。ARを目にし続ける将来は訪れるかもしれない。そうしたら、見たくないものを見なくてよくなるかもしれない。たとえば、露出度の高い女性の水着の広告だとかなんだとか。
でも、今はない。だから店側が物理的なフィルタとしてのれんを設け、年齢と覚悟を問うわけだ。おそらく。
で、検索避けを強要する舞台がどこかというと、インターネットだ。あなたのコンピュータだ。フィルタがかけられる。お互いに。けれど、あえて「不快に思うかもしれないだれか」のために、作者がのれんを用意する必要はない。どうしても見たくないものなら、それは見たくないひとが、見ないために努力をするはずだから。コンピュータは、見たくないものを見ないことができない舞台ではない。
法的に年齢制限をかけるべきあれそれに検索避けを求めるのは、わかる。だが、それについては、検索避けより直接的な手段をとるべきだと思う。ここではおいておく。
そして、それ以外の「見たくない」ものについても（コンピュータでは）、検索避けより直接的な手段をとるべきだ。検索の仕方を工夫する（not検索とか）とか 、NGワードを設定するとか。やり方は、ぜひ自分で検索してほしい。「ウェブブラウザ ngワード」とか。で、そうする手段がまだ用意されていないと思うなら、自ら開発するか、おとなしく待つといい。それすら我慢できないなら、もうやめたほうがいいと思う。インターネットが向いていないかもしれない。
全世界の、なにかを不快に思うだれかのために、調べたやり方を共有すれば、より具体的に不快感を減らせるだろう。
（そのために、わざわざ嫌なものを一度は見なくてはならないのかとか文句を言うひとは、「食わず嫌い」の意味を調べてくれ）
もちろん、公式からなんらかの対処を求められたときは、それに速やかに従いますよ。でも、それまでは、なんら疚しいところのないわたしは、堂々と二次創作をする。公式（原作）への感謝も忘れずに。いつもいつも原作を、たのしませてくださって、ありがとうございます。
http://anond.hatelabo.jp/20161012195410
子供の出会い系サイトとのことで、色々エグい内容が書かれている。ただ、さすがにちょっと信じがたい。
記事でも書かれているが今どき児童ポルノ画像が堂々と貼られている場所があるってのが信じがたいし、直接画像が見れるのに警察が動かないのも首を傾げる。何より謎なのが、そんなサイトがあるのにロリコンが騒がず記事にしても無視されてるって状況が謎すぎる。本当なら絶対２ちゃんで炎上する案件だ。
なので、実際に行って確かめてみた。
記事で書かれている3DS専用掲示板と、その管理者が運営してる外部２ちゃん風サイトは割と簡単に見つかる。
児童ポルノ画像で溢れかえっているように表現されているが、結論から言うとそのような画像は一枚もなかった。
隠しページもあったけど（懐かしいノリだな！）そちらも何もなし。
２ちゃん風サイトのほうは、とにかく糞スレに糞レスが書き込まれてるだけで画像を貼ってるやつなんかいない。
3DS専用掲示板はどんなシステムかというと、オープンなスレッドで3DSのフレンドコードを交換し、3DSのメッセージで共有したパスで鍵付きスレッドに引きこもるって感じ。
専用っつーけど3DS関係ないねこれ、たまたま子供の持ってるネット端末が3DSってだけで他のハードでも可能だな。
ともあれこっちの3DS掲示板は眉をひそめたくなるスレッドが目白押しで、特に鍵付きスレッドではエロチャットや画像の交換をしてる気配があり、いかがわしい空気が漂ってる。
しかし当然当事者以外は中を確認することはできないので疑惑でしかなく、オープンスレッドを見るかぎり中学生が猥談しつつ「学校だりー」とか「宿題めんどい」とか駄弁りながら、カゲプロとか戦国BASARAの話とかしてたまに鉛筆書きのオリキャラの画像をアップするみたいな場所らしい。
あれだな、子供の頃近所にあったエロ本秘密基地の全国版だなこれ。
管理人がその手のスレッドを削除して証拠隠滅したのかとも思ったが、それもちょっと違う気がする。
何が違うのかって言うとこの２つのサイト、とにかく閑散としてる。
時間を置いて何度か見たけど、まともに書き込みがあるのは極一部のスレッドだけで、その書き込みも常連らしいコテハンのくだらない馴れ合い糞レスばかりだ。
新しく立つスレッドも殆どないし利用者も少ないように見える。良くも悪くもゴルスタのようなダイナミズムは欠片もない。
まあ、管理者は間違いなく変質者のたぐいだし、鍵付きスレッドでは子供同士が顔を晒してエロチャットしてるっぽいので子供を近づけるべきじゃないサイトなのは確かだ。
そして勘違いしてる人が多いようだけど、どちらのサイトもPCやスマホでも普通に使えるわけで任天堂は基本関係ない。元記事では3DSでエロチャットしてるように書かれてるけど、そういう事ができないよう3DSのフレンド機能は制限が多く貧弱に作られてる。問題なのはブラウザなのだ。
全国の親御さんに伝えるべきは、小中学生のゲーム機はペアレンタルロックでウェブブラウザの使用を制限しときましょうってことかな。
追記
一晩立ったが3DS画像掲示板のほうは管理者が削除したようだ。
すでに見れないが、自分の見た限りだと児童ポルノなどは存在しない、子供の多い下品な掲示板だった。少なくとも表面上は元記事にあるような違法な画像が溢れるような場所ではない。
ただし、鍵付きスレッドの中では画像ありのエロチャットがあったようで、実際オープンなスレッドで鍵部屋でエロチャットしようみたいな誘いも見受けられた。外から見るぶんには疑惑でしかないが。
管理者が権限を使って覗き見して画像を収集することも、多分やっていただろう。
もしかしたら告発者の言うような悪い意味で活気のあった時期もあったのかもしれないが、自分の見たものと告発内容は完全に別物だった。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
RT 何度も言って申し訳ないのですが、引用RTは呟き元の相手に通知が表示されるのです。あなたはTLに現れた事象について述べたつもりでも、呟き元にとっては｢いや知らんがな｣の文句を言われたような状態になることがしばしばです。目の前の呟きは無料コンテンツではなく、生きた人間のそれです
https://twitter.com/yosinotennin/status/732882497944485889
何故こんなに何回も言うかといえばですね、こういったことが重なって興味深い・楽しい呟きをする方々（大抵フォロワー数が多い皆さん）が嫌になって呟かなくなってしまうとツイ廃としては困るのです。｢引用RTは相手に通知がいく｣とご記憶いただければ幸いです。
https://twitter.com/yosinotennin/status/732883206601482240
一応わからないなりにまとめると、
1. 引用RTを使うな（公式RTを使ってその後ツイートしろ）
3. 相手に通知が行くとそれが嫌になって呟かなくなってしまう
ということらしいのだが。
相手に通知が行くのは公式RTでも行くし、そもそもそれはウェブブラウザとか公式スマホアプリで見てるからだろ。
まあそれはいいとしても、「相手に通知が行くから控えろ」？？？？？？？？
公開されているツイートを用いて意見をいうことをやめろって？？？？
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、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 に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ 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 ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (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 は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。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 に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の 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 がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
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 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
