The mixed content settings are obsolete nowadays. See also: bug #219396. API to expose the internal settings would be at risk, because the internal settings are no longer needed: mixed content was a problem of the 2010s, but we're in the 2020s now and https://w3c.github.io/webappsec-mixed-content/ describes how mixed content should be handled. Then the WebSecurity setting appears to turn off the same origin policy... is this needed for a test harness or something? Surely you don't need this for normal web content? Can you explain your use case?

(In reply to Michael Catanzaro from comment #1) > The mixed content settings are obsolete nowadays. See also: bug #219396. API > to expose the internal settings would be at risk, because the internal > settings are no longer needed: mixed content was a problem of the 2010s, but > we're in the 2020s now and https://w3c.github.io/webappsec-mixed-content/ > describes how mixed content should be handled. > > Then the WebSecurity setting appears to turn off the same origin policy... > is this needed for a test harness or something? Surely you don't need this > for normal web content? Can you explain your use case? The PR we're basing on is not exactly what's going to be implemented. The idea was to check whether the mixed content setting were needed or whether the websecurity one superseeds those. From what you say it seems that the websecurity one should be enough, so we'll go for that only. The use case for the websecurity setting is that some users run their apps in controlled environments and they don't need it, so having it enabled makes things for complicated. Also, for testing and development it's quite convenient.

I suppose the use case is to allow one website that you control to script another website that you don't control? That will make it easier to do evil things, but the app developer using WebKit can inject anything into any page anyway, and it's not a terribly big step from that to allowing web content that you trust to do the same. But then again, it goes both ways: you'd better really trust *everything* that you're loading. I guess it will be OK if only used by apps that load tightly-controlled custom web content, and never used by any normal desktop apps. The disadvantage I see is that some app developer might decide to use it without understanding the consequences.

Can we have more info about the specific use-case that requires disabling same origin policy? Perhaps there's another way to solve the problem.

(In reply to Michael Catanzaro from comment #4) > Can we have more info about the specific use-case that requires disabling > same origin policy? Perhaps there's another way to solve the problem. 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. There shouldn't be much trouble adding this setting and keeping it disabled. It's up to the users if they want to disable it because they trust the set of pages they are loading.

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

Michael, would you feel better if we had a build option to enable/disable that setting? The distros could build with the option disabled so they can't disable websecurity, but those who want something more specific could choose to enable the setting.

Nah, I would just add it if you're certain you really need it. (Gating a public API behind a build option that would be off by default doesn't seem great.)

Pull request: https://github.com/WebKit/WebKit/pull/6128

Committed 258707@main (88ecd4bb2c64): <https://commits.webkit.org/258707@main> Reviewed commits have been landed. Closing PR #6128 and removing active labels.