9 ms·

The thing which bothers me the most isn't the fine structure — steep fines for bad behaviour are fine (pun intended) — it's the so-called 'right to be forgotten

The thing which bothers me the most isn't the fine structure — steep fines for bad behaviour are fine (pun intended) — it's the so-called 'right to be forgotten.' It essentially makes simple immutable logs illegal. I'm still not certain how we're going to handle it. Encrypting each record with a per-identifier key works, but that makes doing anything with the data as a whole prohibitively expensive. And there's the whole question of what counts as identifying information. My understanding is that IP addresses do — so an immutable plaintext server log is now illegal. Privacy is really, really important. But expanding the definition of privacy too far is just too much.

snowball2 9y ago
Backups also...
mappu 9y ago
It's not clear how to implement 'right to be forgotten' inside backed-up data, too.
- geocar 9y ago
  It’s pretty easy: just don’t restore their data. Most businesses with personal data also have invoices. Since you don’t have to destroy those, simply note their request there. Other kinds of personal data like marketing leads and medical data should be much easier to see how to forget.
  - hamandcheese 9y ago
    That isn’t easy from a technical perspective. The whole point of a backup is to restore to a state from a previous point in time... now they want future state (the “right to be forgotten” request) to modify how a backup should be restored?
    - geocar 9y ago
      No. The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. If someone sends you something in the post telling you to delete their data, it should not be difficult to simply keep that record available when you need to restore an unrelated machines backup, unless you have incompetent IT. This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it. A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible.
      - hamandcheese 9y ago
        > The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. And to then restore to a point in time before the software or hardware bugs occurred, no? > A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible. Um what? There are ton of good reasons to stick to a single DB, it’s not unreasonable at all. The main one being that it massively simplifies ensuring data integrity compared to a distributed system. Also it’s just easier for a small team to manage.
        geocar 9y ago
        A single point of failure isn't a good way to protect people's personal data that you have, but even small teams are unlikely to have a single golden source of data. Data tends to flow from one system into another. For example: If someone sends you an email asking to be deleted, why would you store that email in the DB and nowhere else? Your team would read the email then update the database. After a crash, if you then restored a backup, why wouldn't you be able to review your last days email (since the last backup) for any updates? Of course you would. Even small teams could.
      - Silhouette 9y ago
        If someone sends you something in the post telling you to delete their data, it should not be difficult to simply keep that record available when you need to restore an unrelated machines backup, unless you have incompetent IT. "Who's IT?" -- Small and micro-businesses across Europe This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it. "We can't even afford a GDPR consultant. And who's IT?" -- Small and micro-businesses across Europe A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible. Again, this is simply detached from the reality of many, many small and microbusinesses, community organisations, non-profits, etc. It's absurd to think that every organisation that has reasonable need to handle personal data has a dedicated IT team, the people and budget to drop a few thousand on professional advice, the budget to buy extra equipment that isn't otherwise needed, etc. It's also absurd to think that without those things, an organisation can't take reasonable precautions to protect that data or prevent its exploitation for illegitimate purposes. Unfortunately the GDPR (as often happens with EU legislation) makes little allowance for any of this and thus imposes absurdly disproportionate overheads on smaller organisations.
- tyler_larson 9y ago
  Encrypt all person-specific data with the a key unique to that person, and if the person requests deletion, delete the key. This effectively deletes all backups.
  - mappu 9y ago
    Help me understand - that seems like it just centralizes the problem. Since the key is now PII-equivalent, how is the key storage backed up?
    - the_mitsuhiko 9y ago
      Revolving backups and you throw away old ones. After 30 days or so theast traces of a customer’s keys will be gone.
      - mappu 9y ago
        In that situation, the data is "inaccessible" but a data breach during the backup retention period will still leak their details. We can already achieve that result by removing records from the live DB and ignoring the whole backup situation. So what has this separate encryption process achieved?
        the_mitsuhiko 9y ago
        It has achieved that within a time frame PII of a user are removed from backups.
- the_mitsuhiko 9y ago
  How so? The solution is pretty straightforward: encryption with a per customer key that can be discarded.
  - Silhouette 9y ago
    For many businesses that won't be straightforward, it will be rocket science. Even if your business does have the understanding and technical ability to do it, it adds a whole extra layer of complexity and unreliability to what used to be simple, plain text logs -- exactly the kind of information you probably need to access quickly and reliably if you're in the middle of fixing a major fault, for example.
    - the_mitsuhiko 9y ago
      > Even if your business does have the understanding and technical ability to do it, it adds a whole extra layer of complexity and unreliability to what used to be simple, plain text logs -- exactly the kind of information you probably need to access quickly and reliably if you're in the middle of fixing a major fault, for example. But do you need to keep them forever? If you delete logs after 30 days you are unlikely to be impacted anyways.
      - Silhouette 9y ago
        We have server logs going back for years. Moreover, those older server logs have provided valuable information on several occasions for detecting abuse of our systems, attempted fraud, etc, so they are demonstrably useful for legitimate business purposes. We also have backups going back on a staged basis, more frequent backups from the recent past, less frequent going back further. This has been useful more than once for retrieving older information that someone had accidentally modified or deleted and not noticed immediately, so is also demonstrably useful for legitimate business purposes. Both of these appear to be at risk of conflict with the right to erasure under GDPR, in that for example old backups of emails will inevitably contain customer correspondence that can't readily be isolated.
huehehue 9y ago
I'm still trying to wrap my head around the GDPR myself, but I think (and would love evidence to the contrary if wrong) that IP addresses, certain device attributes, and the like are okay if they're required in order to ensure (or protect against threats to) "the availability, authenticity, integrity and confidentiality of stored or transmitted personal data". [0] I don't really know about relational data, where a true "delete" would destroy someone's database. Somebody told me that, if hard deletions aren't technically feasible, then soft-deleting (or marking as archived or whatever) is acceptable. Not too sure I believe them though -- simply replacing the sensitive data with garbage and keeping the relations seems like a better idea. [0] https://gdpr-info.eu/recitals/no-49/ https://gdpr-info.eu/recitals/no-49/
- deleted 9y ago
  [deleted]
- geocar 9y ago
  > Somebody told me that, if hard deletions aren't technically feasible, then soft-deleting (or marking as archived or whatever) is acceptable. Just also remember to record that you shouldn’t restore that persons data to the pre-forgotten state. The European courts haven’t weighed in, but they’re not unreasonable, and the UK has given specific guidance: https://ico.org.uk/media/for-organisations/documents/1475/deleting_personal_data.pdf https://ico.org.uk/media/for-organisations/documents/1475/de...
  - Silhouette 9y ago
    The UK guidance you mentioned there appears to apply to the DPA (the current legislation in this area) and not the GDPR (the new legislation with the stronger rights for deletion etc.).
    - geocar 9y ago
      In what way do you think the GDPR right to erasure is “stronger”?
scurvy 9y ago
Do IPv6 addresses count as identifiable? Because they really shouldn't if you understand how SLAAC works with privacy extensions (the default in almost every client stack).
- geocar 9y ago
  It ultimately depends on what you’re doing (and can do) with those IPv6 addresses. If you can identify someone then it probably is. That’s for example if you have a web form with their details filled in— just make sure they know you’re keeping their IPv6 address for the avoidance of doubt. If you can give it to someone like their ISP, and they can identify someone for you, then it might be: especially if you have a relationship with that ISP where you do that. If not, then probably not.
- detaro 9y ago
  Right now I always get the same IPv4 address, which uniquely identifies my traffic. After a switch to IPv6, I'll likely always get the same /64 or /56 subnet, that uniquely identifies my traffic. Randomizing some of the address doesn't help if another part of it is already enough to identify.
  - tscs37 9y ago
    Most people don't always get the same IPv4, they get a random one from the ISP, though it is still identifying. IIRC zeroing the last one or two groups of IPv4 and the /56 or /48 of the IPv6 address block should be fine. Alternatively you can use a short hash function (xxhash32 cut to 16bits for IPv4 or pure xxhash64) to effectively destroy most of the data but still get a good pseudo-identifier.
  - scurvy 9y ago
    It identifies your network segment, but not you as an individual. I guess if you lived alone that could only be you, but it would only identify your household in a family situation. One could make the argument either way.
Spearchucker 9y ago
Log files are easy (from a design perspective). Keep identifying information (IP, UID, DoB, etc) in one table, and activity data in another, with a join linking the two. When user asks to be forgotten, simply overwrite all the identifying information with generated data. Backups work the same way, but depending on where and how those are stored it could get expensive. We're seperating personally indentifying information out of our normal backups (held warm -> cold over time), and keeping PII backups offsite as warm data, so we can delete/ammend relatively pain-free. Yes. GDPR compliance will cost money and I'm not trivialising that. The degree of panic it's causing baffles me though. Sure, it requires design up front. Oh woe. But regulatory compliance always does. Ref. previous rending of hair and gnashing of teeth in the run-ups to Glass–Steagall, HIPAA, Sarbanes–Oxley, and so on.
- je42 9y ago
  i think we are allow to log the IP etc. as long as there is no link to another identifying key in the same log.
- TeMPOraL 9y ago
  > The degree of panic it's causing baffles me though. I think it's a combination of two things. On the one hand, people are justifiably worried whether or not their design and implementation of necessary changes will be fully correct. The cost of getting that wrong will be huge, and laws are generally not known for being clean and unambiguous. On the other hand, you also have people panicking because their user-hostile practices are no longer legal, and so they'll lose money.
  - Spearchucker 9y ago
    You're right, I think. If anyone worries about whether their design is correct or not it's because they've never treated PII with the respect it deserves. This is doubly so for entities engaging in user-hostile practices. And it's a sad state of affairs. ~12 years ago, in 2005, Kim Cameron first published his 7 laws of identity[1]. Follow those and you'll ace GDPR. Instead we've been directing the sharpest, brightest and smartest minds on the planet at squeezing revenue from advertising, consequences be damned. [1] https://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf https://www.identityblog.com/stories/2005/05/13/TheLawsOfIde...
rusk 9y ago
This is not right. The GDPR allows for reasonable usecases like this. The principles are pretty broad and only stifling once you get into the realm of sharing data between organisations [0] Such uses are "Appropriate", but you would be expected to maintain this information securely and you would not be allowed to use it for some other surreptitious purpose? This actually enables further innovations for instance you can log a cars behaviour without a user fearing you might sell this information on to their insurance company. What upsets people about GDPR is it does away with the notion of data being the holders property and enforces obligations to the subjects of that data. Of course in this day and age where "data is the new oil" this is upsetting for some. At the end of the day however this demonstrates how regulation, apart from propping up inneficiet markets also serves to protect the public from rampant commercialisation of every aspect of their lives! [0] https://united-kingdom.taylorwessing.com/globaldatahub/article-the-data-protection-principles-under-the-gdpr.html https://united-kingdom.taylorwessing.com/globaldatahub/artic...
- Silhouette 9y ago
  The GDPR allows for reasonable usecases like this. The principles are pretty broad and only stifling once you get into the realm of sharing data between organisations [0] The GDPR is rather ambiguous about use cases like this. That's part of the problem. Different national regulators are going to have to decide what they consider reasonable and how much they want to enforce. Unless and until they issue authoritative guidance, everyone is basically in the dark on what this really means, and the penalties for misjudgement could be severe if the regulator strongly disagreed with your interpretation. As for sharing data between organisations, one of the more unwise (IMHO) aspects of the GDPR is that when it comes to the right to erasure, the obligations to notify other parties to which the data has been supplied have guard conditions about reasonable efforts, but there are no such conditions at all on the immediate obligations to delete the data. If you're not covered by one of the acceptable cases (where the scope is, as noted above, not entirely clear yet) then you must be able to delete the data on demand, regardless of the practicality or cost of doing so.
  - rusk 9y ago
    Yes there’s lots of ambiguity and the details will be hammered out over the coming years. You will be subject to audit and noncompliances will be notified. Only the most egregious “bad faith” violators will suffer fines in the near term. I fully expect a couple of high profile cases will be made to get the ball rolling.
