  |
はてなキーワード: Cookieとは
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
の動作とも一致する。
とりあえずキャッシュ全削除してアクセスしたら、確かに自分のお気に入りにアクセス出来るようになった。
でもさ、はてなって時々意図せずログアウトするのね。その時お気に入りを見ていると、別に「ログアウトしました」とか画面遷移しないでログアウト状態で自分のお気に入り見ることになるので、これが仕様だとするとログアウトしてしまったたびにお気に入りにアクセスできなくなるのね。それは困るので「キャッシュ消したらアクセスできるようになったよ」って報告と「これそのままだと困るよ」って要望書いてサポートにメール返信した。
http://gigazine.net/news/20170606-intelligent-tracking-prevention/
cookie保存期間60日とかで、(ﾟдﾟ)ｳﾏ-って言ってたアフィリエイター全員死亡。(´ﾟｪﾟ)ﾁｰﾝ
http://adworld.hatenablog.com/entry/2017/09/21/012010
クリテオとかも発表をなぜか削除してしまったとのこと。
お疲れ様です。
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
全く役にたたなくてもいい。
ただの自己満足なんだけど、フフフ///ってなるコンピュータ技術（用語・名称）のトリビアが知りたい。
諸説あってもいい。誰か、URL貼り付けるだけでもいいから教えて欲しい。
例えばこんな感じ）
GNU → "GNU's Not Unix!"（「GNUはUNIXではない」）の再帰的頭字語
boot → 「pull oneself up by one's own bootstraps」
MySQL → 共同創設者 Monty Widenius の娘の名前にちなんでいる
