Hadley: it seems to be Privacy Sandbox only?

Jeffrey: Apple is doing similar things?

Lola: +me please

DanA: Multi-stakeholder issues?

Jeffrey: Multiple stakeholders are doing it, but not necessarily interested in standardising it.

Hadley: Web arch questions?

Jeffrey: Definitely abuse questions.

DanA: Societal impact label?

Lola: When we did the review for WebNN we included some societal impact questions there.

Jeffrey: The fact that it comes from Privacy Sandbox means they may not answer quickly.

Lola: Exactly - is this something we should wait on before reviewing?

Jeffrey: Tracking someone via IP address allows you to track them across cookie clears, so I think this is still important.

Yves: This allows sites to act as proxies. What's the role of the UA here? Should the UA inform the user? The invasion of privacy happens in the same place, where the proxying happens. Interesting subject.

(Martin) Why is this a TAG review request? It's not something that needs standardization. There is no interoperability impact.

Hadley: they have asked us for feedback on their design choices... not unreaonable... But might not not have a lot of standardization impact... Jeffrey asked them some specific questions... They haven't replied. I send them a nudge asking for replies.

Lola: nothing to add.

Martin: the're maintaining a list of domains.. the criteria for inclusion... is you operate a tracker or you do some advertising... So this is basically saying "you operate a tracker" but we don't want to call it a tracker...

we agree to leave it with them to come back with more info

Hadley: this is limited to one implementer

Lola: unsure what the next step is. This is very early, is the next step to say this is fine/not fine, are we trying to encourage cross platform adoption?

hadley: Given it's limited to one implementer, it's not unreasonable to decline to review it

Jeffrey: There's also https://github.com/w3ctag/design-reviews/issues/1114 where there is a draft comment to decline to review, can reference that

torgo: Wanted to not that we have a doc in 2019 about TAG observations on private browsing modes. Doc was written because specs were starting to be written with notes saying implementers started mentioning it, but there's no specifications on private mode. This document was written to roll that up, or at least just observe what was happening. Is a think other specs can point to when they say "private mode". Unsure how successful it has been, don't know if people have been linking to it. Is there anything that we should be thinking about in revising this, maybe new doc, or an update, maybe pushing on this more to say there ought to be a spec on private modes. - https://www.w3.org/2001/tag/doc/private-browsing-modes/

Christian: That's our feedback for script blocking issue -- suggest we decline this -- basically a single engine feature, encourgae them to create a specification write a a document so that it can be implemendted across engines, and this is the same feedback for IP protection

torgo: let's add a link to our document to that comment, to reinforce that we've done some thinking about this already

Lola: Mike's last message talks about how it's still very early days for this thing, vote to decline similar to Hadley and Christian, becuase they are acknowledging it's not ready for our review. Happy to use Christian's comment

Christian: everything is missing, e.g. security and privacy review, so it's not ready to review

Hadley: Fine with declinging it. Am a little concerned with Christian's suggest that we turn the challenge back to them for standardisation. IIRC in 2019 the problem was there was siginifant divergence between different browsers. Can't turn to just one specific browser. Issue is we need to bring them all together

torgo: agreed

Jeffrey: there's 2 separate questions here. There's standardising private browsing mode. But there's also standardising IP protection and script blocking that Chrome only wants to turn on in private browsing mode

torgo: If you look at the doc that Lucas wrote, it tries to make the point that there are certain things in common to private browsing mode, question should be what web features from a web developement standpoint, web devs should be thinking about how things behave in private mode, because all these browsers have a private mode. I think it's a valuable thing for people to think about. It's valuable to have it on the books. maybe we need to strengthen it in some way. I take Jeffrey's point that the reviews aren't about this. but maybe something to push to privacy WG

Jeffrey: I think there's a caution here for these features, also in the design principles. Doing something different in incognito increases risk that websites will identify users in incognito mode and increases risk that things will break in these modes. Chrome is aware if these concerns, but it's worth reiterating them. We should ask the privacy WG/CG to think about what parts of private mode can be standardised. But also I think the request for the IP protection and script blocking folks is the try and standardise those features whether or not they're in private borwsing mode or other modes

lola: I can write closing comment for IP

Christian: will take other one

torgo: Design principle 2.10 is basically a shorter version of this finding. Funny that we don't link to this finding in that principle. Maybe we should just point to the design principle instead of this finding. It's the living principle we are asking people to adhere to. https://www.w3.org/TR/design-principles/#private-browsing-mode

we agree to add both