Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
anssiko opened this issue Jun 17, 2019 · 11 comments
Closed

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

anssiko opened this issue Jun 17, 2019 · 11 comments

Comments

@anssiko
Copy link
Member

anssiko commented Jun 17, 2019 •
edited

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

Minutes

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

Proximity, ALS, Magnetometer, other Sensor APIs

No v1 blockers, re-enter CR?

Geolocation API

Geolocation Sensor

Device Orientation Event

Battery Status API

Privacy & Security session

Wake Lock API

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:

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
@anssiko anssiko mentioned this issue Jun 17, 2019
Closed
@maryammjd
Copy link

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
Copy link
Member Author

anssiko commented Jun 24, 2019

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

@tomayac
Copy link

tomayac commented Jun 28, 2019 •
edited

Geolocation Sensor

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
Copy link
Member Author

anssiko commented Jun 28, 2019

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
Copy link
Member

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
Copy link
Member Author

anssiko commented Aug 15, 2019

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
}

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
Copy link
Member Author

anssiko commented Aug 15, 2019

@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 anssiko mentioned this issue Aug 16, 2019
Closed
@anssiko
Copy link
Member Author

anssiko commented Aug 21, 2019

@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
Copy link
Member Author

anssiko commented Aug 28, 2019

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
Copy link

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

@satakagi
Copy link

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

@anssiko anssiko changed the title [DRAFT] DAS WG TPAC F2F agenda (Fukuoka, Sep 19-20 2019) DAS WG TPAC F2F agenda (Fukuoka, Sep 19-20 2019) Sep 25, 2019
@anssiko anssiko closed this as completed Oct 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@tomayac @reillyeon @anssiko @satakagi @maryammjd