Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add centralization-is-bad section #95

Closed
wants to merge 4 commits into from
Closed

add centralization-is-bad section #95

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
4a84e36
add centralization-is-bad section
pes10k Jun 29, 2023
9855bae
Update index.html
pes10k Jun 29, 2023
35aa295
Update index.html
pes10k Jun 29, 2023
8f52710
Update index.html
pes10k Jun 29, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -340,3 +340,22 @@ <h3 id="render" data-export="" data-dfn-type="dfn">
and will create user agents to represent those preferences on the web user's behalf.
</p>
</section>

<section>
<h3 id="centralization" data-export="" data-dfn-type="dfn">
The web is decentralized
</h3>
<p>
The web is a platform designed to be used and operated by as wide
a range of individuals and orgaizations as possible.
We will not create web technologies that encourage centralization,
by favoring large or powerful organizations, to the detriment of smaller
organizations. We include in this concern both technologies
that explicitly promote centralization (e.g., systems that rely on
a single or small number of "trusted parties" to collect or pre-process data),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The DNS is hosted by a 'small number of "trusted parties"'. Are you suggesting that the Web shouldn't use it?

There are only three browser engines; does that represent a 'small number of "trusted parties"'?

Does this mean that Google Safe Browsing is centralized?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The DNS is hosted by a 'small number of "trusted parties"'. Are you suggesting that the Web shouldn't use it?

No, i dont intend or think DNS would be covered by this wording. I can stand up a DNS server at home and it'll work just as well. But it would be very bad for a web standard to say "step 3: talk to Google, CF or Comcast's DNS servers".

There are only three browser engines; does that represent a 'small number of "trusted parties"'?

No I didn't intend browser engines to be covered here. I'm happy to revise the text to make that clearer. A browser engine isn't a trusted party, its auditable (or at least an implementation could be auditable, even if not all are). But, it would be bad if a standard was written to require talking to software or a service that was designed to be unauditable ( widevine…), for example.

Does this mean that Google Safe Browsing is centralized?

Google safe browsing is absolutely centralized. I think it'd be very bad to have a W3C standard that required talking to Google Safe Browsing servers to work correctly. Its a useful and valuable system, and I'm glad it exists, but it doesn't seem like a good model for building open standards for the Web.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re DNS, @mnot I realize I might have misunderstood your comment. Were you referring to root servers, or resolvers? My comment was about the latter, but on second thought I see you might have meant the former.

If you meant root servers, yea, thats a tricky one, I take your point. Its unappealing, but maybe its least bad. I could try and emphasize "unless necessary" or "unless no other alternatives exist" or similar (though i appreciate that direction has its own downsides too)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, I meant the root servers.

and technologies that would promote centralization in more subtle ways (e.g.,
systems that are prohibitively expensive to run, or systems that provide more
utility as the number of participants increase).
Comment on lines +357 to +358
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to rule out a large number of potentially useful things; effectiely, you're saying that the Web should not be more useful/efficient at scale.

Copy link
Author

@pes10k pes10k Jul 7, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats not what i mean. I'd be grateful for help rewording, or refining if the principal appeals.

My goal is to capture that it'd be bad to standardize systems that:

  1. that require (either explicitly or in principal) user-bases bigger than what all but the largest system-participants / implementors can achieve. Examples could be K-anon systems with large K, or moderate K over a wide and uniform-ish distributed set of values, or noise-injection systems that require many users to recover a useable signal, etc.
  2. are expensive enough that they'd prohibit many/most system participants from implementing/running

Those goals seem distinguishable from systems that become marginally cheaper, or slightly more useful as usage increases. Though i appreciate the need for careful language to separate the two.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps an example would help: is there a specification you have in mind where a design decision was able to discriminate along these lines? Or one that failed to, when it could have?

</p>
</section>