|
How about this: provide a compile-time configuration switch that makes it easy to compile a client that either does, or does not send this client data by default. Large corporations might choose to compile the version that sends data unless told not to; private individuals working across the internet might choose to build the other version--or to simply turn off the option at run-time.
Failing to provide these sorts of options could conceivably result in people trafficking lot of semi-standard, hacked versions of cvs that don't encroach upon their privacy by default. Having seen public reaction to some similar mechanism that other vendors built into some of their products, my feeling is that this type of client behavior must be treated in a very careful sort of way, to avoid losing users.
hope this adds some ideas...
thanks
john h
-----Original Message-----
From: Kostur, Andre [mailto:Andre@xxxxxxxxxxxxx]
Sent: Friday, October 25, 2002 10:38 AM
To: 'Derek Robert Price'; hubbardjohn@xxxxxxxxxxxxx
Cc: 'bug-cvs@xxxxxxx'; 'dev@xxxxxxxxxxxxxxxx'; konrad.rosenbaum@xxxxxxx
Subject: RE: Right to privacy & client info strings
This may sound extremist, but that's just like saying "If it's an opt-in mailing list, nobody will opt-in! So I'll default to assuming you want the mail, and you can opt-out" (OK, except that you can't trust the spammer's opt-out mechanism, where you [hopefully] _can_ trust the CVS client to not send the data).
If a client is having issues, I don't think that there's a problem with the CVS admin saying: "Well, there seems to be a problem and I need to know some additional information. Could you set this debug option on, and try again please?"
-----Original Message-----
From: Derek Robert Price [mailto:derek@xxxxxxxxxxx]
Sent: Friday, October 25, 2002 10:30 AM
To: hubbardjohn@xxxxxxxxxxxxx
Cc: 'bug-cvs@xxxxxxx'; 'dev@xxxxxxxxxxxxxxxx'; konrad.rosenbaum@xxxxxxx
Subject: Re: Right to privacy & client info strings
My aim is to make debugging easier in large heterogeneous environments
where the admin (debugger) only controls the CVS server. This wouldn't
be very useful if the client users had to turn on the string themselves.
Anyone who really objects could turn it off. Clients could be written
(or hacked) easily enough to lie too - this wouldn't be security - it
would just be there to try and spot trends while debugging though I
suppose it could be used to spot usage demographics like with HTTPD logs.
Derek
--
*8^)
Email: derek@xxxxxxxxxxx
Get CVS support at <http://ximbiot.com>!
--
151. H lp! S m b dy st l ll th v w ls fr m my k yb rd!
ATD Hubbard, John wrote:
> The idea of allowing the client to turn off the data is delightful.
> Everyone gets what they need. Seems hard to imagine that anyone could
> complain, especially if the client option default is NOT to send the data.
>
> thanks,
> john h
> --------------------------------
> John F. Hubbard
> (408) 297-8217 (Home)
> (408) 919-1620 (Work)
> hubbardjohn@xxxxxxxxxxxxx
>
>
> -----Original Message-----
> From: Derek Robert Price [mailto:derek@xxxxxxxxxxx]
>
> Would anyone object strenuously to a hook in the client/server protocol
> to send client information such as host platform, client name, client
> version, and a few other facts that might make debugging intermittant
> client/server problems easier?
>
> How about if there was a client option to turn off the data?
>
> Derek
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxx
| 
