5 ms·

Say I wanted to know your salary. I could start a secret and enter the minimum minus one before I send you the link. Is there a way to prevent this sort of sce

Say I wanted to know your salary. I could start a secret and enter the minimum minus one before I send you the link. Is there a way to prevent this sort of scenario while letting the service remain anonymous?

zerr 13y ago
Maybe show the data after some minimum number of persons participate?
narcissus 13y ago
That's a good point and not something I had thought about to be honest. I guess the whole "bad actor" thing didn't play into how I expected the site to be used. Which is a terrible response, I know! Out of curiosity, are there ways I wonder to actually try and stop this? I mean there are obviously ways to deter it, but is there a way to stop it outright I wonder? I'd have to guess no, but then again, I am definitely not the right person to think about this.
- aiiane 13y ago
  You can display the # of items already entered and the timestamps they were entered at (but not the values). It's not perfect, but it would help eliminate the "pre-loading" attack. However, that still leaves the "post-loading" attack, where you send someone a blank link, and then afterwards, fill in the other entries with known values.
  - narcissus 13y ago
    That's cool. I can definitely do that and then maybe put a message about options for if you don't completely trust the person that sent you the link... Thanks!
  - hmsimha 13y ago
    This (and the other suggestion by zerr) still leave the potential for someone to create multiple false 'minimum' datapoints, then target one of their coworkers to find out their salary.
    - aiiane 13y ago
      Yeah, it's not at all foolproof or even great. I don't think there's really a good solution that still provides true anonymity, since the only way to prevent box-stuffing is to actually restrict people to one entry per real person (and that generally requires a more involved real-world authentication process).
- hmsimha 13y ago
  You could mention that kind of misuse on the page where users enter their code, and suggest they don't enter their salary information unless they are aware that the code was displayed somewhere publicly (yet anonymously) in the company (like a company bulletin board or sent out to a list of company emails from a dummy address, where you can vet that the other addresses it was sent to were your coworkers). That way, no one has any way of knowing which datapoints match to which of their coworkers.
- DanielStraight 13y ago
  If the size of the group is known, just generate one-time use codes equal to the number of people in the group and have the survey creator distribute them. If any code is attempted twice (such as if the survey creator uses your code before you can), trash the whole survey. Then, only display the results when all codes are used. This doesn't prevent several people from colluding, but it does seem to prevent anyone from acting alone to mess with the results of the survey.
- laurenia 13y ago
  Assuming you don't get too many 'bad actors' showing the mean and the median would help.

zerr 13y ago

Maybe show the data after some minimum number of persons participate?

narcissus 13y ago

That's a good point and not something I had thought about to be honest. I guess the whole "bad actor" thing didn't play into how I expected the site to be used. Which is a terrible response, I know! Out of curiosity, are there ways I wonder to actually try and stop this? I mean there are obviously ways to deter it, but is there a way to stop it outright I wonder? I'd have to guess no, but then again, I am definitely not the right person to think about this.

aiiane 13y ago
You can display the # of items already entered and the timestamps they were entered at (but not the values). It's not perfect, but it would help eliminate the "pre-loading" attack. However, that still leaves the "post-loading" attack, where you send someone a blank link, and then afterwards, fill in the other entries with known values.
- narcissus 13y ago
  That's cool. I can definitely do that and then maybe put a message about options for if you don't completely trust the person that sent you the link... Thanks!
- hmsimha 13y ago
  This (and the other suggestion by zerr) still leave the potential for someone to create multiple false 'minimum' datapoints, then target one of their coworkers to find out their salary.
  - aiiane 13y ago
    Yeah, it's not at all foolproof or even great. I don't think there's really a good solution that still provides true anonymity, since the only way to prevent box-stuffing is to actually restrict people to one entry per real person (and that generally requires a more involved real-world authentication process).
hmsimha 13y ago
You could mention that kind of misuse on the page where users enter their code, and suggest they don't enter their salary information unless they are aware that the code was displayed somewhere publicly (yet anonymously) in the company (like a company bulletin board or sent out to a list of company emails from a dummy address, where you can vet that the other addresses it was sent to were your coworkers). That way, no one has any way of knowing which datapoints match to which of their coworkers.
DanielStraight 13y ago
If the size of the group is known, just generate one-time use codes equal to the number of people in the group and have the survey creator distribute them. If any code is attempted twice (such as if the survey creator uses your code before you can), trash the whole survey. Then, only display the results when all codes are used. This doesn't prevent several people from colluding, but it does seem to prevent anyone from acting alone to mess with the results of the survey.
laurenia 13y ago
Assuming you don't get too many 'bad actors' showing the mean and the median would help.