  |
はてなキーワード: Cookieとは
おそらくテレビCMや街に貼られたポスターには厳密な決まり事があると思われる。
そもそもWEB広告にはそういった表示方法や表現の決まりごとを定めたガイドラインって無いのかしら？と思って軽く調べてみた。
■インターネット広告倫理綱領及び掲載基準ガイドライン （http://www.jiaa.org/download/JIAA_rinrikoryo_keisaikijyun.pdf）
本ガイドラインは、本協会がこれらの必要性を認識し、インターネット広告の健全
な発展のため、インターネット広告倫理綱領を制定し、さらに、その趣旨に基づき、
とあるので、会員社一覧（http://www.jiaa.org/about/memberlist.html）にある271社はこのガイドラインに基づき広告制作・掲載を行っていると思われるが、このガイドラインは指針として定められたもので、参加各社が独自に定める広告掲載基準が優先されるとのこと。
１ユーザーとして気になるのは「誤操作を期待する悪質な表示方法に規制はあるのか」「過剰な性表現はどこからがアウト・セーフライン」か、なのでそれらしい所を抜粋する。
・ 消費者等を騙したり、脅したり、欺もうしたり、惑わせたり、不安にさせたり 14
するもの。
とある。
■読者を増やすためだと言えど…電子コミックの過激なバナー広告について議論（http://otakei.otakuma.net/archives/2017012801.html）
上記のように「エロ」「グロ」ショッキングなシーンを切り取った漫画のバナーもたくさんある。
性に関する表現が露骨なもの、 醜悪、残虐な表現で不快感を与えるもの、には当たらないのだろうか。
■スマホの「エロ広告」はなぜ許されている？（https://lmedia.jp/2014/10/09/57020/）
結局法律で規制出来るものでもないし、各事業者団体や広告掲載サイトの自主規制に頼るしか無いらしい。
美少女キャラが胸をさらけ出し惚けた顔で「はやくきてっ…♡」とか言ってようが、
伏せ字で「ブスのま○○に…？！」の見出しとともにセックスしてようが、クリックする人が居て、その広告に一定の効果がある以上規制はされないんだろうなあと思う。
「誤操作を期待する悪質な表示方法に規制はあるのか」については、特にガイドラインに書かれてなかった。
・ユーザーのパソコンに無断でソフトウェアがインストールされる。
・ページが他の点で AdSense プログラム ポリシーに違反している。
・ページが著作権で保護された第三者のコンテンツを無許可で配信している。
・このウェブサイトは、情報の開示およびパーソナライズド広告や Cookie の使用に対するエンドユーザーからの同意の取得（法律で義務付けられている場合）に関して、Google の EU ユーザーの同意ポリシーを満たしていません
おそらくポリシーを違反していれば配信停止なり何らかの処置があると思われる。
「ページに広告のクリックを誘導する内容が含まれている。」とあるので、誤タップを狙って画面上から降りてくる、閉じるボタンを押そうとすると間違ってクリックしてしまう場合は報告出来るはず。
各社広告バナー右上なり左上のinfoマークをクリックすると「広告に関するご意見・ご感想フォーム」に遷移出来るものが多い。(無いものもある！)
「広告の表示方法が不適切」「広告画像、文言が不適切」などの選択項目が用意されているがあまり期待しないほうがいいと思う。
バナー配信や広告掲載の際に何らかの審査があるはずで、配信されているバナーや媒体は審査を通ってるんだよね。
そのインターネット広告の会社がそれで問題ないって倫理観だからしゃーない。
過激な広告の報告・規制が機能していない以上、ユーザーとして出来るのはアドブロックを入れることぐらいなんだけど、
倫理的に正しく運用されている広告まで完全にシャットアウトしてしまうのはコンテンツのタダ乗りになるんじゃないか？という気持ちもありつつ、まあWEB広告が正しく運用されればアドブロック入れないしねっていう。
テレビCMのように数多くの人の目に触れるものでも無ければ、ポスターのように公共の場で不特定多数の目に触れるものじゃなかったんだろうけど、これだけインターネットやスマートフォンが普及して来た今、もう看過出来ないと思う。
各社の自浄に期待したいところだけど、
https://anond.hatelabo.jp/20130927152907
https://anond.hatelabo.jp/20181101164747
https://anond.hatelabo.jp/20181101180741
たぶんわかった。ログインURLが新しくなったんだ。つまり、こう変えるべき
LOGIN_URL="https://hatelabo.jp/login"
cookie="${HOME}/cookie"
それと個人的に引っかかったのは、
--post-data=...
の行。mode=enterアンドbackurl みたいな感じになる。注意書きにあったけど混乱してしまった。スーパープレ記法つらいね...
https://anond.hatelabo.jp/20181102144850
ふーむうまくいかないか... Windows の環境がないから力になれるかはわからないが…
あと > も ＞ に変えてるけどいいのかな。
をHATENA_IDなどを書き換えて試してみて。実行するとターミナルにHTMLがズラッと吐かれて
これでうまくいかないなら、wgetが正常に働いてないのか… MSYS2っていうのがあるんだ？ 詳しくはわからないが windows subsystem ？で ubuntu を動かすことができるはず。そっちでやってみるのもいいかもしれない。
個人的には、いつでも全部消してスッキリできるのは気が楽になるので助かってる…
無事消せたようだ。
今回は、オブジェクトの使い方＝オブジェクト指向プログラミング（OOP）を学ぼう。
などの分類があります。
ここではクラスベースのOOPを取り上げる。学習時間を短縮するために、Javaよりも簡単なPHPでOOPの基本を勉強してみよう。
PHPは誰でも手軽に使えるように工夫された、軽量なプログラム言語です。
WindowsパソコンでPHPを使うために、XAMPPというソフト（無料）をインストールしよう。
XAMPPにはいくつかバージョンがあるけど、ここではUSBメモリに保存できる「ポータブル」を使ってみよう。
↑このページにある「xampp-portable-win32-7.2.10-0-VC15.zip」をダウンロードして、ZIPファイルを展開します。
解凍して出てきた「xampp」をCドライブ直下にコピーしてください。
Port(s)が「80,443」と表示されたら、XAMPP上のApache（Webサーバーソフト）が起動して、PHPが使える状態になってます。
（Apacheを止めるときは、「Stop」ボタンをクリックします。）
phpとは - はてなキーワード http://d.hatena.ne.jp/keyword/php
<?php
?>
（プログラムのソースコードを増田に直接書くと、エスケープされて違う文字になるので、上の例では一部文字を置き換えてある。）
（上記の表示の中で、全角文字の不等号「＜」「＞」を半角文字の不等号に置き換えて下さい。）
（増田はプログラムのコードを貼付けられないのか。不便だな！）
PHPの教材は、本やネット上の記事、動画などたくさんある。自分で分かりやすいものを探して読んでみよう。
3分程度の動画が30個＝90分。最初は内容を理解できなくてもいいから、とりあえず全部一通り見てみよう。（1巡目は雰囲気だけつかめばOK）
2巡目以降は分からないことがあったらノート等にメモして、後で１つずつ解明していこう。
著者あとがき
私はGitを学ぶのに、実はとても苦労しました。それと同時に、「きっと同じように困っている人が他にもたくさんいるはずだ」と考えました。「理解するのに数日かかることを、短い時間でパパッと学べるコンテンツを作りたい」そう思いつき、「マンガでわかるGit 第１話」を個人サイトにて公開したところ、いきなり、はてなブックマークで800ブックマークされました。
“つまづきポイント”を先回りするために
私は、Gitを使い始めて以降、わからないことがあったら「つまづいたことノート」に書いてきました。なお、本書の執筆にあたっても、日々勉強しながら解説を書くという形でした。わかばちゃんが「なんでこうなるの？」と疑問に思う部分は、私が過去につまづいた部分です。
（今回は、PHPの準備、PHPの基本文法の理解までで終わってしまったorz）
（URLのリンクを10個以上貼ると、日記が書き込めないみたいなので、増田では記事を分割せざるを得ない。）
次回は、OOPに関係している内容（#18～#24）を一緒に確認してみよう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備 ←★今ここ★
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
：
http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session
と厳しい叱責を受けたため、無能の見識を書いてみた。
「聞くは一時の恥、聞かぬは一生の恥」のとおり、
せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存
作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)
確認している間に1時間はかかるからいいやと思ってしまっていた
師はきっとJWT生成直後3秒でユーザーが
と気づいて通報
そして師が2秒で
「これは、セッションハイジャックだ！」
と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している
これは確かにJWTだと厳しそうだ
セッションを任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか
(師はログインを即座に検知してセッションを切れるから問題ないのか)
とにかくアカウントロック機能を作れば上記の懸念全てにきれいに対応できそうに見えている
この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える
これはまずい、自分の今までの見識の甘さを思い知らされた
keyは初回に設定したのみで、定期的な交換を勧める文が見つからない
私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか
JWTはhash化してつないでいる前提で
解読時間は下記を参考に、計算はwindows10の電卓アプリを用いて手動で行った
https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83
英数字大文字小文字で約60の時は10桁で20万年と書いているが
現代の解析技術は20万倍は速度が出ると仮定して1年として計算する
日本語に直すと60京4661兆7600億年かかる計算となった
実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ
そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか
私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる
まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと
JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークンは実装しなかったことを告白しておく
そのためapiサーバで上記前提で用いた場合に考えたことを書く
webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく
では危険で
JWT送信→セッション(cookie形式?)送信切り替え→セッションからuser_id取得
とりあえず思いついたのは下記だった
tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能な識別子)が含まれる
httpsで通信するのでパケットキャプチャによる傍受は不可能と思っていた
(httpで通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)
0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない
というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので
JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった
※余談だが、たまに送る回数が少ない方が安全という
攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた
(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)
その前提のため、わざわざ
JWT送信→セッション(cookie形式?)送信→セッションからuser_id取得
で接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる
つまりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった
つまりcookieだろうがjwtだろうがidとpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら
JWT→user_id
でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメントの発言に至った
ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが
セッションにするメリットとして唯一思いついているのは任意にサーバ側でセッションを切れることだが
それを指していたのであろうか
余談だが、ブコメの雰囲気に日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)
というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが
結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので
正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている
強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか
でも暗号化したらよいのでは、と思った
expを適切に設定しつつ、必要ならアカウントロック機能を入れる
(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)
少なくともapiサーバ→ネイティブアプリに関して、セッションIDを含めても危険性は変わらない
正直webアプリでも大して変わらんのでは、と思っているのは内緒である
前提として私は女で漫画が好きなんだけど
twitterとか見てるとバンバン漫画とかスマホゲーとかの広告が出てくるわけ
それがかなりの確率（主観）で女の性的なところが強調されてる画像なんだよ
女の尻どアップだったり、それどころかセックスしかけだったりしてたりした後だったり
いやもーーー勘弁してくれーーーーー
女向け漫画も男向け漫画も女の性的なところを強調する広告出してくるのやめてくれ
マンガアプリとかでも、実際使ってるやつの広告が出てくるときあるんだけど、
いやおめーー女の乳や尻がメインじゃないすげーいい漫画いっぱいあるのになんでそのシーンだけチョイスしたっていうやつ多くてしんどい
分かるよ、エロは人を惹きつけるよ。私もエロは好きだよ。こないだエロ漫画買ったし
けどそれを心構えしてない時にドーーーンバーーーーーンって出してくるのが心に負担なんだよ
それが何度も何度も繰り返されてしんどいんだよ
なんで「女といえばエロだよね！！！」って感じで女のエロい画像を広告に使いまくるんだよ
見ててつらいよ、女が性的に搾取されてたりいじめられてたりする漫画の広告つらいよ
誰が最初に潮を吹くかゲームとかそういうの、いきなり広告で出すのやめてくれよ
誰かがそういうのを好きなのは分かるし誰かに需要があるのは分かるから、嫌いな人がそういうのを一括で拒否できる公的なやり方が欲しいよ
話がずれるけど、男の性的な部分が強調された広告ならいいのかっていったら、それはそれでしんどいんだろうなと思う
なにせこっちは性的なこと考えてない時に「はーーーーいセックスでーーーーーす！！！！！！！！」っていきなり広告ぶち込まれててさ
いや私のテンション的にいまセックス匂わす系はお呼びじゃねえんだわってかんじなのさ
だから女でも男でも組み合わせがヘテロでもホモでも性的なのをいきなり流されるのがしんどいんだろうけど
実はそこに更に「性的なのは女に偏ってる」っていう私の観測が入って、なんで女だけなんだよっていう主観的なムカつきが混ざってて、今はしんどいんだろうなと思う
あと私の性的なことを常に求めているわけではない性質とか混ざってさ
うーーんこのあたり支離滅裂でごめんね
更にずれるけどギスギスした追い詰められてる系漫画の広告もしんどいよ
人類みんなバトルロイヤル系漫画やいじめ復讐漫画が好きなわけではないんだよ
何かのつらさを全面に押し出す広告ばかり流れてくるのはしんどいんだよなあ
追記
twitterのクライアントについて提案してくれてありがとう。twitter好きだからさ、「広告で金稼いで長生きしてくれよな！」と思って公式のアプリを使ってたんだわ。けどなんかもうこの広告見続けるの限界かなって思ったので教えてもらったやつに乗り換えようと思う。
あとウェブブラウザに関してはアドブロック入れてるんだ。けど広告はすり抜けて表示されるし、cookie制限？とかで通販とか色々やりづらくてさ、それも難儀してる。アドブロックを提供してる会社のウェブブラウザも入れたよ。あれ9割広告非表示にしてくれてありがたいよ。けど望ましい広告まで制限かけちゃうからさ、それはそれでどうかと思うんだよね。広告すること自体は悪くないじゃん。自サイトに広告載せることで頑張ってるサイトはどーなんのかなーとかさ、利用者として申し訳なさあるんだよね
なんていうかさ、個人の努力で嫌な広告ガードするのもいいんだけど、それって結構疲れるし知らない人はノーガードになっちゃうじゃん。いろんな人がネット使うわけだしさ、もっと楽に「ごめんこの広告無理だわ」ってやつを見たくないボタンみたいなの押したらそれに類似した広告大体現れなくなるみたいなの欲しい。好きなものを見てる時に突然現れる苦手なものから逃げる方法が欲しい。私インターネット広告の仕組みよくわかってないから馬鹿なこと言ってるんじゃねーかなと思うけどさー
再追記
文中に出した「ホモ」って単語についてなんだけど、「組み合わせがヘテロでもホモでも」って書いてる通り、ヘテロ（異なるもの同士）ホモ（同じもの同士）って意味でさ、高校の生物の授業で出てくるヘテロ接合ホモ接合と同じ感覚で使ったんだわ。
別に誰かを貶めたいわけじゃないんだよね
けどもしかしてこういう使い方も今ってだめなのかな？ホモって単語使った時点でだめなのかな。不勉強でわからないから今度本とか読んでみるわ。指摘してくれてありがとね
Google は、すべてのユーザーによりよいサービスを提供するために情報を収集しています。よりよいサービスの提供のために行うことには、お客様の使用言語などの基本的な事項を理解することや、お客様にとって最も役に立つ広告はどの広告か、オンラインで大切な人々は誰か、おすすめの YouTube 動画はどれか、などの複雑な事項を推定することが含まれます。
お客様からご提供いただく情報 たとえば、多くの Google サービスでは、Google アカウントのご登録が必要です。ご登録に際して、アカウント情報として保存する個人情報（例えば、氏名、メールアドレス、電話番号、クレジット カードなど）の提供をお願いしています。Google が提供する共有機能をすべてご活用いただく場合は、公開される Google プロフィールを作成していただくようお願いすることもあります。これには、名前や写真などを掲載することができます。
サービスのご利用時に Google が収集する情報 Google は、ご利用のサービスやそのご利用方法に関する情報を収集します。たとえば、YouTube で動画を再生された場合や、Google の広告サービスを使用しているウェブサイトにアクセスされた場合、Google の広告やコンテンツを表示または操作された場合などです。これには以下の情報が含まれます。
端末情報
Google は、端末固有の情報（たとえば、ハードウェア モデル、オペレーティング システムのバージョン、端末固有の ID、電話番号などのモバイル ネットワーク情報）を収集します。Google では、お客様の端末の ID や電話番号をお客様の Google アカウントと関連付けることがあります。
お客様が Google サービスをご利用になる際または Google が提供するコンテンツを表示される際に、サーバー ログ内の特定の情報が自動的に収集および保存されます。これには以下の情報が含まれます。
お客様による Google サービスの使用状況の詳細（検索キーワードなど）
電話のログ情報（お客様の電話番号、通話の相手方の電話番号、転送先の電話番号、通話の日時、通話時間、SMS ルーティング情報、通話の種類など）
端末のイベント情報（クラッシュ、システム アクティビティ、ハードウェアの設定、ブラウザの種類、ブラウザの言語、お客様によるリクエストの日時、参照 URL など）
お客様のブラウザまたはお客様の Google アカウントを特定できる Cookie
Google サービスをお客様がご利用になる場合、Google は、お客様の現在地に関する情報を収集して処理することがあります。Google は、IP アドレスや GPS の他、各種センサーから Google に提供される近くの端末や Wi-Fi アクセス ポイント、基地局に関する情報など、さまざまな技術を使用して現在地を判定します。
固有のアプリケーション番号
サービスによっては、固有のアプリケーション番号が割り当てられています。この番号とお客様のインストール情報（オペレーティング システムの種類、アプリケーションのバージョン番号など）は、お客様が当該サービスをインストールまたはアンインストールする際に Google に送信されることがあります。また、当該サービスが Google のサーバーに定期的にアクセスする際（自動更新の際など）にも送信されることがあります。
Google は、ブラウザ ウェブ ストレージ（HTML 5 など）やアプリケーション データのキャッシュのようなメカニズムを使用して、収集した情報（個人情報を含む）をお客様の端末にローカルに保存することがあります。
お客様が Google サービスにアクセスされると、Google およびパートナーはさまざまな技術を使用して、情報を収集して保存します。その際、Cookie や同様の技術を使用してお客様のブラウザや端末を特定することもあります。広告サービスや他のサイトに表示される Google 機能のように、Google がパートナーに提供しているサービスの利用の際に、Google が Cookie や同様の技術を使用して情報を収集して保存することもあります。Google アナリティクスでは、企業やサイト所有者がウェブサイトやアプリへのトラフィックを分析することができます。DoubleClick の Cookie を使用するサービスなど、Google の広告サービスと連動して使用する場合、Google アナリティクス情報は Google アナリティクス ユーザーや Google により、Google の技術を使用して複数のサイトへの訪問数に関する情報とリンクされます。
Google がパートナーから取得したお客様に関する情報に加え、お客様が Google にログインしているときに Google が収集した情報は、お客様の Google アカウントに関連付けられることがあります。Google アカウントに関連付けられた情報は個人情報として扱われます。ご自分の Google アカウントに関連付けられた情報へのアクセス、管理、削除の方法について詳しくは、本ポリシーの透明性と選択肢の項目をご覧ください。
Google は、どの Google サービスから収集した情報も、そのサービスの提供、維持、保護および改善、新しいサービスの開発ならびに、Google とユーザーの保護のために利用します。Google は、お客様に合わせてカスタマイズしたコンテンツを提供するため（関連性がより高い検索結果や広告を提供するなど）にも当該情報を利用します。
お客様が Google プロフィールで指定された名前を、Google アカウントを必要とする Google のすべてのサービスで利用することがあります。さらに、Google は、以前にお客様の Google アカウントに関連付けられた名前を置き換えて、すべての Google サービスでお客様を一貫して識別できるようにすることがあります。他のユーザーがお客様からのメールやお客様を識別するその他の情報を既に取得している場合、Google は、当該他のユーザーに対し、お客様が公開している Google プロフィール情報（お客様の名前や写真など）を表示することもあります。
お客様が Google アカウントをご利用の場合、お客様のプロフィール名、プロフィール写真、Google または Google アカウントに関連付けられた第三者のアプリケーションでの行動（お客様の +1 や、お客様が記述したレビューおよび投稿したコメントなど）が Google サービスに表示される場合があります（広告やその他の商用関連の表示も含まれます）。Google は、Google アカウントでお客様が行う共有または公開範囲の設定に関する選択を尊重します。
お客様が Google にお問い合わせをされると、Google では、お客様がかかえているであろう問題の解決などに役立てるため、お客様との通信の記録を保管します。お客様のメールアドレスを使用して、Google サービスに関する情報（予定している変更や改善のお知らせなど）を通知することがあります。
Google は、Cookie の他にも、ピクセル タグなどの技術から収集した情報を、ユーザーエクスペリエンスの改善や Google のサービス全体の品質の向上に利用します。Google ではこの目的で、Google 独自のサービスの 1 つである Google アナリティクスを使用しています。たとえば、お客様の言語設定を保存して、お客様が指定された言語で Google サービスを表示できるようにします。Google では、広告をお客様のためにカスタマイズして表示する際、Cookie や同様の技術からの識別情報を機密性の高いカテゴリ（人種、宗教、性的指向、健康など）と関連付けることはありません。
Google の自動化システムはお客様のコンテンツ（メールを含む）を分析して、関連性の高いサービス機能をお客様に個別に提供します。このような機能には、カスタマイズされた検索結果、カスタマイズされた広告、スパムとマルウェアの検出などがあります。
Google のあるサービスから取得した個人情報を、Google の他のサービスから取得した情報（個人情報など）と結び付けることにより、たとえば知人との情報の共有を容易にすることがあります。また、アカウント設定によっては、Google のサービスや Google が配信する広告を改善するために、他のサイトやアプリでのアクティビティがユーザーの個人情報に関連付けられる場合もあります。
このプライバシー ポリシーに記載した以外の用途で、情報を利用する場合は、必ずお客様の同意を求めます。
Google は世界中のさまざまな国にある Google サーバーで個人情報を処理します。お客様の居住国以外にあるサーバーでお客様の個人情報を処理する場合もあります。
最後に対策書いてるから、ネット広告のこと知ってるって人はそれだけ読んでくれ。
漫画村もAnitubeもそうだし、「無料動画 アニメ」とかで検索したら腐るほど出てくる。
今回は漫画村が謎にUXめっちゃ良くて人気になって目立ったけど本当にいっぱいあるんだ。
漫画、アニメ、ドラマ、映画、AV、同人誌とジャンルも様々。みんな大好きxvideosも著作権なんてあったもんじゃないよな。
ちなみに増田はブロッキングとかたいして意味のない、法治国家としての根幹をゆるがすようなヤバイことはやめておけ、という派です。
https://news.yahoo.co.jp/byline/kusunokimasanori/20180416-00084015/
広告で収益を得てるわけなんだから広告止めらんないの？って思うじゃん。
止められる。しかし正直ダークな部分もあるから全部は無理。でも大手止めたらそこそこダメージあるはず。
方法はあとで解説する。その前に構造について知っておかないと意味がないと思うから説明させて。
広告を出す（出稿）の大まかな流れはこれな。
もちろんお金はとられるんだけど、めんどうだし詳しくないしってんで代理店に任せる会社は多い。
中小規模の会社はお金も無いし直接媒体社（広告が載るメディア側）とやりとりするけど、1つのサイトだけにってのはほとんどない。1個1個連絡するとコスパめっちゃ悪いから。
それで、アドネットワークとかDSP（＋SSP）とかって呼ばれる、何百万っていうサイトをまとめてる業者に頼むわけ。
代理店ってネットだとサイバーエージェントとかが有名どころ。エロ系だとライブレボリューションとか。
ライブレボリューションはこの記事でも言及されていたな。高学歴使ってエロ案件ばっかりやってる会社。
https://anacondatan.hatenablog.com/entry/2018/04/15/184740
代理店は配信すればするほど儲かる手数料ビジネスだから、お金使いたがる。
あと「結局は商品が購入されればいいんでしょ？」「会員登録されればいいんでしょ？」って感じの、長い目で見た収益なんて考えられてないところも多い。
それがさっき言ったアドネットワークとかDSPに発注する。国内はだいたい国内の業者でやってる。
アドネットワークが抱えてる配信先になんで漫画村とかAnitubeがあるの？ってことなんだけど、儲かるからです。それしかない。
アドネットワークてバナーがクリックされたらお金がチャリンと発生する（表示だけでも発生することある）ので、
漫画村みたいにめちゃめちゃPV多いサイトは金のなる木なんです。たいていこういうサイトはクリックされても購入とか登録に結びつかないから、1クリックあたりの収益は少ないけど。
一応登録する時にはサイトのURLとか入れるんだけど、だいたいザル。
↓エロ系で強かった（今は知らん）i-mobileの登録ページ
https://i-mobile.co.jp/pre_register_partner.aspx
だからあんまり審査が機能していなくてまず登録が行われちゃう。
そんで、漫画村みたいにめちゃめちゃ儲かるサイトってすぐわかるんだから、「あ、やべぇサイトだ。警告や提携解除しなきゃ」ってなるのが普通。
けどやらない。儲かるから。最悪でしょ？お金を前にして善悪が判断できていないの。俺が知る限り上場しているような会社でもこういうケースあるからな。
というわけで、怒られるまでは載せちゃっていいっしょって載せる悪い集団がそこかしこにいる。
漫画村とか色々。小さいところはアドネットワーク1〜2個くらいしか使わないけど、多いとこは10個くらい使う。
結果クリックされたらアドネットワークの手数料を抜いて収益になる。
こんな感じで
ってなってる。詳しい人には釈迦に説法だが。
ダークウェブってほどダークじゃないが、エロとか精力剤とか痩せる薬とかって広告を載せにくい。
どこも怪しいとか、読者に合わないとかで、特に上場しているアドネットワークやサイトはそういう広告を拒否する。
とすると、上場してなくて規制ゆるゆるな中小アドネットワークに任せることになる。
中小アドネットワークはそっちもそっちで、ヤベェけど大量にPVがある海賊版サイトとかをたばねてニッチなポジションを持ってる。
この怪しい商材と怪しいサイトが悪魔合体して、漫画村が成立する世界ができてる。
即効性が高いのは、アドネットワークに通報しつつそれを公にすること。
お金の出処である広告主に通報ってのは正論なんだけど、あまり効果がない。
というのも、もう広告主はどこに出してるかわからないわけ。停止する方法も知らない。
特にDMMなんてお金めっちゃあるから広告出しまくってる。代理店やアドネットワークもたくさん使ってるから誰が悪いことしたかわからない。
あげくの果てに、自社のAVの無断転載サイトに自社の広告が載るみたいなことが起きる。
アドネットワークの方は配信先の審査もして管理するような立場にあるんだから知らないとは言わせない。
ちょっと専門的な話になるけど、クリックしたらその証拠を取るためにCookieをつけます。そのために一度アドネットワークのページにリダイレクトが一瞬される。
最初のリンク先はアドネットワークだからそのURLを見る。スマホだったらバナー長押しして、すぐわかる。
（リンク先がDSPの場合は配信先関係ないけど、まあ通報しておけばいい）
スクショとって運営会社に通報（IRの連絡先とかあればそっちがいいぞ！）しつつ、「この会社の使われてま〜す！」ってTwitterに画像つきで上げろ。たぶんそれが最短。
ちょいちょい相手の首を絞めつつ、世論が出来上がっていく。あとはジャーナリストとメディアに料理してもらおう。
（所要時間35分）
久しぶりにペアーズ再開しようと思って、以前女性として作ったFBのアカウントでログインしようと思ったんだけど、Cookie消したり持ってるアカウント全部ログアウトしてから入ったりしてことごとく失敗した。
俺、Macbook使ってるんすよ（タッチバー付13インチPro
俺、プログラミングスクールでプログラミング教えるアルバイトしてるんすよ（そいつはそのスクールの卒業生
懇親会で「皆さん嫌いな言語とかフレームワークはありますか？」と話題になると私は即座にRailsと言う。
「あのコマンドを打つと中で何が起きてるか知ってますか？」（知らない
「ActiveRecord？生でクエリ書いたことある？インデックスの意味くらい知ってるよね？」（書いたことない、適当なこと言う
3分後
「alert（'XSS'）」
百歩譲って学生エンジニアならまあセキュリティに無知なのは分かる。
しかしだな、文系エンジニアは「俺もハッキングしたい（笑）」な勢いで詳しく解説することを要求してくる。非常にウザい。
"
"
しょうがないので優しく解説すると「君ってハッキングとかしてそう（笑）」「君将来ハッカーになりそうだわ（笑）（クラッキング的な意味で）」
死ねよ。
俺、Git使って開発したんすよ（GUIのSourcetree
え？バグ？ちゃんとテストしたんだけどなぁ（完全手動テスト（）笑
AWSとGCPは登録はしたものの使い方が分からなくて結局放置
pwdとcdしか知らない（Makefileを作ったことないからいつもネットのコピペコマンド
はい、ゴールデンタイムに鯖落ち。復旧した時にはゴールデンタイム終了のお知らせ。
理由、CDNを刺してない、貧弱なプランの鯖（勿論ロードバランサなんか使ってない）
でも彼らは一応優秀な文系エンジニア。高学歴、サービスも作ったこともある、それなりの実績も持っている。しかし文系だ。
こういう奴らがいるからちゃんとしたエンジニアを軽視される。黙って営業職に転職してこい。
まあでも大学じゃ作者の気持ちしか考えてないのだから当然のなのかもな（笑）
追記
残念な理系名前を書くだけ一発採用派遣SIerは対象としてない。論外だ。
給料が安い？
そんなことは無い。400万以上貰える会社に内定もらっているから嫉妬も不満も特に無い。
だがしかし、ムカつく。
そんな奴が同期にいたら蹴り飛ばしてやりたくなる。
だが見てみろ、あいつらのアプリバックエンドが無いんだぞ？意欲は認める。だがそれで胸を張ってiOSエンジニアなんて無理があるだろ？
「ログアウト時に自分のお気に入りにアクセスするとその時のキャッシュが残って、ログインしてもお気に入りにアクセスできなくなる」
とのことだった。
他のひとが試した
https://anond.hatelabo.jp/20180214082441
の動作とも一致する。
とりあえずキャッシュ全削除してアクセスしたら、確かに自分のお気に入りにアクセス出来るようになった。
でもさ、はてなって時々意図せずログアウトするのね。その時お気に入りを見ていると、別に「ログアウトしました」とか画面遷移しないでログアウト状態で自分のお気に入り見ることになるので、これが仕様だとするとログアウトしてしまったたびにお気に入りにアクセスできなくなるのね。それは困るので「キャッシュ消したらアクセスできるようになったよ」って報告と「これそのままだと困るよ」って要望書いてサポートにメール返信した。
