Information

Deprecation is Hard to Do, and We Can Do it Better
  • Past
  • Confirmed
  • Breakout Sessions

Meeting

Event details

Date:
– Pacific Daylight Time
Status:
Confirmed
Location:
-1 Lower Level - Catalina 7
Participants:
Rachel Andrew, Ashima Arora, Panos Astithas, Paulo Avelar, Daniel Beck, Alan Buxey, Brian Campbell, Tim Cappalli, Florent Castelli, Tantek Çelik, Ari Chivukula, Brian Daugherty, Domenic Denicola, Heather Flanagan, George Fletcher, Chris Fredrickson, Megan Gardner, Sam Goto, Yi Gu, Maxime Guerreiro, Dominique Hazaël-Massieux, Johann Hofmann, Tim Huang, Neha K, Marijn Kruisselbrink, Camille Lamy, Philippe Le Hegaret, Sandor Major, Etienne Noël, Mark Nottingham, Aaron Parecki, Nicolas Pena Moreno, Zainab Rizvi, Wendy Seltzer, Aaron Selya, Frank Somich, Austin Sullivan, Zachary Tan, Mike Taylor, Vitalii Tomkiv, Kadir Topal, Zacharias Törnblom, Benjamin VanderSloot, Lukas Weichselbaum, Anna Weine, Mike West, Greg Whitworth, Noreen Whysel, Chris Wilson, Kristina Yasuda, Emma Zuehlcke
Big meeting:
TPAC 2024 (Calendar)

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

Agenda

Chairs:
Benjamin VanderSloot

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

Goal(s):
Improve consensus around deprecation of web platform behaviors

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

Materials:

Track(s):

  • Standards

Minutes

 Read minutes

Export options

Personal Links

Please log in to export this event with all the information you have access to.

Public Links

The following links do not contain any sensitive information and can be shared publicly.

Feedback

Report feedback and issues on GitHub.