Deprecation is Hard to Do, and We Can Do it Better

[bvandersloot-mozilla]

Session description

Deprecating behavior on the web has to be done sparingly. Removing a behavior from the platform means that some websites that once worked will no longer do so. For some sites and behaviors that may be a good thing, e.g if it improves security or privacy protections provided to the user. However, this needs to be weighed against the impact on existing website deployments that don’t need or merit that protection and the impact on the web ecosystem of removing that behavior. Failing to sufficiently incorporate those website deployments' needs leaves the deprecation paternalistic at best.

One place this tension arises is in the similarity of authentication and tracking to the browser. Privacy protections that rely upon deprecating behavior, like third-party cookies, have had to work around this tension.

In this session we will discuss principles for deciding:

• what behaviors are candidates for deprecation,
• when a deprecation should proceed,
• how to mitigate harm from those deprecations.

Participants are encouraged to bring their own examples that reveal challenges to provide concreteness. The chair will use third party cookie deprecation, storage access, FedCM, navigational tracking, OpenID Connect, and SAML as a starting point and example that they are familiar with

Session goal

Improve consensus around deprecation of web platform behaviors

Additional session chairs (Optional)

No response

Who can attend

Anyone may attend (Default)

IRC channel (Optional)

#unship-it-2024

Other sessions where we should avoid scheduling conflicts (Optional)

#10, #12, #49

Instructions for meeting planners (Optional)

No response

Agenda for the meeting.

5-10 minutes of stage setting, followed by discussion.

Links to calendar

• 2024-09-25, 08:30 - 09:30

Meeting materials

• Slides
• Minutes
• Minutes (initial google doc)

[tpac-breakout-bot]

Thank you for proposing a session!

You may update the session description as needed and at any time before the meeting, but please keep in mind that tooling relies on issue formatting: follow the instructions and leave all headings and other formatting intact in particular. Bots and W3C meeting organizers may also update the description, to fix formatting issues or add links and other relevant information. Please do not revert these changes. Feel free to use comments to raise questions.

Do not expect formal approval; W3C meeting organizers endeavor to schedule all proposed sessions that are in scope for a breakout. Actual scheduling should take place shortly before the meeting.

[RByers]

Oh fascinating topic! FWIW we've tried to keep a bit of a log of interesting Chromium deprecations and lessons learned in our principles of web compatibility document.

[bvandersloot-mozilla]

Slides are available here!

[bvandersloot-mozilla]

Scribing doc: https://docs.google.com/document/d/1DbmE_W5ShymGKCd_aQ8bkfUkDthgK5ToE7evW8adBTQ/edit?usp=sharing

[bvandersloot-mozilla]

Follow up rallying point: whatwg/compat#270

[bvandersloot-mozilla]

The slides contain the primary artifact, as do the minutes.

Thank you Heather for the minutes and thank you all for attending!