Mary Hodder

Personal Terms and Contracts: Abbreviated Shorthand Designations

Abbreviation System for Terms: Human and Legal Implementations, Visualization of Implementation

  1. Human Readable Implementation [TBD]
  2. Legal Implementation
Legal Language (Appendix)

The choices that ordinary individuals make about disclosing their data are used to construct a contract between discloser and disclosee. The contract consists of some universal boilerplate, a few clauses that are selected from a standard set in order to match discloser choices, and several pieces of text that the discloser supplies as input. The resulting contract can be visualized like this:


1. Preamble

The preamble never changes:

This Agreement governs a specific Disclosure of Personal 
Information by Discloser to Disclosee, as defined and 
described hereafter. Discloser makes the Disclosure on the 
condition that Disclosee agrees to be bound by the terms and 
conditions herein.

2. Definitions

The agreement tries to incorporate terms by reference rather than redefining them.

Terms that begin with the prefix "dpv:" in this Agreement are defined in 
v1 of the Data Privacy Vocabulary (DPV; dated 5 Dec 2022; see 
https://w3c.github.io/dpv/dpv). Other terms are defined here.

The Agreement is this document, including inputs supplied by the parties, 
along with any definitions and explanatory material that it incorporates 
by reference.

The Discloser is the party to this Agreement that is the 
dpv:DataController of the Personal Information, that offers to disclose 
said information per the specified terms and conditions.

The Disclosed is a dpv:NaturalPerson dpv:DataSubject described by the 
Personal Information. The Disclosed may be the Discloser, or may be some 
other dpv:NaturalPerson (e.g., a dpv:Child or 
dpv:VulnerableNaturalPerson) for whom the Discloser has a 
dpv:DataController role (e.g., because the Discloser is a 
dpv:Representative).

After defining the Discloser and Disclosed, the agreement identifies the Disclosed in a way that is already meaningful to the Disclosee — for example, by a DID, a public key, a username, an email address, a social media handle, a phone number, an account number, or similar. Either the Discloser or the Disclosee can supply these two inputs, but both parties must agree that they characterize the Disclosed.

In this Agreement, the Discloser is the party known to the Disclosee, 
prior to the Disclosure, by the identifier ________________, which is of 
type _________________.


Personal Information is information about a natural person, as defined in 
regulatory frameworks such as GDPR, the UK's Data Protection Act 2018, 
Australia's Privacy Act 1988, PIPEDA, HIPAA, CCPA, COPPA, HIPAA, and so 
forth. This definition matches the meaning of dpv:PersonalInformation, 
but the list of referenced regulations here is broader, and the intent is 
that the list be illustrative, not exhaustive.

The Disclosee is the dpv:LegalEntity party to this Agreement that receives 
the Personal Information through its automated and/or human processes as 
a direct result of the Disclosure, and that processes that information. 
The Disclosee thus becoming a dpv:Recipient and dpv:DataProcessor of data 
about Disclosed. When the Discloser reasonably perceives the interaction 
governed by this Agreement to be with a Disclosee that is a 
dpv:Organisation, any dpv:NaturalPersons who serve as dpv:Representatives 
of said organization may acquire duties and responsibilities related to 
this agreement indirectly, via general legal constructs; however, it is 
the dpv:Organisation as a dpv:LegalEntity that is bound directly by the 
agreement.

After defining the Disclosee, the agreement identifies the Disclosee in a way that is already meaningful to the Discloser — for example, by a website, an SSL cert, a public key, a brand name, a street address, a phone number, or similar. Either the Discloser or the Disclosee can supply these two inputs, but both parties must agree that they characterize the Disclosee.

In this agreement, the Disclosee is the party known to the Discloser by 
the identifier ________________, which is of type _________________.

The Disclosure is the act undertaken by the Discloser that communicates 
the Personal Information to the Disclosee under the governance of this 
Agreement. Disclosure may change how much the Disclosee knows about the 
Disclosed, either by providing new information or by changing the 
Disclosee's certainty about information that it may already know or infer. 
Any changes in the quality or quantity of information that Disclosee 
possesses about Disclosed, or about the relationship between Discloser 
and Disclosed, as a result of Disclosure, are known as the Disclosed 
Delta. This Agreement places the processing of the Disclosed Delta under 
the dpv:Consent basis.

3. Recitals

The recitals document the context in which the Disclosure interaction is occurring. The begin with the following standard paragraph:

This Agreement focuses only on the narrow question of how to 
govern the Disclosure and subsequent usage of the enumerated 
Personal Information in the specified context. It 
supplements rather than replaces any fabric of larger and 
more general legal and regulatory frameworks that may exist 
at the time the Disclosure occurs. It must also be 
interpreted within the context of human rights that are 
stable across time and that cannot be contracted away.

The next piece of context is an enumeration of what specific pieces of data the Discloser is willing to disclose. These pieces of data must be described in terms that are meaningful to the Disclosee. If disclosure takes place via an HTML form, for example, the pieces of data must be described in terms of the arguments to the HTML form (effectively, the Discloser is saying, “I propose to give you data in your first_name, last_name, and zip_code fields”). If disclosure takes place with verifiable credentials, the pieces of data must be described in terms of a credential schema / credential manifest.

The Discloser proposes to disclose the following pieces of 
Personal Information about the Disclosed, in a structure 
known to the Disclosee, as follows (field names, schema, or 
similar): 

_______________________________________________________.

We also need a timestamp is to map the contract to larger context such as when a regulation or when a privacy policy went into effect.

The Discloser proposes to disclose this information at 
approximately this UTC timestamp: _____________________.

We also need some kind of documentation of what the Discloser perceives to be the context for the request. In most web-based interactions, this is communicated by a URL and possibly a cookie value for the session. If the Discloser is purchasing something, the URL should show a shopping cart checkout action, and the cookie would capture the state of the cart. This context serves as a constraint on how later provisos are interpreted.

The Discloser proposes to disclose the Personal Information 
in the following process context (URL plus cookie value, or 
similar): _____________________ .

We also need to stipulate some things about how the following provisos should be interpreted.

The following section of the Agreement imposes constraints 
on how Disclosee processes Personal Information. Disclosee 
agrees to be bound by these constraints: all uses of the 
data that are not granted by these provisos are prohibited. 
Disclosee further agrees that the Discloser retains all 
rights to privacy and constrained data processing that are 
established or upheld by applicable regulatory regimes, that 
are not explicitly limited by this Agreement. 

4. Provisos

This section of the contract is where the Discloser selects whichever clauses correspond to the choices that they make about the four central questions of P7012.

Possible Usage Provisos

The TXN, REL, and N provisos are mutually exclusive. The ENU proviso can stand on its own or can be combined with TXN or REL. If it is combined, it must follow the other proviso

TXN
TXN Usage: The Disclosee agrees that the Primary Use of the 
Disclosed Delta will be to deliver the specific good(s) or 
service(s) that the Discloser has already identified and 
that directly associate with the aforementioned process 
context (e.g., to deliver a nearly completed purchase). Data 
processing purposes that are compatible with this constraint 
include dpv:CustomerManagement, dpv:LegalCompliance, 
dpv:EnforceSecurity, dpv:OrganisationGovernance and 
dpv:RecordManagement. The dpv:ServiceProvision purpose is 
also compatible, except that processing for future 
dpv:SellProducts purposes is explicitly prohibited. 
Processing for purposes such as dpv:Marketing and 
dpv:Personalisation is explicitly prohibited.
REL
REL Usage: The Disclosee agrees that the Primary Use of the 
Disclosed Delta will be to facilitate an ongoing 
relationship in which the Disclosee delivers good(s) or 
service(s) to the Discloser and/or Disclosed. Data 
processing purposes that are compatible with this constraint 
include dpv:CustomerManagement, dpv:LegalCompliance, 
dpv:EnforceSecurity, dpv:OrganisationGovernance, 
dpv:ServiceProvision, dpv:Marketing and dpv:Personalisation.
ENU
ENU Usage: The Discloser allows the Disclosee to use the 
Personal Information for the following DPV processing 
purposes: 
_______________________________________________________. If 
a Primary Use is not defined elsewhere, the first item in 
this list is the Primary Use.
N
N Usage: Via this Agreement, the Discloser imposes no new 
constraints on how Personal Information is used. Data 
processing may still be governed by ambient regulation, 
policies of the Disclosee, and choices negotiated between 
the two parties elsewhere.
Possible Sharing Provisos

A given contract must contain exactly one of the following sharing provisos.

X
X Sharing: The Disclosee may share the Disclosed Delta with
any party that is a dpv:LegalEntity in one of these
jurisdictions: _________________, if that entity is a
dpv:Representative of Disclosee. Disclose must not share the
Disclosed Delta with any other party.
2
2 Sharing: The Disclosee may share the Disclosed Delta with
any party that is a dpv:LegalEntity in one of these
jurisdiction(s): _________________, if that entity is a
dpv:Representative of Disclosee. Disclosee may also share
the Disclosed Delta with other dpv:LegalEntitys in those
same jurisdictions, referred to as Collaborators, if and
only if the following conditions are met: 1) the
Collaborator's help is required for Disclosee to accomplish
approved data processing purposes; 2) the Collaborator
enters into a copy of this Agreement (hereafter "Chained
Agreement"), with all of its associated terms, conditions,
and provisos, directly with Discloser. Collaborator may
execute the Chained Agreement in a direct interaction with
Discloser. Alternatively, Collaborator may initially record
the Chained Agreement only with Disclosee. However,
Disclosee must retain records of all such Chained
Agreements, and must produce them upon demand from
Discloser. All Chained Agreements must be between
Collaborator and Discloser, not between Collaborator and
Disclosee, and must leave Discloser with direct legal remedy
vis-a-vis the Collaborator.
3
3 Sharing: The Disclosee may share the Disclosed Delta with
any party that is a dpv:LegalEntity in one of these
jurisdiction(s): _________________, referred to as a Third
Party, if and only if the Third Party enters into a copy of
this Agreement (hereafter "Chained Agreement"), with all of
its associated terms, conditions, and provisos, directly
with Discloser. Third Party may execute the Chained
Agreement in a direct interaction with Discloser.
Alternatively, Third Party may initially record the Chained
Agreement only with Disclosee. However, Disclosee must
retain records of all such Chained Agreements, and must
produce them upon demand from Discloser. All Chained
Agreements must be between Third Party and Discloser, not
between Collaborator and Disclosee, and must leave Discloser
with direct legal remedy vis-a-vis the Third Party.
N
N Sharing: Via this Agreement, the Discloser imposes no new
constraints on how Personal Information is shared. Data
sharing may still be governed by ambient regulation,
policies of the Disclosee, and choices negotiated between
the two parties elsewhere.
Possible Erasure Provisos

A given contract must contain exactly one of the following erasure provisos.

X
X Erasure: The process of erasing the Disclosed Delta from
Disclosee records is intended to begin as soon as the
Primary Use is accomplished. The Disclosee is required to
implement this erasure policy, with the following caveat. If
the regulatory context includes legal requirements about
data retention that conflict with the previous rule,
Disclosee must notify Discloser as soon as Disclosee is
aware of the conflict, must comply with the data retention
requirements, and must erase the data as soon after the
Primary use is accomplished as the those retention
requirements are satisfied.
T
T Erasure: The process of erasing Disclosed Delta from
Disclosee records is intended to begin within this time
interval after the Primary Use is accomplished:
__________________. If the Agreement includes REL Usage,
this countdown must begin from the time that Discloser last
took an affirmative action that proves they were deriving
concrete, demonstrable benefit from the relationship; the
Disclosee may not assume that the relationship is providing
value simply because the relationship exists. The intent is
to require erasure if the Discloser is passive and
essentially idle. The Disclosee is required to implement
this erasure policy, with the following caveat. If the
regulatory context includes legal requirements about data
retention that conflict with the preceding rules, Disclosee
must notify Discloser as soon as Disclosee is aware of the
conflict, must comply with the data retention requirements,
and must erase the data as soon after the time interval has
elapsed as those retention requirements are satisfied.
D
D Erasure: The process of erasing Disclosed Delta from
Disclosee records must begin upon demand by the Discloser,
with the following caveat. If the regulatory context
includes legal requirements about data retention that
conflict with the timing of the erasure demand, Disclosee
must notify Discloser as soon as Disclosee is aware of the
conflict, must comply with the data retention requirements,
and must erase the data as soon after the erasure demand as
those retention requirements are satisfied.
N
N Erasure: Via this Agreement, the Discloser imposes no new
constraints on how or when Personal Information is erased.
Data erasure may still be governed by ambient regulation,
policies of the Disclosee, and choices negotiated between
the two parties elsewhere.
Possible Correlation Provisos

The X, S, and P provisos are mutually exclusive. The A proviso can stand on its own or can be combined with X or S. If it is combined, it must follow the other proviso.

X
X Correlation: The Personal Information must not be
correlated with any other personal data about Discloser or
Disclosed that is now known or that will become known to the
Disclosee or to any third parties, unless that other data
was or will be disclosed for an overlapping Primary Use and
according to compatible sharing and erasure constraints, or
unless the additional "A Correlation" use is specifically
allowed below. The intent is that correlation only happens
to facilitate the specific shared purpose governed by this
Agreement. In all other contexts, the Disclosed and the
Discloser as revealed by the Personal Information remains
exactly as pseudonymous or as identified as they would be
without the Disclosure.
S
S Correlation: The Personal Information must not be
correlated with any other personal data about Discloser or
Disclosed that is now known or that will become known to the
Disclosee or to any third parties, unless that other data
was or will be disclosed according to compatible sharing,
correlation, and erasure constraints,  or unless the
additional "A Correlation" use is specifically allowed
below.
A
Correlation: Independent of any other constraints on the
usage of Personal Information, the Disclosure may be used to
facilitate a correlation by Disclosee or by another party
that correctly ties multiple pieces of data to the Discloser
or Disclosed (the Correlated Party), preventing the
Corelated Party from being erroneously counted more than
once in a large corpus. However, once the correlation has
accomplished this purpose, the data must be pseudonymized so
the temporarily correlated, now pseudonymized Correlated
Party cannot be easily correlated to additional external
data sets. Furthermore, the party that performs correlation
must agree not to de-pseudonymize the Correlated Party, and
must place all consumers of the aggregate data set under an
identical agreement, with the Correlated Party having legal
remedy directly with those who violate this constraint.
P
P Correlation: Via this Agreement, the Discloser imposes no
new constraints on how or when Personal Information is
correlated. The Discloser encourages correlation because the
intent is to build public reputation.

5. Agreement

This section finishes the contract. It clarifies what evidence constitutes proof that the Discloser and Disclosee have both agreed to be bound by the contract. It always begins like this:

The Discloser is deemed to accept the terms and conditions
set forth in this Agreement if they complete the Disclosure
process. They may prove that they are responsible for a
Disclosure under the terms of this Agreement by signing
(electronically, digitally, and/or cryptographically) the
Disclosure together with this Agreement.
Disclosee Commitment Options

The Disclosee also needs to be committed in a non-repudiable way. There are two options for this.

Contract of Adhesion

This option simply says that if the Disclosee uses the data, and cannot prove that they received it in any other way, they are deemed to have accepted the Agreement.

The Disclosee is deemed to accept the terms and conditions
set forth in this agreement if, after seeing the Agreement,
they give no overt signal to the Discloser that they have
rejected it, and if they then process the Disclosed Delta in
any way other than deleting it immediately.
Explicit Acceptance
The Disclosee accepts the terms and conditions set forth in
this Agreement, as witnessed by the associated signature
(electronic, digital, and/or cryptographic) over the
Agreement.

 

0
Read More

Latest draft of the No Stalking for Advertising Term V.2

UX and INTERFACE

Revised  DRAFT  of a singular, comprehensive term:

 
Draft Icon for inclusion in MVCR and other uses:

USER TERMS: Human language and {{ legal language }} below.

PREAMBLE:  The User submitted term shown here creates an opportunity for individuals to share their single term with entities about how they wish to be treated. This effort is meant to describe human, legal and machine readable versions of a comprehensive term along with additional information for agents who might implement this term for individuals as well as for entities who might see, accept or refuse the term.  {{ Information is defined as personal information provided by the individual about themselves. Data + Meaning = Information. The observer creates meaning (or observer is “informed by” the data), and then can be assigned duties. Information not collected from a person does not by definition constitute personal data. }}

TERMS AGREEMENT:  {{ Information can only be shared with those parties who first agree to abide by these terms.  Any sharing of information with a party that has not first agreed to these terms is a violation of these terms. }}

SHARE: describes the terms for sharing information with entities by individuals.

Choice: 2nd

1st-2nd Party:   My information shared and what I do will be kept between me and the entity.

{{Information shared by an individual (the “1st party”) and their activities are not permitted to be shared by the 2nd party with any other parties.}}

DURATION: describes the terms for retaining information by entities about individuals. {{ Add language referring to laws or contracts, defining 3rd party jurisdiction, to limit this from abuse. }}

QUESTION: should this be just for the session? or for as long as the person still has a relationship and agrees to sharing?

Choice: Session

Session:  My information shared or about what I do will only be kept for the session, unless required by law or contractual obligation.

{{ Information about an individual must be destroyed by the 2nd party immediately after the completion of the transaction for which it was collected or otherwise generated, unless otherwise required by law or contract obligation. }} [NOTE: What about records for audit?  What about hashed storage, e.g., in blockchain or other ledger system?]

OR ?

Choice: Infinity

Unlimited until further notice:  My information will be kept as long as I continue to choose this term, unless required by law or contractual obligation. If I change to another lesser term, my new term will be followed.

{{ Information about an individual can be retained indefinitely by the 2nd party, unless and until the 1st party notifies the 2nd party they have made an alternate selection for duration. }}

PURPOSE: describes the purpose for use of individual’s information provided or about actions they take

Choice: Site / App Use

Site and App UseMy information will be used for providing and / or enhancing the site or service, but not other purposes without my permission.

{{ Information about an individual may be used beyond the transaction for which it was collected or generated, but only with respect to the operation [or further development?] of the site or app over which such original transaction occurred and not for any other secondary uses by the 2nd party or other parties. }}

TRACKING

Choice: Tracking

Tracking: I will allow myself to be tracked by 3rd parties.

{{ Tracking of individual and their activities by any 3rd parties is authorized. }}

0
Read More

Latest Draft of Terms, V .7

This version of terms can also be found here at Kantara, Consent and Information Sharing Working Group, User Terms.

It is version .7 and includes a draft of human readable language after each term choice, followed by legal readable language in double brackets like this: {{ }}.

User Terms v. 7 Draft Icons

User Terms Draft 2 Icons

USER TERMS: Human language and {{ legal language }} below.
PREAMBLE: User submitted terms create an opportunity for individuals to share their own terms with entities about how they wish to be treated. This effort is meant to describe human, legal and machine readable versions of each possible term along with additional information for agents who might implement terms for individuals as well as for entities who might see, accept or refuse the terms. {{ Information is defined as personal information provided by the individual about themselves. Data + Meaning = Information. The observer creates meaning (or observer is “informed by” the data), and then can be assigned duties. Information not collected from a person does not by definition constitute personal data. }}
TERMS AGREEMENT: {{ Information can only be shared with those parties who first agree to abide by these terms. Any sharing of information with a party that has not first agreed to these terms is a violation of these terms. }}

SHARE: describes the terms for sharing information with entities by individuals.
Choice: 2nd

    1st-2nd Party: My information shared and what I do will be kept between me and the entity.
    {{Information shared by an individual (the “1st party”) and their activities are not permitted to be shared by the 2nd party with any other parties.}}

Choice: 3rd

    3rd Party: I will allow sharing of my information or information about what I do with 3rd parties I approve of.
    {{ Information about an individual and their activities can be shared by the 2nd party with mutually approved 3rd parties, including the public, subject to 1st Party’s purpose choices, including but not limited to advertising and data brokering. }}

DURATION: describes the terms for retaining information by entities about individuals. {{ Add language referring to laws or contracts, defining 3rd party jurisdiction, to limit this from abuse. }}
Choice: Session

    Session: My information shared or about what I do will only be kept for the session, unless required by law or contractual obligation.
    {{ Information about an individual must be destroyed by the 2nd party immediately after the completion of the transaction for which it was collected or otherwise generated, unless otherwise required by law or contract obligation. }} [NOTE: What about records for audit? What about hashed storage, e.g., in blockchain or other ledger system?]

Choice: 3

    3 months: My information will be kept for up to 90 days after I share it or take an action, unless required by law or contractual obligation.
    {{ Information about an individual must be destroyed on or before the date that is 90 days after its collection or other generation by the 2nd party, unless otherwise required by law or contract obligation. }}

Choice: Infinity

    Unlimited until further notice: My information will be kept as long as I continue to choose this term, unless required by law or contractual obligation. If I change to another lesser term, my new term will be followed.
    {{ Information about an individual can be retained indefinitely by the 2nd party, unless and until the 1st party notifies the 2nd party they have made an alternate selection for duration. }}

PURPOSE: describes the purpose for use of individual’s information provided or about actions they take
Choice: Transaction

    Transaction: My information will be used only for the purposes I share it for or implied from my actions taken on the site/app.
    {{ Information about an individual may be used only for the purpose of the transaction for which it was collected or generated. }}

Choice: Site / App Use

    Site and App Use: My information will be used for providing and / or enhancing the site or service, but not other purposes without my permission.
    {{ Information about an individual may be used beyond the transaction for which it was collected or generated, but only with respect to the operation [or further development?] of the site or app over which such original transaction occurred and not for any other secondary uses by the 2nd party or other parties. }}

Choice: Partner – 3rd use

    Partner and 3rd Party use: My information or activities may be used by 3rd parties I approve of, for purposes I approve of.
    {{ Partners: Subject to the limitations of the 1st party’s “sharing” preferences, information about an individual can be used for 3rd party purposes. }}

TRACKING
Choice: Tracking

    Tracking: I will allow myself to be tracked by 3rd parties.
    {{ Tracking of individual and their activities by any 3rd parties is authorized. }}

Choice: Do Not Track

    Do Not Track: I do not want to be tracked off the site or app by the 2nd party, or by any other parties on the site or app.
    {{ Tracking by 3rd parties is not authorized by individual. 2nd parties will not track activities by 1st party that occur on another service or site.
    NEED to add: definition of tracking that will describe exceeding authority by an unauthorized party. }}
0
Read More

Terms: What are They and Why Should You Care?

User Terms Draft 2 Icons

User Terms Draft 2 Icons

Terms are choices you make to ask that your data and activities be treated a certain way. Customer Commons is developing terms with Kantara and the Consent and Information Sharing Working Group so that we have a standardized set of terms, which can commonly be used through browsers, apps and other forms.

It is our intention that Terms will come in Human, Legal and Engineering forms so that people can read them, they can be legally binding, and apis and code will convey and negotiate your chosen terms. The idea isn’t that you would constantly be choosing these things, but rather have your agent take your choices and negotiate for you. We also envision being able to copy someone else’s terms you trust, if you don’t understand what these choices will mean for you.

Terms may also be created that fit with various contexts, like how to handle your health data, or what to do about data you share for a purchase, verses data you share for social activity. Those will come later after the initial set is developed. What you see in the picture above are draft icons. We intend to develop prettier versions with a designer, and work with engineers to develop sample or open source code for both choosing terms, as well as responding to those term requests from individuals.

If you are interested in helping with this project, you can join CISWG UX Kantara, by getting on the mail list, signing the IP agreement (so that all contributions can be used in the project) and getting on our calls.  We hope to see you there. Or comment here with questions!

0
Read More

April 6th Customer Commons and PDEC Salon

Join us for a joint PDEC and Customer Commons salon dinner April 6th, Monday night, 6-9pm in Mountain View. This is the night before IIW’s, and at the end of the VRM day, where we will have an opportunity to talk about Banking, Credit and Personal Data with LaVonne Reimer. Sign up at Eventbrite for the Salon Dinner.

About LaVonne: She is a lawyer-turned-entrepreneur with over 15 years experience deploying technologies in markets with data privacy and regulatory sensitivities. Most recently, she engaged an expert user community to streamline ethical data-sharing practices in the commercial credit ecosystem.

http://blog.lumeno.us/
https://www.linkedin.com/in/lavonnereimer
www.lumenous.net

Also, join us for VRM day here, on April 6, 9-5pm, Computer History Museum. Sign ups at Eventbrite.

For dinner, the PDEC / Customer Commons Salon, is 6-9pm at Fu Lam Mum in Mountain View.

NOTE:  Those who want to arrive earlier thank 6pm for socializing, please do, and we have a no host bar at Fu Lam Mum. For those coming at 6pm, we’ll start dinner about 6:30pm and for those just coming for discussion that will start about 7:30pm. However discussion people are welcome earlier for socializing too.

Sign up at Eventbrite for the Salon Dinner.

0
Read More

Thanks for Attending the Customer Commons Salon Last Night

Thanks to everyone who attended the Customer Commons Salon last night. It was a nice night to socialize, and talk.  Doc Searls gave us a quick report on Omie, the Customer Commons project that will be made for Android, and later we hope, other platrforms. Omie is meant to make the device yours, instead of having you captive to all those taking your data and experience.

We had a great night at MINGs in Palo Alto, and want to thank them for the delicious food and accommodations!

We look forward to our next salon, the Monday night before IIW, as always!

0
Read More

Join the Customer Commons’ Salon May 5, 2014 Ming’s Palo Alto

We are holding a salon dinner May 5, Monday night, 6-9pm in Palo Alto.  As we have, the night before the past 4 IIW’s, and at the end of the VRM day, we have an event for Customer Commons.

Join us for VRM day here, on May 5, 9-5pm, Computer History Museum. Sign ups at Eventbrite.

And for dinner, the Customer Commons Salon, 6-9pm at Ming’s in Palo Alto.

NOTE:  Those who want to arrive earlier for socializing, can do so, and we have a no host bar at Ming’s.  For those coming at 7pm, we’ll serve dinner after 7pm.

Sign up at Eventbrite for the Salon Dinner.

We’ll be discussing Omie, Customer Commons work, and we’d love to see you there.

0
Read More

Mozilla has a cute video on the open, privacy protecting web

Check it out here at The Web We Want: An Open Letter:

And the note Mozilla posted with the video:

Our right to a free and open Internets has been under threat lately. The NSA — btw, that stands for the National Security Agency, which has the fancy responsibility of analyzing and acting upon security data — has gotten into the habit of spying on Americans with no justification (including 12 spies who were using NSA tools to spy on their significant others). No, I’m not kidding.

The FCC — btw, that stands for the Federal Communications Commission, which is supposed to regulate and protect our communications channels — just made it easier for big companies to control the speed at which you are allowed to access particular websites. For example, your Internet company (i.e., Comcast or Verizon) could turn into a tiered pay system. So instead of being like a public utility where everyone gets the same amount of water or electricity, Verizon could give Netflix faster access for a fee, but then the smaller start-up that wants to compete and couldn’t afford it would get slower access.

The Internet has become one of the most important resources in our lives. It’s a shared resource that all of us take part in. Government spying on it and corporate interference in it are probably not things we want for the future. So Mozilla had some children voice concern for their own future. Because it’s important. What kind of web do you want?

0
Read More

Data Privacy Legal Hack-A-thon

Customer Commons is supporting, and board member, Mary Hodder, is hosting the Bay Area event. Additionally, there are NYC and London locations. Please join us if you are interested:

Data Privacy Legal Hackathon 2014

Data Privacy Legal Hackathon 2014

This is an unprecedented year documenting our loss of Privacy. Never before have we needed to stand up and team up to do something about it. In honour of Privacy Day, the Legal Hackers are leading the charge to do something about it, inspiring a two-day international Data Privacy Legal Hackathon. This is no ordinary event. Instead of talking about creating privacy tools in theory, the Data Privacy Legal Hackathon is about action! A call to action for tech & legal innovators who want to make a difference!

We are happy to announce a Data Privacy Legal Hackathon and invite the Kantara Community to get involved and participate. We are involved in not only hosting a Pre-Hackathon Project to create a Legal Map for consent laws across jurisdictions, but the CISWG will also be posting a project for the Consent Receipt Scenario that is posted in on the ISWG wiki.

The intention is to hack Open Notice with a Common Legal Map to create consent receipts that enable ‘customisers’ to control personal information If you would like to get involved in the hackathon, show your support, or help build the consent receipt infrastructure please get involved right away — you can get intouch with Mark (dot) Lizar (at)gmail (dot) com, Hodder (at) gmail (dot) com, or join the group pages that are in links below.

Across three locations on February 8th & 9th, 2014, get your Eventbrite Tickets Here:

* New York City * London, UK * San Francisco *

http://legalhackers.org/privacyhack2014/

This two-day event aims to mix the tech and legal scenes with people and companies that want to champion personal data privacy. Connecting entrepreneurs, developers, product makers, legal scholars, lawyers, and investors.

Each location will host a two-day “judged” hacking competition with a prize awarding finale, followed by an after-party to celebrate the event.

The Main Themes to The Hackathon Are:

  • Crossing the Pond Hack
  • Do Not Track Hack
  • Surveillance & Anti-Surveillance
  • Transparency Hacks
  • Privacy Policy Hack
  • Revenge Porn Hack

Prizes will be awarded:

  • 1st Prize:  $1,000
  • 2nd Prize:  $500
  • 3rd Prize: $250

There are pre-hackathon projects and activities. Join the Hackerleague to participate in these efforts and list your hack:

Sponsorship Is Available & Needed

Any organization or company seeking to show active support for data privacy and privacy technologies is invited to get involved.

  • Sponsor: prizes, food and event costs by becoming a Platinum, Gold or Silver Sponsor
  • Participate: at the event by leading or joining a hack project
  • Mentor: projects or topics that arise for teams, and share your expertise.

 

Contact NYC sponsorship: Phil Weiss email or @philwdjjd

Contact Bay Area sponsorship: Mary Hodder – Hodder (at) gmail (dot) com – Phone: 510 701 1975

Contact London sponsorship: Mark Lizar – Mark (dot) Lizar (at)gmail (dot) com – Phone: +44 02081237426 – @smarthart

0
Read More