You are not logged in. Login Now
 0-24   25-49   50-74   75-99   100-124   122-146   147-171   172-184   
 
Author Message
25 new of 184 responses total.
jmsaul
response 147 of 184: Mark Unseen   Sep 10 18:10 UTC 2002

Allowing full outgoing access to anyone who runs newuser is just a bad idea.
mynxcat
response 148 of 184: Mark Unseen   Sep 10 18:13 UTC 2002

I agree
flem
response 149 of 184: Mark Unseen   Sep 10 18:28 UTC 2002

Wait, so we're not supposed to use ID to help prevent identity theft, because
someone could beat us by... committing identity theft?
mynxcat
response 150 of 184: Mark Unseen   Sep 10 18:49 UTC 2002

Something like that. It sounds weird, but if grex is not going to be actually
verifying that id, I really don't see the point in collecting and storing that
id. 
cmcgee
response 151 of 184: Mark Unseen   Sep 10 18:55 UTC 2002

NO, NO!  I need telnet.
I need telnet for weather, for access to UM emails, to play games on the
Internet, for a number of different reasons.
mynxcat
response 152 of 184: Mark Unseen   Sep 10 19:00 UTC 2002

I think he meant no telnet for people who don't pay. Its not a good idea
giving *every* newuser telnet. Get it?
cmcgee
response 153 of 184: Mark Unseen   Sep 10 19:30 UTC 2002

Sorry, I skimmed too many entries *grin*
steve
response 154 of 184: Mark Unseen   Sep 10 19:43 UTC 2002

   The reason for asking for ID and not verifying it is a balance between
trying to do something to protect ourselves, but not get some encumbered
in the process that we spend all our time trying to authenticate people
do not do anything else.  We also ask for id as a form of vandal protection;
once they hear of the request for ID, the vast majority shy away.

   I don't think Grex is overbearing in its requests on this, and I don't
think we need to change much.  I haven't read the entire set of responses
however, so I'll do that now.
mynxcat
response 155 of 184: Mark Unseen   Sep 10 19:46 UTC 2002

What happens when you collect id from someone, who has provided false id, and
when you need to hand it over to the police, if required to, you end up
implicating some poor third person?
aruba
response 156 of 184: Mark Unseen   Sep 10 20:28 UTC 2002

All we do is tell the police what we know, which is that the person who
paid for a particular membership sent us a particular ID.

There is no way to tell who uses a paricular account.  Even if we carried
out some elaborate check to see that the ID we received actually came from
the person it describes, they can still allow someone else to use their
account, or be careless with their password, or what have you.

So there is no absolute security.  There are only compromises.  Grex has
made one, with its policy; it's not the only one possible, but it has served
us pretty well so far, I think.
steve
response 157 of 184: Mark Unseen   Sep 10 20:53 UTC 2002

   It has worked excellently, so far.  I see no reason to change it.

   In the case of false ID presented to us, we'd tell the authorities
who got it that it was what we had.  What else could we do?
russ
response 158 of 184: Mark Unseen   Sep 11 03:45 UTC 2002

Re #143:  Sapna, we don't *know* that the person making the application
is the person named on the license.  However, we do know that the
applicant *had possession of* the license.  Unless the licensee's wallet
was stolen (and maybe even if it was), the licensee could probably give
investigators a good idea of who made the application.  Other forensic
data (such as IP addresses) can exonerate an innocent licensee and finger
the actual guilty party.

If Grex can point investigators down the line, we've carried out our
obligation (and done a pretty good job of deterring vandals).
mynxcat
response 159 of 184: Mark Unseen   Sep 11 03:50 UTC 2002

It still doesn't hold much water. But I don't care enough either, so I guess
it can stay the way it is
jp2
response 160 of 184: Mark Unseen   Sep 11 03:55 UTC 2002

This response has been erased.

other
response 161 of 184: Mark Unseen   Sep 11 04:04 UTC 2002

Psst.  Jamie.  READ THE FUCKING ITEM.  
flem
response 162 of 184: Mark Unseen   Sep 11 05:26 UTC 2002

