DAS WG TPAC F2F agenda (Fukuoka, Sep 19-20 2019)

[anssiko]

The Devices and Sensors WG will meet at TPAC 2019 on Thursday and Friday. See the spec roadmap for all deliverables in scope for the group.

This issues is to solicit feedback from the group on F2F agenda topics. All feedback welcome. Chairs: @anssiko @reillyeon.

Logistics

• Time: Thursday 19 Sep 2019 (full) and Friday 20 Sep 2019 (am)
• Venue: Hilton Fukuoka Sea Hawk
• IRC: irc://irc.w3.org:6667/#dap (IRC web client: http://irc.w3.org/?channels=#dap)
• Remote participation: WebEx details (W3C Members-only)

Minutes

• Devices and Sensors F2F Day 1 – 19 September 2019
• Devices and Sensors F2F Day 2 – 20 September 2019

Schedule

Thursday 19 September

Time	Topic
09:00-09:30	Intro, agenda bashing, admin announcements
09:30-10:30	Permissions UX
10:30-11:00	Coffee ☕
11:15-12:00	Generic Sensor API; Proximity, ALS, Magnetometer
12:00-12:30	Geolocation API
12:30-13:30	Lunch 🍣
13:30-15:00	Geolocation Sensor, Device Orientation Event
15:15-15:45	Coffee ☕
15:45-16:30	Privacy & Security
16:30-17:30	Wake Lock

Friday 20 September

