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: rocallahan@gmail.com [mailto:rocallahan@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 <bhill@paypal-inc.com<mailto:bhill@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]