Do I Actually Own My Data in POD/eVault?

Before we tackle how you can own your POD, let’s take a step back to understand why Tim Berners Lee proposed it in the first place.

A POD turns the familiar platform interaction model inside out: rather than creating endless accounts across platforms and re-uploading the same data many times, you create a single universal account on your own server (a POD) where all your information is stored. Platforms then access this data on a competitive basis. This approach saves you from updating your information on multiple sites, keeps your data up-to-date across all systems, and breaks the platforms' monopoly over your personal information. (For more on how this next-generation internet – Web 3.0 Data Space – operates, continue reading here.)

Owning your POD sounds great, but what does it actually mean to “own” something?

Let’s consider a simple example: you deposit your money in a bank and use a debit card to spend it. The funds sit in the bank, the card is issued by the bank, and transactions are handled by the bank, yet you consider it as your money. Now, imagine you borrow cash. You’re holding it physically, but it isn’t truly yours – you’ll have to pay it back in a month.

Now, ask yourself: do you fully “own” the money in your bank account? Maybe not, at least not entirely.

Imagine wanting to transfer €15,000 to a friend. There’s a 99% chance the bank will refuse to process the transfer, asking you for a lot of explanations since the amount exceeds €10k. This is part of their KYC policy. If your explanation doesn’t satisfy them, they might even freeze your account.

So, do you really “own” your money in the bank? Not completely, since your control is limited.

Should you really consider putting it in your basement? Not the best idea.

Imagine you’re posting on LinkedIn, and your home loses power – how would LinkedIn save your post to your POD? Or what if your server runs out of disk space? Or your ISP cuts off your internet for a day for maintenance?

And then there are hackers and other bad guys – they don’t care where your POD is stored; whether it’s in your basement or the cloud makes little difference to them.

However, there’s one more reason to store your POD in the cloud – we will explore in the next article about “Data Space”.

So, let’s say you decide on MS Azure as your cloud storage provider. That leaves one key question:

As is typical the case with security systems, control must be established across every level of the system:

• At the Physical Level: Microprocessor software could potentially abuse your data if its developers allowed it. You must be confident this won’t happen.
• At the Disk Level: Even if a disk is removed from an MS Azure server, your data must be protected from unauthorized access .
• At the OS Level: MS Azure sysadmins, even with super-admin privileges, should have no access to your POD. And you need to trust that this is enforced.
• At the Cloud Service Level: If MS Azure shut down your server, it should not affect access to data.
• At the POD Software Level: your POD must not engage in unauthorized actions with your data, and you must be convinced it does not happen.
• At the Level of Facebook or any other platform which access your POD remotely: External platforms must not take any unauthorized actions on your data. They should ensure that only users you authorize can access it, and provide reassurance of this security.
• At the User Authentication Level: You should be fully confident that the John Smith accessing your POD is indeed the John Smith you know.

Meeting these conditions will give you complete control over your POD, even when stored in the cloud. Sound too complex? In fact, these are standard requirements for truly secure industrial systems. For PODs, this high level of security simply needs to be extended to individuals. And there's nothing unachievable about that.

Notice how often we used the phrase “and it should convince you” in the previous section? This leads us to the concept of trust.

Your data exists in a complex environment where various programs interact, each from different providers:

• At the very bottom is the computer with its microprocessors – who manufactured them, and can they be trusted?
• Running on it will be an operating system – who created it, and can they be trusted?
• This computer will be located in a data center – can its communication channels and administrators be trusted?
• Within this OS, a POD program will operate – who created it, and can they be trusted?
• Externally, your chosen platform (say, Uber) will interact with this POD – who developed it, and can they be trusted?

Currently, we trust all these developers blindly. We hope Facebook doesn’t sell our data to Cambridge Analytica. Does it really? No one really knows.

To address the demands for security and trust, we’ve expanded on Tim Berners-Lee’s original concept in collaboration with his team at Solid and the European Data Space (IDSA). This evolved architecture, known as Web 3.0 Data Space (W3DS), is designed to achieve just that. You can read more about W3DS here and explore its security aspects here.

W3DS architecture also allows us to know the reputation of Facebook or any other system based on big data – millions of user and expert reviews of Facebook itself. We’ll also be able to monitor the reputations of developers and managers responsible for these platforms. If they misuse our data, their personal reputations will follow them for life, wherever they work.

This level of TRUST is precisely what eReputation mechanics ensure within W3DS. We’ve embedded eReputation mechanics as the foundation for a secure future internet, introducing personal accountability for systems and their developers. For a detailed explanation of how eReputation works and the challenges we’ll face in building it, see this article. Having covered eReputation, we’re now ready to examine all the levels of security outlined above.

