Charter Review

The TAG endorses work on device APIs and the effort to get patent protection even for single-engine features, but we have several concerns with the way the DAS WG is being chartered to do that.

• We're concerned to see the Chromium-only Accelerometer, Gyroscope, and Orientation Sensor specifications in the charter, now that the Device Orientation and Motion spec is in Baseline. It makes sense to maintain non-consensus specifications while websites switch over to equivalent consensus APIs, but the charter should commit to only adding new features to the consensus versions. If there's not enough consensus on the new features to incorporate them into the core Device Orientation and Motion spec, this WG could develop an extension specification that allows websites to mostly use the Baseline feature, with a few engine-specific extensions.

• We want to ensure that the other specifications fill clear user needs and are making appropriate tradeoffs between those user needs and any potential abuse of the APIs. In many WGs, we can rely on all 3 browser engines to check this, but since this WG does not currently include participation from all major browser engines, we're more concerned here. Could you add this goal to the charter for each of the specifications in that class? We see, for example, https://github.com/w3c/vibration/issues/45 to do this for Vibration, but it would be good to use the charter to ensure it gets done.

• The Vibration Council recommended that "the WG document the plan [to ship in multiple major browser engines] it thinks is best, whether or not that plan includes implementation in multiple browser engines, and a compelling rationale to help any reviewers decide whether the plan is acceptable." We couldn't find such a plan in this rechartering effort, and we encourage the WG to write such plans for each single-engine specification, in order to head off this possible formal objection.

• We would like the WG to find a way to signal the expected support level for each specification. There's some discomfort on the TAG with using the same spec status—Candidate Recommendation—for all of:

  • deprecated specs that are being maintained while websites migrate to a consensus replacement;
  • features that are stable in one engine but opposed by the others;
  • "living" consensus specs that never intend to advance to Recommendation; and
  • consensus specs that are intended to advance to Recommendation.

  At the same time, we recognize that this is the only status the Process defines for patent protection of these kinds of specifications. At a minimum, each document's support level should be in its SotD section, but ideally the WG would find a way to ensure that developers reading a specification can tell at a glance which kind of document they're reading.

• We're concerned by the appearance of Web Serial in the Tentative Deliverables. At least Mozilla seems inclined to start implementing that API, and we want it to live in a WG that all implementers are comfortable joining, to ensure that all of their potential concerns about engine/platform capabilities, privacy, and security can be easily raised. That said, its presence in this charter doesn't prevent it from being adopted by another WG instead.

The following concerns don't affect the charter, but we want to flag a few issues that are likely to come up in future design reviews for the individual specifications:

• We will always look more critically at specifications developed by WGs without members from all major browser engines, since we want there to be One Web in the long run, and the fact that some browsers decide not to implement, inherently means there are concerns with the design. The WG should be prepared to explain how the non-members' critical feedback has been sought and considered.
• The Generic Sensor architecture seems overcomplicated overall. In reviews of features that use it, we'd appreciate some justification for why that architecture is better than defining APIs in a single layer, as Device Orientation and Motion does.
• Are the signals in the Battery API still the right ones to help websites help users achieve their goals? Would a "please reduce power use" signal be sufficient, with the UA in charge of deciding how the precise battery level and charging state contribute to that signal?

Thank you for your review feedback. The group and its participants have made available the following resources that may be helpful:

• Designing A Generic Sensor API For The Web Platform article for context setting by the initial editor
• Demos for Generic Sensor API for a "show, don't tell" approach to user needs

We're pleased to see this review resolved with a green light and will take all the feedback into consideration.

Thank you again for your insights on behalf of the group.

We're pleased to see this review resolved with a green light and will take all the feedback into consideration.

Please note it’s not “resolved with a green light”. The TAG has raised serious concerns with the DAS Charter. We are expect to see those concerns addressed.

To address the concerns, the group has delivered the following:

As for the Generic Sensor API & Accelerometer, Gyroscope, and Orientation Sensor, the group has published an explainer document, a use cases document, and demos that address the user needs and use cases concerns for these deliverables. Furthermore, Rick Waldon, an industry-recognised sensor tech expert, and a W3C Invited Expert, has explained the benefits of the Generic Sensor API architecture in this article.

As for the Vibration API, the group’s plan of record is to use the Security IG's newly published threat modeling guide as a framework to understand the privacy and security concerns, and appropriate mitigations.

As for the Battery Status API, the group has produced an explainer for a higher-level battery signal and continues to discuss new API shapes and use cases for this feature.

As noted by @plehegar, the above doesn't address the TAGs concerns: We explicitly asked that you clarify things requested on a point by point basis in the Charter so the W3C Membership has visibility into what the WG is doing; Please also address the recommendations from the Vibration Council.

If you'd like guidance on how to do that, we can set up a call.

Also, having spoken with @simoneonofri, the threat modeling guide is still in very early development. It's barely been road-tested, nor reviewed by the TAG, so merely citing it is not addressing the any concerns.

the group has produced an explainer for a higher-level battery signal and continues to discuss new API shapes and use cases for this feature.

If you'd like the TAG to review that, please file a separate review request. However, it doesn't address any concerns (just raises more of them).

Looking at the minutes, it is unclear if Marcos is talking on behalf of the TAG. Per the minutes use cases and explainers were wanted, thus delivered.

The group will work with the Team on charter text adjustments. Concrete text proposals from the TAG would help avoid misinterpretation and back-and-forths. Thank you for your contributions.

Looking at the minutes, it is unclear if Marcos is talking on behalf of the TAG.

It's a TAG meeting, so talking as a TAG member; Similarly if you are referring to this issue, I am speaking as a member of the TAG.

Per the minutes use cases and explainers were wanted, thus delivered.

The minutes are helpful to understand context, but the minutes are not what you should be reading for the review feedback (they are missing a lot of TAG internal discussion that happens elsewhere as we iterate over the final review). We iterated over the final text elsewhere.

The group will work with the Team on charter text adjustments. Concrete text proposals from the TAG would help avoid misinterpretation and back-and-forths. Thank you for your contributions.

You literally asking the TAG to do the work of a Chair for you (i.e., charter updates are your responsibility as a WG Chair). Let me reming you of the "Role of the Group Chair":

Develops Group charter together with the Staff Contact.

Please work with DAS's Chartering Facilitator to address the concerns.

The TAG is happy to make time to clarify things if the DAS chairs and facilitator needs (either as text or on a call), but we are not your Chartering Facilitator.

I am currently revising the draft charter based on the TAG's feedback and will provide a response to the TAG's concerns once that is complete.

Hi everyone,

Threat Modeling Guide is a draft although, in general, creating a threat model is a practice described in the Security and Privacy Questionnaire, and the guide is intended to help with this concept.

Threat Modeling can be used to understand the various threats, including potentially even at the use-case level (e.g., Legitimate Misuse), so that you have more information to assess the situation.

In any case, since we are testing it with groups, we have the Threat Modeling Community Group, where you can propose your own “what are we building” to discuss together.