4 ms·

I promise you that it’s not. Maybe I’ll rethink this somehow, I just am trying to protect against bot traffic. Tying activity to a specific user makes it easy t

I promise you that it’s not. Maybe I’ll rethink this somehow, I just am trying to protect against bot traffic. Tying activity to a specific user makes it easy to ban access is all.

setr 4y ago
Isn’t captcha the usual default for that goal? At least for the read-access. For write-access, some kind of identifier is sensible. Also the View Rates pages fucks up the back button — that’s not very considerate of you
- ushercakes 4y ago
  Good point. Planning to add captcha then. Fixed the back button, I think. Sorry all - one man show here, really not trying to be malicious and iterating as fast as I can!
phphphphp 4y ago
You might benefit from a (small) shift in mindset: what's bad about "bot traffic"[1] and if it is bad, is it bad enough to justify sacrificing user experience? People can get caught up in protecting against something hypothetical at the expense of something real. Especially early on in the life of a website/app/service, every interaction is very valuable and you want to make it as easy as possible to maximise the value you can get from the interaction. You can even go as far as to trade off your time for ease of use, e.g: remove any barrier to submitting a rate, but manually review new rates yourself before publishing. The likelihood and cost of someone submitting a bunch of bad rates is probably less than the cost of losing a contribution from someone who cannot be bothered to create yet another account. [1] I'd go as far as to say I don't think "bots" are a thing worth worrying about at all early on because "bots" are a reaction to an opportunity to extract value from a service. For example, if a million people use your website, then spammers have an incentive... if nobody uses your website (or very few people) then there's no incentive. Spam is a problem you can deal with in future, if it ever happens, it's not something to worry about today, as long as you design your system such that if spam does happen, it's a headache for you, not users (i.e: a moderation queue). If you make the user experience bad to prevent hypothetical spam, well, the bots have ruined your website without even knowing it exists!
soulofmischief 4y ago
If I decided to scrape your data, spoofing email addresses would be near the bottom of my concerns.

I promise you that it’s not. Maybe I’ll rethink this somehow, I just am trying to protect against bot traffic. Tying activity to a specific user makes it easy to ban access is all.

setr 4y ago

Isn’t captcha the usual default for that goal? At least for the read-access. For write-access, some kind of identifier is sensible. Also the View Rates pages fucks up the back button — that’s not very considerate of you

ushercakes 4y ago
Good point. Planning to add captcha then. Fixed the back button, I think. Sorry all - one man show here, really not trying to be malicious and iterating as fast as I can!

phphphphp 4y ago

You might benefit from a (small) shift in mindset: what's bad about "bot traffic"[1] and if it is bad, is it bad enough to justify sacrificing user experience? People can get caught up in protecting against something hypothetical at the expense of something real. Especially early on in the life of a website/app/service, every interaction is very valuable and you want to make it as easy as possible to maximise the value you can get from the interaction. You can even go as far as to trade off your time for ease of use, e.g: remove any barrier to submitting a rate, but manually review new rates yourself before publishing. The likelihood and cost of someone submitting a bunch of bad rates is probably less than the cost of losing a contribution from someone who cannot be bothered to create yet another account. [1] I'd go as far as to say I don't think "bots" are a thing worth worrying about at all early on because "bots" are a reaction to an opportunity to extract value from a service. For example, if a million people use your website, then spammers have an incentive... if nobody uses your website (or very few people) then there's no incentive. Spam is a problem you can deal with in future, if it ever happens, it's not something to worry about today, as long as you design your system such that if spam does happen, it's a headache for you, not users (i.e: a moderation queue). If you make the user experience bad to prevent hypothetical spam, well, the bots have ruined your website without even knowing it exists!

soulofmischief 4y ago

If I decided to scrape your data, spoofing email addresses would be near the bottom of my concerns.