extensions in Determining User Preference

Hi Roy,

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. 

For the common case, where an extension makes a request via JavaScript XHR 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. 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. 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.

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. In short, I think we can drop this new requirement from the section.

Thanks,
Nick