Gentoo Archives: gentoo-dev

From: "Toralf Förster" <toralf@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
Date: Sun, 26 Apr 2020 10:54:24
Message-Id: b0d0c7a1-0eba-d7b3-030b-6e043411ba24@gentoo.org
In Reply to: Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation by "Michał Górny"
1 On 4/26/20 12:25 PM, Michał Górny wrote:
2 > On Sun, 2020-04-26 at 12:15 +0200, Toralf Förster wrote:
3 >> On 4/26/20 10:52 AM, Michał Górny wrote:
4 >>> Do you have any other idea for spam protection then?
5 >>
6 >> IMO there're 2 types of spam:
7 >>
8 >> 1. made by accident (eg. "* * * * *" instead "@weekly" in crontab)
9 >> 2. made intentionlly
10 >>
11 >> The 1st can be handled by UUID - just drop any old related dataset from inbox when a new one arrived
12 >> For the 2nd: what about accepting only datasets from "valid" UUIDs, meaning where just 1 dataset/week/IPv4 (maybe /16 block) in the mean did arrived in the last few weeks/months ?
13 >>
14 >
15 > I'm sorry but could you rephrase that in more sentences? I don't
16 > understand what you mean.
17 >
18
19 Well, inspired by what Tor people do with Tor bridge stats:
20
21 - Create an UUID (never published, known only at the client and at the gentoo stats server)
22 - Calculate a hash of it. The hash is allowed to be published. The hash may be related with contact informations. The contact data may or may not be published. The hash is used for contacting people in case of questions.
23
24 The stats sent by the client contains the UUID.
25 Stats are send to a stats server in an area where they do live fore a while (days).
26 If a new stats file was got then the stats server deletes all older stats file of thet UUID in the stats area.
27
28 Stats are be trusted if they meet conditions already mentioned by Brian Dolbec.
29
30 IMO do not care about detecting spam, just try to detect valid UUIDs.
31
32 --
33 Toralf
34 PGP 23217DA7 9B888F45

Attachments

File name MIME type
signature.asc application/pgp-signature