Re: extensions in Determining User Preference

Hi Roy

something I am not clear about — was this introduction of a ‘must’ the consequence of a decision we needed to implement, or something you noticed and believed needed fixing?

If it’s the former, could you identify the decision?  I think that if it’s the latter, we’re at the stage where we need to say “there is an issue here” and let the group and chairs decide whether to make a technical change, rather than just making it.

(I’m still pondering the merits of the change itself, and I think we may well need to discuss it.)


On Apr 2, 2014, at 14:22 , Roy T. Fielding <fielding@gbiv.com> wrote:

> On Apr 1, 2014, at 11:07 PM, Nicholas Doty wrote:
> 
>> I appreciate your cleanup of the Determining User Preference section; as you noted, the text (added to multiple times over a long period) could really use it. I don't understand the addition of this requirement text though:
>> 
>>> A user agent that allows extensions to directly make or modify HTTP requests MUST provide a corresponding API to those extensions for determining the user's tracking preference. 
> 
> It is derived from the section on plug-in APIs that I merged into this one.
> 
>> For the common case, where an extension makes a request via JavaScript XHR
> 
> XHR is not what I meant by directly making a request.
> 
>> or some other means, I'm not sure why it would be important to have an additional API for the extension to know before it loads whatever resource what the user's tracking preference will be for that request.
> 
> It is necessary in order for the extension to include the right DNT field
> in the request.  Many extensions are included with user agents, so
> from the user's perspective they are part of the browser; we know
> from experience that user's don't want extensions to ignore the privacy
> settings in their browser config.
> 
>> And where a custom plugin embedded in the browser creates HTTP requests "from scratch" (that is, without using browser-provided APIs, which is maybe what you meant by "directly"?), then the browser has no involvement in or awareness of the request at all.
> 
> That isn't true. The browser invoked the plug-in and is capable of providing
> that plug-in with an API for the privacy config.  The alternatives would be
> to create a separate implementation within every plug-in, each with
> its own list of exceptions, or to not implement TPE at all for plug-ins.
> 
>> While it might be convenient for browsers to work with proprietary plugins that are going to roll their own HTTP requests so the user gets a consistent choice even when using Flash or whichever other plugin, I don't see how this is an interoperability requirement. The text refers to a user agent "that allows extensions to directly make" requests, but when they're made directly, the UA isn't allowing anything, plugins are running code through the OS.
> 
> Same thing.
> 
>> As you note, every user agent would likely handle this differently, and while when we discussed it in the past that it might be convenient for browsers to expose DNT status to plugins in case they want to behave differently under DNT, I thought we'd decided not to add that to the spec.
> 
> We agreed not to define a single API.  That doesn't mean the protocol works
> for extensions without having some means to query the config.
> 
>> In short, I think we can drop this new requirement from the section.
> 
> 
> I don't agree, though I support you making it an objection and calling for a
> more formal decision.
> 
> Cheers,
> 
> ....Roy
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 8 April 2014 15:31:55 UTC