| 1 |
On Sat, 23 May 2020 07:20:22 +1200 |
| 2 |
Kent Fredric <kentnl@g.o> wrote: |
| 3 |
|
| 4 |
> On Thu, 21 May 2020 10:47:07 +0200 |
| 5 |
> Michał Górny <mgorny@g.o> wrote: |
| 6 |
> |
| 7 |
> > Other ideas |
| 8 |
> > =========== |
| 9 |
> > Do you have any other ideas on how we could resolve this? |
| 10 |
> |
| 11 |
> And a question I'd like to revisit, because nobody responded to it: |
| 12 |
> |
| 13 |
> - What are the incentives a would-be spammer has to spam this service. |
| 14 |
> |
| 15 |
> Services that see spam *typically* have a definable objective. |
| 16 |
> |
| 17 |
> *Typically* it revolves around the ability to submit /arbitrary text/, |
| 18 |
> which allows them to hawk something, and this becomes a profit motive. |
| 19 |
> |
| 20 |
> If we implement data validation so that there's no way for them to |
| 21 |
> profit off what they spam, seems likely they'll be less motivated to |
| 22 |
> develop the necessary circumvention tools. ( as in, we shouldn't |
| 23 |
> accept arbitrary CAT/PN pairs as being valid until something can |
| 24 |
> confirm those pairs exist in reality ) |
| 25 |
> |
| 26 |
> There may be people trying to jack the data up, but ... it seems a |
| 27 |
> less worthy target. |
| 28 |
> |
| 29 |
> So it seems the largest risk isn't so much "spam", but "denial of |
| 30 |
> service", or "data pollution". |
| 31 |
> |
| 32 |
> Of course, we should still mitigate, but /how/ we mitigate seems to |
| 33 |
> pivot around this somewhat. |
| 34 |
|
| 35 |
We cannot exclude overlays which will have cat/pkg not in the main |
| 36 |
gentoo repo. So, we should not excludea submission that includes a few |
| 37 |
of these. They would just become irrelevant outliers to our |
| 38 |
processesing of the data. In fact some of these outlier pkgs could be |
| 39 |
relevant to our including that pkg into the main repo. |
| 40 |
|
| 41 |
But, like you I agree that purely spam submissions would be few, if any. |
Archives