Consider changing AccessNeed and related concepts with Purpose

[coolharsh55]

Hi. I realise this is a big ask and its probably quite late given the implementation progress, but IMHO this is an important consideration.

The term AccessNeed, describe through AccessNeedDescription, as "specific explanation of why that data type is being requested" should be replaced with Purpose for the following reasons:

1. AccessNeed is non-normative, does not align with legal or social terminology, and is not expressive enough to represent what it is intended to exhibit (more on this part later).
2. Purpose is normative, well defined and understood both legally and socially, and is IMHO more intuitive for everybody.
3. Access only refers to one form of action or processing over data i.e. to access, which can be stretched in definition to mean at most 'use'. It does not represent other possible actions and their nuances and differences, such as collect, use, aggregate, obtain (from elsewhere), share, retain, store (on pod), store (outside pod), erase. For any of these actions, the intended term should be a description of the 'purpose' explaining why they are being performed. For example, "I want to do X with your Y" is a description of action X over data Y, but does not explain its purpose, which can be to "provide you the Projectron service".
4. Need is typically interpreted to refer to the necessity - most commonly as an obligation. For exampe, I need water vs I want water have two subtle but important nuances - and even if we might not care about them in daily langauge, they have important considerations in semantics and law, where the interpretation may not mean the same thing as we want to. Purpose presents a better abstraction of explaining the purpose of needs and wants over some data.
5. Necessity may be associated with more than Access - for example, some data may be optional (e.g. name is optional while providing email), or some action may be optional (e.g. storing a copy on your pod for generated analytics), or some purpose may be optional (e.g. we can optionally use the location data to personalise your language interface).
6. Access related terms such as Grant and Receipt can be misinterpreted (whether intentional or unintentionally) as only referring to 'access' or 'use' as it relates to the first action. For example, a Company F 'needs' to 'access' the data to provide a service X. After the provision of that service X, it wants to perform some profiling using the data collected, but doesn't tell you because it does not need to 'access' that data from the pod - it already has it. The term Purpose does not have any scope for such shenanigans.
7. Purpose is well known and allows taking advantage of legal obligations such as what consitutes a valid 'purpose' as well as requiring separate permissions for separate purposes, which creates legal certainty in how to interpret use of data by apps and avoids any ambiguity associated with terminology. For example, GDPR uses Purpose predominantly, and so do all other laws around the world, including the recently proposed federal American Data Privacy and Protection Act.

[justinwb]

@coolharsh55 Thanks for raising - it's definitely not too late to consider this - and you make some great points. We'll discuss this issue at one of the upcoming panel meetings.

[coolharsh55]

Hi. Thanks for the acknowledgement. I'll keep an eye on the agenda for meetings. In case I miss it, please share the date, and I will try to attend as well in case I can help answer any queries.

[elf-pavlik]

I added it to tomorrow's agenda ☝️

EDIT: This conversation in AuthZ panel might also be relevant:

• Distinction between policies which can be enforced by technology and by law authorization-panel#286

[elf-pavlik]

We discussed specifying a couple of use cases

• User has service run in their browser, no data is sent outside of the device (easiest one)
• Service collects some data and does something with it (maybe deletes it later)
• Service collects data and maybe sends it to some 3rd party

Notes from meeting:

• @elf-pavlik: the last on in contrast to Support longer delegation chains #222
• @coolharsh55: https://harshp.com/research/publications/057-Making-sense-of-Solid#sec:existing-issues

[CxRes]

While creating the use cases, try to use concrete examples, such as the case of restaurant app asking for allergy information (as discussed in the meeting):

