Re: Opt-back-in Information API (ACTION-94)

The API should allow the browser to determine whether the user has granted, or is willing to grant, the requested exception.  How it determines the answer should be up to the browser (overlay page, pop-up dialog, questions jn the 'chrome', looking at a database of granted exceptions, …)

On Jan 25, 2012, at 23:02 , Jonathan Mayer wrote:

> To clarify: my dashed off proposals were intended to specify possible APIs, not user interfaces.  The discussion is non-normative.
> 
> That said, we probably should go a bit further in specifying API requirements.  Some things we might consider:
> 
> -When can the API return true / when can the browser start sending DNT: 0?  Is explicit consent required?
> -When can the API return false?  Is a browser in compliance if it surreptitiously denies all exception requests?  What about just some requests (e.g. if the user just rejected this very request, and the site's being annoying)?
> -Is the callback guaranteed to run?  If so, is a browser-initiated timeout allowed?  What about a script-initiated timeout (e.g. a new optional parameter)?
> -In addition to exception accepted / rejected, should there be a third state for neither (e.g. user closed the notice, timeout, or anything other than accept/reject)?
> 
> On Jan 25, 2012, at 9:44 PM, Sid Stamm wrote:
> 
>> Shane, Johnathan,
>> 
>> Sorry I couldn't make it to Brussels with everyone, so I may be missing a little context here.  I'm assuming these proposals are for specification and not for non-normative examples in the document.  Please correct me if I'm wrong here!
>> 
>> Shane Wiley Wrote:
>>> Doesn't this promote a UI treatment to some degree?  
>> 
>> The proposal does indeed appear to limit the degree to which user agent software can communicate with our users.  Can we focus on specifying how web sites interact with the user agent (via API) and not on the actions the user agent takes?  For example, off the top of my head:
>> 
>> Rough Proposal:
>> 
>> "boolean requestSiteSpecificTrackingException(String domain,
>> [optional] String notificationText, [optional] moreURL)
>> 
>> "The requesting site calls this function to invoke the User 
>> Agent's exception granting mechanism (for examples of potential 
>> designs, see section #.#.#).  The notificationText is offered 
>> as a human-readable reason for the exception, and an optional 
>> moreURL for additional information provided by the entity 
>> requesting the exception."
>> 
>> Not the best words here, but hopefully my intention is clear.
>> 
>>> I believe our
>>> language was built to avoid the UI treatment and instead provide the
>>> raw elements to allow multiple UI treatments to occur (text + link).
>> 
>> I agree with Shane here.
>> 
>> -Sid
>> 
>>> I believe your proposal is asking instead of provide a top-line
>>> message to users with a link to more, you'd rather simply send the
>>> user to the "learn more" link.  I'd rather the two stage approach
>>> (even with suggested language to make sure we're not attempt to hide
>>> anything from users) but believe forcing them to the full page will
>>> be considered a negative outcome by many users (more "pop-up"
>>> windows with even greater text).
>>> 
>>> - Shane
>>> 
>>> -----Original Message-----
>>> From: Jonathan Mayer [mailto:jmayer@stanford.edu]
>>> Sent: Wednesday, January 25, 2012 4:59 PM
>>> To: public-tracking@w3.org (public-tracking@w3.org)
>>> Subject: Opt-back-in Information API (ACTION-94)
>>> 
>>> Proposal:
>>> 
>>> boolean requestSiteSpecificTrackingException(String domain,
>>> [optional] String notificationText, [optional] moreURL)
>>> 
>>> The browser prompts the user with text and a link to learn more about
>>> the opt-back-in request.
>>> 
>>> Alternative proposal:
>>> 
>>> boolean requestSiteSpecificTrackingException(String domain,
>>> [optional] String notificationURL)
>>> 
>>> The browser renders a page (e.g. in a floating div) that gives the
>>> user more information about the opt-back-in request.
>>> 
>>> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 26 January 2012 17:13:15 UTC