Return to Answer

I spent a bit of time chasing this down.

The spam system is keeping quite a bit of junk out of your inbox, that's for certain; the problem is that these edits are coming from all over the place, by various kinds of bots.

What I'm going to explore is adding a feature to the spam system that just disables anonymous edits on a per-post basis when a post has received X number of edits rejected as spam in Y time.

This would prevent humans from having to do much of anything, and naturally relax the block over time. This would work in conjunction with the system that blocks edits outright when certain things cross certain thresholds, in theory the lock would lift not long after they basically give up.

I have to do a little more research on this and basically replay some spam attacks again from logs against the same model I used to set the thresholds on the system that we're using now. I can't promise anything, but we're definitely going to see if we can tighten up the metaphorical fences around these oddly desirable targets.

Update

The answer to this is probably to gather more useful signal from spammers, just as we do from the community and moderators now. If a suggested edit to a post that has a relatively recent history of edits rejected as spam is also rejected as spam, we can probably just amplify the severity of the event as we record it. That would have kept most of this out.

Part of the goal of the system is to not interfere with benign activity, while making sure this kind of crap rarely (ideally never) shows up in your inbox. I'm reasonably sure that this would be a trivial change.

To be clear, we'll never be completely free of it, but I think we can keep the bulk of it from ever getting in, even in these strangely severe cases.

Again, I've got to run this a few different ways, but I think I've got it. We're probably going to need to break 'spam' into a different reason to reject an edit altogether, but I think this will work. It was only after implementing this system that I realized the actual magnitude of the problem when it comes to anon edits.

I spent a bit of time chasing this down.

The spam system is keeping quite a bit of junk out of your inbox, that's for certain; the problem is that these edits are coming from all over the place, by various kinds of bots.

What I'm going to explore is adding a feature to the spam system that just disables anonymous edits on a per-post basis when a post has received X number of edits rejected as spam in Y time.

This would prevent humans from having to do much of anything, and naturally relax the block over time. This would work in conjunction with the system that blocks edits outright when certain things cross certain thresholds, in theory the lock would lift not long after they basically give up.

I have to do a little more research on this and basically replay some spam attacks again from logs against the same model I used to set the thresholds on the system that we're using now. I can't promise anything, but we're definitely going to see if we can tighten up the metaphorical fences around these oddly desirable targets.

Update

The answer to this is probably to gather more useful signal from spammers, just as we do from the community and moderators now. If a suggested edit to a post that has a relatively recent history of edits rejected as spam is also rejected as spam, we can probably just amplify the severity of the event as we record it. That would have kept most of this out.

Part of the goal of the system is to not interfere with benign activity, while making sure this kind of crap rarely (ideally never) shows up in your inbox. I'm reasonably sure that this would be a trivial change.

To be clear, we'll never be completely free of it, but I think we can keep the bulk of it from ever getting in, even in these strangely severe cases.

Again, I've got to run this a few different ways, but I think I've got it. We're probably going to need to break 'spam' into a different reason to reject an edit altogether, but I think this will work. It was only after implementing this system that I realized the actual magnitude of the problem when it comes to anon edits.

Additional Update

This (remembering which posts have been targeted over time and awarding a harsher penalty in the system) will be rolling out in one of the upcoming builds. If an anonymous user edits a question that is known to be a spam target and that edit is rejected as spam, they'll be blocked from suggesting edits very quickly.

This was the 2 in the 1-2 punch that we needed to deal with more elaborate & distributed setups (bot nets, etc). We can't keep this out of your inbox completely, but we can further reduce the annoyance rather drastically in cases like this.

I spent a bit of time chasing this down.

The spam system is keeping quite a bit of junk out of your inbox, that's for certain; the problem is that these edits are coming from all over the place, by various kinds of bots.

What I'm going to explore is adding a feature to the spam system that just disables anonymous edits on a per-post basis when a post has received X number of edits rejected as spam in Y time.

This would prevent humans from having to do much of anything, and naturally relax the block over time. This would work in conjunction with the system that blocks edits outright when certain things cross certain thresholds, in theory the lock would lift not long after they basically give up.

I have to do a little more research on this and basically replay some spam attacks again from logs against the same model I used to set the thresholds on the system that we're using now. I can't promise anything, but we're definitely going to see if we can tighten up the metaphorical fences around these oddly desirable targets.

Update

The answer to this is probably to gather more useful signal from spammers, just as we do from the community and moderators now. If a suggested edit to a post that has a relatively recent history of edits rejected as spam is also rejected as spam, we can probably just amplify the severity of the event as we record it. That would have kept most of this out.

