並び順

ブックマーク数

期間指定

  • から
  • まで

121 - 160 件 / 639件

新着順 人気順

cookieの検索結果121 - 160 件 / 639件

  • CookieとWeb Storageの仕様を比較する

    Cookie Set-CookieはHTTPのレスポンスヘッダーで、サーバーからユーザーエージェントへクッキーを送信するために使われる。 また、ユーザーエージェントはサーバーに送り返すことができる。 そのため、HTTP サーバーが HTTP ユーザーエージェントに状態を保存するために使用することができる。 Cookieの利用目的 セッション管理 ログイン状態や買い物時のカートの状態など パーソナライズ トラッキング Set-CookieとCookieヘッダ HTTP の Set-Cookie レスポンスヘッダーは、サーバーがユーザーエージェントへ Cookie を送信するために使用します。 HTTP/2.0 200 OK Content-Type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=straw

      CookieとWeb Storageの仕様を比較する
    • XSSがあってもlocalStorageに保存するのに比べてcookieのhttpOnlyはjsから読めないので強いと言うことですが、SPAのサイトであれば、XSSを使ってAPIを呼び出し放題なので、セッションのcookieがjsで読めなくても危険性には大差がないのでは?と思うのですが私の認識がおかしいでしょうか? - ockeghem page

      徳丸本の中の人 OWASP Japanアドバイザリーボード EGセキュアソリューションズ代表 IPA非常勤職員 脆弱性診断、WAFの販売・導入、セキュリティコンサルティングをやっています。 https://t.co/F0kveu1nJM

        XSSがあってもlocalStorageに保存するのに比べてcookieのhttpOnlyはjsから読めないので強いと言うことですが、SPAのサイトであれば、XSSを使ってAPIを呼び出し放題なので、セッションのcookieがjsで読めなくても危険性には大差がないのでは?と思うのですが私の認識がおかしいでしょうか? - ockeghem page
      • アクセストークンをWebWorkerで扱う - console.lealog();

        というアプローチを紹介してる記事があって、なるほど?と思ったのでまとめてみる。 元記事はこちら。 Leveraging Web Workers to Safely Store Access Tokens – The New Stack 毎度のことながら、今にはじまったことではない。 元記事いわく WebWorkerであれば、メインスレッドで実行されるであろうXSSや3rdのコードから触れないので安全! 設計としては、 メイン: まず`Worker`をロード メイン: 初期化のメッセージを`postMessage()` クレデンシャルがあるならそれを渡す ワーカー: アクセストークンの準備 受け取ったやつ or そこで`fetch()`して、オンメモリに保存 (これで準備OK) メイン: APIにリクエストしてほしいと`postMessage()` ワーカー: APIに向けてアクセストークン

          アクセストークンをWebWorkerで扱う - console.lealog();
        • #Qiita ついにTreasure Data のオプトアウトに対応する (「Qiita」「Qiita Jobs」におけるユーザー情報の取り扱い不備について思うこと & Qiita のユーザーページの件でオプトアウトを試す) - 人生100年!生涯エンジニア人生!

          2020年5月12日 更新 Qiita ついにTreasure Data のオプトアウトに対応する 2020年5月8日にQiitaの利用規約が改定されました。 blog.qiita.com 同時にプライバシーポリシーも改定されました。 qiita.com そして、ずーっと私が言ってた!!オプトアウト設定が入りました!! 2020年3月26日から騒いで、ここまで来ましたね。 現場のエンジニアさんも頑張ってくれました、対応に感謝します。 オプトアウトするにはQiitaにログインしてアカウントの設定を行います。 qiita.com このオプトアウトの文言を見ると、このように記載があります。 拒否すると、匿名情報のみがTreasure Dataに送信されます。と書いてあるので、利用情報は渡るようです。 これは匿名加工情報制度によるものなので違法ではないです。 (気分的に嫌と感じる人は、ログアウトし

            #Qiita ついにTreasure Data のオプトアウトに対応する (「Qiita」「Qiita Jobs」におけるユーザー情報の取り扱い不備について思うこと & Qiita のユーザーページの件でオプトアウトを試す) - 人生100年!生涯エンジニア人生!
          • サードパーティ Cookie 廃止に関するタイムラインの変更について

            6 月 25 日にChrome におけるサードパーティ Cookie のサポートを段階的に廃止する計画のスケジュールを含む、「プライバシーサンドボックス」の最新情報を公開しました。取り組みを進めていく中で、この計画を正しく実施するためには、デジタル広告のエコシステム全体でさらに時間が必要なことがわかってきました。 「プライバシーサンドボックス」は、利用者のプライバシーに配慮しつつ、誰もがアクセスできる自由で開かれたウェブ環境を維持できるよう、デジタルビジネスを構築するツールを提供する技術の開発を目指すものです。これを実現するには、エコシステムに携わるコミュニティが一丸となり、ウェブのプライバシーを根本的に強化する開かれた基準をもち、データがどのように利用されるかについての透明性を高め、管理権限をユーザーが持つ必要があると考えています。 そのためには、適切な解決策に関する開かれた議論、規制当

              サードパーティ Cookie 廃止に関するタイムラインの変更について
            • ITP更新: IntelligentではなくなったIntelligent Tracking Prevention|AD EBiS マーテック研究会

              iOS13.4やSafari13.1と一緒に新しいITPがリリースされました。主な変更点は二つ。 * 全ての3rd party cookieをブロック * Local Storage等、クッキー以外のストレージを最後のインタラクションから7日後に削除 インタラクションとは、クリック・タップ・入力のことで、ドメイン毎に監視され、7日以内にインタラクションがないドメインのLocal Storageは削除されます。 その他に、JavaScriptからdocument.referrerで取得する全てのクロスサイトリファラーのダウングレード("https://store.example/baby/strollers/deluxe-stroller-navy-blue.html"の場合、"https://store.example/"しか取得できなくなる)、および5秒以内の自動ページ遷移の検知も追加さ

                ITP更新: IntelligentではなくなったIntelligent Tracking Prevention|AD EBiS マーテック研究会
              • 3PCA 最終日: 3rd Party Cookie 亡き後の Web はどうなるか? | blog.jxck.io

                Intro このエントリは、 3rd Party Cookie Advent Calendar の最終日である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie ここまで、 3rd Party Cookie との 30 年に渡る戦いと、 ITP 以降それが Deprecation されるに至った流れ、そして Privacy Sandbox の API について解説してきた。 最終日は、ここまでを踏まえて、来年以降の Web がどうなっていくのかを考えていく。 「Web 史上最大の破壊的変更」の意味 筆者はこのアドベントカレンダーの最初に、これを「Web 史上最大の破壊的変更」と言って始めた。 Web で破壊的変更と言え

                  3PCA 最終日: 3rd Party Cookie 亡き後の Web はどうなるか? | blog.jxck.io
                • クックパッド株式会社を退職しました - Write and Run

                  クソお世話になりました pic.twitter.com/DfmHibNWMQ— KOBA789 (@KOBA789) 2021年2月26日 タイトルの通りです。2月26日付でクックパッド株式会社を退職しました。有給は6時間しか余っていなかったので最終出社日=契約最終日です。 社内の人は社内ブログにもうちょいマシな記事を置いてきているはずなのでそちらを読んでください。 なんでやめたの? 改めて説明するのがダルいのであまり詳しく書きたくはないのですが、要らぬ邪推を避けるために書いておくと、少なくとも給与やオフィス移転などへの不満ではないです。 平たく言えば COVID-19 Situation に疲れたというやつです。 転職先は? 転職しません。無職をやります。 フリーランスやるんですか、ともよく聞かれるんですがフリーランスは無職ではありません。 しばらくはやりたいことをやって過ごそうかと思い

                    クックパッド株式会社を退職しました - Write and Run
                  • Google Chromeが勧める広告技術FLoCのまとめ - Qiita

                    この1・2週間で一気に話が広まったせいで今さらなかんじになってしまった感もありますが、FLoCの話のまとめです。 サードパーティーCookieの代替としてGoogleが導入を進めているFederated Learning of Cohortsですが、とにかく大不評です。 FLoCについて FLoCとは 非常にざっくりFLoCを説明すると、ユーザを嗜好でグルーピングしてグループID(cohort ID)を発行し、そして広告会社にはグループIDだけを渡すよ、というものです。 お前ロリコングループな、お前は巨乳グループな、などと分類されるわけです。1 ブラウザからWebサイトに渡されるのはグループIDだけなので、そのグループ内の誰であるかを特定することはできません。 木を隠すなら森の中ということですね。 どうしてFLoCが必要になったのか 今後使えなくなるサードパーティCookieの代替手段とし

                      Google Chromeが勧める広告技術FLoCのまとめ - Qiita
                    • 「クッキー」から始めるプライバシーの旅

                      私見ですが、日本ではどうも「プライバシー」に対するこだわりが薄い気がします。プライバシーの話をすると、「自分の個人情報が漏れたところで、何の問題もないよ?」や、「悪いことをしていなければ問題はない」と返されます。人は生活をする上で、さまざまな「情報」を作り出します。例えば購入したもの、歩いた場所や食べたもの。その一部は自らが写真などの形でSNSに投稿し、公開状態にしていたりもするでしょう。その感覚の延長線上に、そういった「プライバシーなんてそこまで気にするもの?」という考え方があるのかもしれません。 果たしてこのような情報に無頓着でいいのでしょうか。今回は多くの方がおそらくよく知らないまま利用している、Webブラウザのとある機能から、パーソナルデータとプライバシーについて考えてみましょう。 毎日食べているけど目に見えない? 「クッキー」とは何か Webブラウザにおける「クッキー」というもの

                        「クッキー」から始めるプライバシーの旅
                      • Googleタグマネージャが同意の設定に対応 | アユダンテ株式会社

                        なお同意ツールを利用していない場合、各同意タイプのデフォルト値は「許可」扱いになります。 そのため、GTMの同意設定に対応した同意ツールのタグテンプレート等を利用していないのであれば、タグの同意設定を変えても特に動作に変化はありません。 一括操作で同意設定を行えるようになる「同意の概要を有効にする」 同意ツールをサイトで利用しているのであれば、ONにしておきたいのが「同意の概要を有効にする」オプションです。 これは管理メニューの「コンテナの設定」画面へ追加されています。 管理 > コンテナの設定 へ「同意の概要を有効にする」が追加実装。 「同意の概要を有効にする」をONにすると、以下の機能が使えます。 タグの一覧画面から、複数のタグの「同意設定」を変更可能になる タグの一覧画面の右上へ同意概要アイコンが追加され、同意設定状況のリストを確認可能になる 要は複数のタグへ一括で同意設定できるよう

                          Googleタグマネージャが同意の設定に対応 | アユダンテ株式会社
                        • DNSプロトコルのここ数年のトピック紹介

                          こんにちは、滝澤です。 筆者の趣味として調べているDNSのプロトコルのここ数年のトピックについて紹介してみます。 ほぼ毎年、DNSに関連する新しいRFC(インターネットに関する技術仕様)が公開され、仕様が更新されたり、新しい仕様が追加されたりしています。 ここ数年のトピックについてまとめてみたいと思い立ち、この記事を書きました。 なお、この記事は2020年8月時点での情報となります。すべてを網羅しているわけではありません。 ちなみに、筆者は次のサイトを公開している人でもあります。 DNS RFCs ANYクエリーに対してRRsetをすべて返すわけではない 2019年1月に「RFC 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」が公開されました。 このRFCでは、DNSレスポンダー(DNSレ

                          • 雰囲気でOAuthを使っていたエンジニアがOAuthサーバ(RFC6749)を自作してみる

                            はじめに Auth屋さんの本やその他有識者のBlogなどを読むことで少しながらOAuthやOIDCの仕組みが理解できてきました。 そんななかで以下の記事が大変勉強になりました。 ↑の記事ではRubyで実装されているのですが、これを参考というかほぼ丸コピですがgolangで実装してみたいと思います。 コードは以下にあります。 仕様 OAuthサーバでは認可エンドポイントとトークンエンドポイントを実装する必要があります。 認可とトークンエンドポイントの2つに加えてユーザ認証を行うエンドポイントを作ります。 今回は元記事と同じようにFormに入力したユーザ&パスワードを受け取り確認します。 RFC6749に関する仕様は元記事の2.注意点と同じになるはずです。 「はずです」というのは恥ずかしながらまだ完全な理解に至っておらず今もRFCを読みながら答え合わせ中です。 ぜひ認識違いがあればご指摘くださ

                              雰囲気でOAuthを使っていたエンジニアがOAuthサーバ(RFC6749)を自作してみる
                            • [アップデート] root ユーザー作業が不要に!Amazon CloudFront で署名付き URL/Cookie 向け公開鍵を IAM ユーザー権限で管理できるようになりました。 | DevelopersIO

                              本日のアップデートで Amazon CloudFront の署名付き URL および署名付き Cookie に対する公開鍵の管理を、IAM ユーザー権限で行えるようになりました! Amazon CloudFront announces support for public key management through IAM user permissions for signed URLs and signed cookies IAM ユーザー権限による公開鍵管理が可能に 従来、CloudFront で署名付き URL および 署名付き Cookie を利用する場合、「CloudFront のキーペア」を作成する必要がありました。このキーペアの作成は AWS アカウントの root ユーザーしか行うことが出来ません。そのため必要になった際にアカウント管理者に連絡しキーペアを作成してもらう、

                                [アップデート] root ユーザー作業が不要に!Amazon CloudFront で署名付き URL/Cookie 向け公開鍵を IAM ユーザー権限で管理できるようになりました。 | DevelopersIO
                              • スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも??? Amazon EC2をステートレスにする為にやるべきこと | DevelopersIO

                                スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも??? Amazon EC2をステートレスにする為にやるべきこと セッション管理が必要なWebアプリケーションを使う場合でも、スティッキーセッションを利用しない方法を説明します。また、ログをインスタンス内に保持しない方法やAuto Scaling化についても触れています。 はじめに おはようございます、加藤です。煽り気味なタイトルで申し訳ございません、念の為より詳細に記載しますが、スティッキーセッションを使っていなければApplication Load Balancer障害の影響を受けるのを防げたかもしれないという内容です。 今後同様の障害への対処として、このブログの対応は行う価値がありますが、これだけやっておけばOKという事では無い事をご理解ください。 2019年8月23日にAWS

                                  スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも??? Amazon EC2をステートレスにする為にやるべきこと | DevelopersIO
                                • サルでもわかるGoogle Chromeのプライバシー対策で何が起こるのか – marketechlabo

                                  Chromeが2年以内にサードパーティcookieをブロックすると正式に発表しました。 https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html いろいろなことが言われていますが、具体的に何が起こるのか、混同しやすいところを含めて初心者でもわかるようにまとめました(このサイトでは珍しい初心者向けの記事です)。 cookieを取り囲むブラウザ環境の変化のおさらい これまではiOS/SafariがITPの取り組みの中でトラッキング目的のサードパーティcookie(※)をブロックしてきましたが、これでSafariとChromeの両方でトラッキング目的のサードパーティcookieをブロックすることになります。スマートフォン、デスクトップ、タブレットで大半のシェアが適用対象になるわけです。 なおFire

                                    サルでもわかるGoogle Chromeのプライバシー対策で何が起こるのか – marketechlabo
                                  • Google Analytics代替として開発された、Cookie不使用のオープンソースの解析ツール・「Pirsch」

                                    PirschはGoogle Analytics代替として開発された、Cookie不使用のオープンソースの、シンプルでプライバシーに配慮した解析ツールです。 GAほど多機能ではないものの、PVやセッション、リファラなどWebサイト解析に必要なメトリックを提供してくれます。 解析用のスクリプトも1KB未満で解析対象のWebサイトのパフォーマンスを損ないません。データはCSVでエクスポートも可能な他、メールで定期的に解析結果を送る事も可能です。 管理画面もシンプルで見やすく分かりやすい印象でした。OSSとして提供されていますが、Webサービスとしても展開しているようです。現在はベータ版のため、無償で利用できるみたいです。ライセンスはAGPL-3.0との事。 PirschOn Github

                                      Google Analytics代替として開発された、Cookie不使用のオープンソースの解析ツール・「Pirsch」
                                    • What's New In DevTools (Chrome 94)  |  Blog  |  Chrome for Developers

                                      Use DevTools in your preferred language Chrome DevTools now supports more than 80 languages, allowing you to work in your preferred language! Open Settings, then select your preferred language under the Preferences > Language dropdown and reload DevTools. Preferences" width="800" height="494"> Chromium issue: 1163928 New Nest Hub devices in the Device list You can now simulate the dimensions of Ne

                                      • GoogleはChromeでユーザーエージェント文字列を段階的に廃止する方針

                                        by Tati Tata ブラウザがウェブサイトにアクセスする際に送信するユーザーエージェント文字列は、使用しているOSやデバイスのアーキテクチャ、ブラウザの情報などを含んだテキストであり、ウェブサイトの表示形式などに影響します。オープンソースのウェブブラウザエンジンChromiumをベースとしてGoogleが開発するGoogle Chromeが、このユーザーエージェント文字列を段階的に廃止する方針であることが明らかになりました。 Intent to Deprecate and Freeze: The User-Agent string - Google グループ https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/-2JIRNMWJ7s/yHe4tQNLCgAJ Google to phase out user-a

                                          GoogleはChromeでユーザーエージェント文字列を段階的に廃止する方針
                                        • Cookie vs Local Storage マルウェア耐性等に差はあるか?Google Chromeによる保存時の暗号化を検証する - Flatt Security Blog

                                          はじめに こんにちは。セキュリティエンジニアの@okazu_dmです。 皆さんはブラウザにおいてLocal StorageやCookieに格納されている値が暗号化されているかどうかを考えたことはあるでしょうか。これらWebサービスの認証・認可において使われるデータが、XSSのようなアプリケーションの脆弱性への耐性に差があるかどうかは頻繁に議論されるところです。 しかし、ブラウザに保存されたデータが暗号化されているかどうかはまた別の攻撃経路への耐性の話であり、馴染みがないのではないでしょうか。 これは、基礎知識としてLocal StorageとCookieの仕組み/挙動の紹介と比較をしつつ、Google Chromeにおけるそれらの暗号化の実装上の違いを検証する記事です。 なお、保存先のストレージとAuth0のアクセストークンのXSS耐性との関連は過去に別の記事で検証しています。興味がある方

                                            Cookie vs Local Storage マルウェア耐性等に差はあるか?Google Chromeによる保存時の暗号化を検証する - Flatt Security Blog
                                          • たまには私のクッキーも受け入れてほしい

                                            受け入れるクッキーを持ってきた人が汚い 家の近くまで呼び出されたべつやくさんは「それころんだの?」と聞く。ころんだ人が持ってきたようなクッキーを受け入れたいだろうか。そう、これも演出である。 受け入れがたいクッキーとは何かを考えた結果、持ってくる人の見た目の印象がよろしくないのではないかと考えたのだ。 そこで自転車を汚した。泥を作ってぬりたくってきたのである 網やチューブなどの変な部品も追加した。自転車が汚い。そしてサンダルである。 加えてもう一点。露出が多い=服装に清潔感がない。サンダルであり、自転車が汚い。ちょうどウーバーイーツについての言及がTwitterで流行っていた。すぐ参考にした​​​​ ダメな配達員を目指した どうすれば受け入れがたいクッキーとなるかを考えていたとき、SNSではウーバーイーツの配達員に対してのとあるコメントが流行っていた。「清潔感がなく、サンダルで、自転車が汚

                                              たまには私のクッキーも受け入れてほしい
                                            • ウェブのプライバシー強化: サードパーティ Cookie 廃止への道

                                              .app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads

                                                ウェブのプライバシー強化: サードパーティ Cookie 廃止への道
                                              • 3rd Party Cookie 調査のための Web 広告導入 | blog.jxck.io

                                                Intro 昨今、特に広告サービスを中心に 3rd Party Cookie を用いたトラッキングについての議論が多く行われている。 Safari による ITP や、 Chrome による Privacy Sandbox への移行など、技術的な変化も著しい。 こうした技術の変遷を観測し、調査検証を行うために、これまで避けていた Web 広告を本サイトに導入することにした。 Motivation 本サイトは、様々な Web に関する技術を調査し、実際に試すためにサイト自体に適用しながらそれを記事にまとめるという目的で運用してきた。 様々な技術を試したり、そのパフォーマンスやセキュリティへの影響を評価する上で、一般的なサイトの構成とかけ離れていれば、あまり意味をなさない。 そのため、本サイトでは以下のように、別に必要はない機能やサービスをあえて導入している。 AMP AMP より Origi

                                                  3rd Party Cookie 調査のための Web 広告導入 | blog.jxck.io
                                                • プライバシー サンドボックスの新しい Topics API について

                                                  メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。

                                                    プライバシー サンドボックスの新しい Topics API について
                                                  • SameSite cookie recipes  |  Articles  |  web.dev

                                                    SameSite cookie recipes Stay organized with collections Save and categorize content based on your preferences. Chrome, Firefox, Edge, and others are changing their default behavior in line with the IETF proposal, Incrementally Better Cookies so that: Cookies without a SameSite attribute are treated as SameSite=Lax, meaning the default behavior is to restrict cookies to first party contexts only. C

                                                    • Google、ChromeでのサードパーティーCookie廃止開始を2024年まで延期

                                                      米Googleは7月27日(現地時間)、Webブラウザ「Chrome」でのサードパーティーCookieのサポート完全廃止開始の目標期日を2024年後半に延期したと発表した。延期するのは2度目だ。 同社は2020年1月、2年以内にサードパーティーCookieを完全に廃止すると発表したが、2021年6月に2023年後半に延期した。 Googleは、プライバシーで問題視されているサードパーティーCookieを廃止し、それでもユーザーに適した広告を表示できるようにするためのイニシアチブ「プライバシーサンドボックス」を推進している。 現在、一部の開発者向けにプライバシーサンドボックスAPIのテスト版を提供している。テストに参加している開発者から、Cookie廃止の前に新しいプライバシーサンドボックスの技術を評価するにはより多くの時間が必要だというフィードバックを多数受け取ったという。 これを受け、8

                                                        Google、ChromeでのサードパーティーCookie廃止開始を2024年まで延期
                                                      • Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備(同ドメイン内なら ...) - Qiita

                                                        Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備(同ドメイン内なら ...)JavaScriptcookieJWTxsstoken tokenを保存する場所 localStorage cookie cookie (http only) メモリ内 (変数) よく言われるのが JWT tokenをlocalStorageに入れるべきではない ということ。 理由としてはJavascriptで簡単に読めてしまうので、XSSがあった場合意図しないスクリプトを動かされてしまい、結果としてtokenが盗まれるというもの。 対応策として cookie (http only) を色んな所で推奨してる。 https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851 http://cryto.net

                                                          Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備(同ドメイン内なら ...) - Qiita
                                                        • ネット履歴の外部提供に「拒否権」 利用者保護へ総務省 【イブニングスクープ】 - 日本経済新聞

                                                          総務省はターゲティング広告など利用者のデータ提供に関するルール整備に乗り出す。ネットの閲覧履歴のデータが第三者に提供される状況を利用者が止める仕組みをサイト運営者に義務付ける。閲覧データを分析する業者や広告配信業者は現在の仕組みでの展開は難しくなり、ネット広告のビジネスモデルの転換につながる可能性がある。プライバシー意識の高まりから世界では閲覧履歴の利用を制限する動きが加速している。日本でも利

                                                            ネット履歴の外部提供に「拒否権」 利用者保護へ総務省 【イブニングスクープ】 - 日本経済新聞
                                                          • Amazonも「最悪」と評されるGoogleの新システム「FLoC」をブロックしたことが判明

                                                            by Marco Verch Googleが開発中の「FLoC」と呼ばれるツールは、多くのウェブサービスやウェブサイトから「最悪」と評され、完成前から独占禁止法違反で調査される事態となっています。新たな調査では、AmazonがこのFLoCをプラットフォーム上でブロックしていることが確認されました。 Amazon is blocking Google's FLoC — and that could seriously weaken the system https://digiday.com/media/amazon-is-blocking-googles-floc-and-that-could-seriously-weaken-the-fledgling-tracking-system/ Googleは2020年に「2年以内にChromeでサードパーティーCookieのサポートを廃止する予

                                                              Amazonも「最悪」と評されるGoogleの新システム「FLoC」をブロックしたことが判明
                                                            • 「Cookie同意バナー」を作れるツール、ユーザーローカルが無償配布 工数・費用対策に

                                                              JavaScriptとマニュアルを同梱。PC版・スマートフォン版のWebサイトに対応する。文章や色は変更可能で、同意を取り消したいユーザー向けの取り消しボタンも用意した。 サードパーティーCookieの利用を巡っては、プライバシー保護の観点から国内外で規制が広がっており、特に欧州では「一般データ保護規則」(GDPR)により、Cookieを使った情報取得の基準が厳格化されている。グローバル展開を前提とする場合は特にCookie利用の同意バナーの設置が重要となる。 ユーザーローカルは「同意バナーを開発してWebサイトに実装するには、工数や費用がかかる問題がある」としてツールの無償配布を決めたとしている。なお、同ツールがユーザーローカルと通信することはないとしている。 関連記事 Yahoo! JAPAN、欧州からの接続遮断へ 「法令順守の対応コスト面からサービス継続不能」 ヤフーが、欧州経済領域

                                                                「Cookie同意バナー」を作れるツール、ユーザーローカルが無償配布 工数・費用対策に
                                                              • Chrome におけるスキームフル Same-Site の適用について

                                                                .app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads

                                                                  Chrome におけるスキームフル Same-Site の適用について
                                                                • 多要素認証でも防げないクラウド攻撃出現、「最高謝罪責任者」を用意するベンダーも

                                                                  米国土安全保障省のサイバーセキュリティー・インフラストラクチャー・セキュリティー庁(CISA)は2021年1月中旬、クラウドサービスを狙ったサイバー攻撃が相次いでいるとして注意を呼びかけた。多要素認証を破られたケースもあったという。 セキュリティーの専門家は、「クラウドだから安全」と考えて適切な設定や運用を実施していない利用者が多いのが一因と指摘。安全性を高めるツールなどを用意しても利用者が使ってくれないとして、クラウドベンダーも苦慮しているとしている。 例えばあるクラウドベンダーは、「みなさんが思っているほどクラウドは安全ではありません」と“謝罪”して回る「Chief Apology Officer(最高謝罪責任者)」を用意しているほどだという。 テレワークの普及により重要度が増す一方のクラウド。利用している組織は十分注意する必要がある。 メールサービスが危ない CISAは注意を呼びかけ

                                                                    多要素認証でも防げないクラウド攻撃出現、「最高謝罪責任者」を用意するベンダーも
                                                                  • SameSite Cookie

                                                                    SameSite cookieについて話をしました。 CookieにSameSiteを付けることでCSRFを防ぐことができます。Chrome 80からはSameSite=Laxがデフォルトになります。 以下の記事を参考にしました。 Cookie の性質を利用した攻撃と Same Site Cookie の効果 | blog.jxck.io ( https://blog.jxck.io/entries/2018-10-26/same-site-cookie.html ) Cookie の SameSite=Lax をデフォルトにする提案仕様 - ASnoKaze blog( https://asnokaze.hatenablog.com/entry/2019/05/09/005513 ) SameSite Updates - The Chromium Projects ( https://w

                                                                      SameSite Cookie
                                                                    • 「リクナビ問題に見る日本の個人情報保護法の欠陥」を電子フロンティア財団が指摘

                                                                      2019年、就職情報サイトの「リクナビ」が、ユーザーデータを用いて個々の求職者が求人を辞退する確率を予測し、顧客企業に販売していたことが明らかになりました。リクナビによる顧客データの不適切利用は「リクナビ問題」として大々的に報じられたのですが、「このリクナビ問題はプライバシー関連法に存在する抜け道の危険性を示している」と電子フロンティア財団が指摘しています。 Japan’s Rikunabi Scandal Shows The Dangers of Privacy Law Loopholes | Electronic Frontier Foundation https://www.eff.org/deeplinks/2021/05/japans-rikunabi-scandal-shows-dangers-privacy-law-loopholes 世界中のテクノロジーユーザーはデータ保護

                                                                        「リクナビ問題に見る日本の個人情報保護法の欠陥」を電子フロンティア財団が指摘
                                                                      • CookieとWebStorageとSessionについてのまとめ - Qiita

                                                                        ざっとこんな感じですかね? WEBストレージは、保存容量が大きいですね。幅があるのはブラウザによって違うからです。あとはサーバー側にいちいちデータの通信をしないところがクッキーとの大きな違いですね。 ちなみに、ローカルストレージはオリジン単位(プロトコル://ドメイン名:ポート番号)でデータを保存するので、当然、別ウィンドウやブラウザを閉じてもデータは共有され続けます。一方、セッションストレージは同じドメインのサイトを別々のウィンドウで開いていても、それぞれが別のsessionStorageとなることに注意っす。 クッキーはWEBストレージより有効期限が自由に設定できますね。 クッキーはサーバー側からクライアントに対してクッキーをセットするようにレスポンスを返す必要があるので、サーバー側の言語で書かれることが多いです。一方、WEBストレージは完全にクライアント側の操作なので基本的に値の取得

                                                                          CookieとWebStorageとSessionについてのまとめ - Qiita
                                                                        • 3rd-party cookieの引退とブラウザのアドテック進出|AD EBiS マーテック研究会

                                                                          クッキーに代わる技術まとめシリーズ第1回「3rd-party cookieのない2年後のアドテックに向けた動きまとめ」からすでに3年経っていますが、3rd-party cookie廃止まではあと1年です。 廃止に向けてPrivacy Sandboxの名前で知られている代替技術は一般公開が進められています。Chromeを利用されている皆様はすでにユーザへの広告機能有効化の告知をご覧になり、「理解した」ボタンを押されたかと思いますが、ここで有効化したものを含めて、主要ブラウザの各種代替APIについて説明したいと思います。 Chromeのターゲティングや計測API有効化承諾画面ちなみにEUでは「理解した」と「設定」ではなく、「Turn it on」と「No Thanks」の選択になっています(しかもボタンの色が同じ)。 それでは2021年のシリーズ第2回の投稿から約2年ぶりとなる今回は、前回ご紹

                                                                            3rd-party cookieの引退とブラウザのアドテック進出|AD EBiS マーテック研究会
                                                                          • Braveがうっとうしい「Cookieを許可してください」のブロックを開始

                                                                            インターネットを利用中に、「Cookieを許可してください」というポップアップが表示されたり、許可するCookieの種類を選ばされたりしたことがある人は多いはず。こうした表示はGDPRといった規制を順守する上で必要なものですが、Cookieの使用を許可するつもりのない人や関心がない人にとってはわずらわしいものです。広告とトラッキングをブロックする機能を搭載しているブラウザのBraveが、このCookieの許可を促すバナーのブロックを開始しました。 Blocking annoying and privacy-harming cookie consent banners | Brave Browser https://brave.com/privacy-updates/21-blocking-cookie-notices/ Braveは2022年9月28日に公式ブログを更新し、10月にリリース

                                                                              Braveがうっとうしい「Cookieを許可してください」のブロックを開始
                                                                            • 公取委、Cookie利用を規制へ 「規制いらない」経団連は反発

                                                                              公正取引委員会がCookieの利用を規制する方向で検討に入ったと、朝日新聞が10月29日付で報道し、Twitter上で話題になっている。公取委は、利用者の行動追跡に利用できるCookieが個人情報などに当たるとして、取得時に利用目的の明示などを求める考え。一方、経団連は「経済の発展を阻害する」として規制案に反対している。 【修正履歴:2019年10月29日午後7時57分 記事の記述を一部修正しました】 【修正履歴:2019年10月29日午後10時35分 記事の記述を一部修正しました】 Cookieは、Webページを閲覧したときのデータを一時保管する仕組み。Cookieの情報だけでは個人を特定できないため、個人情報保護法の対象ではないが、他の情報と組み合わせれば特定できる場合もある。 公取委は8月、消費者保護を目的としてデジタルプラットフォームを運営するIT企業と消費者間の個人情報取引につい

                                                                                公取委、Cookie利用を規制へ 「規制いらない」経団連は反発
                                                                              • Webアプリケーション開発に潜むリスクのケーススタディ | ドクセル

                                                                                徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – – – – EGセキュアソリューションズ株式会社取締役CTO https://www.eg-secure.co.jp/

                                                                                  Webアプリケーション開発に潜むリスクのケーススタディ | ドクセル
                                                                                • GitHub - jonasstrehle/supercookie: ⚠️ Browser fingerprinting via favicon!

                                                                                  You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                                    GitHub - jonasstrehle/supercookie: ⚠️ Browser fingerprinting via favicon!