Re: User confirmation and 307 redirects

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

Received on Friday, 20 August 2010 00:23:52 UTC