Intent to Remove Some UI: mixed content shield.

[Mike West]

CC: security-dev@, felt@, palmer@, lgarron@

"Blockable" mixed content (scripts, etc) is present on ~0.3% of page views: https://www.chromestatus.com/metrics/feature/timeline/popularity/610. Chrome on desktop renders a shield icon in these cases, allowing users to load the insecure script anyway (https://support.google.com/chrome/answer/1342714?hl=en). Other browsers have similar mechanisms, though Chrome on Android and iOS do _not_ have such a mechanism.

According to the (internal, sorry!) `ContentSettings.MixedScript` histogram: over the last four weeks, only 0.1% of page views which had a shield icon resulted in someone interacting with the UI, and about half of those who clicked on the icon proceeded to enable the script. This gives a rough number of ~0.0002% of page views which would be affected.

Given that ballpark figure, and given the danger of mixed content, I'd like to stop giving users the option to shoot themselves in the foot by default by suppressing the blockable mixed content notification on desktop as well as mobile.

I know there are cases in which folks need to be able to enable mixed script (Google has (had?) some internal tools for evaluating advertisements, for instance). I'll boldly claim that those cases a) are dangerous for users who don't really know what they're doing, and b) can be supported via a command-line flag like `--enable-unsafe-mixed-content-override` (or the broader, pre-existing `--disable-web-security`).

What say you, oh glorious API owners, and equally glorious security UX folks (felt@, palmer@, lgarron@, I'm looking at you)?

-mike

[Philip Jägenstedt]

I wasn't sure what this looked like, so:

https://foolip.github.io/mixed-content-blocking.html

Would this be a change in Blink, or somewhere in Chrome's UI code? I suppose to remove the shield icon entirely, not just the ability to bypass the block?

Opera for desktop has quite prominent UI to bypass the block, so I'll ask our desktop people if anyone would mind if that UI simply vanished. Seems like a good idea to me, at least.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike West]

On Thu, Jul 23, 2015 at 12:00 PM, Philip Jägenstedt <phi...@opera.com> wrote:

I wasn't sure what this looked like, so:

https://foolip.github.io/mixed-content-blocking.html

Thanks for putting a demo together! There's also https://badssl.com/ (and https://very.badssl.com/ in particular), for your future security UX needs. :)

One thing to clarify: I'm not proposing any changes to optionally-blockable mixed content (images, etc). This intent is specifically about Blink's behavior for blockable mixed content (scripts, iframes, xhr, etc).

Would this be a change in Blink, or somewhere in Chrome's UI code? I suppose to remove the shield icon entirely, not just the ability to bypass the block?

I think I'd like to keep all the mixed content stuff in the same place to the extent possible. That means I'd like to do something like https://codereview.chromium.org/1248313002, where the embedder would toggle a setting to control whether or not signals were sent up when blockable mixed content was blocked.

Sometime in The Future(tm), I'd like to move mixed content checks out of Blink entirely, and into the browser process, which will enable a lot of refactoring to remove the delegate interfaces we're currently using.

 

Opera for desktop has quite prominent UI to bypass the block, so I'll ask our desktop people if anyone would mind if that UI simply vanished. Seems like a good idea to me, at least.

Thanks! I'm certainly curious about Opera UI folks' opinions.

Speaking of other browsers, +Tanvi: do you have any numbers for Firefox? Would you consider doing the same with regard to the UI?

-mike 

[Philip Jägenstedt]

On Thu, Jul 23, 2015 at 12:24 PM, Mike West <mk...@chromium.org> wrote:

On Thu, Jul 23, 2015 at 12:00 PM, Philip Jägenstedt <phi...@opera.com> wrote:

I wasn't sure what this looked like, so:

https://foolip.github.io/mixed-content-blocking.html

Thanks for putting a demo together! There's also https://badssl.com/ (and https://very.badssl.com/ in particular), for your future security UX needs. :)

One thing to clarify: I'm not proposing any changes to optionally-blockable mixed content (images, etc). This intent is specifically about Blink's behavior for blockable mixed content (scripts, iframes, xhr, etc).

Would this be a change in Blink, or somewhere in Chrome's UI code? I suppose to remove the shield icon entirely, not just the ability to bypass the block?

I think I'd like to keep all the mixed content stuff in the same place to the extent possible. That means I'd like to do something like https://codereview.chromium.org/1248313002, where the embedder would toggle a setting to control whether or not signals were sent up when blockable mixed content was blocked.

Thanks for clarifying, and here is what I think is the normative definition of those categories:

https://w3c.github.io/webappsec/specs/mixedcontent/#categories

I wasn't sure what optionally-blockable mixed content would look like either, so:

https://foolip.github.io/mixed-content-image.html

No shield UI here, so I take it the shield will be gone entirely, or am I still missing something?

Philip

[Mike West]

On Thu, Jul 23, 2015 at 1:43 PM, Philip Jägenstedt <phi...@opera.com> wrote:

I think I'd like to keep all the mixed content stuff in the same place to the extent possible. That means I'd like to do something like https://codereview.chromium.org/1248313002, where the embedder would toggle a setting to control whether or not signals were sent up when blockable mixed content was blocked.

Thanks for clarifying, and here is what I think is the normative definition of those categories:

https://w3c.github.io/webappsec/specs/mixedcontent/#categories

Yup. That's a pretty good reference.

 

I wasn't sure what optionally-blockable mixed content would look like either, so:

https://foolip.github.io/mixed-content-image.html

No shield UI here, so I take it the shield will be gone entirely, or am I still missing something?

Right. The shield would be gone. Users would have no (easy) mechanism by which to enable loading insecure scripts, for example.

For optionally-blockable content, like images, we allow the load, but degrade the UI by dropping the green, and branding the lock. This proposal wouldn't change that behavior at all.

-mike

[Philip Jägenstedt]

Sound good! I'll get back to this thread if I hear back from my colleagues, but in the meantime please proceed as if there are no concerns.

Also an explicit LGTM, although this is so minimally web exposed that I don't think it's needed :)

Philip

[Dimitri Glazkov]

LGTM2.

[Adrienne Porter Felt]

https://code.google.com/p/chromium/issues/detail?id=470529

A proposal we previously discussed was to remove the shield but add its equivalent to the OIB.

[Chris Harrelson]

LGTM3

[Chris Palmer]

Its usage is a rounding error, it's unsafe, and deleting code is always fun. Strong +1 to getting rid of it.

(And strong +1 to The Future in which we move mixed content checks to where it belongs.)

[Lucas Garron]

I'm definitely in favor; Enamel has kind of wanted to do this for a while.

I tried proposing this two months ago, but it didn't get past an internal draft doc stage. (But then, we weren't as proactive about removing stuff back then.)

We already knew a huge fraction of active mixed content triggered on YouTube, but we didn't know where people actually needed the shield, so Jialiu and I added ContentSettings.MixedScript.UserClickedAllow and ContentSettings.MixedScript.RanMixedScript RAPPOR metrics (sorry, those also redirect to Google-internal links) to try to figure out what sites actually need the shield. But those haven't hit beta yet.

»Lucas

--

»Lucas

[Peter Kasting]

On Thu, Jul 23, 2015 at 8:19 AM, Adrienne Porter Felt <fe...@chromium.org> wrote:

https://code.google.com/p/chromium/issues/detail?id=470529

A proposal we previously discussed was to remove the shield but add its equivalent to the OIB.

Could we do this before removing the shield?  It would be good to still have some way for expert users to do this for now, and command-line flags aren't a good option (see below).

On Thu, Jul 23, 2015 at 7:54 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

On Thu, Jul 23, 2015 at 2:12 AM, Mike West <mk...@chromium.org> wrote:

I know there are cases in which folks need to be able to enable mixed script (Google has (had?) some internal tools for evaluating advertisements, for instance). I'll boldly claim that those cases a) are dangerous for users who don't really know what they're doing, and b) can be supported via a command-line flag like `--enable-unsafe-mixed-content-override` (or the broader, pre-existing `--disable-web-security`).

Definitely do not add a command-line flag to allow this.  Flags are only supposed to be for temporary development work, not for "enable advanced features".  Plus, such a flag would mean we couldn't delete any of the UI code for this, we would only bracket it by a flag.

PK 

[Chris Palmer]

On Thu, Jul 23, 2015 at 11:32 AM, 'Peter Kasting' via Security-dev
<securi...@chromium.org> wrote:

>> A proposal we previously discussed was to remove the shield but add its
>> equivalent to the OIB.
>
> Could we do this before removing the shield? It would be good to still have
> some way for expert users to do this for now, and command-line flags aren't
> a good option (see below).

I agree we should not add a command-line flag.

But, if you think of "optionally load unsafe script" as a Blink
(mis-)feature, it's usage is below our normal bar for removal. I don't
think an OIB control is necessary. It should just go.

[Mike West]

