Policy-Discussion

[Ian G <iang AT systemics.com>]

Sven Anderson wrote:
> Ian G, 17.01.2007 18:24:
> > Sven Anderson wrote:
> > > Ian G, 13.01.2007 16:56:
> > > If the trust of the system is based on it's public transparency, then
> > > privacy is counterproductive. If I have a certificate of somebody, and I
> > > want to check it on the CAcert website, I would like to see a list of the
> > > assurers and their assurer points (not necessarily their names though!) If
> > > I just see the number of assurances, or even just an "assured" flag, my
> > > trust in his identity is less.
> > What happens if the Assurers don't want their names to be 
> > released?  See below for more concrete example.
>
> > From the POV, that users of a community want to confirm their "official"
> identities of each other, it's somehow a contradiction to want your name
> to stay private, as such a community is a blurred and open thing.


Right, but this simply highlights your assumption:  that 
users want to confirm their "official" identities to each other.

I want no such thing (speaking as an individual) and I don't 
know why others want it :-)

I want to use certs.  Actually, I don't want to use certs at 
all, I want to be secure in my use of the net.  I can say 
this with  a level of confidence because I design and build 
systems that are an order of level more secure than 
browsing, and they do not use certs;  using certs 
universally reduces security as far as I can see.

Security in my use of the net does not require me to confirm 
my identity to you or anyone .... but because the browsers 
require a certain "PKI certs" regime, users are pushed into 
doing that.

This perhaps best stated as the "popup avoidance" 
interpretation of CAs.  Users will do whatever it takes to 
avoid popups, and CAs make money off that.

Supporting user's needs is a noble mission for CAcert, and 
if that means that we have to "verify identities" so be it. 
 But we should be very careful to understand that the users 
are the mission, not their identities.

To close:  if I was an Assurer (I am not) I would not want 
my name on any list of "who Assurered this person." 
Somebody else's popup avoidance isn't worth enough to let my 
name be exposed to marketeers and scamsters.


> But: I'm maybe radical in the goals but not a fundamentalist. As you can
> see I wrote above: "not necessarily their names though". In a list of
> assurers it is not necessary to show the names, the assurance-level is
> enough. (In an advanced system of course some assurers could allow me as
> an user to see their names in such lists, based on personal configuration,
> as you proposed before.)


Yes, exactly.  A deeper level of analysis of the assurance 
strength is always possible ... lots of good possibilities.

My view:  currently, CAcert has enough to do in sorting out 
the current simply system without improving it :)

For example, CAcert has to establish what it means to be an 
Assurer.  The old view, having been assured to 100 points, 
was simply inadequate.  To sort this out:

  1.  a test is being prepared,
  2.  a handbook is being worked on, and
  3.  at some recent assurance events, Assurers have 
started to split into two groups, being "senior" and 
"junior" (words I pick, not formal) where the former group 
checks and critiques and helps the latter group.
  4.  the Super-assurer concept is being frowned upon 
(speaking in a formal capacity, once we go through the above 
list, we'll start auditing the super-assurances and maybe 
start striking them off.)
  5.  Ditto TTP programme.

These are all good things, which help to establish what the 
term Assurer means.  In audit-speak, establish a minimum 
standard.

I'd say that improving the concept is something we can do 
when we've got a firmer grip on what it means now.


> I just want to propose the following rules in the given order:
> 1. store as few information as possible.
> 2. make as much information available as possible.
> 3. give the user the control of 1. and 2. where possible.
>
> I don't want, that the whole database-dump can be downloaded by everyone
> for instance. Of course not. I'm just approaching the reasonable solution
> from the other side.


I agree with the principle of it.  I've seen too many 
situations where the organisation said "you're safe because 
we protect the data."  They weren't exactly lying, but they 
were very wrong, and professionally negligent.


> > that the best way to protect stored data is to publish it 
> > because that forces you to show that the data is needed. 
> > But it's not a necessary result;  it's not the only way.  If 
> > data like assurer points is needed to usefully calculate 
> > your points, then it can be stored, but not published but 
> > kept secret.
>
> Yes, but I want that we have to argue for why it should be kept secret,
> and not for why it should be published.


Oh, sure.  For my part, I want no info about me on the net, 
except that which I publish.  I've read way too many insider 
stories about how the US data industry works to want it any 
other way....

So, in a sense, what you are suggesting is not a concrete 
change, but the adoption of a principle.  Like the Mozo 
exercise that just started up:

https://financialcryptography.com/mt/archives/000858.html

Your principle(s) might then look like:

a. Data stored is normally publishable.
b. Data published is under user control.
c. Secret data is only accessible under DR rules.
d. Secret data is aggressively kept to the minimum possible.

Or somesuch ... Perhaps we should start a Principles Project?


> > But there are other ways to get control of your data or to 
> > establish confidence that the data stored is appropriate: 
> > ask to see it all, become a system administrator and learn 
> > how the database stores its fields, become a programmer and 
> > read the code, do an audit, especially with a privacy 
> > criteria, file a dispute and get your data, etc etc.
>
> That should be the way for the average user, who just wants to know, what
> data about him does exists and what is done with it?


If that is a concern, then create a standard dispute that 
can be filed?  Or, create a standard program where the 
webpage has a button that spits out a report on all the 
personal data on that person, as permitted?


> > > Also it's easier to correct wrong assurances and make the system
> > > self-stabilizing. I had many cases, where I didn't want to give any
> > > assurance points, but the user already got points! I had no possibility to
> > > vote for a assurance point withdrawal. (Sending these cases all to a
> > > support AT cacert.org
> > >  cannot be the solution.)
> > OK, so how should this be done?  Maybe you as an Assurer can 
> > set negative points?
> >
> > But if you as Assurer can set negative points, and your name 
> > appears as having done that, will you still do it?  Most 
> > will not.
>
> Why not? I will, and I will be proud that I found a mistake. ;-)


Excellent!  I just don't know if we have enough Assurers 
like you ;)


> 1. As I wrote above: I can see that some people don't want to be listed
> with real name in assurer lists, so I agree with you: let the user choose.


OK, grand.  Some people actually like to see their name up 
there in lights :)


> 2. It should be clear, but I have to emphasize again, that the
> assurance-points are just a valuation of the link between an CAcert
> account and the data on official documents. In no way it is a valuation of
> the person itself. So there's no need to feel ashamed to give "negative"
> points.


OK, so how do we go about that?  I actually don't quite see 
the meaning of negative points.  I would wonder whether you 
should file a dispute and have the Arbitrator review that 
rating and perhaps he rules on taking points off?

As in, why can one Assurer take off the points of another 
Assurer (which is just what "giving negative points" would 
be) ????

But, yes, you are right.  It is more or less an assessment 
of "official docs" rather than any personality quirks. 
Should that be stressed on the form?  Should that be 
stressed on the website?


> > Right, and the feedback system is published so it tends to 
> > be over-positive ... which then leads to confidence scams. 
> > That doesn't mean that CAcert shouldn't do it, but there is 
> > no perfect answer here.
>
> Not such a big problem IMHO. Peoples perception will adapt to it.


OK.

Good debate, some more forward movement... (I'm a bit rushed 
on it, excuse any leaps into craziness.)

iang