  |
はてなキーワード: ウェブブラウザとは
[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. お問い合わせ
本利用規約に関してご不明な点がある場合、本サービスにおける個人情報の取り扱いに関するご質問・苦情・ご相談等がある場合は、お問い合わせフォームよりご連絡ください。
以上
＊はてブは一つの記事や話題に対して様々な意見が集まるページがメイン。個人のページはサブな感じ。
＊ツイッターは個人のページがメインで、一つの記事や話題に対して様々な意見が集まるページはハッシュタグやキーワードで検索した場合に生まれる副次的なもの。
＊はてブには「非表示」という機能はあるがブロックに相当するものはない。
はてブはかつては先進的な言論が集まる面があった。しかしその後ネトウヨが流入して言論の質はツイッターと変わらなくなった。そうなると、脳が腐っているとしか思えないネトウヨが大嫌いな自分にとっては上記の特徴は不快でしかなかった。そのほか、
＊はてブは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画像掲示板のほうは管理者が削除したようだ。
すでに見れないが、自分の見た限りだと児童ポルノなどは存在しない、子供の多い下品な掲示板だった。少なくとも表面上は元記事にあるような違法な画像が溢れるような場所ではない。
ただし、鍵付きスレッドの中では画像ありのエロチャットがあったようで、実際オープンなスレッドで鍵部屋でエロチャットしようみたいな誘いも見受けられた。外から見るぶんには疑惑でしかないが。
管理者が権限を使って覗き見して画像を収集することも、多分やっていただろう。
もしかしたら告発者の言うような悪い意味で活気のあった時期もあったのかもしれないが、自分の見たものと告発内容は完全に別物だった。
