Open30
気になった記事の一言まとめ: ~2024年4月末まで
かず2024/01/17
- 2016年ごろの3rd Party cookieに対する各ブラウザのブロック状況について書かれている
- SafariでITP(Intelligent Traking Prevention)が導入され、3rd Party Cookieを本格的にブロックしていく方針になった。トラッキングの判定は機械学習で実施されている
かず2024/01/29
- 3rd Party cookieを防ぐ方法として、PartitioningというTop Level Domainを利用してCookieを分割するという方法について紹介している。
- この方法だとkeyが変わるので認証を引き継げないなど壊れるサイトもあり、別のStorage Access APIを利用して、許可があれば3rd party cookieにアクセスできるようにする、という方法をSafariで提供している
- 許可を求めずに、自分のサイトで取得した3rd party cookieを利用したいケースもあるので、それはPartitioningを利用することで実現できる。これを各ブラウザが別々で行っていたが、ChromeがCHIPSという、Cookieの属性に、"Partitioned"を指定することで、明確にPatitioningをOpt-inできる仕様を提案した
かず2024/01/30
- トラッキングを行っていた業者は、3rd party cookie以外での代替のトラッキング手段を求めるようになった
- 元々の問題で3rd party cookie自体が問題ではなく、それによるトラッキングが問題であり、それを各事業者が意識する必要性を主張していた
- ITPに対して考えられた迂回手段は色々ある
- 1クエリで29万円も課金されてしまった
- GCP周りで問題起きたらとりあえずサポートに問い合わせ
- BigQueryはLimitやWhereを書いてもフルスキャンされる。
- BigQueryはスキャンしたデータ分だけ従量課金制っぽい
- 値段関連はこれも良さそう: https://qiita.com/itkr/items/745d54c781badc148bb9
かず2024/01/31
- 3rd party cookieへの利用制限対策のひとつとして、Bounce Trackingという手法がある。サイト移動時にトラッキング用のサイトを挟みこむことで、ユーザーに関連する情報を1st party cookieとして管理できるようにする。その結果、トラッキング用サイトのドメインのcookieでトラッキングが可能になる。: 実際に試さないとちゃんと挙動理解できてない...
- SafariのITPでBounce Trackingは防がれている(ITPではリダイレクト以外でもサイト利用していないとトラッカーとみなす、という変更で塞がれている)
- ほかの利用制限対策として、Link Decorationという手法がある。aサイトからbサイトに遷移するさいに、専用のURLクエリを付与する => 遷移先のJSでクエリ取得 => 遷移先で1st party cookieとして保存 => トラッキングで利用可能
- Link DecorationとBounce Trackingは組み合わせで利用されることが多い
- ITPではJS(document.cookie)で保存されたcookieは1st partyでも短期間で消える変更により、すでに塞がれている and クエリIDが既知のものが多いのでトラッカー判定されて塞がれてやすい
かず2024/02/01
- Fingerprintingというcookieに依存せずに、ブラウザで取得できる情報をかき集めて、ユーザーの識別をする手法がある
- Fingerprintingには主に、IPやUser Agentの値が利用されている
- IPは、Proxyを経由して、アクセス元のIPを接続先サーバーから隠することで対策できる。各ブラウザもProxyの用意やVPNの用意などで、対策の実施や予定がある。
- User Agentは過去の負債から文字列が増えてきているの
- User Agentの代替として、Sec-CH-UAの対応がChromeを筆頭に進んでいる
用語
- Mosaic: 一番最初期のwebブラウザ
- User Agent: リクエストを行っているユーザーエージェントのバージョンなどを識別するためのhttpリクエストヘッダ
- Sec-CH-UA
- ユーザーエージェントのブランド(Chromeなど)とバージョン情報を提供する
- 低エントロピーの情報
- ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-UA
- Feature Detection
- ブラウザで該当コードがブラウザで対応しているかどうかを調べる機能がある
- ref: https://developer.mozilla.org/ja/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection
かず2024/02/02
- 個人的に学べた内容
- workflow-telemetry-actionという、Github ActionsでCPUやメモリの利用率を簡単に確認できる。これでCIを動かすインスタンスの調整や、並列処理を行う場合の最適な並列数を決められる
- PlaywrightというE2Eテストツールがあるとのこと
- Playwrightには、テストコードの生成補助機があり、ブラウザ操作でその処理のテストコードを生成できる。
- テストを並列実行可能
- テストのトレースが可能: UIモードでリアルタイムにテストの様子確認可能・失敗時にレポート出力可能
かず2024/02/04
- 3rd party cookieの制限の迂回路として、Cloakingという、トラッカーのドメインを正規ドメインとして扱うようにして(=3rd partyではなく1st party)、トラッカーのcookieを扱えるようにする手法。
- 以下の3種類がある
- CNAME Cloaking
- CNAMEというDNSにおいて別名のドメインと正規名のドメインを結びつけるレコードです。これを利用して、1st partyのサブドメインと、トラッカーのドメインを紐づけることで、Same Siteとなる
- Safariなどで対策されている: CNAME先が3rd partyの場合にcookieを短命にするなど
- IP Cloaking
- ドメイン名だとSafariにばれるので、Aレコードを使って、ドメイン名とIPを結びつける方法。
- トラッカー側はIPアドレスを変更できないというデメリットがある
- NS Cloaking
- サブドメインを丸ごと移譲する
- CNAME Cloaking
- Cloakingだと、自分のドメインを事業者側に預けるので、ドメインの価値を損失させられるリスクもあるので、安易に選ぶべき手段ではない
用語
- eTLD+1
- https://shinkufencer.hateblo.jp/entry/2020/01/10/000000
- TLD: トップレベルドメイン
- eTLD:
- eTLD + 1:
- Same Site
- TODO
- CNAMEレコード
- Aレコード
- NSレコード
- 1st party・3rd party
- TODO
- sampel
用語
かず2024/02/05
- 3rd party cookieの制限の迂回路として、super cookieという手法がある
- これは、HSTS(Http Strict Transport Security)をトラッキングに利用する手法である
- サイトがHTTPSに対応していることをブラウザに知らせて、次回からはhttpsに自動でアップグレードさせる機能
- サブドメインをN個用意し、特定ユーザーには特定のサブドメインのHSTSを有効にするようにレスポンスする。
- 保存期間を指定可能
- 次回アクセス時に、そのサブドメインが有効になったユーザーと判別可能。N^2でユーザーを区別可能になる。
- HSTSはブラウザでグローバルに保存されるので、どのページからもフェッチ可能
- この対処にSatte Patintioningで別サイトのHSTSが共有されないようにできる
用語集
Strict Transport Security: https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security
その他参考
Super Cookiesについての参考
かず2024/02/14
- ビッグテックによるユーザーの同意なしのユーザーデータの取得・利用などを行い、プライバシーについて世間ではセンシティブにとらえられるようになった
- これらの問題の根本的解決の方向性として、Safari以外のブラウザもITPの3rd party cookieのブロックという方針に同調して3rd party cookieをdeprecatedする方向になった
- Chromeでは2024年中に3rd party cookieを完全に廃止する方向性で動いている
- 代替の手段としてPraivacy SandboxというAPIを発表している
- これが3rd party cookie終了の実態となる
用語集
かず2024/03/03
- Httpにおける"SameSite"とは、eTLD+1までが同じであれば、同じサイトとして扱う
- Same Site Cookieは、eTLD+1が同じドメインにしか送らないCookie
- Cross Site Cookieは、3rd Party Cookie
- "SameSite"の値として以下を指定できる
- "Strict" : CookieがSameSiteに閉じられる
- "Lax" : 基本CookieがSameSiteに閉じられるが、画面遷移(Top Level Navigation)ではCookieを送ることが可能
- "None": Cross SiteにもCookieを送れる = 3rd Party Cookieであるマーカー
- Chromeは"Lax"をデフォルトに設定している
- 今後のCookieの運用として、read/writeを分離し、read権限用のcookieを"Lax"・write権限用のcookieを"Strict"にするのがベストプラクティスらしい
- 他のドメインから画面遷移時にログイン状態を維持したいので、read権限用のcookieを"Lax"にする
- 書き込みなどのセキュリティを高めたいやつは、より厳密に"Strict"にする
参考資料
かず2024/03/05
- 3rd Party Cookieの代替手段として、Privacy Sandboxという、プライバシーを侵害せずにCookie利用時のユースケースを満たせる安全なAPIの実装がGoogleが主導している
- 1st Party Dataをかなり保有しているGoogleが3rd Partyをただ廃止するだけだと、競合他社に対して不当な圧力とみなされる可能性がある。独占禁止法的な意味での不正競争の防止のため、CMA(イギリスの競争・市場庁)が3rd party cookieの代替手段を準備せず、廃止しないように調査・レビューしている
- Privacy SandboxのAPIを利用するには、登録作業が必要
かず2024/03/13
- Interested Based Advertisingを実現するためのPravacy SandboxのAPIについて紹介している
- 最初にFLoC(Federated Learning of Cohorts)が提案されたが、諸々問題があり取り下げられた
- FLoCの改善版として、Topics APIが提案された。
- Tpoics APIでは、数百種類の分類を返す。分類は公開されていて人間にも読める内容になっている。
- 毎週履歴を集計 => 計算 => 3つを返す仕組み
- 95%の確率で、算出された上位5つのトピックリストから、ランダムにトピックが選択される
- 5%の確率で、分類からランダムにトピックが選択される
- Mozilaは否定的で、Safariは反対的な立場
関連記事
かず2024/0315
- 他サイトで見た商品を、別サイトで表示するリターゲティングを実現するための、turtledoveと括られたAPIの一つのProtected Audience APIについて紹介している
- 商品閲覧時に、Interest Groupという、広告に関する情報をブラウザに保存 => これでInterestGroupが増えていく => 媒体側で広告枠を売るときにオークションを実施する
- どのInterestGroupに参加している・オークションに勝った広告が漏れないように、オークション用のWorkletを利用している
- iframeではなく、Fenced Frameという非常に機能が制限されているHTMLタグで広告を表示している
- この利用を強制するために、オークションの結果をURNを返している
- 広告主側のサーバーでリアルタイムに広告に関する情報を、媒体側に提供するために、Trusted Execution Environmentというものを利用しているっぽい?
関連記事
かず2024/03/18
- 広告の効果測定を行うために、各ブラウザのベンダーはそのユースケースを満たすためのAPIを別々で提案している
- Safari
- Private Click Measurement
- クリックとそれによる購買をブラウザで保存 => 結果を溜めておき24~48hでランダムにレポートする(紐付け阻止のため)
- 紐づけられる情報が少ない(広告側8bit・購買側4bit)
- レポートも クリックが発生したドメインの.wekk-knownに送られるので、送り先を広告プロバイダに変えられない
- 追加案も提案されている
- Private Click Measurement
- Chrome
- Attribution Reporting API
- 広告のクリック以外にも、表示にも対応している
- 紐づけられる情報が多い、64bit
- Meta
- MPCで、データを複数の参加者が分割されたデータの暗号化and 共有をしているっぽい?
かず2024/03/19
- 3rd Party Cookieの廃止で、今までできていたクロスサイトの連携が防がれる
- しかし、同じ運営母体だが、ccTLD(国別コードTLD)が違う・用途ごとにドメイン分けなどでクロスサイトとなり連携できなくなる
- 上記の緩和する案として、ChromeからRelated WebSite Setsが提案された
- Related WebSite Setsでは、Chromeが管理しているjsonファイルに、ドメインに関連するドメインを宣言してマージしてもらう必要がある
- Chromeはこのjsonファイルを読み込んでドメインの関連を認識する
- https://github.com/GoogleChrome/related-website-sets/blob/main/related_website_sets.JSON
- Mozilaは否定的で、Safariは反対の立場
参考文献
かず2024/03/20
- あるサイト(RP)の認証を別のサイト(IDP)の認証で行う場合、従来では3rd Party Cookieを利用して行っていたが、代替の手段としてFedCMというブラウザのAPIに落とし込んだ提案がある
- これはブラウザに対して、IDPへのログイン処理を委譲できる
- RP側で呼び出す際には、JSでCredential Managment APIを利用すれば可能
- Mozilaは、これに対して肯定的、Webkit(=Safari?)は保留
参考文献
かず2024/03/21
- 3rd Party Cookieが廃止されることの影響は、開発者だけに留まらず、ビジネスにまで影響を与える可能性がある
- 広告の収益が低下することで、それに頼ったメディアやサイトは存続のためにどういう舵取りをするのか
- 広告の収益を増やすために、全画面広告や派手な内容(エロ・コンプレックス・儲け話・etc)に歯止めが効かなくなる => Ad Blockerが普及し、広告収益が一層入らなくなる => 最終的に生き残るのが、行き倒れたメディアサイトや勝ち残った課金サイトだけのインターネットになる => 無料のインターネットが終わる、という可能性もある
- ビジネスサイドで、3rd Party Cookieの廃止の影響を残り超えられないと、ユーザーが減りWeb自体が縮小する可能性がある
- 現時点は、Webが縮退するかどうかの重要な分岐点にいる
- Chromeによる1%の3rd Party Cookie廃止のロールアウトが2024/01/04から開始された
用語集
Walled Garden
- プラットフォーマーが自社サービス内に極力ユーザーを留まらせるようにする施策
-
https://infeed.co.jp/glossary/internetmarketing/118/
Global Policy Control - https://ex-ture.com/blog/2023/12/19/gpc-global-privacy-controlとは？/
かず2024/03/24
- 不用意なキャッシュの用意は避ける
かず2024/04/10
- S3とCloudFrontを利用していて、CloudFrontへの転送(Egress)量に対しての課金が高い状況だと、S3をCloudlrareのR2に移行すると効果的
- CloudFlareのR2は、Egress帯域幅料金が無料そう
- cloudflareはawsのcloud frontと比較して、セットアップが容易で機能的にもDDOS対策やDNSなど多機能なイメージ。Cloud Frontで行うと色々なAWSサービスの統合が必要なケースを、CloudFlareは単体で実現できるケースがある。
- 課金体系が全然違い、CloudFrareはTierごとに月払い or 年払いっぽい。Cloud Frontは従量課金制。なので、サービス要件に合わせた選定がかなり大事になりそう。
かず2024/04/11
- ブランチ戦略として、以下の２つがある
- Git Flow
- main・develop・ feature・release・hotfix
- Github Flow
- main・feature
- Git Flow
- トランクベース開発
- https://www.atlassian.com/ja/continuous-delivery/continuous-integration/trunk-based-development
- https://rheb.hatenablog.com/entry/2021/08/24/トランクベース開発について
- 開発者が細かく頻繁なアップデートをmainブランチにマージしていくバージョン管理手法
- 開発単位を小さく保つ and CI/CDを実行して自動テスト・脆弱性診断FBを得る
- これで開発スピードを上げている and デプロイまでの時間を短縮する
- feature flag
- コードを変更することなくシステムの振る舞いを変更可能にする仕組み
- カテゴライズがあり、ライフサイクルやON/OFFの頻度が異なる
- Release Toggles
- Experiment Toggles
- Ops Toggles
- Permissioning Toggles
- トランクベース開発での利用・A/Bテスト・ダークカナリアリリース・特定ユーザー限定の機能の有効化など
- OSSとして、OpenFeatureというfeature flagを管理する抽象化層的なやつが存在するらしい
- feature flagについて、色々SaaSとかもあるらしい
かず2024/04/12
- OpenFeatureは、feature flagの管理を行うサードパーティを抽象化して利用できるSDKを提供している
- Go Feature Flagなる、プロダクトがあるらしい
かず2024/04/13
DeNAの技術スライド面白そうなので、これからはひとまずこちらを中心に読んでく
- テストデータを生成するライブラリがあるっぽい
- 所感まとめ: https://qiita.com/ta_nuki/items/1a9947c6d607b130c356#testfixutures
- 静的な生成:
-
https://github.com/go-testfixtures/testfixtures
- yamlによる管理、既存のDBに接続してymlをdumpする機能ありそう
-
https://github.com/go-testfixtures/testfixtures
- 動的な生成
-
https://github.com/go-faker/faker
- Goの構造体からダミーデータの作成
-
https://github.com/bluele/factory-go
- 同じくGoの構造体からデータ作るが、色々とカスタマイズ性がありそう
-
https://github.com/go-faker/faker
- テストデータ要件的に、特定の状態を持つデータを作る and 共有したい: BANユーザーなど
- その状態を作成する関数を用意している
- https://speakerdeck.com/dena_tech/techcon2021-14?slide=39
- ほかの要件
- 基本系: 依存関係がないテストデータ: 生成コードを自動生成されるようにする
- 基本系: 依存関係あるテストデータ: 生成コードを自動生成されるようにする
- 特殊系: 特定状態を共有するためのテストデータ : 手動で作成
-
https://speakerdeck.com/dena_tech/techcon2021-14?slide=32
- テストはテーブルドリブンテストでテストケースごとに作成することで、基本的にテストデータの共通化はしない and どういったデータでテストするのかを明確にする
- 共通化すると、テスト間で相互作用が発生する可能性がある => メンテナンスのしやすさが下がる
- テストデータの生成をGoのコード内で行うことでデータの内容を簡単に把握できる
- テストはテーブルドリブンテストでテストケースごとに作成することで、基本的にテストデータの共通化はしない and どういったデータでテストするのかを明確にする
かず2024/04/14
- 階層構造を表現する手法として、以下の2つがあるらしい
- 閉包テーブルモデル: ノード間の親子関係を表現するのに、そのペアをその間の距離を保存する
- 任意の二ノード間の関係を非常に迅速に検索できる
- ancestor(祖先)・descendant(子孫)・depth
- 経路列挙モデル
- 階層をノードまでのパスとして保存している
- 階層構造の更新が色々な行に影響を及ぼすので、階層構造が頻繁に更新されるデータの管理には向いていない
- https://takuma521.hatenablog.com/entry/2023/06/08/200829
- 閉包テーブルモデル: ノード間の親子関係を表現するのに、そのペアをその間の距離を保存する
- 列指向・行指向のDBで、上記のそれぞれのモデルからデータを集計して取得するとき、列指向では閉包テーブルモデルが高速で、行指向では経路列挙モデルのほうが高速になっていた。
- データ集計時のJoinで、列が増えるか行が増えるかの違いだが、 DBの特性に応じてデータの持ち方を意識する必要がある
かず2024/04/15
- GCPにはGoogleデータポータル(旧DataStudio)なるDIツールがあるらしい
- データソースにBigQueryを利用できる
- COCOAとは
- https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/cocoa_00138.html
- 新型コロナウイルス接触確認アプリ
- BLE(Bluetooth Low Energy)信号とは
- https://www.musen-connect.co.jp/blog/course/trial-production/ble-beginner-1/
- https://www.marubun.co.jp/technicalsquare/9091/
- https://monomonotech.jp/kurage/webbluetooth/ble_guide.html
- Bluetoothの規格の中で省電力に特化するためにできた通信方式
- 省エネのために基本的にスリープモードで定期的に起動するっぽい
- 接触符号RPIとは
- Exposure Notification API
- iOS・Androidが提供しているコロナ接触に関する通知のためのAPI
- サポートが終了している
- 代替のExposure Notification Expressが出たからかも
- https://japan.googleblog.com/2020/05/apple-google-exposure-notification-api-launches.html
- https://developer.apple.com/documentation/exposurenotification
かず2024/04/17
- langchainをGoで書けるようにしたライブラリのLangChainGoが存在する
- ドキュメントの充実度的には、まだまだ
- 今のところ、LangChainのモジュールである、ModelsとPromptsは色々使えそうかも?
かず2024/04/20
- 言語化のために、得た情報を自分の言葉に変換する、これは結構意識的にやっていくと言語化が鍛えられる以外にも、その情報が頭の中に定着しやすそう
- golangでコードベースで値のバリデーションを色々できるやつ
- 独自のバリデーション関数も作れる
- その際にcontextも引数に用意しているinterfaceもあるので、結構使いやすそう
かず2024/04/21
- protocというprotobufのスキーマから対応するクラスや構造体を生成するコンパイラーが存在する
- protocにはpluginによる拡張機能が存在している
- プラグインは、シリアライズされたprotobufメッセージを標準入力から受け取る
- プラグインは、その入力内容を利用して任意のファイルなどをするために、決まった形式のデータを用意する
- そのデータをprotobuf形式にシリアライズして、標準出力に書き込む
- protocはその出力を受け取って、ファイルの生成などを行う
- プラグインには引数を渡したり、カスタムのオプションをprotoファイルで定義してプラグイン側でそれを受け取ることが可能
- オプションは、ファイル単位だけではなく、メッセージ定義・各フィールド単位ア、諸々の単位で設定可能
- 既存のメッセージ定義を外部から拡張して、フィールドを足すことが可能(extension機能)
かず2024/04/27
- ログの設計方針がまとめられている
- ログレベルを明示的にする
- Log4jでは5つある
- DEBUG ＜ INFO ＜ WARN ＜ ERROR ＜ FATAL
- この際に、概要・詳細・出力場所・対応などを意識すること
- ほかにも、種類として、TRACEやほかにも色々ある
- PHPにおける PSR-3など
- https://www.php-fig.org/psr/psr-3/
- ログの出力場所は、重要情報が含まれたりするので、アクセス権限や不特定のユーザーがアクセスできないようにする
- 出力する情報も個人情報などを含めない or マスキング or 一方向ハッシュなどで分からないようにする
- ログメッセージ
- ハードコーディングしない
- 簡潔・分かりやすくする
- コンソールから確認する用途があれば、1行80文字以内にとどめる
- フォーマットを意識しておく: 統一性があると可読性が上がるため
- INFOレベルの出力にタイミングについて、処理の開始・途中経過・処理の終了などを出力するとシステムの挙動を追えるのでお勧め
- パフォーマンス・ログローテーション間隔・セキュリティなども考慮事項にある
かず2024/04/28
- slogは、Goの従来のlogパッケージではサポートされていないけれど、プロダクト開発では色々と求められる機能などが、追加されていた
- 構造化ログ
- ログレベル
- コンテキストを意識したロギング
- ログのサンプリング
- 設定オプションの豊富さ
- slogは、使いやすさ・高パフォーマンス・実行トレースとの統合を目指しているとのこと
- コンポーネントとして、Logger・Record・Handlerの3つが存在する
- Logger、入力に関するメソッドを提供する
- Record、Loggerの出力メソッドで作成されるログデータ
- Handler、Recordを使って、フォーマットや出力先の決定を行う
- slogの特徴
- 従来のlogパッケージのインターフェスを満たすインスタンスの生成も可能
- key・valueで情報を追加可能
- 子ロガーとして、すべてのレコードに同じ属性を含めることが可能
- ログのグルーピングが可能
- 出力する対象の構造体で、LogValuerインタフェースを満たすようにすることで、出力のカスタマイズが可能
- Handlerの独自での実装
- Handlerのオプションの設定で、既存のkey-valueの値に対して置き換えが可能
- これを利用して、ログレベルの追加も可能
- ログレベルについては、デフォルトでDEBUG・INFO・WARN・ERRORしかなく、それらの値も飛び飛びになっており、あとからログレベルの追加が可能になっている
- これを利用して、ログレベルの追加も可能
かず2024/04/29
- zapからslogに移行した話
- zap利用時は、以下の問題点があった
- 全プロダクトでログのキーワードのネーミングが統一されていなかった
- 出力フォーマットのガバナンスが効いておらず、最低限ログに含まれてほしいも含まれていないこともあった
- マスキング処理を個別対応していた
- 上記の解決 & プロダクト側でもある程度の技術的自由度を持たせるために、共通ロガーの用意
- 要件
- ログとして、RSET・GraphQL・gRPCの全てで共通となる必須項目の定義が漏れないようにする
- データ基盤連携ができるログフォーマットにする
- ログのマスキング処理が用意されていること
- 1と2番めは、プロダクト側にボイラープレートコードを提供
- 3番目はライブラリの用意: 独自のカスタマイズ性はあまりないと判断
- 要件
- あまりslogを利用する意味が分からなかった
- slogの機能で、contextから値を取得してログのレコードに利用する方法がある
- HandlerインタフェースにおけるHandleメソッドをオーバーライドした独自のHandlerを用意して、contextの値を利用する
- そのため、ログにトレースIDを含めるなどの目的のために、contextにloggerをぶち込む・DIする・トレースIDを含めたloggerを適宜作成する、などをしなくても良い選択肢がありそう