The recent hack of Ashley Madison, and the subsequent discussion, reminded me of something Iâve been meaning to talk about for some time.
This is usually expressed, as my title suggests, by a user asking the web site who hosted that userâs account (and usually directly as a result of a data breach) why that web site still had the userâs data.
This can be because the user deliberately deleted their account, or simply because they havenât used the service in a long time, and only remembered that they did by virtue of a breach notification letter (or a web site such as Troy Huntâs haveibeenpwned.com).
Web sites do not see it as a good idea to have a âdeleteâ feature for their user accounts â after all, what youâre asking is for a site to devote developer resources to a feature that specifically curtails the ability of that web site to continue to make money from the user.
To an accountantâs eye (or a shareholderâs), thatâs money out the door with the prospect of reducing money coming in.
To a userâs eye, itâs a matter of security and trust. If the developer deliberately misses a known part of the userâs lifecycle (sunset and deprecation are both terms developers should be familiar with), itâs fairly clear that there are other things likely to be missing or skimped on. If a site allows users to disconnect themselves, to close their accounts, thereâs a paradox that says more users will choose to continue their service, because they donât feel trapped.
So, letâs assume there is a âdeleteâ or âclose my accountâ feature â and that itâs easy to use and functional.
In the aftermath of the Ashley Madison hack, Iâm sure thereâs going to be a few partners who are going to engage in retributive behaviours. Those behaviours could include connecting to any accounts that the partners have shared, and cause them to be closed, deleted and destroyed as much as possible. Itâs the digital equivalent of cutting the sleeves off the cheating partnerâs suit jackets. Probably.
Assuming youâve finally settled down and broken/made up, youâll want those accounts back under your control.
So there might need to be a feature to allow for âremorseâ over the deletion of an account. Maybe not for the jealous partner reason, even, but perhaps just because you forgot about a service you were making use of by that account, and which you want to resurrect.
OK, so many sites have a âresurrectâ function, or a âcool-downâ period before actually terminating an account.
Facebook, for instance, will not delete your account until youâve been inactive for 30 days.
Letâs say youâre a terrorist. Or a violent criminal, or a drug baron, or simply someone who needs to be sued for slanderous / libelous statements made online.
OK, in this case, you donât WANT the server to keep your history â but to satisfy warrants of this sort, a lawyer is likely to tell the serverâs operators that they have to keep history for a specific period of time before discarding them. This allows for court orders and the like to be executed against the server to enforce the rule of law.
So your server probably has to hold onto that data for more than the 30 day inactive period. Local laws are going to put some kind of statute on how long a service provider has to hold onto your data.
As an example, a retention notice served under the UKâs rather steep RIPA law could say the service provider has to hold on to some types of data for as much as 12 months after the data is created.
If youâve paid for the service being provided, those transaction details have to be held for possible accounting audits for the next several years (in the US, between 3 and 7 years, depending on the nature of the business, last time I checked).
Obviously, youâre not going to expect an audit to go into complete investigations of all your individual service requests â unless youâre billed to that level. Still, this record is going to consist of personal details of every user in the system, amounts paid, service levels given, a la carte services charged for, and some kind of demonstration that service was indeed provided.
So, even if Ashley Madison, or whoever, provided a âfull deleteâ service, thereâs a record that they have to keep somewhere that says you paid them for a service at some time in the past.
I donât think eternal data retention is appropriate or desirable. Itâs important for developers to know data retention periods ahead of time, and to build them into the tools and services they provide.
Hackers fetch data from online services. Offline services â truly offline services â are fundamentally impossible to steal over the network. An attacker would have to find the facility where theyâre stored, or the truck the tapes/drives are traveling in, and steal the data physically.
Not that thatâs impossible, but itâs a different proposition from guessing someoneâs password and logging into their servers to steal data.
Once data is no longer required for online use, and can be stored, move it into a queue for offline archiving. Developers should make sure their archivist has a data destruction policy in place as well, to get rid of data thatâs just too old to be of use. Occasionally (once a year, perhaps), they should practice a data recovery, just to make sure that they can do so when the auditors turn up. But they should also make sure that they have safeguards in place to prevent/limit illicit viewing / use of personal data while checking these backups.
Different classifications of data have different retention periods, something I alluded to above. Financial records are at the top end with seven years or so, and the minutiae of day-to-day conversations can probably be deleted remarkably quickly. Some services actually hype that as a value of the service itself, promising the messages will vanish in a snap, or like a ghost.
When developing a service, you should consider how youâre going to classify data so that you know what to keep and what to delete, and under what circumstances. You may need a lawyer to help with that.
If you lay the frameworks in place when developing a service, so that data is classified and has a documented lifecycle, your service naturally becomes more loosely coupled. This makes it smoother to implement, easier to change, and more compartmentalised. This helps speed future development.
Users who know they can quit are more likely to remain loyal (Apple aside). If a user feels hemmed in and locked in place, all thatâs required is for someone to offer them a reason to change, and theyâll do so. Often your own staff will provide the reason to change, because if youâre working hard to keep customers by locking them in, it demonstrates that you donât feel like your customers like your service enough to stay on their own.
Yeah, I know, âto whom you give dataâ, thanks, grammar pedants.
Remember some basic rules here:
Yeah, and Richard Stallmannâs windows want to be broken.
Data doesnât want anything, but the appearance is that it does, because when data is disseminated, it essentially cannot be returned. Just like if you go to RMSâs house and break all his windows, you canât then put the glass fragments back into the frames.
Developers want to possess and collect data â itâs an innate passion, it seems. So if you give data to a developer (or the developerâs proxy, any application theyâve developed), you canât actually get it back â in the sense that you canât tell if the developer no longer has it.
Occasionally developers will collect and keep data that they know they shouldnât. Sometimes theyâll go and see which famous celebrities used their service recently, or their ex-partners, or their âfriendsâ and acquaintances.
EU data protection laws start from the basic assumption that factual data describing a person is essentially the non-transferrable property of the person it describes. It can be held for that person by a data custodian, a business with whom the person has a business relationship, or which has a legal right or requirement to that data. But because the data belongs to the person, that person can ask what data is held about them, and can insist on corrections to factual mistakes.
The US, and many other countries, start from the premise that whoever has collected data about a person actually owns that data, or at least that copy of the data. As a result, thereâs less emphasis on openness about what data is held about you, and less access to information about yourself.
Ideally, when the revolution comes and we have a socialist government (or something in that direction), the US will pick up this idea and make it clear that service providers are providing a service and acting only as a custodian of data about their customers.
Until then, remember that US citizens have no right to discover whoâs holding their data, how wrong it might be, or to ask for it to be corrected.
Developers should also think about this â you canât leak data you donât hold. Similarly, if a user doesnât give data, or gives incorrect or value-less data, if it leaks, that data is fundamentally worthless.
The fallout from the Ashley Madison leak is probably reduced significantly by the number of pseudonyms and fake names in use. Probably.
Hey, if you used your real name on a cheating web site, thatâs hardly smart. But then, as I said earlier today, sometimes security is about protecting bad people from bad things happening to them.
You might use the same nickname at several places; you might provide information thatâs similar to your real information; you might link multiple pseudonymous accounts together. If your data leaks, can you afford to âburnâ the identity attached to the pseudonym?
If you have a long message history, you have almost certainly identified yourself pretty firmly in your pseudonymous posts, by spelling patterns, word usages, etc.
Leaks of pseudonymous data are less problematic than leaks of eponymous data, but they still have their problems. Unless youâre really good at OpSec.
Finally, I was disappointed earlier tonight to see that Troy had already covered some aspects of this topic in his weekly series at Windows IT Pro, but I think youâll see that his thoughts are from a different direction than mine.