On Thu, Jul 23, 2015 at 8:40 PM, Chris Palmer <pal...@chromium.org> wrote:

On Thu, Jul 23, 2015 at 11:32 AM, 'Peter Kasting' via Security-dev
<securi...@chromium.org> wrote:

>> A proposal we previously discussed was to remove the shield but add its
>> equivalent to the OIB.
>
> Could we do this before removing the shield?  It would be good to still have
> some way for expert users to do this for now, and command-line flags aren't
> a good option (see below).

I agree we should not add a command-line flag.

I was thinking of the flag as an enterprise exhaust valve, as I wouldn't be surprised if we needed a mechanism to ween certain segments of the user base off of the dangerous mixed content options we currently provide.

(I haven't talked to the enterprise team about this change; I imagine that they will want such a thing, but maybe they'll surprise me? +Drew)

 

But, if you think of "optionally load unsafe script" as a Blink
(mis-)feature, it's usage is below our normal bar for removal. I don't
think an OIB control is necessary. It should just go.

I agree with Chris. :)

-mike

[Peter Kasting]

On Thu, Jul 23, 2015 at 11:48 AM, Mike West <mk...@google.com> wrote:

On Thu, Jul 23, 2015 at 8:40 PM, Chris Palmer <pal...@chromium.org> wrote:

On Thu, Jul 23, 2015 at 11:32 AM, 'Peter Kasting' via Security-dev
<securi...@chromium.org> wrote:

>> A proposal we previously discussed was to remove the shield but add its
>> equivalent to the OIB.
>
> Could we do this before removing the shield?  It would be good to still have
> some way for expert users to do this for now, and command-line flags aren't
> a good option (see below).

I agree we should not add a command-line flag.

I was thinking of the flag as an enterprise exhaust valve, as I wouldn't be surprised if we needed a mechanism to ween certain segments of the user base off of the dangerous mixed content options we currently provide.

That was the reason for my suggestion as well.

PK

[Mike West]

On Thu, Jul 23, 2015 at 8:51 PM, Peter Kasting <pkas...@google.com> wrote:

I was thinking of the flag as an enterprise exhaust valve, as I wouldn't be surprised if we needed a mechanism to ween certain segments of the user base off of the dangerous mixed content options we currently provide.

That was the reason for my suggestion as well.

If it's something we know we want to remove (and I think it is), then I'd prefer to do so by providing the exact same UI behind a policy or flag for the subset of the user base that requires it today, and then remove the whole thing tomorrow. That seems like a better use of our effort than building new UI on every platform (especially since we don't have any of this UI on mobile at all).

+David, as Drew is OOO.

-mike

[Peter Kasting]

That's fair, but command-line flags are hidden enough that they significantly decrease the impetus to remove the feature entirely -- it's easy to just leave the flag around forever.  That's how we got up to 1300+ command-line flags before I started trying to whittle them down.  So I'm loathe to create new ones.  I'd rather just gut the feature entirely than flag it :)

PK

[Mike West]

On Thu, Jul 23, 2015 at 8:58 PM, Peter Kasting <pkas...@google.com> wrote:

That's fair, but command-line flags are hidden enough that they significantly decrease the impetus to remove the feature entirely -- it's easy to just leave the flag around forever.

I understand that, and agree with the general concern.

 

That's how we got up to 1300+ command-line flags before I started trying to whittle them down.  So I'm loathe to create new ones.  I'd rather just gut the feature entirely than flag it :)

Ok. I'm putting you down for removing the shield entirely. :)

-mike

[Adrienne Porter Felt]

+ainslie

[Elliott Sprehn]

Please don't remove this without adding a command line flag (one that isn't --disable-web-security, that's crazy). Lots of engineers inside Google and outside use this to load load scripts into pages. For example I might need to load facebook.com with my account and then load a local script into it. I don't want to disable web security, that's dangerous for me, I just want to load the script from my development machine.

The team I worked on builds a widget that's deployed into every Google property and the local server doesn't understand https so you must load a mixed content script from localhost:{port}.

[Peter Kasting]

On Thu, Jul 23, 2015 at 5:54 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Please don't remove this without adding a command line flag (one that isn't --disable-web-security, that's crazy). Lots of engineers inside Google and outside use this to load load scripts into pages. For example I might need to load facebook.com with my account and then load a local script into it. I don't want to disable web security, that's dangerous for me, I just want to load the script from my development machine.

I don't see why you can't run a profile with --disable-web-security that you only use for the testing you need to do that requires loading scripts into web pages.

This is obscure.  I'm much more OK with making some engineers use a slightly more cumbersome workflow than I am with adding a flag.  Flags are Really Bad.

PK

[Elliott Sprehn]

I need to login with my Facebook credentials, I don't want to browse with my real account credentials in a profile with web security disabled.

Making developers in Google unable to use Chrome to develop is not acceptable.

- E

[Peter Kasting]

So make a different account.

Making developers in Google unable to use Chrome to develop is not acceptable.

The number of developers in Google is approximately 1/100,000th the size of our userbase, the number of those who need to inject scripts into secure pages is surely far smaller, and the number of _those_ who really *can't* use something like --disable-web-security (as opposed to "don't want to" or "it's inconvenient") is a handful.  I'm not willing to hold Chrome's codebase hostage to that group.

PK

[Chris Palmer]

On Thu, Jul 23, 2015 at 5:54 PM, Elliott Sprehn <esp...@chromium.org> wrote:

> Please don't remove this without adding a command line flag (one that isn't
> --disable-web-security, that's crazy). Lots of engineers inside Google and
> outside use this to load load scripts into pages. For example I might need
> to load facebook.com with my account and then load a local script into it. I
> don't want to disable web security, that's dangerous for me, I just want to
> load the script from my development machine.
>
> The team I worked on builds a widget that's deployed into every Google
> property and the local server doesn't understand https so you must load a
> mixed content script from localhost:{port}.

(http, localhost, 8080) is a secure origin (as defined in the Powerful
Features spec). So, in principle, it isn't even mixed content.

Whether or not all of Chrome and Blink are fully updated with The New
Reality is another question. I'm sure there are gaps, and it sounds
like this is one.

On the third hand, do we want public web origins sourcing things from
(or XHRing to, or, ... et c.) private networks? That is a security
question separate from mixed scripting. We seem to go around and
around on it. But if we decided it was OK, then you wouldn't have a
problem (modulo a policy normalization bug that we should fix).

I'm not sure what the right answer is.

It seems like an extension would satisfy your particular need, though?

[Chris Palmer]

Elliott notes:

>> Making developers in Google unable to use Chrome to develop is not
>> acceptable.

Even I agree :) , rest assured. I think we can find a way.

On Thu, Jul 23, 2015 at 6:10 PM, 'Peter Kasting' via Security-dev
<securi...@chromium.org> wrote:

> The number of developers in Google is approximately 1/100,000th the size of
> our userbase, the number of those who need to inject scripts into secure
> pages is surely far smaller, and the number of _those_ who really *can't*
> use something like --disable-web-security (as opposed to "don't want to" or
> "it's inconvenient") is a handful. I'm not willing to hold Chrome's
> codebase hostage to that group.

And, the telemetry numbers bear this out. I hope I am not re-opening
old wounds :) but, the Shield is kind of the SVG fonts of page action
icons.

[Elliott Sprehn]

That's not really a fair comparison, the small number of page views by these developers are building features used by hundreds of millions or billions of users. 

If localhost:8080 should work then please fix that before removing this feature.

- E

[Ryan Sleevi]

On Jul 23, 2015 6:11 PM, "Chris Palmer" <pal...@chromium.org> wrote:
>
> (http, localhost, 8080) is a secure origin (as defined in the Powerful
> Features spec). So, in principle, it isn't even mixed content.

Yes, but loading http://localhost from https is a-priori insecure according to Mixed Content ;)

> On the third hand, do we want public web origins sourcing things from
> (or XHRing to, or, ... et c.) private networks? That is a security
> question separate from mixed scripting. We seem to go around and
> around on it. But if we decided it was OK, then you wouldn't have a
> problem (modulo a policy normalization bug that we should fix).

Considering bugs like http://tomforb.es/dell-system-detect-rce-vulnerability are a dime a dozen, probably not. But no need to go round that discussion here, other than highlighting why it kinda intentionally (spec and reason) doesn't work like you described (yet?), so that someone doesn't think it's a good idea to just allow it without security review.

[Chris Palmer]

On Thu, Jul 23, 2015 at 6:18 PM, Elliott Sprehn <esp...@chromium.org> wrote:

>> And, the telemetry numbers bear this out. I hope I am not re-opening
>> old wounds :) but, the Shield is kind of the SVG fonts of page action
>> icons.
>
> That's not really a fair comparison, the small number of page views by these
> developers are building features used by hundreds of millions or billions of
> users.

But those few are the most capable of a workaround (such an
extension), enabling us to continue protecting the billions.

[Elliott Sprehn]

