I'm still not convinced that implementing this as a feature of the User Agent benefits the user or is the most appropriate technology for addressing the problem statements in the specification.
What are the use cases where a user is better off if their browser obeys From-Origin than if it does not? Bandwidth "theft"? The user wants to see the image. The problem, such that one exists, is for the hosting server. They can and do address this risk with the Referrer header today. Servers are not better off with this mechanism, since From-Origin is enforced too late, on the client-side, after they've already paid the bandwidth cost to send the image. Font licensing? Again, the user would prefer that his or her agent display the font. The license here is about attempting to keep the user from using something of value and their own agent is a poor policy enforcement point for this. Clickjacking? X-Frame-Options has support in every major browser and is currently sent by over 10,000 sites according to http://www.shodanhq.com/. I see little reason to re-invent something with such broad adoption, or to conflate a feature that is scoped to provide clear security benefit with additional features that users are incentivized to disable. (client-side license and bandwidth "theft" enforcement) Privacy leakage? Elimination of side channels is an extremely difficult task; generally the best result is that the bandwidth of such channels can be limited, but we are attempting to protect a single bit of information here. Methods such as cache-timing and the active attacks recently described by Weinberg, et al (http://websec.sv.cmu.edu/visited/visited.pdf) are likely more than sufficient to reveal whether a user has an account somewhere. Do we have any data here on how common this very specific kind of leakage is, and if there are any sites that would actually be interested in sending this header for this purpose? For this specific case, I would again assert that server-side enforcement based on Referer is simpler and more likely to succeed, as the server can send the same response for both conditions to unauthorized parties, instead of sending a differential response anyway and asking that it not be measured. -Brad P.S: the header itself is a cause of privacy leakage for the sending server by indicating which other servers it is willing to allow embedding content in. There are also issues of header size with the proposed approach. In X-Frame-Options, the current discussion is to allow only a single origin instead of a list. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Anne van Kesteren Sent: Friday, July 22, 2011 8:09 AM To: WebApps WG Subject: From-Origin FPWD Hi, The WebApps WG published the From-Origin header proposal as FPWD: http://www.w3.org/TR/from-origin/ The main open issue is whether X-Frame-Options should be replaced by this header or should absorb its functionality somehow. Cheers, -- Anne van Kesteren http://annevankesteren.nl/
