ylk

On which OS? Android and iOS don’t. Not even Qubes does.

It's sandboxed, not in a VM but using the *OS sandbox/seatbelt. Running all renderers in a separate VM on a consumer phone sounds like a terrible time when you need to stay competitive regarding performance, responsiveness, etc.

you can see in both the lastpassword and the bitwarden tutorials that the default iOS password manager can be toggled on or off, just like the other options.

you're misunderstanding: this isn't specific to passkeys, this is for changing the password manager(s) used when filling passwords, 2fa codes and passkeys.

since the person I responded to couldn't find it, I linked tutorials. it amounts to opening the Settings app, going to "General" and then "AutoFill & Passwords", so it's also not terribly difficult to find compared to other iOS settings.

you could've at least tried to understand what's being talked about before blindly complaining.

LastPass has a tutorial video that shows you how to only use them for autofill: https://www.lastpass.com/features/autofill/iphone

Other password managers do, too: https://bitwarden.com/help/auto-fill-ios/#keyboard-autofill

This is not accurate. The very first sentence of that issue is:

> Passkeys should never be allowed to be exported in clear text.

and from another comment by the issue creator:

> I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.

They're arguing for storing them in encrypted form. That's very much a different argument than arguing against exporting. I'm not taking any sides here, I just think it's bad to so badly misrepresent people's standpoints.

The URL was meant to be https://badhost.org, the site accidentally still has the old canonical meta tag.

You're correct, thank you. Sadly I can't edit my comment anymore. Sorry for the confusion.

There are (illegal) marketplaces initial access brokers sell session cookies on. Some companies try to defend against that by e.g. checking whether it's even possible that you travelled from place A to place B within a certain timeframe and, based on that, might invalidate your cookie. But then again attackers, depending on their sophistication, find their ways around it by ensuring they proxy their traffic via geographically close residential proxies, use the same OS and browser versions, etc.

Google now wants to bind credentials to a device by storing the secret in the TPM: https://blog.google/security/protecting-cookies-with-device-...

For reference, this is how Google says Chrome stores passwords encrypted in memory and uses an elevated service to prevent other processes from impersonating Chrome and gaining access to the plain text passwords: https://security.googleblog.com/2024/07/improving-security-o...

This is not how CVEs work at all. You can be pretty vague when registering it. In fact they’re usually annoyingly so and some companies are known for copy and pasting random text into the fields that completely lead you astray when trying to patch diff.

Additionally, MITRE doesn’t coordinate a release date with you. They can be slow to respond sometimes but in the end you just tell them to set the CVE to public at some date and they’ll do it. You’re also free to publish information on the vulnerability before MITRE assigned a CVE.

> The baseband can do a lot, it has dma

There's an IOMMU:

> Is the baseband isolated? > Yes, the baseband is isolated on all of the officially supported devices. Memory access is partitioned by the IOMMU and limited to internal memory and memory shared by the driver implementations. [...]

https://grapheneos.org/faq#baseband-isolation

> GrapheneOS cannot really influence this, but hardened_malloc could conceivably help.

They can and do, see above. But I don't see how hardened_malloc is related to the baseband doing DMA.

fwiw, they're using CVSSv3. In CVSSv4, it's probably an 8.7: https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L...

> Android 16 no longer provides device trees for Pixels as part of the Android Open Source Project. It's important to note it doesn't provide those for any other devices. There are no other OEMs providing similar AOSP support. [...]

by strcat, Graphene OS founder https://news.ycombinator.com/item?id=44679100