Do extensions support inserting a script into the page that runs in the main world but loads from an "insecure" localhost url?

Given that so few people are using the shield icon we know that removing this isn't really protecting the masses. This is just about code clean up.

- E

[Chris Palmer]

On Thu, Jul 23, 2015 at 6:19 PM, 'Ryan Sleevi' via Security-dev
<securi...@chromium.org> wrote:

> Considering bugs like http://tomforb.es/dell-system-detect-rce-vulnerability
> are a dime a dozen, probably not. But no need to go round that discussion
> here, other than highlighting why it kinda intentionally (spec and reason)
> doesn't work like you described (yet?), so that someone doesn't think it's a
> good idea to just allow it without security review.

I'm certainly happy to not allow public origins to access private
origins, for that very reason. Of course.

(Someone should draw that graph with Public ... Private on 1 axis, and
Potentially Secure ... Not Possibly Secure on the other. I think we
all think we have it in our minds, but do we really?)

It might be that the best way to enable people to inject script is to
just use an extension. (It makes the most sense to me, in any case.)

But, no extensions on mobile. And, mobile already does not have any
recourse for running mixed scripting. So, we already partly live in
the world Elliott fears.

We could allow users to inject script purposefully, from the Developer
Tools console? Presumably we'd authenticate that the console wasn't
being spoofed, somehow, or gated on a human user gesture, or...

[Adrienne Porter Felt]

When we're investigating this, please realize that I'm planning to also use the shield icon for Safe Browsing (for subresources like iframes). So we can't actually delete the UI code for it, since I need to use it for that.

We can still change the behavior for active mixed content but please realize I still need the actual UI code to remain for the second purpose.

[Elliott Sprehn]

That might work for some cases, but I don't think it works for the major use cases.

Say you're Disqus and you're developing locally, you want to load the local copy into the NYT instead of from production. You support a magical url combo like ?disqus-server=localhost:8080 so you can experiment with loading pages with real production content but that load your third party widget, at the same timing during page load that your widget normally would, but from the local server.

This is an important use case, especially if we're talking about getting third parties to work on improving the impact they have on pages. :) Being able to modify my local copy and reload a real page with the new changes to iterate is important.

I don't think the extension solves this, maybe if extensions could load a service worker to MitM the page it could work.

- E

[Chris Palmer]

On Thu, Jul 23, 2015 at 6:40 PM, Elliott Sprehn <esp...@chromium.org> wrote:

> Say you're Disqus and you're developing locally, you want to load the local
> copy into the NYT instead of from production. You support a magical url
> combo like ?disqus-server=localhost:8080 so you can experiment with loading
> pages with real production content but that load your third party widget, at
> the same timing during page load that your widget normally would, but from
> the local server.

Why not ?disqus-server=dev12345.eng.disquscorp.com ? The hostname
would resolves to the Disqus employee's workstation (split-horizon
DNS, most likely) and would serve a certificate signed either with an
internal CA that only internal clients trust?

[Robert Hogan]

On Thu, Jul 23, 2015 at 12:47 PM Mike West <mk...@chromium.org> wrote:

On Thu, Jul 23, 2015 at 1:43 PM, Philip Jägenstedt <phi...@opera.com> wrote:

 

I wasn't sure what optionally-blockable mixed content would look like either, so:

https://foolip.github.io/mixed-content-image.html

No shield UI here, so I take it the shield will be gone entirely, or am I still missing something?

Right. The shield would be gone. Users would have no (easy) mechanism by which to enable loading insecure scripts, for example.

Will someone fix the perf changelog before that happens? It currently makes heavy use of the shield UI. :)

https://build.chromium.org/f/chromium/perf/dashboard/ui/changelog_blink.html?url=/trunk&mode=html&range=199281:199284

 

[august ",' OR 1=1; >%:. $ } ] ) \n\t huber]

This still seems problematic unless you override the CA trust list for
that profile as well; you wouldn't want all of your non-engineering
users running around where any engineer can MitM trusted origins
(accounts.disquscorp.com) because at some point some engineer on the
login service will need to test as well.

>
> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Philip Jägenstedt]

On Thu, Jul 23, 2015 at 1:56 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Thu, Jul 23, 2015 at 1:47 PM, Mike West <mk...@chromium.org> wrote:

On Thu, Jul 23, 2015 at 1:43 PM, Philip Jägenstedt <phi...@opera.com> wrote:

I think I'd like to keep all the mixed content stuff in the same place to the extent possible. That means I'd like to do something like https://codereview.chromium.org/1248313002, where the embedder would toggle a setting to control whether or not signals were sent up when blockable mixed content was blocked.

