タグ

cookieに関するmoritataのブックマーク (6)

  • Cookieを使用せずにユーザー属性を推定する技術を確立し、特許を取得 | ログリー株式会社

    ログリー株式会社(社:東京都渋谷区、代表取締役:吉永浩和、証券コード:6579、以下:ログリー)は、インターネット広告配信においてCookieなどのユーザーを一意に特定する技術を使用せずに、ユーザーの属性を推定する技術を確立し、特許を取得いたしました。(特許:第6511186号) 近年、インターネットにおけるユーザーのプライバシー保護について関心が高まり、ブラウザのCookieが制限されるようになりました。また、EU圏ではGDPR(EU一般データ保護規則 *1)が制定され、Apple社のSafariブラウザではITP(Intelligent Tracking Prevention(以下、ITP)*2)によってCookieによるトラッキングを禁止する機能が搭載されるなど、今後もユーザーのプライバシー保護に対する仕組みが整備されていきます。 ログリーが実施したスマートフォンにおけるITPの影

    Cookieを使用せずにユーザー属性を推定する技術を確立し、特許を取得 | ログリー株式会社
    moritata
    moritata 2019/05/11
    何かと思ったら、アクセスログを解析して情報得る話ってだけだった。解析手法が特許なんだろうけど、ログ解析はどこもやってるだろう
  • どうして JWT をセッションに使っちゃうわけ? - co3k.org

    備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ?」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ

  • http://blk.jp/archives/765

  • オープン化への変貌とキャリアの隠蔽体質を考える – secure.softbank.ne.jpの問題を受けて | [ bROOM.LOG ! ]

    ニコニコPodder iPhone/iPod/iPad対応ニコニコ動画簡単インポートツール aggregateGithubCommits GitHubレポジトリでのコミット数をAuthor/期間別に集計します probeCOCOATek 新型コロナ接触確認アプリCOCOAが配布するTEKを表示・集計 7月になってsecure.softbank.ne.jpという一種のSSLプロキシの廃止を受けて、高木さんと徳丸さんから続けて背景説明のエントリーが発表されている。 SoftBankガラケーの致命的な脆弱性がようやく解消 ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る 簡単に言えばこのSSLプロキシの廃止は重大なセキュリティリスクを回避するために絶対的に必要だったと言うことなのだが、詳細はぜひ上記を参照して欲しい。 正直に言うと、この高木さんとソフトバンクモバイル宮川氏のやり取りの前に少し

  • 「PCでは見えないはず」に頼ることの危険性

    表をご覧いただければ分かるように、いままで漠然と考えられてきた「ケータイだから大丈夫」という感覚は、実は非常に心許ないものなのです。 ここまで見てきたように、ケータイWebの安全神話は、以下の2点を根拠として支えられてきたものです。 ケータイWebが閉鎖的なサービスであった ケータイブラウザの機能が低かった そして、これらが将来にわたって、いまのままであるとはいえないのです。今回の終わりにあたり、今後の展望について少し説明してみましょう。 今後もケータイは閉鎖的なネットワークを維持するのか 連載では、iPhoneAndroid端末は対象としないと書きましたが、これら海外で設計された携帯電話は、Wi-Fi(無線LAN)対応により、インターネットに直接接続する機能があります。このため、日のケータイのような閉鎖的なネットワークを前提にしていませんし、PC向けサイトと同レベルのセキュリティ

    「PCでは見えないはず」に頼ることの危険性
  • 安全なセッション管理を実現するために

    ログイン前とログイン後でセッションIDが変化しない セッション固定攻撃が成立する最後の条件はログイン前とログイン後でセッションIDが変化しないことだ。セッションIDを変化させるためには明示的な実装が必要となるから、意識して実装されていない限り条件が成立する可能性は高いといえるだろう。 ほかの条件については、独自に機能拡張されたアプリケーションサーバやフレームワークを使用するなど、複雑な対策が必要となるが、最後の条件だけは、容易な実装で対策することが可能である。 対策: ・ログイン成功時にセッションIDを再発行する セッションIDを変化させるには、ログインが成功したらセッションIDを再発行させればよい。再発行の時点でセッションIDは攻撃者にとって未知の値となるため、セッション固定攻撃は成功しなくなる。具体的には以下のような実装となる。 /** ログイン処理を実行して成功したらセッションを再発

    安全なセッション管理を実現するために
  • 1