910767 - [tracker] reduce spam issues

Status: RESOLVED WONTFIX

(Input Graveyard :: Submission, defect, P1)

Description

[Will Kahn-Greene [:willkg] ET needinfo? me]

We're getting a non-trivial amount of spam.

This bug covers:

1. specifying what that means with some metrics (i.e. it's not sufficient to define the problem we have now as, "OMG! SPAM!!!!!!111!!")

2. identifying one or more trends in the spam we're getting now

3. determining what steps we can take now to alleviate the spam we're getting now

4. writing up bugs to cover those steps

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

Putting this in the 2013q3 marathon. If I don't get to it, then we'll do it in 2013q4. It's fairly important we work on it sooner rather than later.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

Putting this in 2013q4.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

Fixing the sprint.

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

This needs the analyzers group stuff set up before I can start fiddling with things.

Comment 6

[[:Cww]]

One thing I've been doing with input processing is deleting duplicates. That is, if all fields except the date match, I only count it once.  You may get false positives if five people say "sucks" or "facebook" a lot, but the kind of stuff that's detailed and actually useful is very unlikely to be duplicated.

I tend to use small windows (1 week or so) so maybe we could do a cooling off period as in one-duplicated-per-week allowed or something like that.

Comment 7

[Will Kahn-Greene [:willkg] ET needinfo? me]

I've seen a few responses where the description is pretty intensely long (> 2mb). It's probably the case we want the user to tell us lots of stuff, but 2 million characters is pretty over the top. We should truncate incoming response descriptions at some length that's the upper bound of what we're ok with. 5000 characters?

Comment 8

[Will Kahn-Greene [:willkg] ET needinfo? me]

Adding this as a note so I don't forget:

Any action that deletes spam from the site should log something somewhere. I think for now we can just log counts. I want to know how much spam we're deleting with the new tools and when. We might even want to convert those spam responses into "spam responses" in a separate table so we can keep track of when they were created and when they were deleted and by whom.

Comment 9

[Will Kahn-Greene [:willkg] ET needinfo? me]

Update:

> 2. identifying one or more trends in the spam we're getting now

We identified a couple of spam classes:

1. double-submits from Firefox for Android
2. scripts posting the same thing over and over again in a short period of time


> 3. determining what steps we can take now to alleviate the spam we're getting now

1. I added some code to eliminate double-submits by ratelimiting the (ip address, desc) tuple--that's working well
2. I added some code to reduce script issues by ratelimiting on ip address

Both of these ratelimits generate statsd data so we can track them in graphite and see whether they're going awry and how often they're getting tickled.


Outstanding things here:

1. the spam duplicates report needs a "delete all but one" button and a "delete all" button for deleting identified spam (bug #949461)

2. we need a way to run the spam duplicates report over different time ranges to identify and remove old spam


I'm done all I can do here for now. Turning it into a tracker and bumping it out of this quarter.

Comment 10

[Will Kahn-Greene [:willkg] ET needinfo? me]

Putting this in the 2014q3 target milestone. We'll work on it then.

Comment 11

[Will Kahn-Greene [:willkg] ET needinfo? me]

Unassigning for now. I'm not working on it.

Comment 12

[Osmose [:osmose, :mkelly]]

The Input service has been decommissioned (see bug 1315316) and has been replaced by a redirect to an external vendor (SurveyGizmo). I'm bulk WONTFIXing Input bugs that do not appear to be relevant anymore.