Re: [w3c/ServiceWorker] Foreign fetch vs non-credentialed requests (#878)

> I think the main problem with foreign fetch is the third-party cookie problem as I outlined on blink-dev. Safari has a fundamentally different way of dealing with third-party storage that is arguably better for users. If user agents aligned on that, much of foreign fetch would not work well due to it being double-keyed. So we'd need to work that through first and figure out the more fundamental architecture around third-party storage.

Are there any proposals for supporting double-keying here?  I am doubtful.  Fundamentally:

1. Double-keying is designed to prevent 3rd party origins from maintaining shared state.
2. Foreign fetch is about enabling 3rd party origins to maintain state to enable optimizations or other features.

These are diametrically opposed.  I am having a hard time envisioning a solution that satisfies both goals.

>From my perspective foreign fetch is a progressive enhancement.  It can be present for credentialed requests where the user is willing for 3rd party origins to maintain state about them.  It can also be disabled if the user signals they don't want 3rd party origins to maintain state.

-- 
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/issues/878#issuecomment-290629448