What's the interaction with referrer policy

[jeisinger]

How can a service worker specify a referrer policy to use? According to http://www.w3.org/TR/2014/WD-referrer-policy-20140807/ a worker will always use the "default" policy.

I guess for service workers, it would be desirable to be able to specify a non-default policy somehow.

Feedback plz?

/cc @mikewest

[mikewest]

+@jakearchibald, @slightlyoff, @annevk

[jakearchibald]

The worker default "none-when-downgrade" seems fine.

I guess for service workers, it would be desirable to be able to specify a non-default policy somehow.

Can SharedWorkers set it via the Content-Security-Policy HTTP header? If so, we should do the same.

[jeisinger]

no, they can't.

At least in blink and webkit, all requests originating from any kind of worker are forced to the default policy.

I wonder whether service workers should be allowed to specify the policy per fetch they trigger?

[jakearchibald]

Feels weird to do something special for ServiceWorker vs SharedWorker (or even DedicatedWorker?).

I wonder whether service workers should be allowed to specify the policy per fetch they trigger?

I guess that could be an option on http://fetch.spec.whatwg.org/#requestinit. Pages would get the feature too. Or let developers spoof referrer to anything on the origin. @annevk?

[annevk]

I thought service workers could have a CSP policy of their own. That seems to be at least required for shared workers, which includes service workers.

(We will offer a a feature for fetch() in due course to omit the header, not sure if we will provide for an override policy. An override policy has some extra considerations that might warrant support in the original specification. E.g. who wins with loosening.)

[annevk]

So what @jeisinger describes above seems like a bug in Blink. CSP should work for workers. Anything else that blocks closing this?

[jeisinger]

Yeah, I guess specifying a policy via CSP makes sense. We should probably allow that for all kinds of workers.

[jeisinger]

Sorry for the long delay.

After thinking more about this, I guess what we really need is a way to specify a referrer policy for fetch(). Maybe also a way to query one from an onfetch event?

[annevk]

You will need to elaborate a bit since I don't follow.

[jeisinger]

sorry

So basically, there are three scenarios where the referrer policy and service workers will get in contact:

1) the service worker itself is loaded: which referrer policy should be used for that? (and which referrer...)

2) A controlled page requests a resource using a certain referrer policy: Here the service worker should have a way to figure out which referrer policy was set by the page

3) The service worker itself loads a resource: Here, the service worker should have a way to define the referrer policy to use.

[annevk]

1) It seems for the initial load the referrer policy is that of the document or worker that invokes register(). Subsequent loads for updates won't have a referrer, unless perhaps update() was invoked. Depends a bit on how that is defined. @jungkees should know.

2) The service worker can figure out what the page wanted as referrer through Request.prototype.referrer. However, the service worker currently has no way to pass this through. For that we would need to allow setting the referrer to any same-origin URL I think.

3) That uses the referrer policy of the service worker itself. Just like fetches use the CSP policy of the service worker.

[jeisinger]

2) does Request.prototype.referrer expose the referrer policy as well?

3) at least in chrome that's not implemented (and the referrer spec doesn't mention that either). Anyway, I guess changing it to take whatever the CSP says is probably fine, but I wonder whether we'd want to allow for setting a different policy on a per request basis

[annevk]

2) It doesn't. You could infer it I suppose?

3) I think we do want to allow control over referrer. That should perhaps be a distinct issue. The question is how much. E.g. if we want to emulate the referrer that is the page, we actually need to be able to set referrer to any same-origin URL.

[jeisinger]

2) I wouldn't know how you could infer this information

3) I guess I'll update the referrer spec to say that a worker in general should use whatever the CSP header says and we can revisit this discussion in the future

[annevk]

2) The referrer that is exposed is already modified as per the page's policy.

3) Each worker has its own environment settings object (and therefore CSP policy, referrer policy, service worker). How did workers work so far?

[jeisinger]

2) right, but it doesn't tell you which policy, e.g. you might not be able to tell the difference between origin and origin-when-cross-origin

3) so far, the policy for workers is always "default" (i.e. none-when-downgrade)

[annevk]

2) True. We could expose the various policies on service worker's Client objects at some point I suppose. But it won't matter much until we actually allow setting referrer.

[jungkees]

1) It seems for the initial load the referrer policy is that of the document or worker that invokes register(). Subsequent loads for updates won't have a referrer, unless perhaps update() was invoked. Depends a bit on how that is defined. @jungkees should know.

Yes, it sounds reasonable that fetching a service worker triggered by either navigator.serviceWorker.register() or registration.update() uses a referrer and a referrer policy of its associated service worker clients (the environment settings object of the document or the worker), and the updates triggered by user agents (by invoking Soft Update algorithm) use no referrer and no referrer policy. I think I'll need to update some bits: making registration.update() invoke Update algorithm rather than Soft Update algorithm, setting relevant clients for requests, etc.

[jungkees]

@annevk the requests for fetching a service worker initiated from Soft Update algorithm don't involve an environment settings object (i.e. request's client would be null or empty object?). AFAIK, Fetch uses request's client not only to set the request's referrer but also to refer to its TLS state, global object and to locate the responsible event loop, etc. Do you have any idea how to deal with those requests initiated from within user agent's internal context?

[annevk]

I don't. That's somewhat new. File a bug?

[jungkees]

Set request's client to the associated service worker client for register()/update(): 9c15df90abb9ad50b250b92362d629920e8079f4.

[annevk]

Since https://github.com/slightlyoff/ServiceWorker/issues/615 the client for Fetch can be null. I still haven't heard anyone express opinions about control over the Referrer header. In my opinion we should allow any same-origin URL (that is then subject to the Referrer Policy), but since nobody has really supported that I haven't made any move. If someone is interested I recommend filing an issue against https://github.com/whatwg/fetch and we'll make it work somehow.

Nothing else seems open here.

[mfalken]

Update: https://github.com/whatwg/fetch/issues/80 solved this.