- From: Andrew Sutherland <notifications@github.com>
- Date: Sat, 04 Jun 2016 04:42:41 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc:
- Message-ID: <slightlyoff/ServiceWorker/issues/902/223751206@github.com>
The point is that Service Workers are: 1. Cached. 2. Able to modify all future network requests issued by the origin in question, including: future JS loads, stripping requests by the site to register its own service worker, or just redirecting all traffic to the attacker's own site, etc. It is indeed a problem in the first case if an attacker is able to execute JS in an origin they should not be able to. But what you're requesting allows the attack to perpetuate itself after the original intrusion mechanism may have been fixed. In my previous comment I used the term XSS as a shorthand for cases that are not strictly XSS; the attacker could also compromise JS hosted on third-party domains. It's a reality of the web and net that: - Sites will have security flaws that allow XSS attacks, despite new technologies like CSP that make it easier to prevent them. - Sites will get hacked. - Dangerous functionality implemented in standards for the benefit of a few reduces the security of all. - Complicating standards and thereby implementations to make potentially dangerous things safer for niche use-cases also reduces the security of all. In any event, it's not clear what your actual use-case is. What is it you are trying to do that needs service worker functionality but cannot host a single JS file? Your use-case may actually want something more "app" like as offered by browser extensions/add-ons. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/902#issuecomment-223751206
Received on Saturday, 4 June 2016 11:43:09 UTC