Re: From-Origin FPWD
On Aug 1, 2011, at 10:29 AM, Hill, Brad wrote: > The ability to do all of these things server-side, with referrer checking, > has been universally available for fifteen years. (RFC 1945) > > In every one of the use cases below, From-Origin is a worse solution than > referrer checking. What is the benefit? Why should I choose From-Origin? > Why should we expect it to become universally deployed where referrer > checking is not? The From-Origin design has two advantages over server-side Referer checking: 1) The Referer header is stripped by intermediaries, often enough that sites targeting a wide user base must be prepared for the fact that it may not be present. This limits the effectiveness of checking it. 2) In many static hosting environments, it is easier to add a fixed response header than to add server-side logic to check Referer. It also enables better caching by intermediaries, as the response would not require a Vary: Referer rule. It's quite common to serve resources such as images or CSS from a dedicated host that only serves static resources and does not execute application logic. For these reasons, despite the availability of server-side Referer checking, many Web developers would find a solution like From-Origin convenient and helpful Regards, Maciej
Re: From-Origin FPWD
On Jul 31, 2011, at 5:52 PM, Bjoern Hoehrmann wrote: > * Anne van Kesteren wrote: >> http://www.w3.org/TR/from-origin/ > > The proposed `From-Origin` header conveys a subset of the information > that is already available through the Referer header. From-Origin is a response header and Referer is a request header, so this statement would be irrelevant even if true. Also, it is not true. Referer indicates the resource responsible for generating the request, From-Origin list the sites that are allowed embed access to the resource. I think you may be confusing the From-Origin header with the Origin header. Regards, Maciej
RE: From-Origin FPWD
The ability to do all of these things server-side, with referrer checking, has been universally available for fifteen years. (RFC 1945) In every one of the use cases below, From-Origin is a worse solution than referrer checking. What is the benefit? Why should I choose From-Origin? Why should we expect it to become universally deployed where referrer checking is not? -Brad From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert O'Callahan Sent: Monday, August 01, 2011 6:16 AM To: Hill, Brad Cc: Anne van Kesteren; WebApps WG Subject: Re: From-Origin FPWD On Thu, Jul 28, 2011 at 12:44 PM, Hill, Brad mailto:bh...@paypal-inc.com>> wrote: 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. If From-Origin is widely implemented, then there is no incentive to attempt to steal bandwidth since the stealing page will be broken for most users. Therefore authors won't even try to do it, so servers will be better off. 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. As above, as long as a majority of user-agents honor From-Origin, cross-origin embedding will be discouraged and authors will get a useful tool to control access to their resources. Some users choosing to disable From-Origin checking, or just downloading resources some other way, will not break the system. In fact, if most user-agents honor From-Origin, there is no incentive to do cross-origin embedding in a way that violates From-Origin, so authors won't, so there will be no incentive for users to disable From-Origin. 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. Precisely because side channels are very difficult to eliminate, we need to create mechanisms to prevent cross-origin embedding, since such embedding is prone to all kinds of information leakage due to side channels. For example, cross-origin image embedding leaks not just whether the image can be loaded, but also the image size, and there are proof-of-concept timing attacks that leak information about image pixel data. An intranet configured to use "From-Origin: same" by default, with all intranet users using From-Origin-supporting browsers, would be considerably more robust against information leaks than what we can ensure today. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Re: From-Origin FPWD
On Thu, Jul 28, 2011 at 12:44 PM, Hill, Brad wrote: > 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. > If From-Origin is widely implemented, then there is no incentive to attempt to steal bandwidth since the stealing page will be broken for most users. Therefore authors won't even try to do it, so servers will be better off. 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. > As above, as long as a majority of user-agents honor From-Origin, cross-origin embedding will be discouraged and authors will get a useful tool to control access to their resources. Some users choosing to disable From-Origin checking, or just downloading resources some other way, will not break the system. In fact, if most user-agents honor From-Origin, there is no incentive to do cross-origin embedding in a way that violates From-Origin, so authors won't, so there will be no incentive for users to disable From-Origin. 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. > Precisely because side channels are very difficult to eliminate, we need to create mechanisms to prevent cross-origin embedding, since such embedding is prone to all kinds of information leakage due to side channels. For example, cross-origin image embedding leaks not just whether the image can be loaded, but also the image size, and there are proof-of-concept timing attacks that leak information about image pixel data. An intranet configured to use "From-Origin: same" by default, with all intranet users using From-Origin-supporting browsers, would be considerably more robust against information leaks than what we can ensure today. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Re: From-Origin FPWD
* Anne van Kesteren wrote: > http://www.w3.org/TR/from-origin/ The proposed `From-Origin` header conveys a subset of the information that is already available through the Referer header. As it is, it is very rare for the Referer header, or coressponding interfaces that are available to scripts, to be absent and the draft does not even attempt to argue how the reasons for the Referer header's abscence don't apply to `From-Origin`. It also lacks a description of the problem domain. As an example, it is unclear that there are important use cases that require telling a.example.com apart from b.example.com (assuming that example.com is a "public suffix" while the subdomains are not). That's important if one were to design the mechanism where it's easy for a site to verify if the "from-origin" is acceptable, but hard to learn the actual "from-origin" when it is not. (Consider as a trivial example you send the MD5 of the "from-origin" instead of the actual value: verification would be easy, but learning the actual value would require to go through a possibly long list of possible origins; of course, brute force against MD5 is trivial, and if you use the "whole origin" you couldn't check for "*.example.com", without trying all possibilities for the wildcard, but cryptography offers other options, and knowing constraints is important to find and evaluate them.) Similarily, it is unclear whether there is actually an important need to know more than "same 'public suffix'" if "Referer" is there anyway most of the time (you can obviously make up examples to illustrate a difference, but there are usually design alternatives that render such examples unimportant). Clearly "Referer" information would be available more often if there had always been a policy to only strip path and query information in- stead of stripping it entirely, and the only difference between such a policy and the proposed header -- assuming the idea is that it'd be available 'always' -- that there wasn't such a policy. But that is about all there is to this proposal at the moment, and I don't find that very convincing. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
RE: From-Origin FPWD
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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] 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/
RE: From-Origin FPWD
-Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] 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/
Re: From-Origin FPWD
On Fri, 22 Jul 2011 22:47:59 +0200, Jonas Sicking wrote: It seems to me like this feature heavily overlaps with CORS. In fact, it addresses the exact same cases, except that it does it for resources which we for various reasons use allow-embedding-but-not-reading cross site. Would it make more sense to simply add this into CORS? The long term plan is to have a "Fetching URLs" specifications (or maybe just "Fetch") that includes "fetch" as defined in HTML, CORS, and presumably this specification depending on whether it gets traction. For now however it seems better to wait and see how each of them does on its own. -- Anne van Kesteren http://annevankesteren.nl/
Re: From-Origin FPWD
It seems to me like this feature heavily overlaps with CORS. In fact, it addresses the exact same cases, except that it does it for resources which we for various reasons use allow-embedding-but-not-reading cross site. Would it make more sense to simply add this into CORS? / Jonas On Fri, Jul 22, 2011 at 8:08 AM, Anne van Kesteren wrote: > 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/ > >
Re: From-Origin FPWD
I recommend reading the relevant Internet-Draft: http://tools.ietf.org/html/draft-gondrom-frame-options-01 The draft formalizeds X-Frame-Options as Frame-Options. The issue is on the side of the headers' technical design. Regards, -- Thomas Roessler, W3C(@roessler) On Jul 22, 2011, at 17:52 , J Ross Nicoll wrote: > In my opinion, we should not be supporting X-* headers any more than > absolutely necessary, so phasing out X-Frame-Options in preference of > From-Origin would be the correct way to go. I'm aware this does mean a > cross-over period where servers are likely to have to provide both > headers, and it might be worth specifying what is expected if both are > present and conflict (use From-Origin in preference to X-Frame-Options, > perhaps). > > Ross > > On 22/07/2011 16:08, "Anne van Kesteren" wrote: > >> 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/ >> > > > >
Re: From-Origin FPWD
In my opinion, we should not be supporting X-* headers any more than absolutely necessary, so phasing out X-Frame-Options in preference of From-Origin would be the correct way to go. I'm aware this does mean a cross-over period where servers are likely to have to provide both headers, and it might be worth specifying what is expected if both are present and conflict (use From-Origin in preference to X-Frame-Options, perhaps). Ross On 22/07/2011 16:08, "Anne van Kesteren" wrote: >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/ >
Re: From-Origin FPWD
The web...@ietf.org mailing list would probably be an appropriate place for discussion about x-frame-options. (It's right now an individual internet draft.) -- Thomas Roessler, W3C(@roessler) On Jul 22, 2011, at 17:43 , Arthur Barstow wrote: > On 7/22/11 11:08 AM, ext Anne van Kesteren wrote: >> 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. > > Anne - what list is X-Frame-Options being discussed? > >
Re: From-Origin FPWD
On 7/22/11 11:08 AM, ext Anne van Kesteren wrote: 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. Anne - what list is X-Frame-Options being discussed?
