Re: [vibration] privacy consideration PING comments

Hello

2016-02-29 22:26 GMT+01:00 David (Standards) Singer <singer@apple.com>:

> I have generally understood ‘fingerprinting’ as meaning *reading* a set of
> the device (or user) that uniquely identifies it (sure, using active APIs
> sometimes to gather the data).  I don’t see how a vibration API tells you
> anything about the device (except maybe the 1-bit “can it vibrate?”).
>

That's exactly my point, which is already addressed in the considerations
(that I had the pleasure to co-write). Vibration provides *input* for other
sensors, it allows to "probe" them.


>
> So, is this API a fingerprint risk, or a beacon risk?
>

It provides information - which, in conjunction with other sensors, is a
risk.

There will be a more comprehensive document here, soon.

Best
Lukasz

>
> > On Feb 27, 2016, at 10:43 , Lukasz Olejnik (W3C) <lukasz.w3c@gmail.com>
> wrote:
> >
> >
> >
> >
> >
> >
> >
> > 6. Applications might want to give indications when vibration is in use.
> >
> > Definitely, there SHOULD be an option to indicate it...
> >
> > I don't think that's right. There is an indication that vibration is in
> use: the device is *moving*.
> >
> > It is, if the user is monitoring this device at that very moment, and
> also including your considerations below (thanks!).
> >
> >
> > So there are a couple of more interesting things:
> >
> > When a foregrounded page has permission for vibration, there should be
> an indicator. The same applies to a backgrounded page - I think something
> like the audio playing thing that browsers have started doing would be
> useful. Indeed, it would copy a familiar iconic paradigm from the world of
> phones which have had vibrators for more than two decades (and therefore is
> unlikely to have any IPR issues outstanding).
> >
> > There are plenty of use cases for a backgrounded page having vibrate
> permission - the simple one being the same as the phone, that it is less
> obtrusive as a way of requesting attention, and works without actually
> seeing the device.
> >
> > And finally, of course it is important that all such notifications or
> status indicators are actually *accessible* - have sufficient contrast, are
> announced to screen readers / magnifiers, etc. While this is something that
> browsers should be doing, rather than technically part of the spec, it is
> worth noting that in the privacy considerations and mitigations, and
> tracking whether we have acieved the goal. A spec that provides theoretical
> accessibility but is implemented consistently in a way that discriminates
> against users with disabilities really isn't good enough.
> >
> > This is, in essence, somewhat similar to what I was thinking about for
> long now. I do hope to make the PDF public asap, definitely I'll post it to
> the list.
> >
> > Best
> > Lukasz
> >
> >
> > cheers
> >
> > Chaals
> >
> >
> >
> > --
> > Charles McCathie Nevile - web standards - CTO Office, Yandex
> >  chaals@yandex-team.ru - - - Find more at http://yandex.com
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>