WorldMaker

My father avoided Chrome this way. Liked Firefox back in the day and had no desire to switch since.

Yeah, a lot of people are using old iPads for this sort of thing. That seems to be the biggest competitor to HomeView is "old iPad mounted somewhere". The multi-user Face ID seems a big differentiator in that competition and might for some be a good reason to upgrade that old iPad to something newer.

That is an image of listening to the Pluribus podcast about Pluribus. It shows that it supports the Podcast app.

But the general impression from a lot of this is HomeView seems to be trying to position itself as something like WatchOS where it hands off stuff to/from a user's iPhones/iPads. So it should likely support apps, but they may be more like Watch apps/faces/complications and CarPlay apps.

My parents have been using an Alexa screen for years for this, but then started buying cheap Android-based picture frames because they somewhat want out of the Alexa ecosystem (and also couldn't resist "cheap" for larger form factor picture displays). I could definitely see recommending this as an option to consolidate their ecosystems somewhat.

The multi-user Face ID enclave also sounds like hardware that old iPads don't have.

The built-in "Check In" app is really great (it automates the "text my parent/friend/relative when I get home" flow, including texting obvious delays from GPS tracking data). iMessage apps are a good idea in general even without a "deep bench ecosystem". Though obviously when it was added Apple was hoping for something like the ecosystem seen in the Asian messenger app space where WeChat and others became the primary app stores and "everything" became a messenger app for a while. (Even in Europe there have been points where WhatsApp had a huge app ecosystem.)

Arguably part of why those app ecosystems worked so well was because they were a cross-platform app experience and iMessage only working for Apple devices and most iMessage apps only capable of strong experiences in "blue chat" iMessage user only streams was always a hiccup for why Apple didn't see a larger uptake in the iMessage app ecosystem.

Walkie Talkie has a dedicated "app" icon on WatchOS and I wonder how much more it would be used by people if iOS and iPadOS offered a more obvious link pinnable to the Home Screen like WatchOS.

For what it is worth, this seems to have a similar screen form factor to the expanded to Duo, so maybe they were waiting for this announcement before revealing the simulator to make it clearer that apps supporting one of the devices may support both? Not the first time Apple has made multi-device plays on a new form factor.

Multi-user "Handoff" seems interesting as well. The implications from a lot of the descriptions is that this HomeView is designed from the perspective that every user also has a primary iPhone or iPad and HomeView coordinates data sync across a number of apps from that primary device. (Several features mention that they only work with that user's iPhone or iPad on the same Wifi network.)

I'm just trying to point out that you seem to be fighting strawmen and yelling about last decade's apps and technology as if that was the current state.

Writing down a password is simpler, but it is also stopped being reliable for the vast majority of users because it stopped being adequate security for the average user. Passwords are too easily stolen. Passwords are too easily reused because human memory is quite fallible. Passwords are too easily caught by a man-in-the-middle attack or a social engineering attack. Passwords are too easily leaked in a database breach. Even when properly hashed and salted, password hashes still are weak to rainbow tables and other such attacks.

Passkeys trade off a bit of supposed simplicity (if you ignore modern advice like use different passwords for everything and always use a password manager because you will never remember all your passwords, it's not humanly possible if they are also all secure enough passwords). But the tech is already at a very usable level of simplicity for average users. It's just like learning a password manager. For some average users it is even easier than learning a password manager the standards and standardized user flows have simplified a lot of the hard edges of the password manager, including the above mentioned "use a QR code to provide temporary access on some other device to your Passkey without syncing your full Password Manager".

That is a hopelessly unusable workflow which is why the default behavior on iOS is storing Passkeys in iCloud Passwords and having cloud sync between devices and cloud backup/restore.

On Windows you can use Apple's iCloud Passwords app for Passkeys now directly, in supported browsers because for whatever reason Apple's engineers didn't want to build a Windows plugin for it (yet?) or you can use the Bluetooth option. Windows 11 makes it very easy to use the Bluetooth option and for better/worse some of the requirements that made Windows 11 stop supporting older hardware were also those making sure that Bluetooth LTE is reliable especially for Passkeys.

In the Bluetooth flow the "only" user facing mediation step is the QR code. Some of Microsoft, Apple, and Google's finest all worked together to make sure that UX is about as simple as it can be with just about no learning curve. If someone is used to pulling up a QR code in the camera app and clicking the default app it wants to pop up, "it just works".

If you hear Bluetooth and think of complex pairing dances, that is nothing like how Passkey signings over Bluetooth work. The devices don't need to be "joined" or "paired", they just need clear enough radios for a quick couple of messages, which a QR code kicks off.

To fill out a bit more of the story, they also stopped supporting consumer attestation after arriving at a "good enough" compromise that they felt was more privacy supporting and better worked with backupable/syncable keys, the uvi and uvm extensions for Webauthn which they championed to standards. Once those standards were in place they especially saw no reason to support consumer attestation.

(Those extensions are for a Passkey manager to "solemnly swear" to an RP that a key was involved in some sort of MFA dance such as PIN unlock or biometric unlock and maybe a little bit of rough detail of what sort. Much more rough than Attestation details and not attested claims at all so a Passkey manager could lie about them, but that's enough for the sort of regulatory compliance or "due diligence" that many Banks might need from consumers to replace existing MFA logins with Passkeys. It is a relatively strong bulwark against attestation requirements for consumers.)

Backup and syncing has indeed been mentioned many times as a factor by Apple why they don't think supporting attestation for consumers makes sense. Consumers need easy/automatic backup and syncing for these keys to be used at all in the consumer world by non-technical users. It is the "it just works" of Passkey management.

Apple has also made it clear they have privacy concerns about attestation as well, which is also why they don't support it, but backup and syncing are clearly very important to Apple because that is very important to keeping consumers happy.

It seems a case of both. It's easier to find more written documentation than spoken documentation. Unfortunately I have no idea how to search WWDC talks or the like, because they have brought up privacy concerns many times.

That comment reminded me too that Apple had briefly talked about supporting consumer attestation if they thought they could make it private enough and the compromise they ended up supporting and delivering were the uvi and uvm extensions, which is nothing like Attestation, are not attested claims (and can be "lied" about by passkeys), but are a much more privacy preserving alternative. Since uvi and uvm were accepted as standards I've not heard of Apple mentioning consumer attestation again.

(uvi and uvm are the CYA assertions that "this key was involved in a multi-factor process such as biometric unlock" which RPs like banks can use for "due diligence" and "regulatory compliance" to require keys be MFA in some way without requiring a full Attestation. Because they aren't attested they are "I solemnly swear a biometric unlock was used" claims, but in terms of regulatory compliance that should be enough in most jurisdictions especially if you can prosecute liars as in-breach-of-contract or felony misdemeanors, which a bank can in cases of banking fraud. So these extensions are huge and another big reason this article is wrong about the slippery slope here, because Apple already made huge progress in standing up bulwarks against it, uvi and uvm extensions being big bulwarks against attestation requirements for consumers.)

This is some of my notes from the last time this came up: https://news.ycombinator.com/item?id=43988852

Not to mention how easy it is to lose archives in things like office moves. Put in the wrong pile and shredded to save space on a moving truck or a closet was missed to be marked to moved and left to the next renter/owner to "clean out" and not having any clue if it was a valuable archive closet or not.

I believe The Onion moved (back) to Chicago from NYC in 2012 around the time that print editions were also discontinued.

Right, which is why Passkeys are consumer-minded enhancement to SSH keys in that browsers are asked to require that every domain gets a different passkey. I've seen SSH agents with that requirement, but yes very few users of SSH use more than one public key per device at a time, and many even use the same private key across multiple devices rather than enroll multiple SSH public keys.

They'd currently also have to give up on Apple users. Apple has made a strong case that they will not support attestation on consumer devices because they see it as a consumer privacy violation. (They support it on enterprise-managed devices only.)

Passkeys is just a new brand name and UX flow on top of Webauthn. If you've handled Webauthn keys before you have already seen the code to "implement" passkeys.

Backwards compatibility. Webauthn is the same standard that has been used for physical security keys for decades. Passkeys are a simplification UX layer on top of decades of hardware support and a complex ecosystem of key providers and key types.

Supporting physical security keys and passkeys is basically the same thing. It's the same APIs and standard (Webauthn). Most of the nonsense like attestation is partly left over from physical security keys but unnecessary and finally optional for passkeys. That's the irony of all this: passkeys were the attempt at "weakening" physical security key requirements for general use consumer things. They stay around for enterprises that still desire requiring specific physical keys. The complicated standards for the huge variety in key types and the relying party having any metadata on which key type was used is a relic of decades of backwards compatibility with physical security keys. Passkeys come with a standard that threatens against unattestable devices because it was built on a standard for attestable physical security keys. Not as much the other way around.

(Apple didn't join the FIDO Alliance on Passkeys until they made sure attestation was an optional feature and no longer a requirement, for consumer privacy reasons.)

The other device has to respond "in nearby radio space" via Bluetooth LTE when using the QR code bootstrap, but that's about the only requirement and it can be just about any device.

This "use a passcode from another device such as my phone" tech mentioned above is just Bluetooth LTE. Every phone and most laptops and desktops in the last decade or so has Bluetooth LTE support. Hardware support is very good.

Passkeys are built on Webauthn (and ultimately sort of synonymous with it) and that has always been the web standard for all physical key support such as Yubikey and is basically the same as it has been for decades when dealing with Passkeys only with updated UX on top. Hardware support here is pretty good, too.

They would have to start by banning Apple users. Apple does not support attestations from consumer devices. Apple has said multiple times they see it as a consumer privacy violation.

We don't need attestation and most of the data bits. Apple consumer devices don't support attestation. Only Apple enterprise managed devices do. It's a paranoia tool for big enterprises with strict device management requirements. Apple has a lot of good reasons to believe attestation is a privacy violation for consumers and seems likely to keep up the good fight in making sure it remains an enterprise-only tool.

Most website implementations that support passkeys have to support multiple key enrollment. It's the only long-term reliable way for the many, many users that are cross-ecosystem, which especially means Windows users in the age of no Windows Phone. Every Windows user has either an Android or iPhone. You can bootstrap with Bluetooth LTE access to your phone for a Passkey, but it's a rough web experience if the user needs to do that every time they access a page, so most good flows ask the user the enroll a Windows PC passkey in addition to their phone's passkey and really good ones make use of a passkey auto-enrollment option designed for this scenario (Bluetooth passkey to "local" passkey auto-enrollment).

Perhaps surprisingly, Windows has helped keep Passkeys from being "proprietary" lock-in because Microsoft no longer has users in a single ecosystem.

There is no dedicated auto-enrollment for "backup" keys, but most consumer sites make it very easy to enroll "backup" keys yourself.

Also, Passkeys don't have to be "online" to enroll additional keys. Each key is independent, enrolling is just generating new keys. The trouble is that web browsers generate lots of Passkeys (at least one per domain, at the very least) so if you in theory want to print them all and store them in a physical vault it might be a hefty book you are printing.

Cloud sync isn't required. Most users want it so that they don't have a single-point-of-failure.

As an implementation detail some Passkeys have a master key that is then used in some key derivation function (KDF) to generate the hundreds or thousands of individual passkeys (at least one per domain), and that's what most Yubikey passkey implementations need to do because Yubikeys weren't designed to store lots of keys, so it is devices like Yubikey that makes it seem like Passkeys are less independent than they really are.

Apple has very good support for Passkey storage in third party password managers/wallets. They don't seem to want Passkeys to be a lock in. They've also made it clear that they see attestation as a consumer privacy violation and won't support it.

Also worth point out that Apple consumer devices intentionally do not support attestation at all, and only support it for devices under enterprise management. That's still a dominant enough number of devices in the US at least that a consumer site seems unlikely to want to disable/break logins for all iOS and iPadOS users.

I think it is some interesting mix of Dunning Kruger and Gambler's Fallacy.

National Amusements wasn't considered an official breach of the Paramount decree because it was "the other around", a theater chain owning a studio rather than a studio owning the theaters. It also got a lot of weird exceptions because National Amusements was entirely private at the time.

But the current issue is right now streaming services dwarf theaters today. The Paramount decree was officially suspended by this administration and its courts on this matter stating it isn't a monopolistic oversight for studios to own and entirely control their streaming services (despite doing the exact same things with "originals" and "exclusives" that led to the original Paramount decree). This administration and its courts not only said the current streaming situation is fine, but that it also means the original Paramount decree no longer applies and studios may own theater chains again, because theaters now compete with streaming.

Skydance having both Paramount+ and HBO Max gives them a huge amount of leverage in the streaming space that is going to get stranger with this consolidation, and gets back to why that 200+ years of combined film history is important and relevant.