Email list hosting service & mailing list manager


Deriving a minimal Scheme.org from first principles Lassi Kortela 27 Dec 2020 13:15 UTC

So we have three alternative ways to arrange Scheme websites:

- Have everything as subdirectories on the www.scheme.org main server.

- Have everything as subdomains *.scheme.org.

- Have everything on completely different domains.

Admin-wise, having sub-sites in subdirectories is essentially the same
thing as having them on subdomains, but with several downsides and no
obvious upside.

To compare subdomains vs completely different domains, let's try the
worst-case scenario for doc.scheme.org vs schemedoc.org. If we have
doc.scheme.org, and the whole scheme.org project somehow folds
catastrophically so that doc.scheme.org can no longer stay under the
umbrella, the logical course of action is to move it onto schemedoc.org.
This would work, assuming the contents of doc.scheme.org are backed up
in public git repos. If scheme.org is lost, old links to doc.scheme.org
around the web would break. In the very worst case, someone would take
over scheme.org and replace the old pages at doc.scheme.org with
malicious pages.

 From that disaster scenario we can directly derive the minimum
infrastructure needed for scheme.org. The internal administration of the
Scheme Documentation site is identical whether it's hosted at
doc.scheme.org or schemedoc.org. Even in the latter case, a bad actor
taking over the documentation server can still replace its contents with
malicious stuff. The differences between scheme.org and doc.scheme.org
are about trust in the DNS records. If there's a schemedoc.org domain,
its DNS is presumably run by the same people as its web server, in which
case the threat model between DNS and WWW is identical. In case of
doc.scheme.org, the DNS is run by scheme.org admins who are different
people from the doc.scheme.org WWW admins, slightly increasing the
attack surface. Scheme.org DNS is now also a common attack surface for
all scheme.org subdomains at once. To maximize trust, the job of
top-level Scheme.org is therefore to ensure this attack surface
(people-wise and technology-wise) is no larger than is strictly necessary.

The necessary features are:

- Having one or more human admins who can modify the DNS records.

- Storing the history of DNS records in Git for backups and transparency.

- That's it.

As far as I can tell, the argument to centralize sites under Scheme.org
boils down to having that minimal layer on top, vs not having it and
having everyone go their own way. Does this sound like a reasonable line
of argument?

If so, my personal opinion is that the extra layer adds a lot of
cohesion with minimal technical and social overhead. If we can draft
formal bylaws, we can also minimize the political risk. From my point of
view these controlled risks are well worth taking. Opinions to the
contrary are welcome.