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

You can't leak users' data if you don't hold it

seancoates.com

Post reply on HN
Print view View original

121–130 of 170 posts

Re: You can't leak users' data if you don't hold it

#121

Post by Nursie »

jmward01 wrote: post #10

I agree with the core idea, avoid saving info so you can't ever leak it. I personally think our legal framework should be based on consequences to encourage this mentality more. If you are hacked I don't care even a little that you did everything right, I just care that my information got taken. You should be held liable even if you did what the industry thought was right.

That’s basically what the GDPR tried to do, and a great plan.

Instead of making the retention of data a good thing, make it toxic, make it risky. You don’t want PII in your logs, on anyone’s workstation or anywhere else it’s not absolutely necessary.

Make it radioactive.

Re: You can't leak users' data if you don't hold it

#122

Post by __MatrixMan__ »

hirsin wrote: post #108
__MatrixMan__ wrote: post #85

Earlier quoted context omitted.

It seems likely that you know passkeys better than I do (you wrote a blog about them after all), so I've got a question. My impression is that there's a server side component. It's not just a key in your device, it's a key in your device that's blessed by someone who maintains a server. My further impression is that the people who manage the servers (either the authenticating-you server or the supporting-auth-for-you…

It's not a server-side component but something integral to the passkey itself. Everything is on the key and there's no third party - just the key, and the site you're authing to. So when you auth with a passkey, it includes some details around "this came from a Feitian model x or yubico model y or bitwarden or...". That's blank, IIRC, if it's Apple. And then if a corporate type has said "well we only gave our employe…

I see, thank you. I suppose it also lets you reject keys from hardware platforms that are later determined to be insecure.

The tinfoilhattery which I heard (and regret tangentially supporting on occasion) was that it was a slippery slope towards something like SSO, where some company (1Password, say) is your identity provider. And then other companies might reject your identity because hypothetically 1Password only collects a retinal scan, not also DNA, or somesuch, and now we're in a race to the bottom re: just how authenticated one can be.

Re: You can't leak users' data if you don't hold it

#124

Post by travisjungroth »

filleduchaos wrote: post #91
travisjungroth wrote: post #53

Earlier quoted context omitted.