Here, we’ll address the key security layers of your POD which ensure your ultimate control.

If you’re not technically inclined, feel free to skip this part. The main point is this: your POD is transformed into a true digital fortress. Therefore in the Web 3.0 Data Space we call it an eVault to better capture its protected and controlled essence.

Let’s explore the security and control levels of your eVault:

• Server and Hardware: Can They Be Trusted?

Data attacks can occur through the microprocessors within the computer – though rare, this risk is foreseeable. In the W3DS world, corporate and individual eReputation serve as the standard safeguards against untrustworthy hardware developers. If experts, users, or specialized programs detect anything suspicious, they will uncover the truth.

• HDD Drive Extraction

Unencrypted data can be read directly from an extracted HDD. To prevent this, the eVault encrypts all data, so direct access to the drives won’t benefit any attacker.

• OS – Protecting Against Cloud Service Administrators

Protected OS is a complex issue. We refer to such a computer as an "Unattended Computer" (though we’re open to better names). The essence of an unattended computer is that only the owner, who holds cryptographic keys and an ePassport, can access it. The cloud storage administrator (using MS Azure as our example) can only install or power down the server – nothing more. The good news is that OS developers are beginning to recognize this request and are working on solutions. Interestingly, this challenge seems to be better managed at the OS level on smartphones than on servers.

Naturally, corporate and individual eReputation will provide incentives for OS developers.

• Cloud Storage: Guarding Against Server Shutdown

This challenge is addressed by ensuring the eVault operates with “hot redundancy.” Your MS Azure contract would specify that in addition to Azure, two other servers from competitors (e.g., Hetzner and AWS) are continuously synced with updates to your eVault.

So, if MS Azure goes out of business in 50 years, you’d receive an email from Hetzner notifying you that they are now the primary holder of your eVault and suggesting a new “third provider”, such as Google. This setup also supports long-term data preservation, comparable to a human lifespan.

And, of course, any instability in cloud service performance will impact your cloud provider’s eReputation – no one likes surprises.

• POD/eVault Software Providers: Can They Be Trusted?

In W3DS, the primary safeguard against potential misuse by eVault software developers is their corporate and individual eReputation.

Additionally, the eVault includes two key features: (1) continuous backup of all previous versions of your files and data, enabling you to “roll back” at any time, (like a Time Machine), and (2) full logging of all user actions (with personal signatures) to track exactly who did what.

• Remote Access – Facebook or Any Other Platform: Can They Be Trusted?

Technically, Facebook or any platform will always have temporary access to some of your data while you’re actively using it. Here, eReputation changes the game. Facebook understands that any improper use of your data would harm its reputation. Eventually, such misuse would be noticed (even by internal developers, who could report it anonymously). Following this fall of eReputation, most users would abandon the platform within hours for any one of numerous and more advanced competitors, as W3DS enables seamless switching between platforms with a simple click (check out the article One Key for All).

Platforms won’t want to risk their standing. In the Web 2.0 era, the only place to complain about Facebook was Facebook itself, and leaving the platform was merely impossible due to its quasi-monopoly. In the Web 3.0 Data Space era platforms will be very, very careful.

• Remote access – can we trust users?

Now, we’ve arrived at the last level: how does your eVault know that you are really you, and that your friend John is indeed your friend John? If you've granted John Smith permission to edit your photos, how can eVault confirm it’s the right John Smith and not a namesake or someone who’s hijacked his login credentials?

To tackle this, we’ll need a robust identification and authentication system. We discussed this in detail in the article One Key to Rule Them All.

We set out to answer a straightforward question: do you own your eVault?

The answer is a clear “yes” – you own it, because you control it.

And here’s another positive – things are bound to improve. Right now, much of what you "own" sits on the servers of numerous commercial companies, which can use your data as they wish, despite GDPR and similar laws. It’s virtually impossible to prove if Facebook sells your data, as they can always claim it was someone else. So, we have to change it.

In these forthcoming articles we will explore:

• Data Space: This article will show how various parties – your university, your doctor, the police, and even Cadastre – will put (and entrust) their data about you and your properties on your eVault. All these entities won’t have their own databases, and will store information on your eVault because… it’s ultimately your data.
• Who controls the Web 3.0 Data Space: Here we’ll tackle a bigger question: who will manage this massive Web 3.0 Data Space system, including its standards, regulations, registries, and access permissions? Stay tuned.