Reopening as Safari has addressed this reportedly and standards-wise it's still an issue: https://github.com/w3c/ServiceWorker/issues/719#issuecomment-662900026.

Before we do anything here I think we should be super mindful about negative effects on ability to write offline web applications.

In particular, a website can already read large parts of the contents of unprotected CSS files. What this bug suggests is that we specifically protect values that contain URLs, while leaving the other parts of the CSS file just as exposed as before.

As a developer, it seems really risky to rely on the default SOP to protect the contents of CSS files given how much of the file contents that is readable across sites.

A better solution to me seems to be to enable solutions that enable protecting the entire contents of CSS files, images, scripts and other resources that can be embedded (and thus partially read) cross origin.

It's definitely true that leaving this bug unfixed could cause a security issue. I.e. where there's a CSS file that contains sensitive URLs but not other sensitive CSS values. But the same argument can be made about many changes to CSS syntax, such as with the introduction of variables. They too expanded the set of files which could theoretically now expose sensitive information to an attacker. Do we know of any such instances in the few years since Service Workers or CSS variables were shipped?

Additionally, some of the URLs that we're trying to protect here will still be exposed in the form of computed values on elements in the DOM.

In short, I think implementing the proposal here has significant cost for web developers, both in terms of reduced features, and in terms of a more complex security model. And the benefit seems mainly theoretical to me?

Separately, would Chrome and Safari be willing to fix [1]? If not would there actually be any security benefit for web developers?

[1] https://jsbin.com/pigihubuxa/edit?html,output

Hi Anne, can you investigate further what should be our path forward here? Thank you!

I agree with Jonas that the situation isn't exactly great here and anyone putting secrets in CSS resources is well-advised to use Cross-Origin-Resource-Policy or equivalent.

Fixing this would help with:

1. Inadvertently leaking secret URLs in @import and similar rules not directly exposed through computed styles.
2. Leaking information about the resources tied to those secret URLs through timing attacks on caches or fetching, or equivalent attacks. (At least, it seems this would be a lot harder if you do not get granular information through service workers.)
3. Leaking secret URLs in rules that are guarded by selectors that are (close to) impossible to match.
4. Moving the web platform to a state that's acceptable to everyone (as per comment 65 Safari is shipping this).
5. Making it clear we take exceptions to the same-origin policy seriously.

So overall I continue to recommend we fix this in due course. Hope that helps.

It seems to me that without Chrome and Safari fixing the issue in comment 67 point 1 and 3 does not seem to apply. I.e. authors would still be leaking secrets in those URLs.

It seems like currently we're aligned with Chrome, but fixing this issue would align us with Safari. So it doesn't seem like fixing this issue would get us closer to consensus? Or has Google signaled that they are planning on fixing this issue?

As for point 5, has there been concern raised publicly that Mozilla is not taking SOP seriously? If anything, Mozilla has been pushing for CORS when other vendors have not, for example for video, fonts and sendBeacon().

This leaves point 2, which I honestly don't understand so I'll assume it is valid.

I don't see how comment 67 exposes URLs not exposed through computed styles. It seems this will be discussed as part of https://github.com/w3c/ServiceWorker/issues/1536 and I'll try to attend that (and other things mentioned there).