To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
I wasn't sure what this looked like, so:
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.
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: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.
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:
I wasn't sure what optionally-blockable mixed content would look like either, so:No shield UI here, so I take it the shield will be gone entirely, or am I still missing something?
https://code.google.com/p/chromium/issues/detail?id=470529A proposal we previously discussed was to remove the shield but add its equivalent to the OIB.
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`).
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.
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 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.
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 :)
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.
Making developers in Google unable to use Chrome to develop is not acceptable.
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.
I wasn't sure what optionally-blockable mixed content would look like either, so: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.
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:Yup. That's a pretty good reference.
I wasn't sure what optionally-blockable mixed content would look like either, so: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.
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:
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
Other browsers have similar mechanisms, though Chrome on Android and iOS do _not_ have such a mechanism.
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.
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
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.
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=470529A 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.
<40313)youdone fuckedupNO0B</40313>
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