Devices and Sensors Working Group charter 2021

[xfq]

New charter proposal, reviewers please take note.

Charter Review

Devices and Sensors Working Group Draft Charter

• [x] Existing WG recharter
• Diff from previous charter

Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, and security. Also add a "card" for this issue to the Strategy Funnel.

Communities suggested for outreach:

Known or potential areas of concern: security, privacy, implementation experience

Where would charter proponents like to see issues raised? GitHub

Anything else we should think about as we review?

The updated charter adds Contact Picker API, Idle Detection API, and Compute Pressure to the list of specifications to tentative deliverables of the Working Group.

As the WG's current charter indicates that "the Working Group will prepare an updated Charter that differs only in deliverables" if additional in-scope Rec-track documents are added, the WG requests that reviewers focus on the additions.

/cc @anssiko @reillyeon

[himorin]

I suppose second latest line in the charter history table (starting from 2020/Dec/1st) has wrong end date. (the same also for the current charter)

[anssiko]

@xfq thanks! I think it might be appropriate to move the "Fold Angle Sensor" from Tentative Deliverables to Normative Specifications on the same pass now that this spec has been published as a FPWD and WD (and subsequently renamed to Device Posture API to better reflect its scope).

[xfq]

@himorin @anssiko Thanks. Should be fixed now.

[anssiko]

@xfq perhaps better to link to https://oyiptong.github.io/compute-pressure/ for the "Compute Pressure" instead of the GH repo. If this draft moves to the wicg repo in between the redirects should work then.

[himorin]

No comment/request from i18n.

[xfq]

@xfq perhaps better to link to https://oyiptong.github.io/compute-pressure/ for the "Compute Pressure" instead of the GH repo. If this draft moves to the wicg repo in between the redirects should work then.

Thanks. Link updated.

[michael-n-cooper]

APA Research Questions Task Force is looking at this charter and will get back in a couple weeks.

[wseltzer]

Why are Contact Picker, Idle Detection, and Compute Pressure listed as "Tentative Deliverables"? What does that mean in Process terms?

[plehegar]

It would be good to understand the progress of the DAS Group regarding the recommendations provided in December 2020, in particular with regards to the TAG reviews of the deliverables listed in the current charter.

[reillyeon]

It would be good to understand the progress of the DAS Group regarding the recommendations provided in December 2020, in particular with regards to the TAG reviews of the deliverables listed in the current charter.

The DAS WG discussed the Council's recommendations in a group call last month and resolved to start the process by publishing working drafts of the specifications. @anssiko sent out a CfC for that publication process yesterday. In the meeting we resolved on an overall order for bringing these specifications back to the TAG, starting with the Geolocation API and Battery Status API, after we do some cleanup of these specifications.

[marcoscaceres]

Sorry, Geolocation API or Geolocation Sensory API? (or both... hhmmm, maybe that might be good idea to discuss overlap🤔)

[anssiko]

Why are Contact Picker, Idle Detection, and Compute Pressure listed as "Tentative Deliverables"? What does that mean in Process terms?

@wseltzer, we adopted this Tentative Specifications approach based on Mozilla's FO feedback following an example set forth in the WebApps WG Charter.

[marcoscaceres]

What does that mean in Process terms?

In terms of Process, it should mean that DAS can adopt those specs as work items without the need of rechartering at any point in the next 2 years (or whatever the duration of the charter is).

[wseltzer]

Thanks @anssiko and @marcoscaceres .

Listing as a Tentative Deliverable appears to move the decision about whether/when to formalize work from the Advisory Committee (through charter review) to the WG. The AC might want to see more criteria for that decision than "Depending on the progress." For instance, the Mozilla FO refers to implementation interest. Do you have some criteria in mind for assessing rec-track readiness?

Part of what I'm trying to understand here is whether it makes sense to put all these specs into DAS, and whether they're likely to engage sufficient participation and support to succeed.

[samuelweiler]

No (new) security or privacy concerns. I'm fine with adding these three work items (though some will be interesting to sort through on their own).

I see that the Success Criteria section of this charter notably diverges from the template. This text doesn't preclude the specific instructions re: separate security and privacy sections, so I don't object to it going forward, and given how much of that section has been carefully negotiated, it makes sense to leave it unchanged in this minor recharter. (It might be worth eventually reordering that section, putting the privacy concerns paragraphs together and the testing paragraphs together but, again, this is not important.)

