– DRAFT –
Device APIs

Agenda bashing

<scheib> Ansii: Device WG is re-chartering soon

<scheib> anssik: Looking for signals for evolving the charter

dom: permissions and user consent relationship to this group

vincent: interest to gather implementers interest outside Chromium

<Yam_ACCESS> Toshihiko Yamakami, ACCESS, a browser vendor, but I have almost no knowledge about device API, sorry.

Vincent: Pattrick Kettner from Microsoft working on a polyfill implementation for Edge
… Web Bluetooth on top of WinRT specifically
… notably not part of the Edge implementation

unknown: Microsoft has some concerns about security model of Web Bluetooth

Vincent: I've been in contact with partners, e.g. there's a product called Pocket Lab
… goal to have devices that can be used throughout the year to address physics and math learning opportunities
… have been successfully using Web Bluetooth API for Chrome OS, Android, macOS
… native app for iOS and Windows with a plan to deprecate as soon as possible due to development cost
… also web dev model preferred
… another product, Puck.js, for the makers market
… have shipped ~10K devices to date
… programmable, run JS on device, interface over WebBT
… have implemented their own browser in iOS, injected WebBT implementation
… we are measuring usage of the Web Bluetooth API, roughly several 100s of individual opt in every week
… Web USB is coming along, a bit lower usage
… another real-world usage is in drones that are interfaced with over WebBT
… WebUSB is utilized to flash Android devices
… this is under active development
… utilization by 3rd party for CPR training
… both WebUSB and WebBluetooth provide security advantage due to lower exposure
… under the Web model, I grant access to a single device, can revoke the access and no residual access possibility remains
… drastically stricter security model compared to native

unknown: there's the web sandbox, and this is adding capabilities to that sandbox
… generally thinking about web security, do not provide access to content process
… installed app could be a PWA, we're watching
… any comments from Apple?

dydz: wondering about use cases?

<darktears> anssik, dydz ^^

dydz: what are the problems that WebBT is trying to solve? Can we reframe the problem somehow?

reillyg: the tradeoff between gaving capabilities to web sandbox

<tomayac> Puck.js: https://‌www.espruino.com/‌Puck.js+Web+Bluetooth

reillyg: people are just going to buy these devices
… we can take advantage of the superior security model, if developers build web apps versus native apps
… we require appropriate user concern
… re use cases, we have a number of device APIs on the Web platform, for camera etc.
… we're enabling people to develop apps for small use cases

dydz: can't we solve this using browser extensions?

reillyg: question of tradeoff, forcing extensions path puts us in same position as with native apps
… we're removing extensions, since the extensions make the browsers worse

anssik: no interop for extensions

<tomayac> WebExtensions run on Android Firefox

shwetank: no extensions for mobile browsers in general

dydz: this increases fingerprintable surface area
… concern we are building an OS platform on the Web
… re WebBT, how to ensure the API does not increase fingerprintability, so that people can not scan your devices
… how to mitigate the fingerprinting the risk of such APIs

Vincent: WebBT and WebUSB do not expose any information prior to user's explicit consent
… similarly to filesystem access
… do not increase any fingerprintable surface area
… currently some of sensors exposed through deviceorientationevent are being redesigned to provide enhanced privacy protection

<xfq_> Generic Sensors API: https://‌w3c.github.io/‌sensors/

Vincent: for some generic sensor-based concrete sensors, Chrome expose low fidelity of sensor data to not need to prompt the user while also protect users' privacy
… for high fidelity, can fall back to explicit user consent
… TAG has published a note re fingerprinting

dydz: Safari's deviceorientationevent should be restricted to the top-level frame, but not sure
… not familiar with WebRTC model, how it addresses privacy issues
… camera data is scoped to <input type=file> access

anssik: would you be more comfortable if WebBT would reused <input type=file> as its user-facing UI

Daniel(Apple): we have couple of users to ask user for permission
… Geolocation we reprompt every 24 hours
… we want to create right UX for each of these powerful features
… want to get better sense of developer use cases, problems that are being solved
… we want to understand the use cases better

Vincent: philosophy, we provided content to be rendered on the Web using canvas 2D, WebBT and WebUSB are well-adapted industry standards, we want to leverage these standards rather than create application-specific APIs, e.g. solution that'd be FitBit-specific
… out sensors are used in industrial, medical areas, sensors that are just transmissing data
… arduino community is huge, many of these could be programmed over WebUSB for education purposes which is a significant market
… convenience to go to a web page, use it as your IDE is a powerful too for programmable devices
… other usages: 3D printing, go to a web site print directly to your 3D printer, nicer out-of-box experience for toys
… in general lower the startup cost of development

<scheib> anssik: Essentially, the long tail

<scheib> ... Wrapping that up let's transition to discussing future of the device group

<scheib> ... Considering taking on geolocation API on

<scheib> ... no longer being maintained elsewhere

<scheib> ... can upgrade the API to be more contemporary

<scheib> ... also considering taking on Web Bluetooth, but seeking support from the community

<scheib> ... heard that several are monitoring progress

<scheib> ... apple has raised some concerns, specifically wanting to know the desired use cases

<scheib> ... Specifically re Geolocation, any thoughts? None, seems clear to move forward

<scheib> ... Web Bluetooth, anyone who believes we should wait and keep the specification in incubation longer?

https://‌github.com/‌w3c/‌dap-charter/

<scheib> ... several issues open on github discussing charter

https://‌github.com/‌w3c/‌dap-charter/‌issues

<scheib> ... please contribute thoughts there

https://‌w3c.github.io/‌dap-charter/‌DeviceAPICharter.html

anssik: Device and Sensors WG is rechartering for 2018
… now is the time to submit your feedback, please use GH issues for that

<larsgk> hi

<larsgk> anssik: hi