W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: User confirmation and 307 redirects [#238]

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 20 Aug 2010 11:28:11 +1000
Cc: Dirk Pranke <dpranke@chromium.org>, Adam Barth <ietf@adambarth.com>, Mark Pauley <mpauley@apple.com>, Julian Reschke <julian.reschke@gmx.de>, httpbis <ietf-http-wg@w3.org>, Maciej Stachowiak <mjs@apple.com>
Message-Id: <2AC73E5D-CF70-4CAB-8AB3-AC143A48ED30@mnot.net>
To: Roy T. Fielding <fielding@gbiv.com>
So, keeping this discussion in mind, some might interpret all of the following as conforming to the requirement:

* Any software that uses Curl with the --location option (or the corresponding libcurl arguments)

* A browser which allows the user to configure a 'redirect whitelist'

* A browser which follows all redirects (regardless of method), but has a 'redirect blacklist' for exceptions

* A browser that has a 'automatically follow all redirects to the same domain' preference box ticked

* A browser whose documentation says that it will automatically follow all redirects, regardless of method

Obviously, some of these are more useful for guarding against misuse than others.

I think at a minimum we need:

  1) An explanation of the risks of following redirects for non-GET methods
  2) Expansion on what "can be confirmed by the user" means

Also, it seems to me that it'd be useful to figure out what 'not automatically redirecting' means. The browsers, in their own way, have conformed to this requirement partially by converting unsafe requests into safe ones -- by changing the method to GET.


On 20/08/2010, at 10:23 AM, Roy T. Fielding wrote:

> On Aug 19, 2010, at 4:39 PM, Dirk Pranke wrote:
>> On Thu, Aug 19, 2010 at 4:21 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>>> On Aug 19, 2010, at 3:44 PM, Adam Barth wrote:
>>>> On Thu, Aug 19, 2010 at 3:37 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>>>>> On Aug 19, 2010, at 3:20 PM, Adam Barth wrote:
>>>>>> If you think that 307 redirects are a security vulnerability, then
>>>>>> should should remove them from the protocol.  Trying to atone for the
>>>>>> security sins of the protocol by punting security to the user is
>>>>>> security theater.
>>>>> Using the Internet is a security vulnerability, yet there are sufficient
>>>>> trade-offs to justify it.   The same goes for redirecting an unsafe
>>>>> method if and only if the redirection has been preconfigured or
>>>>> acknowledged by the user.  How that is arranged is not defined by
>>>>> the protocol -- it is left up to the user agent developer to decide
>>>>> on their own user interface *if* they want to autoredirect an unsafe
>>>>> method.
>>>> The draft says:
>>>> [[
>>>> Otherwise, the user agent MUST NOT automatically
>>>> redirect the request unless it can be confirmed by the user
>>>> ]]
>>>> If the user agent developer can choose whether or not to autoredirect
>>>> an unsafe method, in what sense is this requirement a MUST NOT?
>>> The user interface for obtaining confirmation is designed by the
>>> user agent developer.  The user agent developer can choose to never
>>> automatically redirect, provide some form of whitelist or zone
>>> functionality that preapproves such an automated redirect, or
>>> obtain a confirmation directly from the user upon receipt of
>>> the redirect -- any one of those satisfies the HTTP requirement.
>> If the user agent developer can choose to whitelist some redirects,
>> doesn't that directly contradict the text?
> No.  Whitelists are just a prearranged form of confirmation.
> In any case, we already discussed changing the text to be more
> clear, like the paragraph above; it should be somewhere
> in the list of editorial issues.
>> Also, suggesting that the "user" is the designer of the UI (or the
>> programmer), and not the viewer or the end-user, would seem to
>> contradict common usage in our specs.
> Then your specs assume that a viewer is driving the application of
> computing for which the specification exists.  HTTP doesn't.
> If I install a maintenance spider and it proceeds to crawl
> the Internet while I am off sleeping, then I am the user because
> I configured the crawl, not because I am viewing it in action.
> If I turn on a navigation system and it proceeds to perform a
> bunch of hidden requests in the background that I had no part
> in selecting, then I am most definitely not the user from the
> perspective of those requests.  If, however, it provides some
> UI for making such a decision, such as "Send traffic updates to X",
> then I am the user and the system is equally capable of
> explaining X in such a way that it is a group of potential sites
> (e.g., "send traffic updates to Google") rather than something
> else, like "send my location information to anyone in the world".
> ....Roy

Mark Nottingham     http://www.mnot.net/
Received on Friday, 20 August 2010 01:28:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:54 UTC