Meeting minutes
Welcome
anssik: In this working session the editors and other contributors will triage the remaining DeviceOrientation Event Specification open issues in preparation for its expected CR Snapshot publication.
reillyg: we're in a good position with this spec that has a lot of implementation experience, an older specification
… similar to the work we did with Geolocation API to get it to Rec
… thanks Raphael for all the work in modernizing this spec and cleaning it up to standards
… today we go thought the existing issues to see which are v2 to be deferred for later
… we can go from older newest
https://
Add way of getting current orientation
#11
<gb> Issue 11 Add way of getting current orientation (by marcoscaceres)
reillyg: Geolocation API provides getCurrentPosition()
… getCurrentOrientation() could be implementable however it seems extremely polyfillable
… observables can wrap events so you'll get just the first event in a fluid way
… not sure there's significant value in adding this to the API
… not a terrible idea either
… because sensors fire events all the time, the app probably wants to receive a few values and average the results to filter out noise, doing this properly could get complicated
Raphael: we have a legacy API we must maintain because everyone implement it, it probably does not make sense to add another method to this API, Generic Sensor API would be better alternative
Reilly: there's no promise-based version in the Generic Sensor API to get current reading
… I'd like to take an action to close this issue with a comment
proposed RESOLUTION: A Promise-returning API can easily be polyfilled, #11 is considered closed
RESOLUTION: A Promise-returning API can easily be polyfilled, #11 is considered closed
Malicious use of the phone's Gyroscope
#30
<gb> Issue 30 Malicious use of the phone's Gyroscope (by Yossioren)
Raphael: we're not exposing on insecure contexts
Reilly: Chrome issue was mitigated by capping frequency to 60 Hz
… I'd say that given a number of mitigations in place we could consider this closed
Raphael: bug report says just capping the frequency wouldn't mitigate this?
Reilly: accuracy not mentioned in this paper as a mitigation, we've added that additional mitigation to this spec
… reduces passive fingerprinting
<gb> CLOSED Issue 85 Move fingerprintable APIs behind permissions (by pes10k) [privacy-tracker]
Reilly: I think we can close given the proposed mitigations have been implemented and more, close with an invitation for the community to investigate this API further
Raphael: WFM, since the mitigations suggested are in place
proposed RESOLUTION: Proposed mitigations (restrict to secure context, add a permission gate) have been specified and implemented
Reilly: the paper suggests a low-pass filter could be applied to filter out higher frequencies
proposed RESOLUTION: Proposed mitigations (restrict to secure context, add a permission gate) have been specified and implemented, consider #30 addressed
<gb> Issue 30 Malicious use of the phone's Gyroscope (by Yossioren)
RESOLUTION: Proposed mitigations (restrict to secure context, add a permission gate) have been specified and implemented, consider #30 addressed
Security/privacy consideration: cross-origin linkage
#33
<gb> Issue 33 Security/privacy consideration: cross-origin linkage (by wseltzer) [privacy-tracker]
Reilly: agree with Raphael this has been mitigated as commented in w3c/
<gb> Issue 33 Security/privacy consideration: cross-origin linkage (by wseltzer) [privacy-tracker]
Raphael: it is in S&P section, not integrated into the algorithms
Reilly: but MUSTSs in that section are implemented?
Raphael: in Blink yes
Reilly: an action is to update the algorithms to match implementations
proposed RESOLUTION: Integrate visibility state check into affected algorithms, that closes #33
RESOLUTION: Integrate visibility state check into affected algorithms to close #33
Need to define the DeviceMotionEvent constructor
#83
<gb> Issue 83 Need to define the DeviceMotionEvent constructor (by foolip)
Reilly: we don't have algorithms for contructors and Raphael found some implementation issues
… constructors inherit from the DOM spec, no need to spec constructor prose, IDL implementation difference between Blink and Gecko
… DOM spec should define getter steps for each of the attributes
… I'd say close #83 and fix #91
<gb> Issue 91 DeviceMotionEvent atttributes can't be null per current IDL (by saschanaz)
Reilly: if we close #91 do we need to write spec text?
Raphael: if we change the IDL we don't need prose
Reilly: need to figure IDL then and align with implementations
Device motion sampling frequency
#87
<gb> Issue 87 Device motion sampling frequency (by marcoscaceres) [privacy-tracker]
Reilly: this is the same Gyrophone paper than in the earlier issue #30
<gb> Issue 30 Malicious use of the phone's Gyroscope (by Yossioren)
Reilly: Firefox issue notes browser caps, information is outdated
Raphael: spec does not seem to mention frequency caps
… implementations poll the backend
Reilly: normatively limiting the rate would solve this issue, assuming every implementation does that?
Raphael: I don't know what Firefox and WebKit do
Reilly: action item to confirm what engines do and normative specify cap
Raphael: would be great to get feedback from other engines to understand what is the limit they settled on
Reilly: good topic to discuss when we kick off joint work with WebApps WG
Raphael: could also follow up on the GH issue
… I can take that action
… should we try to solve this prior next CR Snapshop or defer to a later snapshot?
anssik: OK to go to CR Snapshot with open issues
DeviceMotionEvent atttributes can't be null per current IDL
#91
<gb> Issue 91 DeviceMotionEvent atttributes can't be null per current IDL (by saschanaz)
Raphael: I looked at this, all engines do this differently and current IDL is wrong
Reilly: many layers of dictionaries, complexity that you can fire an event with null events
… null and undefined are two different things, must be handles differently
Reilly: acceleration, accelerationIncludingGravity must be nullable, initialization with null is valid
… usual WebIDL behaviour is passing empty dictionary you get default initialized dictionary that gets you all of the individual values set to null
Reilly: if dictionary is not required can it be null or only undefined
Reilly: we want to distinguish between null and undefined? Is that useful thing to do?
… would be helpful to enumerate reasonable uses of the constructor and make sure that is possible through IDL
… default dictionary construction not doing what is useful for the spec
… all dicts are nullable indicates support for the values of that attribute the sensor can return
Raphael: what if you make acceleration, accelerationIncludingGravity and rotationRate nullable and default to null
Reilly: we say default value is null?
… is it valid for dict value to be null?
Reilly: if nullable dict type is valid we can say default value is null
… I will add a proposal to the GH issue to revert #55 and explicitly define the default values for acceleration, accelerationIncludingGravity and rotationRate to be null
<gb> MERGED Pull Request 55 Remove '?' from dictionary members of DeviceMotionEventInit (by reillyeon)
Raphael: if we do that though, it will diverge from implementations
… what you propose is the right way to go about and make implementation to align with that
proposed RESOLUTION: Seek feedback from WebIDL experts to ensure the proposed spec changes are correct
RESOLUTION: Seek feedback from WebIDL experts to ensure the proposed spec changes are correct
Behavior when event data cannot be provided is underspecified
#118
<gb> Issue 118 Behavior when event data cannot be provided is underspecified (by rakuco)
Raphael: underdefined behaviour that is not a big issue, the spec could provide more detail here
Reilly: would be nice to improve this because now we have permissions and when you grant permission you may or may not have fired an event
… being more specific would be nice
… in reality there are no platforms where new sensors appear
… and currently there's agreement whether to fire an empty event if no permission
… Safari doesn't fire an event in such a case matching the spec behaviour
… I'm of an opinion APIs should provide errors
… an idea of an empty event appeals to me
… you can check permission state, it'd be nice if the API could produce an error
Raphael: there's nothing in the spec that says there's just one error, should there be text there's just one event?
Reilly: only one event type checks for significant difference, deviceorientation specifically
… I'm be fine amending this so that single event should be fired in this case
… how that interacts with multiple event listeners, I guess only fires the first times
Raphael: I'd expect in that case to fire once per each listener?
Reilly: in overlapping cases sensor state is changing with fire once semantics
Raphael: from spec perspective it makes sense to say fire a null event once
Reilly: right, still underspecified but clearer
Raphael: OTOH, between this and permission handling, if permission denied fire one event as well?
Reilly: if we introduce sensor state concept, "started", "stopped", "errored" it'd be easier to spec
… if we add these states and state machine it'd be easier to spec
… all implementation have a state machine
Raphael: even speccing this is the first event listener is hard
Reilly: if the event listener mechanism tries to hide this detail, it becomes impossible
Raphael: is this so big of an issue?
anssik: we can surface this in the proper as an issue?
DeviceOrientationEvent.absolute's value when data cannot be obtained
#119
<gb> Issue 119 DeviceOrientationEvent.absolute's value when data cannot be obtained (by rakuco)
Reilly: this is about null events, I'd say we'll init this to false, I believe all implementation do that
Raphael: I can take an action to check what WebKit and Gecko do in here
Guidance needed: how to acquire compass headings in a future-compatible manner?
#137
<gb> Issue 137 Guidance needed: how to acquire compass headings in a future-compatible manner? (by juj) [question]
Reilly: this is a known area of implementation incompatibility and we should discuss this with reps from the WebKit project
Raphael: there was an implementation of DeviceOrientation when Blink did not exist
… a new WebKit implementation landed a few years ago
Wrap up
anssik: thanks editors for your diligent work on this spec!