- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 10 Mar 2011 09:12:00 +0100
On Wed, 09 Mar 2011 19:48:30 +0100, Aaron Colwell <acolwell at google.com> wrote: > Thanks for your response.. comments inline > > On Fri, Mar 4, 2011 at 1:30 AM, Philip J?genstedt <philipj at opera.com> > wrote: > >> On Thu, 03 Mar 2011 22:15:58 +0100, Aaron Colwell <acolwell at google.com> >> wrote: >> >> Hi, >>> >>> I was looking at the resource fetch >>> algorithm< >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource >>> >section >>> and fetching >>> resources < >>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetch >>> > >>> sections of the HTML5 spec to determine what the proper behavior is for >>> handling >>> redirects. Both YouTube and Vimeo do 302 redirects to different >>> hostnames >>> from >>> the URLs specified in the src attribute. It looks like the spec says >>> that >>> playback should fail in these cases because they are from different >>> origins (Section 2.7 Fetching resources bullet 7). This leads me to a >>> few >>> questions. >>> >>> 1. Is my interpretation of the spec correct? Sample YouTube & Vimeo >>> URLs >>> are >>> shown below. >>> YouTube : src : http://v22.lscache6.c.youtube.com/videoplayback? >>> ... >>> redirect : >>> http://tc.v22.cache6.c.youtube.com/videoplayback? >>> ... >>> >>> Vimeo : src : http://player.vimeo.com/play_redirect? ... >>> redirect : http://av.vimeo.com/05 ... >>> >> >> Yes, from what I can tell you're correct, but I think it's not >> intentional. >> The behavior was changed by <http://html5.org/r/5111> in 2010-06-25, and >> this is the first time I've noticed it. Opera (and I assume most if not >> all >> other browsers) already supports HTTP redirects for <video> and I don't >> think it makes much sense to disallow it. For security purposes, the >> origin >> of the resource is considered to be the final destination, not any of >> the >> origins in the redirect chain. >> >> >> I agree that redirects should be allowed, but it seems like the force > same-origin flag was introduced to limit the types of redirects. The > YouTube > & Vimeo cases mentioned above seem reasonable, but redirects from > vimeo.comto malicious-site.com might not be ok. As far as I can tell, there's no difference between the YouTube/Vimeo cases and redirecting to malicious-site.com. In both cases, they redirect to another origin, so the exact same thing should happen. Besides, if a good site redirects to an evil site, that's your problem right there. The only issue I'm aware of is if an evil site redirecting to good site, in the hope that the origin of the resource would still be considered evil site, so that they can read out pixel data, etc. That would be a browser bug, though. > It looks like the changes reference CORS > as a future solution. Do you have any CORS references that might be > helpful? Nothing beyond <http://www.w3.org/TR/cors/>, no. Anne is the editor and is on this list so he'll know more if you have specific questions. > You also mentioned that the final destination is what should be used for > security. It seems like this could cause problems for canvas.drawImage() > ( > http://www.whatwg.org/specs/web-apps/current-work/#security-with-canvas-elements) > when trying copy video data to the canvas. If I understand you correctly > a > page on YouTube would have to come from the final destination origin to > allow canvas.drawImage() to work. Is that correct? The details of this is outlined in <http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#security-with-canvas-elements>. The case you mention is this one: "The element's 2D context's drawImage() method is called with an HTMLImageElement or an HTMLVideoElement whose origin is not the same as that of the Document object that owns the canvas element." However, since the spec now says that redirecting video cross-origin should just fail, it doesn't match what at least Opera actually does here. >> 2. What about http: -> https: redirects? Some content is required to be >>> delivered >>> only via https and this sort of redirect enforces that but isn't >>> really >>> a >>> different origin. >>> >> >> Quoting < >> http://tools.ietf.org/html/draft-abarth-principles-of-origin-00#section-3 >> >: >> >> "two URLs are part of the same origin (i.e., represent the same >> principal) >> if they have the same scheme, host, and port" >> >> Since both the scheme (http vs https) and port (80 vs 443) would be >> different, it's considered a different origin. > > > I think I made some poor word choices here. I agree that they are > different > origins because the scheme and port are different. I was just trying to > get > at the fact they still referred to the same content just over a secure > connection. It seems like there are use cases where a set of <scheme, > host, > port> tuples should be considered a single origin from a security point > of > view. It just isn't clear to me how we are supposed to express that. What problem does this solve, though? >> 3. If my interpretation of the spec is correct, are there proposals to >>> change this >>> or other specs that allow content providers to signal that these >>> different hostnames >>> actually represent the same "origin". >>> >> >> I think the force same-origin flag introduced by >> <http://html5.org/r/5111> >> should be removed from the resource fetch algorithm, but the http vs >> https >> origin issue is not something that can really be changed. >> > > So what is the process for proposing this type of change? Is this the > right > forum? > Why is allowing redirects with the same scheme but different hosts ok, > but > redirecting different schemes with the same host not ok? I'm new to this > so > I'm just trying to understand. There is no strict process here, but I suppose if you want to change or invent new security models, this is as good a forum as any. Step 1 would be explaining what the problem you want to solve is, not a specific solution you have in mind. -- Philip J?genstedt Core Developer Opera Software
Received on Thursday, 10 March 2011 00:12:00 UTC