Because their current solution doesn’t meet their own stated goals. > even if we are competent enough to prevent a leak from ever happening, and even if our users trust us to do what we say, we must be resilient to being strong-armed by a future controlling power (e.g. if someone we don't trust buys us) They could be strong armed into collecting data and then handing it over.

And you as a customer can simply stop using their services if you no longer trust their intentions and (and this is a very clear and straightforward point) the company and the new controlling power would have nothing on you. Because it did not exist in the first place. Why are so many of you so keen for them to be "wrong"? Like what even is the alternative approach here supposed to be? Don't build a product in the fi…

> And you as a customer can simply stop using their services if you no longer trust their intentions

The original premise of the article is we don’t have to be concerned with their intentions. This is false.

> Why are so many of you so keen for them to be "wrong"?

I’d rather they were right. But they are wrong.

> Like what even is the alternative approach here supposed to be? Don't build a product in the first place?

Don’t say you can do things you can’t.

I don’t have to offer a solution to point out they’re not offering one either.

Re: You can't leak users' data if you don't hold it

#125

Post by travisjungroth »

defen wrote: post #66
travisjungroth wrote: post #11

Earlier quoted context omitted.

I don’t think the article really answers this. All these decisions you’ve made to not store data are decisions that you could unmake. To put it concretely: if everyone at Matter tomorrow became malevolent and wanted user data, what happens? For example, if you push an app that sends home my private text, how would I know? Could you?

Isn't this an argument against putting any personal information into any app? Signal could turn malevolent tomorrow and start sending all your chats to their servers, which could have life-threatening implications for people vs just potentially being embarrassing.

I put data into Google Docs knowing it lives on their servers. So there’s no problem there.

Signal has an open source client. Big difference for these claims.

Re: You can't leak users' data if you don't hold it

#126

Post by mooreds »

__MatrixMan__ wrote: post #85
mooreds wrote: post #62

Earlier quoted context omitted.

Passkeys are a start. They have their issues (I wrote about some here: https://ciamweekly.substack.com/p/on-webauthn-and-passkeys ) but at least it is widespread, well supported, standardized, (possibly) anonymous public private key cryptography.

It seems likely that you know passkeys better than I do (you wrote a blog about them after all), so I've got a question. My impression is that there's a server side component. It's not just a key in your device, it's a key in your device that's blessed by someone who maintains a server. My further impression is that the people who manage the servers (either the authenticating-you server or the supporting-auth-for-you…

There's a server side component--a public key tied to the private key on a device you control. That public key is also tied to the website that you register the passkey too.

> My further impression is that the people who manage the servers (either the authenticating-you server or the supporting-auth-for-you server) will be able to configure allow/deny lists for each other.

I haven't seen that in the specification. Every host is assigned one or more public keys (again, corresponding to private keys kept in the device), and I don't think there is a common identifier that could be shared between different hosts.

Attestation is not required and seems atypical outside of enterprise use cases. I haven't seen it used at all for consumer use cases.

Re: You can't leak users' data if you don't hold it

#128

Post by yau8edq12i »

mooreds wrote: post #62
Affric wrote: post #57

Earlier quoted context omitted.

I am still waiting for digital identity. Not sure why I can’t authenticate myself with these companies based on a private key and any details they want be disclosed to them for whatever reason don’t just come ephemerally from my server. Obviously, you could also have a third party acting in this space for the non-tech savvy. Right now all my data is held by corporate types who don’t give a shit.

Passkeys are a start. They have their issues (I wrote about some here: https://ciamweekly.substack.com/p/on-webauthn-and-passkeys ) but at least it is widespread, well supported, standardized, (possibly) anonymous public private key cryptography.

Passkeys simply authenticate a device + maybe a PIN. Not a person.

Re: You can't leak users' data if you don't hold it

#129

Post by stephenr »

stpn wrote: post #29

I really love this sentiment. Unfortunately, it also seems really hard to build many kinds of applications in a way that follows this line of thinking. I've been building a personal finance app with privacy in mind, but there are some places where you might begrudgingly "hold" a users' data that are just unavoidable. For instance, if we want to be a serious competitor and have bank integrations, then plaid etc. will…

> good luck collecting payments, avoiding fraud or reporting taxes without collecting name and address

A client of mine collected just shy of $2M last calendar year (2023), and we only store an email address, and a password.

The trick is, let the organisations that (apparently) need that extra data, collect the extra data themselves. Payments are offered via PayPal, Stripe and Amazon Pay, using their hosted payment pages. It works amazingly well. The Stripe and PayPal options can even be achieved without JS, if you wish.

I believe you could also achieve a similar lack of PII using a JS-heavy 'embedded' solution for Stripe and maybe PayPal, but don't quote me on that.

Re: You can't leak users' data if you don't hold it

#130

Post by juped »

__MatrixMan__ wrote: post #122
hirsin wrote: post #108

Earlier quoted context omitted.

It's not a server-side component but something integral to the passkey itself. Everything is on the key and there's no third party - just the key, and the site you're authing to. So when you auth with a passkey, it includes some details around "this came from a Feitian model x or yubico model y or bitwarden or...". That's blank, IIRC, if it's Apple. And then if a corporate type has said "well we only gave our employe…

I see, thank you. I suppose it also lets you reject keys from hardware platforms that are later determined to be insecure. The tinfoilhattery which I heard (and regret tangentially supporting on occasion) was that it was a slippery slope towards something like SSO, where some company (1Password, say) is your identity provider. And then other companies might reject your identity because hypothetically 1Password only c…

It's hardly tinfoil hattery. If it isn't that (and I'm still not convinced by all the above that it isn't) then it needs to explain exactly how it isn't loudly, repeatedly, clearly, and very prominently.
Post reply on HN