Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero Data App

0data.app

Post reply on HN
Print view View original

111–120 of 132 posts

Re: Zero Data App

#111

Post by omnimus »

intrasight wrote: post #106
jeswin wrote: post #64

Earlier quoted context omitted.

Very few people have a NAS. Even among the tech literate, there aren't that many people who use SSH or VPN. If this isn't transparent to the user, you'll see very marginal adoption.

Is that really true? Are there tech-literate folks that don't have a NAS and use VPNs? If so, count me surprised. How would you BitTorrent without a NAS configured with VPN?

With your computer without VPN? Tech-literate doesnt mean hacker.

Most people dont know what NAS is.

Re: Zero Data App

#112

Post by ForHackernews »

peterthehacker wrote: post #102
ForHackernews wrote: post #101

Earlier quoted context omitted.

If the company goes bankrupt and shuts down all their servers, I still have my data.

But if the company shuts down then they won’t be able to maintain the app anyways so as a user I wouldn’t want to use the app anymore and maybe have a copy of my data. The company could be required provide a download of the user’s data (encrypted) before shutting down.

Yeah, but isn't it a lot simpler and easier if I already have a copy of my data?

> as a user I wouldn’t want to use the app anymore

I still have a working copy of Corel Draw 10 from like 2005.

Re: Zero Data App

#113

Post by jstrieb »

Storing information in the URL itself is a grossly underutilized way to allow users to control their own data. If data is stored in the URL, there is often no need to send it to a server. And since URLs are so widely-supported, sharing the data is inherently easy.