• Client App downloads the menu from restaurant's pod and uses allergy information from users' pod to customize menu (data does not leave client's device).
• Client App sends the allergy information to the restaurant, restaurant commits to delete information post-order/visit.
• Restaurant persists the information, so that it might, say, customize their menu in the future.
• Restaurant passes on the information to a researcher in an anonymized form.
• Restaurant sells aggregated information to a third party in an anonymized form.
• Restaurant sells your data to a third party.

[woutermont]

While my initial reaction was in favour of this idea, I think an Access Need conveys other information than a purpose: it is the WHAT of access, while the purpose is the WHY.

That does not mean that a Purpose cannot be included in the Access Need, of course.

[coolharsh55]

Hi. Apologies for the severely delayed use-cases. I have also included additional material (which resulted in a rather long post) about the implications of having or not having informaation, and comparing use of Solid Pods and apps with other app stores (Apple/Google).

Use-Cases

1. Data processed in 'private sphere'
   • source: local, external; processing: local; recipients: none
   • an app reads data from the Pod and processes it to produce new data locally within the browser (or user server)
   • the app then proceeds to write this data back to the Pod, possibly appending exisitng data (e.g. update fitness runs) or modifying it (e.g. update summary of weekly running)
   • here, the data may also 'arrive' from external sources, e.g. the fitness tracker, or the servers of the app.
2. Data processed in 'limited external sphere'
   • source: local, external; processing: external; recipients: app
   • an app reads data from the Pod, transfers it to the app's servers, and processes it there e.g. to update fitness logs / summaries
   • it may return the generated data (e.g. summary) back to the Pod; but it does not send this data anywhere else
   • the data may not even be sourced from the Pod, e.g. fitness tracker logs are directly uploaded to the app server and the generated data is sent back to the Pod
3. Data processed in 'unbound external sphere'
   • source: local, external; processing: external; recipients: any
   • same situation as above (no.2) but where there are no restrictions on where the data ends up - the app can take the data from the Pod and send it to its server and from there it can be sent to any third party

Perspectives on role of Solid

1. Solid as a 'storage device' - here the role of a Pod is only as a storage device, therefore the permissions associated with the data only cover whether the data can be read, written, modified, etc. and by whom. It does not care about the purpose of operations. E.g. an app's request will only cover what data needs to be read, and the identity of the agent.
2. Solid as a 'user device' - here Solid acts as a device controlled by the user, where the permissions cover not only the data but also may have connections to any tool/services associated with the device. E.g. an app's request covers what data is needed, and why (e.g. to provide a service), but no other information is covered in the Pod request. If there are implications of this request, such as what else the app will do with the data or if it will keep it or not - these are covered external to the Pod e.g. in the app itself where the user has another request/agreement.
3. Solid as a 'user agent' - here Solid is an agent of the user which means it has the ability to affect changes outside the Pod. The request to the user therefore has to be fully justified in terms of why the data is needed, what will happen with it, and respond to user actions such as 'terminate agreement', 'withdraw consent', 'request copy of data' - directly from the Pod.

Issues with Lack of Information

• if the user's only interaction with an app/service is through the Pod, then merely stating what data is to be accessed is not sufficient since that is not enough information to understand what is going to happen with the data. In addition to the 'purpose', there are also considerations based on where the data will be stored, for how long, on what basis, and if someone else is going to have access to the data. Role.3 from above becomes important for this. Keeping records of this information is also important as otherwise the user has no ability to access this information.
• if the user is interacting with an app/service elsewhere, and then only using the Pod as a controlled storage (Role.1 and Role.2), then the user already has made a decision in that external context to agree with what the app/service is doing. However, it is well known that currently such interactions are abusive and exploitative - and end up with the user agreeing to everything. Translating this to the Pod would mean the app has access to all data to do whatever it pleases. To avoid this, either the external context has to be replicated in the request so that the Pod request can be compared to and ensured to match the external decsion made by the user; OR the request has to be repeated in the Pod separately i.e. the app has to explain again why it wants the data and for what reasons - except this time in the format the Pod wants which prevents known issues.

Additional considerations

• All the above perspectives were regarding 'consumer protection'. Structured information describing the app's use of data also assists the app developers since it avoids the challenge of how to provide this information, complying with legal information requirements, managing updates, etc. - which can now be utilised through automation and tools based on the structured representations
• Existing mechanisms such as app stores already have structured metadata which must be present (e.g. manifest) but are increasingly also enforcing additional guidelines to declare information specifically related to privacy e.g. Apple and Google have "privacy labels" as a summary of information categorised used by an app and its purpose (e.g. tracking, identifying). Apple has also recently asked developers to explicitly denote the purpose for APIs it deems "sensitive" based on their perceived impacts.
• At a minimum, a Solid Pod should offer the same level of care and protection as these mechanisms, namely by asking for structured metadata explaining what the app is doing, so that the user is better informed and protected.