diff --git a/Agreements/3PVDisclaimerAndLicence.html b/Agreements/3PVDisclaimerAndLicence.html new file mode 100644 index 0000000..bc3755b --- /dev/null +++ b/Agreements/3PVDisclaimerAndLicence.html @@ -0,0 +1,395 @@ + + + +
+This is DRAFT-V0.02. +
+ ++Being that, +
+ ++And that, +
+ ++And that, in offering the USE of certificates to the end-user, +
+ ++And that, +
+ ++We both, CA and Vendor, agree that, +
+ ++Terms used in this agreement are as defined in the + +CAcert Community Agreement. +
+ + ++You and CAcert both agree to the terms and conditions in this agreement. +The relationship between the CA and the Vendor is based on this agreement. +Your agreement is given by your distribution of the root within your +distribution of your root list. +
+ ++The relationship between the Vendor and the end-user is based on Vendor's own agreement +("end-user licence agreement" or EULA). +Generally, the Vendor offers the EULA to the end-user +in the act of distributing the software and roots. +
+ ++The relationship between the CA and the end-user is based on CA's +Non-Related Persons -- Disclaimer and Licence +("NRP-DaL"). +This Licence follows the style of popular open source licences, +in that it is offered to an unknown audience, without a necessary +expectation for explicit agreement by the end-user, +because of the methods and restrictions of delivery. +
+ ++CA offers this licence to permit Vendor to distribute CA's roots +within Vendor's root list to Vendor's end-users. +
+ ++Vendor agrees to make EULA compatible and aligned with the CA's NRP-DaL. +Specifically, the EULA must: +
+ ++all with respect to the root list +(including root keys, certificates, +and related cryptographic and security software). +
+ ++Where agreement is explicitly sought from the end-user +they will be offered and agree to: +
+ +
+Vendors are encouraged to ship the NRP-DaL with their software,
+and make available means for the end-user to further
+examine the NRP-DaL.
+
Note, document this elsewhere in FAQ.
+
+Vendor agrees to make available CA's root key
+in a fair and non-discriminatory way to Vendor's end-users.
+
Note, document this elsewhere in FAQ.
+
+Vendor's relationship with end-users creates risks, liabilities +and obligations due to the end-user's permitted USE of the certificates, +and potentially through other activities such as inappropriate +and unpermitted RELIANCE. +
+ ++We in general DISCLAIM ALL LIABILITY to each other and to the end-user. +
+ + ++Notwithstanding the general disclaimer on liability above, +we agree that, to the extent that CAcert is reasonably +represented to the Vendor's end-user by the software +as being the Certificate Authority, at the events and +circumstances of question, +liability of CAcert is strictly limited to be 1000 euros. +This is the same limit of liability that applies to each +member of the CAcert Community. +
+ ++To the extent that the CA is not reasonably represented +to the end-user, we agree that any liability is limited +to the lowest of agreed liabilities of all CAs for all +roots shipped by the Vendor, and 1000 euros. +
+ ++The Choice of Law is that of NSW, Australia. +
+ ++We agree that all disputes arising out +of or in connection to this agreement +and the root key of the CA +shall be referred to and finally resolved +by Arbitration under the +Dispute Resolution Policy of the CA +(DRP => COD7). +The ruling of the Arbitrator is binding and +final on CA and Vendor alike. +
+ ++We further agree, as a single exception to DRP, +that the single Arbitrator may be chosen from outside +the CAcert Community. +
+ ++The CA also offers a CAcert Community Agreement (CCA). +The CCA replaces the NRP-DaL and this present agreement +for those parties that accept it. +
+ ++If a Community member is also an end-user, then the provisions +of the CCA will replace all elements of the CA's NRP-DaL, +and will dominate this present agreement. +
+ ++Acceptance alone of this present agreement by the Vendor +does not imply that Vendor is a Community User/Member. +
+ ++The following parts are not part of the above licence, +but may shed light. +
+ ++Liability agreement between CA and Vendor +suggests that the end-user be presented with the name of the CA. +This is useful for identifying the particular characteristics +of the CA, and accepts that all CAs are different. +Each CA has its ways of checking, its relevent laws, and its +particular view as to the interests of the end-user. +
+ ++The Vendor should present the name of the CA so as to inform +the end-user of what can be known. +In the event that the Vendor does not present the CA, +the CA is taking on all the risk and liability that the +CA is equivalent to others, which can only be rationally +measured as the lowest-common-denominator, that is, +the lowest of the liabilities that is accepted across all +CAs that are shipped by the CA. +This would generally be zero. +
+ ++If the CA has been presented to the end-user, the end-user +is able to discriminate. +In this case, it is reasonable for the CA to offer to share +the liability, and to accept some limit +to that liability. +
+ ++Always remembering that this is strictly within the +relationship with the Vendor. +As there are millions and one day, billions of users, and as +the software and the certificates are free, the liability +to the end-user must be disclaimed totally. +In other words, set to zero. +
+ ++To reasonably show the name of the CA is undefined, +as security user interfaces currently are not representative +of reasonable descriptions, and the area is an open research +topic (sometimes known as "usable security"). +
+ ++A reasonable man test is known in law, and selects someone +who would be the reasonable person who would use the software. +This might hypothetically examine whether a majority of +random users would have "got it" when presented with the +same information, however this is not quite how it is tested +in law; instead, it is more of a gut-feeling. +
diff --git a/Agreements/CAcertCommunityAgreement.html b/Agreements/CAcertCommunityAgreement.html new file mode 100644 index 0000000..4725355 --- /dev/null +++ b/Agreements/CAcertCommunityAgreement.html @@ -0,0 +1,512 @@ + + + ++This agreement is between +you, being a registered member ("Member") +within CAcert's community at large ("Community") +and CAcert Incorporated ("CAcert"), +being an operator of services to the Community. +
+ ++You and CAcert both agree to the terms and conditions +in this agreement. +Your agreement is given by any of +
+ ++Your agreement +is effective from the date of the first event above +that makes this agreement known to you. +This Agreement +replaces and supercedes prior agreements, +including the NRP-DaL. +
+ + ++As part of the Community, CAcert offers you these rights: +
+ ++You agree to a non-exclusive non-restrictive non-revokable +transfer of Licence to CAcert for your contributions. +That is, if you post an idea or comment on a CAcert forum, +or email it to other Members, +your work can be used freely by the Community for +CAcert purposes, including placing under CAcert's licences +for wider publication. +
+ ++You retain authorship rights, and the rights to also transfer +non-exclusive rights to other parties. +That is, you can still use your +ideas and contributions outside the Community. +
+ ++Note that the following exceptions override this clause: +
+ ++You give rights to CAcert to store, verify and process +and publish your data in accordance with policies in force. +These rights include shipping the data to foreign countries +for system administration, support and processing purposes. +Such shipping will only be done among +CAcert Community administrators and Assurers. +
+ ++Privacy is further covered in the Privacy Policy ("PP" => COD5). +
+ ++As a Member, you have risks, liabilities +and obligations within this agreement. +
+ ++ You are obliged +
+ ++As a Member of CAcert, you are a member of +the Community. + You are further obliged to + work within the spirit of the Principles + of the Community. + These are described in + Principles of the Community. +
+ ++CAcert exists to help you to secure yourself. +You are primarily responsible for your own security. +Your security obligations include +
+ ++Where, above, 'secure' means to protect to a reasonable +degree, in proportion with your risks and the risks of +others. +
+ ++This agreement is governed under the law of +New South Wales, Australia, +being the home of the CAcert Inc. Association. +
+ ++You agree, with CAcert and all of the Community, +that all disputes arising out +of or in connection to our use of CAcert services +shall be referred to and finally resolved +by Arbitration under the rules within the +Dispute Resolution Policy of CAcert +(DRP => COD7). +The rules select a single Arbitrator chosen by CAcert +from among senior Members in the Community. +The ruling of the Arbitrator is binding and +final on Members and CAcert alike. +
+ ++In general, the jurisdiction for resolution of disputes +is within CAcert's own forum of Arbitration, +as defined and controlled by its own rules (DRP => COD7). +
+ ++We use Arbitration for many purposes beyond the strict +nature of disputes, such as governance and oversight. +A systems administrator may +need authorisation to conduct a non-routine action, +and Arbitration may provide that authorisation. +Thus, you may find yourself party to Arbitration +that is simply support actions, and you may file disputes in +order to initiate support actions. +
+ ++You may terminate this agreement by resigning +from CAcert. You may do this at any time by +writing to CAcert's online support forum and +filing dispute to resign. +All services will be terminated, and your +certificates will be revoked. +However, some information will continue to +be held for certificate processing purposes. +
+ ++The provisions on Arbitration survive any termination +by you by leaving CAcert. +That is, even if you resign from CAcert, +you are still bound by the DRP (COD7), +and the Arbitrator may reinstate any provision of this +agreement or bind you to a ruling. +
+ ++Only the Arbitrator may terminate this agreement with you. +
+ ++CAcert may from time to time vary the terms of this Agreement. +Changes will be done according to the documented CAcert policy +for changing policies, and is subject to scrutiny and feedback +by the Community. +Changes will be notified to you by email to your primary address. +
+ ++If you do not agree to the changes, you may terminate as above. +Continued use of the service shall be deemed to be agreement +by you. +
+ ++Notifications to CAcert are to be sent by +email to the address +support at CAcert.org. +You should attach a digital signature, +but need not do so in the event of security +or similar urgency. +
+ ++Notifications to you are sent +by CAcert to the primary email address +registered with your account. +You are responsible for keeping your email +account in good working order and able +to receive emails from CAcert. +
+ ++Arbitration is generally conducted by email. +
+ ++As well as you and other Members in the Community, +CAcert forms agreements with third party +vendors and others. +Thus, such parties will also be in the Community. +Such agreements are also controlled by the same +policy process as this agreement, and they should +mirror and reinforce these terms. +
+ + ++This agreement is CAcert Official Document 9 (COD9) +and is a controlled document. +
+ ++You are also bound by +
+ ++Where documents are referred to as => COD x, +they are controlled documents +under the control of Policy on Policies (COD1). +
+ ++This agreement and controlled documents above are primary, +and may not be replaced or waived except +by formal policy channels and by Arbitration. +
+ ++The governing documents are in English. +Documents may be translated for convenience. +Because we cannot control the legal effect of translations, +the English documents are the ruling ones. +
+ ++You are encouraged to be familiar with the +Assurer Handbook, +which provides a more readable introduction for much of +the information needed. +The Handbook is not however an agreement, and is overruled +by this agreement and others listed above. +
+ ++Intellectual Property. +This Licence does not transfer any intellectual +property rights ("IPR") to you. CAcert asserts and +maintains its IPR over its roots, issued certificates, +brands, logos and other assets. +Note that the certificates issued to you +are CAcert's intellectual property +and you do not have rights other than those stated. +
+ + + + diff --git a/Agreements/NRPDisclaimerAndLicence.html b/Agreements/NRPDisclaimerAndLicence.html new file mode 100644 index 0000000..4d410fb --- /dev/null +++ b/Agreements/NRPDisclaimerAndLicence.html @@ -0,0 +1,136 @@ + + + +NRP-DaL | ++ | (Advisory) | +
POLICY m20070918.1 | ++ | + $Date$ + + | +
COD4 | ++ | + |
+
+Non-Related Persons+(Disclaimer and Licence)+ + +Definitions+ ++This is a Disclaimer and Licence from + CAcert Inc , +the "issuer", +to you, the "user," +being a general user of the Internet. + + +Disclaimer+ ++The issuer has no other agreement with you, +and has no control nor knowledge +as to how you intend to use the products of the issuer. +You alone take on all of the risk and all of the +liability of your usage. +The issuer makes no guarantee, warranty nor promise to you. + + ++Therefore, to the fullest extent possible in law, +ISSUER DISCLAIMS ALL LIABILITY TO YOU +on behalf of itself and its related parties. + + +Licence+ ++This licence offers you a non-exclusive, non-transferable +'PERMISSION TO USE' certificates issued by issuer. + + +
|
+If you find the terms of the above +Non-Related Persons +Disclaimer and Licence +difficult or inadequate for your use, you may wish to +
+ ++These alternatives are outside the above +Non-Related Persons Disclaimer and Licence +and do not incorporate. +
+ + + diff --git a/DisputeResolutionPolicy.html b/DisputeResolutionPolicy.html new file mode 100644 index 0000000..a84645f --- /dev/null +++ b/DisputeResolutionPolicy.html @@ -0,0 +1,639 @@ + + + + +DRP | ++ | Teus Hagen | +
POLICY m20070919.3 | ++ | + $Date$ + + | +
COD7 | ++ | + |
+ | Dispute Resolution Policy | ++ |
+This is the Dispute Resolution Policy for CAcert. +Disputes arising out of +operations by CAcert and interactions between +users may be addressed through this policy. +This document also presents the rules for +resolution of disputes. +
+ ++Disputes include: +
+ ++Anyone may file a dispute. +In filing, they become Claimants. +
+ ++Disputes are filed by being sent to the normal +support channel of CAcert, +and a fee may be payable. +
+ ++Such fees as are imposed on filing will be specified +on the dispute resolution page of the website. +
+ ++The Case Manager (CM) takes control of the filing. +
+ ++The personnel within the CAcert support team +are Case Managers, by default, or as directed +by the Dispute Resolution Officer. +
+ ++The filing must specify: +
+ ++If the filing is inadequate for lack of information +or for format, the Case Manager +may refile with the additional information, +attaching the original messages. +
+ ++The Case Manager selects the Arbitrator according +to the mechanism managed by the Dispute Resolution Officer +and approved from time to time. +This mechanism is to maintain a list of Arbitrators available for +dispute resolution. +Each selected Arbitrator has the right to decline the dispute, +and should decline a dispute with which there exists a conflict +of interest. +The reason for declining should be stated. +If no Arbitrator accepts the dispute, the case is +closed with status "declined." +
+ ++Arbitrators are experienced Assurers of CAcert. +They should be independent and impartial, including +of CAcert itself where it becomes a party. +
+ ++The Board of CAcert and the Users vest in Arbitrators +full authority to hear disputes and deliver rulings +which are binding on CAcert and the Users. +
+ + ++The Arbitrator conducts some preliminaries: +
+ ++Jurisidiction - the right or power to hear and rule on +disputes - is initially established by clauses in the +User agreements for all CAcert Users. +The agreement must establish: +
+ ++An external court may have ("assert") jurisdiction to decide on +issues such as trademark, privacy, contract and fraud, +and may do so with legal remedies. +These are areas where jurisdiction may need +to be considered carefully: +
+ ++The Arbitrator must consider jurisdiction and rule on a +case by case basis whether jurisdiction is asserted, +either wholly or partially, or declines to hear the case. +In the event of asserting +jurisdiction, and a NRP later decides to pursue rights in +another forum, the Arbitrator should seek the agreement +of the NRP to file the ruling as part of the new case. +
+ ++Each country generally has an Arbitration Act +that elevates Arbitration as a strong dispute +resolution forum. +The Act generally defers to Arbitration +if the parties have so agreed. +That is, as Users of CAcert, you agree to resolve +all disputes before CAcert's forum. +This is sometimes called private law +or alternative dispute resolution. +
+ ++As a matter of public policy, courts will generally +refer any case back to Arbitration. +Users should understand that they will have +strictly limited rights to ask the courts to +seek to have a case heard or to override a Ruling. +
+ + ++ When an external court claims and asserts its jurisdiction, + and issues a court order, subpoena or other service to CAcert, + the CM files the order as a dispute, with the external court + as Claimant. + The CM and other support staff are granted no authority to + act on the basis of any court order, and ordinarily + must await the order of the Arbitrator + (which might simply be a repeat of the external court order). +
+ ++ The Arbitrator establishes the bona fides of the + court, and rules. + The Arbitrator may rule to reject the order, + for jurisdiction or other reasons. + By way of example, if all Parties are registered Users, + then jurisdiction more normally falls within the forum. + If the Arbitrator rules to reject, + he should do so only after consulting with CAcert counsel. + The Arbitrator's jurisidiction is ordinarily that of + dealing with the order, and + not that which the external court has claimed to. +
+ + ++The Arbitrator follows the procedure: +
+ + ++The Arbitrator records: +
+ ++Once the Ruling is delivered, the case is closed. +The Case Manager is responsible for recording the +Ruling, publishing it, and advising users. +
+ ++Proceedings are ordinarily private. +The Ruling is ordinarily published, +within the bounds of the Privacy Policy. +The Ruling is written in English. +
+ ++Only under exceptional circumstances can the +Arbitrator declare the Ruling private under seal. +Such a declaration must be reviewed in its entirety +by the Board, +and the Board must confirm or deny that declaration. +If it confirms, the existance of any Rulings under seal +must be published to the Users in a timely manner +(within days). +
+ ++The Ruling is binding and final on CAcert and all Users. +Ordinarily, all Users agree to be bound by this dispute +resolution policy. Users must declare in the Preliminaries +any default in agreement or binding. +
+ ++If a person who is not a User is a party to the dispute, +then the Ruling is not binding and final on that person, +but the Ruling must be presented in filing any dispute +in another forum such as the person's local courts. +
+ ++In the case of clear injustices, egregious behaviour or +unconscionable Rulings, parties may seek to re-open the +case by filing a dispute. The new Arbitrator +reviews the new dispute, +re-examines and reviews the entire case, then rules on +whether the case may be re-opened or not. +
+ ++If the new Arbitrator rules the case be re-opened, +then it is referred to the Board of CAcert Inc. +The Board hears the case and delivers a final +and binding Ruling. +
+ ++All liability of the Arbitrator for any act in +connection with deciding a dispute is excluded +by all parties, provided such act does not constitute +an intentional breach of duty. +All liability of the Arbitrators, CAcert, its officers and its +employees (including Case Manager) +for any other act or omission in connection with +arbitration proceedings is excluded, provided such acts do not +constitute an intentional or grossly negligent breach of duty. +
+ ++The above provisions may only be overridden by +appeal process (by means of a new dispute causing +referral to the Board). +
+ ++The Arbitrator generally instructs using internal remedies, +that is ones that are within the general domain of CAcert, +but there are some external remedies at his disposal. +He may rule and instruct any of the parties on these issues. +
+ ++The Arbitrator is not limited within the general domain +of CAcert, and may instruct novel remedies as seen fit. +Novel remedies outside the domain may be routinely +confirmed by the Board by way of appeals process, +in order to establish precedent. +
+ ++The advantage of this process for Users is: +
+ ++Some disadvantages exist. +
+ ++To the extent reasonable, the Arbitrator conducts +the arbitration as with any legal proceedings. +This means that the process and style should follow +legal tradition. +
+ ++However, the Arbitrator is unlikely to be trained in +law. Hence, common sense must be applied, and the +Arbitrator has wide latitude to rule on any particular +motion, pleading, submission. The Arbitrator's ruling +is final within the arbitration. +
+ ++Note also that many elements of legal proceedings are +deliberately left out of the rules. +
+ + + diff --git a/OrganisationAssurancePolicy/OrganisationAssurancePolicy.html b/OrganisationAssurancePolicy/OrganisationAssurancePolicy.html new file mode 100644 index 0000000..30c7086 --- /dev/null +++ b/OrganisationAssurancePolicy/OrganisationAssurancePolicy.html @@ -0,0 +1,379 @@ + + + +OAP | ++ | Jens | +
POLICY m20070918.x | ++ | + $Date$ + + | +
COD11 | ++ | + |
+ | Organisation Assurance Policy | ++ |
+This policy describes how Organisation Assurers ("OAs") +conduct Assurances on Organisations. +It fits within the overall web-of-trust +or Assurance process of Cacert. +
+ ++This policy is not a Controlled document, for purposes of +Configuration Control Specification ("CCS"). +
+ ++Organisations with assured status can issue certificates +directly with their own domains within. +
+ ++The purpose and statement of the certificate remains +the same as with ordinary users (natural persons) +and as described in the CPS. +
+ ++The Assurance Officer ("AO") +manages this policy and reports to the board. +
+ ++The AO manages all OAs and is responsible for process, +the CAcert Organisation Assurance Programme form ("COAP"), +OA training and testing, manuals, quality control. +In these responsibilities, other Officers will assist. +
+ ++
+ ++The Administrator within each Organisation ("O-Admin") +is the one who handles the assurance requests +and the issuing of certificates. +
+ ++There is one policy being this present document, +and several subsidiary policies. +
+ ++The nature of the Subsidiary Policies ("SubPols"): +
+ ++Subsidiary Policies are open, accessible and free to enter. +
+ ++The essential standard of Organisation Assurance is: +
+ ++ Acceptable documents to meet above standard + are stated in the SubPol. +
+ ++The COAP form documents the checks and the resultant +assurance results to meet the standard. +Additional information to be provided on form: +
+ ++The COAP should be in English. Where translations +are provided, they should be matched to the English, +and indication provided that the English is the +ruling language (due to Arbitration requirements). +
+ ++Organisation Assurances are carried out by +CAcert Inc under its Arbitration jurisdiction. +Actions carried out by OAs are under this regime. +
+ ++Foundations and Associations are now a strong part of CAcert's community. +In part this is because the Dutch have set up a great Foundation, Oophaga, +and a German Foundation named Secure-U is in the process of being +set up for the support in Germany (CeBIT, etc). +As time goes on, we'll get more and more questions on how to do this process. +
+ ++Let's start a policy on Foundations. Here is a WIP policy, +to get people thinking: +
+ ++In this policy, we refer equally +to Associations, Foundations, Vereins (German), Stichtings (Dutch), +and other legal forms found around the world. +For simplicity only the term Foundation is used in this document. +
+ ++ Foundations are a good mechanism to + provide local support to CAcert activities. + As a policy, the CAcert community encourages + well-governed Foundations to be created and + to take up local responsibilities. +
+ ++The Mission / Purpose should be controlled: +
+ ++Comments: +
+ ++... The "limitation of their purpose" has to be fortified. If we accept for example a german "Verein" with a very small membership base, these limitations can be easily changed by a member decission and therfore the way for a missuse of the money is prepared. So this limitation should be "fortified" and controlled carefully. I like (5), but can we - by legal terms - limit the change to a community process outside that foundation? If it is only inside, we need a broad member base ... +
+ +
+disagreement with your idea that the local foundations should be bound on the mission instead of being bound to CAcert. F.e. if the mission is "free certificates" then the local foundations could decide to spend the money to a free PGP project instead of CAcert for example. While it is fine for foundations to support many projects, if we create our own foundations we should make sure that they support CAcert. +
+ ++Creating a foundation with the goal of supporting projects who issue free certificates is completly different then creating a foundation with the goal to support the CAcert project. +
+ ++CAcert's mission itself is not defined. Is it "free certs" ? Is it "any free certs" or is it special "free certs?" We need to define free certs. +
+ ++ + ISOC suggests: +"2. Purpose of Chapters + +Chapters of the Internet Society are expected to serve the interests of a segment of the global Internet community in a manner consistent with the mission and principles of the Internet Society. Through a presence local to its community of interest, a Chapter focuses on issues and developments important to its community. A Chapter recognizes, honours, and uses the culture, customs, and language of its community. Every Chapter shall have an explicit statement of purpose. +
+ + ++ The Foundation should be legally independent from others, including CAcert Inc. +
+ ++Comment: Representing is difficult ... too much hierarchy. +There is a mutual thing with CAcert and others. E.g. +a set of foundations/associations with a common goal, +each with it's sub +area to take care of, each supporting the other. +
+ ++Right know we talk about foundations especially created for the support of CAcert. Or is it for free certs? Which is it? +
+ ++For example: There are several approaches to "issuing free certificates" (the "mission" for this example). I like some of them but not all. I like CAcerts approach. So I would donate money towards CAcert (CAcert's approach) but not to the overall mission "free certificates". If me move from a well-known name attached to a particular mission ("CAcert") to an overall "mission definition" we will lose our shape to the outside. This might confuse public. +
+ ++Or another example: CAcert is accepted as a "trusted CA" in more and more areas ("els..." "Sta...." for virtual post office...). If we move to an "mission attachment" outsiders might think about loose, uncontrollable structures while the believe in a fortified CAcert (which WE know it is not!). +
+ ++ + ISOC suggests: +"7. Liabilities The Internet Society shall not be liable for any act or omission or incurred liability of any kind of any Chapter." Also see "5. Public Positions and Statements." +
+ ++ The Foundation must maintain lines of communication + open with CAcert and the community. +
+ ++ The Foundation must govern its own books. +
+ ++Comment: +So we should define which level of bookkeeping we set as a minimum standard. We don't need to rise it up to the german standard for example, but we should define a minimum. +
+ ++ +Another idea: the "CAcert" foundations should be an Association member +of CAcert Inc. In this way one is less dependent of individuals in the +Association. With this I do not say that personal membership of the +association should be impossible. Having a subgroup of association +members who are a supervisory council and policy group with certain +responsibilities and power the CAcert association gets more body and +corrective entities. The foundations have still their own independence. +Is that something to bind the foundations, as well to get CAcert more +stable? + +
+ ++ +Maybe we could think of CAcert Inc. as a "parent foundation" (don't know if it's the right word. The child entities (the local foundations) are members of it. Having this in place would mean that the child entities (representing the users) have a certain amount of control because they do the AGM and vote in the board. By having this it would be even more protected. That's because control would need to be exercised over many daughter foundations before control of the main foundation was gained. + +
+ + ++=_("This policy discloses what information we gather about you when you visit any of our Web site, and when you issue or use our certificates. It describes how we use that information and how you can control it.")?> +
+ ++=_("We collect two kinds of information about website users: 1) data that users volunteer by signing up to our website or when you send us an email via our contact form; and 2) aggregated tracking data we collect when users interact with our site.")?> +
+ ++=_("When you post to the contact form, you must provide your name and email address. When you sign up to the website, you must provide your name, email address, date of birth and some lost pass phrase question and answers.")?> +
++=_("We only share your information with any other organisation when so instructed by a CAcert arbitrator.")?> +
+ ++=_("We analyse visitors' use of our sites by tracking information such as page views, traffic flow, search terms, and click through. We use this information to improve our sites. We also share this anonymous traffic and demographic information in aggregate form with advertisers and other business partners. We do not share any information with advertisers that can identify an individual user.")?> +
+ ++=_("Some of our advertisers use a third-party ad server to display ads. These ads may contain cookies. The ad server receives these cookies, and we don't have access to them.")?> +
++=_("We don't use cookies to store personal information, we do use sessions, and if cookies are enabled, the session will be stored in a cookie, and we do not look for cookies, apart from the session id. However if cookies are disabled then no information will be stored on or looked for on your computer.")?> +
+ ++=_("If we change our Privacy Policy, we will post those changes on www.CAcert.org. If we decide to use personally identifiable information in a manner different from that stated at the time it was collected, we will notify users via email. Users will be able to opt out of any new use of their personal information.")?> +
+ ++=_("You are able to update, add and remove your information at any time via our web interface, log into the 'My Account' and then click on the 'My Details' section, and then click the relevant link")?> +
+ ++=_("CAcert does not automatically publish the certificates through a directory +service or the website to other people than the user who requested the +certificate. In the future, the user might be able to opt-in for publication +of the certificates through a directory server by CAcert.")?> +
+ + + ++=_("CAcert Assurers can see the name, birthday and the number of points by looking up the correct email address. +No other person related data is published by CAcert. +")?> +
+ ++=_("A CAcert arbitrator may override this policy in a dispute.")?> +=_("To obtain access to confidential data, a dispute has to be filed.")?> +
+ ++=_("CAcert adopts the Australian privacy regulations.")?> +=_("Please see http://www.privacy.gov.au/ for further details.")?> +=_("Governmental warrants and civil supoenas will be processed through the dispute resolution system, which +ensures that valid authority is given to whoever complies with the supoena or the warrant.")?> +
+ + +=_("If you need to contact us in writing, address your mail to:")?>
+
+CAcert Inc.
+P.O. Box 81
+Banksia NSW 2216
+Australia
+