- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 13 May 2013 15:21:47 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>, public-webapps <public-webapps@w3.org>
On Mon, May 13, 2013 at 2:28 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, May 13, 2013 at 10:57 AM, Hallvord Reiar Michaelsen Steen > <hallvord@opera.com> wrote: >> Does anyone have real, non-contrived use cases for the anonymous flag? > > The basic idea was preventing confused deputy attacks by not exposing > any information that could be used as such. So no credentials and no > data about where the request originated from, forcing the architecture > to be token-based effectively. I still think that makes some amount of > sense, but if nobody is keen on implementing that we should indeed > just drop it. Not sending credentials ever however still seems like > something worth preserving (Fetch has a credentials mode for this as > well). I think the strongest use-case that I've been able to think of is to enable a website to take a URL from an untrusted source and then interact with that URL over HTTP. By removing both user credentials and website credentials the website doesn't have to worry about confused-deputy problems. I.e. if website A gets a URL from untrusted source B, A can then interact with that URL without having to worry about that the server that it's interacting with will think "oh, this request is coming from A, it's fine to trust it then". I.e. it doesn't have to worry about B tricking it into taking actions which A has access to, but that B doesn't. This doesn't need to be obviously harmful "permanently delete files" types of actions. For those A would likely need to include some form of credentials anyway since any server-to-server communication can claim to be from A using origin/referer headers. It can also be simpler things like throttling bandwidth if it's getting too many requests from a particular source. / Jonas
Received on Monday, 13 May 2013 22:22:44 UTC