– DRAFT –
Devices and Sensors F2F Day 1 – 19 September 2019

Intros

anssik: Hello, I'm Anssi from Intel, co-chair of this group. I'm interested in getting a perspective from non-Chromium engines and the wider community.
… Chromium is the spearhead project driving a lot of this work.
… TPAC is an opportunity to get feedback from others.

flaki: Hi, I work from Mozilla, here as an observer. I don't represent Mozilla's official position.
… Those are represented by github.com/mozilla/standard-positions.
… I'm here because of my love for IoT.
… I'm interested in APIs that provide native parity. My favorite is Web Bluetooth.

Nikhil: I'm from Google and I work on TensorflowJS. I'm here because I'm interested, not representing Google's opinion.
… Would like to do processing of sensor data locally on device for privacy preservation.

Anssi: Have you been doing any on-client sensors work today with TensorFlowJS?

Nikhil: We use camera and audio, no work yet with motion. Something to look at for the future.
… Could be used for motion controls, accessibility.

flaki: Charlie Gerrard (@devdevcharlie), experimenting with motion controls and gesture detection.

Tom: I'm Chrome Developer Relations.
… These APIs aren't real APIs unless they land in other browsers so excited to see other vendors here even in an unofficial capacity.

<flaki> Charlie's talk mentioned: https://‌www.youtube.com/‌watch?v=HvtlRMpDbnQ

Tom: Excited by new use cases. Ambient light sensor. Geolocation. Orientation.

Riju: Involved from the start in Generic Sensors, working on shipping ALS and Proximity soon.

Anssi: What is blocking your work? What should be resolved in the wider community.

Riju: I would like other vendors to implement. Hoping to leverage new connections with privacy folks.

Anssi: We would like to hear from other vendors so we can solve technical issues.
… The generic sensors work started with a request from Mozilla.
… The original device orientation API provided a very minimal configuration surface, underspecified.
… AnneVK suggested we should do something better.

flaki: In general there is a lot of concern on Mozilla's side on allocation of resources for implementation as well as a concern for privacy.

Anssi: Recognizes that privacy is a focus of Mozilla and Apple's browsers. We have invited university researchers to present to us on privacy of this API.
… We want to break down privacy concerns into actionable items and make sure mitigations are in place.
… Riju and Reilly developed a technical measure against ALS-based attacks.

Riju: Yes, we added mitigation against using ALS to skim PIN codes being entered on the device.
… Readouts are limited to an accuracy of 50 lux. Output needs to vary by more than 25 lux before a new value is available.

flaki: It's always a fight between accuracy and use of the API.

Riju: Feedback from developers is that this mitigation doesn't prevent their use cases.

flaki: Use case for more raw data from folks who are trying to build their own sensor fusion, separated from other use cases.
… Hardware world is moving that processing into drivers and hardware.

<xfq> s/Scribe: Reilly//

Riju: For the new Generic Sensors API we have more configuration knobs so we can understand exactly what kind of capability the site really needs (high or low frequency, etc.)

Anssi: By definition low level APIs expose more granularity. There could be some innovation in how you acquire user consent. IF you get low level access there could be more user consent in place. For high-level data threats may not apply and so lower consent needed.

flaki: Consent is complicated and questionably effective.
… I'm generally on-board with this kind of ramp-up model for capabilities and consent.
… I'm not familiar with the research in this area and they are not as trivial as they seem.

Anssi: Personally I prefer making the common case simple for dev and user. Make advanced use cases possible but they don't need to be easy.
… As that applies to privacy, the advanced use case that requires more privacy should require more advanced prompting.
… The common use case should have a smoother UX if the threat level is low.

Riju: Intel has a sensor hub (ISH) where all the processing happens in hardware and drivers.

flaki: The WebXR polyfill is a good example of the power of the extensible web manifesto.
… On the other hand the web is not native. You can get away with high accuracy data. The web can't get away with that.

Riju: We shouldn't say what is allowed. We should give options.

flaki: This isn't boolean.

Anssi: Yes, this isn't boolean.
… Multiple low risk sensors together might be high risk.

Anssi: Invited research coming later. Maryam, from Newcastle University, is doing device sensor privacy research.

reillyg: We're now deep into this Generic Sensors discussion.

Riju: Proximity implemented as a WIP change and waiting on use cases/develeoper partners.
… ALS has seen progress on mitigations and has developer interest.

Tom: We tried to get internal (Google) customers interested.
… For external partners we struggle to prioritise features to introduce to them given their resource limitations.

Riju: Reached out to developers and saw nice-looking demos but couldn't see anything useful.
… One use case is iProov. They do 3D face recognition for authentication.
… Not pushing Magnetometer right now. Chatted with the Chrome Security & Privacy team. Might need to revisit mitigations.

Anssi: Anything that would help with this from a spec perspective or is it an implementation concern?

Riju: WebXR isn't interested in Magnetometer anymore.

Anssi: Has seen other cases of gesture recognition using this sensor.

Ehsan: I come from Newcastle University. My field is cybersecurity-related protocol design.
… We analyzed various attacks through sensors on the web.
… We are here to describe security and privacy aspects of sensors.

Ovidio: I work at Google with Reilly on device APIs. This is my first TPAC.
… Most of my work has been on WebUSB and Web Bluetooth.
… I've done some permissions UX work. I'm interested in how the UI for these sensor permissions should be done.

Anssi: It would be great to see Namrata (Google UX)'s presentation materials from last week here in this group.

xfq: I have been the team contact for this group for the past 2 years.
… We are very interested in hearing more feedback from other engines re: the work in this group.
… If you need any help from the W3C team on logistics or process feel free to contact me.

Kris: I'm here to observer and see what you guys do in this group.
… I am a researcher at Trinity University in Dublin.
… I'm interested in smart-buildings and adaptive services.

Agenda

Anssi: Presenting the set of specifications that are in scope.
… w3.org/das/roadmap

Permissions UX

Tom: For context, in Chrome we have a number of different reviews including UX, Security and Privacy.

Ovidio: Presenting slides from the Fugu Summit last week originally presented by Namrata.

Anssi: On defaults, these are something that each vendor can decide for themselves.

Reilly: So as an example, Chrome is working through shifting the defaults for sensors.

flaki: For new APIs shifting the default shouldn't be as difficult because the API has been designed from the beginning to support permissions.

Tom: Why did Apple build a separate static method for sensor permissions rather than integrate with the Permissions API.

Anssi: Apple doesn't ship the Permissions API, a static method was a compromise.

<anssik> reillyg: from developer perspective, good to have a consistent way to manage permissions, also reduces spec language duplication, understanding cross-browser consensus is important

<anssik> tom: does Chrome implement both status requestPermission() and Permissions API's corresponding mechanism together?

<anssik> reillyg: will need to look into that

Reilly: There doesn't seem to be much investment into the Permissions API given lack of consensus.

Tom: From a developer perspective the lack of consistency is confusing.

flaki: Scope of file system permission is comparable to combining multiple sensor types.
… We need further research into how to message these to users effectively.

Ehsan: Permissions like camera are obvious, the consequences of sensors are not.

Anssi: We need greater diversity of expertise to solve these problems.
… We should message to users how long permissions will be granted.

Ovidio: There have been discussions in Chromium that we should have temporary permissions. Everyone agrees that we should try it

Ovidio: (Wrapping up presentation) the important thing is showing what is being granted, to whom and how long.
… We will work on making these slides public.

<flaki> Battery Status API question on Twitter: https://‌twitter.com/‌jsscclr/‌status/‌1174469243582078977

Generic Sensor API

reillyg: first issue Add API for requesting permission https://‌github.com/‌w3c/‌sensors/‌issues/‌388
… Permissions API lack of consensus, so this issue asking if the Generic Sensor API should add its own requestPermission() similarly to DeviceOrientation, Notifications
… proposing we should do this, if the method is defined in a similar way as in Permissions API, implementation could be reused/shared
… Permissions API is a generic API for requesting permissions, API exposed on navigator.permissions
… Generic Sensor API could provide a requestPermission() that hooks into the Permissions API implementation on those implementations that currently implement that API
… other vendors' position on Permissions API informs the approach this group should take

