The openPDS software is one of the types of capabilities that will enable big data and personal data to travel on the same highways without crashing into each other.
Read all about it...
Read all about it...
3 plus ones
Shared publicly•View activity
- The press announcement above says, "Today, he says, "when you install an application, it tells you ‘this application has access to your fine-grained GPS location,’ or it ‘has access to your SD card.’ You as a user have absolutely no way of knowing what that means. The permissions don’t tell you anything.”" I agree, with a reservation.
One factor that does hold an app-maker's feet to the fire is public discussion and public opinion. If an app-maker is over-reaching and abusing data, then it runs the risk that a vigilante researcher (or whistle blower) will discover the infraction and publish it.
A vigilante researcher caused much grief for Carrier IQ; eventually Carrier IQ reformed its data practices. http://www.engadget.com/2012/05/09/carrier-iq-hires-former-verizon-privacy-counsel-magnolia-mobley/Jul 15, 2014
- Great point, Ben. To make your point more explicit, IF there are permissions granted then there is a basis upon which to determine whether a party is "over-reaching and abusing data" because one can refer to the permissions actually authorized and ask if the later conduct of the party is in the scope what the individual permitted... or not. The practices are now, with permissions, at least observable and hence, as you point out, a research/investigation can reveal major problems in some cases.
But what if those same permissions could be used to reverse the situation and not only as a starting basis for a potential long-shot that a vigilante researcher or whistle blower might discover, work on and find success shining light upon the situation? Let's face it, hoping for a vigilante researcher (or whistle blower) is not an especially reliable, effective or minimally adequate plan. The MIT Human Dynamics Lab has developed a way to use these same permissions to form a simple and small action intended to result in a solid and scalable solution to the problem.
Consider this: The "touch-point" between a person acting as an individual consumer and an app (ie the legal party behind the software such as a an app "developer" or a company that distributes an app to make it easier to do business with them, etc) sometimes provides MUCH more information about the precise nature and scope of permissions granted. When the permissions are made through the basic web-flow of OAuth 2 (which is the most common and perhaps nearly universal method) then we have, be design, created and preserved evidence of precisely the information needed for each of the three key parties in the scenario to demonstrate whether they were acting properly.
The three basic party types are 1) the individual (the person who, acting in their private personal capacity and not on behalf of a business or other entity, is using an app and granting permissions to that app), 2) the app provider (the party who is responsible for the app that has requested access to some otherwise unaccessible personal data or other protected resource of the individual) and 3) the protected resource host/provider (eg your calendar, your contacts, your geolocation, your travel itinerary, your photos, your financial information, your shared notes, etc). Let us call these the "Three Roles" of this "Scenario" and these are indeed the three typical roles involved.
Technically (but oversimplified for quick/easy ingestion) what is happening is use of OAuth 2 protocol enabling the user to grant permission to a third party app to do something with secure information (aka "protected resources") of the user. Example general permissions might be some type of authorization to access or read-only, or to add, modify and/or delete protected resource data or some other authorized function or flow.
Functions and workflow or approval chain type grants of authorization other than add/modify/delete might include permission to discover when the protected data is modified and to send an alert or it could be to enable an integrated transaction flow for any purchase above or below a defined amount of money, etc.
These are called "Scopes of Authorization" and every OAuth 2 enabled grant of permission by an individual user for an app to access and do something with a protected resource necessarily operates according to one or more of these "scopes".
If you are thinking (as a lawyer) "hey, isn't this important? what are these scopes again? how many are there? can i see some? how we we audit them and do reports to understand which scopes are being used by which users? how do we know whether the limitations or requirements enumerated in the scope are or are not being performed? how do these scopes of authorization relate to the terms and conditions of the contracts and licenses between the same parties? what is the place of these scopes of authorization in the basic definition of the roles and relationships of and among the parties (ie the individual and inter-party functions, expectations and duties including their applicable rights, responsibilities, requirements, recourse and remedies)?" ... these are good questions.
So... yes, i believe your insight that the permissions granted by people are a relevant point of intersection upon which much progress can be made is a great point and can be leveraged to reduce the "permissions don't tell you anything" blight and actually reverse the situation to enable the permissions to be the anchor-point that tell you precisely who all parties are with enumerated types of authorizations to the personal data and other protected resources of individuals.
This is available today with virtually no new technology or system or platform or services. Simply by configuring and integrating OAuth 2 existing widely (perhaps almost universally used) protocols this is achievable today.
Specifically, the IAuth approach demonstrates how to leverage the scopes of authorization by listing the permissions granted clearly and cross-linking scopes from and to the relevant provisions of contracts. This information provides a fuller picture of all the parties with access to a person's protected resources (private data) and can be presented directly on the account pages or "apps management" panels that web sites already provide for people to get a view of their current situation with the company (billing relationship, permissions, integrated apps, etc).
This means it is possible to have the basic business deal (the value proposition) and business transactions from the view of each party aligned, harmonized and literally integrated with the legal and technical dimensions of the roles and relationships of all the parties to this common scenario of web based commerce and transactional permission access to identity and protected data.
By use of this IAuth approach to existing technical and business methods it is possible to transform permissions confusion that create violations for privacy, consumer fraud and information security into new deal on data ensuring appropriate individual comprehension, consent and controls over their own identity and personal data.
Using the IAuth way to offer the globally used OAuth 2 based individual permissions, we can reverse the sad situation that "You as a user have absolutely no way of knowing what that means. The permissions don’t tell you anything."
More info at: http://ecitizen.mit.edu/iauth-project and the (somewhat stale now) blog: http://iauth.org/Jul 15, 2014