Avoiding Internet Centralization
mnot.github.io
mnot.github.io
Look at the history of everything that was acquired by either Qwest/CenturyLink or Level3, and then the merger of Level3. You can't tell me that the existence of Lumen, the combined Centurylink-Level3 entity is good for anyone, except for their shareholders.
It's the very definition of too much centralization.
Look at all of the things that have now been jammed together into the modern Verizon, as well.
Look at the sad state of competition in Canada, with Rogers and Shaw trying to merge.
When 90%+ of people have no upload capacity at their house, and are behind tons of CGNAT, then onedrive/iCloud/google drive become the only solution for storing your things you can access later. Same with chat protocols.
0: https://www.att.com/support/article/u-verse-high-speed-inter...
1: https://www.ebay.com/itm/164939095713
2: https://forums.att.com/conversations/att-internet-equipment/...
There are a couple of bypass methods on the GPON network that let you use your equipment with the ONT and bypass the RG. I don't think I would bother, though, and I'd just use the 'IP Passthrough' DMZ to assign the public IP to your router. The only problem was the size of the internal connection table on the RG was historically very small and didn't clear quickly which really only causes problems if you torrent. The newer RGs don't have this problem.
On the XGS-PON network the ONT is integrated into the RG so it's not possible right now, but again the DMZ 'IP Passthrough' mode actually works well.
They support IPv6 and they give out a /56 if that matters to you.
However, as an individual, I could gain great utility by not exposing any of my data to any company. And I would not have to if I could setup a NAS at home with a 1Gbps+ upload that me and my family can setup our devices to backup to, or use in a similar fashion as Dropbox or run a peer to peer chat protocol like WhatsApp.
But all of that is a nonstarter because of the minuscule number of people with 1Gbps+ connections at home with ipv6 and not hidden behind CGNAT, there is no viable market for selling the software and NAS that can cut out the big tech companies.
BT doesn't own our wires as such. OpenReach does (yes they were formally BT but spinned off).
BT or OpenReach - who cares? The important thing is functionality. I'd like to provide you with a novel telephony setup but the lack of ENUM means I am not able to do that.
Openreach are a wholly-owned subsidiary of BT, they're not really independent.
BT retail (the arm that sells to clients) has strict rules that forbid it from sharing with BT wholesale (the arm that sells to the other ISPs) so BT retail really can’t crush the competitors.. I don’t know the exact arrangement but they’re treated like any other ISP customer I believe
Each satellite is visible under idea circumstances from about 3% of the surface of the Earth at once. At an eventual 12000 satellites, that would mean 360 satellites would on average be visible from a given spot. The orbits are such that there will be much less coverage in the far north or far south and much more in between, so let's call it 1000 satellites on average visible in a given area that they will serve.
The next generation satellites are supposed to have 80 Gbps bandwidth to the ground. That's enough for 800 users simultaneously downloading. But most users most of the time are not going all out.
Let's try to estimate what average use is. Most Xfinity users have no trouble staying under their 1.2 TB/month cap. I've read somewhere that the average usage is only about 1/4 that. That would correspond to an average usage of around 1 Mbps, 1/100 of the speed of a Starlink connection. Using that, we can handle 80000 users per satellite, or 80000000 users for the 1000 satellites visible on average.
Taking into account the ground area in which a satellite is visible, we can work out the maximum ground density of customers at that usage level that stays within the bandwidth total. It works out to about 11 users/square mile (4.4 users/square kilometer).
In summary, Starlink should be able to deliver a decent 100 Mbps 100x oversold internet service in places where over the area visible from a satellite (about 7000000 square miles or 18000000 square kilometers) the customer density is under 11/square mile or 4.4/square kilometer.
The US population density is 94/square mile (36/square kilometer). California is 2.5x that, Florida and New York around 4x that.
The density it can support is probably actually a little lower than I got because I'm assuming that any satellite visible from your location can be used. My understanding is that the antenna is aimed in a good general direction at setup, and then uses a phased array to track satellites as they come and go. I'd expect that this limits you to satellites that are in front and not too far to the side of where the dish is pointed.
[1] https://www.techdirt.com/articles/20200928/09175145397/repor...
wireless is only radically different from a consumer perspective and the capacity is nothing to write home about. It's the coverage and latency that bring value.
Implementing them takes time and you need many implementations for the protocols themselves to become de-centralized.
This is what breaks most new protocols and languages combined with diminishing returns (low hanging fruit has allready been harvested).
Personally I'm going back to HTTP, DNS and SMTP.
And even if DNS is completely centralized, it's the only thing we have for name lookups after 38 years!
Also I never rely on DNS if I can avoid it (I use static IPs and only use the hostname for virtual hosting / load balancing).
And de-centralization by hosting is more important than the protocol itself being p2p, since no p2p protocol can operate purely without server because of discovery.
I have made my own, from scratch, implementation of all 3:
DNS and SMTP soon coming to a rupy (HTTP), enabling DNS and SMTP through HTTP, you'll basically be able to control DNS and SMTP via a "Servlet/Filter".
Home hosting on fiber with static IP and ports 80, 53 and 25 open is the real challenge.
Making sure your ISP enables those has way higher priority than this document!
And the real canary is when you don't get an external IP on your fiber when IPv4 allocations in Africa run out.
It's time to wake up if we want an internet that does not become rent seeking.
Google charges for static IP addresses on GCP which should not be a thing if they get allocations for free.
IPv4 is a scarce asset, so they have an incentive to slow down IPv6!
Depending on how you mean, it's not the only thing or its not 100% centralized; https://en.wikipedia.org/wiki/Alternative_DNS_root lists the major alternatives in that immediate space.
Same as in AWS (IIRC) in Google Cloud you don't get billed for static IP addresses if they are in use:
"If you reserve a static external IP address and do not assign it to a resource such as a VM instance or a forwarding rule, you are charged at a higher rate than for static and ephemeral external IP addresses that are in use.
You are not charged for static external IP addresses that are assigned to forwarding rules."
External IP Charge on a Standard VM Usage 2021-11-01 2021-11-30 2,XXX.XXX hour 50.XXXXXSEK
So ~$2 per IP in USE per month!
>gcloud compute addresses list
ERROR: (gcloud.compute.addresses.list) Some requests did not succeed:
- Request had insufficient authentication scopes.
We need to move away from these companies before it's too late... they are incompetent and rent seeking.
They also do not rebate your free instance if you shut it off and change the instance type of the instance that had the rebate, even if you change it back.
And there is no recourse, no support, no way to get help.
NAME REGION ADDRESS STATUS
euro europe-west1 X.X.X.X IN_USE
asia asia-east1 X.X.X.X IN_USE
iowa us-central1 X.X.X.X IN_USESo "...you are not charged for static external IP addresses that are assigned to forwarding rules", yes, but a VM is not a forwarding rule :P
So you gotta pay for external IPs attached to a VM, but not to a Load Balancer. Seems like they're trying to incentivize using LBs to use less IP addresses, I guess...
The problem here is the word "Always". Encryption is good for just the reasons they say. But only encryption, always encryption, not having an option for plain text is highly centralizing in itself. This is because the current status quo for encryption is to use TLS based on certificate authorities. And CAs are always highly centralized and highly centralizing.
If Lets Encrypt ever goes corrupt like dot Org did it would cause an incredible amount of trouble and that entity would have power over a large portion of the web, if not the entire internet. There's an easy solution to this though. Don't throw alway plain protocls. Plain and TLS wrapped are synergistic. Use both. There's no need for, and it is damaging, to always encrypt without an option for plain text.
A hypothetical downgrade attack is not an excuse for using only highly centralized TLS CA based protocols in this context.
If you allow self signed certificates, anyone who can MITM traffic can masquerade your site just like with http
Self signed does however stop passive fibre taps - to intercept you need to MITM.
There then the “remember this cert” option. If I visit www.selfsigned.com on a secure network, my browser remembers the certificate. If I then travel to another network with a MITM, my browser can flag up a warning. This is how SSH works.
However I’m not too concerned by SSL certificates as a centralised point - my browser trusts dozens, probably more than 100, root certificates. That’s not centralisation.
https://ccadb-public.secure.force.com/mozilla/CAInformationR...
If we're not going to show interstitial warning pages for HTTP-not-S sites, so you can't see if it's HTTPS without checking the address bar, then a red open padlock and a red strike through the "https" seems sufficient for self-signed HTTPS sites. Some indication is needed, otherwise you'd see the "https" and think it was secure, but the indication shouldn't be scarier than HTTP-not-S!
Not everything has to be TLS or even HTTP. Look at messaging apps. Signal is encrypted, but the end-to-end encryption it uses isn't TLS and doesn't use certificate authorities.
> If Lets Encrypt ever goes corrupt like dot Org did it would cause an incredible amount of trouble and that entity would have power over a large portion of the web, if not the entire internet.
Not really. Let's Encrypt doesn't have a monopoly over anything. They use an open protocol (ACME) that any other CA could implement. If they went evil, someone else would implement the same protocol and everybody would switch to them. Which also implies that they won't, because why bother if that's what will happen?
This is kind of a problem with the CA system the other way -- if you have one bad CA they can sign any domain even if they shouldn't -- but in this case it prevents what you're worried about.
For reference, many CAs (even paid ones) have implemented it:
Digicert https://docs.digicert.com/certificate-tools/Certificate-life...
Sectigo (formerly Comodo) https://sectigo.com/resource-library/sectigo-adds-acme-proto...
This is why certificate transparency is a thing and most browsers require it for public internet domains[0,1].
0: https://chromium.googlesource.com/chromium/src/+/refs/heads/...
Not that it's much better. IPs are still granted to you by someone in a centralized hierarchy.
Technically it is so captured -- IANA is the root of the hierarchy that distributes both IP address assignments and ASN assignments -- and the RIRs are effectively centralized authorities in their regions. Thus far it has not been a problem.
With a larger address space and longer ASNs you could decentralize the entire process. Basically, subnets and ASNs would be hashes of public keys, and you would use a path-vector protocol where the NLRIs contain NIZKs proving knowledge of the secret keys and asserting who the NLRI was sent to at each hop (identified by ASN). It is not current being considered because (1) it would greatly increase the cost of routers and related infrastructure and (2) thus far there is no immediate need.
> "[A]ny decentralized order requires a centralized substrate, and the more decentralized the approach is the more important it is that you can count on the underlying system."
This somewhat counterintuitive notion is often overlooked. In order to facilitate a healthy decentralization effort you need a heck of a collaborative movement to make it a reality and sustain the initiative.
[0] https://www.thediff.co/p/the-promise-and-paradox-of-decentra...
It does not avoid government control. Even ignoring local legalities, at the very least it will be under the physical control of whichever country hosts the nearest ground-segment station.
https://github.com/fiatjaf/nostr
Kinda like the "fediverse", but improved in the sense that it is not federated, but also not P2P (because pure p2p doesn't scale).
It is better to design systems to handle centralization than with the assumption that they will remain decentralized, which would sort of break them.
If it seems like everything that we build is centralized, it might just be that we're bad at building things that last.
2021: AWS and amazon US-EAST-1 is down, this means my coffee maker doesn't work
1970: Early networks suffered from congestive collapse problems, routing protocols were slow to converge, computed suboptimal routes, and had count-to-infinity problems, only a handful of transit networks existed, domain names were managed by one dude broadcasting a file to everyone, little to no security infrastructure, etc.
2021: We have robust congestion control and queue management, scalable routing protocols that find optimal routes and have no count-to-infinity problems, DNS, large numbers of transit networks with a high level of redundancy, and at least some security infrastructure in key places (DNSSEC, RPKI, etc.).
Don't confuse web infrastructure and hosting services with the Internet itself, which is the network and which has never been more distributed or more robust than it is today.
The most significant incident in recent memory involved a severed fiber optic line in New York City earlier this year, which affected the US Northeast in various ways. The impact was relatively short-lived, and despite living and working in NYC I was not personally affected at all -- even though I use Verizon FIOS and the line in question was operated by Verizon (a testament to how resilient Verizon's own network is). That is the mark of an extremely robust system -- a major, overly-centralized component (one cable carrying many supposedly redundant links) is destroyed and the effects remain highly localized and the impact is not universal even within the local area.
The Internet has become so robust and reliable that end users take the network for granted. At this point most of the headline-making incidents involve services running on the Internet, not the Internet itself (at least in the US, EU, and other highly-connected regions/countries; there are still countries that can be taken offline by just one cable being severed, and their Internet users cannot take the network for granted yet). In my adult life there have only been a handful of significant, global outages/reductions in service quality on the Internet itself. Regional outages happen from time to time, though few are significant enough to make national or international news.
So yes, network-level improvements mean a lot to end users -- they mean that end users can rely on the network itself, and only have to worry about problems at higher levels of the stack.
The day facebook was down for a few hours, I was asked why the internet was down. That person uses the internet for fb and whatsapp (also fb) A decentralized communication protocol and a federated social network wouldn't fail completely under the same circumstances.
Technical decentralization is orthogonal to commercial issues.
If it was federated and Facebook still controlled it, it would still be centralized.
While Wire and Matrix are working on a decentralized version the IETF is, unfortunately, working towards one based on a central entity.
Source:
https://news.ycombinator.com/item?id=25102916
https://matrix.org/blog/2021/06/25/this-week-in-matrix-2021-...
On the Matrix side we’re working on fully decentralising it (as per https://matrix.uhoreg.ca/mls/ordering.html). There’s also a cool similar project from Matthew Weidner: https://dl.acm.org/doi/10.1145/3460120.3484542
It’s a bit perplexing that mnot’s draft cites XMPP as decentralised, given MUCs are very much centralised to a single provider which entirely controls that conversation, and if that provider goes down the conversation is dead. But I guess that’s because XMPP is submitted to the IETF, and Matrix isn’t yet.
1. Open network, but each user lives on a single server, each conversation is dependent on a single server: (XMPP MUCs)
2. Open network, but each user lives on a single server (with some ability to manually migrate between servers), conversations are replicated across all participating servers: (Matrix, ActivityPub, SMTP, NNTP)
3. Open network, users are replicated across multiple servers, conversations are replicated across all participating servers: (Matrix + MSC1228 or MSC2787 or similar)
4. Open network, users live on a single P2P node, conversations are replicated across all participating nodes: (Briar, today's P2P Matrix)
5. Open network, users are replicated across multiple P2P nodes, conversations are replicated across all participating nodes: (P2P Matrix + MSC2787 etc).
So yes, XMPP is decentralised by some definition, but it's kinda useful to map out the whole space.
No, there is nothing unavoidable in making a centralized DNS system.
Suppose the root is a set of public keys, each with a top level domain. Adding one requires a supermajority of the others to agree. Removing one is impossible; it can sign its own successor and that's it. You now have a federated system with no single chokepoint.
Compare with systems that don't revolve around making any coherent global view, like Petnames. In the context of Zooko's triangle - do the human readable name lookup once as part of a manual process, and then persist the relationship as decentralized/secure but not human-readable.
All voting systems require protection against Sybil attacks. The best methods to protect against Sybil attacks are centralized. The not-best methods use proof of work, which has extreme downsides and only makes Sybil attacks expensive, not impossible.
The voting system is the protection against Sybil attacks. A successful Sybil attack would allow you to add your own TLDs, but if you can't already do that then you can't do a Sybil attack.
The real issue with that kind of system is deciding on the initial group of voters.
> Each name set consists of three elements: a key that is global and securely unique (but not necessarily memorable); a nickname that is global and memorable (but not at all unique), and a petname that is securely unique and memorable (but private, not global)
An essential component of a practical addressing system is names which are global, memorable, _and_ unique. Colloquially, I need to be able to say "Google dot com" over the phone to someone, and their experience using that name needs to be identical to mine. A system that doesn't provide this property doesn't solve the problem.
There isn't a single world-wide authority that assigns names to people or companies, or plate numbers to cars or airplanes. It's partially federated and we accept the tradeoffs.
There's plenty of ways do to so: by configuration, by quorum, by bookmarking pet names on first use, or by asking the use (what every search engine does when people look up e.g. "netflix")