Re: Constraints 2014

+1

For what it's worth, I agree with Martin that developers should be able 
to enumerate device capabilities instead of jumping through all these 
silly hoops. This will result in a much cleaner API.

Gili

On 23/03/2014 8:27 PM, Martin Thomson wrote:
> (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 15:42:29 UTC