Suggestions for identifying a computer?

[Tim Smith]

Where I work, one of our products includes online chat and messaging
services. There are some rather non-nice people out there that can make an
online chat unpleasant. Microsoft, in fact, just announced that they are
basically giving up, in fact, in many countries, because of this:

http://asia.reuters.com/newsArticle....toryID=3496061

We're not ready to give up yet, so we are still trying to find ways to
control the non-nice people.

Right now, I've got two ways I can suspend someone from the chat and
messaging service.

1. I can ban IP addresses or ranges. However, that doesn't work well for
jerks on dynamic IP.

2. When our software is installed, it generates an ID number and stores it
somewhere (registry, I think...I'm a server guy, not a client guy, so don't
know all the details). That ID number is basically what the software uses
to log in to the chat/messaging server. I can ban by that ID number.
However, there are some people who've figured out that they can change that
number.

*If* we only had paid users, things would be a great, because that ID number
could be used on the server to look up account information, such as a credit
card number (it's a subscription service, so there is a credit card on
file). Banning by credit card would be pretty effective. If I ban someone
and they have to come up with a different valid credit card to get around
the ban, I think that would be good enough.

However, people don't have to pay for our services. There is a free trial,
and for many of our services, you can even stay free forever, with lower
resource limits or reduced functionality compared to paid users. For the
free users, that ID number does NOT lead to anything interesting like a
credit card or a billing address.

So, what I'm looking for is some way I can identify a machine, so that I
can ban that machine from the chat and messaging service, that meets the
following two requirements:

1. It is a pain for the user to change this identification.

2. It doesn't raise too many privacy concerns for the user.

Here's what I'm currently thinking of. Can anyone see anything wrong with
this from a privacy point of view?

1. When the user logs in, note a bunch of characteristics of the machine,
such as:

IP address
MAC address
Disk size
RAM size
Timezone
Type of optical drives
Hash of browser home page URL
% of disk space used
Version of OS and various system components

and other things like that...none of these really identify a machine, but
that's OK (see below).

2. When someone gets banned, remember the values of those characteristics.
Associate this with their ID number.

3. When someone logs in as a free guest, using an ID number we've not seen
before, take their characterstics, and compare them against those on the
recently banned list. If one is found that is very close (e.g., similar IP
address, matches on most of the others), then add this new ID to the ban
list, and don't allow them in.

(Yes, % of disk space used might seem odd to use...but most bans are not
permanent, so things like disk space used can be useful over the short
term).

I've got a hash of the home page URL there, rather than the URL itself,
because all I want to be able to tell is if it the same URL or not, so by
using a hash that is not computationally feasible to reverse, there's a lot
less of a privacy problem.

Any thoughts on this? Any suggestions for things to include in the
characteristics list? Any to exclude? Or is this approach totally bogus,
and if so, anyone have any other ideas?

--
Evidence Eliminator is worthless: www.evidence-eliminator-sucks.com
--Tim Smith

[Jay T. Blocksom]

On Wed, 24 Sep 2003 07:17:30 GMT, in <alt.privacy.spyware>, Tim Smith
<reply_in_group@mouse-potato.com> wrote:
>
> Where I work, one of our products includes online chat and messaging
> services. There are some rather non-nice people out there that can make
> an online chat unpleasant.
[snip]

Especially one where strong user authentication is not a prerequisite for
using the system.

> Right now, I've got two ways I can suspend someone from the chat and
> messaging service.
>
> 1. I can ban IP addresses or ranges. However, that doesn't work well for
> jerks on dynamic IP.
>
[snip]

Useless, for precisely the reason you note.