Thanks for clarifying, and here is what I think is the normative definition of those categories:

https://w3c.github.io/webappsec/specs/mixedcontent/#categories

Yup. That's a pretty good reference.

 

I wasn't sure what optionally-blockable mixed content would look like either, so:

https://foolip.github.io/mixed-content-image.html

No shield UI here, so I take it the shield will be gone entirely, or am I still missing something?

Right. The shield would be gone. Users would have no (easy) mechanism by which to enable loading insecure scripts, for example.

For optionally-blockable content, like images, we allow the load, but degrade the UI by dropping the green, and branding the lock. This proposal wouldn't change that behavior at all.

Sound good! I'll get back to this thread if I hear back from my colleagues, but in the meantime please proceed as if there are no concerns.

Sigbjørn Vik, one of our security folks, says "I am all for blocking automatically" and "manually allowing the inlines isn't really needed," so no concerns on our part, as expected.

Philip

[Tanvi Vyas]

Starting in Firefox 42, we are no longer going to use the Shield Icon to indicate that mixed active content has been blocked.  Instead, we are moving it into our Control Center (your OIB)[1].  We've also considered removing the mixed content override completely[2] as our metrics show the override isn't used very frequently[3].  We'll see how these metrics change once we move the override into Control Center and then decide if we should remove the override completely.

One thing to note is that if we ever decide to block mixed display content by default, we'll need to consider adding back the shield or a more visible override.

As for localhost request from https, our Mixed Content Blocker treats them as insecure and blocks them.  We don't have any plans to change this behavior.

Thanks!

~Tanvi

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1175702
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1140777
[3] 20K overrides out of 2.5billion page loads in Firefox 38 - http://telemetry.mozilla.org/advanced/#filter=release%2F38%2FMIXED_CONTENT_UNBLOCK_COUNTER%2Fsaved_session%2FFirefox&aggregates=Submissions&evoOver=Time&locked=true&sanitize=true&renderhistogram=Table

On 7/23/15 3:24 AM, Mike West wrote:

On Thu, Jul 23, 2015 at 12:00 PM, Philip Jägenstedt <phi...@opera.com> wrote:

I wasn't sure what this looked like, so:

https://foolip.github.io/mixed-content-blocking.html

Thanks for putting a demo together! There's also https://badssl.com/ (and https://very.badssl.com/ in particular), for your future security UX needs. :)

One thing to clarify: I'm not proposing any changes to optionally-blockable mixed content (images, etc). This intent is specifically about Blink's behavior for blockable mixed content (scripts, iframes, xhr, etc).

Would this be a change in Blink, or somewhere in Chrome's UI code? I suppose to remove the shield icon entirely, not just the ability to bypass the block?

I think I'd like to keep all the mixed content stuff in the same place to the extent possible. That means I'd like to do something like https://codereview.chromium.org/1248313002, where the embedder would toggle a setting to control whether or not signals were sent up when blockable mixed content was blocked.

Sometime in The Future(tm), I'd like to move mixed content checks out of Blink entirely, and into the browser process, which will enable a lot of refactoring to remove the delegate interfaces we're currently using.

 

Opera for desktop has quite prominent UI to bypass the block, so I'll ask our desktop people if anyone would mind if that UI simply vanished. Seems like a good idea to me, at least.

Thanks! I'm certainly curious about Opera UI folks' opinions.

Speaking of other browsers, +Tanvi: do you have any numbers for Firefox? Would you consider doing the same with regard to the UI?

-mike 

[Chris Palmer]

Interesting. Thank you, Tanvi.

[Tanvi Vyas]

On Thursday, July 23, 2015 at 2:12:41 AM UTC-7, Mike West wrote:

Other browsers have similar mechanisms, though Chrome on Android and iOS do _not_ have such a mechanism.

Testing this on Chrome on Android and iOS, I see different behaviors.  Android seems to block mixed active content without an override.  And on iOS the mixed active content is loaded by default!  Is this expected behavior?

[Lucas Garron]

tl;dr: Yes, those are currently working as expected (although iOS 9 change things).

»Lucas

--

»Lucas

[Adrienne Porter Felt]

It's a WebView limitation on iOS.

[Justin Schuh]

Speaking to the larger proposal: We should do this in the future, but we're simply not ready to do it yet.

