[Webkit-unassigned] [Bug 156651] [GTK] Expose AllowUniversalAccessFromFileURLs preference now that calling localStorage.getItem() results in SecurityError: DOM Exception 18

[bugzilla-daemon at webkit.org]

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

--- Comment #33 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #32)
> I still kinda think the best option is just to add the new API, even in a
> stable release, because I think very few apps will be affected by this.
> 
> (In reply to comment #30)
> > It's not actually changing the semantics, it's just assuming that if you
> > enabled that setting is because your app is serving file URIs and you also
> > want to allow access to the local storage, for backwards compatibility only.
> 
> I guess it's OK to do this for 2.12 only, to unblock this, but then apps are
> going to have to change twice: once now to use AllowFileAccessFromFileURLs
> if they didn't already have that set (does this lightdm greeter use that?),
> and again in five months to switch to AllowUniversalAccessFromFileURLs
> because AllowFileAccessFromFileURLs won't work anymore in 2.14. (Surely we
> do not want the semantics of our setting to differ from Apple's going
> forward.)

No, that's not the point at all. Apps should not need to adapt anything, that's why I don't want to add a new setting, I'm assuming that aps already use AllowFileAccessFromFileURLs, which I think is the case lightdm, the only app we know that is affected by this.

> > That's why my initial proposal was to limit it to apps already enabling file
> > access. We could also check the document URL to see if it's a local file,
> > but it could be a custom URI scheme or a resource:/.
> 
> I don't think this wins much; if apps using AllowFileAccessFromFileURLs
> allow opening untrusted files, then that's already more serious than
> allowing access to localStorage.

The point is simply that apps don't need to do anything.

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