specialist 9y ago
Valid concern. Translucent Databases covers this. http://wayner.org/node/46 http://wayner.org/node/46 http://a.co/97iqrM5 http://a.co/97iqrM5 TL;DR: Various clever ways to encrypt records, organized for fast & easy retrieval, uncoverable if the key is lost (or deleted). Also: We should always encrypt all (demographic) data at rest.

snowball2 9y ago

Backups also...

mappu 9y ago

It's not clear how to implement 'right to be forgotten' inside backed-up data, too.

geocar 9y ago
It’s pretty easy: just don’t restore their data. Most businesses with personal data also have invoices. Since you don’t have to destroy those, simply note their request there. Other kinds of personal data like marketing leads and medical data should be much easier to see how to forget.
- hamandcheese 9y ago
  That isn’t easy from a technical perspective. The whole point of a backup is to restore to a state from a previous point in time... now they want future state (the “right to be forgotten” request) to modify how a backup should be restored?
  - geocar 9y ago
    No. The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. If someone sends you something in the post telling you to delete their data, it should not be difficult to simply keep that record available when you need to restore an unrelated machines backup, unless you have incompetent IT. This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it. A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible.
    - hamandcheese 9y ago
      > The whole point of backups is to protect against hardware failures and unforeseen software bugs/defects. And to then restore to a point in time before the software or hardware bugs occurred, no? > A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible. Um what? There are ton of good reasons to stick to a single DB, it’s not unreasonable at all. The main one being that it massively simplifies ensuring data integrity compared to a distributed system. Also it’s just easier for a small team to manage.
      - geocar 9y ago
        A single point of failure isn't a good way to protect people's personal data that you have, but even small teams are unlikely to have a single golden source of data. Data tends to flow from one system into another. For example: If someone sends you an email asking to be deleted, why would you store that email in the DB and nowhere else? Your team would read the email then update the database. After a crash, if you then restored a backup, why wouldn't you be able to review your last days email (since the last backup) for any updates? Of course you would. Even small teams could.
    - Silhouette 9y ago
      If someone sends you something in the post telling you to delete their data, it should not be difficult to simply keep that record available when you need to restore an unrelated machines backup, unless you have incompetent IT. "Who's IT?" -- Small and micro-businesses across Europe This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it. "We can't even afford a GDPR consultant. And who's IT?" -- Small and micro-businesses across Europe A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible. Again, this is simply detached from the reality of many, many small and microbusinesses, community organisations, non-profits, etc. It's absurd to think that every organisation that has reasonable need to handle personal data has a dedicated IT team, the people and budget to drop a few thousand on professional advice, the budget to buy extra equipment that isn't otherwise needed, etc. It's also absurd to think that without those things, an organisation can't take reasonable precautions to protect that data or prevent its exploitation for illegitimate purposes. Unfortunately the GDPR (as often happens with EU legislation) makes little allowance for any of this and thus imposes absurdly disproportionate overheads on smaller organisations.
tyler_larson 9y ago
Encrypt all person-specific data with the a key unique to that person, and if the person requests deletion, delete the key. This effectively deletes all backups.
- mappu 9y ago
  Help me understand - that seems like it just centralizes the problem. Since the key is now PII-equivalent, how is the key storage backed up?
  - the_mitsuhiko 9y ago
    Revolving backups and you throw away old ones. After 30 days or so theast traces of a customer’s keys will be gone.
    - mappu 9y ago
      In that situation, the data is "inaccessible" but a data breach during the backup retention period will still leak their details. We can already achieve that result by removing records from the live DB and ignoring the whole backup situation. So what has this separate encryption process achieved?
      - the_mitsuhiko 9y ago
        It has achieved that within a time frame PII of a user are removed from backups.
