Only 3% of the 30% go to payment processing. Hence why they still want 27% when developers choose their own payment system.
The 27% are seen similar to Sony and Nintendo as fees to be on a platform which has wide reach but also gives tools and does stuff to enable app distribution.
Is that too much? I don‘t know but it‘s what all appear to do. The platform politics didn‘t evolve as fast as the tech though. So what about apps like Patreon, Netflix, Spotify, that was never on the table in 2008.
The 3% payment charge is the transaction fee, but that doesn’t take into account the actual handling of the rest of the transaction lifecycle, like managing refunds, or chargebacks. A single chargeback will cost you $25 whether it’s successful or not (plus refunding the transaction if you lose), but on google play and co it’s just refunded.
And there you have it. The "technology industry" hasn't had anything
to do with computer scientists, engineers or technology people in
about 20 years. It's run entirely by marketing people.
I'd imagine there is quite a lot of legal pressure against doing that. Not knowing who your customers are seems like the sort of thing that would eventually involve lawyers.
mullvad.net was interesting to me because I could pay with Monero, meaning that they may actually have no data about me whatsoever except whatever is technically required for a VPN connection. Pretty cool company but it seems like the sort of model that would struggle in most countries with the amount of financial monitoring that tends to be in place.
You're taking it too far. KYC concerns legal entities, that's a different story. In regards to individuals and their privacy, there are ways to greatly minimize personal information processing in "plain" form while keeping records (or access to records) to fulfill legal obligations.
Having had conversations with people on security and anti-fraud teams, many experts clearly share this view.
Could still be done by re-incorporating companies in countries without kyc laws. And if fines for being breached get high enough, that's probably what would happen.
That would probably be bad for tax receipts though, so it's more realistic that there's an upper bound on infosec related fines
I think I'm a tech guy and know my fields. I still have no real clue how passkeys work, how it is better, what it really is.
When your security feature is not as simple as - remember a name and a password and store it somewhere safe - it doesn't work.
Something about keys that are on devices. But what happens when I use a phone and a pc? How to get access then? Do I need a User/PW for the first time? Or do I need one of those keys I have to plug into the device first?
SSH is nice because you don't have to think about it. Your private key sits in your .ssh folder, and then everything is transparent. You _can_ put an SSH key in a smartcard if you want, but you have to opt-in to this kind of pain. And even if you do, almost all SSH servers will support that login method without issue.
Passkeys don't sit in your .passkey folder. Your browser doesn't look for passkeys in a standard folder at all. You don't just do passkey-keygen like you would ssh-keygen and forget about it.
Websites might support various combinations of FIDO/U2F/TOTP security keys, your USB security key might support various combination of FIDO2/CTAP/WebAuthn, and the user will be left confused what any of this mess means, why there are so many competing standards, and why they're asked to scan a QR code when they plug in their dongle, and it doesn't just work at all.
Passkeys ought to be exactly like SSH keys. Unfortunately, they are not.
The attempts to restrict when and how they are stored, and how you can access them - those are going to cause a lot of pain and confusion.
I have all of my SSH keys stored in KeepassXC, which (imho) is a lot more secure than having them hang around in my .ssh directory. Open KeepassXC, and the keys are available. Close it, and they're gone. Synchronizing the KeepassXC-file across devices means that I have access to the keys on all of my devices.
The big companies pushing passkeys are trying very hard to prevent this kind of convenience.
They shouldn't be exactly like SSH keys. With SSH keys, you can go and copy/paste your private keys on a scammer's website because they asked you nicely. People will totally do it as they don't understand what they're doing.
The main thing with passkeys, and key dongles in general, is that you simply can't do that as the keys are inaccessible and you can only prove possession of a key when asked by a domain you've explicitly registered with (the proof-of-possession is never sent to any other domain than that which you registered with).
What OP says is that opens the possibility for key providers to lock-in users, as that seems like an unavoidable side-effect of the legitimate goal of preventing phishing (phishing is the biggest security issue today, to increase security means making phishing impossible, so I still support passkeys as the best solution for that).
There's a big difference between "can't just hit the copy button and paste in the key" and "can't export the key as part of a backup." Physically preventing users from ever accessing their own keys is an absurd user-hostile proposition. Even more absurd when the they're software keys stored in a database the user can decrypt. The FIDO alliance is just ensuring that password managers will require 3rd party backup tools to be useful.
Password managers have prevented phishing just fine by binding passwords to particular domains, ssh keys prevent phishing with IdentitiesOnly and passkeys are bound in the same way as regular password managers.
There has been a pretty insane number of times I've asked someone for their SSH public key and I get a response of ---- BEGIN RSA PRIVATE KEY ----. From people employed in tech jobs. Now imagine someone who barely understands how to use a computer, they're an easy target to get their identity phished.
I don't think the answer to these problems building system that treats users the same as an attacker when it comes to accessing and backing up their own private keys. Because at the end of the day the ability to export your private keys and store them somewhere securely is the account recovery of last resort.
Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense. It's fine for Apple or Google to store your keys at your request and they should keep them secure but the model of "here's my key, now don't ever let me look at it but let me use it via what is effectively DRM" is silly.
If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key." isn't enough to stop people giving it away then no security was ever going to work for them. They would give away the credentials that lets them use the key in its absence.
> Because at the end of the day the ability to export your private keys and store them somewhere securely is the account recovery of last resort.
Or just have multiple passkeys for the same account. It doesn't matter if I lose the passkeys on my laptop because I've got other passkeys to those accounts on several other devices.
> Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense
Resident keys practically are HSMs, aren't they? None of my passkeys are backed up to a Google or iCloud account.
> If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key.
In those conversations with people who should be experts I usually made a point to tell them send me the public key and told them to never share the private. They still sent the public. People have been told to never share passwords either but I still often hear "yeah my password for this is blahblah123..." when asking for help.
Any security solution that involves lay people having access to keys is NOT secure. What you call "absurd user-hostile" is actually basic security in the real world with non-technical people.
Technical people can already be secure using appropriate protections, but even for them it's very difficult to do it properly.
Lay people will, without understanding what they're doing, ask the password manager to give them their password to enter manually on any phishing website as they'll think that it's not working because it's "broken". So , absolutely no, password managers do NOT prevent phishing.
If you think I am exaggerating, well, I work with this and I assure you it's even worse than that.
I would say the exact opposite, traditional ssh key management should eventually give way to resident keys. Aka, treating them just like passkeys.
We've been storing ssh keys directly on our yubikeys since before passkeys were a thing.
Not only is it clearly more secure it's also been a usability lift. Plugin your yubikey, start an ssh agent, and run ssh-add -K to get all your resident keys added to your current session.
I understand this, but the person who responded said Passkeys are exactly the same as SSH and used the same, when asked what they are. If that was true, then we would just teach non-technical users to use SSH Keys.
You should produce a key per device, and produce a backup key that is safely stored & not used anywhere.
You can recover if you lose all devices via your break-glass backup key, and you limit the blast radius of "my key got stolen" from rotating all your keys to just a single device (or maybe the more likely "I screwed up and pushed my key somewhere public")
... which is completely nonviable if you connect to more than a single service.
I agree that you should use a different key per device, but when you connect to over a dozen different services/machines it quickly starts to become a serious chore to add another key. Have fun spending an hour enrolling your new device - provided you can even remember every single usage it should be enrolled with.
Unfortunately SSH certificates have really poor uptake in practice, and it's essentially unheard of to have a personal CA instead of a per-company CA.
But yes, having a single long-living "primary key" everyone can trust which you'd use to generate short-living per-device "secondary keys" would indeed be the ideal solution.
Sure, but then limits you to a handful of keys. The WebAuthn people don't like this, they want one key per service, so basically YubiKeys no longer really work with WebAuthn (unless you're fine with only ever using a max of 25 services).
For me that means having multiple keys in `authorized_keys` for the same user and never transferring private keys between devices. From what I gathered from the discussion here, this is not a given.
Why would you want to? Just create a new passkey on the other machine. If you're saving them in a password manager, just create a new entry, "Another Machine's Passkey."
I went to school in a brutalist building from the 70ies? and I always hated it. I didn‘t know why at the time but the concrete everywhere and the soullessness influences the inhabitants.
This could be done better with wood paneling or painting it. But even as architecture from the outside it just looks sad, cold, depressing.
There's a video on YouTube of the Smithsons - a couple who built some landmark Brutalist projects in the UK.
They're clearly either mentally unstable, or on drugs, or both.
They made a name for themselves by designing a modernist not-quite-brutalist-yet school - plenty of concrete, glass and rectangles, which turned it into a greenhouse in summer, a fridge in winter, and an echo chamber for shrieking kids all year round.
Some architects are very strange people, far more interested in building huge sculptures that happen to have rooms in them than creating inspiring usable spaces.
The 27% are seen similar to Sony and Nintendo as fees to be on a platform which has wide reach but also gives tools and does stuff to enable app distribution.
Is that too much? I don‘t know but it‘s what all appear to do. The platform politics didn‘t evolve as fast as the tech though. So what about apps like Patreon, Netflix, Spotify, that was never on the table in 2008.