You could do that. A group could establish a number of variations on policies based around a core. Each variation would be a list of changes on the core, and each would have a URL that listed the differences and rendered into a full-text agreement. The supplier would list such of the variations as they felt comfortable with. The user could choose. Or the process of matching could be automated. The critical difference between a CommonAccord approach and similar approaches is that you don't have to have full agreement to get benefit. It is not 4 varieties of Creative Commons, but 4 plus variations, and each branch renders into a full document. "Cheap branching." The "standard" text could also be tied into into regulations or a quasi-legislative process. http://www.commonaccord.org/index.php?action=list&file=Wx/gov/whitehouse/OMB/Legislative/Letters/cpbr-act-of-2015/ (This is not a real policy, it just shows the chain of text approach from regulation to charter to policy.) On Sat, Mar 12, 2016 at 8:18 PM, Adrian Gropper <agropper@healthurl.com> wrote:
+1 James
The baseline UMA model clauses should be for the case where RS==RSO, AS==ASO, and C==RqP. In each of these three cases, by definition of ==, there is no privacy notice for the RS, AS or C respectively. As you suggest, this would be the case where the RS is a door lock solenoid, the AS is a FreedomBox, and the C is an email client. In this baseline case, the only privacy notices and agreements would be: RSO-ASO, RqP-ASO, and RqP-RSO.
What I imagine is that the ACME RSO-RO sign-up agreement replaces the familiar:
- [ ] I accept the ACME Privacy Policy.
with
- [ ] I accept the ACME Automattics_3 Privacy Policy.
or
- [ ] I accept the ACME Automattics_3 Privacy Policy with these exceptions <http://www.commonaccord.org/index.php?action=source&file=Dx/Acme/03-Policies/03-Automatted-Privacy_v0.md> .
or even better,
- [ ] I accept the ACME Automatics_2 Privacy Policy via my authorization server at http://agropper.xyz/
In the last example, the RSO-RO agreement would no longer be a "notice" but actually be an agreement with technical agency for both the RSO and RO (as peers).
In the last example, the ACME RSO privacy notice and any exceptions would be presented to the RO in the context of their AS and make the registration process truly consumer-centered.
Adrian
On Sat, Mar 12, 2016 at 1:35 PM, James Hazard <james.g.hazard@gmail.com> wrote:
On the question of user/patient/owner/peer control, my sense is that peer control naturally flows from a real P2P system. The mission of CommonAccord - and a "Center for Collaborative Law" - is strictly limited to integrity of the text and the discussion, not to any particular outcome. But ....
In a P2P system, even large organizations and groupings are peers, and they will insist on control of their own identities. It is costless to extend that solution to smaller organizations and individuals. Coming from the other direction, the IoT requires a kind of sovereignty for each gadget. So each thing, including even "Individuals", will at least have the option to control their own client. As we now do with our email clients.
On Sat, Mar 12, 2016 at 7:04 PM, Adrian Gropper <agropper@healthurl.com> wrote:
I'm much more interested in how to make best use of CommonAccord with UMA than trying to boil the ocean of passive-aggressive privacy practices. We can use CommonAccord to pave the cow path of 20-page privacy notices and then try to link that to 200 model clauses in tangle of UMA relationships. Or, we can structure the use of CommonAccord at two separate levels: one that standardizes the baseline and is shared among all of the services and actors in a particular domain, and another that captures the deviations from that standard in the case of a specific RSO and a specific ASO.
The Automattics privacy policy is an example of a good candidate for the social media RSO policy standard. It should be relatively stable the way OSI or CC licenses are stable from year to year unless some really new tech or business model comes along. CommonAccord is of relatively limited value in managing a standard policy or license that's generic within the domain, stable, and not meant to be negotiated.
CommonAccord will then be incredibly valuable if it's applied (only) _to the exceptions_ from the standard and negotiated with the parties to an UMA relationship. That will result in much shorter output documents, sometimes with only a handful of lines. The UMA relationships would be much easier for all to understand in that case as well.
I love UMA because I take the user-managed access as an enabler of user-centered technology. Not everyone in our group sees user-mananged as user-centered and I understand that UMA needs to serve both. In the user-centered case, the UMA authorization server will be called upon to serve RSO domains as different as social media is from healthcare and from IoT. (Some clients can also be expected to serve people across domains). By applying CommonAccord to the exceptional aspects of the privacy notices of RSOs we have a prayer of actually making UMA agreements person-centric.
Adrian
On Sat, Mar 12, 2016 at 12:53 PM, James Hazard <james.g.hazard@gmail.com
wrote:
I think that you end up with at least as good a solution as Adrian wants, and the road incorporates work such as TosBack2. The point is to lay efforts end-to-end and to enable sources of "social" knowledge. That can happen by treating legal text like source code.
IF LAWYERS ARE AS CODERS - LET US GET GOOD AT IT - (tip of hat to Whole Earth Catalog)
The open source software community has shown how to iterate to first-class results on very complex matters expressed as text (software source code), without top-down. The conditions are:
1. Frequent, widespread, immediate need for _a_ text solution, however imperfect. In software that might be to print a document, serve a webpage, validate a user. In law it might be an NDA, Master Services Agreement or privacy policy. The immediate need drives the rest.
2. Modularity. So that we can separate idiosyncratic or confidential from general and repeating. Mix, match, improve.
3. A platform for collaboration. Um ... GitHub.
Privacy policies have similarities as well as differences. A good one would be helpful to others with similar needs. If there is a way to mix and match that maintains traceability, then the community can leverage efforts of Automattic, and everyone else. A simple approach is to break up the documents at their section and subsection breaks and parameterize the variables. You can chop finer as needed.
Here are a few more privacy policies available for mixing: http://privacy.commonaccord.org/index.php?action=list&file=/Com/
The privacy conversation between EU and US could be leveraged to play a critical role in driving P2P (see especially the pumpkin-colored part near the end):
http://www.commonaccord.org/index.php?action=doc&file=Dx/Acme_FR/11-EU-US-DataTransfer/Doc_v0.md
On Sat, Mar 12, 2016 at 6:19 PM, Andrew Hughes < andrewhughes3000@gmail.com> wrote:
You've missed my point.
The analysis and ontology work that went/is going into TosBack2 is the piece you might want to explore. You are looking for a simplified representation of policy - but until you examine the structure and conceptual meanings of the policies that will be simplified, there's a risk of missing important pieces.
Just a suggestion, rather than re-inventing and creating new uses for words...
*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*
o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *
On Sat, Mar 12, 2016 at 9:12 AM, Adrian Gropper < agropper@healthurl.com> wrote:
Yes. TOS Back has the same goal but is the exact opposite of what I'm proposing. It presumes that there's some value to the consumer for having 20-page privacy policies and terms of use that are heavily customized for every service we visit. We might call this the passive-aggressive approach to authoring and managing privacy notices. Just because we can create 20 page custom legal documents for an apartment lease or a privacy notice doesn't mean there's actual value to the consumer in doing so. A privacy notice is not the same as a piece of source code and should not need a Diff function run by experts to be understood. Privacy notices can be standardized.
We standardize software licenses and apartment leases for a reason. We do it to help typical people understand any unusual exceptions, good or bad, from what might be expected in the particular domain. The problem is that standards organizations are funded by commercial interests and making privacy notices easier to understand and to enforce is not likely a priority yet. As ad-blockers and GDPR begin to add real costs and benefits to privacy practices, we can expect to see a shift toward standardization.
Adrian
On Sat, Mar 12, 2016 at 11:44 AM, Andrew Hughes < andrewhughes3000@gmail.com> wrote:
> Not completely on topic, but Adrian: have you seen the ToSBack2 > project from ISOC? > > https://tid.isoc.org/confluence/display/TOSBACK2/ToSBack2+Home > > I have not plunged into the abyss of reading the documentation... > but I suspect that they have created a functional ontology for privacy > policies that enables the analysis engine to do cross-version comparison. > That might save some thinking work about how to slice and dice then > represent the policies... > > just a thought. > > andrew. > > *Andrew Hughes *CISM CISSP > Independent Consultant > *In Turn Information Management Consulting* > > o +1 650.209.7542 > m +1 250.888.9474 > 1249 Palmer Road, > Victoria, BC V8P 2H8 > AndrewHughes3000@gmail.com > ca.linkedin.com/pub/andrew-hughes/a/58/682/ > *Identity Management | IT Governance | Information Security * > > On Sat, Mar 12, 2016 at 4:42 AM, James Hazard < > james.g.hazard@gmail.com> wrote: > >> Running, but as a first cut: >> >> >> http://www.commonaccord.org/index.php?action=source&file=Dx/Acme/03-Policies/03-Automatted-Privacy_v0.md >> >> On Fri, Mar 11, 2016 at 10:29 PM, Adrian Gropper < >> agropper@healthurl.com> wrote: >> >>> Thanks, for sharing this. From my strictly consumer perspective, >>> here's what I would do with this: >>> >>> 1. Start a Standard Privacy Notice workgroup in Kantara with a >>> narrow charter to classify and label privacy notices. >>> 2. Make the Automattic Policy the first label and post it the >>> way we would a CC or OSI license. >>> 3. Publish a DRY Privacy Notice Best Practice that would >>> incorporate a labeled privacy notice BY REFERENCE and list only the >>> exceptions, if any to the referenced policy. >>> 4. Add CommonAccord to this as an option for describing only >>> the exceptions. >>> 5. Suggest standardized formatting for the exceptions right >>> down to the fonts and colors. >>> >>> My guess is that the world can get by with only 5 or so of these >>> baseline privacy notice labels to serve, for example: >>> >>> - blogs, (Automattic) >>> - merchants, (Vendor) >>> - things, (Robot) >>> - medical services, (HIPAA) >>> - directories (Dating) >>> >>> In addition, I would classify each privacy notice into one of >>> three classes depending on the kind of API they provide: >>> >>> Class 1: Service will not see your data. You are in sole control >>> of the API. >>> >>> Class 2: Service will see your data but the API you control has >>> all of the data available in reral-time. >>> >>> Class 3: Service will see your data but there's limited or no API >>> access. >>> >>> I've described these three classes in >>> http://thehealthcareblog.com/blog/2016/02/22/apple-and-the-3-kinds-of-privac... >>> >>> The result would be that Kantara privacy notices would look like: >>> Automattic_2 or HIPAA_3 and people would mostly pay attention only to the >>> exceptions. >>> >>> Adrian >>> >>> On Fri, Mar 11, 2016 at 12:31 PM, Eve Maler <eve@xmlgrrl.com> >>> wrote: >>> >>>> On today's call, I mentioned a cool privacy policy I ran across >>>> when I downloaded this app: >>>> >>>> http://buddhify.com/privacy-policy/ >>>> >>>> The app costs $4.99, and I carefully looked at the policy and >>>> decided I was very willing to pay money -- and they were making the >>>> tradeoff very worthwhile. They based the policy closely on this (both are >>>> CC-licensed -- hooray for DRY content!): >>>> >>>> https://automattic.com/privacy/ >>>> >>>> BTW, the app is awesome too. >>>> >>>> >>>> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: >>>> @xmlgrrl >>>> >>>> >>>> _______________________________________________ >>>> WG-UMA mailing list >>>> WG-UMA@kantarainitiative.org >>>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>>> >>>> >>> >>> >>> -- >>> >>> Adrian Gropper MD >>> >>> PROTECT YOUR FUTURE - RESTORE Health Privacy! >>> HELP us fight for the right to control personal health data. >>> DONATE: http://patientprivacyrights.org/donate-2/ >>> >>> _______________________________________________ >>> WG-UMA mailing list >>> WG-UMA@kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/wg-uma >>> >>> >> >> >> -- >> @commonaccord >> >> _______________________________________________ >> WG-UMA mailing list >> WG-UMA@kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/wg-uma >> >> >
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
-- @commonaccord
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
-- @commonaccord
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
-- @commonaccord