I would support extending the charter an add'l 6 months, giving them ~2 years from this recharter event.

I filed a PR re: calling out the rename of Fold Angle and moving it to normative. https://github.com/w3c/dap-charter/pull/112

[anssiko]

Do you have some criteria in mind for assessing rec-track readiness?

Multiple implementer interest is our key criteria when assessing readiness. We also listen to signals from web developers per our charter commitment. The exact wording ("Depending on the progress...") is borrowed from the WebApps WG Charter.

Part of what I'm trying to understand here is whether it makes sense to put all these specs into DAS, and whether they're likely to engage sufficient participation and support to succeed.

Based on our vF2F discussions, this group seems to have the interest and expertise, including the current spec editors (or their member companies). As a curious detail, Contact Picker API has precedent in this group dating back to 2009 (see https://github.com/w3c/dap-charter/issues/97).

[wseltzer]

The exact wording ("Depending on the progress...") is borrowed from the WebApps WG Charter.

I propose that we be more specific here, at least "Depending on the progress, including interest from multiple implementers..."

[marcoscaceres]

I propose that we be more specific here, at least "Depending on the progress, including interest from multiple implementers..."

I agree. The new Contacts API serves as an exemplary case in point: as both Google and Apple have implemented the API (even if Apple is not part of the WG).

[plehegar]

In the meeting we resolved on an overall order for bringing these specifications back to the TAG, starting with the Geolocation API and Battery Status API, after we do some cleanup of these specifications.

IMO, it would better to demonstrate progress in the Working Group by actually starting some of the TAG reviews before asking the Director to add yet another set of deliverables. Back in September last year, we understood that Screen Fold API was almost ready, yet we don't have a Candidate Recommendation for Device Posture today.

[anssiko]

@plehegar, below is a report of the group's progress with respect to the horizontal reviews and related activities which should address your concerns. We're considerate of horizontal groups' time and want to do our homework properly before requesting reviews.

• Screen Fold API / Device Posture API

This spec was adopted by the DAS WG as its deliverable in the 1 Dec 2020 charter update. The group published Screen Fold API FPWD in Q4 2020 well ahead of the planned FPWD Q3 2021 charter milestone and the group is on track to publish a CR by Q2 2022. TAG review request was submitted in Q4 2020 and it is being discussed by TAG. It is not preferred for a spec to go from FPWD to CR in ~6 months, thus your request for "CR today" must be an error.

• Geolocation API

The group resolved to publish the First Public Working Draft of the Geolocation API hardened for security and privacy. Due to process issues the publication has been delayed, but we expect FPWD publication to happen soon.

• Battery Status API
• Proximity Sensor
• Ambient Light Sensor
• Geolocation Sensor
• Orientation Sensor
• System Wake Lock

Following the discussion and resolution taken at the Q2 2021 vF2F, the group resolved to publish updated Working Drafts of the above specs in scope of the AB/TAG Experiment to pull in changes to the TR.

All these publications are now in transit, and horizontal reviews will be requested when we have the TR references at hand that we expect not to change from underneath the reviewers. We also do not want to clog the horizontal review machinery, and plan to use a staggered approach starting with requests for specs that are the most time sensitive.

[michael-n-cooper]

In APA review, the group wonders if the Contact Picker API is in scope of the WG, which otherwise focuses on APIs for specific hardware features. It seems that API might be more suited to the Web Platform Working Group (or whatever it is currently named). APA thinks this API would have more user interface implication than the other APIs. If this is in the charter, API requests to be included as a liaison in section 4.1, with text like "Coordinate on accessibility of user interface features implied by the APIs".

[marcoscaceres]

@michael-n-cooper, we could take it in WebAppsWG. It's indeed probably a better fit, and we have Apple in that WG, so they could better participate (in as far as they could provide valuable input/feedback as implementers).

[anssiko]

@michael-n-cooper thanks for the APA review. Please note this group’s extensive history in the contacts capabilities space https://github.com/w3c/dap-charter/issues/97 and also another picker model using spec https://www.w3.org/TR/html-media-capture/ this group has delivered.

Also thanks for suggesting a new liaison in 4.1, I’m supportive of that.

With this data at hand, this group looks like a good home for this work. We’re open for new members and look forward to collaborating with APA more closely.

[marcoscaceres]

We should probably make a call here about the Contacts API with respect to where it should live (DAS vs WebAppsWG). Although @anssiko is right that historically contacts was in the purview of DAP/DAS, we should consider where we will get maximum implementer input and IPR commitments for the API.

@plehegar, wdty?

[anssiko]

I believe AC review is an appropriate process step during which members are expected to provide feedback if they have concerns with the proposed charter.

FTR, in addition to the supportive historical context https://github.com/w3c/strategy/issues/267#issuecomment-853579925, I see only support signals in https://github.com/w3c/dap-charter/issues/97 and https://github.com/WICG/contact-api/issues/37 for the plan to adopt Contacts Picker API from WICG. I’m not aware of any member concerns with that plan.

Edit: I think it is relevant to point out this WG has received in the past a substantial contribution from Apple using the License Grants from Non-Participants mechanism. I believe this same mechanism is still available should Apple wish to contribute as a non-participant.

[plehegar]

After additional thoughts, we're going to start the AC review of the charter as proposed.

[plehegar]

@hober, can you please confirm asap in the AC review of the DAS charter that Apple would prefer for the Contacts Picker API to be in the Web Apps charter rather than DAS charter (feel free to revise/update your comment before the review end date if other things come up). It's too late to change the charter since it's under review but, since we're also going to send the WebApps charter for review soonish, the sooner we can close the loop on that deliverable, the better.

@anssiko , would the DAS Group opposed to move the deliverable in WebApps? (regarding Intel position, you're free to get it recorded as part of the AC review as well btw).

[reillyeon]

I agree with @anssiko that the Contact Picker API is in scope for this WG but I am unopposed to it being adopted by WebApps if that makes it easier for everyone interested to participate.

[anssiko]

@plehegar, an earlier DAS WG charter states the following in its scope section:

Devices sometimes provide calendar, contacts and other personal information management services. These services are also in scope for this Working Group, but to work on Specifications in that area the group would need to recharter to add new Deliverables.

By rechartering to add this Contacts Picker API deliverable, we are following the expectations set forth earlier.

WebApps WG scope is generic in this regard and it is not clear why contacts work that has happened in DAS WG over the course of 2009-2016 should not continue in the DAS WG.

Given this context, it is reasonable to expect participants who read charter documents carefully to be surprised if this deliverable moves elsewhere.

[plehegar]

@plehegar, an earlier DAS WG charter states the following in its scope section:

Devices sometimes provide calendar, contacts and other personal information management services. These services are also in scope for this Working Group, but to work on Specifications in that area the group would need to recharter to add new Deliverables.

By rechartering to add this Contacts Picker API deliverable, we are following the expectations set forth earlier.

Expectations can change when a new charter is adopted. It's not uncommon to move deliverables between groups. Note also the earlier comment from the APA Working Group was surprised to find the deliverable in the charter.

WebApps WG scope is generic in this regard and it is not clear why contacts work that has happened in DAS WG over the course of 2009-2016 should not continue in the DAS WG.

The clear gain is increased implementer participation in the deliverable.

Given this context, it is reasonable to expect participants who read charter documents carefully to be surprised if this deliverable moves elsewhere.

The point of the AC review is to adjust the charter following feedback, so we're discussing what should be the expectation for the charter document.

[hober]

@hober, can you please confirm asap in the AC review of the DAS charter that Apple would prefer for the Contacts Picker API to be in the Web Apps charter rather than DAS charter (feel free to revise/update your comment before the review end date if other things come up).

We would prefer it to be in Web Apps, yes. Apologies if my comment during the charter review was unclear.

[marcoscaceres]

Pending outcome, I've preemptively sent https://github.com/w3c/webappswg/pull/56

[plehegar]

@marcoscaceres @reillyeon @anssiko , would anyone object to make the Contacts Picker API as a joint deliverable between WebApps and DAS?

[marcoscaceres]

Sounds good to me.

[anssiko]

@plehegar, my belated (back from vacation) sounds good to me. Please let us know if the chairs can be of further help.

[xfq]

Announced: https://www.w3.org/2022/11/das-wg-charter.html