On Fri, Nov 7, 2008 at 2:21 PM, Silvia Pfeiffer <span dir="ltr"><<a href="mailto:silviapfeiffer1@gmail.com">silviapfeiffer1@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
From: Robert O'Callahan <<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>><br>
Date: Thu, Nov 6, 2008 at 5:12 PM<br>
<div class="Ih2E3d">> On Thu, Nov 6, 2008 at 4:12 PM, Gregory Maxwell <<a href="mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>> wrote:<br>
>> On Wed, Nov 5, 2008 Robert O'Callahan <<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>> wrote:<br>
>> [snip]<br>
>> > The main reason is that it gives servers control over who uses their<br>
>> > resources. Checking 'Referrer' headers doesn't work well since it<br>
>> > denies access to anyone behind a firewall that strips Referrer for<br>
>> > good privacy reasons (or similarly, disables Referrer in the browser<br>
>> > for the same reasons).<br>
>><br>
>> I think most people who have done serious web work are aware of the<br>
>> significant shortcomings of referrer (unreliability, inability to<br>
>> distinguish reference from embedding, etc). I'm very glad to see the<br>
>> new control tools.<br>
<br>
</div>What makes us think that a new HTTP header will be used more<br>
consistently than referrer?</blockquote><div><br>Some people, and many firewalls, turn off or strip the Referrer header because it reveals the full URL of the referring page. So for example, if <a href="http://intranet.example.com/WorldDomination/mind-control.html">http://intranet.example.com/WorldDomination/mind-control.html</a> has a link to <a href="http://wikipedia.org">wikipedia.org</a>, <a href="http://example.com">example.com</a>'s firewall might strip Referrer to avoid leaking information to <a href="http://wikipedia.org">wikipedia.org</a>.<br>
<br>The Access Control spec improves matters in two ways:<br>1) The "Origin" header, unlike "Referrer", contains only the domain, not the full URL, and I don't think we'll be sending Origin for link navigation. So it's much less of an information leak and we (browsers, the W3C, etc) will be encouraging firewalls to not strip it.<br>
2) For simple cases (only same-origin allowed, or only one other domain allowed), the server can leave the access check to the browser and things will work even if Origin is stripped.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>> But what would be lost for this purpose by having a fail-working<br><div class="Ih2E3d">
>> situation: Client sends "Origin:" and the client displays the result<br>
>> unless the server response indicates otherwise?<br>
><br>
> Good question. The main reasons:<br>
> 1) It's generally a good idea to make the secure option the default.<br>
> 2) Access Controls is used in situations (such as cross-site<br>
> XMLHttpRequest) where the default is (and must remain) restriction to<br>
> same-origin. Varying the default based on the kind of load would be<br>
> confusing, and probably dangerous.<br>
<br>
</div>So does this mean that in the current situation, where no servers<br>
support the header, the <video/> element will be useless because it<br>
will not allow any video to be played?</blockquote><div><br>Not at all. Any site where the video file is hosted on the same domain as the HTML page containing the <video> will always work just fine. (And I'm sure there are *some* servers that already have "Access-Control-Allow-Origin: *" since it's trivial and they're experimenting with cross-site XHR.)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If search engines cannot access captions and subtitles and any other<br>
annotations, that will be really useless.</blockquote><div><br>Nothing we're talking about here will have any impact on search engines.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Serving media streams that can be "hotlinked" by anyone in the world<br><div class="Ih2E3d">
> doesn't seem like something that everyone is going to want to do. If<br>
> you want to do it, you need a reasonably large operation capable of<br>
> handling a lot of traffic. Already today most people who want to serve<br>
> video just upload it to some site that does all the hard work for<br>
> them.<br>
<br>
</div>To me this sounds backwards. People complained about the bandwidth use<br>
of images when the Web began. I think that bandwidth is not an issue<br>
any longer, or at least increasingly less important. I know from my<br>
own experience with customers that people are currently outsourcing<br>
their video operations because it is too complex to set up video for<br>
their sites, and because there is a lot of technology involved (flash<br>
players, thumbnailing, transcoding, embedding, cross-site domain<br>
managment). I thought the creation of the <video/> tag was about<br>
making this easier, not more complicated.</blockquote><div><br>The need for an extra static header to enable cross-site video loading seems much more minor to me than the things you mentioned ... or the other inhibitors to <video> adoption, such as the problem of getting a free interoperable codec into major browsers.<br>
</div></div><br clear="all">Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>