On Wed, 09 Mar 2011 19:48:30 +0100, Aaron Colwell <[email protected]>
wrote:
Thanks for your response.. comments inline
On Fri, Mar 4, 2011 at 1:30 AM, Philip Jägenstedt <[email protected]>
wrote:
On Thu, 03 Mar 2011 22:15:58 +0100, Aaron Colwell <[email protected]>
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
