- From: Pete Snyder <psnyder@brave.com>
- Date: Mon, 12 Dec 2022 17:21:08 -0600
- To: Jeffrey Yasskin <jyasskin@google.com>
- Cc: public-privacy <public-privacy@w3.org>, John Wilander <wilander@apple.com>
Howdy howdy, We haven’t done anything in this direction so far, mostly for implementation difficulty reasons and competing resources, but for a couple other reasons too: 1. 3p state in frames in Brave is cleared when the top level site is closed (no more top level frames), so we just in general have far less state sticking around in general 2. We’ve using script injection / resource replacements to sandbox state for known-unwanted 3p scripts. We call the automated system we use for generating these SugarCoat [1], and it lets us effectively give targeted scripts frame-lifetime, sandboxed state. We ship these on desktop and android currently. Happy to say more if it’d be helpful! Pete 1: https://brave.com/research/files/sugarcoat-ccs-2021.pdf > On Dec 12, 2022, at 12:54, Jeffrey Yasskin <jyasskin@google.com> wrote: > > I was recently reminded of the piece of https://lists.w3.org/Archives/Public/public-privacy/2019JulSep/0067.html that says some browsers were moving to «dynamic policies for handling JS set storage (e.g. there is no single global “storage clear” event to decide when to reset device Ids against, but lots of small micro, per value decisions)». > > How is that change going? My impression from https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ is that Safari never proceeded to having different lifetimes for different pieces of non-cookie storage? Did Brave? If so, did you notice any web-compat problems? > > Thanks, Jeffrey
Received on Monday, 12 December 2022 23:21:34 UTC