Mikhail Goriachev <[EMAIL PROTECTED]> writes:

> User Freebsd wrote:
>> On Wed, 2 Aug 2006, Nikolas Britton wrote:
>>> This may sound dumb but why don't we just put a registration link on the 
>>> FreeBSD main page... or "registration" in sysinstall. Isn't this how 
>>> everyone else handles the problem?
>> User A installs FreeBSD, registers, works with it for a week, finds he 
>> isn't getting anything done with it, wipes the drive and goes to something 
>> else ...
>> User B installs FreeBSD 5.x, registers, works with it for a while and 
>> decides to CVSup to -CURRENT, so now we have an artificially high # of 6.x 
>> installs, and an artificially low # of 7.x installs ... nobody looks to be 
>> moving to 7.x, therefore why support it from a vendors perspective ...
> Right, I've been following this thread from the start but didn't want to
> get involved, even though I felt this is important and necessary. I've
> come up with this token-based registration idea:
> Agent: Knock, knock...
> Server: Hi, give us your last 2 tokens...
> Agent: I don't have them... I'm a newborn.
> Server: Ok. Here's one for you $token1 and come back in 7 days.
> 7 days later (or more if it's a laptop)
> Agent: Knock, knock...
> Server: Hi, give us your last 2 tokens...
> Agent: I only have 1 token.
> Server: Ok. There you go $token2. Get back in 7 days.
> 7 days later (or more if it's a laptop)
> Agent: Knock, knock...
> Server: Hi, give us your last 2 tokens...
> Agent: Take them, $token1 and $token2.
> Server (compares tokens): Thanks, now give us some info about yourself.
> Agent: Ok, sending $information.
> Server: Thanks, this is another $token3 for you. Come back in 7 days.
> ... beyond this point the agent is officially registered but must
> maintain its rego by reporting every 7 days and keep providing latest 2
> tokens ...
> In short, an agent must earn the registration. In this case it takes 2
> weeks. Once it registers, it becomes a real number in the stats. If that
> agent stops reporting for a few months then it gets removed from the
> stats. If agent's computer upgrades, then it doesn't matter because it
> still sends $information (with updates) every time it reports.
> If another agent steals the tokens then it isn't an issue. The victim
> gets rejected until it collects new tokens. This is because stolen
> tokens already got registered. The burglar, in the other hand, stays
> with that stolen registration and resubmits its own $information (uname,
> dmesg, whatever), which overwrites victim's data. To strengthen the
> system and avoid token high-jacks we could increment the number and
> complexity of tokens.
>>From users' point of view, there are no registration or scary
> configurations. The system takes over and does everything behind the
> scenes. For sure, the only necessary thing would be an enable_rego=YES
> or similar line in /etc/rc.conf.
> In order to cater for the demand, I reckon there would be enough people
> willing to donate servers and bandwidth (I'd be one of them). Agents
> also could detect the closest server on their own and report to it
> (fastest_cvsup[1] style)...
> Ok, I'll stop here for now.
> Cheers,
> Mikhail.
> [1] -
> http://www.freebsd.org/cgi/url.cgi?ports/sysutils/fastest_cvsup/pkg-descr
You still can't avoid fakeries.  In fact, I guess that unless one uses
some kinds of Genuine Advantage things, you can not tell if the data
is true.  However, acquiring a unique id from the server is a good
idea to prevent from duplication, if the bandwidth permits.

Therefore, why not simplify it?

1. Require an ID from the server after installation if permitted by
   the user.

2. Provide the ID and `uname -mr` periodically or in a randomized time
   interval between one to two months.  Or simply let the user decide
   when to run it.  But states clearly that it'll overload the server
   if all the clients connect simultaneously.

Let me say it again.  There are three problems we are trying to

a. Bandwidth.
b. Duplicates.
c. Fakery.

By randomizing the time interval, bandwidth can no longer be a
problem.  And the uniqueness is assured by the ID generated in the
server.  Finally, I can't see any open source solution could prevent
some people from generating fake boxes, even with some serial number
of the hardwares.  Can we do some checks of the hardware serial
numbers?  Okay, even if we do, we are going to touch too much
privacy.  So just forget about it.

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to