tom: Permissions API enables bundling, we bundled low-level sensors accelerometer, gyroscope, magnetometer under one high-level sensors bundle

reillyg: today in Chrome you have a permission for "sensors" that grants access to accelerometer, gyroscope, orientation sensor, however it is implemented in such a way that we can surface low-level permissions as needed

reillyg: I can back off a bit from my comment that Sensor.start() should not have side-effects

tom: I'm torn between bundling, closing roads to that future

reillyg: Chromium moving to "ask by default" so would need something like this, Apple is in "ask by default" or "block by default", Mozilla's position needs to be checked

https://‌w3c.github.io/‌sensors/#api

PROPOSED RESOLUTION: Close issue #388 without adding a static `requestPermission()` API. Relying on the existing side-effects in `Sensor.start()` and the Permissions API for more advanced use cases such as permissions bundling.

Resolved: Close issue #388 without adding a static `requestPermission()` API. Relying on the existing side-effects in `Sensor.start()` and the Permissions API for more advanced use cases such as permissions bundling.

https://‌www.w3.org/‌2019/‌09/‌19-dap-minutes.html#x05

anssik: discussing features in-scope for CR re-enter (since last CR added WebDriver Extension API)

xfq: I asked the group to consider to re-enter CR since we're behind the roadmap
… we're of course waiting for more implementations

reillyg: Generic Sensor API, Accelerometer, Gyroscrope and Orientation Sensor are feature complete
… for ALS, Proximity, Magnetometer, do we need to include further Security and Privacy input before declaring feature completeness and re-enter CR

anssik: any objections to re-publish CRs?
… specifically, CRs of Generic Sensor API, Accelerometer, Gyroscrope and Orientation Sensor

PROPOSED RESOLUTION: Re-publish CRs of Generic Sensor API, Accelerometer, Gyroscrope and Orientation Sensor

[no concerns]

Resolved: Re-publish CRs of Generic Sensor API, Accelerometer, Gyroscrope and Orientation Sensor

https://‌github.com/‌w3c/‌sensors/‌issues/‌13

Allowing data batching when poll frequency < sensor frequency #13

reillyg: related with workers, batching, high frequency
… can react to sensor events when the main thread is busy, there are couple of solutions, input stack uses a concept of batching
… that's something we could adopt for sensors as well, there's also a question in general on the recommended pattern of using this API over DeviceOrientation, it does not need to be event-driven
… for example in an event loop you may want to read the sensor reading
… issues around data batching are implementation questions mostly, that is an important thing to have in the spec
… if you look at this #13 in contrast to #171, the latter seems duplicate
… #171 is a Level 2 issue that is premised on a fact that high freq data is available
… this suggest we leave #13 to be, since no strong use cases for high frequency readouts, and WebXR work is ongoing now, so may not be needed for that

PROPOSED RESOLUTION: Allowing data batching when poll frequency < sensor frequency #13 maintains it Level 2 status, awaits use cases

Ehsan: privacy-related information is already leaking at lower frequency, so that'd be amplified with high frequency polling

[no concerns with proposed resolution]

Resolved: Allowing data batching when poll frequency < sensor frequency #13 maintains its Level 2 status, awaits use cases

Geolocation API

https://‌github.com/‌w3c/‌geolocation-api/‌issues/‌25 is fixed! \o/

reillyg: in Chromium we've used Feature Policy for restricting access to iframes
… it sounds like we have implemented this restriction in Chromium, but there's no such language in the spec

reillyg: do you block Geolocation API in x-origin frames? I recall Feature Policy is not Mozilla-preferred mechanism

Flaki: there's a Mozilla bug for this, closed 9 days ago!
… another bug related to Feature Policy in this context, fixed in Firefox 71

PROPOSED RESOLUTION: Add Feature Policy integration into Geolocation API to match Chromium and upcoming Firefox