Part of the goal of the system is to not interfere with benign activity, while making sure this kind of crap rarely (ideally never) shows up in your inbox. I'm reasonably sure that this would be a trivial change.

To be clear, we'll never be completely free of it, but I think we can keep the bulk of it from ever getting in, even in these strangely severe cases.

Again, I've got to run this a few different ways, but I think I've got it.

I spent a bit of time chasing this down.

The spam system is keeping quite a bit of junk out of your inbox, that's for certain; the problem is that these edits are coming from all over the place, by various kinds of bots.

What I'm going to explore is adding a feature to the spam system that just disables anonymous edits on a per-post basis when a post has received X number of edits rejected as spam in Y time.

This would prevent humans from having to do much of anything, and naturally relax the block over time. This would work in conjunction with the system that blocks edits outright when certain things cross certain thresholds, in theory the lock would lift not long after they basically give up.

I have to do a little more research on this and basically replay some spam attacks again from logs against the same model I used to set the thresholds on the system that we're using now. I can't promise anything, but we're definitely going to see if we can tighten up the metaphorical fences around these oddly desirable targets.

Update

The answer to this is probably to gather more useful signal from spammers, just as we do from the community and moderators now. If a suggested edit to a post that has a relatively recent history of edits rejected as spam is also rejected as spam, we can probably just amplify the severity of the event as we record it. That would have kept most of this out.

Part of the goal of the system is to not interfere with benign activity, while making sure this kind of crap rarely (ideally never) shows up in your inbox. I'm reasonably sure that this would be a trivial change.

To be clear, we'll never be completely free of it, but I think we can keep the bulk of it from ever getting in, even in these strangely severe cases.

Again, I've got to run this a few different ways, but I think I've got it. We're probably going to need to break 'spam' into a different reason to reject an edit altogether, but I think this will work. It was only after implementing this system that I realized the actual magnitude of the problem when it comes to anon edits.

I spent a bit of time chasing this down.

The spam system is keeping quite a bit of junk out of your inbox, that's for certain; the problem is that these edits are coming from all over the place, by various kinds of bots.

What I'm going to explore is adding a feature to the spam system that just disables anonymous edits on a per-post basis when a post has received X number of edits rejected as spam in Y time.

This would prevent humans from having to do much of anything, and naturally relax the block over time. This would work in conjunction with the system that blocks edits outright when certain things cross certain thresholds, in theory the lock would lift not long after they basically give up.

I have to do a little more research on this and basically replay some spam attacks again from logs against the same model I used to set the thresholds on the system that we're using now. I can't promise anything, but we're definitely going to see if we can tighten up the metaphorical fences around these oddly desirable targets.

Update

The answer to this is probably to gather more useful signal from spammers, just as we do from the community and moderators now. If a suggested edit to a post that has a relatively recent history of edits rejected as spam is also rejected as spam, we can probably just amplify the severity of the event as we record it. That would have kept most of this out.

Part of the goal of the system is to not interfere with benign activity, while making sure this kind of crap rarely (ideally never) shows up in your inbox. I'm reasonably sure that this would be a trivial change.

To be clear, we'll never be completely free of it, but I think we can keep the bulk of it from ever getting in, even in these strangely severe cases.

I spent a bit of time chasing this down.

The spam system is keeping quite a bit of junk out of your inbox, that's for certain; the problem is that these edits are coming from all over the place, by various kinds of bots.

What I'm going to explore is adding a feature to the spam system that just disables anonymous edits on a per-post basis when a post has received X number of edits rejected as spam in Y time.

This would prevent humans from having to do much of anything, and naturally relax the block over time. This would work in conjunction with the system that blocks edits outright when certain things cross certain thresholds, in theory the lock would lift not long after they basically give up.

I have to do a little more research on this and basically replay some spam attacks again from logs against the same model I used to set the thresholds on the system that we're using now. I can't promise anything, but we're definitely going to see if we can tighten up the metaphorical fences around these oddly desirable targets.

Update

The answer to this is probably to gather more useful signal from spammers, just as we do from the community and moderators now. If a suggested edit to a post that has a relatively recent history of edits rejected as spam is also rejected as spam, we can probably just amplify the severity of the event as we record it. That would have kept most of this out.

Part of the goal of the system is to not interfere with benign activity, while making sure this kind of crap rarely (ideally never) shows up in your inbox. I'm reasonably sure that this would be a trivial change.

To be clear, we'll never be completely free of it, but I think we can keep the bulk of it from ever getting in, even in these strangely severe cases.

Again, I've got to run this a few different ways, but I think I've got it.