dwaite

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.

That is unfortunately more about adding another edge case for the non-reified Java generics system where it has been forced to partially reify, rather than really addressing the larger complaint.

Historically, Java had a real habit of delaying new major versions for years as features hardened. Some of those features even lost relevance before their first shipping version.

So now they have a precise release cadence that features can fall into. If it is a large feature, it better get worked in incrementally (via feature previews) because it is unlikely to be able to land completely within the release window.

One could pessimistically say the faster release cadence partially serves to provide more opportunities for extended support revenue, though.

Anyone with access to the article know what their sources are on this?

This seems pretty out there compared to say adopting UALink.

The article says they are exploring Nvidia networking, not GPUs

I agree except for disparaging the AVP as not being a real computer while the steam frame is.

One lets you one-tap download native Microsoft Office, one runs it through a browser or via bespoke vm/wine configuration.

Instead, I'd say the difference is that both are consumer devices, AVP geared primarily toward computing while steam frame is geared primarily toward gaming, but the steam frame is open enough for you to develop upon and customize to meet whatever use case you desire.

That isn't really how it works, unfortunately.

The foundation models run on the device for access to the local graph database and to interact with local actions (intents).

Not everything runs locally, but a local model still needs to run to understand that it needs to recruit help, to package up a subset of data for the external agent, and to perform actions on its behalf as well as return results.

Without the local agent, you are shuttling off all your data to be persisted by an AI cloud provider in case they need it.

I think you are describing JavaScript web frameworks, and before that Java web frameworks.

it is a window that starts with usage and continues for five hours.

When I was doing an evaluation using a lower paid tier of Claude, I would have a service send a "hello" ping 4 hours before I started my work day, to reduce my first work-hours session window to 1 hour.

The goal was to have this be more of a "thinking" session for planning the next larger block of work, and then being able to use a lower cost model for implementation.

That said, if your 5 hour window quota is 15% of your weekly quota, this means you can be using 30% or more a day of the weekly quota.

Every project I have tends toward coding agents over time partly for this reason - if nothing else, I want have both control, visibility and portability over memory and a log of the reasoning that went into the current state of things.