Re: issues and questions in the latest TPE draft

It seems to me that there is certain information that is best provided
by the site, but other information that the UA is in the best position
to present.

For example, it makes sense to let the site explain to the user why it
thinks the user should grant an exception.

But I think there is a good argument for having the UA be the one that
tells the user which domain is asking for the exception and exactly
what exception the user would be granting.   The standard security
model on the web is that sites are not trusted to identify themselves
to the user.   Instead, the UA tells the user which site it is
interacting with.   (Legitimate sites don't try to mislead users about
who they are; but bad actors can and do mislead users, with bad
effect.  UAs try to prevent this by keeping the user informed about
sites' identities.)

The UA is the entity that is best positioned to know what the user
would be consenting to. For example, if the UA chooses to convert a
narrower request to a site-wide exception request, the UA will know
that this is happening but the site probably won't know--which means
that the site's explanation of what the user is being asked to accept
will not be accurate (through no fault of the site).

What this suggests is an approach in which the site makes its pitch to
the user in any (non-deceptive) way it wants, then the UA triggers
some kind of confirmation/choice UI through which the user can choose
to grant the exception.

In the spirit of not overspecifying UI details, I don't think we need
to say that it must happen this way.   But I think the text should
allow the approach I described--which would seem to rule out any flat
statement that the user experience for exceptions is entirely the job
of the site or entirely the job of the UA.

On Wed, Aug 29, 2012 at 9:15 AM, David Wainberg
<david@networkadvertising.org> wrote:
>
> On 8/29/12 1:12 AM, Nicholas Doty wrote:
>
> On Aug 22, 2012, at 12:15 PM, David Singer <singer@apple.com> wrote:
>
> Finally, section 6.7 includes non-normative language that states that UA's
> may implement exception management as they see fit, and gives an example of
> a UA prompt to allow a requested exception. Although this is non-normative,
> I have concerns about the impact. In my view, the requesting party (i.e. the
> publisher) should control the messaging of the request, and the UA should
> provide only a simple yes/no confirmation. The example given will create a
> terrible user experience, as the user will be presented with multiple and
> possible conflicting explanations of the request. Let's not encourage this.
> Canit we please remove it?
>
> I agree with you on the model of the exceptions -- that the site's pages
> should explain what's going on, and that the API call and resulting UI
> should be a confirmation.  I wonder if, if that is the case, we need all the
> explanatory parameters to the API, and I agree that re-writing 6.7 in the
> light of that model would be good.
>
>
> It sounds like the concern is over the possibility of having a UI that uses
> an explanatory string or a "more info" URI rather than just having a
> non-normative example at all.
>
> Are there cases where the user sees conflicting explanations of the request?
> I guess a truly confusing site could provide contradictory statements in its
> HTML content before the JS call and the optional explanationString parameter
> (or the detailURI), but our APIs certainly won't prevent sites from choosing
> to be confusing and sites that don't wish to use the string parameter can
> simply not use it. The suggestion in January was that a browser could have a
> good incentive to present this to the user and that optional parameters (and
> no UI requirements) could provide variety among vendors.
>
> My understanding is that in this thread [0] Jonathan, Shane and Sid
> ultimately agreed on this approach, and it's been supported in each
> re-drafting since.
>
> [0] http://lists.w3.org/Archives/Public/public-tracking/2012Jan/0321.html
>
> The issue is not conflict between two contradictory UI's or messaging
> presented by the site, but conflict (or redundancy) between the UI and
> message presented by the site vs a UI and message presented by the UA. I
> think there is consensus that the site should control the message around the
> exception request, yes? Assuming that's true, UA's should not be encouraged
> to also provide a UI, which is, I think, what the example does.
>
>
>
>

Received on Wednesday, 29 August 2012 14:18:11 UTC