Pace the discussion in #224, there is renewed interest in figuring out some way to make it less onerous for sites that host many user's content on a single origin to avoid URL-space bun-fights and malicious "takeover" using SWs.
At some level this is theater. Many other resources can be poisoned. We don't have any concept of "sub-origin" today and the SW design is the wrong place to construct such a thing.
So, noting the above, is it still meaningful to restrict scopes? E.g., the restriction might be that a visit to https://example.com/app/index.html would only allow registration for https://example.com/app/* but not https://example.com/* or https://example.com/otherstuff/*.
This restriction would be in addition to the other restrictions currently placed on SW registrations, namely: SSL-only, same-origin-hosted SW scripts, and 24-hour max caching before update pings sent to the server. It would likewise be additive to proposed mitigations against compromise (e.g., #224).
From the spec side, this has some issues:
It gets us in the business of reasoning about path separators in URLs and imbuing them with more meaning.
We'd have to change the meaning of the default scope from "*" "the current path minus any terminal location + "/*""
The restriction is likely to be misunderstood as providing some sort of stronger security guarantee/isolation than it can actually provide.
annevk
commented
10 years ago
Pace the discussion in #224, there is renewed interest in figuring out some way to make it less onerous for sites that host many user's content on a single origin to avoid URL-space bun-fights and malicious "takeover" using SWs.
At some level this is theater. Many other resources can be poisoned. We don't have any concept of "sub-origin" today and the SW design is the wrong place to construct such a thing.
So, noting the above, is it still meaningful to restrict scopes? E.g., the restriction might be that a visit to
https://example.com/app/index.htmlwould only allow registration forhttps://example.com/app/*but nothttps://example.com/*orhttps://example.com/otherstuff/*.This restriction would be in addition to the other restrictions currently placed on SW registrations, namely: SSL-only, same-origin-hosted SW scripts, and 24-hour max caching before update pings sent to the server. It would likewise be additive to proposed mitigations against compromise (e.g., #224).
From the spec side, this has some issues:
"*""the current path minus any terminal location +"/*""/cc @phuu @jakearchibald @devd @sicking @shinypb @mikewest @annevk @abarth