

JavaScript API pricing is dangerous. Here is why - arunoda
http://dokeeno.com/v/blog/javascript-api-pricing-is-dangerous!-here-is-the-why-[demonstrated]

======
arunoda
Mixpanel authorized person has answered to this in the blog post. Here it is
\----------

I'm glad you like Mixpanel! This is certainly something we've considered, but
(at least for us) the usage-based api makes the most sense. Unfortunately you
can't avoid this kind of thing once you go the usage-based path, but it hasn't
been an issue in practice.

We've _never_ had a malicious user manipulate someone's data (and it would be
pretty obvious if they did). If it did happen, we wouldn't charge them for it.

------
solox3
I know what you mean, and I understand your concern, but as an API, the API
provider is meant to handle these [D]DOS attacks / miscounting (e.g. Google
Analytics hardly ever miscounts).

Alternatively, if you understand the consequences of using an unofficial API,
and your web service has the bandwidth to do so, you can trigger the API by
manually stimulating server-side REST requests identical to what the JS API
does.

~~~
arunoda
yes. You are correct. This is not a new thing. But the difference here is with
the (D)DOS. Customer has to pay for it. Not mixpanel. That is the concern I'm
making. It is huge

~~~
equark
Doesn't seem huge. Most people pay for bandwidth. Standard web DOS attacks
cost money too. Same thing with linking to S3. The fix is as it's always been,
email your provider and explain the situation. Most likely they'll revert your
usage. Presumably if it becomes a big problem they'll set up something like
rate limiting by IP.

~~~
arunoda
Yes You might argue that. But the vendors should do some kind preventive
mechanism on doing this. I don't know what. If they need to serve there
customers well, they need to focus on that. What we need is a preventive
mechanism and if they don't do this. This will be the next generation viruses.
And extreamly dangerous.

