SoylentNews is people
SoylentNews
from the stifle-opposition-quash-free-speech-and-muzzle-expression dept.
Internet shutdowns by governments have 'proliferated at a truly alarming pace':
The number of government-led internet shutdowns has exploded over the last decade as states seek to stifle dissent and protest by limiting citizens' access to the web.
Nearly 850 intentional shutdowns have been recorded over the past 10 years by nonprofit Access Now's Shutdown Tracker Optimization Project (STOP), and although the group acknowledges that data on incidents before 2016 is "patchy," some 768 of these shutdowns took place in the last five years. There were 213 shutdowns in 2019 alone, with this figure ticking down to 155 in 2020 as the world adapted to the COVID-19 pandemic (which delayed elections and led to lockdowns that kept populations at home more often). And already in the first five months of 2021 there have been 50 shutdowns across 21 countries.
"Since we began tracking government-initiated internet shutdowns, their use has proliferated at a truly alarming pace," Access Now's Felicia Anthonio, campaigner and #KeepItOn lead, said in a new report on the issue in The Current, a publication of Google's internet thinktank Jigsaw. "As governments across the globe learn this authoritarian tactic from each other, it has moved from the fringes to become a common method many authorities use to stifle opposition, quash free speech and muzzle expression."
(Score: 0) by Anonymous Coward on Sunday September 05 2021, @08:57PM (18 children)
The sad fact of the matter is, only an entity with the scale and power of a government has the necessary funding and institutional backing for major infrastructure projects, and governments are not in favor in decentralizing anything.
(Score: 5, Insightful) by Opportunist on Sunday September 05 2021, @09:04PM
The only reason we have the internet in its decentralized form... or rather, we had, was that the government was scared that there's an enemy powerful enough that it can do a decapitation strike, so that's why it wanted a sufficiently resilient decentralized network.
Since that enemy doesn't really exist anymore, there is no governmental interest in not having everything in their grasp.
It's time for China to become threatening again to again make governments feel that it would be a good idea that a decapitation cannot happen.
Kinda strange to think that Soviet Russia was one of the cornerstones for our freedom. As long as they existed, our wannabe-dictators had to pretend they're the good guys.
(Score: 0) by Anonymous Coward on Monday September 06 2021, @12:48AM (16 children)
Not true. A project like this could be done by a few hackers with tin cans and modems. And then expanded on an as-desired basis. It could even be piggybacked over the internet for long haul - why not? If the contents of the packets are opaque, it'd be pretty straightforward.
The problem is the nobody-gives-a-shit level. I've already done the mathematics and design, decades ago. But everybody told me the internet would always be free and route around damage forever because we can trust Uncle Sam...
(Score: 0) by Anonymous Coward on Monday September 06 2021, @02:07AM (15 children)
Well, cough it up, big shot! Don't bogart that joint...
(Score: 0) by Anonymous Coward on Monday September 06 2021, @04:25AM (14 children)
OK, assuming you're actually interested on a technical level and not just another time-waster: The central challenge is that you do not, and can not know what the topology of the network is aside from your direct connections, because even if you did, it might change at any time. In general this is a pain in the arse because it means that no routing table withstands scrutiny for long, and route usage has to be based on a combination of past information plus current discovery. You'll notice that if you can solve for this, you also solve for chokepoints because a new route that can be discovered works whether's the official AT&T route, or Bob the Hobbyist with a cantenna and a wild look in his eye.
The next challenge is how you handle name and address collisions, because you must assume that they can be deliberately created by bad actors. You need a disambiguation system, as well as an ad hoc technique for setting up that infrastructure without a central (or even decentralised, but effectively delegated) authority handing out names and addresses.
There's quite a bit to the naming/addressing thing, but to I'll cut to the meat of the matter, that at its heart public/private keys give you a last line of spoofing defence, so the public ones have to be part of the naming infrastructure. Given out-of-band options for verification, this is pretty effective.
The question of routing comes down to figuring out how much smarts your machine needs. Interfaces are a legacy approach of the IP way of thinking; they have been used to create virtual identities, but honestly they're not very helpful. What you want is to reach a given destination, and how you get there is moot. This still supports virtual machine identities, because you can host them on a given real host. So then you start by figuring out how tough the routing choices are that your machine has to make, and its level, so to speak, of routing intelligence. A degenerate case is 0 connections to other machines; any packet is either local or dead. Slightly higher: only 1 connection. It's either for local, outbound, or dead. Higher yet: two connections. It's either for the local environment, passing through, or outbound - and this is the lowest level where some kind of choice is to be made, because it could go out one way or another. This prompts a route discovery, which is related to (but not identical to) what used to be called a "big shout" looking for the destination.
There's a lot more to this, even though it's algorithmically simple, because you'd actually start with routing hints where available. The naming system has, not merely a record of identity and verification (key) but also a routing hint that would be familiar to people who still remember UUCP. This is no coincidence, because UUCP solved a pretty similar case. This reduces the hunt for a grain of sand on a beach to a pebble in a pile.
This isn't a good forum for laying out the whole damn thing, but if you're genuinely intrigued, you can respond with questions and so on.
Bear in mind, this isn't supposed to be efficient in the ideal case - it obviously isn't. It's supposed to be functional in a hostile case, which is where we're going.
(Score: 0) by Anonymous Coward on Monday September 06 2021, @05:12AM (2 children)
I took a quick glance at the routing section of the RFC for UUCP and I think I have a general idea of what you mean when you talk about routing hints, but a little more clarification would be helpful. How do we prevent source/destination filtering between endpoints with a malicious network operator? When it comes to discovery, is there a way to avoid TCP/IP's naive approach of relying on "politeness" and dumb routing when hints are not enough to generate a clean route ahead of time?
(Score: 0) by Anonymous Coward on Monday September 06 2021, @04:08PM (1 child)
OK, a couple of questions packed together.
"How do we prevent source/destination filtering between endpoints with a malicious network operator?"
Answer number 1: You don't. You can't. If the government of Shariastan is palpitating with horror at the idea that you might be seeing decadent western beach pictures, and they look for destination addresses of beachpics.XXX to drop those packets on the floor, you can't prevent them from doing so. However, if Shariastan does so, but the wicked Russian Freedom of Speech collective sets up alternative networking through a satellite, or powerlines, or whatever, then that alternative route will be discovered because requests for beachpics.XXX suddenly do start returning through it. The government of Shariastan can't even know that such traffic exists without trying it itself, and reverse-engineering the route step by step. They can't cut off addresses, because they don't control them. They can't withhold naming because they don't control that. They can't revoke keys, because they don't control that, and as long as some dissidents are willing to put up links, those will keep popping up like bittorrent sites in the wake of a takedown wave.
Answer 2: The equivalent of VPN servers would be trivial to create, because the ability to pop up a virtual server, assign it a name and number and just have it act as a router, unwrapping and forwarding, inside encrypted connections, is basically baked into the founding assumptions of any such network protocol. "Someone sent me a packet. Unwrap - it's another packet for someone else. Toss it in _that_ direction." The VPN doesn't even have to know with any clarity what the source was, or be able to decipher the contents.
Bear in mind that a given packet only needs, in principle, a destination and a payload. You could add some network management data elements if you like but a source is not a requirement for a pass-through node to perform routing. This means that performing naive source/destination targeting isn't possible, and even tracking things like sequence numbers doesn't work if they're in the encrypted payload. Pulling stupid webcache tricks to inject advertisements is right out because you don't even know that the traffic is web traffic, let alone what the content is.
"When it comes to discovery, is there a way to avoid TCP/IP's naive approach of relying on "politeness" and dumb routing when hints are not enough to generate a clean route ahead of time?"
Yes and no. The direct analogy of TCP/IP's default or fallback routing processes doesn't quite apply in most cases because, aside from "outbound, not local" there kind of isn't a default route.
But here's a bit more of a breakdown on that. You and all the kids from school got soup cans and string, and set up primitive modems to wire up your suburb. It works, cool, with only a 58% packet loss rate, at 300 baud! Amazing. You want to send a message to Suzie.hot.library.grrrlz, and ask her what she's doing on Friday. You are pretty sure she's online, and your little computer is hooked up to Bobby's, kitty-corner to your place. In the first instance, it's easy. Your computer checks its cache, and determines that you never had the balls to talk to Suzie before, so it's not locally cached at all. Your computer sends a request to Bobby's.
Bobby is a real social animal, so his computer has four outbound links (not to mention his parents have a large plot of land bordering several others). Two of those are leaf nodes, including yours, but two connect to other people with more connections of their own. How does Bobby's computer know this? Because when the computers establish a physical and logical connection, they communicate an identity and also the complexity of their own network context. Ergo, your computer told Bobby's: "I'm JoesRPi, level 1" while his told yours "I'm BobsAmiga, level 4". Extend this principle, and Bobby's computer can tell that when and if it doesn't have a route, it has two non-leaf connections through which it can request remote data.
However, there's a wrinkle. You're not just asking to talk to Suzie, because there's more than one Suzie in school, and you are kind of scared of Suzie.cheer.queen.bitch, not to mention her attitude turns you off like a switch. So your request isn't just Suzie, as a computer name, but Suzie's computer in a naming context. So the first request that REALLY goes out is of the order of a DNS query. Cutting a bit of this already long story short, the DNS query returns with:
suzie.hot.library.grrrlz - computer ID 12345 - public key 54321 - routing hint 67890
Bobby's computer doesn't need to know, necessarily, how to reach 12345. In fact, it probably doesn't because as luck would have it Suzie the library grrrl has a leaf node computer as well. Just not that much traffic for her flows through Bobby's node. However, 67890 is a node belonging to Steve the Supernerd, which has five leaf connections and three trunk connections, and to which Suzie's is directly connected. Bobby's machine knows, or can _very_ rapidly find out from the cached data of neighbours (in a network with any stability, this sort of data propagates very rapidly, depending on assumptions) where to find Steve's, and Steve's knows where to find Suzie's.
Putting it in more prosaic terms, you ask Bobby if he knows Suzie, and he says naww, but if Suzie knows Steve he knows Steve, so yeah, they can get you together. Success!
(Score: 0) by Anonymous Coward on Tuesday September 07 2021, @04:19PM
Next question:
Does anybody give enough of a damn about any of this to actually work on an implementation?
So far, judging by the response, the answer is a firm "no".
(Score: 2) by c0lo on Monday September 06 2021, @06:33AM (6 children)
You resolve trust between discussing over net but never physically meeting IRL ... exactly how? Because otherwise everything is just handwaving.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Monday September 06 2021, @03:23PM (5 children)
Same as it ever was. Out of band communications. Many ciphers depend upon them - for example, OTP. If you really, really REALLY need to know that you're going to be getting only authorised kitten pictures from Kittenpics.XXX, then you absolutely have to have independent verification of their public key, which you can then, at your option, include as part of your name search to make sure that the diabolical powers of Puppypics.XXX haven't spoofed the local naming system, the local addresses and pre-empted the valid response coming from Kittenpics.XXX.
(Score: 2) by c0lo on Monday September 06 2021, @10:25PM (4 children)
Then your internet is not a replacement for the current internet and the two will need to coexist, because your internet is inherently much poorer in regards with the possible interactions, no e-banking/e-commerce as the first two.
I always rely on trusting a DNS to resolve the name of my bank. If you replace it with certificates (or shared secret or whatever crypto handwaving), I'll need to store an immensity of them and deal with their expiration.
Ummm... yeah. Try explaining to me a decentralized ebay next.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Monday September 06 2021, @10:38PM (3 children)
Wait ... waitwaitwait.
You think the current internet solves that? For real? For realsie-reals?
HAHAHAHAHAHAHAHA.
I'm sorry. That was so rude of me. Heehee. I mean, unforgivable. Hahahha.
Let me put it this way: if you trust the current DNS infrastructure, then you should be just peachy-keen a-OK FINE with a distributed approach to naming with a foundation of identifiable nexus servers.
But you do you, I guess.
(Score: 2) by c0lo on Monday September 06 2021, @10:44PM (2 children)
Read more on trust [schneier.com]. It's always a compromise.
Move the balance towards paranoids and only the paranoids will use your internet.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Monday September 06 2021, @11:33PM (1 child)
Compromise is available. For folks like you, trusting what you get back from a regular query is just fine, now roll over and go back to sleep while Big Brother's Little Sister rubs your back.
For the paranoid, out-of-band verification, multi-factor authentication and all that stuff is still there.
(Score: 2) by c0lo on Monday September 06 2021, @11:58PM
I survived a communist regime and its secret police for 25+ years.
Use your technology and stick out as a sore thumb, just prepare yourself for a $5 wrench attack on your or your close contacts' multifactor authentication. Also keep in mind the situation is dynamic and can change in any minute.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Tuesday September 07 2021, @07:33PM (3 children)
On the contrary, as a tech site this is the precise forum, to discuss technique instead of arguing stupid politics that distracts everybody's attention.
Personally, I would like to "broadcast" my signal, and the guy with the "key" will pick up, but how do I hide my "transmitter"? Plus we need hardware just just passes a signal regardless of content or protocol. The pipe itself has to be truly passive
(Score: 0) by Anonymous Coward on Tuesday September 07 2021, @08:03PM (2 children)
If you're just broadcasting, and everybody's just broadcasting, you start to run into bandwidth problems pretty quickly, especially in a routed network because of exponential growth of the number of links; it's like a massively parallel breadth-first search.
You also, under that assumption, can't hide a transmitter because anyone who can pick up the transmission can deduce that the transmitter exists, and a fair amount about it. Best case, you scream an encrypted message that only the intended recipient can decrypt, and verify that you're the source, but at layer 0 a source can still be traced.
And passive pipes do exist; traditionally they were made of copper wire although optic fibres exist as well these days. The problem is that the moment you want to apply discrimination to routing so as to conserve shared resources, you need to bolt some smarts onto your passive pipe. However, a properly self-managing system should be able to have set-and-forget routing nodes as elements.
(Score: 0) by Anonymous Coward on Wednesday September 08 2021, @03:26AM (1 child)
And there still needs to be a physical meeting to exchange keys, gotta use one time pads, right? I think a partial solution is intermittent connections, or some sort of "spread spectrum" scheme, switching addresses at irregular times, and piggybacking on the noise, but, how do you sync?
(Score: 0) by Anonymous Coward on Wednesday September 08 2021, @03:28PM
You don't necessarily have to meet physically, but there are workarounds. Depending on what you intend to do, it could be a physical mail, or even an advertisement in a newspaper. It depends on the context of the intended communication.
As for what you're talking about, look up ratcheting ciphers.