Google Chrome User Agent String Reduction

 最近再看 Google Chrome User Agent string reduction 的文件。

1. 主要目的是為了避免太多額外資訊被利用來做 fingerprint ，所以拿掉主要是移除 minorVersion / oscpu / deviceModel ，透過將這些數值回傳靜態數值( static value )來避免 fingerprint。

例如

(Linux; Android 9; SM-A205U) 變成 (Linux; Android 10; K)

Chrome/93.0.1234.56 變成 Chrome/93.0.0.0

2. Google Chrome Dev 有提到 User-Agent Client Hint (sec-ch-ua)跟 navigator.userAgentData 來取代 user agent string ，但是在 safari 跟 firefox 都不支援的情況下應該不會特別想轉過去使用。

3. 影響比較大的應該是 Reduced navigator.platform values (for all versions) 如下圖，有使用此數值的服務應該要檢查一下。

Ref: https://web.dev/migrate-to-ua-ch/

Ref: https://uar-ot.glitch.me/navigator

Ref: https://wicg.github.io/ua-client-hints/#examples

Ref: https://www.chromium.org/updates/ua-reduction/

GTM 上的 Server Side Tagging(伺服器標籤追蹤)

 

最近看到一篇 GTM 的 Server Side Tagging [Ref.1]，發現這是 google 出的給 GCP 做 CNAME Cloaking [Ref.2]。

說的更簡單 google 希望各個 在 GCP 上的 publisher 都給 Google 一組 CNAME 做 1st party 的追蹤所出的解決方案。

[Ref.1] GTM 的 Server side tagging 網頁開發雜記

[Ref.2] CNAME Cloaking

CNAME Cloaking

由於大眾越來越注重隱私，所以現在 3rd cookie tracking 越來越難追蹤了，例如 Apple safari 的 ITP [Ref.1]。

所以就有廣告技術商提出來 CNAME Cloaking，跟合作的 Publisher 討論好廣告技術商上的 tracking pixel 在 網址 domain name 的格式。

例如廣告技術商  TenMax 跟 WSJ.com 合作，談好 CNAME Cloaking 的網址為  tenmax.wsj.com，請 Publisher WSJ.com 在他們的 DNS 上面設定一組 CNAME 指到 tenmax.wsj.com 到 TenMax 的主機上。

https://tenmax.wsj.com/track/ 這樣 TenMax 就可以透過這個 pixel 存取 wsj 上的 1st party cookie 了 。

[Ref.1] Safari ITP 歷程介紹 2019

Privacy Preserving Lookalike Audience Targeting

 最近在技術討論頻道討論的一個議題，覺得還蠻值得丟出來討論的

1. chrome 有提出一個用來去識別化來記錄轉換(conversion) 的作法叫做 aggregation report API [Ref.2]。

2. Facebook 希望能擴充這個 API 讓這個 API 可以做到去識別化的 lookalike audience [Ref.1]。

3. 其實做方法就是讓 aggregation report API 回傳的結果可以是 embed vector，讓 publisher 的後端可以去計算出去識別化的 audience。

[Ref.1] Privacy Preserving Lookalike Audience Targeting

[Ref.2] Aggregation Report API

Persistence Layer 是什麼?

系統通常會有下面架構，Data Base 負責儲存資料， Data Access Layer 負責存取資料，Persistence Layer 負責作為 DAL 跟 Business Logic Layer (商業邏輯層)，把存取出來的資料持久化，避免一再重複透過 DAL 存取 DB 造成大量資料 query 的情況。

Java Persistence Api (JPA) 則是其中定義的 API 介面，而實做這個介面的有很多廠商，例如 hibernate 、 Oracle TopLink。

JSON Web Token(JWT) 儲存在前端那邊比較好?

1. 不建議 JSON Web Token(JWT) 儲存在 localStorage/sessionStorage，透過 JavaScript XSS 攻擊可以輕易存取到。

2. 可儲存 JWT 在 HttpOnly cookie ，一般來說如果後端有用一些簡單框架，都有防止 Cross-site request forgery (CSRF) 的攻擊方式來存取 cookie 資訊。

ref: Where to Store your JWTs – Cookies vs HTML5 Web Storage