I don't think that's such a bad question.  (#160, that is.)  As has been
nearly beaten to death in this and previous items, we collect and retain ID
for two reasons.  First, to make a reasonable effort to ensure that one person
can't get two voting memberships, and second, to be able to produce some
information about the people we give certain kinds of access to.  I think
these are reasonable, worthwhile goals.  If they can be accomplished without
collecting ID, then it would be worth trying to do so.  However, I'm
skeptical.  I imagine it may be possible, even likely, that system logs
contain enough information to nullify the second reason, but I don't see how
they can satisfy the demands of the first goal.  So I think we shouldn't
change ID policy unless and until we can come up with a way to make reasonably
sure that people can't get more than one voting membership.  Or,
alternatively, decide that we don't care about that.  
jp2
response 163 of 184: Mark Unseen   Sep 11 14:35 UTC 2002

This response has been erased.

bhelliom
response 164 of 184: Mark Unseen   Sep 11 16:05 UTC 2002

resp:159 - Okay, I'll bite.  If you didn't care, why were you making 
such a big fuss about this?

mynxcat
response 165 of 184: Mark Unseen   Sep 11 18:10 UTC 2002

You're not paying attention. This is not one of my crusades. The most fuss
I've made is to point out that it was silly to collect and store id when you
weren't going to verify them. I would hardly call it making a "big fuss".
scott
response 166 of 184: Mark Unseen   Sep 11 19:51 UTC 2002

Well, I buy car insurance without ever intending to wreck my car.  Is that
a waste of my money?

How exactly *would* we verify said ID, anyway?  Demand a notarized declaration
that the ID is valid, cosigned by the local police chief?  How far would be
sufficient to be completely certain the ID wasn't stolen/faked?
aruba
response 167 of 184: Mark Unseen   Sep 11 19:52 UTC 2002

Re #63: Such evidence is in coop item 16, which you participated in heavily.
aruba
response 168 of 184: Mark Unseen   Sep 11 19:55 UTC 2002

Also, there was a very long discussion of the one person, one vote policy in
coop9, item 7.
cross
response 169 of 184: Mark Unseen   Sep 11 23:32 UTC 2002

Regarding #93; Yes, I worry about it.

Regrding #111; The question is, what data do you keep?  If they send you
a driver's license, that's fine.  Do you need to keep their DL number and
other identifiers, or just their name, address, and possibly phone number?

Regarding #113; So far, I've never heard of an Internet cafe being sued.
It seems unlikely that it would happen.  However, I agree with you about
the geographic limitation versus global accessability.

Regarding #115; That sounds like an excellent solution; look at the ID,
record the name and address, etc, and then destroy it.

Regarding #117; I had forgotten about that incident; it was rather
amusing.  It's a good point, but even if that company had sent a driver's
license or similar, that doesn't mean it would need to be retained.
There's a minimum of information that grex *needs*, and it ideally it
shouldn't store any more than that.

Regarding #137; Yes, I am telling you that public kiosks at Columbia
allow public access (isn't that implicit in the definition of ``public
kiosk?''), and I'm telling you that a Java applet can save files to the
local machine's disk.  Of course they have a network interface; they're
kiosks.  They run Linux, boot off the network, and reinitialize the disc
every time they come up; if you're concerned about security, power-cycle
the machine.  The diskette drives have a physical lock mechanism in them
that prevents one from booting off a floppy, but we can afford that.

Regarding #140; The issue isn't the *asking* of ID, it's what is done
with the ID after its received.

Regarding #142; Seeing an ID doesn't mean you have to keep it.

Regarding #161; dude, that's just rude.
jp2
response 170 of 184: Mark Unseen   Sep 12 02:58 UTC 2002

This response has been erased.

bhelliom
response 171 of 184: Mark Unseen   Sep 12 17:23 UTC 2002

resp:170 - Believe what you will.
 0-24   25-49   50-74   75-99   100-124   122-146   147-171   172-184   
Response Not Possible: You are Not Logged In
 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss