Multi-author sites

[mnot]

As discussed, https:// sites that have multiple authors may be surprised to discover that user a can now overwrite content for user b.

What's needed:

1. text (Security Considerations?) explaining the attack
2. evangelisation to warn sites
3. maybe a csp-ish opt-out (or -in, but @slightlyoff isn't hot on that)

Will do a pull for 1.

[slightlyoff]

There has been quite a lot of further discussion on this point. Looks like we're going to sacrifice this goat to accommodate sites which, frankly, are already broken. Le sigh.

We're likely going to go with a CSP-based OPT IN to enable Service Workers. The straw man is to require a CSP header for the on-origin SW script.

Thoughts?

[KenjiBaheux]

Filed crbug.com/423983 for tracking in Blink

[annevk]

The amount of developer hurdles keeps growing, but we have required opting into Danger Zone for less.

Are we still requiring that the SW is served with a correct JavaScript MIME type?

A CSP header on the SW script itself affects what the SW can do. It would make more sense to me if the opt-in came with the document or worker that wanted to use a SW.

[slightlyoff]

Yes, still requiring valid JS. The CSP header affecting what the SW can do seems good? We want more people setting CSP, no?

Do you have a straw-man for another way of doing this that you prefer?

[annevk]

A new token for Content-Security-Policy: serviceworker. To be set by global environment that is to register service workers rather than the service worker script.

[inexorabletash]

We need to make sure some spec says you can't set this new CSP token via meta tags.

(I'm a CSP n00b, but it looks like this is the first opt-in CSP directive? Are there any other places where the general opt-out design of CSP will require special handling?)

[jakearchibald]

I don't think page-based CSP is a good idea here, the impact of a SW is beyond the page. Also, CSP is so-far opt-out, and we're proposing opt-in.

I think we should reconsider the SW script location when it comes to scope. /~jakearchibald/my/app/sw.js may not be registered for scopes wider than /~jakearchibald/my/app/. There's been confusion about this when I've proposed this in the past, so I want to stress that it's the location of the serviceworker script that limits scope, and not the registering page.

The benefit of this is we don't break hosts that are safe, such as github.

If we must go for an opt-in solution, I'd rather we went for a content type like application/serviceworker+javascript, or application/javascript;serviceworker, or something along those lines. But I much prefer a solution that doesn't break hosts that happily give you your own origin.