I built Servury because I was tired of seeing “privacy-focused” services that still collect everything. The tipping point was realizing that even after all the GDPR regulations and privacy scandals, most companies are STILL using “we care about your privacy” as marketing while their architecture makes privacy impossible.
I wrote this post because the HN/tech community needs to understand the difference between privacy promises (marketing) and privacy architecture (engineering). Too many people think they’re anonymous because a service SAYS they don’t log, when the service could easily lie or be compelled to hand over data.
Mullvad proved it’s possible to architect your way out of surveillance. I wanted to show that this applies beyond VPNs - to any service that actually gives a shit.
Quite interested myself into selling things to people without asking anything to them but I am mostly curious about regulations/legal concerns where I could need to KYC.
I honestly don’t care and rather not but I guess the money laundering concern could be a thing when checked by the taxes entity.
Maybe a follow-up question here. You do allow a login with a simple 32 chars string, I then assume that you use quite a strict throttler to limit the amount of tries from the same IP?
You never got any concern on that topic of people trying to sneak up on other’s account by trying it slowly over time and rolling their IPs?
Could the usage of Passkeys be considered to maybe add a 2nd factor while still asking for no PII?
Same, asking because I want to do the same approach haha.
Currently, we do not ask for anything because the service is only a few weeks old, but as you said, I will probably have to ask for a country on the order page for regulatory reasons.
Not sure if that would be legal, but we could say that this is strictly for legal purposes, and that nothing can stop the customer from entering a bogus country. After all, what is the point of checking the user’s selection against browser language locales and IP when both of these can be manipulated?
Actually, we used to, and then I realized this went against the whole model, it required me to keep record of IPs in one way or another, so no, we do not have that, and I’m not sure what you mean by “limit the amount of tries from the same IP?“, if you’re implying the risk for bruteforce attacks, I invite you to check the amount of possibilities for a 32 character alphanumeric lowercase string.
≈ 6.33 × 10⁴⁹ possible strings
≈ 165 bits of entropy
This is the reason why I chose the authentication model to work as such, because in the case of mullvad, the 16 digit authentication model, while still having an extremely high number of possibilities, is still viably bruteforce-able, especially in the case where a threat actor would use distributed bruteforce as a means of breaking into people’s accounts.
Have you considered using passkeys instead of random account numbers? idk about everyone else but I always end up just pasting the number onto a text file on my desktop or something (my password manager doesn’t really let me have a note without an associated account), I’d imagine passkeys would be more secure since the user isn’t expected to handle a raw string of text and keep it secure themselves.
Here’s the official FIDO documentation. Some of the points you brought up in your article about email being an identifier I brought up in an article I wrote a bit ago:
Basically I believe that email is mainly used because of the deficiencies of passwords, and passkeys can eliminate the need for email account signups. With passkeys, you can’t forget them and by default they will be synced with E2EE in the cloud in most people’s password managers so there won’t be a need for a recovery method.
This site has a guide on implementing them as well, apparently it’s the officially recommended one.
You opting out of collecting IPs isn’t “anonymity by architecture“, that’s just metadata-privacy by policy. So a guide for Tor-only use is definitely needed.
I’m glad to see you have link to the Tor Onion Service front end so you know that’s a thing. I’m a bit puzzled why you’re not advocating Tor as the primary way to enforce anonymity. Also, the link is probably just down and not performative, but this isn’t exactly backing the “99.9% uptime guaranteed” claim.
I’m opting out of collecting any kind of data which is not necessary for me to offer my services, unlike others, which would ask for names, KYC, e-mail, phone number, country, etc, this is what my blog post is about. I would argue that is an architectural choice.
I went ahead and updated the onion link in the website footer, thank you for pointing that out. Unrelated, but I plan to set up a canary soon, backed by a PGP key.
That’s a lot indeed, but the more customers you have the more collision risk there will be to a point where you could end up on somebody’s account by cheer luck.
I do acknowledge that it is very unlikely but depending on what you sell, might still be quite a huge issue.
Again, there are probably ways to still double-check that you haven’t entered somebody’s else account that I am not considering.
I’m a bit sad that you totally skipped that part of my previous message where I asked pretty much the same question as @fria but eh, it’s mentioned anyway so I’m happy.
Might definitely be a bit more complex/niche but the benefits are quite nice too and they do go one step further on the “I don’t want to know anything about you, at all”.
Saying it’s “architectural” is downright misleading. It’s policy based security because what you’re doing when enacting the policy change is just flipping a boolean, uncommenting a function call on server side or at worst, you add the missing logging function (below) and call it.
def log_to_file(path, user_id, ip_addr):
with open(path, "a") as f:
f.write(f"{get_timestamp()} : {user_id} = {ip_addr}\n")
That’s all it takes. That’s how a policy decision is conveyed into the server-side code. It undermines every claim and users will be none-the-wiser.
You don’t get to call messaging app end-to-end encrypted if you delete plaintext copies on server-side (hopefully) before reading them. The same way you don’t get to argue privacy-by-design with systems where the user has no way to check that the behavior is enforced by code the user controls.
Don’t get me wrong. Privacy by policy is absolutely fine. Just be open about it. Don’t oversell it. Be upfront about it in your threat model. Put that threat model on front page. That way it’s so good it can’t be ignored.
Helps against your government issuing a subpoena. Does nothing about the government next to yours hacking your system, and exchanging that data with your government. The only way to keep data secure, is to not collect it at all. Data Is a Toxic Asset - Schneier on Security
I am pretty sure I just successfully implemented passkey registration / authentication.
But this raises a concern, should I allow users to add other passkeys from other devices to log into their account, and if so, what kind of flow would be best?
Yes the guidance is to allow multiple passkeys. FIDO has some guidance on this, basically the UI of the credential manager/OS will handle multiple passkeys on sign in. In the account settings, you should have what they call a passkey card that lets them manage their passkeys.
They have some examples here showing how it should look. They also have a directory of services that support passkeys if you wanna check them out.
Hope that helps, I’m very excited to see a possible passkey-only service. I would definitely link to your site as an example to follow.
that you totally skipped that part of my previous message where I asked pretty much the same question as 