Den 16. mai 2013 kl. 18:45 skrev Anne van Kesteren <[email protected]>:
> On Tue, May 14, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen > <[email protected]> wrote: >> Say, for example, OpenID is a setup where the user might provide an >> "untrusted" URL to a third-party web site ("Here's the service that can >> authenticate me"), and XHR might be involved - but the Open ID *provider* >> would of course want to know what site it is interacting with, to present >> some information about what authenticating means to the user.. > > Why? That information could be in the resource. Well.. Open ID already has a real risk of being abused for phishing and fraud (how many regular users can *really* verify that the site took you to the right provider? Or that the provider has a real understanding of which service it will log you in to?) OpenID providers probably need non-spoofable origin indicators more than most sites. > Or if you e.g. > implement your own browser-like thing that accepts arbitrary URLs you > would want something similar. Sounds like a pretty esoteric use case.. And really, if I wrote a "browser-like" web app - fetching random URLs by XHR (would be an odd browser that could only "surf" CORS-enabled sites!), you have it exactly backwards: I would want to set withCredentials to true to please all those sites that require cookies and show an error message without. (Screen scraping scripts w/o cookie support are not as capable as those with - trust me!) The anonymous mode would not IMO meet any real requirements presented by this use case. Also, if I, having written this "browser" found that site Y sends more content to my "browser" than to some other browser because it somehow has put special trust in my domain - is that a feature or a bug? It might be a case of site Y kindly adapting their content for my "browser"? Should I hard-code anonymous mode for requests to site Y to make sure it can not do so? > You might also want to do same-origin requests that do not include the > overhead of Cookie / Origin / Referrer headers. HTML already has > rel=noreferrer for that. As far as I can tell, this is not equivalent. There is nothing in HTML5 that forbids sending cookies to the target site of a noreferrer link, and use case "follow a link, let target know or not where the link was" is even conceptually different from "fetch inline resource, and let backend know (or not) what origin the page requesting the resource has". > We should expose functionality like that in > the low-level API. To do so, we can allow setting Referer header to null or the empty string with setRequestHeader. That would be the noreferrer equivalent. Anonymous mode still seems like useless complexity to me, so I'm still in favour of dropping it. Hallvord
