- From: James Rosewell <notifications@github.com>
- Date: Tue, 14 Apr 2020 04:16:50 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/483/613380834@github.com>
In summary further work and consultation is needed to understand the impact and justification for the proposal. At a macro level the W3C needs a more ffective method of engaging with impacted stakeholders. There is also the complex consideration of public trust associated with the providers of different digital services and the impact discrepancies have on a seemingly simple changes. The W3C should pause assessing the proposal until these matters are understood and addressed. **Justification** The proposal should have a clear justification. The explainer and IETF documents cite an [EFF](https://www.eff.org/deeplinks/2013/12/nsa-turns-cookies-and-more-surveillance-beacons) and [Washington Post](https://www.washingtonpost.com/news/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/) article related to Google PERF. The articles make interesting reading, but are biased and sensationalise the Snowden documents. The stakeholder review consists of a limited series of tweets between two Google employees and another person. This is one of a series of proposals being presented to TAG where privacy is used as a justification to trump all other considerations. Given it is not the role of the W3C to pick winners and losers on the web a balanced justification is needed with at least comparable rigour and consultation as the expected engineering specifications and debate. **Impact** The explainer contains a table showing the age of non-securely delivered cookies to support the limitation of lifetime to a session. The underlying data could be used to assess the impact of the proposal. What is the sample size and are there any biases in the sample? How representative is the sample of the web in general? How was the sample collected? This information should be easy to obtain by the proposer and will help the TAG understand how many websites or web sessions might break as a result of the proposal being implemented. 19,000-man years would be wasted if one billion people need to reauthenticate with their favourite websites and spent an average of 10 minutes doing so. This seems like a useful piece of information to inform the TAG assessment. No one would unwittingly wish to degrade or break even 1% of the web. **Trust** This proposal, and others seeking to remove long established features from the web, suggest Google are in some way more trustworthy than others. However consider the following scenarios. - Whenever someone types into their address bar of their web browser a search request is made to their search engine provider (often Google). This happens even when they are entering a URL which isn’t going to result in navigating to the search engine. The search engine will know which website they went onto visit even though the user didn’t intend them to know this. - A link from one web site to another will pass information about the referring page potentially passing information about the users’ preferences. Where Google Analytics is being used to provide web site analytics, often for free, Google will gain access to this information. - In the case of Google the use of the [X-Client-Data header is well documented](https://www.google.com/search?q=X-client-data). Every request for a Google asset including fonts, CSS, JavaScript from Chrome is accompanied with this identifier. Google have successfully entangled themselves into society and come to dominate the web via their control of Chromium and other essential services. The [Google brand is exceptionally well known](https://markets.businessinsider.com/news/stocks/interbrand-top-10-brands-in-the-world-2019-10-1028610273#3-amazon-brand-value-125-million8) and easy for consumers to consent to Google privacy termsin only a small number of places (i.e. installing Android, creating a Google account, using search or accepting privacy policies). Smaller players and new entrants lack the brand presence or convenience of consent that Google almost uniquely benefit from. When a feature is removed it will hurt these smaller players far more than Google. In many cases Google will be forewarned and will have already taken steps to mitigate the impact within their own services. When assessing this, and other proposals to remove features from the web, the W3C must balance the level of consumer trust enjoyed by Google with that which could be reasonably expected for all stakeholders including new entrants. **Consultation** The following paragraph from the explainer deserves highlighting. _“The assumption I'm making here is that developers will not react to public announcements, mailing list threads, blog posts, Lighthouse scores, devtool warnings, or etc. That's been our experience with many deprecations over the years; it is simply difficult to get a message out to a zillion developers.”_ This proposal has been publicly visible on the W3C TAG design review thread for over one month. I appear to be the first person unconnected to Google or the W3C to make a comment. Very sensibly @ylafon has requested external feedback. What is being done to solicit external feedback? Representatives from software vendors like F5, NGINX, HAProxy, Varnish and others would be well place to provide a view on the impact related to load balancing and web performance. Similarly, Content Delivery Networks (CDNs) such a Cloudflare or Akamai could be asked for comment. The accepted norms of public debate and consultation must be followed for this and any other change which removes something from the web. The EU’s introduction of GDPR provides an effective consultation model to learn from. The web browser impacts more lives than GDPR. Robust governance is needed. Given the acknowledged difficulties in consultation and the fact that proper consultation will take time the W3C should pause the proposal until these matters are addressed irrespective of the technical merits or otherwise of the proposal. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/483#issuecomment-613380834
Received on Tuesday, 14 April 2020 11:17:04 UTC