You can't leak users' data if you don't hold it
seancoates.com
seancoates.com
Of course, that assumes a different world where companies actually pay for screwing up in the first place.
In a sense, that gradation is present for other offenses. You kill a man by accident? It may end up being involuntary manslaughter. You kill that same man with malice and planning? It charge will move to aggravated and premeditated murder.
At the end of the day, a life was taken and some level of judicial review should take place. That does not appear to happen for 'hack' events.
If we take the comparison down a step (and into what I think is maybe a more comparable situation), I routinely see warnings in parking lots that they are not liable for stolen property or damage and imagine those are generally probably pretty accurate outside of, again, some negligence on the side of the business.
A better analogy would be like if you were a bank holding peoples' money. Armed assailants break into the money and take it. Is the bank liable because it did not have adequate defenses for the attack?
But the bank situation is easy to solve because it's money and money is fungible, so you solve it with insurance.
Leaked data can't be revoked and it's hard to quantify.
If you make the policy wrong, you essentially end up punishing a victim party (the end users are victims, but the firm that was attacked is also a victim).
Developing & spreading spyware that collects people's personal data without permission is illegal (you don't even need to leak the collected data for it to be illegal), but wrap it in some flashy marketing, dozens of pages of unscrutable ToS and "privacy" policy, and suddenly not only your spyware operation became legal but you can even leak or sell the data in total impunity.
This is valid in Europe as much as the US. Keep in mind that even before the GDPR, most countries had some sort of legislation around personal data processing, use and storage, but none of it was enforced. The GDPR is no better in terms of enforcement, which is why you see tons of (non-compliant) "consent" flows and spying continues as usual for the most part since businesses entirely based on non-consensual data processing are still alive and kicking.
I think that this is a good idea. It's similar to the principle of least privilege: keep only what you need to offer the service you are providing. Less risk for the provider, less risk for the consumer.
However, at least in the USA, I've noticed an increasing number of companies who have determined that personal data is worth good money. This is why most stores have rewards programs, where they capture what you've bought and when you have bought it.
If it was just about repeat business, they'd still be using punch cards, like they did a decade ago.
I don't have any insight into how they use the data, but why would they offer free things (restaurants offer appetizers, grocery stores offer discounts, etc) unless the value they received was more than the cost of the incentive?
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.
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 server) will be able to configure allow/deny lists for each other. They can say:
> sorry passkeys.jimbobsmomsbasement.com, you're not on the list of servers that I trust, so I'm not going to accept this key
Quoting GP here:
> Right now all my data is held by corporate types who don’t give a shit.
Is it true that passkey providers will be able to use this feature band together and prevent passkey providers that they don't like from being useful? It was something about attestations--I didn't fully get it the first time it was explained to me.
If so, doesn't that make the "corporate types who don't give a shit" problem worse? At least with a password the corporate types couldn't deny you the right to authenticate because in their estimation your password provider isn't corporate enough.
And then if a corporate type has said "well we only gave our employees Yubikey 3s", they can instruct their idp to only accept passkeys for Yubikey 3s.
This is a tradeoff - their employees can't register legitimate, useful personal passkeys like their phone, but an arbitrary (not dedicated nationstate) attacker is a bit less likely to somehow takeover the account and add a Feitian key. That mismatch is a nice signal to block the user.
But in general, outside of corporate identities, no one has any interest in caring what kind of passkey you use. GitHub doesn't, certainly, outside of resident key requirements, a different bundle of fish.
(and yes, Dan is definitely great at this stuff, read his blog on this stuff).
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.
> 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.
> An important component of the attestation object is the attestation statement. This is a specific type of signed data object, containing statements about a public key credential itself and the authenticator that created it. It contains an attestation signature created using the key of the attesting authority (except for the case of self attestation, when it is created using the credential private key).
The concern was about how creatively parties with a market interest in providing authentication services (1Password, Okta, Apple, Google) can use this field in service of goals that the user doesn't share, such as preventing competition.
It's already the case that if you don't have a phone number you're in some ways a non-person because you can't 2fa with many services that require it. The same dynamic could be used to guarantee that everybody have a relationship with one of a small handful of providers such that they don't have to care about whether we consent to whatever new requirements they dream up. Maybe. I'll have to think about it a bit more.
For instance, could this object one day contain an attestation that the user has a credit score above a certain threshold? That's the sort of thing that's new compared to passwords.
In a perfect world, we should have the right to revoke our data access anytime we want, specially when there is a material change in management ( Exit/Acquired/CoFounder left) etc.
But rewards programs might make matching easier (across different credit cards and household members).
They also are owned by the service provider and don't reveal anything to credit card companies.
Again, I'm speculating here.
They can track your cards and if they want to track those back to an address and match them all up, not a big deal, but they can sell it if you agree to their turns.
Then let's make the penalties substantially higher with the risk it incurs.
Some because they forgot, some because they have not figured out how to monetize it yet.
Ignoring selling the data to brokers, it's not hard to think of some ways to use the data that's beneficial to both you and them:
- Inventory management: You buy something low demand, but you do it consistently. If they can match up all the purchases of that item to specific folks, and they know the general frequency at which people buy that item, they can ensure it's stocked when you need it, without the need to greatly overstock it. If you stop coming, they also know they may be able to reduce that stock safely.
- Price sensitivity: They do a price increase. Which customers have stopped purchasing the product? Do they need to do a sale on the item for you to purchase it again? Do they need to drop the price? This is more of a benefit on their side than yours, but knowing the most frequent purchasers stopped purchasing it due to an increase could lead to a decrease, where this is harder to determine without good data.
- How effective are their sales? Are they targeting them correctly?
The discount they offer isn't really a discount. It's a price hike for folks without the loyalty program.
They definitely seem reasonable to me, though I'm not sure they need individually identifiable info for most of them.
> The discount they offer isn't really a discount. It's a price hike for folks without the loyalty program.
Sure, that's just messaging. But as a consumer it feels like a discount when I get 0.50/lb off chicken I buy when I use my card.
But no, supermarket chains are all heavily data driven now.
The same concept (don't store the data) was applied to creditcard account data 10 years ago in many point-of-sale systems. Malware simply evolved to logs the data itself.
Not collecting user data in the first place might be a solve, but don't let simply not storing it create a false sense of security. Your user's data is still very much at risk.
Our laws shouldn't punish people for honestly doing the best they know how to, especially with a caveat that it doesn't matter if it was industry standard. Not only is that confusing and at serious risk of punishing all the wrong people, it creates incentives to help hack your competition and throw them to the legal wolves.
Sure, but holding on to data you do not strictly need is not doing the best
I'd argue that my bank doesn't need to retain details of my transactions, only the amount paid/owed. For sure they don't need that data indefinitely. Do I legally go after them because I don't think they need that data? And does the defendant in such a case just need to provide any potential use case for a specific piece of data they store?
If anything, an insurance policy for it allows the companies to externalize and distribute the fines.
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.
I can tell you that it has not made me popular with my coworkers. This whole blasted industry has become completely drenched in PID harvesting, and incredibly casual treatment of said PID. My solitaire apps are constantly trying to get me to sign up for leaderboards and challenges.
I have been denying pig-butchering (most likely) signups for our new app, at about a 30% rate. It's pretty damn sobering (each signup is manually vetted. We don't really care about quantity). We are restricted to US, Canada, and India, and have barely made any efforts to promote the app, but the scammers jumped all over it.
Right now, they are primitive (we have a specific demographic that is hard to fake), but I expect that to change.
I have just come to accept that baddies will get in, so it's important that the liquor cabinet be empty, if they try raiding it.
Side note, we at Sentinel Devices are taking exactly this “we don’t hold your data” approach for industrial machinery. Think automated AI pipelines that are air-gapped. And we’re hiring! If you’re interested, reach out to hello@sentineldevices.com
https://vaultvision.com/blog/what-is-oidc
The user experience is these "continue with" buttons:
- https://id.atlassian.com/login
- https://www.xsplit.com/user/auth
Then you don't have their account creds to lose.
Personal data, PII, etc. is risk debt.
That’s more of a consumer problem.
"It's not clear that anyone can secure large data collections over time. The asymmetry between offense and defense may be too great. If defense at scale is possible, the only way to do it is by pouring millions of dollars into hiring the best people to defend it. Data breaches at the highest levels have shown us that the threats are real and ongoing. And for every breach we know about, there are many silent ones that we won't learn about for years.
A successful defense, however, just increases the risk. Pile up enough treasure behind the castle walls and you'll eventually attract someone who can climb them. The feudal system makes the Internet more brittle, ensuring that when a breach finally comes, it will be disastrous."
Remember "Facebook - It's free and always will be."
Just for clarification, you are storing on your servers encrypted versions of all of the pictures the user enters? Just not storing keys?
If so - storing encrypted user data is not necessarily the end of the world, but why advertise it as though you aren't storing user data at all? You are doing what many other companies do, which is store encrypted user data. Backblaze does the same thing. Or maybe I am misunderstanding.
> If we make changes to this privacy policy, we will update it here and update the effective date at the top. (We can’t email you about changes because we don’t collect everyone’s email addresses.) Changes to this policy will not apply retroactively.
Effectively they can change it any time and you probably won't know.
If they violate it, what power do you have to enforce it? Pay an attorney six figures? For what damages under what law?
Also, I'm not sure what 'retroactively' means here, legally: They have my data and change the policy; can they tomorrow use my data according to the new policy? (Not that it matters much, because I won't know about the changes anyway.)
They explicitly ruled out using your data according the new policy - retroactively means, if they update it, the updated version doesn't apply to you.
They could post a notice in their app, for example.
> They explicitly ruled out using your data according the new policy - retroactively means, if they update it, the updated version doesn't apply to you.
I think it's much more vague than that. Maybe it's not retroactive to prior actions of theirs or to prior data they had. You're assuming it's not to prior users.
I work in cyber security and I am more convinced by the day that the answer is not having the data to steal rather than attempting to mitigate every possible threat.
This combined with zero trust and 2fa/passkeys will go much further than many other snake oil solutions the industry loves.
[1] https://www.schneier.com/essays/archives/2016/03/data_is_a_t...
infosec does the opposite
I thought of just building offline apps for the browser and letting the user sync data using Dropbox or some competitor, but never found an open source project to facilitate that kind of thing (an actual db that syncs through Dropbox). I also heard that locally storing a Dropbox token in the browser could be dangerous (assuming an offline-app-for-the-browser architecture, for example), which meant I'd have to build actual native apps. But then, isn't it dangerous to store a token in the OS as well?
I might never build a side project. But damn, I wish there weren't bad people willing to steal data out there.
Maybe once it matures a bit I'll deploy E2EE, but i gather it's a bunch of work.
I ended up finding some possibilities out there that could potentially help me build stuff. One of them is RxDB [1], which offers WebRTC syncing - you'd still need a signaling server, I suppose, but all sensitive information could be synced E2E-encrypted via WebRTC.
Then there's CRDT's [2], which is a universe that turned out to have multiple possibilities that match (at least partially) my needs. In particular, the next thing I want to take a look at is cr-sqlite [3], which might be just thing I needed to kick-off some side-projects.
I'm posting here cause I just found some hope of not needing to build a traditional client-server app and having to deal with all the hassle involved in securing a server (and with fear that my efforts could be not good enough), and I thought someone else could benefit from getting to know these things.
[1] https://rxdb.info/ [2] https://crdt.tech/ [3] https://github.com/vlcn-io/cr-sqlite
False. You can't leak a user's data if you never have it to begin with. If you process it, you are at risk of leaking it.
Alternatively, stop being pedantic.
But Apple can? From the title, "We outsourced storing user data to an evil megacorporation" isn't exactly what I was hoping for...
How is this prevented, when the evil nation asks you to modify the code to your app to do what you said you wouldn't do? i.e. Steal the data.
Instead, the industry rallied around popups and tried to shift the blame to the GDPR.
it won't, Matter
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 require you to run a server that can see the data, even if you don't want it.
We also don't collect names in our app, just an email, but good luck collecting payments, avoiding fraud or reporting taxes without collecting name and address.
We've built our system to be as minimally invasive (e.g. in the above, financial data is only proxied to the user's device, never stored on the server), but that's only the "intention" part - there's just not a way to take the full measure.
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.
It does exactly what you are describing in this post, all data is local, has identity (so no passwords), data is encrypted on local device but with ability to sync between devices securely.
Another benefit it has is that the code is verifiable, the app you create is just series of JSON files that anybody can read, do verifiable.
Yet another benefit is that the code is written in natural language, making it easy to understand what is suppose to happen. I call it intent programming. You can see more about it at plang.is
I have increasingly come to the belief that mediating our life experiences and social interactions through apps isn't good for us.
Your website "Matter" [1], to be honest, seems completely dystopian to me and an indication of all that's wrong with the relationship between technology and society.
Apps aren't going to make you happier. If you want to be happier, go for a walk outside and go hang out with your friends, in person.
An Uber driver waiting for their next passenger isn’t able to go hang out with friends, but they can play on their phone, or read a book.
I’m on HN right now instead of playing piano or going for a walk. I think I need the reminder sometimes.
Personally, having a driver sit their counting the number of red cars or counting the number of different state license plates is equally purpose serving as doom scrolling. In fact, it's probably much less detrimental to their mental health.
It saddens me a wee bit that people think that the devices much be attended to to this extent.
We don't consider people watching TV, listing to the radio, or reading books as addicts yet people decried each of them as they became ever more popular for ruining the youth etc. People like stimulation and seem to indulge when it's new, but most people also get used to it relatively quickly.
Your second sentence is null after your first.
Compare retention numbers between smoking and clash of clans, a clearly successful pay to win game, and it’s not even close.
We could talk about various other apps, but nobody has actually nailed addiction for the general population just the people highly susceptible to such behaviors.
it's like you think a device is only able to play games which is clearly ludicrous.
Meta has billions of users but that’s split across 4 platforms FB, WhatsApp, Instagram, and Messenger. So clearly popularity isn’t the same as addiction otherwise their FB app would be all they need.
Go back a few years and Netflix seem addictive as people binged shows, but I doubt anyone is seriously suggesting they are addictive today.
Q.E.D. New and fun isn't the same as addictive.
I can't tell if they're trying to sell me groundbreaking new brain scan technology or very dodgy supplements. Possibly one of the most vague product sites I've seen and there are a lot that come up on here.
I'm surprised this happens in tech so much. I feel I'm always very aware of people in the real world having no idea what I work on, so I always need to give background and context. I have noticed people in other industries haven't experienced that their whole life so often rattle off jargon that means nothing to me.
Looks like all the founders are US based, maybe it's a cultural thing.
Few years ago I was at a cloud conference and met who worked for a failure large and known security company in a tech position. They have all kinds of offerings. While he was talking to someone, I decided to speak to one of their sales guys. I shared a bit about what my company did and what kind of infra we were using and then asked him what they offered and specifically what they could offer to us. This was one of dumbest conversation I had ever had. The guys had no f*cking clue what his company was selling beyond "we sell turn key enterprise security solution", it was so painful. I even tried to steer him into trying to sell us some vulnerability scans or traffic analysis for threat detection.
Yeah, I get it, it maybe niche, he is in a non technical, they have many offerings, he hadn't been there too long (iirc about a year, which is long enough for sales), but it was still unacceptable. To me it's the same phenomenon – lack of clarity in communication – not exactly sure what the root cause.
As a result there isn't much video of the kid, but I don't regret it. By the timewe switched to video cams in our pockets, I had pretty much given up, and apart from a few few-second captures, I haven't shot any video in years. And TBH I don't miss it at all.
Apps like this are simply more of the same.
So thanks, but this isn't enough anymore. We need laws that will guarantee that every company that handles our data will do it thoughtfully and safely. In the meantime, I'm not expecting much.
You should probably read the article, though. (-;
I have access to everything (on the tech side) at Matter, and if you put your social security number into the app, I wouldn't be able to access it to write it on a sticky note. That's the whole point.
PS I'm also old and jaded. (-;
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?
Signal has an open source client. Big difference for these claims.
Still, I’m less confident in saying any other company fulfill’s Matter’s promise than saying they aren’t.
That's a major point that's addressed in the blog post, did you read it?
Audit the code as desired, pin to specific versions, run on a private network.
> 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.
A closed source client is fundamentally incompatible with the claims they want to make.
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 first place?
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.
1. You can't leak what you don't have.
That is, even if the company gets bought out or is hacked, if they don't have the data, there is nothing to leak. This point is also at least partially enforced by another point from the post:
2. Advanced app users can audit their network traffic from the app
Now, granted, I wouldn't expect many users to do this, but highlighting it at least serves as a warning that it should be harder for the app to surreptitiously change what is sent to the server (and to emphasize, I know this can be worked/hacked around, but I don't think working around this could ever be done with plausible deniability).
Given the fact that companies and products jettison their high-minded policies as soon as it becomes economically inconvenient, the only other thing I'd recommend for the author is to have a good, simple export tool, e.g. something that dumps all the "memories" to a directory or PDF file. The post talks about backup and restore, but if I were a potential user I'd like to know that if the company does kick their privacy policy to the curb at some point that I could get all of the investment and data out of the app without needing to continue to rely on the app for at least the base data I put into it.
Isn't the point of the article that they can't leak something they don't have?
So if I never get your social security number from you, then I have zero risk of leaking it or exposing it to hackers. I can't give them (intentionally or unintentionally) something that I don't possess.
The author says:
> Given these criteria and extremes, we decided that our best course of action is to just never have our users' private data.
---
To your next question on what happens if Matter is acquired. Well the app might stop working or change how it works or have new logo in the corner, but your data never left your device, so you don't really have to worry about it being leaked to Belarus.
You're one update away from having an app that has access to all its data and can ship it anywhere. Do you keep updates off?
Every time I turn on my computer dnfdragora is like "there are 35 new updates!"
Oh yeah? But my computer is working. Those updates could fix problems that I don't have but could break stuff I have as well. I'm not updating until they release Fedora 40. (my nvidia driver stopped working when I upgraded to 39, again...)
To begin with who thought these notifications were a good idea? Just appear meekly on the system tray when you have something to say. The only time a popup is acceptable is if it says "yo, your computer is on fire." Anything less is unnecessary distraction.
I want my software as-is, changing only when I want it to change. The other day a Windows update removed my "show desktop" button from the task bar to insert a copilot button. Who asked for this? The taskbar changes when I say it changes! I started using the program because I liked the way it was. If it wasn't the way it was I wouldn't have started using it, so why change?
To make matters worse, I don't think there has ever been a time a software updated that I said "they finally added X!" It just never happens. It's insane. Things really only get worse with time. Ten years ago GIMP didn't have nondestructive editing. It still doesn't. I'm still waiting for it. They said it will come in GIMP 3, for years. I feel like that update is just never coming. We're at GIMP 2.99.18 now. Can you believe it? 2.99.18. Who even reaches minor version .99?!
As soon as it has a server to talk to things changes. It becomes rather expensive to maintain a server that has to support any previous client, or to support all the users who don't know how to update.
In practice auto-update is the best default. Android lets you turn it off. On iOS I don't know.