Meeting minutes
AB TAG Recommendations
<scheib> https://
<anssik> Report of AB/TAG experiment
reillyg: following TPAC, the AB+TAG did an experiment to figure out a way to move forward from Mozilla's objection to the Charter. In recognition of the W3C operating without a Director, the AB+TAG acted a council and held a meeting with the Chairs and Mozilla and minutes were published. Link above.
reillyg: I wanted to go through the recommendations and make resolutions as a group.
reillyg: there is a long list of tasks that we could pursue. Let's triage them in this meeting.
… reillyg presents the recommendations....
reillyg: the first recommendation, they recommended publishing a bunch of specs as a working draft.
reillyg: I know we are publishing the Geolocation, so wondering if we need to get wide review?
xfq_: we don't need to get wide review for FPWD.
reillyg: I was confused about the review processes for Geolocation
marcosc: that was because we ere going to REC again... but now FPWD doesn't require it.
reillyg: if it's indeed not a heavy process to republish drafts, then we should publish those those documents. Then we can publish all as working drafts, and then seek review one or two at a time.
<anssik> proposed RESOLUTION: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor
reillyg: then we can do some of the spec modernization.
anssik: we need to decide the what level of work we want to do on them... and if we want to triage issues on those specs.
reillyg: we need to decide if these are truly living documents. Or can we leverage the w3c publication process ?
anssik: if we have a resolution, we can just automate the publication process.
marcosc: that sounds great
<anssik> proposed RESOLUTION: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor with a note warning readers that these specifications are being reviewed with reference to the AB/TAG decision and set up automatic re-publishing.
reillyg: that sounds like the minimal things to get us started
+1
<anssik> proposed RESOLUTION: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor with a note warning readers that these specifications are being reviewed with reference to the AB/TAG decision
<anssik> proposed RESOLUTION: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor with a note warning readers that these specifications are being reviewed with reference to the AB/TAG decision and set up automatic re-publishing.
reillyg: what we want to communicate is that we plan to continue working on these specs actively
Resolution: Republish WDs of Battery Status API, Proximity Sensor, Ambient Light Sensor, System Wake Lock, Geolocation Sensor, Orientation Sensor with a note warning readers that these specifications are being reviewed with reference to the AB/TAG decision and set up automatic re-publishing.
reillyg: we can discuss in the next resolution what are our next steps
reillyg: ok, so then, this makes the rest of what I have in my notes easier... looking at the specs that were highlighted in the recommendation I idetified two categories. Battery and orientation, and Ambient and system lock are implemented. The proximity and Geolocation sensor have not been implemented at all. I propose we prioritize the ones that are implemented, and review the orientation sensor API... and the we move to the other APIs a
s we get to them.
reillyg: We then limit to around two specs at once
anssik: yeah, we should limit what we work on, so not to flood reviewers.
anssik: there is evidence that there in interest in doing some retrofitting work, as shown by implementer interest in the Geo spec
reillyg: the battery API needs a fair bit of love. It would be good to bring Geolocation API and Geolocation Sensor together spec to the TAG. The argument in favor of Geolocation Sensor is that the design of the API has limitations as it relates to extensibility. So it would be good to bring to the TAG if it worth pursuing the Geo Sensor or if we can figure out a way to extend the olde Geolocation API
kenchris: is there an explainer that covers this?
reillyg: I'm not sure there is.
anssik: the value of the Geosensor is the teasing out of use cases, which tomayac did a great job in teasing out and capturing into the Geo Sensor API
anssik: the aim here is to make sure developers get their use cases covered.
anssik: by some API
tomayac: I see that we've had a review of Generic sensor. But we never had a review of Geosensor. There are some things the legacy API does easier, like watching a position. For background geo, it's not covered by the old API. Geofencing, we discussed notification triggers. For geo tracking use cases, we could have a system wake lock that would keep the geosensor alive.
<Zakim> anssik, you wanted to note there's a one-off read() https://
tomayac: if we could do the use cases in the old api, we might not need the new API... specially as we are facing some resistance to the generic sensor API.
anssik: we need to address the use cases, with hopefully a better API surface that can provide better privacy assurances. We don't need to make any decisions today. Yesterday we discussed privacy issues with our friends at Brave. We should make time to discuss that further.
<tomayac> The privacy concerns around the _current_ API seem to be mostly around permission (persistence) and not so much about the actual sharing and tracking (in the foreground) of one's location.
reillyg: to bring this back to a proposed resolution...
reillyg: there a few places where the battery API doesn't match implementation. We need to investigate privacy improvements. rakuco was having a look at some of the privacy issues.
anssik: that work has already been done
<anssik> https://
anssik: I need to check how quantization is done... and if we need to fix up the use of the RFC2119 keywords
tomayac: should we clarify what modernizing means... does it means showing a prompt in places? making the api async... adding SecureContext, which could break sites potentially
reillyg: what I mean is making editorial changes to algorithms to better match implementations
<Zakim> anssik, you wanted to propose we pursue more modern security and privacy reviews for all these documents and based on that feedback modernize the API
reillyg: we could look at if there would be "breaking changes" to the specification - but generally we want to take the specs to a better place
anssik: supporting what reillyg said. Plus we need to go and talk to the PING folks and see what their suggestions are. And if they want to us to change things to MUST etc.
tomayac: there is stuff that is obvious, like adding SecureContext, etc.
reillyg: we should do a cleanup round on our own. And then send this to PING.
anssik: I agree that we should update the specs before showing them to PING... or maybe they can review pull requests.
anssik: I know we have privacy experts in this group, but it's good to have interactions with the PING folks as they provide a lot of good feedback.
reillyg: I'd like to timebox discussions of specifics at this point.
reillyg: we know that "doing the right thing", specifically around bot detection + fingerprinting, we might need to break some sites - but there are good alternatives in the platform.
Resolution: Apply editorial modernizations to the Battery Status API, perform a round of self-review and revisions on the Security and Privacy aspects of the API before requesting horizontal review from the PING.
marcosc: do we have an editor
reillyg: we voluntold rakuco to do it (heheh)
<tomayac> scribeNick tomayac
marcosc: We can go to a First Public Working Draft and then straight to CR
marcosc: Since everything is implemented universally, we can go to REC next
reillyg: Sounds great. Question to the group: do we want to get the Geolocation API back to a living standard mode?
reillyg: Should Geolocation Sensor be included? Or abandoned?
marcosc: Ideally I'd like to sit down with tomayac and other interested folks and make a determination from there.
marcosc: Need to work out what's missing
anssik: That background work that marcosc is offering is very much in need
anssik: What use cases are really top priority for web developers? Once we understand that, which of those can be retrofitted?
anssik: And what is the implementors' feedback on these new use cases?
anssik: Knowing all this, we can then invest our effort accordingly.
anssik: Is this your priority, marcosc?
marcosc: Correct
larsgk: When you mentioned Geolocation Sensor being abandoned, we talked about sensors to step back on granularity
larsgk: This makes it easier for developers to understand the budget they may be overstepping. The more APIs are involved, the harder it is to figure that budget out for developers.
reillyg: Do we feel the new privacy mitigation can be applied to the legacy API, or do we need a new API for that?
reillyg: Not proposing to make a decision now. Proposing to make a decision as part of moving the Geolocation API to be a Living Standard.
reillyg: Some of the discussion motivates a new API.
anssik: Want to make a final point that the most vocal developers have been not the most constructive.
anssik: Some developers think it's the world's most popular feature.
anssik: Maybe we need to get marcosc legitimate data.
reillyg: That's the area where the new design has promise.
reillyg: Because the new API has this document event structure it doesn't make certain use cases easy like geofencing
reillyg: Acknowledging that it may not be easy to drum up implementor interest to implement.
marcosc: To speak in general, there needs to be the general problem that needs solving of doing things in the background, not just geolocation, but others.
marcosc: Some discussion happened in the service worker repo, but service worker is not the place according to Jake Archibald
marcosc: As a larger community we need to figure this out.
marcosc: That way there will be less resistence
reillyg: This unfortunately hasn't answered my questions. Do we want to consider this as part of Geolocation REC track, or after?
marcosc: Let's do it after (in parallel)
tomayac: +1, let's tackle these questions independently
anssik: We can do both indeed
anssik: Let's not block on experimentation
anssik: Please ask for help, marcosc.
<anssik> proposed RESOLUTION: Investigate the future of the Geolocation Sensor API in parallel with bringing the Geolocation API to REC track.
<anssik> proposed RESOLUTION: Investigate the new use cases of the Geolocation Sensor API in parallel with bringing the Geolocation API to REC track.
marcosc: Before we break, do we make a resolution to publish as FPWD?
<anssik> proposed RESOLUTION: Investigate the retrofitting of the new use cases enabled by the Geolocation Sensor API to the Geolocation API in parallel to bringing the Geolocation API to REC track.
reillyg: Because you were working on it, marcosc, I took it as a given
marcosc: This would be edition 3, or we drop the editions entirely, since we're moving it to living
<anssik> proposed RESOLUTION: Investigate retrofitting of the new use cases enabled by the Geolocation Sensor API to the Geolocation API in parallel to bringing the Geolocation API to REC track.
<anssik> proposed RESOLUTION: Investigate the retrofitting of the new use cases enabled by the Geolocation Sensor API to the Geolocation API in parallel to bringing the Geolocation API to REC track.
<anssik> proposed RESOLUTION: Investigate retrofitting the new use cases enabled by the Geolocation Sensor API to the Geolocation API in parallel to bringing the Geolocation API to REC track.
<anssik> proposed RESOLUTION: Investigate retrofitting the new use cases enabled by the Geolocation Sensor API to the Geolocation API
tomayac: Can we split it in two resolutions?
reillyg: The thing we want to note is that we're doing both things in parallel
<anssik> proposed RESOLUTION: Publish a FPWD of the Geolocation API
anssik: By definition they are not blocking
Resolution: Investigate retrofitting the new use cases enabled by the Geolocation Sensor API to the Geolocation API
reillyg: Looks good
Resolution: Publish a FPWD of the Geolocation API
<xfq_> [Break ☕️]
reillyg: We said what we do for Battery Status and Geolocation. That's two high prio specs cleared. The third is Orientation Sensor.
reillyg: I think we should do a review of Orientation Sensor. Do we just want to do this for Orientation Sensor, or make it broader?
reillyg: Concretely that means Accelerometer, Gyroscope, Gravity Sensor
reillyg: Within those specs, we have Orientation, Relative Orientation,… a bunch of others
anssik: When we say "should do a review", is that do a wide review and horizontal review? What did the TAG recommend?
reillyg: This is where we get in the later points of the document
reillyg: They recommend the group start with the second point (proactively pursue more modern security and privacy reviews)
reillyg: There should be a clear improvement in the shape improvement and the privacy section
reillyg: We added a Gravity Sensor since, which is a small addition, but it proves the architecture of the Generic Sensor API, so we can just add new sensors without much hassle
reillyg: It's an extension of the device motion sensors
reillyg: Had we extended the Device Motion API, it'd have been a lot harder
anssik: Why did Chromium decide to adopt this work?
anssik: Particular use cases were enabled
anssik: There was a customer demand for Gravity Sensor (Unity)
anssik: What would help TAG convincing, kenchris?
kenchris For the TAG, there is a lot of work, so not much time for individual issues. Have a good explainer helps, so we don't lose time when we need to dive in again
kenchris Generic Sensor is generic and doesn't define individual sensors, this is not clear to everyone for example
reillyg: Can we get a resolution?
<anssik> Motion Sensors Explainer
larsgk: I'm missing something on power consumption
larsgk: I remember that being a big problem in Nokia. I don't think the current API helps people use the hardware in reasonable ways without draining the battery
anssik: It's worth opening a new issue for. The sensor could hint at how it wants to be polled.
larsgk: If we move into background polling, then we need this
anssik: Open it for Generic Sensor or the particular sensor.
reillyg: One of the aspects of the API are that it has parameters which allow you to configure things accordingly
reillyg: It provides controls for making power consumption more optimal by making data minimization
reillyg: There are other things that could be done
reillyg: For example setting triggers or batching events
reillyg: Generally, this suggests that it's good to have a new shape
rakuco: Would like to doublecheck if I understand correctly
rakuco: The APIs have been maintained for years, but not much changes. Are we asking the same questions to the TAG again, like the TAG has evolved but not the spec?
reillyg: It's a combination
reillyg: The other recommendation from the TAG was to improve the privacy and security sections to better document concerns
reillyg: I did a review of these sections, but there wasn't full clarity on what the TAG actually asked
reillyg: But we can definitely always do a better job on these sections
anssik: Agreed. The world has changed, it wasn't ready when we published initially. But now it is ready
rakuco: So a new checkup.
anssik: The Motion Sensor API is still in progress
anssik: It should be Generic Sensor based
reillyg: I think the Generic Sensor API is a good framework but discussing it requires concrete examples.
reillyg: Like motions sensors
reillyg: And use those for the discussion
reillyg: We can take that for the discussion for other sensors that are out of the pure motion sensors
reillyg: Sticking with something we understand helps
anssik: I like this.
anssik: Leaving this to marcosc to decide how this should look like for Geolocation Sensor
anssik: Could be a markdown file with a fancy name like findings
tomayac: Is "wide review" defined?
<xfq_> https://
anssik: It is defined and is a mailing list. It's also known as horizontal review.
rakuco: Are we leaving out some sensors?
reillyg: Yes, focusing on sensors that are already part of the platform
reillyg: Leaving out new sensors that haven't been implemented yet
reillyg: By including new sensors we water down the discussion by triggering justification discussions for the existence of the new sensors
<anssik> proposed RESOLUTION: Pending completion of other horizontal review work, revise Security and Privacy sections of the Generic Sensors specifications, provide the TAG with a revised explainer for motion sensors and seek horizontal review for already shipping Generic Sensor API, Accelerometer API, Gyroscope API and Orientation Sensor API.
reillyg: Instead, we focus on the existing sensors
rakuco: When ALS came to mind, I imagined people already to complain about it
Resolution: Pending completion of other horizontal review work, revise Security and Privacy sections of the Generic Sensors specifications, provide the TAG with a revised explainer for motion sensors and seek horizontal review for already shipping Generic Sensor API, Accelerometer API, Gyroscope API and Orientation Sensor API.
scheib: With Geolocation Sensor, what is the carrot for developers?
scheib: Other groups of Chrome have pushed the concept of privacy budget
scheib: Maybe some new APIs might use this carrot
reillyg: Not aware of any specific discussions
reillyg: Remember similar disucssions around putting sensors behind a permission prompt
reillyg: If we allow frequency readings without prompts, that could be possible
marcosc: I haven't seen discussions in Mozilla about this while I was there previously
scheib: Maybe kenchris or anssik?
anssik: I like the idea of carrots.
anssik: Who is the person who's the most into privacy budgets?
kenchris: Not sure, not sure if it is pursued. Haven't followed to be honest.
scheib: There are people in Google who are behind it
reillyg: I haven't had discussions
reillyg: Don't know the current status
kenchris: It was discussed in the TAG, but they were not very fond
anssik: I expect PING to have opinions on this
https://
reillyg: We have our existing plan of republishing our specs
reillyg: There are a lot of things the TAG advises.
reillyg: We already do many of these
reillyg: Like providing developer incentives
reillyg: The start of this is the notes on the specs
reillyg: The decision around the Network Information API can happen now
reillyg: On this API, we haven't made much progress
reillyg: It's on the backlog, it occasionally comes up.
reillyg: For example with compute pressure.
reillyg: Olivier presented the API in the last meeting
reillyg: It's an API that tells the site how busy the device is
<anssik> Compute Pressure API
<anssik> FTR, I reached out to PING co-chairs to ask whether PING has reviewed or discussed the Privacy Budget proposal
reillyg: So sites can avoid thermal throttling or adapt their behavior if the device is too busy
<anssik> Privacy Budget proposal
tomayac: It's not directly connected to Network Information
reillyg: Correct, it's in a similar space
reillyg: The summary is that like System Wake Lock it's on our backlog
reillyg: We agree with the concerns raised by the current draft
reillyg: And would like to revise it, given enough time
<marcosc> tomayac: met with Yoav, and with some folks from Microsoft... we couldn't work out exactly what the use cases were for it. There were other outside scope use cases, like fraud detection
<marcosc> tomayac: we still need to look at other use cases that are already covered by the platform... like CSS prefers-low-data or something. So there are alternative approaches. The tl;dr: we don't fully understand the use cases.
marcosc: We wrote an extensive use cases doc
<marcosc> https://
<marcosc> tomayac: we did look at those
tomayac: We looked at those, we also acknowledged there's a black hole of use cases like tracking, bot detection, fraud detection,…
reillyg: It's too early to have a propsoed resolution
anssik: It's lower priority at the moment
reillyg: We will pursue work on this
<reillyg> new Promise((resolve) => {})
anssik: It feels like we have discussed the TAG concerns
anssik: We have a number of resolutions, which is good
anssik: We made great progress
reillyg: We ended up discussing a lot of the remaining agenda items
reillyg: The one thing we didn't discuss was the PING, because Pete couldn't make it
anssik: Already reached out regarding privacy budget