In the past week, OpenPD has made several more important steps to its initial release, and there has been lots of discussion about the internals of the configuration system. You can read an online version of this email here.
Progressive Hack Night. Last week, OpenPD was invited to Progressive Hack Night to run a ‘breakout’ working group for development and discussion of the project. If I remember correctly, nearly ten people spent their entire time at Progressive Hack Night in the OpenPD working group, and dozens others stopped by. To those of you who were in the group: thank you for your contributions.
Persistence codes. The most significant development since the last update is the creation of persistence codes. Persistence codes allow the service to specify how long they keep data, and also allow for different use codes to apply throughout time. Using persistence codes, an e-commerce service can specify that they share your shipping address with outside entities until your shipment completes, and then keep the data only internally. Persistence codes are relative to when the data is collected. A draft of the persistence codes legal copy is present in OpenPD v0.0.2.
Collection codes. There are now 47 preliminary collection codes. A primary focus of the working group at Progressive Hack Night was to develop more granular biometric collection codes, which are now reflected in the most recent version of the document.
Modifications to the right to erasure. As of OpenPD v0.0.2, the ‘right to erasure’ can be nullified by the ‘undeleteable’ use code. If a collection code is labeled undeleteable, the data subject may not request that the data be deleted. This is to allow more flexible OpenPD configurations. (If you’re a newspaper and you only allot non-subscribers ten online articles per month, you don’t want to allow them to reset their quotas! In this situation, the newspaper could apply a 1-month ‘undeleteable’ use-code to whatever collection codes they use to identify readers.)
Immediate versus non-immediate information. The distinction between immediate and non-immediate information has important consequences for OpenPD. OpenPD generally assumes that any data a service has about a data subject is collected from that data subject. When this is true, the data is called immediate information. A form that a user fills out on a website, for example, is an example of immediate information. Non-immediate information is information collected about a data subject from a third-party source.
OpenPD applies to all information a service collects that is related to a data subject, regardless of whether the data itself was collected directly from the data subject. That being said, the idea of immediate versus non-immediate information affects OpenPD in two ways:
- Because non-immediate information can be collected without the knowledge of the data subject, the data subject may not know that they are afforded the right of erasure. The data subject has a ‘right to know’ what data the service has about them. (This ‘right to know’ will be present in OpenPD v0.0.3, and presents a partial solution to this issue. It will allow data subjects to request and receive all data that a service has that relates to them.)
- When it comes to non-immediate information, it is often unclear who the data subject is. (Imagine, for example, information tied to a particular address. Perhaps an apartment building. Who is the data subject? It’s often ambiguous.) In other cases, a single piece of data may relate to multiple data subjects: a group photo is a prime example. If one data subject wants the data removed and another does not, what does the service do? OpenPD makes the assumption that data is tied to a single data subject, and while this is usually true, there are edge cases that must be considered.
All that aside, there is precedent here. The German data protection law Bundesdatenschutzgesetz perhaps puts the of immediacy versus non-immediacy most plainly:
Principle of Immediacy: The personal data must be collected directly from the person concerned.
If only data was that simple and clear. (To be fair, the above text is not the law itself, nor is it a translation; that is from a summary on Wikipedia.)
Disclaimer. As usual, the contents of this message is not legal advice and I am not a lawyer. See a more verbose version of this disclaimer on all OpenPD websites.
Anyway, feel free to reply to this email with comments and feedback. OpenPD is moving along!