the_mitsuhiko 9y ago
How so? The solution is pretty straightforward: encryption with a per customer key that can be discarded.
- Silhouette 9y ago
  For many businesses that won't be straightforward, it will be rocket science. Even if your business does have the understanding and technical ability to do it, it adds a whole extra layer of complexity and unreliability to what used to be simple, plain text logs -- exactly the kind of information you probably need to access quickly and reliably if you're in the middle of fixing a major fault, for example.
  - the_mitsuhiko 9y ago
    > Even if your business does have the understanding and technical ability to do it, it adds a whole extra layer of complexity and unreliability to what used to be simple, plain text logs -- exactly the kind of information you probably need to access quickly and reliably if you're in the middle of fixing a major fault, for example. But do you need to keep them forever? If you delete logs after 30 days you are unlikely to be impacted anyways.
    - Silhouette 9y ago
      We have server logs going back for years. Moreover, those older server logs have provided valuable information on several occasions for detecting abuse of our systems, attempted fraud, etc, so they are demonstrably useful for legitimate business purposes. We also have backups going back on a staged basis, more frequent backups from the recent past, less frequent going back further. This has been useful more than once for retrieving older information that someone had accidentally modified or deleted and not noticed immediately, so is also demonstrably useful for legitimate business purposes. Both of these appear to be at risk of conflict with the right to erasure under GDPR, in that for example old backups of emails will inevitably contain customer correspondence that can't readily be isolated.

huehehue 9y ago

I'm still trying to wrap my head around the GDPR myself, but I think (and would love evidence to the contrary if wrong) that IP addresses, certain device attributes, and the like are okay if they're required in order to ensure (or protect against threats to) "the availability, authenticity, integrity and confidentiality of stored or transmitted personal data". [0] I don't really know about relational data, where a true "delete" would destroy someone's database. Somebody told me that, if hard deletions aren't technically feasible, then soft-deleting (or marking as archived or whatever) is acceptable. Not too sure I believe them though -- simply replacing the sensitive data with garbage and keeping the relations seems like a better idea. [0] https://gdpr-info.eu/recitals/no-49/ https://gdpr-info.eu/recitals/no-49/

deleted 9y ago
[deleted]
geocar 9y ago
> Somebody told me that, if hard deletions aren't technically feasible, then soft-deleting (or marking as archived or whatever) is acceptable. Just also remember to record that you shouldn’t restore that persons data to the pre-forgotten state. The European courts haven’t weighed in, but they’re not unreasonable, and the UK has given specific guidance: https://ico.org.uk/media/for-organisations/documents/1475/deleting_personal_data.pdf https://ico.org.uk/media/for-organisations/documents/1475/de...
- Silhouette 9y ago
  The UK guidance you mentioned there appears to apply to the DPA (the current legislation in this area) and not the GDPR (the new legislation with the stronger rights for deletion etc.).
  - geocar 9y ago
    In what way do you think the GDPR right to erasure is “stronger”?

scurvy 9y ago

Do IPv6 addresses count as identifiable? Because they really shouldn't if you understand how SLAAC works with privacy extensions (the default in almost every client stack).

geocar 9y ago
It ultimately depends on what you’re doing (and can do) with those IPv6 addresses. If you can identify someone then it probably is. That’s for example if you have a web form with their details filled in— just make sure they know you’re keeping their IPv6 address for the avoidance of doubt. If you can give it to someone like their ISP, and they can identify someone for you, then it might be: especially if you have a relationship with that ISP where you do that. If not, then probably not.
detaro 9y ago
Right now I always get the same IPv4 address, which uniquely identifies my traffic. After a switch to IPv6, I'll likely always get the same /64 or /56 subnet, that uniquely identifies my traffic. Randomizing some of the address doesn't help if another part of it is already enough to identify.
- tscs37 9y ago
  Most people don't always get the same IPv4, they get a random one from the ISP, though it is still identifying. IIRC zeroing the last one or two groups of IPv4 and the /56 or /48 of the IPv6 address block should be fine. Alternatively you can use a short hash function (xxhash32 cut to 16bits for IPv4 or pure xxhash64) to effectively destroy most of the data but still get a good pseudo-identifier.
- scurvy 9y ago
  It identifies your network segment, but not you as an individual. I guess if you lived alone that could only be you, but it would only identify your household in a family situation. One could make the argument either way.

Spearchucker 9y ago

