New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 48 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Aug 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Block script/CSS/plug-in loads that are over http, and occur within https pages, aka "mixed content errors"

Reported by scarybea...@gmail.com, May 5 2011 Back to list

Issue description

This was turned on as of http://src.chromium.org/viewvc/chrome?view=rev&revision=84203

This bug is filed to track notes and any troubles with this feature.

The feature may be disabled with the new command-line flag --allow-running-insecure-content
Mixed-content images and frames are not blocked by default because of the much higher incidence and much lower risk. That can however be turned on by --no-displaying-insecure-content

Note that the risk of this feature is greatly limited by the fact that IE9 behaves similarly. (IE9 does have a sort of "infobar" to load the site insecurely but I opted not to have an infobar in iteration #1 because users just click through it. It is therefore more secure to not have an infobar at all).

If you find something that is broken by this, this is the bug to note it on (although beware that the correct course is likely to notify the buggy web site).

 
Labels: Feature-Security
While blocking insecure content is ideal from a security perspective, the reality is that most content providers are not providing secure version of embeddable content (like Twitter).  This makes embedding content on secure pages completely broken for chrome users.  Again, in an ideal future all content providers will provide secure widgets, but until then it needs to be more obvious to the end user that content has been blocked and easier for users to allow that content.  

--Alex
Thanks for stopping by :)
A list of examples of affected sites (URLs) would be really useful to help gauge what the right thing to do is.

Thanks for the quick reply.  I threw together a short list of well known sites that use insecure embeddable content.  Of the many sites I checked I only found one that was using a secure connection for embedded JS, which was gist.github.com.

Skype
http://www.skype.com/intl/en-us/tell-a-friend/get-a-skype-button/

Twitter
http://twitter.com/about/resources/widgets/widget_profile

Babel Fish
http://babelfish.yahoo.com/free_trans_service

Pandora
http://www.pandora.com/feeds

AddThis
http://www.addthis.com/


Thanks. Do you have examples of https-hosted websites that use these http-only embedding services?
If, for example, the method of embedding is an <iframe> then this condition won't be blocked by default (it's a much less serious mixed-content condition than a <script>, which _will_ be blocked by default).

Comment 6 by okoe...@gmail.com, May 15 2011

Hello,

I'm glad to have found this page, as both Chrome and Chromium don't seem to have a possibility to toggle this security feature.

We are developing something and suddenly my Chrome Dev couldn't see the page and turned out to be this. This feature is extremely intrusive, as only the JavaScript Console pane seems to provide a hint on the error. There is no way that normal users would have found this to be the problem, let alone to be able to know how to solve it.

I would hope that this feature can be switched off by default, and enabled explicitly in the Under the hood GUI or something like it.


    Oscar

Comment 7 by cdn@google.com, May 16 2011

@scarybeasts, it seems like we probably at least want to provide an infobar for this. Just making it not work seems to break an awful lot.

Comment 8 by h.lepp...@gmail.com, May 17 2011

There used to be an option on the Under the Hood panel for this, way back.

Can't we get this option back? Using a cmd-line argument is really not optimal.

Comment 9 by jsc...@chromium.org, May 18 2011

Cc: jsc...@chromium.org abarth@chromium.org
 Issue 83007  has been merged into this issue.
Cc: -jsc...@chromium.org -abarth@chromium.org
I'm reopening the bug because this change is probably too radical for the moment. We can look at pursuing an infobar or something similar, but blocking without an overt indication is probably not the right move.
Status: Assigned
(OK, re-opening then.)

I agree that doing this without a notification isn't good.

This would be one of the rare cases where I'd actually support an option in the "HTTPS/SSL" portion of the options, which would allow more security-conscious users to toggle this on immediately.  I'd certainly like to move toward a world where we could make this the default, though I don't think we're in that world yet.

It probably makes sense to make this a content setting, or else make it additional granularity on the existing JS/plugins/etc. content settings.  That way users can see notifications and act on them from the standard places (omnibox, content settings page, etc.)
Oh, and for convenience, to copy some data from  issue 83007 ,

