ITPの変遷・最新の仕様と挙動の違い／対策の必要性と方法 – marketechlabo
ITPの仕様 次々と新しいバージョンがリリースされるITP。微妙にアップデートされ、仕様がわかりにくくなっているので現時点で最新のものを解説する。 ITPの目的と概要 われわれウェブサイト運用者は cookieやローカルストレージなどを使ってブラウザにドメインのデータを保持し、 それらのデータを必要に応じてツール間で連携する ことによって行動計測やコンテンツの出し分けなどのマーケティング活動を行っている。ITPはウェブサイト訪問者のプライバシー保持のためにそれを制限する仕組みである。具体的に何をやっているのかざっくりまとめると、 この3つのケースにおいて cookieなどを使ったデータ保持が短期間しかできなくなる（期間の長さはケースごとそれぞれ異なる） リファラが使い物にならなくなる 可能性があるということである。その結果 コンバージョントラッキングができない リマーケティング広告が配信で
Cookie の性質を利用した攻撃と Same Site Cookie の効果 | blog.jxck.io
Intro Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。 この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、 CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。 現在、提案実装されている SameSite Cookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。 Cookie の挙動とそれを用いた攻撃、そして Same Site Cookie について解説する。 Cookie の挙動 Cookie は、 Set-Cookie によって提供したドメインと紐づけてブラウザに保存され、同じドメインへのリクエストに自動的に付与される。 最も使われる場面は、ユーザの識別子となるランダムな値を SessionI
Datadog Logsでアプリケーションログを管理する | CyberAgent Developers Blog
この記事はCyberAgent Developers Advent Calendar 2017 6日目の記事です。 アドテクスタジオ Dynalyst開発チームの黒崎 (@kuro_m88) です。早いもので入社して3年目になりました。今年はDatadog Logsを一部本番に導入したので紹介しようと思います。 Dynalystではサーバやアプリケーション、AWSのマネージドサービスの監視やメトリクスの可視化にDatadogを使っています。 どんな風に使っているかは以前発表した資料があるのでこちらをご覧下さい。 そして、このスライドの最後に「ログのマネジメントもできるといいなぁ…?」と書いてありますが、なんとその願いが叶った結果、Datadog Logsが11月末に発表されました！！！！ 何ができるのかは公式ドキュメントの図がわかりやすいです。 https://docs.datadoghq
Conventional Commits
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意 スコープ]: <タイトル> [任意 本文] [任意 フッター] あな
HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
0.0.0.0にはアクセスしないこと - Qiita
はじめに この記事は2019年4月時点で調べたものをベースにしています。将来的に変わるかもしれません。 tl;dr 0.0.0.0を宛先に使うのは誤り ただしOSによっては 127.0.0.1 に到達するので支障がなかったりする 想定読者 0.0.0.0と127.0.0.1の違いをすぐに答えられない人が対象です。 ネットワークな人はわかっていることだと思うのでブラウザバックしてもらって構いません。 強い人は間違えているところコメントください。 環境 Ubuntu 16.04を利用します。 $ uname -a Linux parallels-vm 4.10.0-28-generic #32~16.04.2-Ubuntu SMP Thu Jul 20 10:19:48 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 簡単な例 Webの文脈ではWebサーバのQu
Electronアップデータのチャネル対応 - Qiita
自分用メモなので殴り書き注意 もろもろ都合でelectron, electron-builderも古い。 けど、基本的な構造はそんな変わってない。。。ような気がする。。。（未確認） package.json 設定 "dependencies": { "electron-auto-updater": "^1.0.0" ... } "devDependencies": { "electron": "^2.0.0", "electron-builder": "^20.15.1", "electron-packager": "^12.1.0", "electron-updater": "^2.21.10" }, "build": { "win": { "target": "nsis", "icon": "icon.ico", "publish": [ { "provider": "generic"
Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか
Tech Deep Dive #0 https://connpass.com/event/72517/ 2017年12月20日 高い可用性を持ちながらも低レスポンスタイム高スループットの性能を持つシステムを構築するために、何をどのように作ればよいのかを、アーキテクチャから実装レベルまで紹介いたします。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Updating Applications | Electron