Log files are easy (from a design perspective). Keep identifying information (IP, UID, DoB, etc) in one table, and activity data in another, with a join linking the two. When user asks to be forgotten, simply overwrite all the identifying information with generated data. Backups work the same way, but depending on where and how those are stored it could get expensive. We're seperating personally indentifying information out of our normal backups (held warm -> cold over time), and keeping PII backups offsite as warm data, so we can delete/ammend relatively pain-free. Yes. GDPR compliance will cost money and I'm not trivialising that. The degree of panic it's causing baffles me though. Sure, it requires design up front. Oh woe. But regulatory compliance always does. Ref. previous rending of hair and gnashing of teeth in the run-ups to Glass–Steagall, HIPAA, Sarbanes–Oxley, and so on.

je42 9y ago
i think we are allow to log the IP etc. as long as there is no link to another identifying key in the same log.
TeMPOraL 9y ago
> The degree of panic it's causing baffles me though. I think it's a combination of two things. On the one hand, people are justifiably worried whether or not their design and implementation of necessary changes will be fully correct. The cost of getting that wrong will be huge, and laws are generally not known for being clean and unambiguous. On the other hand, you also have people panicking because their user-hostile practices are no longer legal, and so they'll lose money.
- Spearchucker 9y ago
  You're right, I think. If anyone worries about whether their design is correct or not it's because they've never treated PII with the respect it deserves. This is doubly so for entities engaging in user-hostile practices. And it's a sad state of affairs. ~12 years ago, in 2005, Kim Cameron first published his 7 laws of identity[1]. Follow those and you'll ace GDPR. Instead we've been directing the sharpest, brightest and smartest minds on the planet at squeezing revenue from advertising, consequences be damned. [1] https://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf https://www.identityblog.com/stories/2005/05/13/TheLawsOfIde...

rusk 9y ago

This is not right. The GDPR allows for reasonable usecases like this. The principles are pretty broad and only stifling once you get into the realm of sharing data between organisations [0] Such uses are "Appropriate", but you would be expected to maintain this information securely and you would not be allowed to use it for some other surreptitious purpose? This actually enables further innovations for instance you can log a cars behaviour without a user fearing you might sell this information on to their insurance company. What upsets people about GDPR is it does away with the notion of data being the holders property and enforces obligations to the subjects of that data. Of course in this day and age where "data is the new oil" this is upsetting for some. At the end of the day however this demonstrates how regulation, apart from propping up inneficiet markets also serves to protect the public from rampant commercialisation of every aspect of their lives! [0] https://united-kingdom.taylorwessing.com/globaldatahub/article-the-data-protection-principles-under-the-gdpr.html https://united-kingdom.taylorwessing.com/globaldatahub/artic...

Silhouette 9y ago
The GDPR allows for reasonable usecases like this. The principles are pretty broad and only stifling once you get into the realm of sharing data between organisations [0] The GDPR is rather ambiguous about use cases like this. That's part of the problem. Different national regulators are going to have to decide what they consider reasonable and how much they want to enforce. Unless and until they issue authoritative guidance, everyone is basically in the dark on what this really means, and the penalties for misjudgement could be severe if the regulator strongly disagreed with your interpretation. As for sharing data between organisations, one of the more unwise (IMHO) aspects of the GDPR is that when it comes to the right to erasure, the obligations to notify other parties to which the data has been supplied have guard conditions about reasonable efforts, but there are no such conditions at all on the immediate obligations to delete the data. If you're not covered by one of the acceptable cases (where the scope is, as noted above, not entirely clear yet) then you must be able to delete the data on demand, regardless of the practicality or cost of doing so.
- rusk 9y ago
  Yes there’s lots of ambiguity and the details will be hammered out over the coming years. You will be subject to audit and noncompliances will be notified. Only the most egregious “bad faith” violators will suffer fines in the near term. I fully expect a couple of high profile cases will be made to get the ball rolling.

specialist 9y ago

Valid concern. Translucent Databases covers this. http://wayner.org/node/46 http://wayner.org/node/46 http://a.co/97iqrM5 http://a.co/97iqrM5 TL;DR: Various clever ways to encrypt records, organized for fast & easy retrieval, uncoverable if the key is lost (or deleted). Also: We should always encrypt all (demographic) data at rest.