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.

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

What are these situations?

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

Post by 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
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

[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

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

What are these situations?

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

Post by 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
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

[Jake]

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

Post by 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

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

What are these situations?

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

Post by 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
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

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

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

What are these situations?

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

Post by 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
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

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


On Wed, Jun 13, 2012 at 10:57 PM, William Chan (陈智昌)

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

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

What are these situations?

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

Post by 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
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

[Mark Larson (Google)]

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

+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

Post by Peter Mayo
In the metaphor, just because you're using a door, it doesn't mean you're
going outside.
On Wed, Jun 13, 2012 at 10:57 PM, William Chan (陈智昌) <

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

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

What are these situations?

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

Post by 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
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

[Chris Evans]

Post by Mark Larson (Google)

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

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

Post by Mark Larson (Google)
--Mark

Post by Peter Mayo
In the metaphor, just because you're using a door, it doesn't mean you're
going outside.
On Wed, Jun 13, 2012 at 10:57 PM, William Chan (陈智昌) <

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

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

What are these situations?

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

Post by 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
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

[Scott Hess]

Received: by 10.224.108.202 with SMTP id g10mr564327qap.8.1339648592563;
Wed, 13 Jun 2012 21:36:32 -0700 (PDT)
X-BeenThere: chromium-***@chromium.org
Received: by 10.229.106.205 with SMTP id y13ls61549qco.1.gmail; Wed, 13 Jun
2012 21:36:25 -0700 (PDT)
Received: by 10.224.192.133 with SMTP id dq5mr1739915qab.51.1339648585051;
Wed, 13 Jun 2012 21:36:25 -0700 (PDT)
Received: by 10.224.192.133 with SMTP id dq5mr1739912qab.51.1339648585040;
Wed, 13 Jun 2012 21:36:25 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176])
by mx.google.com with ESMTPS id dr7si6139717qab.48.2012.06.13.21.36.25
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 13 Jun 2012 21:36:25 -0700 (PDT)
Received-SPF: pass (google.com: domain of ***@google.com designates 209.85.216.176 as permitted sender) client-ip 9.85.216.176;
Received: by qcsc21 with SMTP id c21so953475qcs.21
for <chromium-***@chromium.org>; Wed, 13 Jun 2012 21:36:24 -0700 (PDT)
Received: by 10.229.135.202 with SMTP id o10mr170425qct.19.1339648584749;
Wed, 13 Jun 2012 21:36:24 -0700 (PDT)
Received: by 10.229.135.202 with SMTP id o10mr170411qct.19.1339648584517; Wed,
13 Jun 2012 21:36:24 -0700 (PDT)
Sender: ***@google.com
Received: by 10.229.18.1 with HTTP; Wed, 13 Jun 2012 21:36:24 -0700 (PDT)
In-Reply-To: <CAA4WUYji5JmHfy+jb�SJaUji8+***@mail.gmail.com>
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQm/WHGxekoP0lhCwcxO9rG8+Q0eWvefADaSp23s3u8qTF1gqC6WQL+6ARrebQ8G3Mlju5zHtSnnYRZkLdnD/vw1sZf07HdZiaH3NPSMIzVatyWar4Iks+Ns+OqNMaXii3xN5mzBOFW6P0vBoxE+8WHK6XXGmw=X-Original-Sender: ***@google.com
X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain
of ***@google.com designates 209.85.216.176 as permitted sender)
smtp.mail=***@google.com; dkim=pass header.i=@google.com
Precedence: list
Mailing-list: list chromium-***@chromium.org; contact chromium-dev+***@chromium.org
List-ID: <chromium-dev.chromium.org>
X-Google-Group-Id: 995022193801
List-Post: <http://groups.google.com/a/chromium.org/group/chromium-dev/post?hl=en_US>,
<mailto:chromium-***@chromium.org>
List-Help: <http://support.google.com/a/chromium.org/bin/topic.py?hl=en_US&topic%838>,
<mailto:chromium-dev+***@chromium.org>
List-Archive: <http://groups.google.com/a/chromium.org/group/chromium-dev/?hl=en_US>
List-Subscribe: <http://groups.google.com/a/chromium.org/group/chromium-dev/subscribe?hl=en_US>,
<mailto:chromium-dev+***@chromium.org>
List-Unsubscribe: <http://groups.google.com/a/chromium.org/group/chromium-dev/subscribe?hl=en_US>,
<mailto:googlegroups-manage+995022193801+***@googlegroups.com>
Archived-At: <http://permalink.gmane.org/gmane.comp.web.chromium.devel/32517>

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


