1 |
On Sat, 2020-05-23 at 07:20 +1200, Kent Fredric wrote: |
2 |
> On Thu, 21 May 2020 10:47:07 +0200 |
3 |
> Michał Górny <mgorny@g.o> wrote: |
4 |
> |
5 |
> > Other ideas |
6 |
> > =========== |
7 |
> > Do you have any other ideas on how we could resolve this? |
8 |
> |
9 |
> And a question I'd like to revisit, because nobody responded to it: |
10 |
> |
11 |
> - What are the incentives a would-be spammer has to spam this service. |
12 |
> |
13 |
> Services that see spam *typically* have a definable objective. |
14 |
> |
15 |
> *Typically* it revolves around the ability to submit /arbitrary text/, |
16 |
> which allows them to hawk something, and this becomes a profit motive. |
17 |
> |
18 |
> If we implement data validation so that there's no way for them to |
19 |
> profit off what they spam, seems likely they'll be less motivated to |
20 |
> develop the necessary circumvention tools. ( as in, we shouldn't accept |
21 |
> arbitrary CAT/PN pairs as being valid until something can confirm those |
22 |
> pairs exist in reality ) |
23 |
> |
24 |
> There may be people trying to jack the data up, but ... it seems a less |
25 |
> worthy target. |
26 |
> |
27 |
> So it seems the largest risk isn't so much "spam", but "denial of |
28 |
> service", or "data pollution". |
29 |
|
30 |
I've meant 'spam' as 'undesired submissions'. You seem to have used |
31 |
a very narrow definition of 'spam' to argue into reaching the same |
32 |
problem under different name. |
33 |
|
34 |
Let's put it like this. This thing starts working. Package X is |
35 |
broken, and we see that almost nobody is using it. We remove that |
36 |
package. Now somebody is angry. He submits a lot of fake data to |
37 |
render the service useless so that we don't make any future decisions |
38 |
based on it. |
39 |
|
40 |
-- |
41 |
Best regards, |
42 |
Michał Górny |