Need for linkable and reusable section that defines the https restriction

[mvano]

The Push API needs to use the exact same https-based security restriction as Service Workers which appears to be here:
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#security-considerations

Specifically, the definition should not mention Service Workers as it currently does, instead the Service Workers spec should link internally to this reusable concept.

The "sufficiently secure context" concept from Requirements for Powerful Features [1] is too lenient because it e.g. permits file schemes when determining whether the origin is trustworthy [2].

[1] http://www.w3.org/TR/powerful-features/#sufficiently-secure-context
[2] http://www.w3.org/TR/powerful-features/#is-origin-trustworthy

CC @mikewest

[annevk]

What is wrong with trusting the file URL scheme?

[annevk]

You want to reference that concept either way. If you have some other restrictions you'll need to state those in your own document and perhaps communicate those back. (File URLs won't work for service workers of course as the service worker itself requires https which won't be same-origin with a file URL.)

[mounirlamouri]

Why file: coludn't work with a SW? I mean, why SW should require https instead of rely on powerful-features?

Though, I agree with @annevk, I think SW should point to powerful-features and maybe add prose about such and such scheme being not considered trustworthy in the context of SW.

[annevk]

@mounirlamouri we want the service worker script to be a networked resource so it can be updated. I think the specification requires https for that at the moment. I guess you could try to make it work locally, but I think that will fall apart given Chrome's origin policy for file URLs pretty quickly.

[jungkees]

Note that SW refers to powerful features to check the security context (in Register algorithm step 1.) Will update the section 6 as such.

For file scheme, I'll add text for the exception in the algorithm and the relevant part of the section 6.

[mikewest]

@mvano what would you like the POWER spec to give you? If there is some reasonable flag we could pass to the algorithm to give you the right answer, I'm happy to do so.

That said, there are likely better ways to accomplish your goal: for instance, should SW work inside a sandbox? If not, you could key the registration against origins which are globally unique identifers. That (doesn't yet, but hopefully will soon) include file:.

[mvano]

@mikewest: Maybe we can pass in a list of whitelisted schemes e.g. ['https']? It should still permit localhost regardless of scheme.

I'm not sure how the second part would help, perhaps I'm misreading it.

[jungkees]

I added a text about using secure context for SW in the Security Considerations section: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#secure-context. I agree we should largely defer to what the Secure Context spec defines. Note that "file" scheme and "wss" scheme are filtered out when it gets to fetch.

@mvano let me close the issue. If you have further concerns/needs about the use of secure contexts in SW spec, please feel free to re-open it.