Can I remove the --disable-web-security flag?

[Justin Schuh]

I don't know the original reason for this flag, but it's the metaphorical equivalent of going outside without an immune system... or skin. And I occasionally see it recommended to "solve" security problems. Unless we have a compelling reason for keeping it around, I'd like to remove it entirely.

-j

[Jake]

Please don't. Some of us use that flag for situations where web security is not required, and really gets in the way.

On Wed, Jun 13, 2012 at 6:47 PM, Justin Schuh <jsc...@chromium.org> wrote:

I don't know the original reason for this flag, but it's the metaphorical equivalent of going outside without an immune system... or skin. And I occasionally see it recommended to "solve" security problems. Unless we have a compelling reason for keeping it around, I'd like to remove it entirely.

-j

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Jake]

We have several applications that do complicated processing involving multiple sites, and being able to turn off security really makes things simpler and easier to maintain.

If you remove the flag then I'll have to do a special build locally that disables all of the same things the flag does, which will make it extremely difficult to track chromium changes.

On Wed, Jun 13, 2012 at 6:53 PM, Fred Akalin <aka...@google.com> wrote:

What are these situations?

[Justin Schuh]

Is there a reason why you can't address this use-case with a custom extension? That seems far more reasonable than disabling the entire Web security model.

-j

[William Chan (陈智昌)]

Who uses these web apps? Are these people using Google Chrome for normal web browsing too in addition to running these web applications? If so, that would be very unfortunate to have them running with web security disabled.

On Wed, Jun 13, 2012 at 6:14 PM, Jake <ja...@jakeonthenet.com> wrote:

[Peter Mayo]

Perhaps this flag should be removed in official builds?  I.e. you don't get Chrome running like this, but if people want to build Chromium based apps, or use a suitably custom technology with it, more power to them.  But it's not Chrome-secure.

In the metaphor, just because you're using a door, it doesn't mean you're going outside.

[Mark Larson (Google)]

On Wed, Jun 13, 2012 at 8:26 PM, Peter Mayo <pete...@chromium.org> wrote:

Perhaps this flag should be removed in official builds?  I.e. you don't get Chrome running like this, but if people want to build Chromium based apps, or use a suitably custom technology with it, more power to them.  But it's not Chrome-secure.

+1. It should be simple to make the flag a noop if GOOGLE_CHROME, no? Or to tweak the code so that it only works if some GYP define is set (so embedders/ports could enable it if it makes sense).

--Mark

[Chris Evans]

On Wed, Jun 13, 2012 at 8:33 PM, Mark Larson (Google) <m...@chromium.org> wrote:

On Wed, Jun 13, 2012 at 8:26 PM, Peter Mayo <pete...@chromium.org> wrote:

Perhaps this flag should be removed in official builds?  I.e. you don't get Chrome running like this, but if people want to build Chromium based apps, or use a suitably custom technology with it, more power to them.  But it's not Chrome-secure.

+1. It should be simple to make the flag a noop if GOOGLE_CHROME, no? Or to tweak the code so that it only works if some GYP define is set (so embedders/ports could enable it if it makes sense).

Another option is to re-use the same infobar we use if Chrome is launched with (e.g.) --single-process or --no-sandbox.

[Scott Hess]

I was thinking maybe the flag could work, but only allow browsing
non-FQDNs. So you could use it in concert with localnet hosts, but
not on the wider Internet.

-scott

[Jake]

No, these apps are run using a custom install of Chromium, never in Google Chrome.

I like the idea of allowing the flag in non-official/Chromium builds - that would work fine for me.

[Jake]

I'd have to educate our web team on writing extensions. I tried going down this path, but they freaked :(

[David Souther]

This flag makes complex multi-subdomain automated testing possible. We load the testing site (www.nytimes.com) in an iframe, then drive it from the harness (localhost:9876). With web security, we have to have a ridiculously complex proxy layer in the middle equating the domains. Without, it just runs. It's an opt-in runtime flag, are people really accidentally starting Chrome with it on?

-DS

[László Lajos Jánszky]

Same here, I use it for end to end testing with Karma. From today I can access only localhost origins with it. I guess somebody thought it is a good idea to do the changes without asking anybody... :S

[Charlie Reis]

The change in behavior is probably because cross-site pages no longer run in the same process, once Site Isolation launched.  Thus, even when you turn off security in the renderer process, it's not possible to access pages running in a different process.  You can probably work around that for now using --disable-site-isolation-trials together with --disable-web-security.

We're interested in a longer-term solution for debugging that doesn't rely on --disable-web-security, with the beginnings of a discussion on https://crbug.com/327804.

Charlie

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/82f0bfd2-6df4-4a2b-b308-938e7d78c838%40chromium.org.

[László Lajos Jánszky]

Thanks!

It works with  `--disable-site-isolation-trials` for remote origins, but for the error protocol (Chrome error pages) it does not work. I use that to detect mistyped addresses mostly. Still it is a big help, I might be able to catch the security error now for wrong addresses.

[László Lajos Jánszky]

Any idea how I can access Chrome error pages with the `error:` protocol? With Chrome v68 I was able to, now even with disabled site isolation I got a security error when trying to access the location object. I cannot distinguish the bad address and the bad environment errors this way. :S

[Nasko Oskov]

Chrome error pages are now isolated in a matter similar to how site isolation works. There is no plan to allow disabling this behavior, as it both makes the browser less secure and the codebase more complex. I would be happy to help brainstorm how testing frameworks can implement the testing facilities in a way that is compatible with the isolation primitives that Chrome is using. The disable flag you are using will likely disappear in the not-so-distant future as well, so updating testing frameworks is definitely going to be beneficial.

Thanks!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/b871c63a-8a48-471a-b4e7-f23ad4875b77%40chromium.org.

[László Lajos Jánszky]

As I already wrote I disabled site isolation with a CLI flag. I can access for example google.com from localhost, but not the Chrome error pages...

[Nasko Oskov]

Yes. Error pages are isolated similarly to site isolation, but are not governed by the site isolation flag. I'm happy to help and contribute knowledge of how the browser works to improve testing frameworks, since we won't have the flags to disable isolation forever.
Thank you for contributing your feedback on https://crbug.com/327804. It will be useful case to consider in how to provide testing capabilities without completely disabling all security in the browser.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/3e6b20fb-5635-410e-b34e-744eab1694e5%40chromium.org.