The disabled buttons should have tooltips saying “you need X karma to vote”.
I think you’re underestimating the difficulty in getting up to 100 karma.
Maybe 10 is okay for upvoting, but there needs to be a sufficiently high limit for downvoting, to stop the usual Eugine’s strategy of “post three quotes in rationality thread, get a few upvotes, and immediately use the karma to harass others”. Higher costs of doing things increase the cost of avoiding bans by making new accounts repeatedly.
Well, if they cannot even solve the existing problems, then I have to predict that the existing problems will continue to exist, duh.
A different solution would be okay too. But some solution is needed. And I violate the virtue of silence again by saying that as a determined user, I could ruin the website in a weekend, even without scripting. (With scripting, I could make a program that ruins the website at any moment at a click of a button.) Eugine is really picking just the absolutely lowest hanging fruit; and fixing that already creates about 50% of moderators’ work. Multiply this by ten, and LW will not have enough manpower to deal with the problems. A script could multiply it by a million.
When a user has admin on, they can see the list of users who upvoted or downvoted a comment in the tooltip (which currently shows % positive).
All karma calculations use a ‘weight’ variable that’s stored per user, and can be adjusted at the userpage by a user with admin on.
That means shutting down sockpuppets is two clicks, and discovering them is a mouseover. The main uncertainty is how the weight variable will impact the performance of the site.
The “weight” only needs values 0 and 1. And the value 0 can be achieved by disabling the buttons (which has negligible impact on performance) and removing the existing votes (which only happens one per user).
You need to define and specify the problem first. For example, you were saying that the 10 karma to gain the right to vote is too low—but e.g. in the weaponised scenarios that you mention the number of karma points is pretty much irrelevant. Setting this variable to 100 (or 1000) will not provide much defense.
As usual, step one should be to specify the threat model.
As usual, step one should be to specify the threat model.
I think describing it publicly in details is not a good idea. I have a model of attack which I believe is strong enough that within a day I could reduce your (or anyone else’s) karma to zero, without using my existing account (i.e. pretending that I am a completely new person, or that my old account was banned), and without scripting, assuming I spend the whole day doing this. With scripting, it is merely a question of clicking a button when the script is ready, and the script could be ready in a day or two. After having the script ready, the slowest part would be getting the first 10 karma for the new account, which is quite easy. Which is why I recommend making exactly this part more difficult.
After running the script, to undo the damage it would be necessary to find the account that did it, and make a script that removes all its votes. (Assuming the attack was done with one account. That’s not a reasonable assumption with scripting.) Judging by how “quickly” the support has reacting in the past, that would take about a month. Running the script again would take just one more click. Fixing the problem again would probably take a few days. There is a huge assymetry of effort. And with small modification, version 2.0 of the script could create hundreds of new accounts (now the slowest part would be the attacker typing the captcha for registering the new accounts), which would make defense impossible for a few months, until the necessary changes in code would be implemented.
All I am asking for is to make this vector of attack more costly, by increasing a fucking constant. What else am I supposed to do to convince anyone? Do I have to produce a working prototype of the scipt? There is already enough information here for anyone to connect the dots.
All I am asking for is to make this vector of attack more costly, by increasing a fucking constant.
My point is that increasing that constant is not a viable defence against the attacks. You are not putting up a roadblock, merely a microscopic speed bump that a capable attacker will not even notice.
You suggestion is like prohibiting passwords consisting of a single character. Will it help in the case of really stupid people? A bit. Will it help in the case of people actually likely to mount an attack? Not at all. Does it create the impression that you’ve “improved the security”? Yes, and that’s the worst part.
In theory, the only values defensible from the first principles are 0, 1, and infinity. In practice, the difference between an hour and a week can be significant.
Will it help in the case of people actually likely to mount an attack? Not at all.
Actually, it can make the attack without scripting quite expensive, and having to write and debug a script can be an obstacle for many people. For example, I am quite tempted to make a proof-of-concept script and fire it at you just to prove my point; and I have already written scripts interacting with websites in the past; but I am still quite likely not to do it, because it would take me a few hours of work. Procrastination, trivial inconveniences, etc.
You suggestion is like prohibiting passwords consisting of a single character.
I believe that CAPTCHA would be a better analogy, because it is an amount of work that has to be done by the user manually, before they are given access to the full functionality. More specifically, it is like changing a one-character CAPTCHA into multiple characters.
In practice, the difference between an hour and a week can be significant.
Sure, but why do you want to take a roundabout-karma way about it? If you care about slowing attacks down, make it so that no account younger than X days can vote. If you care about a sockpuppet explosion, implement some checks on the front end so that no IP address can create more than Y accounts in Z days (yes, proxies, but that’s another speed bump).
However I feel that all this distracts from a bigger point. LW is in crisis and some people even say it’s dying. This is not because LW is under siege from multiple accounts or sockpuppets. If Eugene goes away LW will still be in crisis. While I’m not in general a big fan of YAGNI, I feel that it’s appropriate here. Focus on important parts first.
There is more than one problem with LW. But for me this is just more reason to make one go away quickly by increasing a constant, and then focus on the remaining ones.
The disabled buttons should have tooltips saying “you need X karma to vote”.
Maybe 10 is okay for upvoting, but there needs to be a sufficiently high limit for downvoting, to stop the usual Eugine’s strategy of “post three quotes in rationality thread, get a few upvotes, and immediately use the karma to harass others”. Higher costs of doing things increase the cost of avoiding bans by making new accounts repeatedly.
Our design docs for LW v2.0 are not written by Eugine, are they?
Well, if they cannot even solve the existing problems, then I have to predict that the existing problems will continue to exist, duh.
A different solution would be okay too. But some solution is needed. And I violate the virtue of silence again by saying that as a determined user, I could ruin the website in a weekend, even without scripting. (With scripting, I could make a program that ruins the website at any moment at a click of a button.) Eugine is really picking just the absolutely lowest hanging fruit; and fixing that already creates about 50% of moderators’ work. Multiply this by ten, and LW will not have enough manpower to deal with the problems. A script could multiply it by a million.
When a user has admin on, they can see the list of users who upvoted or downvoted a comment in the tooltip (which currently shows % positive).
All karma calculations use a ‘weight’ variable that’s stored per user, and can be adjusted at the userpage by a user with admin on.
That means shutting down sockpuppets is two clicks, and discovering them is a mouseover. The main uncertainty is how the weight variable will impact the performance of the site.
The “weight” only needs values 0 and 1. And the value 0 can be achieved by disabling the buttons (which has negligible impact on performance) and removing the existing votes (which only happens one per user).
You need to define and specify the problem first. For example, you were saying that the 10 karma to gain the right to vote is too low—but e.g. in the weaponised scenarios that you mention the number of karma points is pretty much irrelevant. Setting this variable to 100 (or 1000) will not provide much defense.
As usual, step one should be to specify the threat model.
I think describing it publicly in details is not a good idea. I have a model of attack which I believe is strong enough that within a day I could reduce your (or anyone else’s) karma to zero, without using my existing account (i.e. pretending that I am a completely new person, or that my old account was banned), and without scripting, assuming I spend the whole day doing this. With scripting, it is merely a question of clicking a button when the script is ready, and the script could be ready in a day or two. After having the script ready, the slowest part would be getting the first 10 karma for the new account, which is quite easy. Which is why I recommend making exactly this part more difficult.
After running the script, to undo the damage it would be necessary to find the account that did it, and make a script that removes all its votes. (Assuming the attack was done with one account. That’s not a reasonable assumption with scripting.) Judging by how “quickly” the support has reacting in the past, that would take about a month. Running the script again would take just one more click. Fixing the problem again would probably take a few days. There is a huge assymetry of effort. And with small modification, version 2.0 of the script could create hundreds of new accounts (now the slowest part would be the attacker typing the captcha for registering the new accounts), which would make defense impossible for a few months, until the necessary changes in code would be implemented.
All I am asking for is to make this vector of attack more costly, by increasing a fucking constant. What else am I supposed to do to convince anyone? Do I have to produce a working prototype of the scipt? There is already enough information here for anyone to connect the dots.
My point is that increasing that constant is not a viable defence against the attacks. You are not putting up a roadblock, merely a microscopic speed bump that a capable attacker will not even notice.
You suggestion is like prohibiting passwords consisting of a single character. Will it help in the case of really stupid people? A bit. Will it help in the case of people actually likely to mount an attack? Not at all. Does it create the impression that you’ve “improved the security”? Yes, and that’s the worst part.
In theory, the only values defensible from the first principles are 0, 1, and infinity. In practice, the difference between an hour and a week can be significant.
Actually, it can make the attack without scripting quite expensive, and having to write and debug a script can be an obstacle for many people. For example, I am quite tempted to make a proof-of-concept script and fire it at you just to prove my point; and I have already written scripts interacting with websites in the past; but I am still quite likely not to do it, because it would take me a few hours of work. Procrastination, trivial inconveniences, etc.
I believe that CAPTCHA would be a better analogy, because it is an amount of work that has to be done by the user manually, before they are given access to the full functionality. More specifically, it is like changing a one-character CAPTCHA into multiple characters.
Sure, but why do you want to take a roundabout-karma way about it? If you care about slowing attacks down, make it so that no account younger than X days can vote. If you care about a sockpuppet explosion, implement some checks on the front end so that no IP address can create more than Y accounts in Z days (yes, proxies, but that’s another speed bump).
However I feel that all this distracts from a bigger point. LW is in crisis and some people even say it’s dying. This is not because LW is under siege from multiple accounts or sockpuppets. If Eugene goes away LW will still be in crisis. While I’m not in general a big fan of YAGNI, I feel that it’s appropriate here. Focus on important parts first.
There is more than one problem with LW. But for me this is just more reason to make one go away quickly by increasing a constant, and then focus on the remaining ones.
We’re disagreeing about whether increasing that constant will make the problem go away.