Policy-Discussion

[Ian G <iang AT systemics.com>]

Sven Anderson wrote:
> Ian G, 13.01.2007 16:56:
> > I personally would go half as far as that, I think people 
> > should have an ability to set a flag saying "public" on each 
> > piece of data.  So if I want to show my address and my 
> > assurers list, then I can.  If I want to show I've got 150 
> > points and I've passed the Assurance test, I can.  E.g., it 
> > is rather valuable in some circles to show that I am over 
> > the age of 18.
>
> Adress?... Age?... In Germany, and maybe in the whole EU, we have the
> (I'll try to translate:) "precept of data minimizing data processing"
> ("Gebot der datenminimierenden Datenverarbeitung"). So I think, there
> should be no data stored, unless it is necessary, because either it will
> be in the certificate (after having been assured), or because it is part
> of the web of trust. If you don't need it, just don't store it.


I see the point, in that EU principles of minimisation 
definately demand a point to collecting the DOB.


> > But forcing everyone to do that would I think be highly 
> > limiting.  What's wrong with providing privacy-oriented 
> > people the CAcert facility, with privacy for their 
> > activities?  It's not as if this hides anything specially, 
> > as you always need to check the details anyway if you are 
> > going to rely on them.
>
> 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.


> Don't get me wrong. I'm totally pro-privacy. But the best way of realizing
> privacy is to publish all data. That sounds paradox.


Yes, it sounds like a paradox, and I think it is:  It may be 
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.


> But then you are
> forced to anonymize as much data in you system as possible, that is
> _destroying_ the data, not just hiding it. And everybody can see by its
> own, how much data is really stored about him, and he can decide to let
> his data being removed. (I assume, there could be certain cases, where I
> would agree that storing but not showing the data is still the best
> option, but it should be the exception.)


Well, this is the real point that you are making:  that 
everyone is in (more) control of their data because they can 
see what is being stored and used.

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.

CAcert is open in many ways ... but this doesn't mean that 
it should be open in *all* ways.

...
> 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.


> That is also a way to get rid of the reliance/liability problem. CAcert
> can exclude all liability and build up _direct_ identity trust at the same
> time. Like ebay also isn't liable for a seller, who has an ass full of
> positive feedback, although they provide the feedback system.


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.


> > Why would you put it in the certificate?  That would then 
> > become stale;  surely you are interested in the assurance 
> > level today, the latest info available, not what happened a 
> > year back?
>
> Exactly. That's why there should be something like:
>
> "Assurance level at time of certificate issue: 580
> For current level and details visit http://cacert.org/userid";
>
> How cool would that be? ;-)

Sure, I wouldn't oppose it.  But I know a lot of people will 
go nuts if you try that ;)

Good debate, keep it up!

iang