2

I understand some of the use-cases for write-access in v2 of the API -- primarily to enable full access to StackExchange sites without a web browser. And I'm sure it will be a hit for people who want to access the site via a Chumby, for instance, or other hand-help mobile devices where the browsers aren't ideal (iPhone, PSP, etc.).

I'm also sure that Kevin et al. have discussed this to some extent, but I'd like to bring the discussion here as well.

What can (or will) be done to prevent abuse?

Surely you won't be able to connect to the API anonymously and ask or answer questions (as you can on the sites currently). Even requiring an OpenID won't really stop anything. And obviously there's no way to validate a user with a captcha, through a JSON interface.

The situation that I would most worry about would be spam. I would expect a slight increase in "typical" spam (fake Rolexes, Viagra, and the like), but the community is very good about closing/flagging/deleting those posts quickly.

It sounds as though the simplest solution would be to require a relatively high reputation threshold before allowing any write-access... But what's to stop someone from asking a few "gimme" questions, repping up, and then writing a script to go through every question tagged [sql] and [unit-testing] and posting an answer or comment like

SQLUnitTester is the best application for this. It has a free trial too! Download it at somefakesite.com!

To prevent this, there's a few options:

  • A restrictive time limit between posts
  • Disallow multiple, identical (or very similar) posts
  • Rely on community to flag user for spam. Perhaps put a user straight into the penalty box if an API post is flagged for spam?

Those cases are just a couple obvious ones. What other abuses can occur, and what can be done to prevent them?

Improve this question

2 Answers 2

Reset to default
4

limiting write-based per-day API access like the following way:

api-write-requests-per-day = floor(reputation/some_constant)

Btw. I don't think a 10k+ user would abuse the site from the API, although possible.

(the constant can be something from 10 to 200)

EDIT: some_constant can be different for different calls. asking questions, editing could have it set at 200 (so a 1k user can ask or edit 5 question per day), but upvoting, downvoting could be set at a lower rate, like 10 or 20. Commenting can be at 50 or so, etc.

Improve this answer
6
  • +1: I like this idea. And I agree that by and large, a 10k'er wouldn't abuse the site. But some of them might be angry coding fiends when they're drunk. Or their account could be compromised, although that's probably significantly less likely than them being an angry drunk.
    – Mark Rushakoff
    Commented Jun 5, 2010 at 16:56
  • Hey - I'm a 3.3k user and I would never think of abusing the v2 API. But I'm only one person...
    – Nathan Osman
    Commented Jun 5, 2010 at 17:36
  • + sounds like a good place to start.
    – Sky Sanders
    Commented Jun 5, 2010 at 17:48
  • @George: 3.3k with a constant of 50 should be enough for most of the things a normal person does on SO. Just a tought.
    – SztupY
    Commented Jun 5, 2010 at 20:26
  • @Mark: I imagine a spamrobot, that uses low-paid koeans to get upvotes to get to the 10k limit, then uses the new power to abuse the site randomly. Although if it has enough low-paid people, it can circumvent the captcha and others too either...
    – SztupY
    Commented Jun 5, 2010 at 20:28
  • a write API would require the user to login right (in order to do things like up/downvote) so a user can only upvote a question once. So in order to get a question to 10k it would 10k users which would be kind of noticeable.
    – Jonathan.
    Commented Jun 5, 2010 at 21:12
-2

Same limits as the normal site I think, as apps and things can be built using HTML Parsers and POST and such stuff. The API should just make it easier, than fiddling around with HTMl or whatever.

I think the best way to protect the sites is through the API key, quite simply the admins or whoever can see which API key was "used" to post the spam/junk. Then should one API key keep being used to spam then it's obvious that is a robot. So make the writtable API, key only.

Should a user use another person's API key, say a user using a API based app and some automation program then exact same thing that happens if a user uses the website with an automation tool.

So developers have to get API keys to use the writing API.

Improve this answer
4
  • - think this one through, jonathon. I decide to write a spambot and need a key - I download your app and find your key and spam away. Now your key is shut down and all of your deployed apps no longer work. Just sayin....
    – Sky Sanders
    Commented Jun 5, 2010 at 20:09
  • Well obviously the developers could talk to the SO people and explain. For instance if I make an iPhone app and someone somehow gets the key I used and writes a spambot then its obviously not my app. But it would be just as easy for someone to write a spambot for the website as the API. Also what about captchas, the main site uses it so why shouldn't apps?
    – Jonathan.
    Commented Jun 5, 2010 at 21:09
  • strings is a very powerful program. If you want to say API keys are secure, then I would put a lot of junk strings around your key in your application, that way the person who wants to write a spambot and use your key would have a lot of digging to do
    – Matt S.
    Commented Jun 5, 2010 at 21:41
  • a spambot can be built to use the website, without any API at all. Adding the developers API adds to the security of the website. Just have the same limits as the website and make the write API key only.
    – Jonathan.
    Commented Jun 5, 2010 at 21:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .