Closed Bug 841613 Opened 7 years ago Closed 7 years ago

Use a Vid.ly iframe over HTTPS

Categories

(Webtools :: Air Mozilla, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: peterbe, Assigned: peterbe)

References

(Blocks 1 open bug)

Details

(Keywords: compat, Whiteboard: [MixedContentBlocker])

At the moment we include archived videos from vid.ly with `<iframe src="http://vid.ly/..."` and that's going to break Nightly shortly.
Priority: -- → P1
Keywords: compat
OS: Mac OS X → All
Hardware: x86 → All
See Also: → 834836
Whiteboard: [MixedContentBlocker]
I have a support request into Vid.ly.  I'll report back here when they reply.
Can you respond:

On https://air-dev.allizom.org/wheres-my-vote-20121107/
we switched to use https://vid.ly/embeded.html?link={{tag}}&new=1&autoplay=false&hd=yes&token={{token}}
All images (from cloudfront) are loading fine but the video is not playing. 
I noticed that the URL https://vid.ly/0o4i1s?content=video&format=webm causes a 302 redirect to http://m.vid.ly/ which is not good since that leaves HTTPS.
Vid.ly replied:

Thanks for the heads up. We'll look into the redirect issues that you reported. When does mozilla go full HTTPS with this product?


...can I give them an estimate of the date of the apocalypse?
Is this in nightly yet?   Do I need to change a pref to test?
(In reply to Richard A Milewski[:richard] from comment #4)
> Vid.ly replied:
> 
> Thanks for the heads up. We'll look into the redirect issues that you
> reported. When does mozilla go full HTTPS with this product?
> 
> 
> ...can I give them an estimate of the date of the apocalypse?

Firefox 22, So, around June 25th.

(In reply to Richard A Milewski[:richard] from comment #5)
> Is this in nightly yet?   Do I need to change a pref to test?

security.mixed_content.block_active_content=true
Still aiming for FF22 (the current nightly).  The bug that tracks when the pref turns on is bug 834836.  Any updates from vid.ly?
No news, but I have an open support ticket on the issue.
Duplicate of this bug: 860251
This is now in today's Nightly so I think we should be proactive and insert a message on Air Mozilla before our community thinks Air Mozilla is broken.
Duplicate of this bug: 726215
Duplicate of this bug: 860690
I'm nominated this as a good use case for determining whether the current UI is discoverable enough for our end users, in this simple use case. Does the user need to discover the shield themselves to workaround, or can we add a dialog/glow similar to what we do for CTP?
Flags: needinfo?(tanvi)
The preference to block mixed active content is turned on in Firefox 23.

(In reply to Alex Keybl [:akeybl] from comment #13)
> I'm nominated this as a good use case for determining whether the current UI
> is discoverable enough for our end users, in this simple use case. Does the
> user need to discover the shield themselves to workaround, or can we add a
> dialog/glow similar to what we do for CTP?

We have discussed the discoverability of the Mixed Content Blocker doorhanger at length.  We didn't want to show the user the doorhanger every single time they encountered a mixed content warning because the page may work perfectly fine with the mixed content loaded.  Also, this would contribute to security warning fatigue.  Our first proposal was to show the doorhanger the first 3 times a user encounters any page with mixed content (so 3 times per browser, not 3 times per user).  After further thought, UX had some other ideas being discussed in bug 834828.

Note that Chrome's mixed content blocker is also a shield/badge in the location bar that does not provide any information/text unless you actually click on it.

IE's Mixed Content Blocker (which blocks mixed content iframes and hence is triggered or airmozilla) shows a light yellow bar at the bottom of the page.

Since this question is about the discoverability of the mixed content blocker, and isn't specific to vid.ly, I think further discussion about the UI should take place in bug 834828.  We can use this bug as an example use case, but I don't want to deter from the work to move vid.ly to https.
Flags: needinfo?(tanvi)
Duplicate of this bug: 861109
Hi,

> On https://air-dev.allizom.org/wheres-my-vote-20121107/ we switched to use
> https://vid.ly/embeded.html?link={{tag}}&new=1&autoplay=false&hd=yes&token={{token}}
> All images (from cloudfront) are loading fine but the video is not playing. 
> I noticed that the URL https://vid.ly/0o4i1s?content=video&format=webm
> causes a 302 redirect to http://m.vid.ly/ which is not good since that leaves HTTPS.

This URL https://vid.ly/0o4i1s is currently in ERROR state (this should be visible from admin panel). 
It won't work anyway, with or without https.
Could you try to restart it please?
Vova,

We'll look for another example with a working transcode.   But there are a couple of issues here:

After Firefox 23, (and in our current Nightly builds) the redirect to http://m.vid.ly/ will be blocked as a security measure.  We have reports that beta versions of Chrome are doing the same.  Vidly needs to ensure that all redirects from an https:// page are to another https:// page.

Can you confirm that 302 redirects from https: to http: only occur in cases of a failed transcode?
Vova,

Which admin panel are you referring to?   

Currently our only visibility of the status of transcodes is with a GetStatus XML call.  That only provides a binary ("Error" vs "Finished") indication.  

For videos such as the "Where's My Vote" video which failed transcoding many times over a three week period, we need some indication of WHY the transcode failed, not just that it did.
(In reply to Zandr Milewski [:zandr] from comment #19)
> Vova, Please try https://air.mozilla.org/the-monday-meeting-20130415/ ,
> which uses 2u3s8a

Vova, Zandr, Richard,

I picked another random video on https://air-dev.allizom.org/ and switched it to the HTTPS iframe embed tag and lo and behold, it worked!!

For example
https://air-dev.allizom.org/intern-presentation-message-passing-in-rust/

All this time we've been testing and testing on a "broken" video. 

Still though, that "Where's my vote" video USED to work when we served it with the HTTP iframe tag.
We have now switched the IFRAME embed tag that uses HTTPS:// on Air Mozilla production. E.g. https://air.mozilla.org/poetic-apis/

And it works.

Turns out that the whole time, when we were testing on the dev server, we were testing with a video that was apparently "broken".
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Awesome! Thanks for taking care of this!
This is great!  Thank you!
Assignee: nobody → peterbe
You need to log in before you can comment on or make changes to this bug.