public-device-apis-log@w3.org from October 2019 by author

Anssi Kostiainen via GitHub

• Re: [sensors] Spec should include mandatory mitigations for privacy harms / risks (#397) (Friday, 25 October)
• Re: [sensors] Remove text about non-explicit permissions (#396) (Friday, 25 October)
• Re: [deviceorientation] Move fingerprintable APIs behind permissions (#85) (Friday, 25 October)
• Re: [sensors] Move fingerprintable APIs behind permissions (#398) (Thursday, 24 October)
• Re: [sensors] Remove text about non-explicit permissions (#396) (Thursday, 24 October)
• Re: [sensors] Syntax correction for the Feature-Policy response header example (#395) (Monday, 21 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Friday, 18 October)
• Re: [battery] Allow use in same-origin children, add Feature Policy integration (#13) (Wednesday, 16 October)
• Re: [sensors] [meta] Wide review tracker (#299) (Monday, 14 October)
• Re: [sensors] [meta] Wide review tracker (#299) (Thursday, 10 October)

Chris Dumez via GitHub

• Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Friday, 18 October)

Gregory Koberger via GitHub

• Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Sunday, 27 October)

Kenneth Rohde Christiansen via GitHub

• Re: [wake-lock] Make WakeLockPermissionDescriptor.type required. (#244) (Thursday, 17 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Thursday, 17 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Thursday, 17 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Thursday, 17 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Wednesday, 16 October)
• Closed: [wake-lock] WakeLock.request() returns a promise that never resolves (#226) (Wednesday, 16 October)
• Re: [wake-lock] Add an "if aborted" step to WakeLock.request() to deal with hidden documents (#234) (Friday, 11 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Wednesday, 9 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] WakeLockPermissionDescriptor's type should be required (#233) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)

Marcos Cáceres via GitHub

• Re: [wake-lock] Rewrite user-visible API (#237) (Thursday, 17 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Thursday, 17 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Thursday, 17 October)
• Re: [wake-lock] Consider not defining a custom WakeLockEvent (#238) (Thursday, 17 October)
• Re: [wake-lock] Race condition in request() steps (#239) (Thursday, 17 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Wednesday, 9 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Wednesday, 9 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Wednesday, 9 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Wednesday, 9 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] WakeLockPermissionDescriptor's type should be required (#233) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• [wake-lock] WakeLockPermissionDescriptor's type should be required (#233) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)

Mario González via GitHub

• Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Wednesday, 23 October)
• Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Friday, 18 October)

Martin via GitHub

• Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57) (Sunday, 27 October)

Nikolay Matyunin via GitHub

• Re: [sensors] Access to magnetometer and potential security & privacy issues (#394) (Sunday, 13 October)
• [sensors] Access to magnetometer and potential security & privacy issues (#394) (Friday, 11 October)

pes via GitHub

• Re: [deviceorientation] Move fingerprintable APIs behind permissions (#85) (Thursday, 31 October)
• Re: [deviceorientation] Move fingerprintable APIs behind permissions (#85) (Wednesday, 30 October)
• Re: [sensors] Spec should include mandatory mitigations for privacy harms / risks (#397) (Saturday, 26 October)
• Re: [sensors] Remove text about non-explicit permissions (#396) (Saturday, 26 October)
• Re: [deviceorientation] Move fingerprintable APIs behind permissions (#85) (Saturday, 26 October)
• Re: [sensors] Move fingerprintable APIs behind permissions (#398) (Thursday, 24 October)
• Closed: [sensors] Move fingerprintable APIs behind permissions (#398) (Thursday, 24 October)
• [sensors] Spec should include mandatory mitigations for privacy harms / risks (#397) (Thursday, 24 October)

Raphael Kubo da Costa via GitHub

• Re: [deviceorientation] Need to define the DeviceMotionEvent constructor (#83) (Saturday, 19 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Friday, 18 October)
• [wake-lock] Figure out what to do with workers and permission requests (#246) (Friday, 18 October)
• Closed: [wake-lock] Race condition in request() steps (#239) (Friday, 18 October)
• Closed: [wake-lock] Consider not defining a custom WakeLockEvent (#238) (Friday, 18 October)
• Closed: [wake-lock] Describe WakeLockSentinel.type (#240) (Friday, 18 October)
• Closed: [wake-lock] WakeLockPermissionDescriptor's type should be required (#233) (Friday, 18 October)
• Re: [wake-lock] Make WakeLockPermissionDescriptor.type required. (#244) (Thursday, 17 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Thursday, 17 October)
• Re: [wake-lock] Remove WakeLockEvent and WakeLockEventInit. (#242) (Thursday, 17 October)
• Re: [wake-lock] Add an "if aborted" step to WakeLock.request() to deal with hidden documents (#234) (Thursday, 17 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Thursday, 17 October)
• Re: [wake-lock] Add an "if aborted" step to WakeLock.request() to deal with hidden documents (#234) (Thursday, 17 October)
• Re: [wake-lock] Race condition in request() steps (#239) (Wednesday, 16 October)
• [wake-lock] Describe WakeLockSentinel.type (#240) (Wednesday, 16 October)
• Re: [wake-lock] Race condition in request() steps (#239) (Wednesday, 16 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Wednesday, 16 October)
• Re: [wake-lock] Add an "if aborted" step to WakeLock.request() to deal with hidden documents (#234) (Friday, 11 October)
• Re: [wake-lock] Add an "if aborted" step to WakeLock.request() to deal with hidden documents (#234) (Friday, 11 October)
• Re: [wake-lock] Fix reference to "a new promise". (#235) (Friday, 11 October)
• Re: [wake-lock] Add an "if aborted" step to WakeLock.request() to deal with hidden documents (#234) (Friday, 11 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)
• Re: [wake-lock] WakeLock.request() returns a promise that never resolves (#226) (Friday, 4 October)
• Re: [wake-lock] WakeLock.request() returns a promise that never resolves (#226) (Thursday, 3 October)

Reilly Grant via GitHub

• Re: [deviceorientation] Move fingerprintable APIs behind permissions (#85) (Wednesday, 30 October)
• [wake-lock] Hide failure to acquire a screen wake lock (#247) (Wednesday, 23 October)
• Re: [wake-lock] Describe WakeLockSentinel.type (#240) (Wednesday, 16 October)
• Re: [wake-lock] Race condition in request() steps (#239) (Wednesday, 16 October)
• Re: [wake-lock] Rewrite user-visible API (#237) (Wednesday, 16 October)
• [wake-lock] Race condition in request() steps (#239) (Wednesday, 16 October)
• Re: [wake-lock] Consider not defining a custom WakeLockEvent (#238) (Wednesday, 16 October)
• [wake-lock] Consider not defining a custom WakeLockEvent (#238) (Wednesday, 16 October)
• Re: [sensors] Access to magnetometer and potential security & privacy issues (#394) (Friday, 11 October)
• Re: [wake-lock] WakeLockPermissionDescriptor's type should be required (#233) (Tuesday, 8 October)
• Re: [wake-lock] Anyone implementing "system" lock? (#232) (Tuesday, 8 October)
• Re: [wake-lock] In obtain permission: don't co-opt resultPromise - it's creating a custom permission model (#198) (Tuesday, 8 October)
• Re: [wake-lock] WakeLock.request() returns a promise that never resolves (#226) (Friday, 4 October)
• Re: [wake-lock] WakeLock.request() returns a promise that never resolves (#226) (Thursday, 3 October)

Robert Linder via GitHub

• Re: [sensors] Syntax correction for the Feature-Policy response header example (#395) (Monday, 21 October)

Thomas Steiner via GitHub

• Re: [wake-lock] WakeLock.request() returns a promise that never resolves (#226) (Thursday, 24 October)

Last message date: Thursday, 31 October 2019 17:07:54 UTC