581–590 of 618 posts
Earlier quoted context omitted.
Look at Apple’s PAT: the website knows the service that did the attestation, but not the user. The service knows the user, but not the website. If you controlled both you can link the user, but otherwise you can’t.
Yes, but they can still collude. It's possible to do age verification in a way that prevents that. Look e.g. at Privacy Pass.
Earlier quoted context omitted.
As far as I know no currently proposed age verification method does this in practice. The only way to implement truly privacy preserving age verification is through zero knowledge proofs (or blind signatures) but what that would allow is undetectable token forging.
The EU's proposed system uses ZK proof. You get a PGP signed message from "someone" who knows your identity (government or private agency) then store it on your phone to pass to websites that need your age. It does have an obvious flaw in that whoever you give the token to has no proof it's actually yours. https://ageverification.dev/av-doc-technical-specification/d...
Because what you described does not preserve your anonymity if the government and the service collude.
Earlier quoted context omitted.
What happens when I set up a tor hidden service that (in conjunction with some client software) stands in for a visitor's device and will proxy any requests back to my personal card? After all the payloads are anonymous so what's the risk to me?
To prevent this sort of abuse, the server would have to request the `pseudonym` field, which contains a hash across the server identity and the card's secret salt, allowing the server to detect abuse but not to track the user across multiple services.
It would probably be possible to use the service that the parent is suggesting and try to link it to requests to the server based on timing. But I don't even know if anyone would bother trying to identify the OP: probably it would just be enough to rate-limit the requests.
As always: it's easy to criticise, harder to actually get it right.
Earlier quoted context omitted.
Parental controls are intentionally gimped. They do the bare minimum while providing more than enough wiggle room for a tech savvy teenager. To implement a robust parental control scheme you need network level filtration which isn't something the average parent will know anything about.
I disagree with that, because the teenager should be the parent's responsibility, regardless of how smart or savvy they are. Parents should be talking to their children, communicating what their and society's expectations are. If the parents are attempting to exert technical control over their children, by home router for example, there should be websites or computer shops they can go to. If the parents don't care or…
From what I remember from being a kid myself, it definitely is not.
Earlier quoted context omitted.
Not sure how that's relevant. There are computers now . Regulations change with the times. Green lasers weren't controlled in the 1700:s either. Are you comfortable with anybody being able to ring up the hospital and say "yo, it's majorchord, how are my gonnorhea results?"
> Are you comfortable with anybody being able to ring up the hospital and say "yo, it's majorchord, how are my gonnorhea results?" No, that's why we have safety protocols in place. When you call a doctor they ask you for your birthdate or sometimes also a PIN/password on your account to protect your data. How would that still be considered a breach of privacy?
But giving birthdate (available to anyone via a single query in a public database) and (sometimes?! - what?!) PIN over the phone wouldn't really be considered good enough here. Birthdate is, as I said, public knowledge. And a phone is too insecure a medium for transmitting a password.
I'm not super interested in an long argument about whether it's reasonable that this isn't considered secure or not. I'm just letting you know what reality looks like. And the reality is that "just call them" is not a solution, because such information will simply not be handed out over the phone.
Earlier quoted context omitted.
I imagine an agent would make a lot of the first time setup from scratch easier, but the fastest reliable way to get up and running is mail-in-a-box or mailcow. Before those were available I built a flurdy style Postfix+Courier+Amavisd+MySQL setup and have been evolving it ever since. Now I'm on Postfix+Dovecot+rspamd+MySQL but I don't think that's for everyone or even the best way to start. The science of not gettin…
For the people who's mail service blocks you and they cannot or will not change their mail provider, what is your solution?
If you use mailgun or similar you have to setup dkim keys for them and add them to your spf.
Eww. Ok, so, I’ve used reCAPTCHA on sites I maintain at work, just on forms to prevent excessive bot spam submissions. No way do I want to subject users to this BS, though. Does anyone have recommendations for other decent captchas that could be used instead?
I did something unpopular and just didn't have a captcha, I just read up on creepjs etc and rolled out my own which is just browser state analysis, basic ip check (abuse lists only) and PoW. Haven't had an issue with a single bot registration (yet).
Cool! I would like to hear more about this, and understand how to do the same.
I did something unpopular and just didn't have a captcha, I just read up on creepjs etc and rolled out my own which is just browser state analysis, basic ip check (abuse lists only) and PoW. Haven't had an issue with a single bot registration (yet).
A simple captcha with distorted characters + some hidden form fields would stop every single "opportunistic" bot. There's hardly anything you can do to stop someone determined enough to spend money to spam your specific website. These kinds of captchas do raise the bar somewhat, but every single one of them is ultimately bypassed by paying people to solve them for you.
bots get pruned after an hour since 100% of the bots fall into the same trap, giving it a delay makes A/B testing really difficult and breaks most AI strategies.