[User Context] architectural comments on latest editor's draft

These comments are not necessarily "first public working draft" material -
editor's discretion should be applied.

In the privacy model, clarify that when a query results in a prompt and null
or the default value is returned, a callback is only invoked if (1) the user
allows the setting to be shared and (2) the setting has a value other than the
default. The "permission denied" and "setting left at default value" cases are
indistinguishable to the script.

I think this is implicit already, but it should be stated precisely. We don't
want callbacks executed when the user allows sharing and the setting is at its
default, since this leaks the fact that the user was prompted (as opposed to
having changed the setting), and may reveal something of the user's
privacy-related behaviour.

Consider replacing the "userScreenReaderSettings" category with a wider
"userATSettings" category, if the proposed "AT-enabled" setting is included in
the spec. This setting has been proposed in several meetings, and this entire
category remains the subject of working group discussion.

Under "Example Restriction UI", update the log messages to be more accurate.
As the example now stands, we aren't querying for audio descriptions, and the
else branch is taken if either the user has elected not to share the screen
reader setting, or no screen reader is active.

Under "User Agent Requirements for Restricted User Settings":
The earlier text suggests that whether a prompt, or prompt with justification,
is required depends on the category to which the setting belongs. In this
section, however, it is assumed that the user can decide whether prompting is
needed for a specific setting, and if it is, whether a justification is
required. For example:
"If the user has a general 'prompt' restriction enabled for the requested
setting".

If the intention here is to allow the level of prompting required in each
category to be configurable, this should be clarified, and we need to decide
whether this type of flexibility is desirable. At the moment, I'm simply
noting that the privacy model isn't consistent on this point, as the draft now
stands, unless I'm misreading it. Of course, the degree of configurability
could be left to implementations, but the text still needs to be clear and
consistent.

We should also decide under what conditions the user is prompted, e.g., a
script queries a restricted setting and at least one setting in the associated
category has a non-default value. Users who haven't changed their media
settings, for example, or who aren't using screen readers, shouldn't even be
prompted. If they are prompted, then I predict a barrier to adoption (no one
wants unnecessary browser dialogues).

"Example restricted call to window.userSettings()":
I suggest revising the comments in the example. If the else branch is taken,
this might be due to the user's denying permission to access
"audio-description". If the author now provides a control in the custom media
player to enable the audio description track, the user's privacy is breached,
as the value of this widget is accessible via scripting. The only way to
preserve the user's privacy is to provide timed text or an audio description
track in the video and let the user agent determine whether to render it.
Otherwise, there's no longer any point in imposing a privacy restriction on
the setting.

General comment: the draft states in several places that prompting SHOULD be
implemented. Inevitably, the question will be asked whether this ought to be
"MUST" instead. I'm not arguing for either alternative here, but we need a
persuasive rationale, whatever the decision.

Received on Saturday, 17 May 2014 06:09:21 UTC