The usage numbers we have today are misleading because we still have some significantly painful mixed content cases we need to address (liked sub-resource loads in Flash). That's going to result in a much greater need for the shield during the transitional phase while publishers migrate their mixed Flash content. So, we need to wait until we're actually blocking all the scary mixed content cases before we even think about removing the shield. And even then, we're going to have a fun time accounting for cases where we don't have good data, like enterprises.

[Mike West]

On Thu, Jul 30, 2015 at 2:39 PM, Justin Schuh <jsc...@chromium.org> wrote:

Speaking to the larger proposal: We should do this in the future, but we're simply not ready to do it yet.

The usage numbers we have today are misleading because we still have some significantly painful mixed content cases we need to address (liked sub-resource loads in Flash). That's going to result in a much greater need for the shield during the transitional phase while publishers migrate their mixed Flash content. So, we need to wait until we're actually blocking all the scary mixed content cases before we even think about removing the shield. And even then, we're going to have a fun time accounting for cases where we don't have good data, like enterprises.

It sounds like you're making two claims:

1. We're currently not blocking some kinds of content that we'd like to block. Doing so will likely create some churn, and we'll want to have an interface for folks to enable these kinds of content as a transition.

2. Enterprise.

#1 seems like an argument against getting rid of the UI, but it's not at all an argument about whether or not we should continue triggering that UI for the _existing_ kinds of things that we currently consider mixed content. In particular, it's not an argument for allowing users to opt-into mixed script via the shield.

#2 is what we're planning on testing by removing the shield's trigger in Canary and Dev.

-mike

[Justin Schuh]

On Thu, Jul 30, 2015 at 5:48 AM, Mike West <mk...@google.com> wrote:

On Thu, Jul 30, 2015 at 2:39 PM, Justin Schuh <jsc...@chromium.org> wrote:

Speaking to the larger proposal: We should do this in the future, but we're simply not ready to do it yet.

The usage numbers we have today are misleading because we still have some significantly painful mixed content cases we need to address (liked sub-resource loads in Flash). That's going to result in a much greater need for the shield during the transitional phase while publishers migrate their mixed Flash content. So, we need to wait until we're actually blocking all the scary mixed content cases before we even think about removing the shield. And even then, we're going to have a fun time accounting for cases where we don't have good data, like enterprises.

It sounds like you're making two claims:

1. We're currently not blocking some kinds of content that we'd like to block. Doing so will likely create some churn, and we'll want to have an interface for folks to enable these kinds of content as a transition.

Now that I see CLs for blocking plugin subresources I'm feeling a bit mollified on this front. 

2. Enterprise.

#1 seems like an argument against getting rid of the UI, but it's not at all an argument about whether or not we should continue triggering that UI for the _existing_ kinds of things that we currently consider mixed content. In particular, it's not an argument for allowing users to opt-into mixed script via the shield.

#2 is what we're planning on testing by removing the shield's trigger in Canary and Dev.

History has shown us that enterprises don't pay much attention to anything other than stable releases. So, regardless what we do we should expect they'll still need an escape hatch.

-mike

[Tanvi Vyas]

On 7/30/15 7:06 AM, Justin Schuh wrote:

On Thu, Jul 30, 2015 at 5:48 AM, Mike West <mk...@google.com> wrote:

On Thu, Jul 30, 2015 at 2:39 PM, Justin Schuh <jsc...@chromium.org> wrote:

Speaking to the larger proposal: We should do this in the future, but we're simply not ready to do it yet.

The usage numbers we have today are misleading because we still have some significantly painful mixed content cases we need to address (liked sub-resource loads in Flash). That's going to result in a much greater need for the shield during the transitional phase while publishers migrate their mixed Flash content. So, we need to wait until we're actually blocking all the scary mixed content cases before we even think about removing the shield. And even then, we're going to have a fun time accounting for cases where we don't have good data, like enterprises.

It sounds like you're making two claims:

1. We're currently not blocking some kinds of content that we'd like to block. Doing so will likely create some churn, and we'll want to have an interface for folks to enable these kinds of content as a transition.

Now that I see CLs for blocking plugin subresources I'm feeling a bit mollified on this front.

I would love to block mixed active plugin subresource loads, but I'm not sure how to distinguish a script from an image[1].  If you have found a way to do this, please do share!  Or if you think we can get away with blocking all mixed plugin subresources, I'd be open to that too.  Thanks!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=836352

[Justin Schuh]

We don't have a way of distinguishing them either, so the plan is to experiment with blocking them all first, and see how that goes over on the Canary/dev/Beta channels.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=836352

[Tanvi Vyas]

We've decided to remove our Mixed Content Blocker override for Firefox on Android.

