Policy-Discussion

[Alex Robertson <alex-uk AT cacert.org>]

On 28/05/2014 19:40, Eva Stöwe wrote:
> Dear Alex,
>
> > So what is wrong with my suggestion - it moves towards the framework you
> > want and doesn't leave a gaping hole to fall into! I'm not against the
> > idea of a separate policy or even a procedure about the matter, but I do
> > want to know what I am agreeing to.
> why?

CCA is a not just a policy - it is a contract - hence a legal document. 
It would be regarded as not being good practice to refer to a 
non-existent addendum in such a document. If the intent is to leave it 
with the arbitrators until a policy is in place then say so. If there is 
another intent then say so. Just don't leave it open.

At this point, I'd be perfectly happy for the new policy to define the 
triggers if that's where you want them and what the result of those 
triggers is to be.

In addition, most "ongoing" contracts should have the exit conditions 
specified in whatever manner - currently it is that certain requests 
will effectively either create an arbitration case or will follow an 
earlier arbitrators ruling in order to terminate. Without the new policy 
being present there is a risk of CCA being declared void if it were 
challenged legally since the terms were not made clear to one of the parties

It costs nothing to put a very short subsidiary policy in place that 
simply says that "only an arbitrator may terminate this agreement" and 
then return to it when ready.

Note that I feel as strongly about this as you seem to about privacy.

I am happy to discuss that subsidiary policy in due course, but since 
CCA is a legal document, I object strenuously to the idea of leaving it 
undefined.
> And as long as it is not defined - as so many other things are not
> defined - it's back to arbitration - so we should be fast to put
> something in place.
Not necessarily true - this is a gross assumption to make in a legal 
document - Simply define that it does and it's resolved.

> As for termination in case of death: Nobody has had any better idea. It
> would at least give an idea where R/L/O may be put (even if I would
> prefer to have something more. s - we even do not know the nationality
> of our members.
Agree in general - the issue I had was that there was (and still is!) no 
way that death can terminate the agreement other than as a 2.5.2 
violation. It is not even one of the current triggers for a termination 
process - in practice I see no real option to the route Uli went down as 
far as R/L/O are concerned as this is currently a contract between an 
individual and CAcert Inc. Board did not like it at the time, and I 
suspect that they would be unhappy if this were used as the default but 
this is probably for another time.



> If it is a trigger it HAS to activate the process not "MAY" activate the
> process.
Hmm...  Conditional, future, imperfect and subjuctive - May is one of 
several forms of  correct use of English in this context but would not 
be appropriate in the document


> In our principles we write that we value education high. So why do you 
> suggest that we should answer ignorance with watering up our ideas 
> instead of trying to educate how to do it correct?

In an ideal world. However, when people don't want to learn, you cannot 
force them to.

> If you did it with your own account this should be easy - sharing a 
> computer is not the same as sharing n account on a computer. 

The point I'm making is that - given physical access to a machine - it 
is not in general particularly difficult to get hold of keys, passwords, 
whatever if they are held on that machine. Some systems may be harder 
(more secure!) than others.

> Well you cannot assign an email to two accounts - and you cannot just 
> free an email from one account. Sure you can get another email for 
> another account quite fast. Everything else probably an issue for an 
> Auditor. But at least we should be able to identify the person or at 
> least a person who assured the person. ;-) 
Always provided that we know it has happened. As I say, I am not aware 
of any "active" checking to prevent it. This means that there could be 
an huge number of spurious certificates out there - I don't think there 
are, but I cannot show it to be a fact.

> At least they would not have more than vote rightfully, as there is 
> one vote per member and not per member account. (PoP does not ask for 
> a vote at all - it asks for rough consensus. 
I think a vote can be called for by anyone....
> > It may or may not be - show me the research and maybe I'll believe it,

> > Why should I do this? With the same right I could ask you to present
> > research that people do not join CAcert because of this.
You were the one making the initial sweeping assertions! What you've 
explained justifies your belief - but it is a limited view as even you 
stated. That said - one counterexample is sufficient to make it clear is 
does not apply to all people.

> > Not necessarily - it would normally depend on the terms of the contract
> > they have - in all cases I believe it falls back to NSW law under either
> > CCA or under NRP rules.
> Just because we say so?
Any claim would have to be made against what we purport to offer. We 
define clearly the laws we regard as applicable in the various documents 
so those laws form the basis of that contract. Yes - international legal 
cases do occur - and make lawyers rich
> > What about simplifying it to "You are responsible for all activity on
> > your account" and just leaving it at that.
> Why?
Why not! It's clear and simple! (and see next para!)
> > The difficulty with the "must not" approach is that you cannot logically
> > then make the conseqences explicitly clear at that point.
> Sure I can: Up to 1000€ and other penalties awarded against the member
> by arbitration.
>
> As stated in 2.2 Liabilities.
This comes back to member education - I agree with the facts - but this 
is one place where reiteraring that an user is liable for all activity 
on his/her account might beneficial.

Alex

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature