Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoiding Internet Centralization

mnot.github.io

Post reply on HN
Print view View original

91–100 of 111 posts

Re: Avoiding Internet Centralization

#91

Post by immibis »

meltedcapacitor wrote: post #84
catlikesshrimp wrote: post #62

Earlier quoted context omitted.

I love the internet as it is today (facebook and google aside) the system is reliable enough for us. But the discussion is about centralization. This is not about infrastructure. 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 unde…

Facebook could also run federated technically, so that it never fails all at once. It failed because they put all the eggs in one basket in some top layer. Technical decentralization is orthogonal to commercial issues.

If it was federated it wouldn't be Facebook, it would be Mastodon.

If it was federated and Facebook still controlled it, it would still be centralized.

Re: Avoiding Internet Centralization

#92

Post by immibis »

AnthonyMouse wrote: post #9
superkuh wrote: post #2

> 5.2. Encrypt, Always: When deployed at scale, encryption can be an effective technique to reduce many inherited centralization risks. ... 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 cert…

> This is because the current status quo for encryption is to use TLS based on certificate authorities. 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…

I'm surprised if Signal doesn't use TLS, considering that Android tries to force apps to always use TLS, which is because of the point the parent comment is making.

Re: Avoiding Internet Centralization

#93

Post by immibis »

midasuni wrote: post #17
superkuh wrote: post #7

Earlier quoted context omitted.

Browsers scaremonger really hard about self-signed SSL certs. And browsers are starting to implement HTTPS only as a default. It won't be too long before HTTP is blocked by mega-corp browsers and not having a CA TLS cert means your website is now un-visitable by non-technical people (and not indexed by search engines).

The concern about http over https is that a bad actor can intercept and change traffic. 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…

Self-signed certs should be no scarier than unencrypted connections. If self-signed certs are allowed then you can have a case for banning unencrypted connections - the way Mozilla tried to do in the past, but they didn't allow self-signed certs.

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!

Re: Avoiding Internet Centralization

#94

Post by immibis »

AnthonyMouse wrote: post #44
notriddle wrote: post #37

Earlier quoted context omitted.

> because they're based on voting 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.

> All voting systems require protection against Sybil attacks. 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.

What stops me adding 10000000000 fake users and having them all vote for my new TLD?

Re: Avoiding Internet Centralization

#95

Post by immibis »

goodpoint wrote: post #86
preseinger wrote: post #56

Earlier quoted context omitted.

What? Practical addressability requires centralization by definition. How could it work otherwise?

...for an arbitrary definition of "practical". 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.

Humans can use ad-hoc disambiguation where needed - "it's the A1 Computers down by the lake" - but computers can't handle one name resolving to two different sites. When a1computers.com is registered twice, it won't automaticallychange one to a1computersdownbythelake.com and the other to a1computersbytheairport.com.

Re: Avoiding Internet Centralization

#96

Post by Arathorn »

zaik wrote: post #85
Arathorn wrote: post #22

Earlier quoted context omitted.

As far as we know, the Wire version is still logically centralised, using a centralised sequencing server. 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…

XMPP is still a decentralized protocol by design. That you can't send messages to a conference hosted on a server that is offline doesn't make it 'centralized'.

There are probably five broad levels of decentralisation here:

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.

Re: Avoiding Internet Centralization

#97

Post by tzs »

lotsofpulp wrote: post #23
walrus01 wrote: post #11

Something not really covered is this concept: "Maybe don't let one telecom company acquire too much control". 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…

Also need fat upload pipes (i.e. fiber) to individuals’ homes so they can operate their own backup and peer to peer services. 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.

I don't understand. If my upload bandwidth is sufficient for me to keep my stuff on OneDrive/iCloud/Google Drive, why wouldn't it be sufficient to keep my stuff on any other remote storage service?

Re: Avoiding Internet Centralization

#98

Post by tzs »

justinpombrio wrote: post #65
serverholic wrote: post #55

Earlier quoted context omitted.

Two networks are less centralized than one. Why do people think centralization is binary?

And Starlink is especially good, because it can compete with all of the cable companies at once. No one will have a monopoly anymore. Hopefully a lot of people will suddenly start getting better service, which I hear is common when competition rolls into town.

Starlink will not have enough bandwidth, even after the full constellation is deployed, to compete with even one cable company in a major metropolitan area. Starlink is designed for places where there is not a high customer density.

Re: Avoiding Internet Centralization

#99

Post by bullen »

bullen wrote: post #82
tecleandor wrote: post #81

Earlier quoted context omitted.

> Google charges for static IP addresses on GCP which should not be a thing if they get allocations for free. 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 addresse…

That's not true, I have 3 static IPs connected to VMs and they charge me for them: 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.…

I just had to authenticate apparently:

  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_USE

Re: Avoiding Internet Centralization

#100

Post by lotsofpulp »

tzs wrote: post #97
lotsofpulp wrote: post #23

Earlier quoted context omitted.

Also need fat upload pipes (i.e. fiber) to individuals’ homes so they can operate their own backup and peer to peer services. 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.

I don't understand. If my upload bandwidth is sufficient for me to keep my stuff on OneDrive/iCloud/Google Drive, why wouldn't it be sufficient to keep my stuff on any other remote storage service?

You can keep it on other services, but economies of scale, bundle pricing, and security concerns benefit the large incumbents. For example, I stick to iCloud, because all of my data is already exposed to Apple, so exposing it to another entity is just increasing the number of entities my data resides at just increases my vulnerability.

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.

Post reply on HN