Time	Topic
09:00-09:30	Agenda bashing
09:30-10:30	Wake Lock (cont'd)
10:30-11:00	Coffee ☕
11:00-11:30	Battery Status
11:30-12:30	Incubations: webGPIO, webI2C, WebNFC
12:30-13:30	Lunch 🍣

Proposed topics

Generic Sensor API

• v1: Add API for requesting permission Add API for requesting permission sensors#388
• v1: Discuss any features in-scope for CR re-enter (since last CR added WebDriver Extension API)
• v2: 🚧 #13, @riju to cherry-pick other issue from Level 2 for discussion

Proximity, ALS, Magnetometer, other Sensor APIs

• Proximity Sensor https://github.com/w3c/proximity/issues
  • Discuss Chrome implementation experience spec implications Generic Proximity sensor or UserProximity sensor proximity#4
  • Security and privacy Security/privacy considerations proximity#17

No v1 blockers, re-enter CR?

• Ambient Light Sensor https://github.com/w3c/ambient-light/issues
• Magnetometer https://github.com/w3c/magnetometer/issues
• Accelerometer https://github.com/w3c/accelerometer/issues
• Gyroscope https://github.com/w3c/gyroscope/issues
• Orientation Sensor https://github.com/w3c/orientation-sensor/issues

Geolocation API

• Restrict interfaces to secure contexts? Restrict interfaces to secure contexts? geolocation#25
• Spec clarifications: #10 #11 #12 #24
• Normative changes landed: #20
• Plan to publish a revised Rec?

Geolocation Sensor

• DAS WG TPAC F2F agenda (Fukuoka, Sep 19-20 2019) #24 (comment)

Device Orientation Event

• Permission model spec clarifications needed informed by implementation experience requestPermission() and event handling clarification deviceorientation#74
• Integration with the Permissions API, reuse permissions tokens Add integration with the Permissions API deviceorientation#70
• Integration with Feature Policy Add integration with Permissions Policy deviceorientation#64
• compassneedscalibration implementation experience compassneedscalibration event - cannot confirm interoperability deviceorientation#38
• Review whether the open security and privacy issues are mitigated by the new permission model Security/privacy consideration: cross-origin linkage deviceorientation#33 Malicious use of the phone's Gyroscope deviceorientation#30
• PermissionState enum already defined in Permission API
  PermissionState is already defined in Permission API deviceorientation#82

Battery Status API

• Review real-world usage data, do a data-driven decision on whether to add proposed restrictions Allow use in same-origin children, add Feature Policy integration battery#13
• Detect power saving mode #9

Privacy & Security session

• Security and privacy of sensors research findings by Newcastle University @maryammjd
• TAG-published Security and Privacy mitigation strategies intersection with DAS WG work - check @lknik availability?

Wake Lock API

• DAS WG TPAC F2F agenda (Fukuoka, Sep 19-20 2019) #24 (comment)
• (Schedule for Thu around 4pm to get @marcoscaceres and @rakuco, remote)

Incubations of interest/relevant to DAS WG audience

Given time and the critical mass of interested people in the room, we can discuss incubations relevant to DAS WG. Possible ones:

• Web NFC API - redesigned API, implementation experience
• webGPIO and webI2C
• Serial API
• WebUSB API
• Shape Detection API
• Network Information API - Web & Networks IG soliciting use cases for future work

Admin

• The group has an option to adopt a Pull Request Template for its specs to ensure implementations and tests stay in sync with spec changes. Recommended for mature specs with multiple implementations. Piloting with Geolocation API #31

[maryammjd]

Hi everyone,

Since security/privacy/permission of sensors has been the centre of lots of discussions, I would like to have a half an hour presentation on our research on "security and privacy of sensors". It will be fantastic to hear from all the people in the room about the challenges and opportunities. Hopefully, such a discussion will help the WG to have a proactive approach for new sensors, resulting in better security and privacy experiences.

Thanks,
Maryam

[anssiko]

Thanks @maryammjd, I created a "Privacy & Security session" and allocated you a slot in it. We may shuffle the order of agenda topics.

[tomayac]

Geolocation Sensor

• 🚧 Triage https://github.com/w3c/geolocation-sensor/issues for F2F issues - @tomayac to help?

Looking at the open spec issues, I can see eight bullets (following the labels) that we can discuss:

1. Accuracy:
   How should the desired accuracy be expressed?

2. Latency:
   How should the desired latency be expressed?

3. Workers:
   How should user activation be transferred to the Worker?

4. Foreground tracking:
   Rather than reads based on a frequency, can the old change-based behavior of watchPosition() be preserved?

5. Update frequency:
   This is Sensor.frequency needs to be setable to allow frequency adaptation sensors#63 really.

6. Background tracking:
   Is maybe a "system" (or potential "geo") type Wake Lock the better home for this?

7. Background geofencing:
   Is maybe Notification Trigger (search for "location", also see the related Chromium bug) the better home for this feature?

8. Power saving:
   Should a "battery saver" status have an impact on Geolocation Sensor accuracy and frequency?

This is just a proposal, what do you think? (Note: I will be out of office most of July, please expect delayed responses.)

[anssiko]

Thanks @tomayac! Looks like a well thought out list of topics. I'll let others chime in over the summer period (expect slow responses from me) and we'll bake these into the agenda proper sometime in August.

[reillyeon]

In planning our agenda we should perhaps attempt to avoid scheduling the entire day for both days given that our meeting conflicts with the Web Applications WG.

[anssiko]

Brainstorming with @rakuco and @kenchris. For Wake Lock API, we'd propose the group discusses the following "v1" issues:

Notes:

• @rakuco will call in from CET, so -7 hours behind. Prefer to discuss this API as the last topic of either of the days.
• Try get @marcoscaceres as a friend of wake locks visit us at some point.

WakeLock.request() returns a promise that never resolves

https://github.com/w3c/wake-lock/issues/226

• The concern in this issue is the non-standard promise behavior

WakeLock and Page Life Cycle

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

• 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.
• Currently, a possible JS workaround is:

if (!document.hidden && areWeFullScreenStill()) {
// request a new wake lock
}

• If keeping the current behavior, should update https://w3c.github.io/wake-lock/#h-note-4 to match the normative prose

Need to add "wake-lock" to permissions registry

https://github.com/w3c/wake-lock/issues/184

Custom permission model?

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

System lock use cases

• Discuss security implications of system locks in common use cases. Example: use geolocation while navigating might open up an opportunity to use e.g. audio recording.

[anssiko]

@reillyeon: In planning our agenda we should perhaps attempt to avoid scheduling the entire day for both days given that our meeting conflicts with the Web Applications WG.

Here's the WebApps WG's F2F schedule: w3c/webappswg#10

WebApps WG F2F runs unconference sessions from Thu noon onwards and the whole day Friday. I'd propose DAS F2F runs full Thursday and ends noon-ish Friday. This would allow DAS participants who want to join or lead WebApps WG unconference session(s) to do so Friday afternoon. We could perhaps break on Thu 11:15am to allow interested folks to join WebApps WG's unconference logistics session.

Does this sound good?

[anssiko]

@riju, do you mind looking at Generic Sensor API Level 2 issues to see what would make sense to discuss at F2F considering in particular implementation status and plans?

I added #13 as an example, since its latest comment notes a number of open issues that are related.

[anssiko]

I started putting the proposed agenda topics into a schedule, see #24 (comment) All feedback welcome.

We'll do agenda bashing as the first thing on both the days, but please let us know already now if you're aware of a conflicting time. I scheduled Wake Lock as the last thing on Thursday to work for @rakuco (remote) and @marcoscaceres (visiting us from WebApps WG).

[maryammjd]

A relevant paper: A Large-scale Study on the Risks of the HTML5 WebAPI for Mobile Sensor-based Attacks

[satakagi]

Hi, this is my input about Web GPIO and Web I2C
https://github.com/satakagi/TPAC2019-docs/blob/master/WebGPIO_I2C.md