The screen is a 16:10 screen with some extra pixels added next to the notch. By default, the system uses a resolution of 1512x982 (14"), which you can change to 1512x945 (16:10) to move the menu bar below the notch and end up with black pixels next to the notch.

You don’t have to assume, the docs in the repo tell you that it does run a Linux kernel in each VM. It’s one container per VM.

Not trying to argue that this happens regularly, but some recent (last 6 months or so) minted update contained breaking changes.

> a feature that can only be appreciated by a subculture of people (privacy advocates)

Just because it can’t be “appreciated” by all users doesn’t mean it’s only “for” a small sub-group.

It seems to me they’re just trying to minimise the data they have access to — similar to private cloud compute — while keeping up with the features competitors provide in a less privacy-respecting way. Them not asking for permission makes it even more obvious to me that it’s not built for any small super privacy-conscious group of people but the vast majority of their customers instead.

What you write sounds plausible at first, but then there’s this example from the German KSK:

„In 2018, the German Federal Criminal Police Office uncovered a plot involving unknown KSK soldiers to murder prominent German politicians such as Claudia Roth, Heiko Maas and Joachim Gauck among others, and carry out attacks against immigrants living in Germany.[7] Also, earlier that same year in a separate investigation, the State prosecutors in the city of Tübingen investigated whether neo-Nazi symbols were used at a "farewell" event involving members of KSK.[8][9]

In June 2020, German defence minister Annegret Kramp-Karrenbauer announced that the unit would be partially disbanded due to growing far-right extremism within the ranks.[10] The KSK had become partially independent from the chain of command, with a toxic leadership culture. One of the force's four companies where extremism is said to be the most rife was to be dissolved and not replaced.[11]“

https://en.m.wikipedia.org/wiki/Kommando_Spezialkr%C3%A4fte

It’s recommended to have at least two anyway, to still have access to your accounts in case one is lost. That means you can keep one key at your desktop and you’d only need to go up to get your keys when adding them to an account.

I agree that it's annoying that there's now a limit on the amount of credentials you can store on hardware keys. But while older Yubikeys only support 25 resident keys, models with firmware 5.7 onwards support 100. That probably makes it feasible to exclusively store passkeys in hardware. https://www.yubico.com/blog/empowering-enterprise-security-a...

However, I don't know whether it's possible to delete only a single resident key you no longer need.

Just use a password manager that doesn't sync by itself then

https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys

I’m saying most people who do phishing likely don’t care to implement passkey detection to display a relevant error message to the user, as it’s not worth the effort, as of now

There are syncable and hardware-bound passkeys and you are free to use a password manager that syncs your passkeys. iPhones don’t even let you create a passkey with the built in password manager if you have synchronisation disabled. I don’t know for sure if Google does the same but I expect them to.

If you’re remembering all your passwords there’s a good chance they’re terrible, you frequently re-use them or both. That really helps attackers e.g. when they use leaked passwords to run credential stuffing attacks on your employer.

You just wrote two comments bashing a technology you admit you didn’t properly educate yourself about.

Register a passkey on a different device or get a hardware key or whatever. Or call Microsoft support and complain to them. This doesn’t feeling like an honest discussion anymore.

Honestly don’t care to spend time on looking up the various states of 2fa proxies. But I’ve learnt so far that attackers don’t build/use the most advanced tooling you can think of at all times. They often use the simplest thing that gets the job done. If it’s not targeted, it’s fine to not get the credentials of people with a passkey. Up until a significant portion of targets use passkeys, which I highly doubt to be the case as of now.

Additionally, “the kind of person who's prone to non-targeted phishing attacks” is actually everyone — including infosec professionals spending lots of time on phishing campaigns for red team engagements. You just need to be lucky enough to reach them at the right (emotional, stressful, …) moment. Getting grammar and spelling correct and even potentially even slightly customising each email is made much easier by AI. Knowledgeable users might, however, stop once their passkey doesn’t work and try to understand why.

Find your phone: https://www.icloud.com/find/

Scanning a QR code: https://support.apple.com/en-us/102680

The time investment could even be worth it, since "Signing in with a passkey is three times faster than using a traditional password and eight times faster than a password and traditional MFA", according to the article.

> In the case of those services you mention, passkeys are nothing but convenience; they provide no extra security.

They do provide extra security, in that they ensure that you're on the correct domain instead of a phishing site.

That’s for accessing the website, not for sending your traffic via TOR to Mullvad. I don’t think they have a built-in way to send traffic to them via TOR without going through an exit node.

You can also mail them cash