Google Docs
http://docs.google.com/

...is on the list here, at least when you embed YouTube videos into presentations.  (There is also a small Googler-used site called shuttle.hobnob.com that is less relevant to the web at large.)
@pkasting - For reference, IE9 blocks with an infobar to allow the content in this scenario (although I agree that an infobar is not a great solution). Either way, I can flip the switch back to the old behavior tomorrow.
The Mozilla folks seem interested in doing something along these lines too:

http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/0c131d919bfcce0f

Coordinating with them will make it easier to do something more secure here.

Comment 15 by okoe...@gmail.com, May 18 2011

Another problem I see with this, is that there are hints online that refer to an option that doesn't seem to exist anymore. Did this really left the Under the hood? I'm fine with new defaults which is clearly there for a good security-wise reason. I hope that a switch could return in the Under the Hood page and another notification that a block has occured would really be appreciated.

Thanks
Some quick notes:
1) Please don't flip the switch back just yet. That's going in the wrong direction.
2) I will post the promised Chromium blog post when I get back from vacation. We can also huddle at such time.
3) Please, please file bugs against any buggy products uncovered by this. For the case of YouTube embeds, it's trivial to switch a direct <object> or <embed> to an <iframe>-based embed and this should sidestep the block nicely.
4) Please use this bug to list any specific URLs which demonstrate casualties from this change.

Comment 17 by k...@google.com, May 19 2011

Cc: anan...@chromium.org dglazkov@chromium.org krisr@chromium.org kerz@chromium.org jam...@chromium.org
Issue 83080 has been merged into this issue.
Project Member

Comment 18 by bugdroid1@chromium.org, May 19 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=85954

------------------------------------------------------------------------
r85954 | jschuh@chromium.org | Thu May 19 12:49:37 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/browser.cc?r1=85954&r2=85953&pathrev=85954

Temporarily disabling mixed-content bocking by default. Will re-land with an infobar/bypass option and may alter the hueristic for blocking.

BUG= 81637 
TEST=None.

Review URL: http://codereview.chromium.org/7033026
------------------------------------------------------------------------
Labels: -Mstone-13 Mstone-14
Cc: tsepez@chromium.org
Ok, we retargeted to M14 so we can take a better run up to this. Today is the first day of M14, so I'm flipping the flag back.
Tom will land an infobar (without the option to click through at first, to see if it can stick that way) that explains the situation in a more visible way.
I'll do a Chromium + Google Online Security blog post over the next few days to warn of the change.

I'm collecting the various known-broken sites and getting them to fix their issues. Twitter have a fix ready to go, I'll check in on Google Docs video embeds.
Project Member

Comment 21 by bugdroid1@chromium.org, Jun 1 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=87511

------------------------------------------------------------------------
r87511 | cevans@chromium.org | Wed Jun 01 11:53:19 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/browser.cc?r1=87511&r2=87510&pathrev=87511

Revert 85954 - Temporarily disabling mixed-content bocking by default. Will re-land with an infobar/bypass option and may alter the hueristic for blocking.

BUG= 81637 
TEST=None.

Review URL: http://codereview.chromium.org/7033026

TBR=jschuh@chromium.org
Review URL: http://codereview.chromium.org/7020036
------------------------------------------------------------------------
Having no way to unbreak the page isn't OK.  We must have a way to show the broken content.  Please do things like the Java plugin infobar does, which is annoying but still allows users to see the content if they're willing to be insecure.
@pkasting: let's reconvene on that (with agl@ -- who has eloquent arguments for why a click-through is FUBAR) -- once the blog post has sunk in and we're back on dev with the initial cut at the infobar.
Of course there are good arguments why allowing users to do this is bad for them.  Allowing people to run the Java plugin is also bad for them, to the degree that I'd be extremely surprised at any argument that the risk and cost/benefit of this case are more in favor of no-clickthrough than that one.
@pkasting: yeah, there's the possibility that we'll have to end up running with a click-through in Chrome for a few releases (with a fixed-period notice on when the click-through becomes deprecated)
Sure, that's what jschuh and I talked about, along with collecting stats on how often and where people click through (the where part to be collected by an extension so it could send us actual URLs).

