See also: IRC log
<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
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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/proposal/idea/ Succeeded: s/a/an/ Succeeded: s/npdoty_// Succeeded: s/bluetooth metadata/bluetooth capabilities and kinds/ Succeeded: s/for how long would the request last?/time lapse by which the server plans to abide by these policies/ Succeeded: s/incentive/invasive/ Succeeded: s/YYY/Shijun Sun/ Found Scribe: tobie Found ScribeNick: tobie Present: Anssi_Kostiainen npdoty Tobie_Langel dsinger Agenda: https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Device_APIs_and_Privacy.2FPermissions Got date from IRC log name: 28 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/28-web-bluetooth-minutes.html People with action items:[End of scribe.perl diagnostic output]