WICG / client-hints-infrastructure

Specification for the Client Hints infrastructure - privacy preserving proactive content negotiation
https://wicg.github.io/client-hints-infrastructure
Other
61 stars 26 forks source link

Client Hint Reliability: Alignment with TAG Ethical Web Principles #31

Open jwrosewell opened 4 years ago

jwrosewell commented 4 years ago

The complexity introduced increases the learning curve for "do-it-yourself" or "individual" developers' when improving performance or optimising their websites. This does not seem to align with Ethical Web Principle "The web must enhance individuals' control and power".

There is a similar concern regarding Ethical Web Principle "The web is for all people". People "on low bandwidth networks and low specification equipment" will be particularly disadvantaged if website publishers lack the skills or time to modify their websites. The proposal risks essential services needed by economically disadvantaged people becoming unavailable. The justification for such impacts must therefore be very high indeed.

In time it will also be important to ensure broad W3C membership support to comply with Ethical Web Principle "The web is multi-browser, multi-OS and multi-device". A route to making this a mandatory standard for all browsers is needed to avoid encouraging "the creation of websites that work only in one browser".

Overall, there are a set of policy and governance questions to resolve prior to any further engineering work being performed on this set of proposals.

cwilso commented 4 years ago

(This response is my own personal opinion; it should not be read as the opinion of my employer, nor as the opinion of the Advisory Board.)

I'm not sure exactly what you mean. By the way I read your initial logic, any additional complexity would be decreasing individuals' control and power - when adding features like this is the exact opposite, as it increases their control over the platform. This proposal adds complexity for those who need it, but can be ignored if you don't, or don't wish to learn about it.

Similarly, it would appear that people on low bandwidth networks and low specification equipment are ALREADY at a disadvantage, and website publishers tend to abandon them - in part because they lack the API tools (such as client hints) to address these scenarios effectively. The goal in proposals such as this is to enable them to fix that.

But finally, and most importantly, I would point out that during its entire history, the Web has never had "mandatory standards" - the platform has grown as an interoperable agreement across many vendors; there is no body that CAN "mandate" any particular support. Indeed, as the Web platform grows, it needs to continue to interoperate across browsers, OSes and devices; that is a core principle, and frankly, the principal reason behind my own 27-year career in it.

As an incubation, there is little governance here, because this is not (at this point) an official standard of the W3C, or even on the track to become so (it would need to be a Recommendation-track deliverable of a Working Group).

jwrosewell commented 4 years ago

@cwilso the issue relates specifically to the Client Hint Reliability proposal (the “Proposal”) added recently to the repository rather than Client Hints more broadly.

When a new feature is added and an old one deprecated developers will need to perform work. Some of those developers work in teams and are highly skilled. Others work as individuals, have limited time, and are less skilled. My initial comment relates to these latter group of developers who are recognised in the Ethical Web Principles. The following is the paragraph related to “The web must enhance individuals’ control and power” with emphasis added.

“We recognize that web technologies can be used by developers to manipulate people, complicate isolation and encourage addictive behaviours. We recognize these risks and seek to mitigate against them when creating these technologies and platforms. We will therefore favour a decentralized web architecture that minimizes single points of failure and single points of control. We will also build Web technologies for individual developers as well for developers at large companies and organizations. The web should enable do-it-yourself developers.”

The W3C have advocated secure contexts for more than five years. Search engines have been prioritising performance for a decade. Therefore, all developers, no matter how skilled, must consider security and performance if their work is going to be successful. They are not optional.

The Proposal adds complexity that could be avoided if all the information were provided to the website on the very first request via new HTTP headers or via the existing User-Agent HTTP field value. As such the Proposal is not compatible with Ethical Web Principle “The web must enhance individuals’ control and power”.

I’m not sure that website publishers tend to abandon people on “low bandwidth networks and low specification equipment”. For many website publishers it would not be in their interests to do so. I do however observe that an increasing use of JavaScript has a tendency to degrade performance.