For example, it takes about 3 lines of JavaScript to store and retrieve a base64-encoded, stringified JSON object in the URL fragment (the part after the # – https://en.wikipedia.org/wiki/URI_fragment).

Re: Zero Data App

#114

Post by sidsidev »

theamk wrote: post #32
vasco wrote: post #6

I'd like to see this applied to online advertising, making cross-site tracking against the law and forcing advertisers to bid per real-time request for user data and the money is paid to the user themselves. Currently advertising platforms make more money by allowing advertisers to better target their ads. I have nothing against this as long as I'm paid for access to my data at the price I think is right (might be MA…

The problem is someone making good money will likely not bother with that system - they will just say “my info is not for sale” instead of trying to figure out settings which would earn them them 0.1% of their regular income. So this system will mostly be used by the people with little disposable income, enthusiasts who enjoy gaming the system, and scammers with tricks to maximize earnings. Those people are not going…

This is starting to happen to YouTube ads. Anyone with money just pays for the monthly subscription and sees no ads.

Re: Zero Data App

#115

Post by conradev »

asdfasgasdgasdg wrote: post #86
conradev wrote: post #83

Earlier quoted context omitted.

Why is Solid architected such that your data resides on a computer that you don’t own, when people own computers and phones that are plenty capable of storing data and communicating via the Internet?

There are a number of reasons you might prefer an architecture like this. The main two are resilience (don't place all your eggs in one basket -- if your computer is damaged or lost you don't lose your data) and availability (if your computer is shut down you can still access your data from your phone, tablet, or another device). It would make great sense to have a non-hosted backend option, though, for power users w…

Resilience and availability are two great reasons, but even then, why not get those by utilizing end-to-end encrypted sync, such that the server does not have access to the data, but the devices do?

Decoupling data storage from the application layer has some advantages, yes, but keeping the data in the clear server-side brings along many of the problems of the original:

- Data is still centralized in large repositories maintained by a company, and these repositories are still valuable and still open to attack, from both inside and outside of the company.

- There is a pinky promise between the data storage company and the consumer to treat their data properly and not to look at it or sell aggregated versions of it, but it is, at best, a pinky promise.

I agree that the open nature of the protocol making "self-hosted" an option is absolutely fantastic. But until that is accessible and easy for every single person to use, then only smart tech people will truly "own their data". That's really all I'm proposing: self-hosting being considered the default.

Re: Zero Data App

#116

Post by conradev »

asdfasgasdgasdg wrote: post #90
somdax wrote: post #88

Earlier quoted context omitted.

You can host your own solid server, right?

Perhaps so. I don't know the details. I was operating under the assumption that the parent comment was correct in its accusation that there was no self-hosting option.

It doesn't matter in the aggregate if there is a self-hosting option if only the tech-savvy can use it.

Re: Zero Data App

#117

Post by asdfasgasdgasdg »

conradev wrote: post #115
asdfasgasdgasdg wrote: post #86

Earlier quoted context omitted.

There are a number of reasons you might prefer an architecture like this. The main two are resilience (don't place all your eggs in one basket -- if your computer is damaged or lost you don't lose your data) and availability (if your computer is shut down you can still access your data from your phone, tablet, or another device). It would make great sense to have a non-hosted backend option, though, for power users w…

Resilience and availability are two great reasons, but even then, why not get those by utilizing end-to-end encrypted sync, such that the server does not have access to the data, but the devices do? Decoupling data storage from the application layer has some advantages, yes, but keeping the data in the clear server-side brings along many of the problems of the original: - Data is still centralized in large repositori…

I'm not sure how e2e encrypted sync works in this context. Someone needs to own a key. If the app is open, then it can't be an app key (or else it doesn't protect against bad actors on the server). Is there meant to be a tertiary party that holds the key then? Probably it would be difficult for most normal people to use a product like this.

Re: Zero Data App

#118

Post by conradev »

asdfasgasdgasdg wrote: post #117
conradev wrote: post #115

Earlier quoted context omitted.

Resilience and availability are two great reasons, but even then, why not get those by utilizing end-to-end encrypted sync, such that the server does not have access to the data, but the devices do? Decoupling data storage from the application layer has some advantages, yes, but keeping the data in the clear server-side brings along many of the problems of the original: - Data is still centralized in large repositori…

I'm not sure how e2e encrypted sync works in this context. Someone needs to own a key. If the app is open, then it can't be an app key (or else it doesn't protect against bad actors on the server). Is there meant to be a tertiary party that holds the key then? Probably it would be difficult for most normal people to use a product like this.

Apple syncs iMessages and Health data between a user's devices in an end-to-end encrypted manner, and plenty of normal people use those apps. They don't even need to be aware that those are end-to-end encrypted.

Imagine the device has a (non-encrypted) database, and the app runs locally and interacts with that database, like normal. Think localStorage if you are web-oriented.

The sync would be a separate background process (i.e. managed by the "Solid server" part) that handles encryption and decryption. As for how to manage a "circle" of devices that share the key without revealing it to the server: you can add a device via a key-exchange with the untrusted device asking a trusted device for the key. You can perform a key roll to remove a device. This can all be done automatically, though, where all the user sees is a control to add or remove a device. The hard part is key escrow (you throw all of your devices in a lake), by password protecting a copy of the key. Apple uses HSMs and Signal uses SGX to prevent brute-forcing this backup key.

Re: Zero Data App

#119

Post by [deleted] »

conradev wrote: post #118
asdfasgasdgasdg wrote: post #117

Earlier quoted context omitted.

I'm not sure how e2e encrypted sync works in this context. Someone needs to own a key. If the app is open, then it can't be an app key (or else it doesn't protect against bad actors on the server). Is there meant to be a tertiary party that holds the key then? Probably it would be difficult for most normal people to use a product like this.

Apple syncs iMessages and Health data between a user's devices in an end-to-end encrypted manner, and plenty of normal people use those apps. They don't even need to be aware that those are end-to-end encrypted. Imagine the device has a (non-encrypted) database, and the app runs locally and interacts with that database, like normal. Think localStorage if you are web-oriented. The sync would be a separate background p…

[deleted]

Re: Zero Data App

#120

Post by asdfasgasdgasdg »

conradev wrote: post #118
asdfasgasdgasdg wrote: post #117

Earlier quoted context omitted.

I'm not sure how e2e encrypted sync works in this context. Someone needs to own a key. If the app is open, then it can't be an app key (or else it doesn't protect against bad actors on the server). Is there meant to be a tertiary party that holds the key then? Probably it would be difficult for most normal people to use a product like this.

Apple syncs iMessages and Health data between a user's devices in an end-to-end encrypted manner, and plenty of normal people use those apps. They don't even need to be aware that those are end-to-end encrypted. Imagine the device has a (non-encrypted) database, and the app runs locally and interacts with that database, like normal. Think localStorage if you are web-oriented. The sync would be a separate background p…

I guess this is a design decision. Some services might be ok with the "if you lose your password you may lose everything without recourse" approach. I think it would be a tough sell for a lot of customers. Is iMessage really handled this way? I can believe that Signal is, considering how often they remind me to remember my PIN.
Post reply on HN