Ask HN: You have one shot to redesign the Internet – what do you change?
This was just an idle conversation we were having at work. Imagine that one day you wake up and you've been sent back in time, where you are now a researcher at DARPA in the early 1960s. You've got the influence to effect fundamental changes in the next sixty years of the Internet's history, and can make your changes any time in the next sixty years - but you know that as soon as you change one thing in history, you'll be sent back to 2021, to continue living in the world you have wrought.
How are you going to make the Internet better?
321 comments
[ 2.8 ms ] story [ 286 ms ] thread1. Everything being 'free' by default drives us to ad-supported centralized services. Economics aren't a separable concern.
2. Too few IP addresses. (At least one of the pioneers, I forget which, said he pushed for longer addresses but was overruled. So the technical constraints probably did not force this.)
I'm not sure how to fix #1, but here's an approach from the 90s: https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16....
Quite frankly, if they didn't allocate full /24 to single entities (including localhost...), we might still have enough addresses left.
IPv4 is just inefficiently allocated in general. Why does the world need 10.0.0.0/8 in addition to 192.168.0.0/16? Isn't 65k addresses enough? Is there a private organization in need of 16 million addresses?
Not to mention AMPRNet (amateur radio) owned the entire 44.0.0.0/8 up until 2019 (a portion was sold off to Amazon). That may have seemed reasonable in 1980 but now it's just plain crazy.
[1] https://en.wikipedia.org/wiki/Reserved_IP_addresses
Plenty of mobile phone networks have well over 16 million subscribers, and they typically don't have enough public IPv4 addresses for everyone. This has led to really hacky stuff, like using DOD IP ranges as psuedo-private space, or re-using private IP addresses in different regions (which can't be fun to maintain.)
Some networks have fixed the problem by using NAT64 - forgoing IPv4 altogether internally, and translating to public v4 at the edge. (Works surprisingly well, T-Mobile US has been doing it for the better part of a decade.)
This is why 192.168.0.0/16 is often used for services like libvirtd, kubernetes and docker. And the use of the range by those services makes it even more unwieldy to try and put some other LAN in there.
You can work around these considerations if you want, but many people won't. When you're the network engineer responsible for designing a company's networks, you'll be wanting to keep things simple and robust. When you're called in at 3am on a Sunday because the network is down, you better hope your ability to recover doesn't require making a bunch of subnet calculations because you decided to try and use the pool of available IP addresses efficiently.
For how long?
Even if we hadn't wasted /8s on huge allocations to single companies, and things like 240.0.0.0/4, we'd still be basically where we are today, with v4 address space being scarce and traded as a commodity.
The problem of how to fund actual web application development is not much different from the problem of how to fund media development in general. Newspapers, television, and magazines alike long ago settled on some mix of premium-tier subscription services augmenting a more open, ad-funded free tier.
This is so much more of an issue today than 30 years ago not because of anything specifically about ads to fund media, but because ad profitably has been driven sky-high by individual consumer profiling that relies upon privacy invasion and surveillance of your customers. Ads back in the day would improve via voluntary focus groups and that was fine. Today, they improve by tracking every digital action a person ever takes in order to more accurately correlate interacting with an ad with making a future purchase. Volunteers for focus groups are pretty much okay with giving their opinions in return for cash. Every person on the planet is not nearly as okay with having every digital action they ever take recorded and analyzed.
This doesn't mean it'd kill advertising. It wouldn't even kill all of the forces encouraging me to put my 'content' on centralized services even though I'm nothing like a media corp. But I suspect the right changes could've helped a lot towards a healthier computational ecosystem now.
This early architectural decision that costs are out of band didn't fundamentally make anything impossible. But when you see a lower-level problem addressed by higher-level workarounds, and you're getting to redesign the system, isn't that exactly what constitutes an opportunity?
I also don't want to be nickle and dimed to death, given the transaction fees there's a huge push to subscriptions and other models. Where if I could instead just pay exactly what a generic ad I'd _never_ click on anyway pays to get placed (like 0.00001 dollars for all the ads on a webpage stuffed with them) I might actually pay instead of using adblock for all of the security, usability, and bandwidth saving reasons.
I hate this argument. I've been online for a long time and the internet existed just fine without, for example, facebook. We don't have to accept ads but we do have to be willing to not use certain things out there.
I know this is a holywar topic and many would disagree simply by seeing `blockchain` word used here. But to my mind this exactly the place where this technology is beneficial. We need automated algorithm controlled currency to have this type of smart internet subscription.
I'm push as many examples of capability based security into the academic world as I possibly could, in the 1970s.
Alternatively, push a version of Pascal with a standard library, and drown the insane practice of ending strings with a null instead of knowing their lengths.
For good reason, though. Who says what information is "verified", the government, the news media, the publishers? And what governments, media, and publishers get a say?
Perhaps it'd be nice for browsers to show a little indicator to confirm that a website is hosted by a government (although .gov and .mil are only valid for American governments, government could use a given domain as their government basis). There's a big difference between what's right ("climate change is real") and what the government is saying ("who knows, maybe drinking bleach is a good idea?").
Dividing the net goes straight against the idea of the internet. I don't think using a special browser for special domains is very tempting. We'd probably end up with the alt-net version of onion.to to proxy all different kinds of sites to a single application.
https://en.m.wikipedia.org/wiki/JANET_NRS
[0] https://news.ycombinator.com/item?id=24438978
The problem is that these MTAs get hacked or people just hijack domains.
Heck, the barrier to buying a domain is so low that this is a legit way of spamming too.
This suggests that one way of making spam unprofitable would be to require any domain which sends email to put up a bond of $100 which is forfeited if any of the big four email providers decide that the domain is sending spam.
To make this acceptable to public opinion, the forfeited bonds would to go directly to popular charities, and all existing domains would be automatically grandfathered in, so there would be no extra cost for any current business or user.
Yes, but the customer will blame you when e-mail from a misconfigured MTA doesn't arrive (from my experience running one).
If only we'd had DKIM from the start, preventing thousands of broken servers from being set up in the last twenty five years...
There's really just a difference in thinking, "private by default for email" vs "public by default." Or "untrusted network" vs "trusted network." However you want to think about it.
S/MIME seems to work pretty well, but the paid certificates pretty much doomed its uptake. I think I still have a Startcom certificate from back in the day that has long since expired.
1. Encrypted onion routing on layers that betray source/dest IP. 2. eSNI on all TLS connections. 3. Privacy-focused DNS.
Such a government could then require app stores to remove "dangerous" technologies like Tor and messaging apps that support end-to-end encryption.
Perhaps ISPs would be allowed to support "legacy" devices and OSes, but with a special "Evil Bit" set on packets, so that websites could (and in some cases would be required to) refuse access.
The other problem you run into is ease of use. Most users of the internet can't understand PKI based certificates so I don't know how an interface could look that would provide a strong guarantee of identity but also allows my mom to use it and not get phished.
A) Establish the expectation that websites "close" in the middle of the night for ~5-6 hours, local time / for each timezone. I don't know if would best be done via cultural influence -- giving talks, writing essays, personal communication, testifying / making inroads with politicians -- or via creating some sort of protocol. The idea is to prevent the unhealthier aspects of internet binging and screen addiction.
B) Establish the expectation that internet comments are transcriptions of voice recordings. I.e. to leave a comment, you have to call a phone number and leave a message which then gets transcribed as "the comment." In order to respond or reply to a post or a thread, you have to listen to the message and tone of voice of the person you are replying to. I don't think this would solve every internet dialogue, but it'd promote healthier interactions and less division.
In my book, the largest problems with the internet are techno-cultural, not technological.
Also who is this to protect? The user? What if they work midnights or their days are backwards?
I see this is as a problem of the medium of discussion more than anything else.
You can read a bit about how it works in practice on the web.
https://www.huffpost.com/entry/ultraorthodox-jews-are-co_b_1...
http://www.hareidi.org/en/index.php/Hareidi.org%27s_Kosher_I...
Background: https://www.journals.uchicago.edu/doi/pdfplus/10.14318/hau7....
The problem is that it's the 60s. My first thought was "security", but unless you an also teach them about elliptic curves, they're going to use the security of the 1960s, which as we now know isn't very secure.
Maybe at least having security baked in would help make it easier to switch to better security later, like how ssh can use different protocols as old ones are broken. But you'd have to make sure that you were very clever about how it was implemented so that it could be switched without major changes.
Another thought is "more IP addresses", but again you are in the 60s. The computers don't have enough memory to deal with IPv6 length addresses. So again the best you can do is try to set them up with easy upgrades.
Which makes me think the best suggestion would be to teach them about Moore's Law, which of course would have a different name, and try to push for every protocol being extensible as technology grows -- make sure that more octets can be added to IP addresses without them breaking, that security is baked into everything but everything has a way of negating a protocol so that they can be upgraded, that there are no hard upper limits that are assumed and can always be changed.
Basically, teach them what we now know are software best practices -- constants shouldn't be hard coded in the software, they should always be in a separate config.
In fact, you can even ping any 32 bit unsigned integer and it will turn it into an ipv4. Try it: `ping 134744072` will ping `8.8.8.8`
So why not 64 bit? 32 bits fit in 64.
Instead we now have 2 concurrent protocols.
ps. 8*256^3 + 8*256^2 + 8*256 + 8 = 134744072
For example, if an old router got a packet for 1.2.3.4.5.6.7.8, where would it send it, if it didn't crash just trying to read that address?
Attempting to change the format of an existing protocol in-place in a way that existing hardware and software cannot handle, would be an effort that's dead on arrival.
The global transition to ipv6 is already hard enough, and that's with it designed as a separate protocol so that existing equipment that doesn't understand it can at least gracefully discard it instead of mishandling it.
Slowly over time the roads were upgraded, so now you can use mostly high speed roads to get between places and you don't really see Model Ts anymore because it's not convenient to avoid all the high speed roads.
Nothing has stopped making faster cars just as nothing (fundamentally) has stopped us from making a "better" Internet (supporting more addresses and other features). What hasn't been done is to say, "Ok, so we already have this massive hardware rollout but we're going to literally obsolete 99.99% of it overnight and cost everyone, home users, small businesses, governments, megacorps, billions or trillions to replace their hardware."
Why didn't that happen? Because it would've been stupid. Instead we ended up with what's amounted to two Internets with bridges between them. The transition hasn't been smooth, but it has been happening.
The address is not the real issue. An IPv4 header contains 32 bits for the source address and 32 bits for the destination address. That's what needed to be extended. IPv4 implementations expect the destination address to be 32 bits after the source address.
Any fix you can think of to extend the address fields in the header will fall into the situation of having an additional protocol. Because changing the v4 header and calling it a v4 header would probably get your packet dropped as bad. Or have it being sent to somewhere else. Or some other undefined behavior.
So your best option is to have it identify as a new version. Yes, v4 implementations will reject your packet, but that's what you want in this case.
So the only real option is creating a new protocol with a new protocol ID in the header. And if we're making a new protocol anyways, we might as well design it to fix more problems than just address space exhaustion.
And that's what IPv6 is. The Wikipedia article has a lot of details on the kinds of changes it makes and why: https://en.wikipedia.org/wiki/IPv6#Comparison_with_IPv4
Don't you think that would have slowed down the growth quite a bit?
Obviously it wouldn't apply to everything, but back in the 60s future growth was clearly not thought about the same way as today.
This could perhaps have been implemented in VLSI back in the 80s in such a manner that 32-bit IPs ran at full speed, 64-bit at half speed and 128-bit at quarter speed.
The last big things to secure are DNS (can be done with DNSSEC), and possibly somehow mandate TLS for connections (although you definitely don't want that all the time).
One big glaring problem is BGP, which we don't really have an answer for. Whereas "just use DNSSEC" pretty much solve the last big security hole above, BGP is still difficult because you have to basically have a system to attest the path for each BGP node. AS1 can't say "I have a path of length 5 through AS2 AS3 AS4 AS5 AS6 to AS6" unless that message can be attested to by each node, but then this comes into a bootstrapping problem (e.g. how do you reach those ASes to get some sort of key without going through AS2 first?) or trusting some authority as we do for ssl certs. God knows the first thing I do on any fresh install is uninstall those root certs from any sketchy government I don't trust.
Having worked on SDN in its heyday for some of the big players in the space, there are definitely good ideas in the space, but getting to adoption is damn difficult, bordering on impossible. I don't know what it will take to oust BGP, so we're kinda stuck with it for the foreseeable future.
If people decided to take this away by adding some security directly into the IP layer (i.e. such that communicating without it is impossible, such as mandatory IPsec), I don't think the tradeoff would be worth it. Now you would have to manage all the normal stuff that comes with keys (e.g. expiration and renewal), and you may find your device gets wedged if you don't do the delicate key expiry dance correctly (i.e. you can't even connect to the site to get updated keys).
It's very easy to say "those DARPA morons not designing security was a big mistake!", but I am not convinced that the tradeoffs of solving it at the internet level (i.e. L4 and down) are worth the bootstrapping / flexibility hits.
I see what you did there :D
One of the primary uses cases for Web Package is to let two users exchange content while offline, perhaps via a usb stick or what not. This isn't part of the specification, but we could begin to imagine sites that have a list of the web packages they have available for download. And we could imagine aggregating those content indexes, and preferring to download from these mirrors over downloads from the origin's servers.
I'm hoping eventually we get a fairly content-addressed network, via urls.
[1] https://github.com/WICG/webpackage
(see http://www.youtube.com/watch?v=bpdDtK5bVKk&feature=youtu.be&... by Jaron Lanier, also see Ted Nelson)
" Refusing to accept the authority of previous philosophers, Descartes frequently set his views apart from the philosophers who preceded him. In the opening section of the Passions of the Soul, an early modern treatise on emotions, Descartes goes so far as to assert that he will write on this topic "as if no one had written on these matters before." "
The original idea was that protocols would allow any one to participate by simply making their own webpage. But dynamic IP addresses, the DNS system, and even just HTML design were out of reach for most people so that got lost and monsterous websites under centralized control became the mediators for most people.
So if we could find a way to bake that decentralization into the protocols even more strongly while making them accessible to non-technical people, that's the change I would make.
The aim is to create a world where central platforms are not dominant, but any user can easily participate in the communication protocols with out there being a central point to collect all the data or force changes from.
...of course, I have no idea how one would go about doing that, and there in lies the rub.
Now, it could've been done in a better fashion, more deliberately, or more broadly, but there are at least two notable early protocols with decentralization/distribution in mind: email (consisting of several protocols) and nntp. Now an individual may still access a, to them, centralized authority for sending/receiving content, but the protocols themselves were meant to support a distributed architecture.
Have you heard of Holochain?
"Holochain is an open source framework for building fully distributed, peer-to-peer applications.
Holochain is BitTorrent + Git + Cryptographic Signatures + Peer Validation + Gossip (data propagation).
Holochain apps are versatile, resilient, scalable, and thousands of times more efficient than blockchain (no token or mining required). The purpose of Holochain is to enable humans to interact with each other by mutual-consent to a shared set of rules, without relying on any authority to dictate or unilaterally change those rules. Peer-to-peer interaction means you own and control your data, with no intermediary (e.g., Google, Facebook, Uber) collecting, selling, or losing it."
Centralization has been greatly enabled by it being legal to hoover up all kinds of user data and monetize it by selling ads or using it for ML training. Huge moats, unassailable by anyone trying to charge money directly and discouraging interest and participation even in free, volunteer efforts (since the commercial ones are already no-charge...) while encouraging players to jealously keep their users captive, avoiding open protocols and certainly not developing new ones (notice how application-level network protocol development and support started to dry up fast as FB and Google's money-printing machines really started to get going?).
I'd say the shortest path to fixing the Internet is making that illegal, especially since that activity is also horrible and dangerous for other reasons. Ideally, the same law would hamstring the credit reporting agencies and also keep banks and other financial institutions from using/selling your data.