People getting their accounts compromised leads to spam email, spam comments, fake crypto livestreams, etc that impact others. Google definitely has an interest in preventing people from getting their accounts compromised and not just for the benefit of the individuals with the accounts but their platforms as a whole.
Let’s say for example, I am at my friend’s house, and for one reason or another, I don’t have my phone.
If you need to log into your friend’s laptop to check your email, you would need your phone or some other passkey you had set up for your account, yes, as long as that was the only login method you have setup on your account. If you don’t have your phone, you might not be able to pass the two-factor steps or account login location checks many accounts. If Google finds the new login attempt suspicious for some reason, it will ask for additional checks like a code sent to your email or through a text and you may not be able to log in with just the password anyways. Just because you have the right username and password, it doesn’t mean that a service may let you log in without access to some kind of other trusted information accessible on an existing device.
Overall though, think of it like forgetting your physical keys.
Does that also mean that if I forget to log out of passkey, they can access all of my accounts correlated with my passkey account?
Yes, the same as if you had left your physical keys there and those keys provided access to all your accounts. There may be some technical protections like the timeout until it locks on a password manager but that’s up to the password/passkey manager app to implement and for the OS to guarantee the security of. It’s no different from loading up your password manager on the device. If you don’t trust the device or the owner of the device, you should not access your password/passkey manager on it.
what happens if my passkey account is compromised? All of my accounts are linked to a single point of failure?
The same thing that happens if your password manager is compromised: you secure it (rotate encryption, create a new database, however you want) and then you set about updating new passwords and passkeys for your accounts. That’s why it’s recommended to only have your actual password/passkey manager on something you trust (your phone, your computer, etc) and use that device as the passkey for whichever other device your logging into rather than loading up your password/passkey manager on each device you’re logging into.
A friend of mine had to break out some kind of USB dongle to log into his Google account on a new machine the other day. Is that a form of passkey?
It’s a form of WebAuthn credential most likely, yes. Passkeys aren’t actually entirely new in how they can be used with accounts, the standards have been there for a while now. It’s mainly just a unified marketing from the big players as well as developing an ecosystem around it the standard such as the protocols for using a phone via Bluetooth as a passkey on a desktop/laptop to log in and other things like syncing the passkeys between devices using their existing password manager services for user convenience (so that the average person can actually use them). Under the hood it’s still WebAuthn for the actual authentication. Hardware security keys that connect via USB, Bluetooth, or NFC have been around for a while but have usually operated in nonresident key mode where they’ve been used for second factor authentication. Nonresident key mode has the advantage of storing the private key in an encrypted format with the website or service your logging into, meaning that the actual hardware key doesn’t need to have any storage capacity and can work with an infinite number of sites. This has the disadvantage that you have to provide a username (and typically a first factor like a password) to lookup which keys should be used (ie the ones associated with a specific account). That is probably how your friend logged in with a USB dongle. WebAuthn credentials that operate in resident key mode like passkeys do on the other hand store both the information related to identity and authentication, meaning that all you have to do is select the account you want to log into. This requires that they are stored on a trusted device like a phone, a laptop, or a hardware security key dongle that has storage.
What happens if that dongle gets lost/stolen/broken? Or what if you just forgot it at home? Are you SOL?
Again, the same thing that happens when you forget your physical keys for your car or home. You can’t access the thing protected by them until you go get them. The alternative is to bypass the normal authentication workflow and work around it, such as with an account recovery process (similar to getting a locksmith to get back into your car or home).
I am all for more security and less password remembering, but I hop around a lot of computers.
Then you’d probably like being able to log in by just unlocking your phone and confirming things, rather than having to go through a password lookup and one time code entering process each time.
One key benefit regarding hacking: the data that’s passed back and forth between the user’s browser/app and the website/service is a challenge and a response and is no longer sensitive like a password is and the authentication related data (the public key) that the website stores for a user’s account isn’t useful to an attacker.
One key benefit regarding phishing: passkeys/WebAuthn credentials incorporate the domain name into part of the authentication and it’s enforced by the browser. This means that using a passkey/security key on the wrong site won’t give an attacker anything useful unless they also somehow control the DNS and have a valid TLS certificate to impersonate the site with. This is unlike the situation with a phishing website where a user can be tricked by a fake but convincing looking website into giving over not just a password but a one time code provided through SMS or a TOTP.
One key benefit regarding usability: The user just has to choose which account to log into from their password manager instead of having it need to autofill correctly on the website (I still run into sites that don’t autofill right). They also don’t need to worry about any specific password complexity requirements or changing passwords in response to breaches or password expiration times.
Couldn’t a site theoretically use a nonresident key with just a username, in place of a password?
This seems to imply it might be possible:
https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/Resident_Keys.html
Discoverable Credential means that the private key and associated metadata is stored in persistent memory on the authenticator, instead of encrypted and stored on the relying party server. If the credentials were stored on the server, then the server would need to return that to the authenticator before the authenticator could decrypt and use it. This would mean that the user would need to provide a username to identify which credential to provide, and usually also a password to verify their identity.
For the accounts that are highly important, you might want to use only keys that are bound to a device like a computer, phone, or hardware security key. This would require a bit of manual management as you swap out devices and hardware keys but for a limited number of important accounts this should be feasible. For all the other general accounts, storing them in a password manager can continue to be the most convenient way to use them. The Google/Apple/Microsoft solutions take this second approach and allow them to be synced across devices.
As for the portability, it’s still relatively early and I don’t think there’s a standardized format to export passkeys into. It’s only a matter of time before things settle down and different password/passkey managers support importing and exporting to at least one format that will work.
Passkeys are a way of doing public/private key-pair crypto to prove that you are in possession of the private key that corresponds to the public key that was registered with a site or service when you added the passkey to the account. The use of the passkey is often protected by biometrics like the fingerprint or facial recognition systems on your device but it doesn’t necessarily need to use biometrics at all if you don’t want to and you can instead use a passcode to unlock your device or password/passkey manager.
Basically instead of the normal way with passwords:
With passkeys you have:
In the password scenario, the website could be following best practices and hashing the password or it could just be storing them directly and insecurely. You have no idea what really goes on inside their systems. This also means that due to reused passwords, a security breach at one site can mean problems for other sites, even if they didn’t do anything wrong.
In the passkey scenario, you’re not sending anything particularly sensitive to each site so it’s more secure.
Uh, each service only has access to your public key, not the private one that stays with you. It’s less risky than a regular password.
Even with U2F hardware keys where the server-side stores the encrypted key (to allow for infinite sites to be used with a single hardware key), it’s only decryptable on your key and thus isn’t that useful for someone who has compromised a service.
It basically performs the same function as an SSH key (providing public key authentication), yes.
Your issue with logging in on your phone vs laptop can be solved by either syncing them (like the OS/Browser platforms of Google/Apple/Microsoft or a password manager like Proton Pass/Bitwarden do) or by setting up each device separately (like most people should do with SSH keys). Each method comes with trade-offs: syncing means they aren’t device bound and can potentially be stolen, setting it up on each device can be a pain, etc.
The important thing to remember is that passkeys don’t need to be the only authentication methods attached to an account. You can use the convenience of a passkey most of the time when it’s possible and then fall back to another method (like a password/TOTP pair) when that’s not available (such as when setting up a new device). There’s also always the standard account recovery options if all else fails, those don’t necessarily go away.
The other thing to remember is that it’s not trying to be a perfectly secure solution to all authentication everywhere but to replace passwords with something better. Not having to generate and store random passwords with arbitrary complexity requirements, being able to log in with just a tap or a click, and not having anything that needs to be kept secret on the website’s side can be enough of an improvement over passwords to make the change worthwhile.
Seems like it was mostly Mastodon people irritated The main issue is that it was opt-out and not opt-in:
https://github.com/snarfed/bridgy-fed/issues/835
https://github.com/snarfed/bridgy-fed/issues?q=opt-out
I don’t think the bridge provides the moderation features of Bluesky though.
The author definitely is on the fediverse: @mmasnick@mastodon.social
The article may be fairly positive about Bluesky but how Bluesky separates out various functions like feeds, moderation/labeling, and data storage/portability is a definite advantage that I think should be discussed.
Nope, you still need a phone number. You just don’t need to give the phone number out to contacts you want to talk with and can instead use the username.
I’m not saying NewPipe doesn’t use their bandwidth, just that taking YouTube’s app/UI code too just feels worse to me for some reason. It’s less about the logic of it and more about the feeling.
I think there’s a difference between a third-party app/frontend and a modded app like these. One is at least trying to provide their own value, and stuff like NewPipe for example can support multiple services in the same UI, a feature I wish was better supported in streaming as I dislike trying to navigate all the individual apps. Modifying a service’s app to remove the ads while still consuming their bandwidth and not putting in the effort to make your own app feels worse for me for some reason. At least pirates generally tend to use their own bandwidth and servers to distribute things instead of leeching directly off the original.
Hope that helps explain it for at least one person.
As for what these were, they are modified versions of the official YouTube app. What has been taken down is the full modified app files (.ipa) ready to install on an iPhone, not the source code to the tweaks that are in the repos.
These modifications do things like replicate the paid YouTube Premium features, from the uYou features list for example:
- Ad-Free Browsing: Bid farewell to interruptions and enjoy seamless video playback without annoying advertisements.
- Background Playback: Keep your favorite videos running in the background while you multitask or lock your device.
- Video and Audio Downloads: Download videos, shorts, and audio tracks in various formats, including MP4 and WebM, for offline viewing and listening pleasure.
- […]
You can see why Google would want to have them taken down. They aren’t even a re-implementation with their own code/UI like NewPipe.
You also know that all votes are technically public and can be viewed by any instance admin that’s federated with the server a community is on, right? There’s no way to see that in the Lemmy UI at the moment but the data is there on the server.
It was just for the EU, because they didn’t want to add a whole framework and support for third-party browser engines to act as home screen web apps. Now they’ll continue to offer those based on WebKit everywhere.
Ah yes, MacRumors falsely reporting… Apple’s own statements, right…:
Previously: https://web.archive.org/web/20240216001557/https://developer.apple.com/support/dma-and-apps-in-the-eu/
Why don’t users in the EU have access to Home Screen web apps?
To comply with the Digital Markets Act, Apple has done an enormous amount of engineering work to add new functionality and capabilities for developers and users in the European Union — including more than 600 new APIs and a wide range of developer tools.
The iOS system has traditionally provided support for Home Screen web apps by building directly on WebKit and its security architecture. That integration means Home Screen web apps are managed to align with the security and privacy model for native apps on iOS, including isolation of storage and enforcement of system prompts to access privacy impacting capabilities on a per-site basis.
Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user’s camera, microphone or location without a user’s consent. Browsers also could install web apps on the system without a user’s awareness and consent. Addressing the complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps. And so, to comply with the DMA’s requirements, we had to remove the Home Screen web apps feature in the EU.
EU users will be able to continue accessing websites directly from their Home Screen through a bookmark with minimal impact to their functionality. We expect this change to affect a small number of users. Still, we regret any impact this change — that was made as part of the work to comply with the DMA — may have on developers of Home Screen web apps and our users.
Now: https://developer.apple.com/support/dma-and-apps-in-the-eu/
Why don’t users in the EU have access to Home Screen web apps?
UPDATE: Previously, Apple announced plans to remove the Home Screen web apps capability in the EU as part of our efforts to comply with the DMA. The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS.
We have received requests to continue to offer support for Home Screen web apps in iOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS.
Developers and users who may have been impacted by the removal of Home Screen web apps in the beta release of iOS in the EU can expect the return of the existing functionality for Home Screen web apps with the availability of iOS 17.4 in early March.
The way I see it, Google knows that changes are coming to the advertising industry, either through regulations or just public opinion. By doing this now, they can try to get ahead of those changes/criticisms while controlling what systems their advertising competitors will have to operate under. I don’t doubt that Google will still have enough data to do relevant advertising, either with the data from these new systems in the browser or the first-party data they have on people through their sites.
It’s part of the open source chromium engine.
Here’s how it implements some of the privacy sandbox stuff for example: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/components/privacy_sandbox/
and here’s some of the Topics API stuff: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/components/browsing_topics/
Theoretically they could still inject malicious code even if the stuff in the chromium source code looks fine. Given they got sued for their servers still tracking you while Chrome was in Incognito mode (even with the warning every time you open Incognito mode), I’d imagine any injection of code like that would result in another lawsuit (or several). At some point you either have to trust that Google is implementing things how they say they are in the code that they put out or just use a different browser.
It’s definitely trying to be user friendly enough that non-technical users like the family members you mention can use it to replace passwords. For your use case with a strong password and 2FAS to generate a code, it still gets rid of the phishing potential. The main advantage for the other people like your family is that they don’t have to type or autofill anything, just select an account to log into or click approve on their phone. A main advantage for the service is that the user’s diligence is taken out of the equation for a lot of it and they don’t have to worry about a user giving their password and 2FA codes to a phisher. If a user tries to use a passkey at the wrong site (like a phishing site), it won’t pop up as an option to select because the domain is wrong.
Passkeys can also help anyone who is using a service in an indirect way. The 23andMe “breach” was due to stolen credentials from other actually breached sites being used to log into accounts that have data shared with them. That 23andMe data was shared to those compromised users by people who may have actually had all their security turned up to the highest settings like 2FA but was nonetheless scraped and obtained by the bad actors anyways. If 23andMe had been using passkeys (or even magic login links in an email), there would have been no credentials from other sources to use against their 23andMe’s users. Moving everyone to more secure authentication methods is in the best interest of everyone involved, it’s just that typically it was a hassle to have to setup an authenticator app or a password manager for 2FA. Passkeys, when everything is working properly, finally provide both more security and more convenience for the average person than just a password and so people might actually adopt them.