[Webkit-unassigned] [Bug 246606] [GTK][WPE] Add provision to enable / disable websecurity

[bugzilla-daemon at webkit.org]

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

--- Comment #6 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Miguel Gomez from comment #5)
> Any user that wants to run the browser using a set of pages that are
> controlled by them, and hosted in different places. Or some local pages that
> access resources from trusted sources. We've had several users requesting us
> to disable web security in those situations, as it makes things way simpler
> for them.

Thing is, although you might trust the web content that you're loading, if there's any mistake, say an XSS in the least-secure part of your application, then the weakest web content that you've loaded in the web view effectively has full control over the web view, and can load and script all other origins. And those mistakes are inevitable. (E.g. We've had several XSS in Epiphany.)

There are probably alternative ways to do what you want. If two pages are hosted in different places and want to be controlled by each other, then they can use CSP to loosen the same origin policy just for those pages. Or say Origin A doesn't know about Origin B but the application wants to allow Origin A to be scripted by Origin B anyway, then you can forcibly allow it by injecting your own CSP into the unwilling Origin A using <meta http-equiv=""> tags. Would a strategy like that work for you? It's probably only a little more work, but would better contain the damage if anything goes wrong.

I'm a little conflicted in whether we should accept this or not. Let's say your application has code to refuse to load any web content except a.example.com and b.example.com, then it's probably OK: the same origin policy no longer seems very important. But if the setting is provided, developers are no doubt going to be tempted to turn it on even when it's not a good idea. So I'm a little hesitant to make this easily available for Linux apps to use. Would still like to see more opinions on this.

-- 
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/20221019/e7aef3f4/attachment.htm>