ref: 以 JSON Web Token 替代傳統 Token

Ad Fraud - 數位廣告詐騙分析

集團內的技術分享，有興趣的朋友可以參考一下。

Ad fraud-FunP Tech Sharing from Kevin Zhuang

行動裝置上的創意廣告四種類型

以行動裝置來討論，目前有四種互動模式。

•  跟環境互動-AR

Wikimedia Commons - Augmented Reality

•  跟原本網站操作連動- (ex 往下滑廣告輪播)

•  跟廣告操作互動 (ex 360度輪盤轉動)

•  跟裝置連動 (ex 陀螺儀) 

[JS] 執行 new Foo(...) 發生的三個流程

1. 新增物件繼承自 Foo.prototype。

2. Foo 的 constructor function 會被呼叫。

3. 第一步的物件會被回傳出去(通常 contructor 不會特別指定回傳物件)。

Ref: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/new

AdExchange 廣告交易中心的疑似詐騙行為

image from commons.wikimedia.org

最近聽到很有趣的疑似廣告流量詐騙議題。

某網站流量跟 CTR 都很固定，約在每日十萬， CTR約在 1% 左右。算是很不錯的流量來源。

然後忽然此網站某幾個版位某天 CTR 開始逐步成長到 3.x%，以廣告交換中心會覺得這些版位成效不錯，並且逐漸拉高廣告出價(bid floor)。

忽然某個小時灌入近 10 倍的流量，由於廣告交換中心 bid floor 計算還來不急反應下修，變等於是使用 3.x% CTR 的出價去購買這些 10倍的流量，進而造成發佈商營收大量增加。

類似股市坑殺散戶的概念，這種情況如何偵測是個好議題。

數位廣告筆記 - third party tracking, GDPR issue.

1. webkit 對於 3rd  party cookie 的限制 (Intelligent Tracking Prevention) 以 make expired 做範例。

情境：有可能一個 我今天在 example-product.com 種了一個使用者 cookie id 在 example-tracker.com 網域下想說之後如果以點擊/購買我可以認列在我們的轉換。

結果使用者三天之後才買， example-tracker.com 就會存取不到第三方 cookie 的使用者資訊，就沒辦法認列。

Webkit Intelligent Tracking Prevention


2. 因應上述限制 facebook 提供 first party cookie option 跟 連外頁面連結帶 fbclid 做連結。

廣告技術者需要知道的 Facebook Pixel 重大更新

Facebook to release first-party cookie option for ads, pull web analytics from Safari

3. GDPR 廣告科技/數位媒體/電子商務 等的影響。

Google Blogger 的 GDPR 宣告

我們公司有對這個議題作分析，我自己是覺得，重點是要告知使用者，並且讓使用者有被遺忘，不被追蹤的權力，而非只是單純的阻止廣告科技/數位產業追蹤使用者

而 GDPR 的 opt-in/opt-out
(Opt in - 先不納入使用者使用，由使用者決定確認後要使用後才啓用。
Opt out - 先提供該服務給使用者, 再由使用者決定是否要繼續使用。)

其實是偏向 opt-in，但是實際上對 數位廣告/電商/數位媒體 真的很難做到使用者同意再給廣告跟追蹤。

我自己個人也是支持 GDPR 的，但是技術上我覺得還有很多尚待討論的實做問題。

所以重點還是回到有沒有提示使用者/跟給予使用者刪除被遺忘的選項。

以數位廣告做流量/素材管理，所以提供給使用者跟廠商的是資料被遺忘權。

對電商/數位媒體則需要提供資訊呈現給使用者，而且不能用落落長的 term of use 法律條文來呼籠。

給網站主的 GDPR 因應建議

Immutable In JavaScript

FunP 集團的技術分享
筆記一下

數位廣告業界洞察 - UnMuted/Muted 事件

最近 mobile device 對於影片要能自動播放，大多都會要預設靜音 (muted)。

也因此當使用者有沒有播放聲音這個行為就相對變的重要，而且值得觀察了。

影音廣告的規範文件 在VAST 1.0 就定義了 TrackingEvents-> mute/unmute 也逐漸被重視。