dwaite

I think Firefox had system integration with the password/passkey provider framework since 122.

If you do not have access to your personal Apple account on your work laptop, you would need to find some other passkey provider with native integration.

Under Settings > Privacy and Security, look to see that Firefox is listed and has access under "Passkeys access for Web Browsers". Unlike a native app which only needs passkeys for its own services, Firefox needs access for every potential service you might hit over the internet.

Then under General -> Autofill and Passwords, you'll see any apps which are registered as system password managers. Unfortunately this is a subset of the ones which register on iOS and I'm not familiar who has done integration yet in their Mac release - Chrome (with GPM) for instance is not listed even though it is available on iOS.

Generally, if you want to restrict the user to use a particular authenticator, you need to own that authenticator. At that point you can have the attestation you are looking for. If you want Yubikey policy and behavior, you're gonna have to get your user a Yubikey.

The passkey provider vendors are motivated to serve their customer's needs (the end users, and secondarily enterprise deployments) over non-customer needs.

So Apple platform support (for example) will only send an attestation when one is configured via MDM. Your provisioned work device can indicate to work systems that it is in policy.

The compatibility-limiting risk, if it exists, is more likely from regulators putting their hands on the scale and pushing for security policies that would prevent synchronization and backup, and requiring attestations to make sure those policies are in effect.

That isn't what is being discussed by the issue. The issue was pertaining to an unencrypted export.

Which changed to KeepassXC looking to support the standarization work to allow passkeys to be moved between user-controlled software products.

The complaint wasn't in allowing credentials to move (that is the point of the CXF and CXP work). The complaint was in having sensitive data in a plaintext file live long-term without any protections. That is also why one of Tim's early recommendations was to require encrypting the file via a passphrase.

> When a website prompts me to set up a passkey, depending on the device I happen to be using at the time it could end up going to Google password manager, Samsung password manager, iCloud Keychain, or Windows somethingorother.

This is the same problem we've had for 20 years with password managers, though.

The solutions are mostly the same as well (with the change to a QR + BLE based mechanism over manual transcription to go cross-device, and a protocol to support moving passwords and passkeys over to different software rather than using a plaintext password CSV export).

Many password managers also manage passkeys (and were managing TOTP before).

> nd its dialectical opponent: a fan with a chandelier attached to it. (Perhaps a chandefan?)

I believe the term is "Schadenfan", the misfortune fan

Third switch. 68000 series to PPC to Intel to Apple Silicon.

Now that they have stopped supporting Intel-based Macs, I understand the desire to not have to port new code and features to x86-64 to keep legacy apps happy.

That is why Intel-based Mac App support is going away, but Rosetta 2 as infrastructure will remain - a much smaller footprint of system functionality will be addressable by x86-64 code that they can reasonably maintain going forward.

That's actually better than where I thought we would be now - I thought by M6 they would remove the hardware extensions that allow Rosetta 2 function from Apple Silicon.

What is the consent line being drawn here? From handwriting recognition and mail filtering from back in 2002, face detection in iPhoto back in 2009, text to speech and Siri, dictation, NLP, text to speech, the vision framework, and Core ML are all examples of AI/ML tech that have shipped at some point standard on new Macs long before Golden Gate.

My understanding is that they are not SSDs - they lack a disk controller, instead providing flash memory more directly to the SoC

Hey hey, we obviously should ask Gemini to settle this disagreement.

Yes, but you shouldn't be taking instruction on how to verify the security of a JWT from the JWT itself in the first place. Don't follow an attacker's security steps.

Google's search AI actually its too dangerous to release to the public. I have relatives routinely citing it as their source for medical advice.

I have quite strongly told them, in no uncertain terms, that they are going to kill themselves doing that.

I think the counter-argument would be that one obviously should have gotten a Kia K4. Otherwise equivalent for everyone's needs excluding hand brake location.

Does Xcode 26 still work on Sequoia? They usually stop supporting N-1 around March.

Not sure. People are saying "Siri" but complaining about space utilization which I assume is for the foundational models. Those are used pervasively, and are exposed as a resource for third party app usage as well.

Apple's goal was to have a set of foundational models to discourage proliferation of small bundled models in first and third party software. So ironically, they exist to try to save people disk space.

Interesting, I do that and haven't really thought embarrassed about it. I consider it akin to putting away tools once I'm done with them.

Likewise, speaking collaboratively or capturing emotion ("We did it!") would just align with any ongoing interactive and/or personal context of the thread.

I've done a mock "what if I wake up naked in Tokyo" for my own recovery several times, mostly because I keep things really tied down.

I have not yet done an actual test within Japan, however.

I have over 2,000 accounts. The majority of them have unique passwords. I can count the services that have passwords that I know on one hand, with quite a few spare fingers.

Passwords just don't provide a broad recoverability benefit once you commit to doing strong, unique passwords.

> Passkeys were created specifically to close that loophole.

Credential sharing? I have a family share with passwords and passkeys in it. Passkeys most certainly didn't stop this.

They did add friction to having a user being duped to share their password to someone claiming to be tech support, since you can no longer request plaintext secrets be sent over arbitrary channels.

> Plus, SMS didn't allow for vendor lock-in, which is arguably why they're so hated in security circles (SIM-jacking is real, but doesn't scale anywhere near enough to warrant deprecating it as mechanism for regular users).

SMS is an ugly user experience and more importantly is expensive. Now a lot of services do emailed codes when they don't have a regulatory reason to require SMS - an even worse user experience, but less expensive.

We have authenticator apps which use a standard OATH setup, and quite a few platforms which have integrated support to try to sand over the worst part of the UX. Unfortunately they just didn't become popular, and OATH fails the same regulatory requirements that emailed codes fail.

Passkeys are not meant to have a vendor lock-in story. Credential exchange allows for credentials stored in consumer credential managers to be imported into another credential managers. The platforms have added infrastructure specifically to make this easier for users.

The exceptions are when enterprises run their own passkey stores, or when the user explicitly picks a solution that doesn't allow export (like a physical Yubikey).

FWIW my break-the-glass actual use of backup codes is for access to my password manager.

Everything else which has ever given me a backup code... gets stored in a secure note in my password manager.

It is just another knowledge-based factor. It is one that they are reasonably sure you aren't spreading around the internet. It is one that the site gets to pick rather than the user. But in reality, they are a often just a way to try to reduce some support and identity verification costs.

The path to get to the password manager is the case where the backup codes truly matter, because without them there may not be a way for support to restore access. Those codes may be your only way of regaining the master encryption key.

But that also winds up being part of the trade-off of security vs user friendliness. Some password managers are way easier to get back into.

Right - you can treat the protocol as having:

1. Initiation (QR code, NFC in draft)

2. (Proximal) negotiation (BLE key exchange)

3. Communication (over websockets or a direct L2CAP channel)

The challenge is that a devices without bluetooth (at least today) don't have another common way to wirelessly judge proximity. A desktop/laptop without bluetooth likely either doesn't have NFC, or has bluetooth disabled by policy and would likely have cross-device passkeys disabled by policy as well.

That's likely Google's implementation of Local Network Access (https://wicg.github.io/local-network-access/).

The browser delegates passkey plumbing up to the core platform typically, so it already should have the appropriate permissions.

Yes, the passkey flow QR code contains a public key, and a local key exchange is done over bluetooth to prove proximity. That is used to set up a confidential channel.

That means attackers need more than to display a QR code, they also need a local presence (radio).

> But this still breaks the login flow for a very common use case: how do I log in on a device that I don't own? With a password in a password manager I at least have the option of manually typing the password.

This is meant to be solved by the cross-device flow - a QR code pops up that you scan, and a secure channel is established from that with your other device.

[Disclosure: an editor of said standard]

> The biggest problem, though, is how users are pushed into it without any warning or knowledge of what they're signing up for.

On macOS/iOS, the system gives this prompt regardless of where your passkeys are being created/stored:

Save a passkey?

"<site>" supports passkeys, a stronger alternative to passwords that cannot be leaked or stolen. A passkey for "<username>" will be saved in "<provider>".

There is a transparent upgrade option though that sites can request - basically when a site supports passwords and passkeys, they can request a password manager supporting both create and return a new passkey on password sign-in.

> [...] and had to go back and figure out how to undo it after being blocked from login on another computer (which computer was I on again?).

That's unfortunate. A site/service should absolutely not replace other passkeys, nor should it remove other sign-in options like passwords, without explicit user consent.

The above credential upgrade flow makes that doubly so; even if someone relies on a password manager to manage and provide their credentials for a site, it very well may not be the singular piece of software that does so.

> it's a low level language - ergo you have to literally express more things about the code

That isn't really a comparison of the languages as much as the standard runtimes and ecosystems. It is important to consider that each have comparable components.

So you aren't comparing a no_std rust project against a comparable JavaCard, but say Diesel vs Hybernate code examples around ORM.

> Which Java famously does not have.

Hmm? Java gets null dereferences all the time, that's what a NPE is. The VM takes on the extra plumbing to surface a dereference of a null pointer in a recoverable way to code. On Windows this is done using SEH, on Unix it is handling SIGFAULT - but each NPE corresponds to a null pointer dereference that java then tries to clean up.

That the language does not have a way to have compiler enforced "never null" is actually a huge productivity drain, specifically because you have to do your own defensive measures against null or attempt cleanup/recovery when it happens.

Even languages like Swift which use Optional (e.g. a maybe monad) to provide a concept of nilability still internally will hit null pointer dereferences on occasion with faulty bridged code/bindings. However, they treat this as a non-recoverable violation of invariants - a developer shouldn't be trying to recover from incorrect code at runtime.

I've found the challenge of running a non-existent version on a tree that was EOL 16 years ago is typically keeping it up with internal security standards, and not one of new collaborative development.

> They can offer very good performance (often better than Java) when small. But as they evolve over time, or are very large to begin with, they become much harder to keep performant.

Generally, efficient memory management is orthogonal to object oriented design. Meaning, as your complexity grows and your business logic changes, it often means the optimal memory management changes because the lifecycle and relationship between objects change.

For a web server for instance, you have both request/response as well as various transactional memory requirements. In Java, the role of the garbage collector is to adapt to whatever the best memory policy is based on runtime behavior, rather than statically defined rules. One could say that the evolutionary and revolutionary changes in garbage collectors as well as the multitude of tuning parameters comes from this being a really hard task.

If you have a services architecture, the runtime advantages of Java go down significantly.

> I wasn't talking about "runtime compatibility" but of overall version compatibility. Java has an unmatched compatibility record.

I would say both matter significantly more again in a monolithic architecture. It matters a lot more when you are trying to deploy your software into a single application server, or trying to avoid version incompatibilities when integrating large amounts of code into a single executable.

> Time and again we see Rust or C++ programs spend 30-50% on memory management.

I've seen plenty of Java applications spend 30 seconds or longer because they had to do a full garbage collection back in the day. I even had one customer who maxed out Java to utilize all the memory in their server and hit a 13 minute production pause due to otherwise unoptimized GC (promoting many temporary transactional objects to the mature generation until it eventually exhausted memory).

The different strategies for memory management (static vs dynamic) ultimately still require recognizing, diagnosing and correcting issues. GC provides unique challenges because the tuning mechanism is decoupled from the actual code. GC challenges can also often go undiagnosed until staging/production workloads hit them, precisely because they are dynamic behaviors.

Java is still excellent when you need to have software that ships and gets integrated into a customer's environment, or need to support a diverse set of such integrations yourself.

A weather app could be asking for your location to give you more convenient local forecasts.

It could also be asking for it to help advertisers build a robust behavioral profile about you.

This is not a systems permission, nor is it something that billions of users can judge the ramifications of each potential privacy impacting decision. Privacy is a systems property, not a technical property enforced with ACLs. ACLs can only keep the door from being wide open, they can't prevent access which has been granted from being abused or help the user understand ramifications of granting access.

We need privacy to be a regulatory concern with actual enforcement via an international framework. Until then, it is a business concern of Apple/Google - because they are in the business of having consumers feel confident that a weather app isn't reporting their behavior to anyone willing to pay for it.

Identity Verification is the realm of digital credentials. The goal isn't to make putting a driving license or passport on a desk and to verify the picture is of authentic pixels, but to move to mDL / EIDAS2 technology to have a digital representation of a driving license/passport.

This tech would just indicate that they got authentic pixels capturing a potentially fake license.

Likewise, this doesn't help as much as you'd like with most bespoke remote selfie verification systems, since this doesn't support video, doesn't protect against MITM and adds a remote processing delay that breaks any time-of-flight measurement. It shuffles the risks around.