Re: [w3c/ServiceWorker] "no-cors" CSS SOP violation (#719)

F2F: This was discussed partly in WebAppSec and in a dedicated breakout session:
- https://www.w3.org/2018/10/23-webappsec-minutes.html#item12
- https://www.w3.org/2018/10/24-csssop-minutes.html

If I may attempt a summary.

Arguments in favor of making the requests skip the service worker:
- It's arguably a SOP bypass.
- There have been real instances of CSS leaking private data, ca. 2011 (Eric Lawrence to try to provide more details about this).
- Firefox changed to at least partially block this for Resource Timing: https://bugzilla.mozilla.org/show_bug.cgi?id=1180145
- Allowing a SOP bypass because it's already exposed via other APIs or side-effects seems unsatisfying; not moving where we want to be.

Arguments in favor of going to the service worker:
- The information is already exposed via Resource Timing; getComputedStyle(); and side-effects of the import itself on geometry/etc.
- Changing the behavior now could break sites.
- It would become difficult to explain to developers when subresource requests go to the service worker and when they don't.
- There would be some complexity in specing/implementing skipping, due to nested imports and redirects.

Observations:
- Any new APIs won't make subresource requests from no-cors contexts. If we were to start from scratch, we'd have made CSS cors-only.
- A core problem is there is no way for developers to make cors `import` requests. You can only do cors from `<link>`.

Outcomes:
- We want to timebox this decision (there were some references to mid-November, or this year).
- Youenn (WebKit) is to check internally to try to make a decision about what they want to do.
- @wanderview (Chrome) volunteered to add metrics to estimate how many sites would be affected.

(I don't know how to cc Eric L or Youenn on GitHub.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/719#issuecomment-433819735