This is a quick reaction to reading this post. More elaboration is needed about how to reliably execute this, but I decided to strike while the iron is hot.
The web needs an easy toggle button on all content to determine how long it persists:
Permanent Storage: Once chosen, the associated content is uploaded to a permanent cloud storage location and given a universal link that will never go away and will always persist. The storage system must be designed to enable this permanent retrieval and must have enough backups to guarantee permanent storage and always-on access.
Local Storage: Associated content is saved to the user’s device or other designated personal storage cloud. This latter personal cloud will only be on devices owned by the user, not owned by companies or the government. These devices could exist at remotely rented space, but they and their data would not be owned by the leasing company.
Forget: The data only exists as long as you are running the application/session. Once the session ends, the data is forgotten. For example, a text chat program with this option enabled would hold the chat history only as long as the participants are actively running the session window, then would lose the data as soon as the session ended. No chat record.
Timed Forget: The data exists for a certain period of time after the application/session ends and is then forgotten. Extra options for how to persist the data as remote vs. local could be chosen. Note that the remote option is NOT compatible with the permanent storage system.
With these storage options come the sharing options. Inspired by Java’s scope declarations:
Public: The content is available to anyone and links to it may be generated by 3rd parties.
Protected: The content is only available to those who are sent the link directly. The link will not work beyond a single step—no one may forward or otherwise copy the link to a 3rd party.
Private: Content is only available to the originator.
This system would be greatly facilitated by some kind of universal ID system, where each citizen has one “true” ID account. Other pseudonymous, anonymous, or temporary accounts will still exist.
The success of the above options will rely crucially on interface design, which must connect a user’s choices to some understanding of consequences. I can also imagine applications that would automatically apply policies to particular types of content based on a user’s presets, so as to avoid having to always go through these options. Certain conventions and standards could be developed, for example that text chats are by default Forgotten, while corporate or government emails are by default Permanent Storage. And so on.