Among professional-ready DAWs, as far as I know, it's unique in its approach. Pro Tools and FL Studio still don't have score rendering or even MusicXML export! Reaper has limited score rendering/engraving support, but minimal customizability.
And on the notation-oriented side, you have things like MuseScore, Finale, etc. where there is an event model, but the UI itself doesn't have mature (or any) support for tracking mixer/knob automation (outside of what can be derived automatically from dynamic symbols).
Years ago, I used Logic in a musical theater context where I could build a constantly-updated demo for pitching/rehearsals/live-iteration and edit the final orchestration to be printed for the pit orchestra, both from the same living document. Could I have duplicated my changes in a DAW and notation software separately, and kept them in sync manually? Absolutely, and many creators do. But there's something special about having that holy grail at your fingertips.
> I dont want an online backup. I want my credentials to only be on my computers. So now I gotta learn about which apps are ok, don't have cloud synching
If an "online" password manager uses end-to-end encryption, then the credentials really are only on your computers. The only thing "in the cloud" is encrypted blobs of data being moved around for the purpose of device sync and backup.
This insistence on using local non-syncing password managers is a masochistic exercise in making life difficult for yourself with no security benefit.
Let me rephrase: for the majority of users, the usability and resilience benefits of synced credentials are enormous, and the security costs are marginal at best. But this rests on a number of assumptions. YMMV.
This is not true - browsers including Safari support passkeys managed by third-party password managers.
I'm using 1Password with browser extensions for Safari and Chrome on macOS and iOS and it works seamlessly with my passkeys, which are not stored in iCloud Keychain.
> you're always locked in to one passkey vendor or another.
> This is not true - Safari also supports passkeys managed by third-party password managers.
I think you know what I meant and are just being pedantic here for no good reason.
Do you think I'm unaware of 1Password? I don't want to use 1Password any more than I want to use iCloud Keychain.
Technically, pendantically, Safari "supports" anything that third-party Safari extensions support. I'm a Safari extension developer myself. But this is totally different from how Safari supports the use of passwords, which is all built in, requires no third-party software, can be local-only, allows plaintext export/import, etc.
Reading the cfx spec [1], the raw private key is exported as a base64 encoded der. I don't understand what your concern is here. It appears that any cfx export file is not tied to a specific service to service import path, but can be imported into anything, or just used locally with self written tools.
This is merely the exchange format between credential providers, which is encrypted and gatekeeped by the credential providers. None of this is exported to users.
OK I see what you mean. Having the ability to switch between vendors but not the ability to export your data locally (e.g. as plaintext keys) is a new meaning of "vendor lock-in" I hadn't considered before.
Yes. User freedom is not all-or-nothing. There are degrees, and the tech companies are coming up with fiendish new ways to lock away your data from you. So in the case of passkeys, you can technically move your data between vendors, though that can be quite inconvenient as the submitted article mentions, but nonetheless every vendor locks away your data from you, and most vendors have a financial incentive to keep your data away from you, so that you have to pay for the services.
Once "secure credential exchange" becomes supported by commercial credential managers, what's to stop someone implementing an open source password manager that implements the standard and allows local export in plaintext?
Passkeys relying parties can block providers. Tim Cappalli threatened the KeypassXC developers so.[1] The restrictions demanded now do not restrict user freedom significantly arguably. But the incentives and capabilities are clear.
OK but you'd still be able to use the open source "password manager" to export the keys - which solves the issue lapcat raised in this thread - even if relying parties blocked it for authentication, which would be a separate issue.
Someone could develop a "passkey export tool" purely for the purpose of doing credential exchange then local export.
Or are you saying the credential exchange process itself could block providers?
You misunderstood lapcat I think. They wanted Passkeys stored locally exclusively. And they wanted to be able to use them. The issues are not separate.
Not sure how stating that my (an individual) opinions on a topic are evolving is interpreted as "threatened the KeypassXC developers".
If you've been following along, you'll have seen that I am actually one of the biggest advocates of the open passkey ecosystem, and have been working really hard to make sure all credential managers have a level playing field.
Always happy to chat directly if you have concerns!
The threat you relayed was more serious than the threat you made. But it is a threat when a person with influence suggests they may support a punishment.
The biggest advocates of an open ecosystem say attestation should be removed and no one should adopt Passkeys before. Is this your position now?
The concerns were clear I thought. I would be happy to discuss this publicly.
Not really. The attestation model defined for workforce (enterprise) credential managers/authenticators doesn't really work in practice for consumer credential managers.
Avoid weasel words please. Is it possible in theory to use attestation or any other Passkeys feature ever to prevent a user to use any software they chose with any service they chose?
In theory any code could be written at any time that does something good or bad. Sure.
But in reality, the people who actually work on these standards within the FIDO alliance do not want a world where every website/service makes arbitrary decisions on which password managers are allowed. That would be a nightmare.
Some password managers provide an offline root of trust which family members can use in this scenario. For example, 1Password tells users to print off an "Emergency Kit" which is a physical piece of paper with secret recovery codes printed on it, which they store in one or more safe places. [1]
If someone passes away, their family members can use the Emergency Kit to gain access to and use all their credentials - including their passkeys.
(The Emergency Kit also allows you to recover your data in the event that you forget your master passphrase or lose all your devices.)
I keep hearing it repeated, but where does this "tied to a single device" idea come from?
The default, built-for-the-masses implementation of passkeys is called "synced passkeys". They are designed to sync between all your enrolled devices, ideally using end-to-end encryption.
You authenticate with whatever device you happen to be using at the time - phone, tablet, laptop, desktop - doesn't matter. If you lose one, you replace that device and re-enroll - then all your passkeys magically re-appear on the new device.
If you're cross-platform, modern password managers work across ecosystems - for example, 1Password syncs passkeys between Mac, Windows, iOS, Android, and Linux. If you're all-in on Apple, their native passkey implementation syncs passkeys between all your Apple devices. I thought Google and Microsoft do something similar now.
It's a real mystery why people believe passkeys have to be stored on your phone only.
There are many cross-platform password managers that sync very nicely, which would solve for the machines you control - the Windows gaming machine and Android phone.
For machines you don't control, such as your employer Mac, well that's a special case. In theory you can use "FIDO Cross-Device Authentication", which is a passkey flow designed specifically for authenticating on one device using a passkey stored on a different device, and involves scanning a QR code.
I've never tried this though. Personally I tend to avoid mixing personal stuff with work stuff, so the problem rarely arises.
Because by default, they do, and you have to explicitly install software to let it be moved. And even if you do, it’s discouraged and the spec is allowed to deny you access.
Not exactly. For example, the default credential manager on Android is Google Password Manager, which works on Windows, macOS, iOS, and Ubuntu. There are also dozens of other third party choices.
Last I heard, they were pushing hard for resident keys only, maybe that's changed. I don't like that there's still the option to restrict it to that in the same way having the option to force remote attestation makes me uneasy.
A passkey is a discoverable credential (aka resident key) in spec terminology. But the type of credential has no relationship to attestation (which is not used in the consumer passkey ecosystem).
Just to point out, protecting a key using the secure enclave and syncing it using end-to-end encryption aren’t necessarily mutually exclusive.
The security property you care about is that the plaintext key is only ever processed in use within the secure enclave (transiently, during authentication).
That doesn’t preclude syncing or backing up the encrypted key via a cloud service - if the device allows the application to do that.
Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.
How do the decryption keys for the encrypted passkeys get shared between devices?
>Huh interesting, how does that work? I thought the way yubikeys operate the keys are generated on-device and are impossible to remove, and also come in limited number.
I wasn't referring to hardware keys (like YubiKeys), but rather on-device secure enclaves, TEEs, or TPMs.
Also I said "protecting a key using the secure enclave", which is perhaps a bit of a sleight of hand :-)
By that I mean a key that is wrapped (encrypted) using a parent key stored in the secure enclave. The key itself is not stored in the SE. But since it is wrapped using a parent key that is stored in the SE, that means it can only be decrypted in the SE. I believe this is how iCloud Keychain works, for example.
Digging into this further, it looks like I might have been wrong to imply that a credential manager app can instruct the SE itself to perform the proof of possession calculations needed for passkey authentication using a private key that is "protected" in this sense. When the app asks the SE to decrypt a passkey private key, it looks like the SE might return the passkey private key in plaintext to the app, and then the app itself performs the proof of possession calculation transiently outside the SE. I'm not sure about that, but I'd love to know.
> How do the decryption keys for the encrypted passkeys get shared between devices?
They get established as part of the device enrolment process. I suspect this simply adds another layer to the key hierarchy, so that your passkey private keys are encrypted under a sync key (parent) which is encrypted under a SE key (grandparent).
In that case, you could still claim that your passkeys are "protected by the SE" since they are encrypted at rest and in transit, and they cannot be decrypted anywhere except in the SEs of your enrolled devices.
> Because by default, they do, and you have to explicitly install software to let it be moved
Apple's native passkey implementation doesn't require doesn't require you to install extra software, and the passkeys sync by default. I thought Google's and Microsoft's were similar - but I haven't tried them.
> And even if you do, it’s discouraged
Really? Where is it discouraged? I thought synced passkeys are intended as the solution for consumers.
> the spec is allowed to deny you access
Yeah but I thought that's for enterprise use cases, not consumer. E.g. employers that want to enforce device type restrictions on their employees.
It does if you want to share accounts between my iOS phone and Linux desktop. And it still puts you entirely at the whims of Apple, etc. if you’re allowed to log in to unrelated accounts.
& I think it is mostly being used for enterprises for now ,but much like TPM and remote attestation running on “my” computer, I don’t like that it’s an option
> it might take only one intelligent life form for the space to (eventually) get filled with it
It wouldn't need to be intelligent to do this; it could be a self-replicating machine with no intelligence at all - which is orders of magnitude simpler and therefore more likely.
Chaotic initial state -> self-replicating machine -> intelligence is much more likely than chaotic initial state -> intelligence.
(See my other reply to the GP comment about The Recursive Universe, where all this is discussed.)
Your first question is discussed in the book The Recursive Universe by William Poundstone (1984).
One of the chapters asks "what is life?". It considers (and rejects) various options, and finally settles upon a definition based on Von Neumann-style self-replicating machines using blueprints and universal constructors, and explains why this is the most (only?) meaningful definition of life.
Later, it talks about how one would go about creating such a machine in Conway's Game of Life. When the book was written in 1984, no one had actually created one (they need to be very large, and computers weren't really powerful enough then). But in 2010 Andrew J. Wade created Gemini, the first successful self-replicating machine in GoL, which I believe meets the criteria - and hence is "alive" according to that definition (but only in the sense that, say, a simple bacteria is alive). And I think it works somewhat like how it was sketched out in the book.
Another chapter estimated how big (and how densely populated) a randomly-initialized hypothetical GoL universe would need to be in order for "life" (as defined earlier) to appear by chance. I don't recall the details - but the answer was mind-boggling big, and also very sparsely populated.
All that only gives you life though, not intelligence. But life (by this definition) has the potential to evolve through a process of natural selection to achieve higher levels of complexity and eventually intelligence, at least in theory.
Presumably endpoint detection & response (EDR) agents need to do things like dynamically fetch new malware signatures at runtime, which is understandable. But you'd think that would be treated as new "content", something they're designed to handle in day-to-day operation, hence very low risk.
That's totally different to deploying new "code", i.e. new versions of the agent itself. You'd expect that to be treated as a software update like any other, so their customers can control the roll out as part of their own change management processes, with separate environments, extensive testing, staggered deployments, etc.
I wonder if such a content vs. code distinction exists? Or has EDR software gotten so complex (e.g. with malware sandboxing) that such a distinction can't easily be made any more?
In any case, vendors shouldn't be able to push out software updates that circumvent everyone's change management processes! Looking forward to the postmortem.
My guess is it probably was a content update that tickled some lesser trodden path in the parser/loader code, or created a race condition in the code which lead to the BSOD.
Even if it’s ‘just’ a content update, it probably should follow the rules of a code update (canaries, pre-release channels, staged rollouts, etc).
Are you saying other sequencers are unable to render the same data as piano roll and score?
reply