Why do service workers only work over HTTPS?

问题:

Per the original proposal, regarding "Prefer Secure Origins For Powerful New Features"

“Particularly powerful” would mean things like: features that handle personally-identifiable information, features that handle high-value information like credentials or payment instruments, features that provide the origin with control over the UA's trustworthy/native UI, access to sensors on the user's device, or generally any feature that we would provide a user-settable permission or privilege to. Please discuss!

“Particularly powerful” would not mean things like: new rendering and layout features, CSS selectors, innocuous JavaScript APIs like showModalDialog, or the like. I expect that the majority of new work in HTML5 fits in this category. Please discuss!

Yet for some reason service workers have been thrown into the first category. Is there any canonical reason for why this happened?

回答1:

Jake Archibald from Google in official Service Workers draft spec sandbox, later cited by Matt Gaunt from HTML5rocks states that

Using service worker you can hijack connections, fabricate, and filter responses. Powerful stuff. While you would use these powers for good, a man-in-the-middle might not. To avoid this, you can only register for service workers on pages served over HTTPS, so we know the service worker the browser receives hasn't been tampered with during its journey through the network.

回答2:

To me this applies to ServiceWorker:

features that handle personally-identifiable information, features that handle high-value information like credentials or payment instruments

Being basically a proxy between the page and the server a ServiceWorker can easily intercept, read and potentially store each information contained into each request and response travelling from the origin, included personally identifiable information and passwords.