DeprecationReportBody using the Reporting API

[brentfulgham]

Request for position on an emerging web specification

• WebKittens who can provide input: Ryosuke Niwa, Chris Dumez, John Wilander.

Information about the spec

• Spec Title: Deprecation Reporting
• Spec URL: https://wicg.github.io/deprecation-reporting/
• GitHub repository: https://wicg.github.io/deprecation-reporting/

Design reviews and vendor positions

• TAG Design Review:

• Mozilla standards-positions issue:

  Mozilla has partially implemented, but no official standards position.

Bugs tracking this feature

• WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=244899
• Radar: rdar://99654496

Anything else we need to know

Deprecation reports indicate that a browser API or feature has been used which is expected to stop working in a future update to the browser. This seems like a reasonable and useful browser feature, and would help us more explicitly surface deprecated features to developers and site owners who may not pay close attention to release notes or development discussions.

[annevk]

@othermaciej could you please expand on the privacy and security concerns?

---

I think an API like this makes sense, but I think it needs some encompassing infrastructure:

1. A set of principles that guide us when it's okay and not okay to remove something from the web platform.
2. Other ways of informing web developers than the console and reports. Perhaps something like https://deprecate.it/ that is not engine-specific.

[karlcow]

Webcompat 💡 hat on. (not a standard position)

I can identify issues as currently defined, but having a way to signal a website that an API will be abandoned in a near future could be very useful for Web developers and may help to avoid some webcompat issues.

To make it slightly more useful, I would think that it would be useful for webdevs to make it possible for the browser to signal when they are using an antique pattern or feature. Let's say old version of flexbox, or linear gradient, document.write, etc. which have to be kept for webcompat reasons (aka not breaking websites), but to tell webdevs that there is a more modern way.

It could become quickly very verbose. So need to figure this out too in a way that would be useful for webdevs.

Risk of tracking with implementation defined-id instead of generic across browsers. also date doesn't seem useful compare to browser versions, but then browser versions reintroduced another form of tracking.

but basically this is the counterpart of @support or blah in window for what is currently supported.

I could see a scenario with a webcompat risk, where the developer of the site, instead of updating the site will signal to its users.

After Browser FOO Version XXX, we will stop supporting it. Please switch to browser BAR.

😭

[karlcow]

status as of today

• About Reporting API
  • Firefox 120 (Not Enabled) about:config for dom.reporting.enabled is false
  • Chrome 120 implemented and usable
  • Safari 17.0 implemented and usable
• About DeprecationReportBody
  • Safari has a stub implementation made by @brentfulgham
  • WPT tests about deprecation reporting
  • Firefox is passing most of the current tests, not Safari, not Chrome. I guess Firefox is activating the Reporting API for the tests.
  • The Draft Community Group Report about this API has been last updated on 28 September 2020. (not much activity).
  • There is a spec issues list. If this was pushed it would require a bit of editing.
  • Discussions at the TPAC 2022 but not sure if there is a clear explanation on how the Deprecation Reporting API would be used. Probably there is more work to do on how this would be practically used by Web devs, more than the use cases that browsers implementers imagine.
  • Privacy issues: There is a privacy issue for the Deprecation Report which doesn't have much, but link to Discuss the privacy of monitoring which is detailing some framework to think about it (unfortunately the discussion mostly revolves around crashes and not deprecation):
    • "allows websites to learn things about the user and the user's environment thats sites currently cannot learn."
    • does it require a user-opt-in or not?
    • does it serve/benefits users? Or in some ways why is it useful to be a standard in the user agent if it's serving only the purpose of the website owners. (not taking position)
    • Basically the work about privacy threat or not has not really been done for this specific type of information.
  • Processing Model: @brentfulgham mentioned that the processing model is not defined.

With all my digging here, I want to take a bit more time reading the content of the spec, and I would like to see real concrete examples on how it has been helpful for web developers in the context of Chrome implementation to better understand.

[karlcow]

In Sentry repo, a pull request for removing by default deprecation warning following some comments:

We had many people reporting that they want to disable the deprecation warnings

They switched to make it optional and not activated by default. I wonder if it was too noisy?