Web sites & web apps that don’t load 3rd party content and don’t send cross-origin requests suffer from the auto-deletion of local data according to the ITP 7-day policy. Why are the users of such sites punished by data loss because completely unrelated sites are full of trackers? Perhaps you could make ITP slightly more intelligent?
<rdar://problem/126301939>
Thanks for filing! Let me start by saying that sarcasm is rarely a good starting point for a productive conversation. There is a significant difference between a web*page* and a web*site*. A browser engine only ever sees webpages and doesn't know about the content of pages not visited yet. Thus, a browser engine cannot know if a website or web app has cross-site content or not. It only knows about visited webpages since the user last cleared history or for the current session/tab in the case of ephemeral browsing. A policy along the lines that you propose would have to consider both the past and the future. Past: Only if visited pages from the website have been free of cross-site content for N+ days will it be exempt from certain tracking prevention measures. Future: As soon as a visited page from the website is found to load cross-site content, it needs to be opted in to the tracking prevention measures, including for website data created in the past. The future perspective also applies to a single webpage since it can dynamically pull in cross-site resources at any point in time. So that would also have to be covered by the policy. Questions: 1. Is the above what you are envisioning? 2. Would tying it to a strict CSP work as technical enforcement? 3. Do you have thoughts on how developers can manage their websites to not make a cross-site resource load mistake on some page? As mentioned, CSP is an obvious tool, but one can make mistakes with CSP too.
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.