On Wed, Jun 13, 2012 at 7:57 PM, 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.

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

What are these situations?

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

Post by 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
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

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


On Wed, Jun 13, 2012 at 8:57 PM, William Chan (陈智昌)

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

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

What are these situations?

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

Post by 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
--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

--
http://groups.google.com/a/chromium.org/group/chromium-dev

[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

Post by 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

[László Lajos Jánszky]

Post by 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

Post by 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

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
<https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html>.
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

On Thu, Nov 1, 2018 at 1:04 PM László Lajos Jánszky <

Post by László Lajos Jánszky

Post by 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

Post by 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

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
--
--
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
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/82f0bfd2-6df4-4a2b-b308-938e7d78c838%40chromium.org?utm_medium=email&utm_source=footer>
.

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

Post by Charlie Reis
The change in behavior is probably because cross-site pages no longer run
in the same process, once Site Isolation launched
<https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html>.
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

Post by László Lajos Jánszky

Post by 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

Post by 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

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
--
--
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
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/82f0bfd2-6df4-4a2b-b308-938e7d78c838%40chromium.org?utm_medium=email&utm_source=footer>
.

[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

On Saturday, November 3, 2018 at 10:31:18 AM UTC+1, László Lajos Jánszky

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

Post by Charlie Reis
The change in behavior is probably because cross-site pages no longer run
in the same process, once Site Isolation launched
<https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html>.
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

Post by László Lajos Jánszky

Post by 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

Post by 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

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
--
--
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
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/82f0bfd2-6df4-4a2b-b308-938e7d78c838%40chromium.org?utm_medium=email&utm_source=footer>
.

[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!

On Wed, Nov 7, 2018 at 11:31 AM László Lajos Jánszky <

Post by 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
On Saturday, November 3, 2018 at 10:31:18 AM UTC+1, László Lajos Jánszky

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

Post by Charlie Reis
The change in behavior is probably because cross-site pages no longer
run in the same process, once Site Isolation launched
<https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html>.
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
On Thu, Nov 1, 2018 at 1:04 PM László Lajos Jánszky <

Post by László Lajos Jánszky

Post by 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

Post by 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

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
--
--
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
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/82f0bfd2-6df4-4a2b-b308-938e7d78c838%40chromium.org?utm_medium=email&utm_source=footer>
.

--

--
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/b871c63a-8a48-471a-b4e7-f23ad4875b77%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/b871c63a-8a48-471a-b4e7-f23ad4875b77%40chromium.org?utm_medium=email&utm_source=footer>
.

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

Post by 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!

Post by 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
On Saturday, November 3, 2018 at 10:31:18 AM UTC+1, László Lajos Jánszky

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

Post by Charlie Reis
The change in behavior is probably because cross-site pages no longer
run in the same process, once Site Isolation launched
<https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html>.
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
On Thu, Nov 1, 2018 at 1:04 PM László Lajos Jánszky <

Post by László Lajos Jánszky

Post by 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

Post by 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

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
--
--
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
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/82f0bfd2-6df4-4a2b-b308-938e7d78c838%40chromium.org?utm_medium=email&utm_source=footer>
.

--

--
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/b871c63a-8a48-471a-b4e7-f23ad4875b77%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/b871c63a-8a48-471a-b4e7-f23ad4875b77%40chromium.org?utm_medium=email&utm_source=footer>
.

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

On Thu, Nov 15, 2018 at 11:56 AM László Lajos Jánszky <

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

Post by 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!
On Wed, Nov 7, 2018 at 11:31 AM László Lajos Jánszky <

Post by 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
On Saturday, November 3, 2018 at 10:31:18 AM UTC+1, László Lajos Jánszky

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

Post by Charlie Reis
The change in behavior is probably because cross-site pages no longer
run in the same process, once Site Isolation launched
<https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html>.
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
On Thu, Nov 1, 2018 at 1:04 PM László Lajos Jánszky <

Post by László Lajos Jánszky

Post by 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

Post by 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

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
--
--
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
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/82f0bfd2-6df4-4a2b-b308-938e7d78c838%40chromium.org?utm_medium=email&utm_source=footer>
.

--

--
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/b871c63a-8a48-471a-b4e7-f23ad4875b77%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/b871c63a-8a48-471a-b4e7-f23ad4875b77%40chromium.org?utm_medium=email&utm_source=footer>
.

--

--
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/3e6b20fb-5635-410e-b34e-744eab1694e5%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/3e6b20fb-5635-410e-b34e-744eab1694e5%40chromium.org?utm_medium=email&utm_source=footer>
.