It'd be much kinder to our users -- and to us UI folks doing bug triage and work -- to land the initial infobar with the ability to show the insecure content, and collect stats on that to inform your decisions, than to do it the other way around, have the inevitable batch of bugs filed by angry users, and then have to make some kind of argumentative judgment call on adding bypasses.  And as I said above, I really don't think this is worse than (or even as bad as) various other clickthrough cases we already have.  Just by making it annoying we've taken a good first step.

Please?

Comment 27 by agl@chromium.org, Jun 16 2011

Cc: agl@chromium.org

Comment 28 by Deleted ...@, Jun 16 2011

Seriously, add the feature "show me which content/script items are insecure".

Don't make me manually trawl through the "network" tab manually looking for non-SSL traffic. That sort of thing is what computers are good at.
Already taken care of.  Open wrench > tools > Javascript Console to see a list of blockages.

Comment 30 Deleted

#Chromium developers: thanks so much for implementing this! It's awesome.#

I enabled the "--no-displaying-insecure-content" flag. Upon first arrival this very webpage ( bug 81637 ) shows HTTPS (secure-green), yet when I click the "star" to add my vote to this bug the infobar drops down warning me that Insecure Content has been blocked (the star will never highlight yellow). At first glance it appears that I cannot add the star without adding insecure content to the page. Yet if I click "Load Anyway" from the infobar, then the star will highlight yellow and the https in the Omnibar stays secure-green.

Things are different though when the insecure-content flag is disabled: clicking the star (to make it yellow) will always result in the "insecure content yield sign" appearing over the https in the Omnibar (i.e., it no longer stays secure-green).

Is this a bug?
@jtodd929@hotmail.com: thanks for dropping by :) Yep, looks like a minor bug in code.google.com; I'll bounce it to the website owners.
What about the discrepancy of results between clicking "Load Anyway" and disabling the insecure-content flag? For example, when I had the --no-displaying-insecure-content flag enabled and clicked "Load Anyway" the omnibar continued to display a secure-green https, yet I was expecting that the "yield sign" would appear over the https. Was it indeed still secure or this is a bug? The reason I ask is because when the insecure-content flag is disabled then the Omnibar shows the "yield sign" over the https when I click the star.  
@jtodd929@hotmail.com: "Load Anyway" basically reloads the page with the setting changed to "allow" instead of "block".
The star image isn't loaded automatically on page load, so you won't see the yield triangle util you click the star again.
Cc: rsleevi@chromium.org wtc@chromium.org jcivelli@chromium.org finnur@chromium.org abarth@chromium.org
Issue 72015 has been merged into this issue.
@bernhard.bermeitinger: thanks! Yep, I was looking at this one yesterday. I'll get it nailed down ASAP.
I understand the use of this function, but there should be a way to disable it via advanced settings without having to add a command line parameter.
The "Learn more..." link in the infobar should open a new tab and not navigate away from the mixed content page.

Comment 42 by aever...@gmail.com, Jun 24 2011

