Closed Bug 844555 Opened 13 years ago Closed 13 years ago

Mixed content blocks YouTube videos in Google Reader

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: Dolske, Unassigned)

References

Details

I use Google Reader to read a variety of RSS feeds. Since turning on the security.mixed_content.block_active_content pref, every time an article has an embedded YouTube video, it's blocked. (I get the shield icon/doorhanger as expected) I mentioned this in passing to bsmith the other day, who seemed surprised. Sounded like for him everything is working fine for him. Filing this bug to look into if this is (A) some client-side inconsistency we should fix or (B) some server-side inconsistency we should try to understand and possibly get Google to fix. FWIW, I'm not in the YouTube HTML5 trial (http://www.youtube.com/html5), although I was in the past. [YouTube''s HTML5 support and bandwidth has seemed flaky, so I switched back to Flash :-(] FWIW2, I've had the pref on for a week, and this is the only breakage I've noticed.
Hmm. I may not have been clear: The videos are blocked in Google Reader. So, for example, when I see a new article from the http://cuteoverload.com/ feed, I'll often just get a big blank/white area where the YouTube video would normally be. Clicking the article title to open the site in a tab does work fine. (Unsurprisingly, since most of the sites are not SSL and thus mixed-content isn't involved at all.) The Google Reader tab I have pinned is https://www.google.com/reader/view/.
I wonder if this is some kind of breakage unique to Google Reader -- YouTube videos work fine on Twitter. (eg https://twitter.com/mart3ll/status/305462050350567424)
(In reply to Justin Dolske [:Dolske] from comment #2) > I wonder if this is some kind of breakage unique to Google Reader -- YouTube > videos work fine on Twitter. (eg > https://twitter.com/mart3ll/status/305462050350567424) Please immediately make a complete backup of your Firefox profile in which you are experiencing this issue. Then, please try it in a new profile. Last week, I tried to reproduce using the same RSS feed that dolske was reading and I couldn't. I suspect the cause may be something like a Google Reader script in your HTTP cache that assumes that Firefox allows all mixed content, but if/when that script is updated from the server, things will work fine again. Or, something along those lines. I tried with and without the YouTube HTML5 preview enabled.
(In reply to Brian Smith (:bsmith) from comment #3) > (In reply to Justin Dolske [:Dolske] from comment #2) > > I wonder if this is some kind of breakage unique to Google Reader -- YouTube > > videos work fine on Twitter. (eg > > https://twitter.com/mart3ll/status/305462050350567424) Twitter is using <embed src=https://...> so there is no mixed content.
I started Nightly with a new profile and signed into Google Reader. Videos in various feeds were ok. Then I flipped the mixed/active pref, and loaded Reader in a new tab. Same breakage as my regular profile. I also tried a new profile, but flipped the pref _before_ logging into Google. Also broken. I wonder if it depends on some per-account setting? Not sure why else it would work for you but not for me.
I wonder if this is a common mistake for sites to make. We just did it on https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of-the-web-as-a-platform-for-gaming/ HTTPS url, content with <iframe src="http://www.youtube.com/embed/XsyogXtyU9o?feature=oembed">. I was wondering why it was just text with big empty sections...
(In reply to Justin Dolske [:Dolske] from comment #6) > I wonder if this is a common mistake for sites to make. We just did it on > https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of- > the-web-as-a-platform-for-gaming/ > > HTTPS url, content with <iframe > src="http://www.youtube.com/embed/XsyogXtyU9o?feature=oembed">. I was > wondering why it was just text with big empty sections... Yes it is, especially on mozilla.org because our developers tend to use Firefox and Firefox doesn't help them avoid this issue yet. There is already a bug on file about automatically rewriting http:// -> https:// in these situations instead of just straight-up blocking the load.
This seems like another occurance, although it is likely very common, https://unigine.com/products/oilrush/media/ Has anyone been in touch with EFF about HTTPS Everywhere? This seems like a commonly used extension that could be badly impacted by this change.
(In reply to Bryan Quigley from comment #8) > Has anyone been in touch with EFF about HTTPS Everywhere? This seems like a > commonly used extension that could be badly impacted by this change. By what change? The auto upgrading (bug 776278) or mixed active content blocking in general? Mixed Active Content blocking shouldn't affect HTTPS Everywhere. For auto upgrading, it depends on how it is implemented. If HTTPS Everywhere is invoked first, it will do the upgrading for Firefox. If Firefox upgrades first, HTTPS Everywhere will see an HTTPS link and skip it. But perhaps there is an issue I'm not thinking of at the moment. We should definitely test with HTTPS Everywhere to make sure that we don't break it. Thanks for bringing it up. I will note it on the auto upgrading bug.
(In reply to Tanvi Vyas [:tanvi] from comment #9) > Mixed Active Content blocking shouldn't affect HTTPS Everywhere. For auto > upgrading, it depends on how it is implemented. If HTTPS Everywhere is > invoked first, it will do the upgrading for Firefox. If Firefox upgrades > first, HTTPS Everywhere will see an HTTPS link and skip it. But perhaps > there is an issue I'm not thinking of at the moment. I think this is related to the idea that mixed content blocker should run after all nsIContentPolicies and other callbacks, so that we don't block something that HTTPS Everywhere will upgrade. It is very similar to the "don't block things that would be upgraded by HSTS" issue.
> mixed active content blocking in general? The very simple case that I just had with the unigine site. It got upgraded to SSL with HTTPS Everywhere, which then blocked youtube. I'm guessing they would have to change their rules a bit.
(In reply to Brian Smith (:bsmith) from comment #7) > There is already a bug on file about automatically rewriting http:// -> > https:// in these situations instead of just straight-up blocking the load. Note that in bug 776278, people argue against rewriting URLs automatically... This problem is not specific to Google Reader, I noticed this with another feed reader https://www.newsblur.com/site/903/i-can-has-cheezburger
Bug 879075 was filed for newsblur. (In reply to Nickolay_Ponomarev from comment #12) > This problem is not specific to Google Reader, I noticed this with another > feed reader https://www.newsblur.com/site/903/i-can-has-cheezburger
Google Reader is ending on July 1st. Should this bug be closed?
(In reply to Bryan Quigley from comment #14) > Google Reader is ending on July 1st. Should this bug be closed? Let's wait for that to actually happen.
Google Reader has now been shut down.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.