- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Fri, 7 Apr 2006 13:46:25 -0700
- To: Jim Ley <jim@jibbering.com>
- Cc: <public-webapi@w3.org>
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 mnot@yahoo-inc.com
Received on Friday, 7 April 2006 20:47:34 UTC