Now (I'm on r90349) both of the buttons read "Load Anyway". Try a Wikipedia page, for example https://secure.wikimedia.org/wikipedia/en/wiki/chrome, to see this.
Cc: -security...@gtempaccount.com security@chromium.org pkasting@chromium.org
As it turns out, we intended to revert to a one-button design - but it looks like there is a missing GetButtons virtual method in insecure_content_infobar_delegate.cc that would have said "one button".

Comment 44 by adys...@gmail.com, Jun 26 2011

(evangelism-ish)
The VM ticket/customer support system is unusable because of mixed content. Sending a ticket takes the user to a page that has mixed content and does not send the data. Then reloading breaks the flow and causes the form to error.

https://help.virginmedia.com/system/selfservice.controller?CMD=ESCALATION_REQUEST
@adys.wh: thanks for taking the time to report! I've also had a complaint about a problem trying to book a plane ticket on Virgin America... maybe it's the same issue?
It sounds like something Virgin really want to fix, on account of being a security bug and also the possibility of losing money. I'll try and find a contact.

Comment 46 by mal@google.com, Jun 28 2011

Cc: -security@chromium.org security-bug-mail@chromium.org

Comment 47 by jon...@gmail.com, Jun 28 2011

Ran into this problem with the Google Plus signup
https://services.google.com/fb/forms/googleplus/

Comment 48 by agl@chromium.org, Jun 28 2011

jonnew: thank you for reporting the issue with the the Plus signup page. This has now been fixed.
shuttle.hobnob.com still exhibits problems -- once you login, the site basically displays nothing until you "run insecure script".
@pkasting: I don't use that site; any chance you'd be willing to fire them off an e-mail explaining the error of their ways? Also, if you had IE9 around, could you see if there's a similar behaviour there?
You can log into it with your GAIA account, you don't need anything site-specific.

The same problems occur with IE9.

I don't know enough to send anyone a useful mail.  AFAIK this site is run in conjunction with the Google transportation team so it seems like there ought to be someone internal concerned about it.
[Minor] Google logo (http://www.google.com/images/logo_sm.gif) is served over HTTP for the following HTTPS pages causing mixed content warnings to appear:

https://encrypted.google.com/logos/index.html
https://encrypted.google.com/logos/official.html
https://encrypted.google.com/logos/fan.html

I reached these pages by clicking the "I'm Feeling Lucky" button on https://encrypted.google.com

Comment 53 by adys...@gmail.com, Jul 25 2011

Oddly nobody mentioned this yet, but any http-included script (eg. youtube videos) in rss feeds causes a mixed scripting error on Google Reader over https.

Comment 55 by agl@chromium.org, Jul 25 2011

I'll fix the image URL on the logos pages. Reader will hopefully be fixed in the coming weeks. Finally, we're aware that code.google.com pages need significant amounts of work.
[Minor] Several instances of images served over http for these https pages:

https://www.google.com/support/forum
https://www.google.com/support/forum/p/Chrome
https://www.google.com/support/forum/p/Chrome/thread?tid=07bc5e1f14e6a561&hl=en (user images -- http://www.google.com/s2/photos/public/...)

Rather than clutter this page up with comments like these, is there a better place to report such occurrences?

Comment 57 by k...@google.com, Jul 28 2011

Labels: -Mstone-14 Mstone-15 MovedFrom-14
Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.
Status: Fixed
We're done with this for now:

M14: blocks mixed scripting with an infobar on *.google.com. Also has flag --no-running-insecure-content

M15: blocks mixes scripting with an infobar on *. Also has flag --always-run-insecure-content

It's not clear if we can promote this feature to * for M15, but it's worth trying.
I've noticed none of the sites Chrome shows as having insecure content/scrips show as insecure in Firefox if the AdBlock Plus add-on is enabled in Firefox. NoScript will sometimes defeat insecure content/scripts as well even when the "Scripts Globally Allowed" setting is enabled (i.e., the NoScript add-on is enabled but all scripts are nevertheless allowed to run).

I installed the AdBlock Plus add-on in Chrome with the same filters as I was using in Firefox, but it does not block insecure content/scripts like it does in Firefox. 

I have replicated this on many sites; however, https://gmx.com is a good site for testing it. In Chrome, the MAIL tab sometimes shows insecure content while the USER LAB tab shows secure. Other times both the MAIL and USER LAB tabs will show insecure scripts in Chrome. But in Firefox when AdBlock Plus is enabled, both MAIL and USER LAB tabs always show secure. 
This bug is not about AdBlock Plus, Firefox, or any other extensions or browsers.  Given the number of comments here it's important not to go off on tangents.
This feature prevents the display of AdSense ads on a page delivered over https. To my knowledge AdSense doesn't provide an https version of their scripts, so this feature will cause the insecure content warning to appear on any https page that includes AdSense ads, and I'm sure the same would be true of other ad networks as well.

I ran across the issue in a Facebook game I am developing. Starting on October 1, Facebook is requiring all Facebook applications be served over https (see http://lukaswhite.com/blog/post/2011/facebook-canvas-pages-require-ssl-certificates),  so developers of ad-supported games and apps (and by extension AdSense) are going to find that Chrome users aren't seeing the ads they've included to monetize their content.
@brian: thanks for the note.
Can you paste the HTML fragment you use to include AdSense ads in your app? I'll see if there's a working HTTPS equivalent.
Also, don't you hit this issue already in IE9 ?
Sure thing. Here's an example AdSense snippet:

 <script type="text/javascript"><!--
                google_ad_client = "ca-pub-2880202210813851";
                /* StatusFightBelowStatus */
                google_ad_slot = "4138342926";
                google_ad_width = 200;
                google_ad_height = 200;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

Comment 65 by Deleted ...@, Sep 23 2011

I get "This page has insecure content" warnings when visiting a variety of Google websites. Is just me, or should Google be the first to acknowledge the mixed scripts considering their browser is giving invasive warnings that persist despite turning it off on the command line.

//Rant over

Comment 66 Deleted

@evan: It would be helpful if you could provide the exact URL to us when you hit this on one of Google's websites.   Also, which version of chrome are you running, and what it your exact command line that fails to disable the warning?

Comment 69 by adys...@gmail.com, Sep 23 2011

Google finance comes from doubleclick. The google code issues should be reported at http://code.google.com/p/support/issues/detail?id=5475. Youtube issue is known afaik.

Comment 70 by audv...@gmail.com, Sep 24 2011

Firefox implements a similar policy, so my question is why doesn't Chrome listen to the X-Content-Security-Policy header?

It really is not a good idea to require that everything be SSL on a page, especially images if you just specify where things are allowed to come from (and what things can be done, like inline scripts and eval), which is what the header is for.

And nobody wants to click (especially if they don't understand what's going on) 'Load Anyway' over and over again. The flag is a workaround for DEVELOPERS, nobody (especially on a Mac) is going to even consider trying it.
> Why doesn't Chrome listen to the X-Content-Security-Policy header?

Content-Security-Policy is still going through the standards process.  Chrome listens to the X-WebKit-CSP name.  Ideally Firefox would have picked a vendor prefixed name for their implementation prior to standardization as well.  Once the standard is done, we'll all listen to Content-Security-Policy.

Comment 72 by audv...@gmail.com, Sep 25 2011

I am having lots of trouble finding documentation on these headers and I do not want to use meta tags to do this.

The W3C information is clearly not up-to-date (and not complete) and it doesn't seem to even mention about 'allow' directive.

I placed X-WebKit-CSP header in Nginx with the same options as Firefox (which works 99% other than some error in the log which doesn't seem to matter). This paranoia mode that the browser is running in is very frustrating to deal with. All I want is to allow content from the same domain (don't care about subdomain), and for the moment, with certain packages like MantisBT, I have to allow inline scripts (say poor programming on their part all you want, but that's how it is now).

From configuration:
add_header X-Content-Security-Policy "allow 'self'; img-src http://$server_name https://$server_name; style-src http://$server_name https://$server_name; options inline-script"; # Works mostly
add_header X-WebKit-CSP "allow 'self'; img-src http://$server_name https://$server_name; style-src http://$server_name https://$server_name; options inline-script";
@audvare: This isn't the right bug to discuss these issues.  This bug is about mixed content detection, not Content-Security-Policy.

The documentation of CSP should improve as the specification moves further along the standards process.  In the meantime, this is the most recent draft of the specification: http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-unofficial-draft-20110315.html

Comment 74 by audv...@gmail.com, Sep 25 2011

Apparently, Chrome (latest available on site) and Chromium (14.0.835.162) listen to  X-Content-Security-Policy, not the old one.

Comment 75 by adys...@gmail.com, Sep 26 2011

Tesco online shop has a few issues too on secure.tesco.com [evangelism]

https://secure.tesco.com/register/contactDetails.aspx?vstore=99 (might need an acc)

Comment 76 by Deleted ...@, Oct 5 2011

Warning for mail.google.com

Unsafe JavaScript attempt to access frame with URL https://mail.google.com/mail/?zx=id-replaced-here&shva=1#inbox from frame with URL https://plus.google.com/_/apps-static/_/js/nw/nw_i/rt=h/ver=EclwwfMMOns.en./am=!id-replace here/d=1/. Domains, protocols and ports must match.

Comment 77 by adys...@gmail.com, Oct 26 2011

https://checkout.google.com/seller/what.html?hl=en&gl=GB mixed content errors on google.com domain

Also some adsense one reported in  issue 101334 

Comment 78 by paxu...@gmail.com, Nov 25 2011

The default behaviour totally breaks any bookmarklets that dynamically load a script from http into the current https page.  Moreover, since they are bookmarklets and can only run in the currently visible content, clicking the infobar's "load anyway" button causes a page reload, making that bookmarklet useless.

Comment 79 by paxu...@gmail.com, Nov 25 2011

I should clarify:  re-running the bookmarklet after the reload does work.  Maybe that's the best we can get, without having to modify a bookmarklet to load from https.
@paxunix: thanks for the comment, and an interesting use case. The dynamic loading of an http script into an https page does represent an unpleasant security vulnerability (i.e. the total loss of HTTPS), so if the script can be fetched over https, that would be first preference.
I won't complain about the default settings.
But when I land in a "not really secure" site with mixed content, with the appropriate warning icon, I should be able to ask to reload the page without this content (without restarting Chrome with a --no-displaying-insecure-content option I should take back afterward).
Is there a way to do so ? IE does this with a popup or infobar letting the user choose. But it is fine to let load insecure content (display, not script), and in the https information under the warning icon, have a button allowing to reload safely (though maybe a bit broken).
Else I am stuck in a login page not beeing able to log in really securely...

last page I encountered the problem :
https://monespace.generali.fr/portal/public/creation
Could you report that to whoever owns https://globalchokepoints.org/countries/france ? Telling us (chromium developers) about an error on some website out there doesn't help anyone.

Comment 84 by adys...@gmail.com, Jan 24 2012

That would be the EFF. But openlayers is the one who should be contacted, they don't provide an https alternative and their api is supposed to be public.

BTW, I'm reporting here because a chromium dev asked to report insecure content errors here; if that's changed I'm happy to stop.

Comment 85 by sleevi@google.com, Jan 24 2012

adys.wh: That request only applied towards Google properties, to ensure that things were properly reported internally (which your feedback has been appreciated.

To echo what James has said, it would be best to directly contact the owner/operator of the site in question.

Thanks! 
I'll ping EFF.

Comment 87 by adys...@gmail.com, Jan 25 2012

https://sites.google.com/site/jknottinc/ is causing trouble too (It's the example site in google sites -> business template)

Comment 88 by adys...@gmail.com, Jan 25 2012

Nevermind, doesn't seem to be affiliated with Google, but quite a few templates seem to be causing trouble. Is it fixable by the Sites team?
I believe this happens when it attempts to load adsense ads (http) on any
google site (https). It's been an issue for months now that someone really
needs to resolve...

Comment 90 by agl@chromium.org, Jan 25 2012

Thanks for the heads up. We're aware of the unfortunate interaction between AdSense and Sites and are working to address it.

Comment 91 by adys...@gmail.com, Jan 31 2012

https://services.google.com/events/adsense_games triggers it.

Though the page looks outdated, adsense for video is much better and doesnt trigger it:
https://support.google.com/adsense/bin/request.py?hl=en&contact_type=video_joinbeta&rd=1

Comment 93 by agl@chromium.org, Apr 18 2012

adys.wh: thanks for the report. Can you tell us what you did to trigger that? It doesn't trigger for me and, if it's something simple like "do a search", then you're probably seeing an experiment that I'm not.

Comment 94 by adys...@gmail.com, Apr 18 2012

It's simply on the page. I'm logged in and have a delegated account in my account list, from the UK, no special preferences afaik.

Logged out in incognito I see it too.

Comment 95 by agl@chromium.org, Apr 18 2012

adys.wh: thanks for the notice. We're fixing the issue ASAP.

Comment 97 by agl@chromium.org, Apr 25 2012

adys.wh: thanks, I'll chase that up.
I'm seeing "This page has insecure content" on https://support.google.com/drive/bin/answer.py?hl=en&answer=2374855&topic=2375074&ctx=topic (which I assume is the yt video)

Comment 99 by Deleted ...@, Aug 7 2012

Just trying to understand if something was done to enable users to accept unsecured content on a secured website. Just blocking unsecured css files makes Chrome inferior to any other browser out there right now. 
yuval: The old infobar has been replaced with a shield icon in the URL bar in chrome 21.0.1180.57.
"Just blocking unsecured css files makes Chrome inferior to any other browser out there right now." -- isn't it quite the opposite? Chrome seems to now have a leading security story here but you can still run the CSS if you really want to, via the new shield icon as noted by adys.wh in comment 100.

If there are any web sites which are very broken and rely on "mixed CSS" to work properly, please list them on this bug. We can reach out and get the website owner to fix their security vulnerability.
Here's a good reference in case anyone else ends up here:

http://blog.chromium.org/2012/08/ending-mixed-scripting-vulnerabilities.html

A lot of websites' https setup is broken like that. If you run the https everywhere extension, you'll see exactly just how many. To name a few popular ones: xkcd.com, nytimes.com, twitch.tv...
@adys.wh: interesting! Presumably no-one links to the https versions of those sites, otherwise they'd be widely broken in other browsers too? (IE9 comes to mind, and Firefox also has plans to catch up in this area IIRC)
1. Looks like Android Chrome app does not block mixed content (? for
example, I tested on https://nytimes.com).
And it is even more difficult for an user, on a phone, to check the source,
the certificates...

2. On the desktop, the shield message is not very clear (in french : "Cette
page pr
@chris

Does Chrome gather any data itself on websites affected by mixed content? If not it probably should.
@adys...

Many corporate intranet sites are misconfigured in this fashion.  I doubt those companies would appreciate having data about their internal URLs collected in this fashion.
@fewaffles

Chrome has an opt-in for "generic collection of data" at installation time. Plus, it would obviously ignore any internal urls (without tld, or even not .com/net/org/cctld). it was just a thought
I can't use the Private Gadget Editor or Domain Gadget Directory from Chrome 21 because those Google developed gadgets refer to a non-https javascript file.  The gadgets themselves are available via https.  If Google is blocking this, then they need to make sure their stuff is in order first.

Also, I am seeing no shield prompt in the Omnibar.  Now I have to use the --allow-running-insecure-content or use a different browser.
Some sites (such as those that opt into HSTS, or those that we whitelist (eg. google.com) are held to a higher standard, for which no bypass is provided.  Please provide the URLs of the non-compliant pages and we'll suitably flog them.
@russell.milliner: thanks for the note, but you seem to have omitted the faulty URLs that we would need to follow up and get this promptly looked into and fixed.

Comment 112 Deleted

There's something more to this issue. On a simple https:// login form on a website of ours (private url, sorry), we have this html snippet:

<link rel="stylesheet" type="text/css" href="/static/main.css" />

When I mouse over the links, I see they point to https://.../static/main.css, which is correct. But when I click on the links, I get a (presumably cached) non-secure version, and the url bar shows: http://.../static/main.css. I'm seeing this problem in google chrome v21. 

Is it possible that the caching system is broken wrt honoring protocol? I've seen this exact situation on a number of our sites.



This bug is closed and won't be monitored, so it's best to file a new bug with a repro case we can diagnose. However, first you should verify that what's happening is not actually a server-side redirect from HTTPS to an HTTP URL (which is the more likely situation).

Comment 115 by Deleted ...@, Oct 2 2012

Chrome is not displaying unsecure content without any kind of warning or way to override. This makes life very difficult for me.
dloverde, you'd have to provide us with a specific URL for us to take any action.
dloverde, check the "Shield" icon in the Omnibox/Location bar. It's in the right-hand side. Clicking on it will show an option allowing you to load the unsafe code.

Comment 118 by Deleted ...@, Nov 2 2012

I need to be able to "Enable Display Mixed Content" on Google Chrome.  A site that we must use at work has to have the Mixed Content enabled, or it won't work.  I was able to enable the mixed content on IE, but I don't really care for IE, and our workplace as a whole is migrating to Gmail and other Google Chrome features, but if I need to run this particular program, I'll have to open IE, log into the particular site and run it from there.  I'd rather just stay with Google Chrome, but you leave me no choice.
I have coworkers who must either use Firefox or use google chrome and click the shield icon literally hundreds of times a day. There really needs to be a config setting for "allowed domains for mixed content".
See http://support.google.com/chrome/bin/answer.py?hl=en&answer=1342714

Although not recommended, you can also use the command line flag --allow-running-insecure-content to prevent Chrome from checking for insecure content. Instructions on how to add a command line flag can be found on our Chromium site (English only).
Indeed, the content settings screen would be a great place to manage 
such exceptions, but it does not appear to be there, at least in version 
22 on ubuntu linux. Adding a cookie and site data exception does not 
seem to have any effect. Am I missing something obvious?

Comment 122 by re...@harts.net, Nov 17 2012

Videos at Coursera appear to be blocked because of this issue.
https://class.coursera.org/progfun-2012-001/lecture/index
Version 22.0.1229.94 Ubuntu 12.10 (161065)
Works fine in Firefox.

Java script console and the security padlock (before location) duly show that this is a mixed content page, although these are not sufficiently obvious when the user is faced with a blank page. 

Suggested actions: Alert on mixed content; allow override by source domain or URL prefix.

@122: Have you pointed out the issue to Coursera? They need to know about this problem.
Also, is there any reason that insecure content shouldn't be loaded if it is already cached in the browser? That would probably mitigate the problem greatly.
I don't follow.  There's no reason to believe the content was legitimate at the time it was first cached, so why would subsequent use be legitimate?

Comment 126 by re...@harts.net, Nov 20 2012

@123: Yep, I told Coursera. They haven't replied yet.  I also gave them the link to this issue.   (#123)
Add this to the list of references now silently blocked by Chrome:
type="text/javascript" src="http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.3" which is referenced in https sites.

How arrogant can Chrome get? They won't even admit they screwed up on this. When they write the book on Google/Chrome the subtitle will be something like "How Arrogance Destroyed the Empire"
 

Comment 128 by adys...@gmail.com, Jan 30 2013

https://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.3 is served just fine. Whatever site has src="http://..." should change it to src="//...". Chrome's behaviour is correct there.
Project Member

Comment 129 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Feature-Security -Mstone-15 Cr-Security Cr-Internals M-15

Comment 130 by Deleted ...@, Oct 9 2013

I appreciate googles intent.  However so much educational media is affected that this is a serious eye-sore for me.  Would google consider allowing people to manage exceptions similar to other things (such as when to allow java) so at least if we have a subset of sites we regularly use we don't have to finght this issue daily.
Given that firefox is moving to the same model, those sites will have to just fix those errors at some point...
Labels: Restrict-AddIssueComment-EditIssue
Yes, the sites are simply broken. Closing comments because the bug is fixed and the behavior is correct.

Sign in to add a comment