W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: XMLHttpRequest Object feedback

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Fri, 7 Apr 2006 13:46:25 -0700
Message-Id: <6CBC3A1B-C2FA-4D79-8686-A0D8C2F54C8C@yahoo-inc.com>
Cc: <public-webapi@w3.org>
To: Jim Ley <jim@jibbering.com>

On 2006/04/07, at 12:40 PM, Jim Ley wrote:
>> AIUI that's under discussion in a TF now.
> So the task force can decide the behaviour rather than pre-empting  
> their conclusions with a MUST or SHOULD that is only relevant after  
> they have decided.  Given that at least one likely conclusion will  
> be a whitelist file allowing cross domain from such sites, your use  
> case is met without endangering user freedoms.

Not quite; a site may choose to open its content using an access- 
control of "*", yet still need the referer for auditing, or selective/ 
dynamic access controls to it. If you have a complex ACL, it's very  
inefficient -- and for larger sites, unfeasible -- to force people to  
write the whole ACL directly into content, and rewrite the content  
each time the ACL changes.

>>> and then usefully there's a way
>>> of taking an XHR stream and converting it to an image or video   
>>> stream, again
>>> something that doesn't exist.
>> You're losing me here; how do "image or video streams" come into it?
> Because anything included in an IFRAME or new window is already  
> trivially able to be retrieved without a referrer header in the  
> vast majority of UAs that support script today.  The only things  
> you cannot do is add an image with img (you can with iframe) or css  
> background or content in an embed element, so the only relevant  
> protection you're introducing is in these formats, not simple HTML  
> or text documents.

Just because there are a few corner cases where Referer isn't set  
(note, it still can't be changed there) doesn't mean that it should  
be able to be manipulated by any site that wishes to.

Mark Nottingham
Received on Friday, 7 April 2006 20:47:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC