w3c/htmlwg

HTML Review Draft — Published 18 January 2021: review tracker

Closed this issue · 10 comments

siusin commented

This is a review tracker of HTML Review Draft — Published 18 January 2021.

Requested

Important Changes between Jan 2020 and Jan 2021

Accessibility?

I18N?

Security & Privacy?

Architecture?

plehegar commented

whatwg/html#6478 is also raising concerns

samuelweiler commented

In whatwg/html#6933 (comment), I requested a warning around references to the Reporting API. Here is proposed language for that:

Notice: the (above / below) functionality hooks into the Reporting API, which is a not-yet-standardized
work in progress at W3C and which has unresolved privacy issues. In particular, some are concerned
that the Reporting API functionality violates the W3C's hierarchy of constituencies by exposing users
to potential harms while the primary beneficiaries of the API are websites. Implementors are
encouraged to follow these issues and be aware that this functionality could change or be removed as
those discussions progress.

plehegar commented

background: this is part of a proposed plan based on a conversation between PING chairs/TC and @plehegar:
[[

  • PING will draft warning language. If it makes conclusions re: the reporting API (and, IMHO, it does not need to - it need only refer to 'unresolved concerns about privacy et. al., which might require breaking changes to resolve') @plehegar will want to run it by WebPerf.
  • @plehegar will sort out the mechanics for how to display that on the snapshots.
  • @plehegar try to get the HTML WG engaged on the discussion re: adding sec/priv sections to these docs, meaning the charter issues (and possibly/probably the doc issues) are still open.
    ]]

cc @LJWatson @hober @sideshowbarker @siusin

plehegar commented

In particular, some are concerned
that the Reporting API functionality violates the W3C's hierarchy of constituencies by exposing users
to potential harms while the primary beneficiaries of the API are websites.

Imho, I don't think we should be specific about concerns related to the Reporting API. If there is an issue opened against the Reporting API related to this concern, we could link to it.

So, how about:

Notice: the (above / below) functionality hooks into the Reporting API, which is a not-yet-standardized
work in progress at W3C and which has unresolved privacy issues (e.g. @@link to specific issues?). Implementors are
encouraged to follow these issues and be aware that this functionality could change or be removed as
those discussions progress.

cc @yoavweiss

samuelweiler commented

Fine with me. @pes10k ?

pes10k commented

a-ok with me too

yoavweiss commented

I'd like to know what specific issues are involved here before adding random warnings to HTML. Looking through Reporting's issues, I found w3c/reporting#168 and w3c/reporting#194

w3c/reporting#194 seems reasonable and the concerns raised there is that delayed reporting could reveal information about the user (e.g. show that they changed networks). But, the solution to this issue is simply to avoid sending delayed reports or condition them e.g. on lack of network changes, and most likely won't involve an API change.

w3c/reporting#168 OTOH is an issue where @pes10k argues that Reporting is somehow special and requires a permission (contrary to many other web platform features that traditionally performed a similar role and do not require permissions: image requests on dismissal events, beacon, <a ping> and Fetch keep-alive are a few that come to mind).
The thread includes a lot of evidence supporting Reporting's role in helping provide users with a more secure web, but it seems like nothing short of accepting @pes10k's premise and requirements would be sufficient and no amount of evidence would be convincing enough. As such, I don't see why we need to litter the HTML spec with pointers to that discussion.

Notice: the (above / below) functionality hooks into the Reporting API, which is a not-yet-standardized
work in progress at W3C and which has unresolved privacy issues (e.g. @@link to specific issues?).

I'd object to calling w3c/reporting#168 "unresolved privacy issues". They seem to be "unsubstantiated privacy concerns" at best.

samuelweiler commented

@yoavweiss Both 168 and 194 are in scope. You might well be right that the ultimate conclusion of 168 will be that @pes10k is "in the rough". In the meantime, though, that discussion looks unresolved. And there's also 194.

Would you prefer we merely say "unresolved discussions" without even characterizing them as "privacy"?

[Adding merely as context: Reporting API is pre-CR. The doc has been around since 2016; the last WD was published in 2018. The doc is in the WebPerf WG, and yoavweiss is one of the WebPerf co-chairs.]

yoavweiss commented

Either "unresolved discussions" or "unresolved privacy-related discussions" works for me. (assuming that the HTML editors are fine with this)

  • 👍2
plehegar commented

I believe the compromise for the warning note is:

Notice: the (above / below) functionality hooks into the Reporting API, which is a not-yet-standardized
work in progress at W3C and which has unresolved privacy-related discussions. Implementors are
encouraged to follow these discussions and be aware that this functionality could change or be removed as
those discussions progress.

(I added a link to the open privacy related issues in the reporting repo)

  • 👍1