Spec should not specify behavior of other specs in Editors Draft status (i.e., Reporting API)

[pes10k]

(this issue was the result of a PING privacy review: w3cping/privacy-request#47)

The draft currently defines interactions with the Reporting API which is currently in Editors Draft status, has open privacy issues on it, and has not had wide or horizontal review yet.

I do not think the HTML spec should define interactions with the Reporting API, or other proposals in a similar status, for several reasons (I'm mentioning Reporting API below bc its the one i noticed, but I think the following points are general):

• coupling the HTML spec to a draft Reporting API proposal constraints the ability to address privacy (and other) issues in the Reporting API when it comes up for review
• without at least some surrounding annotation, it'd give the reader of the HTML living standard the impression that the behavior in the Reporting API proposal is in a similar status as the HTML spec (living standard, and so unlikely to make breaking changes, etc), when that is not the case (at least in the eyes of W3C process)

Again this point may apply to other specs and proposals referenced in the HTML Standard. If so, i think this concern applies equally there too

[domenic]

Sorry, this is a decision the editors have generally disagreed with you on. We think clear interactions with other specs is very important, and if other specs want to work with us to avoid monkeypatching, we welcome and encourage that, regardless of the formal status of that specification.

Integrations are still generally subject to the multi-implementer interest rule in the WHATWG working mode, but there is definitely multiple implementer interest in COOP and COEP reporting, so we have no plans to remove that integration.

I'll close this, since it's not going to change, but we're happy to continue discussing in the closed thread.

[plehegar]

The draft currently defines interactions with the Reporting API which is currently in Editors Draft status, has open privacy issues on it, and has not had wide or horizontal review yet.

Note that Reporting API is a Working Draft: https://www.w3.org/TR/reporting/

[samuelweiler]

@domenic

... We think clear interactions with other specs is very important, and if other specs want to work with us to avoid monkeypatching, we welcome and encourage that, regardless of the formal status of that specification.

I concur.

I also think @pes10k raises a good point about the Reporting API being problematic, and I suspect there is merit to his claim that breaking changes will be needed to resolve those problems.

Would the HTML editors be willing to mark references to the Reporting API (and I'm not sure if there are ones beyond the cited section) with a warning (above @pes10k suggests "some surrounding annotation")? e.g. "n.b. The Reporting API has privacy issues. Exercise caution before implementing the below, and be aware that breaking changes might be needed to resolve the open privacy issues." I'm not wedded to the wording; if you don't like it, suggest something else.

[domenic]

No, I think it's best for you to pursue such changes in the reporting API itself, if you wish. HTML is not the place to make statements about which groups are in favor or not in favor of other specs.

[samuelweiler]

No, I think it's best for you to pursue such changes in the reporting API itself, if you wish. HTML is not the place to make statements about which groups are in favor or not in favor of other specs.

Changes are being pursed in the Reporting API. As you know, that spec is in the W3C, where we have spec maturity levels, the first notable one of which this spec hasn't even reached. And where blocking privacy issues have been filed.

Setting that aside, your response re: a warning in the HTML spec feels non-intuitive to me.

Including the interactions in the HTML spec seems like an implicit endorsement (and possibly also a claim about expected stability). If I asked HTML to include interactions with some other terrible API, it would seem reasonable for you to push back - because you don't want to endorse my bad idea - or proceed with a warning, as I have requested in this case. Or would HTML include the interactions with my terrible API without comment?

[domenic]

"terrible API" is a value judgment, which we (the editors) have not made with regard to the reporting API.

The judgment we have made, is that the particular integration here---the link to the "queue" algorithm in the reporting API---has multi-implementer interest. So we'll be including it, without commentary, like we do for all other links in the document.

[annevk]

Can someone elaborate on the open privacy issues with the Reporting API? Now it's document-lifetime bound, how is it any different from fetch()?

[pes10k]

Sure, happy to. I dont mean this to be a comprehensive list (it might be, its just been a bit since i've read the reporting API closely) but here are a couple of concerns (some are with Reporting API itself, some are with :

1. it is, at root, inappropriate to add APIs to the browser that are designed (in full or in part) to allow sites to offload debugging and monitoring costs onto uncompensated, unconsenting users. Making sure example.org is working correctly is example.org's responsibility, not the visitors to example.org. Its rude and inconsiderate to web users for sites to help themselves to user resources like this, and browsers shouldn't be adding APIs explicitly intended to help sites do so.
2. Most of the discussed use of Reporting API is user hostile and / or comes with significant privacy risks. These reports rely on self-monitoring capabilities that are not available to fetch in all cases
   a. Intervention reporting would have the browser tell the site when the browser has protected the user from the site. For cases where the site would be getting useful information, this is at least sometimes the browser siding with the site against the user
   b. For network error logging / network reporting, there are many cases (that i've raised over there) where these reports will leak the use of other privacy protecting tools, particularly DNS filters and other between-the-client-and-the-server protections. Partitioning these reports only addresses some of these cases

[annevk]

Thanks.

I disagree with 1. Remote debugging is a necessity of sorts for complicated applications.

I agree with NEL being bad (haven't looked at Intervention reporting), also in terms of privacy, but there are other uses of the Reporting API, such as COOP/COEP/CSP. And it's not even clear NEL can use the Reporting API in its current state, though I suppose some parts are reusable, such as the format.

[pes10k]

I disagree with 1. Remote debugging is a necessity of sorts for complicated applications.

Whether or not this is correct, thats not what the concern is around the Reporting API.

It can (and probably is) both be the case that:
i) remote debugging is important and necessary, and
ii) that it is not appropriate for sites to help themselves to users' resources to do that remote debugging without consent, notification and / or compensation.

One of the initial bugs issues I filed (w3c/reporting#168) tries to cut this knot specifically.

[annevk]

I think if there's a path to enable i) through fetch() (and there is) and there is a path to enable it through an opt-in API, sites will opt for using the former.

I don't agree with ii). As Artur noted in that thread it's a trade-off between individuals and all users of the site.

In any event, that issue is probably best used to track this.