Device APIs and Privacy/Permissions -- 28 Oct 2015

<anssik> scribe: tobie

<anssik> ScribeNick: tobie

jyasskin: explore what's difficult about device APIs,
... why permissions are hard,

dsinger: I have a idea

<mishizaw> mishizaw hans joined #web-bluetooth

aalfar: security too?

jyasskin: list of scary APIs:
... Bluetooth
... NFC
... USB
... GPIO
... I2C
... Automotive
... Actuators
... Battery
... Camera/Mic
... Ambient Light
... mDNS
... Screencapture
... Health
... * fingerprinting
... one way of mitigating the problem, only expose part of the API
... we don't know the permission story for scanning, acting as a server, doing that in the background, BT classic protocol, etc.
... for NFC: just the foreground use case. (Page visibility).
... there's useful things beyond that but permissioning story hard.

anssik: drag and drop is a nice example: parts the user understand (eg the picture)
... part the user doesn't: the metadata

jyasskin: security issue too, as there's no origin model for things like bluetooth
... FIDO is looking into that?

<npdoty_> FIDO requires knowing the origin, because it expects devices to return different values based on the origin

Claes: are you considering stornger security models beyond permission/https?

jyasskin: how would we do that?
... are you suggesting the device would be aware of certain origins it wants to talk to?

<dom> [a survey of various permission models used in current Web APIs I conducted 18 months ago http://dontcallmedom.github.io/web-permissions-req/matrix.html ]

jyasskin: we talked about a CSP-based solution but that kind of fell off the radar

dom: limitation of CSP: since it can be put in the markup, if there's an XSS then there are issues.

jyasskin: there feedback on this in Media Capture
... you can require certain CSP constraints (e.g. not in page)

<Zakim> npdoty_, you wanted to comment on how NFC clarifies what you're doing

npdoty_: how can you explain this to the user?
... is great because there's physical movements involved
... are there other similar solutions like this?

anssi: goes back to my previous drag and drop example

jyasskin: nextstep ability, upgrade from NFC to bluetooth. How do we explain that upgrade?

dsinger: have you used the app bump?

jyasskin: with NFC's security model you know which device you're giving access to, but you don't know their capabilities.

npdoty_: we should be thinking about that in terms of multiple steps.

anssik: I like that, who and what.
... who am I talking with, what am I transferring?

jyasskin: what is the most important + the most difficult bit
... with bluetooth, the browser doesn't know what's being transferred

npdoty_: is there metadata around bluetooth capabilities and kinds?

<jyasskin> https://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx

<jyasskin> Standardized protocols ^

jyasskin: in general no, there are some standards around keyboards in the list above.

npdoty_: usability issue in BT

<npdoty_> opaque names are a problem with BT pairing already, just with native OS

jyasskin: we'd like to build a registry of bluetooth identifiers to user-readable names

<npdoty_> makes it hard to know which device you're actually connecting, as well as what it's going to do

jyasskin: this has issues too, obviously, eg: innocuous name

<npdoty_> wow, this is a crazy list, including "Continuous Glucose Monitoring" and "Next DST Change Service"

Claes: xxx

<dom> dom: can you use this bluetooth connection to break the same origin policy?

dom: e.g bluetooth device fetching data over http breaks SOP

jyasskin: even if you blacklist this, you can still get device that do it in non-standard way.
... at some point we can't prevent users from shooting themselves in the foot

npdoty_: fringerprinting users using bluetooth ID

jyasskin: we're not exposing standard ID, but won't block non standard ones

<npdoty_> jyasskin: we can blacklist the standard device identifier fields

Health Data Idea

dsinger: what's my reaction to health data sensor?
... usual model is we ask the user
... problem: the list is huge
... the user isn't aware of the data policy.
... idea: a digital file on the server that has these three data points:

1. which health sensors would be required

2. which policies the website would abide by?

3. time lapse by which the server plans to abide by these policies

Makes it possible to turn privacy violation into promise violation.

jyasskin: seems related to p3p

dsinger: basic idea is you can avoid asking the user in most cases.

<npdoty_> dsinger: provide URLs, rather than full machine-readable policies (a la P3P)

<Claes> My questions was that if the IPv6 profile (IPSP) is used then the device is an IPv6 device, standard protocols and security mechanisms could be used and the resources of the device could be exposed through an internal web server, i.e. no specific Web Bluetooth API would be needed? Jeffrey answered that this could be done for new devices but for existing devices not running IPSP this API is needed.

<dom> Privacy Rulesets editors draft, back from 2010

dsinger: current model by which we get user consent is broken, we ask them at the worst possible moment.
... UA will need to cache this data + enforce it.

dom: developers want a way to express what they need the data for, but UA don;t won't devs to meesage withing trusted chrome.
... so it seems this would somehow solve this.

jyasskin: plan for bluetooth follows extensible manifesto
... first low level, then use that to create higher-level APIs such as health

<npdoty_> tobie: similar to sensors that we distinguish between high-level and low-level

<npdoty_> ... incentives for developers to use higher-level sensors unless they really really need access to the low-level

<npdoty_> ... gyroscope more invasive than just the step count

<npdoty_> anssik: data minimization, the least information that gets the job done

<npdoty_> dsinger: similarly, better to ask for permission about the type of data, rather than the particular mechanism. like "location" rather than "GPS"

jyasskin: bluetooth prompt is going to be quite invasive
... you get two prompts
... we have to find a different story for innocuous bluetooth devices (e.g. toys in happy meals).

<npdoty_> I wonder if it's possible for a bluetooth device to certify that it is "innocuous"

dom: broader question: ongoing conversation over the years, how do we solve this in a more general way?

<npdoty_> "I am a toy, with no high-granularity sensors or unique identifiers. Anyone can access me, without destruction of property or privacy invasion."

jyasskin: we want to ship something and use this to inform design

<dom> when you say "certify", do you mean with guarantees that it doesn't lie?

<dom> ^npdoty

<npdoty_> dom, I actually think it could partly be purely self-certified. if it turns out you're wrong and someone destroys your customer's device, well, it was your fault. (maybe privacy is harder.)

jyasskin: we're shipping this using XXX

<dom> but the bluetooth device could be part of the attack; e.g. "I'm an innocuous toy, but in fact am collecting geolocation data and sending it to my owner"

<npdoty_> dom, yeah, it makes more sense for the actuator/device-destruction problem

Shijun Sun: general pattern for permission, as you need that for certain cases (e.g. notification, push, etc.)

anssik: implementations could improve permission revoking
... it should be as easy to revoke permission as it is to grant them

jyasskin: the default for new permissions is secure origin

- DRAFT -

Device APIs and Privacy/Permissions

28 Oct 2015

Attendees

Contents

Health Data Idea

Summary of Action Items

Scribe.perl diagnostic output