WebPerf charter review

[caribouW3]

New charter proposal, reviewers please take note.

Charter Review

https://www.w3.org/2020/10/webperf.html

What kind of charter is this? Check the relevant box / remove irrelevant branches.

• Existing

• Existing WG recharter
• Existing IG recharter
• If this is a charter extension or revision, link a diff from previous charter, and any issue discussion:

https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2018%2F09%2Fwebperf%2F&doc2=https%3A%2F%2Fwww.w3.org%2F2020%2F10%2Fwebperf.html

Horizontal Reviews (intended to be checked only by horizontal reviewers when they are satisfied with the charter)

• Accessibility (a11y)
• Internationalization (i18n)
• Privacy
• Security

Communities suggested for outreach:

Known or potential areas of concern?:
none

Where would charter proponents like to see issues raised? (github preferred, email, ...)
email or GH.

Anything else we should think about as we review?
Process/Patent 2020 charter style?

[himorin]

I wonder why this draft uses http for W3C icon at http://www.w3.org/Icons/w3c_home

[caribouW3]

fixed 2 occurences of http -> https, thx.

[samuelweiler]

Where would charter proponents like to see issues raised? (github preferred, email, ...)
email or GH.

Absent a specified GH repo, I'm raising issues here.

[caribouW3]

In my understanding "GH" means "Comments in this issue", creating a repo for each new charter would be a terrible idea.

[samuelweiler]

In my understanding "GH" means "Comments in this issue", creating a repo for each new charter would be a terrible idea.

Terrible idea or not, that is what people have done for some charters. For example: https://github.com/w3c/dap-charter and https://github.com/w3c/audiobooks-wg-charter. And some groups put their charters in the WG or IG's own general-purpose repo, presumably so that non-team can more easily edit them. Again as examples: https://github.com/w3cping/administrivia/blob/master/charter-draft.htm
https://github.com/w3c/webappsec/tree/master/admin

Thanks for clarifying what you want for this one.

[samuelweiler]

Link to the GitHub repos (from the sentence "This group primarily conducts its technical work in its public repositories.") is broken (or at least not publicly readable): https://github.com/orgs/w3c/teams/web-performance/repositories

[michael-n-cooper]

No comments from APA; over to @brewerj to complete accessibility horizontal review.

[himorin]

No comment from i18n.

[samuelweiler]

I appreciate the work WebPerf has done on Device Memory, moving to a Client Hints approach.

I am concerned, though, about the potential for the various timing and reporting functions, including the Network Error Logging API and the Reporting API, to leak sensitive information. I wonder which of the various timing and reporting functions could be achieved in a more privacy-preserving way by reporting them through a telemetry system such as Prio. What analysis has the WG done of which pieces of these APIs might be reasonably reported with something like Prio?

Absent requiring privacy-preserving reporting, I would be fine with continuing to specify them exclusively for use in test farms or when enabled for a specific debugging session. I have seen this WG be reluctant to include a requirement to hide these APIs behind a switch - e.g. during PING's review of High Resolution Time. Arguably this is in violation of the requirement in section 1.2 of both the current charter and this draft charter. As a member of the the broader community (v. just this WG), I want to see a "red letter warning" at the beginning of each of these specs, saying that they should only be enabled in test farms or for limited durations for a specific debugging, after explicit user consent.

Lastly, I see that this draft charter does not appear to have started from our current template. The Strategy team has been discussing whether to require that.

Flagging as both privacy- and security- since the leaks could impact both.

[caribouW3]

Hi @samuelweiler ,

About your first suggestion, services like Prio are proposing an aggregation through anonymizing/encrypting servers. This use case has not been discussed in the WG (maybe it has been incubated somewhere else).

Your second point is specifically about how the APIs are used and exposed. There seems to be a misunderstanding of what some of the APIs are for (test farms is certainly not the exclusive/main use case).
Specific issues for each API can be worked on during horizontal reviews of these specifications and adequate recommendations like hiding the API or getting user consent are part of the items to be covered in those reviews. The "red letter warning" that you are proposing seems too broad to be implemented on all specifications. It might even be counter-productive if understood as a way to dismiss review of more specific issues.

I could not find any disagreement on the resolution of an issue related to the obligation mentioned in section 1.2 for the HR Time specification. The current wording of section 1.2 seems sufficient to describe the importance of privacy and security in the development of these APIs ; text about the good usage of the APIs does not fit well in the charter, but rather in the specifications themselves.

[samuelweiler]

About your first suggestion, services like Prio are proposing an aggregation through anonymizing/encrypting servers. This use case has not been discussed in the WG (maybe it has been incubated somewhere else).

Would the WG like to have its charter expanded to include this work?

Your second point is specifically about how the APIs are used and exposed. There seems to be a misunderstanding of what some of the APIs are for (test farms is certainly not the exclusive/main use case).

Perhaps. What do you see at the main use case?

[caribouW3]

• I think it's a bit premature for the WG, but could be discussed/incubated somewhere else.

• There is a significant need in web applications themselves, e.g. thanks to HR Time an application can precisely synchronize elements like animations, audio, etc. It's not just for benchmarking and performance analysis.

[yoavweiss]

Perhaps. What do you see at the main use case?

You mentioned both the Reporting API and NEL. For both of them, their main use-cases are about getting reports from the wild, about failures related to performance, the site's development, security feature deployments, etc.