I set my design and engineering team the challenge of creating a website with a focus on performance on all devices without using JavaScript to see what would be possible. The results can be seen on Pagespeed. The solution makes extensive use of server-side optimisation techniques. I provide free and open source solutions to enable server-side developers to support these techniques.

If a new method is needed, then developers will be required to invest their time in making changes to support them. Given the 10s of millions of websites involved the cost and lost opportunity in developing more meaningful features will be vast. If those developers do not make the necessary changes their existing solutions might break. This is an import consideration for the Proposal at the conceptual stage.

The Proposal will need to be supported by all browser vendors to avoid fragmenting the web. This is fundamental to Ethical Web Principle "The web is multi-browser, multi-OS and multi-device”. The following is the relevant paragraph with emphasis added.

“We will not create web technologies that encourage the creation of websites that work only in one browser. We expect that content provided by accessing a URL should yield a thematically consistent experience when the user is accessing it from different devices. The constant competition and variety of choices for our users that come from having multiple interoperable implementations means the web ecosystem is constantly improving.”

If there is no method to mandate support, then a consensus-based approach requires all browser vendors to indicate they will adopt the Proposal because the Proposal will encourage the creation of websites that only work in the browsers that support it. Established norms for technical standards governance place the responsibility for gaining consensus on the proposer.

You recognise the importance of this approach to governance in your email of 7th July 2020. Many stakeholders recognise the need for the W3C to reconsider it’s position on governance in their email of 13th July. I’m a co-signatory.

A proposal initiated from a large participant is viewed significantly differently by commentators than if the same proposal originated from a smaller participant. Experiments and consultations from large participants shift share prices. See this chart for performance marketing company Criteo following the announcement of Privacy Sandbox.

Share Price

These are important realities. Perhaps the incubation process is in need of an upgrade.

Devyn404 commented 4 years ago

Why the shit aren't I receiving what was promised then???

On Wed, Jul 15, 2020, 11:59 AM James Rosewell notifications@github.com wrote:

@cwilso https://github.com/cwilso the issue relates specifically to the Client Hint Reliability proposal (the “Proposal”) added recently to the repository rather than Client Hints more broadly.

When a new feature is added and an old one deprecated developers will need to perform work. Some of those developers work in teams and are highly skilled. Others work as individuals, have limited time, and are less skilled. My initial comment relates to these latter group of developers who are recognised in the Ethical Web Principles. The following is the paragraph related to “The web must enhance individuals’ control and power” with emphasis added.

“We recognize that web technologies can be used by developers to manipulate people, complicate isolation and encourage addictive behaviours. We recognize these risks and seek to mitigate against them when creating these technologies and platforms. We will therefore favour a decentralized web architecture that minimizes single points of failure and single points of control. We will also build Web technologies for individual developers as well for developers at large companies and organizations. The web should enable do-it-yourself developers.”

The W3C have advocated secure contexts for more than five years. Search engines have been prioritising performance for a decade. Therefore, all developers, no matter how skilled, must consider security and performance if their work is going to be successful. They are not optional.

The Proposal adds complexity that could be avoided if all the information were provided to the website on the very first request via new HTTP headers or via the existing User-Agent HTTP field value. As such the Proposal is not compatible with Ethical Web Principle “The web must enhance individuals’ control and power”.

I’m not sure that website publishers tend to abandon people on “low bandwidth networks and low specification equipment”. For many website publishers it would not be in their interests to do so. I do however observe that an increasing use of JavaScript has a tendency to degrade performance.

I set my design and engineering team the challenge of creating a website with a focus on performance on all devices without using JavaScript to see what would be possible. The results can be seen on Pagespeed https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.51degrees.com%2F. The solution makes extensive use of server-side optimisation techniques. I provide free and open source solutions to enable server-side developers to support these techniques.

