[Webkit-unassigned] [Bug 272189] ITP 7-day exception for origins that don’t communicate with other origins

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=272189

--- Comment #3 from Callionica <callionica at callionica.com> ---
Thanks for responding, John. I’m not sure where you’re seeing sarcasm. None intended.

You’re doing some good thinking about how to get to a solution.

To answer your specific questions:

Q1: “Is the above what you are envisioning”
A1: Probably. I don’t want to constrain the design space too much, but this is the kind of thing I was imagining:

1. The browser would track when a page makes a cross-origin request and store a simple boolean flag (CROSS_ORIGIN) in memory associated only with the source origin (destination origins do not matter & wouldn’t be recorded - it only matters that there’s cross origin communication)
2. The browser would persist the CROSS_ORIGIN flag to disk immediately if local data is already present for the origin, or it would do it later at the same time that local data is persisted for the origin.
3. When deleting data, the ITP policy would look at the CROSS_ORIGIN flag to determine whether data should be deleted. If the CROSS_ORIGIN flag is not set, data does not need to be deleted.
4. The CROSS_ORIGIN flag is deleted/cleared when there is no local data stored for the origin and no code/state for that origin in memory.

Does that match closely with what you were thinking?

Q2: “Would tying it to a strict CSP work as technical enforcement?”
A2: Not sure. I didn’t see this as a bug that would require changes on the part of website developers, I was looking at it more as a way of identifying classes of web site that could be carved out from the ITP data deletion policy without harming the intention of the policy.

Q3: “Do you have thoughts on how developers can manage their websites to not make a cross-site resource load mistake on some page?”
A3: CSP is interesting for this certainly. Documenting the CROSS_ORIGIN flag and its location in the file system might be the lowest cost approach that would provide value. A web inspector setting that throws an exception when the CROSS_ORIGIN flag is set would probably be more useful than CSP for catching a mistake. Most valuable of all, in my view, would be to allow Safari users to have a setting that allows them to disallow cross-origin requests from any web site, then developers could use the same feature. These would all be bells and whistles though. Very nice to have, but strictly speaking unnecessary for fixing the core issue. It would particularly be a shame to go down a CSP route that might encourage a heavyweight process with other browser involvement when the behavior in question appears to be Safari-specific.

I hope you find these brief thoughts helpful.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240417/da7d3cd3/attachment.htm>