>* How much "right to privacy" are users entitled to? Information
>providers often use access logs to cost-justify their operations, so
>they need to know at least generally who's accessing what. But I think
>it's pretty widely agreed that keeping information like "Joe User
>accessed cindy.gif at 2:47pm on Jun 12, 1994" is a violation of Joe's
>privacy.
I am a UNIX sysadmin at Rice University (by day). A couple of
years ago ... maybe three? ... we hashed out our policy w/r/t privacy.
We concluded that as system administrators we could NOT guarantee our
users privacy, but WOULD promise them confidentiality. The difference
seems to be omitted or forgotten or otherwise missed, but is important.
We stated formally that we might through the exercise of our duties
get specific information that the users might not want us to have,
but we purpose to not divulge that information unless legal or
university requirements mandated that we do so. I like it.
Aggregate info is a problem ...
>* On the other hand, nothing is currently keeping information providers
>from lying about their readership. In the magazine business, there are
>auditors that will check claims like "we have a 10,1000 qualified
>subscribers."
How can one confirm this without looking at some details?
>* Can information providers tell clients not to pass on Referer:
>information? That is, can an information provider declare that the
>address of its documents are sensitive information, not to be
>divulged? ...
How can that be enforced? (I've been wondering how the -m
option to PGP can *really* keep decrypted cleartext off the recipient's
disk; recipient could very well have modified PGP to ignore it, no?)
(then again, I'm new to PGP and so may have misunderstood the meaning)
There's a senseless (IMHO) law that you can't listen in on
people's cel-phone conversations. The reason it's senseless is that
[kinda like gun control] only the good guys will comply. It gives
the end user (here the cel-phone customer) a false sense of security.
This is common knowledge for you and me w/r/t e-mail. But the newbies
don't know. So it'll have to start with some education. A canonical
document that explains the facts clearly and concisely, almost like a
constitution.
>But suppose client C uses secure-HTTP or whatever to access
>confidential information at X, which contains an link to public
>site Y. C's request to Y will not be encrypted, and X may consider
>it's document addresses sensitive.
Seems to get back to what is practial, for which we at Rice
happily hid behind the technology. ;-)
We've been putting a lot of value on privacy here in the US
lately. I'll have to go back and re-read the constitution, but I
don't think we're guaranteed a right to privacy. Freedom of speech,
and freedom in general, doesn't go hand-in-hand with privacy. Now it's
true that someone will invade your privacy to interfere with your freedom.
But privacy itself isn't all that valuable except where it supports
freedom. That is, freedom is more valuable than privacy.
But you have to trust someone. As we (philosophically in the US)
don't trust the government, drawing analogy we might choose to not trust
the providers. They might promise things that they can't deliver or
can't deliver economically, like privacy and confidentiality.
I'm one to argue for stronger local government and leaner
federal government. Here too, a local community is better able to
know its own needs, and thus in many ways better able to meet them.
Server X must have a certain relationship with client C before sharing
the keys. X and C must be in the same "community". Therefore C
(the human) must agree to abide by whatever "law" says that X's
document addresses shall not be divulged. It gets simple:
if C won't play by the rules, then C can't enter into the game.
So C (the human) won't knowingly run a client program that leaks.
Getting back to the committment we made at Rice and how it
relates to the Web: the user has NO "right to privacy" once the user's
activities take him beyond the realm of those promising privacy.
>Just thinking...
>
>Dan
-- Rick Troth <troth@ua1vm.ua.edu>, Houston, Texas, USA http://ua1vm.ua.edu/~troth/