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.
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.
Some because they forgot, some because they have not figured out how to monetize it yet.
Then let's make the penalties substantially higher with the risk it incurs.
But no, supermarket chains are all heavily data driven now.
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.
Of course, that assumes a different world where companies actually pay for screwing up in the first place.
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.
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.
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).
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.
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.
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.
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.