For the Reporting API, it's currently used for reports on CSP, Permission Policy and Document Policy violations, COOP/COEP issues, deprecated feature use, UA interventions, crashes and more.
Its purpose is to help developers catch functionality regressions with their site when deploying code to their users. Those regressions are not something you can always catch in the lab (as users are typically exercising more parts of your site than you testing infrastructure does, with a variety of interactions and devices the lab can't match).
I suspect that if the API was in fact leaking sensitive user information, the security community and WebAppSecWG in particular (that are heavily relying on the API) would have told us by now.

As for Network-Error-Logging, its goal is to provide reports of network issues in the wild, and help developers understand them and fix them (e.g. server configuration issues that only impact certain regions, due to DNS load balancing, CDN use, etc). Again, not something lab testing could catch.

[samuelweiler]

@caribouW3 writes:

...services like Prio are proposing an aggregation through anonymizing/encrypting servers. This use case has not been discussed in the WG ...

I mention Prio not as a use case, but as a tool to use in achieving the WG's ends (while still taking care of users).

• There is a significant need in web applications themselves, e.g. thanks to HR Time an application can precisely synchronize elements like animations, audio, etc. It's not just for benchmarking and performance analysis.

That speaks to HR Time. Would you like to say anything about the others?

FYI, I'm reviewing the discussion in w3c/reporting#168, w3c/reporting#169, w3c/reporting#158, WICG/crash-reporting#1, WICG/deprecation-reporting#1, WICG/intervention-reporting#1, and WICG/crash-reporting#7. I'll have more to say later.

[caribouW3]

• WRT Prio: After my first answer to your comment, you asked "Would the WG like to have its charter expanded to include this work?" (i.e. privacy-oriented aggregation). Defining an interface to this kind of service is not in scope of any of the current WG deliverables and more discussion (incubation ?) is needed before it could become a WG deliverable.

• Your second proposal was to strengthen the privacy requirements in section 1.2 of the charter, with a general obligation for all the deliverables. Every specification is bound to have an horizontal review, and explicit privacy/security considerations. I'm not seeing how a general statement, in the charter, limiting the applicability of those specifications to test environments, could help resolving the privacy issues. I explained the use cases for HR Time, Yoav detailed the use cases for Reporting and NEL. Resolving the potential problems for each specification, in the issues you mentioned and other issues, seems to be the right way.

[swickr]

editorial nit: in Section 2.1 only two of the instances of the previous charter citations are hyperlinked. I suggest that the rest of the previous charter URIs be made links as well.

[caribouW3]

Fixed, and all links checked too.

[wseltzer]

It sounds as though privacy and security review have identified issues for the group's consideration, suggesting that the WG either incubate and adopt privacy-preserving reporting mechanisms or make reporting opt-in and limited to short intervals for specific debugging. Some of those issues might prompt objections from members in response to AC review request of the charter or advancement of specific individual specifications.

[caribouW3]

Yes, this kind of issues against some aspects of a spec may trigger objections on the basis of identified privacy-preserving mechanisms that should be in place but are not mandated in the said spec. This belongs to the W3C Process and not specific to this charter nor these specifications. Is there a history of past objections wrt this group's specifications that would justify a stronger requirement? I don't believe so.

[yoavweiss]

Is this a concern raised by Members or Groups? If so, that was not clear.

[samuelweiler]

Is this a concern raised by Members or Groups? If so, that was not clear.

Why does it matter? If the concern were being raised by a someone not associated with a member or even someone anonymous, would we should still consider it.

Some of the underlying issues - filed against individual specs - are cited above. All of those were presumably filed by people, not automata. I think all of these people are associated with members, though I have not looked closely. Some of those comments are explicitly stated as organizational concerns. Others comments are not specific about that, though I'm sure some of those are supported by the commenter's org. If it helps, the Privacy IG is interested in these concerns. But, in any case, they were (again, presumptively) filed by people.

[samuelweiler]

Yes, this kind of issues against some aspects of a spec may trigger objections on the basis of identified privacy-preserving mechanisms that should be in place but are not mandated in the said spec. This belongs to the W3C Process and not specific to this charter nor these specifications. Is there a history of past objections wrt this group's specifications that would justify a stronger requirement? I don't believe so.

There is a history around the high res time spec as well as issues on other specs, many of which remain open.

[yoavweiss]

Why does it matter? If the concern were being raised by a someone not associated with a member or even someone anonymous, would we should still consider it.

The Process provides us with clear tools to handle concerns from Groups and Members as part of chartering. The same is not true for anonymous and vague concerns.

I'm reviewing the discussion in w3c/reporting#168,

The issue seems to be opened by a PING person, based on an opinion that the API should be behind a user opt-in without tying it to a particular threat, as it is "not useful to users". The rebuttal, from a WebAppSec person, outlines how lack of a reporting API would result in many more cross-site leaks, saying "I feel like having reporting available on an opt-in basis would likely be a net loss for user privacy and security."

That doesn't seem to me like something that should prevent this charter from moving forward.

w3c/reporting#169,

The issues raised were resolved by:

• Limiting the reporting API to the scope of the Document
• Splitting out features that rely on Reporting to their own incubation repos

w3c/reporting#158,

comments were addressed and the issue resolved.

WICG/crash-reporting#1, WICG/deprecation-reporting#1, WICG/intervention-reporting#1, and WICG/crash-reporting#7

Those WICG issues seem wildly out-of-scope for this charter discussion. Are they not?

There is a history around the high res time spec

Can you clarify what you mean by that?

[arturjanc]

On the narrow point about privacy-preserving reporting alternatives, I added some comments in w3c/reporting#168.