-
Notifications
You must be signed in to change notification settings - Fork 939
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent mechanical signups by malicious users #4307
Comments
What exactly are you suggesting? We don't have a magic wand... Presumably you are asking for a captcha? Which will have all the usual problems and probably also be a problem for the ongoing issues around third party authentication. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
We have #1083 "suppress creating accounts by bots/scripts" Is this or previous spam wave some share characteristics of accounts that could allow to detect or target malicious users, beyond blanket suppressing of automated account creation? |
#1083 has old (from 2015!) comment
has it changed? |
What exactly do you think I've been doing for the last few weeks but trying to apply such blocks - options are limited when faced with a determined attacker. A captcha is unlikely to help with the recent issues anyway as we long since stopped them doing bulk account creations and they now only create two or three at a time which can be done manually. |
In this case it was mostly directed at @SomeoneElseOSM to check is it intentional new issue or duplicate of #1083 "suppress creating accounts by bots/scripts" I am well aware about ongoing attempt to apply various blocks using available methods (though definitely not about all of them)
I seen it, so I assumed that "Prevent mechanical signups by malicious users" issue is about some other attack, maybe potential one. |
@matkoniecz The main reason why I raised this is because whatever we're doing as a project right now, it isn't good enough. Just in the last couple of hours we've had significant vandalism by at least 20495461, 20495462, 20499080, 20499083, 20499226, 20499230, and 20499223 (and possibly more - those are just the ones I've spotted). We cannot allow scripted signups like this for a couple of reasons - one is to prevent vandalism, but another is to prevent "clever" people adding data mechanically to OS without the person submitting the data ever actually seeing the Contributor Terms etc. - if someone has never read what data is license-compatible with OSM how can we be sure that the data that they submit actually is? Whether this is dealt with here or on #1083 I really don't care - but that issue has languished there since 2015. We absolutely shouldn't underestimate the effort that @tomhughes has put into trying to resolve this - the rate limiting introduced by #4198 has helped greatly. There is, unfortunately, still more to do. It does seem that the team working on this code is is vastly under-resourced - hence #3815, I guess . There are various ways that the root cause of that could be addressed (some discussed on that ticket, although I'm not convinced that "reviewing randomly-submitted PRs" - which is what it sounds like is happening at the moment - would really help). |
I would absolutely love to add a captcha to the signup, though not for the reasons you want them for because as I say I don't think it will help you at all. Experience tells me however that any captcha will not be acceptable to the community in general. Also they just don't work if https://elk.zone/en.osm.town/@[email protected]/111283441957439307 is to be believed. |
The way I think about captchas is: They are supposed to make it more annoying to do things for bad actors. But they cannot prevent someone who is really motivated to get in. However, increasing the barrier is still worth to filter some segments of bad acting. I think about them like bicycle locks: They are all unsafe. It's more about how long it takes to pick them. Having one lock prevents some segment of thefts (opportunity thefts). Having two locks makes it annoying and prevents another segment of theft. But once an experienced thief comes along, the bike is gone… At betterplace.org we used the invisible Recaptcha (by Google) in this spirit. It made things very annoying for the less informed bad actor while still preserving a great UX for regular users. I don't think Google (Invisible) Recaptcha is an option for us due to privacy topics. However, maybe a service like https://friendlycaptcha.com/ is something to look into. |
My proposal would be to delay sending out confirmation emails by up to 24 hours ("...for technical reasons..."), giving admins enough time to spot suspicuos patterns, with the option to remove those users early on. |
Absolutely not. That would prompt my immediate resignation. |
Oh, ok. Is your concern that angry folks start filling up your inbox, because they can't start mapping right away? |
Mapping parties and HOT and many other events have large groups of new signups. Holding accounts would not be the best route for engagement. |
Absolutely. We already get a few people emailing us when the confirmation hasn't arrived 30 seconds after they signed up so there is no way I will be processing the tech support queue in OTRS if we make them wait 24 hours. |
Do you have any evidence that these are scripted signups? Half a dozen accounts is not too many to sign up for. It's only a barrier if you need hundreds of accounts. I'd still like to prevent mechanical signups, but I don't expect it will help with the current issues. |
The speed of accounts being created before rate limiting was introduced (1000s of users) suggests yes. After rate limiting, we're still seeing some sequential examples (like 20495461 and 20495462 above), suggesting scripting.
I don't think a fixed 24 hour delay would be a good idea for all sorts of reasons, but surely we could do something - perhaps another queue in OTRS just for simpler things such as "approve a self-deletion request", handled by more people? |
That is the whole point though - we have limited them to extent that even if they aren't currently doing it manually they could do so. So yes it might be automatic AT THE MOMENT but 24 hours after we add a captcha they'll just switch to doing it manually and we'll be back where I started. So it would be much more useful for me to spend my time on rate limiting edits that on rate limiting accounts. You just seem to be totally incapable of understanding that forcing me instead to actually spend my time repeating myself endlessly here and on IRC. |
Both things must to be implemented to be effective |
WE ALREADY ADDED RATE LIMITS TO COMBAT AUTOMATIC SIGNUPS. I am now going to unsubscribe from this ticket in the interest of preserving my sanity. |
URL
https://community.openstreetmap.org/t/how-about-limit-new-accounts/101656/237
How to reproduce the issue?
Whilst the rate limiting introduced at #4198 is still working, we're still seeing "entirely mechanical" signups by malicious users.
It should not be possible for someone to script the OSM signup process in this way. The effect is not directly related to, but the effect is compounded by, #4018 . A user signing up to OSM must have demonstrate that they are a real human being actively managing the signup process, reading and understanding the contributor terms, etc. The signups that we're seeing (often of consecutive userids) suggests that this is not the case.
I appreciate that there is pressure from elsewhere (see e.g. #4288 ) to reduce signup interactivity. This request doesn't necessarily contradict that, provided that the external sites that that pull request is designed to help can provide similar "this really is an interactive signup" information.
The text was updated successfully, but these errors were encountered: