The best infosec advice I ever received was “data is toxic”.
computers are built to process data and networks were made to share data
infosec does the opposite
You can't leak users' data if you don't hold it
151–160 of 170 posts
Re: You can't leak users' data if you don't hold it
#152[deleted]
Re: You can't leak users' data if you don't hold it
#153Similarly from Notes From An Emergency [1] by Maciej Cegłowski:
"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."
Re: You can't leak users' data if you don't hold it
#154I 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.
I agree with the sentiment here, but I'm not sure how that could ever really be implemented. 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.
The government should assign punishing penalties for leaks that scale with the quantity and invasiveness of the data, and help grow an insurance industry for paying those penalties. That way, the law dictates how "bad" leaks are with fines, and the insurers encourage/require best practices. Externalities become internalities.
Re: You can't leak users' data if you don't hold it
#155Earlier quoted context omitted.
> Our laws shouldn't punish people for honestly doing the best they know how to Sure, but holding on to data you do not strictly need is not doing the best
Who gets to decide what data is needed? 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?
What you should do when you believe your bank is mishandling your personal information depends on your local laws. In European countries, you would first contact your bank and get them to clarify precisely what data they are storing about you, and what legal basis they are relying on to do so (they should have this already available in their privacy policy, so perhaps you would just go and read that). If the bank refuses to answer, or if you disagree with them about the lawfulness of processing your data, you would then file a complaint with your local data protection authority. After the DPA is done with the case if you disagree with their conclusion, the next step would be to go to the court.
Re: You can't leak users' data if you don't hold it
#156Earlier 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…
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. Ev…
So I did some hunting in the spec (which I should've done when I first heard this concern), so that I can be specific. I turned up this from https://w3c.github.io/webauthn/#attestation-object
> 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.
Re: You can't leak users' data if you don't hold it
#157Earlier quoted context omitted.
> avoid saving info so you can't ever leak it 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 rewa…
> 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? 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…
None of those need to track individuals, they're all really just SKU sales metrics dressed up in different ways.
Re: You can't leak users' data if you don't hold it
#158Earlier quoted context omitted.
I simply used gaming to make it clear attempting to be addictive wasn’t the same as actually being addictive. Social Apps rise and fall in popularity just like everything else. 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 addict…
The only QED is your circular logic
I accept your concession.
Re: You can't leak users' data if you don't hold it
#159> When users add memories to the app, they'll usually add content such as images. We don't want to (and we don't) hold these, either—at least not in a way we can see them. We primarily store these images on your device, but because the size of this storage is limited, we do have a system for storing assets such as images that have been encrypted on-device, and the actual photo contents or the decryption keys are never sent to us. We store data for users, here, but to us it looks like random noise (the binary ciphertext), never like a photo of whatever it is you're storing a photo of.
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.
Re: You can't leak users' data if you don't hold it
#160This is why i wish projects like TBL's Solid [https://en.wikipedia.org/wiki/Solid_(web_decentralization_pr...] would take off some more. I happily pay providers for an application (or at least the service/utility that an app. provides) because that is often the value they is brought to bear for my benefit...but the data, ah the data is something I don't want anyone to control but me. Projects like Solid pave a possible path forward that *could possibly* enable an ecosystem where we still can legitimately pay a provider for value they provide a la an app or service, but still we as users would exert maximum control over our data sovereignty. I hope this author and others continue to keep thinking of data in this way.