Skip to content
This repository has been archived by the owner on Nov 2, 2023. It is now read-only.

Discrimination Concerns #115

Open
BenWestcott opened this issue Jul 21, 2023 · 2 comments
Open

Discrimination Concerns #115

BenWestcott opened this issue Jul 21, 2023 · 2 comments

Comments

@BenWestcott
Copy link

When considering any new feature with potential to lock out certain clients from a service, it is important to consider who is most likely to be locked out, and weigh that against the benefits (see several other open issues) against the impact this would have on those users.

As it stands, many individuals are not purchasing new devices, both due to the ongoing global economic recession, and also as new devices are not offering compelling features. This adds up to a large number of people using old devices to interact with the web.

Because the majority of web browsing is done from mobile phones, and these devices are typically tightly locked down with little post-sale support, many of these clients are using outdated software on an outdated operating system with limited hardware. Even if the browser itself is kept up to date, cryptographic features may be limited and slow, or even completely unable to process large amounts of data due to resource constraints.

The specification does not currently define much at all how this process is intended to work technically speaking, or what data are involved, but given the stated goals of the project, it is likely that a large amount of information about the client configuration would need to be considered/processed to truly rule out any tampering. This could be prohibitive on older devices.

This will also have an inherent network bandwidth and access latency overhead, which will disproportionately affect individuals with slow connections or high packet drop. What happens if the attestation times out? Or if the data arrives corrupted? Is the solution robust to these conditions, and how much additional overhead does it add under these conditions? None of this is clear from the proposal, suggesting this was not kept in mind.

All of this adds up to a proposal that is likely to disproportionately lock out poor and disadvantaged users from the internet, and there does not seem to be any concern or consideration of this possibility. Almost everything today is reliant on the internet, even though not everyone has good access. Being unjustly prevented from using sites and services that would implement this feature would be devastating for these people and a grave social injustice.

@jbruchon
Copy link

It's most likely to be used to lock out people who disagree politically with the people controlling the attestation authority.

@BenWestcott
Copy link
Author

@jbruchon, this is an excellent point I had not considered. If the information included in the attestation is enough to connect the user to their real-world identity, which it likely is, this could have serious implications for suppressing political opposition, especially in more authoritarian countries/regions.

That said I think that concern focuses on trust of the attestation authority, while my focus on this issue is the viability of this approach for disadvantaged internet users with limited hardware, software, and access. For the purposes of keeping discussion on topic it may be helpful to spin that off into a separate issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants