2 ms·
yeah the account number is basically the mullvad model, 16 digits, no email no password. its a tradeoff, i know some people hate it. login is rate limited serve
by lobito25 2mo ago
yeah the account number is basically the mullvad model, 16 digits, no email no password. its a tradeoff, i know some people hate it. login is rate limited server side so you cant just sit there hammering numbers at it. is it weaker than a long passphrase? probably yeah. the flip side is theres no personal info sitting in a database for someone to leak, or for someone to show up with a subpoena for.
on the local network point, thats only your own devices seeing each other. traffic between different customers is blocked.
logs, our thing is reactive, we're not sitting there watching everything. we act when we get an abuse report. some of it is just blocked structurally anyway, port 25 is closed so no spam is coming out of there. and we keep zero logs. child abuse material, account gets terminated if we get a credible report or a legal notice, but we dont proactively scan, thats not really possible when the traffic is encrypted and theres nothing logged to scan in the first place. the only thing counted is aggregate bytes per account for the quota and the trial. not what, not where.
and honestly, this is a one person project. code needs cleanup, secrets and config need to come out, and it needs a proper security pass before its safe to publish.
- akerl_ 2mo agoThe difference is that Mullvad doesn't enable any east/west connectivity at all. If somebody guesses a user's Mullvad 16 digit number, they can use Mullvad's services as that user. If somebody gets a SmokeVPN users's 16 digit number, they can connect to that user's other devices. How would you take any action with an abuse report and no logs? You'd get a report or subpoena or similar that listed an egress IP and a timestamp and say "We need information on this user for this charge" or "You're ordered to halt this illegal traffic", and you'd not have any way to tie that out to a specific user retroactively. There are plenty of providers who take the stance that they don't log and thus effectively cannot prevent or restrict illegal or abusive activity. I'm just not understanding how you could claim to both be logless and restrict those things.
- deleted 2mo ago[deleted]
- deleted 2mo ago[deleted]
- deleted 2mo ago[deleted]
- deleted 2mo ago[deleted]
- deleted 2mo ago[deleted]
- deleted 2mo ago[deleted]
- lobito25 2mo agoYou're right on both counts. My Mullvad comparison was focused on the credential, not on the LAN model. Brute forcing the account was never the issue, I missed the point about device-to-device was the real threat, fair point. I'm starting implementing LAN connections as opt-in, not default. Second point, you're also right, because I was mixing prevent and identify, preventions shouldn't need logs, we can't take an IP address and a timestamp and attach a user to it, and the AUP imply something else, I'll rephrase this.
- lobito25 2mo agoFor completion, I decided to make device to device connections an opt-in feature that requires 2fa enabled to log into the account. AUP was also rephrased to make a clear distinction between prevention and identification.