Blog 11: Complete Delete
Published on:
Case Study:
Complete Delete: In Practice, Clicking ‘Delete’ Rarely Deletes. Should it?
Today’s case study delves into one of the most critical issues when talking about data privacy. The Delete button rarely deletes the data that the user wants deleted. In some cases, this is a negative impact to the user as they truly want the data gone forever. In other cases, the act of not really deleting the data can be a lifesaver if the user changes their mind and comes back to recover the data. This whole complication is a result of modern computer systems getting more and more sophisticated and it is now up to the system designers to decide what the Delete button actually does.
In this blog, I am going to discuss questions that can help us cope and adapt in this new environment of modern computer systems. There are ways in which these systems fail but there are also ways in which they excel. One of the most obvious ways in which they commonly fail is not telling users that there are remnant data on their systems. This begs the question: What approaches should they use to inform their users of the existence of such data on their systems? The answer to this question is a challenging one in my opinion. The reason this is the case is because the existence of such data ‘on their systems’ defeats the purpose of the Delete button in the first place. With this in mind, whatever approach we can think of should not appear straight after the user clicks the Delete button because would be confusing rather than bring clarity to how the sytem is operating. The idea that comes to mind is to redesign the Delete button and make it say something like ‘Trash it’ to signify that your data is heading somewhere you can you can go back to but only for a limited time before the garbage company comes and tosses it away forever. This approach seems the most sensible to me if we are designing a system that does not delete the data forever. However, if we want the system to completely delete the data, using a specific verb like ‘Delete’ or ‘Erase’ would do just fine as long as we are sure the data is truly gone forever.
The heart of the case study is basically two situations. The first one is when all the information is completely gone when you hit the delete button and the second is when the informtion stays around. Both of these scenarios present advantages that are very hard to compare in my opinion. What I mean by this is that they can be both useful depending on the moment. As I have already touched on above, imagine you delete picture that you are not proud of at all and do not want to see it ever again in your life. In this case, when you hit the Delete button, you will hope and pray that the picture is indeed deleted once and for all. With this in mind, there is a whole other situation whereby we wish we did not delete something and we hope and pray that it reappears somehow. For example, imagine you have an exam coming up and you are in grade 12. You are desperately looking for anyone with past papers that you can practice with and upon reflection, you remember your friend once sent you their past papers from grade 12 but this does not help since you recently deleted some old files in your hard drive to make space for new ones. In this situation, it would be nice if you could recover the old files you deleted recently so you will wish the information on your computer is permanent somehow. In both these situations, the advantages of the two systems, one that completely deletes and another that does not really delete, are not comparable because they are useful under different circumstances. The reason you would choose one or the other is simply based on your needs but it does not necessarily mean choosing one makes the other useless.
The two situations above are both classic examples that have been around for quite sometime. Today’s data storage and deletion technologies are no longer constrained to computers. They now dominate the car manufacturing industry in the name infotainement systems. These systems are widely known for remembering and displaying the names and address books of telephones that were recently paired with the car. Although the systems always come with a ‘system reset’ function that makes all that data vanish, it is rarely used by renters of such cars. One reason for this is that the system reset is often hidden in settings which are notorious for being hard to navigate so a casual user is perfectly fine with not spending all that extra time trying to find a feature that appears useless because it is not advertised well enough. A good way to address this problem is obviously to look into how the system is designed and change things there. One design that would be useful in making sure renters remember to delete their data is to include a message as soon as someone connects their phone to the car as well as when the car turns off. Adding onto this, it would be nice to put the function in a form of a button on the home screen instead of burying it into the system settings. As for what the function actually does when you hit ‘system reset’, that is another system design question. The most sure design I can think of would be to implement cyryptograpic erasure which I assume would be easy since the infotainement systems have their own operaring systems that are independent from the phones they connect to. This independence would make sure that the data gets encrypted in the system and then as soon as a phone is disconnected, make sure the key is destroyed which means the data can no longer be recovered from anywhere.
Another method that could help in getting rid of the data that remain in infotainement systems is object overwriting which is a straightforward solution. However, this can negatively impact the performance of the system and I do not think it is worth the sacrifice when there are more modern and efficient solutions like cryptographic erasure. In fact, many software engineers nowadays do not make object overwriting mandatory on computer systems and I think this is the right call because of the method’s negative impact on battery life and performance. Furthermore, I can already think of a vulnerability associated with the method. I am not sure how feasible this is but I am assuming since we are deleting the data by overwriting it, one could install a tracker that records the history of memory adresses that way we can go back in history and access previous data even though they are not there right now. With all these risk plus impact on performance, I think it is better if software engineers dedicate their effort in improving efficient mwthods like cryptographic erasure.
As I was reading the case study, one question came up as I was reading the four policies that all system designers need to keep in mind in their work. How comparable are the costs of making the deletion technologies, object overwriting and cryptograpic erasure? And which one makes the most sense in terms of coste effectiveness? I think this question is very important because it helps the reader add a different perspective in their analysis, adding to the already discusses issue of impacting system performance and battery life.
All in all this blog has opened my view to the different tough decisions that software engineers make everyday. It was also a bit counterintuitive to get to terms with how much a simple feature in real life as data deletion can be so complicated in the digital realm. It is very easy to get rid of unwanted papers in the offline world but it’s interesting how that gets super complicated online.