[Webkit-unassigned] [Bug 168631] Feature Request: Make partitioned localStorage persistent

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 21 16:10:53 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=168631

--- Comment #18 from John Wilander <wilander at apple.com> ---
(In reply to Malte Ubl from comment #15)
> Please do not put words in my mouth. All I did, was file a bug because John
> Wilander suggested that there might be a bug. I'd appreciate the bug being
> fixed, because it'd allow me to delete a lot of code, and increase user
> privacy.
> 
> What I am suggesting it to add a feature that provides additional privacy
> control by avoiding data leakage from the 3p to the 1p. This does not add
> any capabilities that aren't already possible. It is a strict privacy win
> for users.
> 
> In our case we are both the 1p AND the (technical) 3p (the iframe is on a
> different origin from the 1p window for security reasons), but we want to
> avoid that the technical 3p having to supply data to the 1p to maintain
> strict separation of data.

Hi Malte!

First, for clarification, this is how I interpret your 1st-party opt-in part:

1) Safari's default policy is to partition and not persist 3rd-party storage such as localStorage and IndexedDB.
2) The 1st-party can offer 3rd-parties to store persistently on their behalf through postMessage.
3) Since many 1st-parties run 3rd-party scripts, those 3rd-parties can set up postMessage-to-store themselves. And allowing 3rd-parties to run script in the 1st-party context can be interpreted as an opt-in to such storage.
4) If 1st-parties "opt in" by running 3rd-party scripts we might as well allow 3rd-parties to persist their partitioned storage under that 1st-party. This could be done through an opt-in attribute named allowStorage or similar.

Am I right so far?

If so, I believe our position is that 3rd-party storage is a user setting, not a 1st-party site setting. The postMessage-to-store practice is an unfortunate trick 3rd-parties can pull to track users but it at least requires them to convince the 1st-party to run their script. I understand the user win in less 3rd-party scripts running in the 1st-party context but I honestly doubt that any trackers are running scripts exclusively for this purpose. Maybe I'm wrong. Do you have experience and/or telemetry there?

Then there's your specific case where you are the 1st-party and the 3rd-party for security reasons. That's your choice, right? You have decided to serve AMP cached content under google.com which is an origin many users authenticate to and an origin that controls those users' email, documents, YouTube data, blogs et cetera. I understand that this creates a security challenge for you but you have full control over this. You can serve the AMP cache from a different origin with significantly less security risk to users, right?

As for the the original request, I interpreted it as you wanting partitioned localStorage to work as partitioned IndexedDB persistence-wise. But you also want a change in Safari's default storage policy now that we've established how things work. Am I right? If so, the default settings part should probably be handled in a separate bug/request.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170421/751c52cc/attachment-0001.html>


More information about the webkit-unassigned mailing list