841613 - Use a Vid.ly iframe over HTTPS

Status: RESOLVED FIXED

(Webtools Graveyard :: Air Mozilla, defect, P1)

Description

[Peter Bengtsson [:peterbe]]

At the moment we include archived videos from vid.ly with `<iframe src="http://vid.ly/..."` and that's going to break Nightly shortly.

Comment 1

[Richard A Milewski[:richard]]

I have a support request into Vid.ly.  I'll report back here when they reply.

Comment 2

[Richard A Milewski[:richard]]

Vid.ly support pointed us at this:

http://www.encoding.com/help/article/how_do_i_use_the_https_version_of_vid.ly_urls_and_thumbnails

Comment 3

[Peter Bengtsson [:peterbe]]

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.

Comment 4

[Richard A Milewski[:richard]]

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?

Comment 5

[Richard A Milewski[:richard]]

Is this in nightly yet?   Do I need to change a pref to test?

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(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

Comment 7

[Tanvi Vyas[:tanvi]]

Still aiming for FF22 (the current nightly).  The bug that tracks when the pref turns on is bug 834836.  Any updates from vid.ly?

Comment 8

[Richard A Milewski[:richard]]

No news, but I have an open support ticket on the issue.

Comment 10

[Anthony Ricaud (:rik)]

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.

Comment 13

[Alex Keybl [:akeybl]]

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?

Comment 14

[Tanvi Vyas[: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.

Comment 16

[Vova Manannikov]

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?

Comment 17

[Richard A Milewski[:richard]]

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?

Comment 18

[Richard A Milewski[:richard]]

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.

Comment 19

[Zandr Milewski [:zandr]]

Vova, Please try https://air.mozilla.org/the-monday-meeting-20130415/ , which uses 2u3s8a

Comment 20

[Peter Bengtsson [:peterbe]]

(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.

Comment 21

[Peter Bengtsson [:peterbe]]

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".

Comment 22

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Awesome! Thanks for taking care of this!

Comment 23

[Tanvi Vyas[:tanvi]]

This is great!  Thank you!