Re: [w3c/ServiceWorker] Refinements and description of Service-Worker-Allowed. (#1409)

jakearchibald approved this pull request.

Just a couple of nits to fix, then feel free to merge.

> @@ -2119,6 +2119,26 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe

     [=/Service workers=] enable this by allowing {{Cache|Caches}} to [=/fetch=] and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in the {{Cache}} as {{Response}} objects whose corresponding [=Response/responses=] are <a>basic filtered response</a>, the objects stored are {{Response}} objects whose corresponding [=Response/responses=] are either <a>CORS filtered responses</a> or <a>opaque filtered responses</a>. They can be passed to {{FetchEvent/respondWith(r)|event.respondWith(r)}} method in the same manner as the {{Response}} objects whose corresponding [=Response/responses=] are <a>basic filtered responses</a>, but cannot be meaningfully created programmatically. These limitations are necessary to preserve the security invariants of the platform. Allowing {{Cache|Caches}} to store them allows applications to avoid re-architecting in most cases.
   </section>
 
+  <section>
+    <h3 id="path-restriction">Path restriction</h3>
+
+    *This section is non-normative.*
+
+    In addition to the [[#origin-restriction|origin restriction]], service workers are restricted by the [=url/path=] of the service worker script. For example, a service worker script at <code>https://www.example.com/~bob/sw.js</code> can be registered for the [=scope=] <code>https://www.example.com/~bob</code> but not for the scope <code>https://www.example.com</code> or <code>https://www.example.com/~alice</code>. This provides some protection for sites that host multiple-user content in separated directories on the same origin. However, the path restriction is not considered a hard security boundary, as only origins are. Sites are encouraged to use different origins to securely isolate segments of the site if appropriate.

```suggestion
    In addition to the [[#origin-restriction|origin restriction]], service workers are restricted by the [=url/path=] of the service worker script. For example, a service worker script at <code>https://www.example.com/~bob/sw.js</code> can be registered for the [=scope=] <code>https://www.example.com/~bob/</code> but not for the scope <code>https://www.example.com/</code> or <code>https://www.example.com/~alice/</code>. This provides some protection for sites that host multiple-user content in separate directories on the same origin. However, the path restriction is not considered a hard security boundary, as only origins are. Sites are encouraged to use different origins to securely isolate segments of the site if appropriate.
```

Adding a trailing slash to the URLs, as `https://www.example.com/~bob/sw.js` won't be able to register for scope `https://www.example.com/~bob`.


> @@ -2119,6 +2119,26 @@ spec: webappsec-referrer-policy; urlPrefix: https://w3c.github.io/webappsec-refe

     [=/Service workers=] enable this by allowing {{Cache|Caches}} to [=/fetch=] and cache off-origin items. Some restrictions apply, however. First, unlike same-origin resources which are managed in the {{Cache}} as {{Response}} objects whose corresponding [=Response/responses=] are <a>basic filtered response</a>, the objects stored are {{Response}} objects whose corresponding [=Response/responses=] are either <a>CORS filtered responses</a> or <a>opaque filtered responses</a>. They can be passed to {{FetchEvent/respondWith(r)|event.respondWith(r)}} method in the same manner as the {{Response}} objects whose corresponding [=Response/responses=] are <a>basic filtered responses</a>, but cannot be meaningfully created programmatically. These limitations are necessary to preserve the security invariants of the platform. Allowing {{Cache|Caches}} to store them allows applications to avoid re-architecting in most cases.
   </section>
 
+  <section>
+    <h3 id="path-restriction">Path restriction</h3>
+
+    *This section is non-normative.*
+
+    In addition to the [[#origin-restriction|origin restriction]], service workers are restricted by the [=url/path=] of the service worker script. For example, a service worker script at <code>https://www.example.com/~bob/sw.js</code> can be registered for the [=scope=] <code>https://www.example.com/~bob</code> but not for the scope <code>https://www.example.com</code> or <code>https://www.example.com/~alice</code>. This provides some protection for sites that host multiple-user content in separated directories on the same origin. However, the path restriction is not considered a hard security boundary, as only origins are. Sites are encouraged to use different origins to securely isolate segments of the site if appropriate.
+
+    Servers can break the path restriction by setting a [=Service-Worker-Allowed=] header on the service worker script.

```suggestion
    Servers can remove the path restriction by setting a [=Service-Worker-Allowed=] header on the service worker script.
```

Just a nit. Feel free to ignore.

>            1. Let |scopeString| be "<code>/</code>" concatenated with the strings in |scopeURL|'s [=url/path=] (including empty strings), separated from each other by "<code>/</code>".
-          1. If |scopeString| starts with |maxScopeString|, do nothing.
+          1. If |maxScopeString| is not null and |scopeString| starts with |maxScopeString|, do nothing.

 Nit: Seems like a good opportunity to flip this around.

```
1. If |maxScopeString| is null or |scopeString| does not start with |maxScopeString|, then:
    1. Invoke [=Reject Job Promise=]…
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1409#pullrequestreview-242600032