Re: User confirmation and 307 redirects

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.

And, yes, an automobile navigation system that stupidly depends
on redirects (as opposed to DNS or IP redirection that doesn't
require the body of the message to be sent twice) can easily be
preconfigured to allow automatic redirects to known safe sites.
The "user" is the person that causes the request to be initiated,
which in your scenario is the navigation system's programmer,
not the driver.

....Roy

Received on Thursday, 19 August 2010 23:21:52 UTC