> 2. When our software is installed, it generates an ID number and stores
> it somewhere (registry, I think...I'm a server guy, not a client guy, so
> don't know all the details). That ID number is basically what the
> software uses to log in to the chat/messaging server. I can ban by that
> ID number. However, there are some people who've figured out that they
> can change that number.
>
[snip]

Two things:

1. - If you have "problem users" who are willing to muck around in the
Registry in order to *be* "problem users", you will need a non-trivial
solution.

2. - If you require the user to install your software on your machine in
order to accsss your service, you can IN THEORY do just about anything you
need to do to enforce strong user authentication. But you'll inevitably
*also* raise lots of "red flags" in the eyes of cautious users. and rightly
so.

> *If* we only had paid users, things would be a great, because that ID
> number could be used on the server to look up account information, such
> as a credit card number
[snip]

That's one answer, and probably the best one, given the rest of your story.

> ...(it's a subscription service, so there is a credit card on
> file).
[snip]

I thought you said it was a free service? I, for one, would NEVER provide
credit card info for such ANY non-payment purpose, as a matter of principle
(and prudence).

> However, people don't have to pay for our services. There is a free
> trial, and for many of our services, you can even stay free forever, with
> lower resource limits or reduced functionality compared to paid users
[snip]

IOW, you have created your very own "attractive nuisance". Think about that
for a bit before you decide to go to a lot of work to perpetuate the same
fundamental problem.

> So, what I'm looking for is some way I can identify a machine, so that I
> can ban that machine from the chat and messaging service,
[snip]

Wrong.

You don't want to ban a *machine*, you want to ban a *user*. That same
"problem user" can change machines just about as easily as he can change
dial-up IPs; so ID-ing or banning the *machine* is essentially pointless.
Besides, did you learn nothing from the Intel Pentium III GUID debacle?

> ... that meets the following two requirements:
>
> 1. It is a pain for the user to change this identification.
>
> 2. It doesn't raise too many privacy concerns for the user.
>
[snip]

These are largely (but not completely) mutually exclusive goals.

Given that, you really only have a few choices:

1. - Go to a pay-service model, with billing to a *verified* credit card,
similar to what you already contemplated (but don't permit the service to be
used until ALL aspects of the billing data have been verified).

2. - Make the sign-up process difficult to "spoof" by using tokenized
closed-loop confirmation such as discussed (albeit, in a different context)
here: <http://www.cluelessmailers.org/info/listmanagement.html> *and* not
accepting ANY sign-ups using e-mail addresses at highly abusable domains
like Hotmail, Yahoo, etc. (or basically any "free e-mail" service). Better
yet, only send the logon ID/password by snail mail -- this would slow down
the sign-up process somewhat for everyone, legitimate users included; but
mostly it would put a severe crimp in an abuser's ability to morph from one
"trial account" to the next.

3. - *NEVER* accept connections, regardles of how or whether the user is
"ID-ed", from open proxys or so-called "anonymous surfing" portals.

Finally, if you're *sure* you want to ID machines, as opposed to users
(which I still think is a fundamentally bad idea), then hard-code an
encrypted GUID in your client software, as opposed keeping that data in the
registry; then mail the client software on a floppy (or CD-ROM, if it's a
bloated mess) to each new user at the snail-mail address they MUST give you
to get access to the service; and finally, keep all user-account data (which
ties back to that GUID, of course) on your server, not on the client system.
If/when the user of a given copy of your client software misbehaves, disable
that GUID. Of course, this doesn't scale very well if you anticipate LOTS
of users, since each copy of the client software would need to be "custom
made" so to speak. And just as obviously, you would need to PROMINANTLY and
EXPLICITLY disclose ALL of this to each new user *before* they have an
opportunity to "sign up".

> Here's what I'm currently thinking of. Can anyone see anything wrong
> with this from a privacy point of view?
>
> 1. When the user logs in, note a bunch of characteristics of the machine,
> such as:
>
> IP address
[snip]

Easy, but useless. See above.

> MAC address
[snip]

Of what? The only MAC address *any* piece of network hardware EVER sees is
that of the next chunk of hardware up/down the line.

> Disk size
> RAM size
> Timezone
> Type of optical drives
[snip]

Not nearly unique enough or reliable enough for your purposes, *and* it
starts to breach the "none of your f-ing business" threshold.

> Hash of browser home page URL
[snip]

*What* "browser home page URL"? (Hint: What is the MD5 hash of the null
set?)

> % of disk space used
[snip]

That will constantly change on any given system; so it is inherently useless
as any sort of identification data point.

> Version of OS and various system components
>
[snip]

Same problems as disk size, RAM size, etc.

> and other things like that...none of these really identify a machine, but
> that's OK (see below).
>
[snip]

No, it *isn't* "OK" -- and you're just kidding yourself to think that it is.

> 2. When someone gets banned, remember the values of those
> characteristics. Associate this with their ID number.
>
[snip]

You're now dipping your toe into the nasty world of "E-Pending" -- and doing
it poorly, at that. This is a VERY bad idea.

> 3. When someone logs in as a free guest, using an ID number we've not
> seen before,
[snip]

Huh? What do you mean, "an ID number we've not seen before"?!? Why aren't
*you* generating the ID numbers?

> ...take their characterstics, and compare them against those on the
> recently banned list. If one is found that is very close (e.g., similar
> IP address, matches on most of the others), then add this new ID to the
> ban list, and don't allow them in.
>
[snip]

If "very close" is defined loosely enough to catch a significant fraction of
the putative "bad guys", it will also produce LOTS of false positives,
guaranteed.

> Or is this approach totally
> bogus,
[snip]

Yes.

--

Jay T. Blocksom
--------------------------------
Appropriate Technology, Inc.
usenet01[at]appropriate-tech.net


"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: E-Mail address in "From:" line is INVALID! Remove +SPAMBLOCK to mail.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Unsolicited advertising sent to this E-Mail address is expressly prohibited
under USC Title 47, Section 227. Violators are subject to charge of up to
$1,500 per incident or treble actual costs, whichever is greater.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[Tim Smith]

In article <0l2cnv8hvhjb4ri7rp6bqo4pla3rfrg4qe@news.rcn.com >, Jay T Blocksom
wrote:
> > ...(it's a subscription service, so there is a credit card on file).
> [snip]
>
> I thought you said it was a free service? I, for one, would NEVER provide
> credit card info for such ANY non-payment purpose, as a matter of
> principle (and prudence).

It's a free service with a certain set of features and limits, or you can
buy a subscription and get more features and less limits.

....
> 2. - Make the sign-up process difficult to "spoof" by using tokenized
> closed-loop confirmation such as discussed (albeit, in a different
> context) here: <http://www.cluelessmailers.org/info/listmanagement.html>
> *and* not accepting ANY sign-ups using e-mail addresses at highly abusable
> domains like Hotmail, Yahoo, etc. (or basically any "free e-mail"
> service). Better yet, only send the logon ID/password by snail mail --
> this would slow down the sign-up process somewhat for everyone, legitimate
> users included; but mostly it would put a severe crimp in an abuser's
> ability to morph from one "trial account" to the next.

Unfortunately, most of our users are "ordinary" users. Hotmail or Yahoo is
often the only email address many have (or at least know of...they've
probably got one from their ISP sitting somewhere in an unread pile of paper
that came when they got their cable modem installed). We're talking that
kind of people that are the ones that are spreading all these damn worms
'cause they are too dumb to use Windows Update.

That's one of the reasons it probably needs to go by machine.

Anyway, thanks for the suggestions. I'm continuing to think about this
problem. (Technically, it is a quite interesting problem).

--
Evidence Eliminator is worthless: www.evidence-eliminator-sucks.com
--Tim Smith