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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 21 15:18:01 PDT 2017


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

--- Comment #16 from Brady Eidson <beidson at apple.com> ---
(In reply to Malte Ubl from comment #15)
> Please do not put words in my mouth. 

I don't believe I did - I asked two clarifying questions to make sure I understood precisely your meaning. This is why my comments were in the form questions.

> All I did, was file a bug because John Wilander suggested that there might be a bug. 

I understand that. While he suspected there might be a bug, we've established at this point that there's no bug. WebKit is behaving as designed.

> I'd appreciate the bug being fixed, because it'd allow me to delete a lot of code, and increase user
> privacy.

Again, we haven't reached an understanding on how making 3rd party storage persistent when the user has blocked 3rd party storage increases their privacy.

I'm trying to understand how this helps the user, but if the description of how it helps them is somewhere in this discussion I missed it.

> 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. 

But... you are directly asking for something that is currently impossible; For persistent 3rd party storage when the user has blocked 3rd party storage.

> It is a strict privacy win for users.

As mentioned above, I don't understand how making 3rd party storage persistent when the user has blocked 3rd party storage 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.

I understand this is what you want.

-- 
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/35134454/attachment.html>


More information about the webkit-unassigned mailing list