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