Re: extensions in Determining User Preference

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

Received on Wednesday, 2 April 2014 12:23:10 UTC