PROPOSED RESOLUTION: Add Feature Policy integration into Geolocation API to match Chromium and upcoming Firefox (fixes issue #10)

<flaki> The bug: https://‌bugzilla.mozilla.org/‌show_bug.cgi?id=1579373 (fix landed, slated for Firefox 71 and expected to go stable at the end of this year,)

anssik: will lack of WebKit's Feature Policy implementation cause an interop issue here?

<tomayac> WebKit's status on Feature Policy: https://‌bugs.webkit.org/‌show_bug.cgi?id=187816 (not implemented currently)

reillyg: FP can default to same-origin, that's how we'd spec it for this API, so if Apple blocks x-origin, it would breaks sites that expect to grant access to x-origin subframe

tom: in this case no breakage, if it is not allowed [in WebKit]?

Resolved: Add Feature Policy integration into Geolocation API to match Chromium and upcoming Firefox (fixes issue #10)

https://‌www.w3.org/‌2019/‌09/‌19-dap-minutes.html#x09

reillyg: https://‌github.com/‌w3c/‌geolocation-api/‌issues/‌11 is a duplicate of #25 that we discussed just a minute ago

<tomayac> WebKit currently allows x-origin iframe geolocation requests, so no breakage: https://‌stump-product.glitch.me

reillyg: https://‌github.com/‌w3c/‌geolocation-api/‌issues/‌12 was resolved by https://‌github.com/‌w3c/‌geolocation-api/‌pull/‌34

<tomayac> Firefox also allows x-origin access

https://‌github.com/‌w3c/‌geolocation-api/‌issues/‌24

anssik: spec language issue related to WebIDL, no implementation impact, just work that needs to be done
… https://‌github.com/‌w3c/‌geolocation-api/‌pull/‌20 was finally landed in Chromium, also Gecko implemented this as well as WebKit
… Plan to publish a revised Rec?

anssik: https://‌www.w3.org/‌TR/‌geolocation-API/ is not reflecting reality anymore

reillyg: let's fix #24 and then re-publish

xfq: we need to go back to CR and Rec

anssik: do we need to do wide review?

reillyg: changes are around security

xfq: wide review for the diff is enough

PROPOSED RESOLUTION: Publish CR and then Rec after fixing issue #24, wide review for the diff to previous Rec

[no concerns with the publication plan]

Resolved: Publish CR and then Rec after fixing issue #24, wide review for the diff to previous Rec

Geolocation Sensor

Anssi: Background, Geolocation API is the currently shipping API with consensus that we are not adding new feature but have resolved a few issues to strengthen security and privacy.
… GeolocationSensor is a new API shape taking advantage of the Generic Sensor API structure and solutions to existing problems.

Tom: My interest in coming to this specification is from background geolocation. The core specification was already there.
… Outstanding issues to discuss:
… 1. Accuracy
… Specification should be informed by what it technically feasable.

<anssik> [tom discussing Geolocation Sensor features that are work-in-progress, outlined at https://‌github.com/‌w3c/‌devicesensors-wg/‌issues/‌24#issuecomment-506748290]

Maryam: Are these standards-level questions to resolve or is it up to implementers?

Anssi: The previous API was underspecified. This new API provides the developer more control.

Reilly: More information from developers (better API) allows implementations to make better decisions.

Anssi: This stage of specification is a good opportunity to suggest changes.

Tom: From the start this API had the concept of fuzzing a location.
… That idea was abandoned as infeasible because "city-level" depends on density (Tokyo vs. rural America).
… 3. Worker
… Relatively straightforward.
… 4. Foreground tracking

Anssi: Frequency, accuracy, latency, are all correlated.

Anssi: One-shot readings are specifically included in the GeolocationSensor interface.

Reilly: This could also be useful for orientation sensors.

Tom: 7. Background tracking
… This could be a better for wake lock.
… If there is a `geo` wake lock then we could offload to the hardware to do tracking and not keep the site itself awake.

Tom: 8. Background geofencing
… Notification triggers are specified generically, they could be geofences.

Reilly: A background location tracking API could look similar to an event batching API discussed previously.

Tom: 9. Power saving

Maryam: Feedback from users is that apps in stores are approved by Google, Apple, etc. Whereas websites are not approved and would be concerned by background tracking.

Tom: System Wake Lock is not currently enabled precisely because we are not yet sure of the permission model.

Reilly: We are working on adding app-like UX to web applications with Installable PWAs.
… Also on Chromium we have a site engagement score which could be used as a signal.

Maryam: Do we have research into how user trust of a site adjusts when it is installed?

Tom: As a developer site engagement is difficult because of a lack of predictability.

Anssi: As something to study, why do users trust applications that are in the store? It is human review? Association with a known brand? The flow of installation itself?

Maryam: This shifts over time with generations, but generally people trust app stores no matter the process. It appears to be the branding of the store itself.
… Are stores planning to inspect the code for PWAs in app stores?

Tom: To some extent, possibly black-box testing.
… PWAs on the app store are built as TWAs which have to go through the normal review process.

Reilly: Next steps for work appear to be geofencing (through Notification Triggers) and foreground tracking with more expressive configuration.

Tom: Could we implement expressive configuration in the original specification?

Anssi: It would be more digestible for existing implementations to iterate on the original specification?

PROPOSED RESOLUTION: Explore retrofitting expressive configuration (Tom's comment on #24 items 1..5) of foreground tracking into the Geolocation API specification.

PROPOSED RESOLUTION Explore retrofitting expressive configuration (Tom's comment on #24 items 1..5) of foreground tracking into the Geolocation API specification.

Resolved: Explore retrofitting expressive configuration (Tom's comment on #24 items 1..5) of foreground tracking into the Geolocation API specification.

<anssik> [sangwhan agrees]

Device Orientation Event

reillyg: a number of issue, we'll work them one by one
… issue #74 asks for clarification of behavior of the Permissions API
… which event to fire when permission is granted, when to throw exception if not granted
… Safari implements this API
… we need to spec more precisely the details raised in #74, once we have another implementation we should be able to resolve this with implementation experience from two implementions

anssik: the group agrees #74 this is spec work that is blocked on Chromium being the second implementation

reillyg: https://‌github.com/‌w3c/‌deviceorientation/‌issues/‌70 is kind of related with Generic Sensor API issue #388

riju: talked with Firefox folks why they do not implement Permissions API

sangwhan: there's design disagreement, TAG has an action to look at aligning "Permission-like" APIs

tom: permissions are currently something UAs do as they want, any TAG interest to get people together to agree on the permissions UX and related APIs, incl. permissions bundling

sangwhan: yes, but it is complicated, since browsers and OSs have different permission models and UX
… bringing a lot of new features to the Web means this requires attention to avoid prompt fatigue
… will discuss this with mwest

reillyg: issue #70 can potentially wait until we have clarity on the status of Permissions API

sangwhan: agree, not critical
… another issue related to WebXR that exposes sensors, a different permission from sensor APIs, or is an OR gate

reillyg: right answer might be to have a token per each API, and for WebXR have "webxr" token, and leave it to UAs to decide how to communicate that to the users; API needs to be expressive enough so that implementations can communicate the need to users in an understandable way

sangwhan: TAG would like to hear your feedback on this matter

reillyg: you should be able to express the need "I need geolocation every 15 meters with an accuracy of 5 meters"

sangwhan: similar this in media

anssik: constraints model?

sangwhan: right
… also a similar pattern exists in audio

maryam: do web sites explain why they want this particular permission?

reillyg: in some native app platforms it is possible to add a custom string into the permission prompt
… this is possible on iOS and not on Android, not on the Web.

sangwhan: that is not very useful feature, people would just use "just press yes" on the Web

maryam: studies show explaining the reason for permission in the context of permission request is helpful for the user

anssik: on the web there's an emerging pattern of an onboarding page that explains why the permission is needed just before a prompt is shown

tom: problem is people can lie what the reason is for permission request, on the web there's no review process

PROPOSED RESOLUTION: For issue #70 wait until we have clarity on the status of Permissions API.

Resolved: For issue #70 wait until we have clarity on the status of Permissions API.

<tomayac> Publishers ask for notification permission on page load because the opt-in rate in A/B tests was higher than in contextual asking. What the blindspot of these A/B tests is is that users then block the notifications once the first (spammy) notification arrives.

<tomayac> (On Chrome, we have started mitigations against this)

PermissionState enum already defined in Permission API #82

https://‌github.com/‌w3c/‌deviceorientation/‌issues/‌82

reillyg: seems we can just spec this out

anssik: Chris of Apple agrees, no change on WebKit implementation

PROPOSED RESOLUTION: Re-use the PermissionState enum from the Permissions API (fixes issue #82).

[no concerns]

Resolved: Re-use the PermissionState enum from the Permissions API (fixes issue #82).

https://‌www.w3.org/‌2019/‌09/‌19-dap-minutes.html#x15

reillyg: Integration with Feature Policy
… Chromium does Feature Policy, Safari and Firefox comply with the default Feature Policy
… proposing we spec this using Feature Policy

https://‌github.com/‌w3c/‌deviceorientation/‌issues/‌64

PROPOSED RESOLUTION: Add integration with Feature Policy (fixes issue #64).

PROPOSED RESOLUTION: Specify and add integration with Feature Policy into Device Orientation Event specification (fixes issue #64).

PROPOSED RESOLUTION: Specify and add integration with Feature Policy using ["self"] as an allowlist into Device Orientation Event specification (fixes issue #64).

[no concerns]

Resolved: Specify and add integration with Feature Policy using ["self"] as an allowlist into Device Orientation Event specification (fixes issue #64).

reillyg: compassneedscalibration implementation experience

https://‌www.w3.org/‌2019/‌09/‌19-dap-minutes.html#x16

reillyg: https://‌github.com/‌w3c/‌deviceorientation/‌issues/‌38 only implemented by IE, should we remove it from the spec?

anssik: this has been open for ~3 years with no feedback

anssik: couldn't this just be delegated to the underlying platform API and a native UI?

reillyg: options: 1) do nothing, 1) use platform UI, or 3) expose the event and allow custom web calibration UI

tom: on iOS there's a low-level system thing that triggers platform UI

<tomayac> https://‌developer.apple.com/‌documentation/‌corelocation/‌cllocationmanager/‌1620563-dismissheadingcalibrationdisplay

maryam: OSs and/or hardware do this automatically, I think

reillyg: proposal to leave this issue open

https://‌github.com/‌w3c/‌deviceorientation/‌issues/‌33

Security/privacy consideration: cross-origin linkage #33

reillyg: global state is the generic issue, orthogonal with iframes, with multiple tabs open they get the same data, should we restrict to visible content only, not an issue on mobile since only one visible at the time
… the existing Permissions API work does not resolve this issue
… Chromium implementation restricts the DeviceOrientation/MotionEvents to visible browsing context.

anssik: we should probably specify this?

reillyg: should look at x-browser compatibility

anssik: Generic Sensor API has a mitigation in place for this, spec'd and implemented

reillyg: iframe case was only implemented recently

PROPOSED RESOLUTION: Restrict DeviceOrientation to visible browsing context, borrow language from Generic Sensor API (fixes issue #33).

[no concerns]

Resolved: Restrict DeviceOrientation to visible browsing context, borrow language from Generic Sensor API (fixes issue #33).

https://‌github.com/‌w3c/‌deviceorientation/‌issues/‌30

Malicious use of the phone's Gyroscope #30

reillyg: mitigations are moving these to permissions that are not allowed by default, reducing sampling rate is not enough

<rakuco> is webex supposed to be working? I've joined the conference but don't hear anyone

Privacy and Security

Slide: A Systematic Approach to Minimize the Risks of Mobile Sensors

A handout has been passed around summarizing the sensors currently exposed on native and web platforms.

Slide: Sensors access via Android, iOS, and Browsers

Maryam: We have implemented attacks using artificial intelligence to recover sensitive information.
… My understanding is that the web is trying to become as powerful (or more powerful?) as native apps.

Anssi: We can never reach parity because we run on those platforms but we want to reduce incentive for developers to target native over web while balancing security and privacy.

Maryam: Categorization of sensors is controversial but these 4 groups make it easier to consider the way that users interact with consent.

Anssi: Are these 4 sensor categories what users understand?

Maryam: People are much more concerned about ID and Comm sensors even though motion sensors can also be used to detect user location.
… The actual risks might not match the users' perceived risks.
… Are all these sensors in scope for this group?

Anssi: Motion and ambient are in scope for this group but members of this group also work on NFC and Bluetooth.

James_Hollyer: Fitness sensors, such as heart rate, use Bluetooth and so are already covered by Web Bluetooth.

Maryam: Insurance companies are very interested in health information and that can have negative consequences.

Reilly: Most of these sensors are in scope for this group but they are blocked by this kind of security and privacy work.
… Intel has an implementation of depth camera support in Chrome but depth cameras are currently rare.

Slide: History and Facts

flaki: In Accessibility WG it was mentioned that this sensor data can be used to detected disabilities.

Maryam: GDPR has highlighted these issues.

scheib: For big companies GDPR has been implemented worldwide.

Maryam: The GDPR doesn't specifically speak to sensor data and whether or not it is personal data.

Tom: Does GDPR imply sensors in any way?

Maryam: It is unclear. I am not a lawyer.

scheib: Every company needs to make its own legal determination. I suspect that many companies would assume that sensor data is personal data to ensure compliance.
… Within this group we should take the approach that this is personal data.

Maryam: If we are doing authentication using motion sensor data then this is personal data.

Slide: Research Questions

Maryam: Academia has come up with a number of attack. We don't know if these attacks are practical in a real world setting.

Anssi: We were unable to reproduce a number of these results, even in a controlled setting.

Maryam: Most of these papers and my own word use AI techniques.
… I want to focus strongly on building solutions that provide a good UX.

Reilly: You mention cross-platform differences are frustrating? Do you see users using multiple platforms and devices?

Maryam: Yes, users may in use multiple browsers or have multiple mobile platforms in their family.

<tomayac> "TouchSignatures: Identification of User Touch Actions based on Mobile Sensors via JavaScript" https://‌arxiv.org/‌pdf/‌1602.04115.pdf

Anssi: The takeaway for this group is that the permissions UX is important across browsers.

<scheib> Related: Privacy Threat Model proposed this TPAC: https://‌cryptpad.w3ctag.org/‌code/#/‌2/‌code/‌edit/‌NLylvy0EoY8ILUwfjq8wBOSQ/

scheib: This group should be aware that the Privacy Threat Model is relevant.
… From a research point of view it is an opportunity to contribute in a formal way.

<anssik> https://‌w3cping.github.io/‌privacy-threat-model/

<scheib> Privacy Budget: https://‌cryptpad.w3ctag.org/‌code/#/‌2/‌code/‌edit/‌5oNjMaFJJM3W8ar5LOiiLmZR/

<tomayac> Deep link to the Explainer: https://‌github.com/‌bslassey/‌privacy-budget

Maryam: Do our current permissions actually empower users?

Slide: Safe-zone sensors sampling rates

Slide: Is AI a solution?

Reilly: What kind of data would be used to train such a system?

Maryam: We don't know at this point. It is just a suggestion.

Tom: Going back to "safe zone," it could probably still be used as a fingerprinting mechanism.

Balasz: It's unclear to us whether there is anything that is safe and also useful.

<tomayac> Balazs: Even a low-accuracy rate while delivered when the permission is off would be in conflict with a user's preference if they select "off" for a given sensor.

Reilly: If we had low-acc and high-acc sensors we would still have an off mode that was really off. The default would just be low-acc.

Balazs: Have you done research on the best tone to use when communicating risks to users?

Maryam: No, this is a future work item. I haven't seen any research that specifically looks at sensors.

Tom: There is research on certificate warnings by Emily Stark at Google.

<tomayac> https://‌acmccs.github.io/‌papers/‌p1407-acerA.pdf

Wake Lock

WakeLock and Page Life Cycle

https://‌github.com/‌w3c/‌wake-lock/‌issues/‌139

anssik: As of currently spec'd, losing focus e.g. switching tabs will cause the screen wake lock to reject.
… Options: keep current behavior, auto acquire when returning to the tab.

reillyg: connection with Page Life Cycle is a bit red herring
… there are situations where wake lock is automatically released by the system, should also be acquired automatically?

<tomayac> I have created a quick demo that shows the behavior: https://‌wake-lock-demo.glitch.me/

reillyg: it adds complexity to API to acquire it but not really

rakuco: should discuss if it makes sense to add an option per kenneth's suggestion or keep current behavior

tom: pasted a demo link that shows the behavior

reillyg: there's a short period when it is invisible when transitioning to full screen, also when pulling out a tab from the tab strip
… related to a bug filed against the Chromium implementation of this feature a few days ago

<tomayac> Edit link: https://‌glitch.com/‌edit/#!/‌wake-lock-demo

reillyg: concern is, auto acquire mode means we have wake locks in this 3rd state that is "acquired, but currently released and waiting to be acquired"

anssik: are we optimizing for the common use case as we should?
… Google Slides etc.

marcos: I'm not seeing the JS required as an issue

<tomayac> I want to discuss https://‌github.com/‌w3c/‌wake-lock/‌issues/‌226

PROPOSED RESOLUTION: Decided to keep the internal state of the API simple, tab change does release the lock (closes issue #139)

PROPOSED RESOLUTION: Keep the internal state of the API simple, tab change does release the lock (closes issue #139)

PROPOSED RESOLUTION: Keep the internal state of the API simple, tab change does release the lock, add informative prose to the spec to show how to reacquire the lock (closes issue #139)

[no concerns]

marcos: ship it!

Resolved: Keep the internal state of the API simple, tab change does release the lock, add informative prose to the spec to show how to reacquire the lock (closes issue #139

WakeLock.request() returns a promise that never resolves

reillyg: I agree with marcos that we go back to the "old API-style", with single navigator.requestWakeLock() method, fires on all releases.

[reillyg shows another demo code on screen]

reillyg: I wanted the promise guide to give guidance when promises are used in connection with AbortController

[reillyg live-editing code on a big screen in search of a perfect API shape]

[it seems AbortController is now gone]

james: why we need lockId?

reillyg: we can have multiple locks, e.g. screen wake lock and system wake lock, maybe in the future "blue wake lock" that makes the screen blue

tom: can we have two wake locks of the same type?

reillyg: that'd not be useful

reillyg: https://‌wicg.github.io/‌web-locks/ API shape does not work for the Wake Lock API

[a ton of API design happening on the big screen, scribe unable to capture the sausage-making process]

flaki: all locks regardless of type, need unique identifiers

the new API surface that the group came up with https://‌github.com/‌w3c/‌wake-lock/‌issues/‌226#issuecomment-533032056

rakuco: should the spec clarify how the locks have their ids allocated, or is it implementation specific?

marcos: implementation detail, look for other similar APIs

PROPOSED RESOLUTION: Update the spec per the new API proposal as described in #226 (fixes issue #226)

[any concerns?]

rakuco: kenchris asking about AbortController

marcos: I'll talk to him

In obtain permission: don't co-opt resultPromise - it's creating a custom permission model #198

https://‌github.com/‌w3c/‌wake-lock/‌issues/‌198

marcos: do we need permission for this API?

reillyg: we want to go through permissions flow, just in case the user wants to out-out

marcos: what invokes this algorithm?

marcos: step 6.1 of https://‌w3c.github.io/‌wake-lock/#request-static-method is in the wrong place

[no concerns recorded for previous proposed resolution, so making it a resolution]

Resolved: Update the spec per the new API proposal as described in #226 (fixes issue #226)

Adjourn