I’ve been using mobile internet for last few years and whenever i would try to seed it’d be like 0.2 kb/s at best. I know that it’s due to my dynamic IP (or whatever it’s called) and i have closed ports.
Then i saw some people say that opening your ports makes your connection better/faster because you’re able to connect not only to people with open ports, but closed ones aswell. Does it make sense download-speed-wise? Because how could i take traffic from someone who’s unable to seed due to closed ports?
So, that’s an interesting point. A provider would need to know where to send traffic to, but the idea is generally that they run services from RAM with minimal logging and associate the port forward with your account ID (or some other sub-account ID). That would prevent them from having to record IP address info, but in truth if a VPN provider says they are no-log you are really just trusting them that they aren’t lying.
Even if they show they are 3rd-party audited, people need to understand that they KNOW when they are going to be audited and the scope of the audit. Its incredibly easy to game that system if you control how its done.
That being said, if you look at it observationally, people who use port-forwarded VPNs do not receive DMCA notices anywhere near the extent that non-VPN users do, and there isn’t any real DMCA notice discrepancy between port-forwarded and non-forwarded VPN services.
I mean you’re right in that in practice it might not mean receiving DMCA notices, but it has to identify you.
I mean you’ve been assigned the port, and your torrent client publishes that port on the tracker. Surely the port assignment can’t only be recorded in RAM, you’d have to change the ports configured in your client every few weeks.
I remember when Mullvad offered port forwards, it assigned you both a port and a key. My guess is that they simply authenticated the key to determine if the port should be routed to whatever tunnel established the connection. So, they would have to map that a dynamically generated key was assoicated to the port (and probably other bits of non-PII like datacenter/region), but nothing beyond that point outside memory. Even account IDs they generated were dynamic. In theory if you were able to guess the ID, you could use the account.
Yeah good point. Even when they offered port forwards, they would only do it with the once off payment accounts. If you set up a payment method against your account ID to be used each month then you couldn’t do port forward because the port number shown on the tracker could be linked to your card which could be linked to you.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !piracy@lemmy.dbzer0.com
⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.
So, that’s an interesting point. A provider would need to know where to send traffic to, but the idea is generally that they run services from RAM with minimal logging and associate the port forward with your account ID (or some other sub-account ID). That would prevent them from having to record IP address info, but in truth if a VPN provider says they are no-log you are really just trusting them that they aren’t lying.
Even if they show they are 3rd-party audited, people need to understand that they KNOW when they are going to be audited and the scope of the audit. Its incredibly easy to game that system if you control how its done.
That being said, if you look at it observationally, people who use port-forwarded VPNs do not receive DMCA notices anywhere near the extent that non-VPN users do, and there isn’t any real DMCA notice discrepancy between port-forwarded and non-forwarded VPN services.
I mean you’re right in that in practice it might not mean receiving DMCA notices, but it has to identify you.
I mean you’ve been assigned the port, and your torrent client publishes that port on the tracker. Surely the port assignment can’t only be recorded in RAM, you’d have to change the ports configured in your client every few weeks.
I remember when Mullvad offered port forwards, it assigned you both a port and a key. My guess is that they simply authenticated the key to determine if the port should be routed to whatever tunnel established the connection. So, they would have to map that a dynamically generated key was assoicated to the port (and probably other bits of non-PII like datacenter/region), but nothing beyond that point outside memory. Even account IDs they generated were dynamic. In theory if you were able to guess the ID, you could use the account.
Yeah good point. Even when they offered port forwards, they would only do it with the once off payment accounts. If you set up a payment method against your account ID to be used each month then you couldn’t do port forward because the port number shown on the tracker could be linked to your card which could be linked to you.