Re: ACTION-43: added user-agent-managed site-specific exception proposal to Editor's Draft

On Jan 6, 2012, at 4:54 PM, Sid Stamm wrote:
> Here are some comments I've got after taking a first cursory look at the addition.

This is all good feedback, thanks for writing these up. Initial responses below.

> 5.7.3.2: "User agents MUST provide a user interface prompting the user to choose whether to provide site-specific exceptions to Do Not Track for the requested origins, or, if pre-configured to accept or reject these permissions, respond with the user’s previously configured preference."
> -> This sounds like "User agents MUST do X, or not."  This is weak and doesn't seem to be normative as intended.  I think this would be better as "User agents SHOULD do X, or Y, or something equivalent."  Getting too detailed here is at risk of violating "Questions of user interface specifics — for granting, configuring, storing, syncing and revoking exceptions — are left open to implementers" in the first part of the section.

I don't think there's anything wrong in general with writing "User agents MUST do X or Y" but maybe this language is unclear. One advantage of having normative text requiring user interaction in some cases would be to guarantee to sites that this mechanism can be used to facilitate negotiation with the user (so that they don't need to do it themselves).

What would you suggest specifically to replace this text? One possibility:
"If a user has pre-configured the user agent to accept or reject these permissions, the user agent SHOULD respond with that preference. If no pre-configured preference exists, the user agent MUST provide a user interface prompting the user to choose whether to provide site-specific permissions for the requested origins."

> 5.7.3.2: "a third party may query this property to determine whether Do Not Track applies to its domain." It isn't clear how the third party realizes they're a third party.  Should they know?  This is precisely the conflict between HTTP-request based context and JS-runtime context.

It's true that it might not be the case that every piece of third party JavaScript will know definitively that it's running in a third party context. (That being said, window.location makes it pretty easy for a piece of JavaScript to know if it really wants to, right?) This functionality is here just as a suggestion, in any case.

> 5.7.3.3: "The user agent MUST store granted site-specific exceptions in the form of a pair (document origin of the top-level document, site-specific-exception document-origin)." This violates the top part that says storage design is up to the UA.  We could define what the exception is (first+third party origins) and say the UA MUST store both or neither, but saying in what form they must be stored is thorny.

Good point. The spec ought to specify normatively what the exception is, but doesn't need to specify the storage form; I thought "store" still left the user agent flexibility on the implementation, but I'd be open to suggestions here. Do you have an alternate text form to replace this sentence with? Is the concern that storage is required at all? I think some storage is necessary for this to make sense -- an exception can only be applied to future requests, an exception that is never stored is no exception at all in this scheme.

> I'm still reading through, so I might follow up with a few more thoughts.

Thanks, please keep them coming.
Nick

Received on Saturday, 7 January 2012 01:56:39 UTC