If a new method is needed, then developers will be required to invest their time in making changes to support them. Given the 10s of millions of websites involved the cost and lost opportunity in developing more meaningful features will be vast. If those developers do not make the necessary changes their existing solutions might break. This is an import consideration for the Proposal at the conceptual stage.

The Proposal will need to be supported by all browser vendors to avoid fragmenting the web. This is fundamental to Ethical Web Principle "The web is multi-browser, multi-OS and multi-device”. The following is the relevant paragraph with emphasis added.

“We will not create web technologies that encourage the creation of websites that work only in one browser. We expect that content provided by accessing a URL should yield a thematically consistent experience when the user is accessing it from different devices. The constant competition and variety of choices for our users that come from having multiple interoperable implementations means the web ecosystem is constantly improving.”

If there is no method to mandate support, then a consensus-based approach requires all browser vendors to indicate they will adopt the Proposal because the Proposal will encourage the creation of websites that only work in the browsers that support it. Established norms for technical standards governance place the responsibility for gaining consensus on the proposer.

You recognise the importance of this approach to governance in your email of 7th July 2020 https://lists.w3.org/Archives/Public/public-new-work/2020Jul/0005.html. Many stakeholders recognise the need for the W3C to reconsider it’s position on governance in their email of 13th July https://lists.w3.org/Archives/Public/public-web-adv/2020Jul/0016.html. I’m a co-signatory.

A proposal initiated from a large participant is viewed significantly differently by commentators than if the same proposal originated from a smaller participant. Experiments and consultations from large participants shift share prices. See this chart https://www.cnbc.com/2020/01/14/criteo-stock-crashes-after-google-announces-chrome-cookie-change.html for performance marketing company Criteo following the announcement of Privacy Sandbox.

[image: Share Price] https://user-images.githubusercontent.com/1679482/87564489-5de82b00-c6b8-11ea-93f2-dd6af8dd639f.png

These are important realities. Perhaps the incubation process is in need of an upgrade.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/WICG/client-hints-infrastructure/issues/31#issuecomment-658838927, or unsubscribe https://github.com/notifications/unsubscribe-auth/APCPJPKCIUEPCJDAU4F25STR3XG67ANCNFSM4OYVW4EQ .

Devyn404 commented 4 years ago

I honestly don't care about any of this unless I need to or have come to my attention but you see here my friends is that Google proposed to me and came to my house. How the fuck do I get what they wanted me to do if I have no idea what they want me to do. So fed up beyond yet patient as all hell so get back to me. Like yesterday!!!

On Mon, Jul 13, 2020, 8:12 PM Chris Wilson notifications@github.com wrote:

(This response is my own personal opinion; it should not be read as the opinion of my employer, nor as the opinion of the Advisory Board.)

I'm not sure exactly what you mean. By the way I read your initial logic, any additional complexity would be decreasing individuals' control and power - when adding features like this is the exact opposite, as it increases their control over the platform. This proposal adds complexity for those who need it, but can be ignored if you don't, or don't wish to learn about it.

Similarly, it would appear that people on low bandwidth networks and low specification equipment are ALREADY at a disadvantage, and website publishers tend to abandon them - in part because they lack the API tools (such as client hints) to address these scenarios effectively. The goal in proposals such as this is to enable them to fix that.

But finally, and most importantly, I would point out that during its entire history, the Web has never had "mandatory standards" - the platform has grown as an interoperable agreement across many vendors; there is no body that CAN "mandate" any particular support. Indeed, as the Web platform grows, it needs to continue to interoperate across browsers, OSes and devices; that is a core principle, and frankly, the principal reason behind my own 27-year career in it.

As an incubation, there is little governance here, because this is not (at this point) an official standard of the W3C, or even on the track to become so (it would need to be a Recommendation-track deliverable of a Working Group).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/WICG/client-hints-infrastructure/issues/31#issuecomment-657893040, or unsubscribe https://github.com/notifications/unsubscribe-auth/APCPJPKOXRHVRQ5VPN4BU2DR3OPHLANCNFSM4OYVW4EQ .