The massive problem of data lock-in

Search This thread

Hendrix7

Member
Nov 18, 2023
34
6
Imagine that the camera software on your smartphone did not store your pictures and video recordings in DCIM/Camera but instead into a private, locked-in directory such as /data/… , which normally is inaccessible from the outside.

This means that no other application can view the photos and videos you have taken, and you can not move them to a computer or USB stick or hard drive or any other external device.

Imagine you could only view your photographs and play back your videos through the stock gallery app that came with the smartphone. If you ran out of space, you could not move your pictures and videos out. Once you fill up the 128 GB (or however much) of internal storage that your phone comes with, that's it. You would have to delete older photos to make space.

Imagine you could not back up your data anywhere else. When your smartphone breaks or stops working for whichever reason, there go your memories.

Does this nightmare sound familiar?

Let me introduce you to the data lock-in problem.


Data LockIn.png


We have accepted data lock-in on mobile web browsers and messengers.​


Have you noticed that none of the major mobile web browsers offer a built-in way to export your bookmarks and history and session (list of open tabs) to a file?

The leading mobile web browser, Chrome, only stores three months of browsing history.

Why would you want more than that? If you remember a page you have visited long ago, it is much easier to find it through browsing history than through web search, since the Internet is flooded with an avalanche of new information, and older posts and videos sink deep in the search results, or might have been removed. If a video has been taken down, you do not want to be searching for something that does not exist anymore through the web search. It is better to see immediately it was removed than "searching in the dark" for something that can not be found.

Also, you might want to export your current session to a file so you can close all tabs and start afresh without losing your current session. The ability to export tabs prevents "tab hoarding", since you know you can get the previous session from the exported file anytime. The current mobile browsers do not have this simple feature.

Currently, the only way to export tabs on a mobile web browser is to tediously manually copy the URL of each opened tab into a text file. For several hundreds of tabs, this takes hours to finish. A simple tab export feature would do the same work within seconds.

On desktop web browsers, exporting user data can be easily achieved through using extensions, but mobile web browsers largely do not support extensions. The one that does support extensions, Kiwi Browser, depends on the Google Chrome Extension store, which has added a login requirement in 2023. Extensions "sideloaded" through a CRX file can not export user data "for security reasons™ ".

The same applies to messaging apps. Do the pre-installed messaging apps of Google and Samsung let you save your messages into a text file? No. The only way to get your messages out is to copy them individually. If you have over 9000 messages, good luck with that.

I, for one, would love to see a law requiring web browsers and messaging apps to have export functionality. At least Microsoft set an example by recently adding history exporting to their Edge desktop browser, but since the browser profile folder is accessible on desktop anyway, and extensions for exporting history existed, it made little difference. It would have made a significant difference on mobile.

This is yet another reason why one should get root access. If ones device is not rooted, one does not fully own it. But some users realize it too late. Due to data protection, rooting requires a factory reset.

Recommended article: The sad state of personal data and infrastructure

Internal storage is not an archive.​


Some people have the bad habit of treating the internal storage of their electronic devices, not limited to mobile phones, as a long-term archive.

If you are one of those people, I have bad news for you: Your smartphone's internal storage is one of the worst places to treat as long-term storage. It is among the most vulnerable locations to store data, given that it has so many points of failure.

Factors that could lead to the loss of data include: Your device could get lost, stolen, it could stop working due to a bogus update, you might drop it on the ground or into water and the water protection fails, the USB port of a smartphone might break. These are also reasons why MicroSD is not and will never be obsolete.

In 2022, this person learnt the hard way what happens if you store data only on a portable device:


KAgmrvW.jpeg


(Image source: davdreamer, Imgur )

Actual long-term storage​


There is only one way to reliably store data very long term. What is it? You might not like the answer.

It's optical media. The thing you assumed to be obsolete. The type of storage media you thought is "so 2005". In particular, it is archival-grade optical media.


blu-ray-discs.jpg


Optical discs (CD, DVD, Blu-ray) can not fail without warning, are water-resistant, and have an early error detection system. A hard drive is defective the second it is dropped into water, where as optical discs can survive in water for a long time. Perhaps not for years, but easily long enough for you to take them out of the water.

Optical discs are also not sensitive to electromagnetic impulses, and a disc from a defective drive can be inserted into a new and working drive.

The error detection can be done using tools such as the quality checking feature of Nero DiscSpeed and QPxTool and Opti Drive Control. However, not all vendors of optical drives support it. One that does is LITE-ON.

For the one-time inconvenience of writing data to optical discs (using K3b, ImgBurn, CDBurnerXP, InfraRecorder, or UDF packet writing), you get several decades of reliable archival.

Let him explain the rest:


(Video URL if embedding does not load.)

[I hereby release this text under the Creative Commons Attribution ShareAlike 4.0 license.]
 
Last edited: