Re: Constraints 2014

(No argument with the rest of it.  However...)

On 23 March 2014 14:52, Jim Barnett <1jhbarnett@gmail.com> wrote:
> The lengthiest dispute/discussion was over whether the application should be
> notified which mandatory constraints failed.  Some people felt this made
> fingerprinting too easy, others felt that information was important for
> intelligent applications.   The latter group has prevailed.

I have no idea about what is the prevailing attitude here.  However, I
will observe that if we permit the use of immediate errors that
include information on what mandatory constraints could not be met,
then the difference between that and a complete enumeration of device
capabilities is effectively nil [1].

If we do provide an error indication like this, then I will - again -
repeat that we should instead be enumerating device capabilities
completely.  That enumeration should expose capabilities as affected
by other users of the system.  (For the fingerprinting averse, this
means that you get to learn about some combination of the system, and
the other users of the system, probably both over time.)

[1] If you are clever, you can almost protect a single capability by
ordering enforcement, forcing the app to risk asking the user to probe
its state, though that's also trivial to avoid.  For instance, if you
a protecting resolution by enforcing its constrain last, the app can
ask for something implausibly large.  This allows it to safely probe
all other capabilities.  Then, if the app is willing to take the
chance that the browser asks the user, it can reduce resolution one
pixel at a time until the user prompt appears, thus revealing
resolution capabilities precisely.  Protecting an unordered capability
with many states could reduce the chance that the app successfully
probes its state without triggering a user prompt.

Received on Monday, 24 March 2014 00:27:58 UTC