| 1 |
On Thu, 21 May 2020 10:47:07 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> Other ideas |
| 5 |
> =========== |
| 6 |
> Do you have any other ideas on how we could resolve this? |
| 7 |
|
| 8 |
And a question I'd like to revisit, because nobody responded to it: |
| 9 |
|
| 10 |
- What are the incentives a would-be spammer has to spam this service. |
| 11 |
|
| 12 |
Services that see spam *typically* have a definable objective. |
| 13 |
|
| 14 |
*Typically* it revolves around the ability to submit /arbitrary text/, |
| 15 |
which allows them to hawk something, and this becomes a profit motive. |
| 16 |
|
| 17 |
If we implement data validation so that there's no way for them to |
| 18 |
profit off what they spam, seems likely they'll be less motivated to |
| 19 |
develop the necessary circumvention tools. ( as in, we shouldn't accept |
| 20 |
arbitrary CAT/PN pairs as being valid until something can confirm those |
| 21 |
pairs exist in reality ) |
| 22 |
|
| 23 |
There may be people trying to jack the data up, but ... it seems a less |
| 24 |
worthy target. |
| 25 |
|
| 26 |
So it seems the largest risk isn't so much "spam", but "denial of |
| 27 |
service", or "data pollution". |
| 28 |
|
| 29 |
Of course, we should still mitigate, but /how/ we mitigate seems to |
| 30 |
pivot around this somewhat. |
Archives