As I said before, with Firefox 42, we moved Mixed Content Blocker to our Control Center (your OIB).  Hence, both Desktop and Mobile no longer have dedicated UI just for Mixed Content.  Since we have limited real estate on Mobile and there is already a lot going on in the Control Center, we decided not to clutter it more with the override button.  Mixed active content will be blocked and there will be no easy way to recover a broken site.  We'll see how it goes!

Thanks!

~Tanvi

[Corvin Russell]

I agree with adding it to the OIB as a transition to eliminating it. Speaking as a user, about twice a month I encounter an HTTPS site I need to interact with that loads essential non-HTTPS scripts. This may be a result of my using HTTPS everywhere, uMatrix, and generally having strict settings, but I haven't experimented to verify this, and for now, I regularly need the option to load these scripts as certain sites simply won't function otherwise. I am not sure why so many large sites are taking so long to get HTTPS right, but in the meantime, we need transitional measures.

Corvin

2015-07-23 14:32 GMT-04:00 'Peter Kasting' via Security-dev <securi...@chromium.org>:

On Thu, Jul 23, 2015 at 8:19 AM, Adrienne Porter Felt <fe...@chromium.org> wrote:

https://code.google.com/p/chromium/issues/detail?id=470529

A proposal we previously discussed was to remove the shield but add its equivalent to the OIB.

Could we do this before removing the shield?  It would be good to still have some way for expert users to do this for now, and command-line flags aren't a good option (see below).

On Thu, Jul 23, 2015 at 7:54 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

On Thu, Jul 23, 2015 at 2:12 AM, Mike West <mk...@chromium.org> wrote:

I know there are cases in which folks need to be able to enable mixed script (Google has (had?) some internal tools for evaluating advertisements, for instance). I'll boldly claim that those cases a) are dangerous for users who don't really know what they're doing, and b) can be supported via a command-line flag like `--enable-unsafe-mixed-content-override` (or the broader, pre-existing `--disable-web-security`).

Definitely do not add a command-line flag to allow this.  Flags are only supposed to be for temporary development work, not for "enable advanced features".  Plus, such a flag would mean we couldn't delete any of the UI code for this, we would only bracket it by a flag.

PK 

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

--

Twitter: @corvinr

Google Plus: https://plus.google.com/115459943980453987525

My PGP key is here. 

Help restore privacy and freedom of association for everyone by using Signal on iPhone and TextSecure and RedPhone on Android.

[Corvin Russell]

Quite obviously, the other part of the solution is not technical, it is simply public pressure and education. Google and Mozilla can use their market and media clout to get the message out - a public announcement and a very simple educational page for webmasters on how to do HTTPS right (and how to do it wrong). Launch it with public fanfare, and say sites may stop working for end users if these sites don't implement HTTPS correctly by X date. The boo hoo brigade will of course start whining, but too bad for them.

[icx...@gmail.com]

<40313)youdone fuckedupNO0B</40313>

may i ask why?

JJMN GRSM EZRD

On Thursday, July 23, 2015 at 2:12:41 AM UTC-7, Mike West wrote:

CC: security-dev@, felt@, palmer@, lgarron@

"Blockable" mixed content (scripts, etc) is present on ~0.3% of page views: https://www.chromestatus.com/metrics/feature/timeline/popularity/610. Chrome on desktop renders a shield icon in these cases, allowing users to load the insecure script anyway (https://support.google.com/chrome/answer/1342714?hl=en). Other browsers have similar mechanisms, though Chrome on Android and iOS do _not_ have such a mechanism.

According to the (internal, sorry!) `ContentSettings.MixedScript` histogram: over the last four weeks, only 0.1% of page views which had a shield icon resulted in someone interacting with the UI, and about half of those who clicked on the icon proceeded to enable the script. This gives a rough number of ~0.0002% of page views which would be affected.

Given that ballpark figure, and given the danger of mixed content, I'd like to stop giving users the option to shoot themselves in the foot by default by suppressing the blockable mixed content notification on desktop as well as mobile.

I know there are cases in which folks need to be able to enable mixed script (Google has (had?) some internal tools for evaluating advertisements, for instance). I'll boldly claim that those cases a) are dangerous for users who don't really know what they're doing, and b) can be supported via a command-line flag like `--enable-unsafe-mixed-content-override` (or the broader, pre-existing `--disable-web-security`).

What say you, oh glorious API owners, and equally glorious security UX folks (felt@, palmer@, lgarron@, I'm looking at you)?

-mike