- cross-posted to:
- privacy@lemmy.world
- cross-posted to:
- privacy@lemmy.world
Even if you have encrypted your traffic with a VPN (or the Tor Network), advanced traffic analysis is a growing threat against your privacy. Therefore, we now introduce DAITA.
Through constant packet sizes, random background traffic and data pattern distortion we are taking the first step in our battle against sophisticated traffic analysis.
I love these guys. Let’s see if somebody can just bootstrap the FOSS framework directly on TCP to work on the internet without a VPN. Fantastic project
Those words sound cool and mean literally nothing
Bootstrapping See the Application section specifically.
FOSS = Free/Open Source Software TCP = Transmission Control Protocol VPN = Virtual Private Network
These words mean a lot actually. Pretty basic terms when it comes to the internet.
That means the same as fossing the tcp so it bootstraps your privacy.
See I can sound like a bot too. Or a journo.
I think they meant the comment as a whole doesn’t really make sense, it’s a bunch of technical terms kind of shoved together. If you understand it can you explain what it means?
Yes, the individual words have meanings, as words tend to do. Those words, in that order, form a NCIS, two people typing on the same keyboard, level word salad that has so little real world relevance that it tips soundly into the absurd.
NCIS?
https://youtu.be/kl6rsi7BEtk?si=VK0Mn-Ld2mVW85ev
Here is an alternative Piped link(s):
https://piped.video/kl6rsi7BEtk?si=VK0Mn-Ld2mVW85ev
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Err… Like… a 2009 Java applet? Those were built straight on TCP. And the lack of security let anyone else in the same LAN cafe steal your password.
The closest thing I can think of that goes for the vibe you’re talking about is I2P
I’m afraid just generating random traffic from your IP address won’t do anything against traffic flow analysis. Because most internet traffic is point to point, people who are interested in the flow, just follow the traffic moving between various points. So if you’re sending extra traffic to other random sites, it doesn’t interfere with point-to-point flow analysis.
In the context of a VPN, because all of your traffic is encrypted, you have to work harder to determine what traffic is going where. Because all traffic is going from your network to another virtual network. So an outside observer just sees the size and frequency of traffic but not the destinations. In this context since they don’t see the destinations, it makes sense to add random traffic flows, because that’ll obscure the signal that the observers are looking for.
Considering that VPNs are Point-to-point too (home->VPN), I was wondering if one could use DAITA with TCP directly instead of having to use a VPN. Imagine if TCP had DAITA baked in.
Even if you baked in variable packet size into TCP. It would be trivial for anybody monitoring network flow, to see you who you’re talking to. There would be no ambiguity.
The only reason this makes sense for a VPN, is there’s a lot of traffic bundled together, so a third party doesn’t actually know where your traffic flow is going.
Consider the example if you ran your own personal VPN endpoint. So you were the only user on the VPN. Even with randomized traffic flow injected into your VPN connection, it would be trivial for any third party who’s monitoring traffic flow to know that traffic is yours. Because you’re the only VPN connection talking to the VPN server. This thought experiment applies when you don’t have a VPN at all.
If I were to send packets to a single entity over time, I’d have no use for DAITA. I agree with you on this.
However, let’s say that I run a bunch of VPN endpoints across VPSes, and the entity trying to track me doesn’t know about all of these IP ranges. I could be renting from a colo, the cloud and even a a bunch of friends who have their ports open. If I were to mix this in with my usual internet traffic, it becomes significantly harder for third-parties to figure out what I’m doing connecting to all of these different IPs. A state actor could put the resources behind it, but the average third-party will have a hard time with it. I can certainly see use-cases for it.
I think we’re mixing up vocabulary.
Every IP you talk to is visible to anybody monitoring your network. The sale of net flow data is commonly acknowledged by ISPs. So every computer you talk to is common knowledge for sale.
In your scenario, let’s say you have five VPN connections set up to go to five endpoints that you control. But if nobody else is using those same endpoints. Your net flow data still exposes exactly what you’re doing. There’s no ambiguity. Your traffic is plainly obvious to anybody observing the network. Even if those VPN connections are adding randomized traffic onto the links.
Except that I will not necessarily be connecting to the exact same IPs over time, just going to do so in specific ranges which the VPS/colo owns. There’s plenty of people who are going to be renting VPSes and will have their traffic originate from the same IP range as mine, which means that if everybody using TCP had their traffic anonymized like so, the third party wouldn’t actually know that MigratingToLemmy specifically was connecting to AWS at a certain time and from a certain location, so to speak. This hypothesis doesn’t include correlation through other data in the threat model. But it could definitely prevent correlation with traffic across locations, which is similar to what Mullvad states
I’m sorry no. This will not help you avoid flow analysis
I think you both are talking past each other. You said “But if nobody else is using those same endpoints.” but @MigratingtoLemmy@lemmy.world said “There’s plenty of people who are going to be renting VPSes and will have their traffic originate from the same IP range as mine”. Reading this thread, it seems like you both have different network setups in mind.
What am I missing?