nickzana

I believe this is a vulnerability that occurs when copying data from dom0, which is a more common task. Generally the Qubes model recommends copying data from more trusted VMs to less trusted VMs, and dom0 still runs some system-wide processes in many default configurations.

For example when you take a screenshot with xfce4-screenshooter, the file is saved to dom0, and you have to use qvm-copy-to-vm to move it to a (less trusted) qube to do something with it. That's the most frequent use case, at least for me.

I haven't tried OpenClaw, but I gave Claude Code an account on my Forgejo instance. I found issues and PRs to be a very good level of abstraction for interfacing with the new agent teams feature, as well as bringing the "anytime, anywhere, low activation energy" benefits this article talks about.

I let it run in a VM on my desktop and I can check on its progress and provide feedback any time. Only took a few iterations of telling it to tweak its workflow to land on something very productive. Doesn't work for everything but it covers a lot of my work.

Passkeys do have a (partial) solution to this problem: multi-device credentials. See the videos at the bottom of [1].

Say you install an app/visit a website on your phone and register an account with a passkey. My current understanding is that on iOS 16, the passkey lives in your iCloud keychain. If you want to sign in on a Mac on Safari, you can just visit the website and the discoverable credential from your phone will appear when you try to log into the site with webauthn. The website will be able to tell that you're logging in from a new device and optionally require additional authentication.

If you want to sign in on a device that doesn't have access to your keychain, you can use your phone as an authenticator over a combination of Bluetooth and a tunnel server by scanning a QR code on that device with your phone. The site is then supposed to prompt you to register the new device with whatever its local passkey solution is.

The best source I could find for how this protocol works at a technical level is an episode of "Security. Cryptography. Whatever" on passkeys. I guess the specs aren't exactly public yet (at least since I last checked) and are only available to fido alliance members.

I've been trying to work on figuring out ways to build a "passkey manager" of sorts to live up to the potential webauthn offers with hardware-backed credentials that are also synced and backed up (to an offsite key). As far as I can tell, as mentioned in another comment, this just doesn't seem to be a priority for the fido alliance, which is a real shame.

I'm cautiously waiting to see how 1Password deals with passkeys, given that they're one of the few FIDO members with a vested interest in being cross platform, but I'm betting they'll just implement a software keystore built into their current vaults without any hardware backing.

[1] https://fidoalliance.org/multi-device-fido-credentials/

That's essentially what passkeys are: a consumer-friendly name for on-device FIDO keys you can use over webauthn, along with (in the apple/google/Microsoft case) a mechanism for syncing/backup/recovery provided by your platform account provider. The keys are still backed by hardware, but instead of an external key it uses the internal platform security module (TPM, Secure Enclave, etc.)

You can use your phone without the syncing part to authenticate other device through a mix of a QR code, a tunnel server, and Bluetooth.

Nebula has also recently started selling skillshare/masterclass-esque classes in addition to the main video platform product. Many (maybe all???) are taught by existing Nebula creators.

The classes are advertised on the Nebula homepage to subscribers, but require additional payment.

Isn't it better to leave them exposed and make it easier for security researchers who genuinely want to test the chip? Someone interested in and capable of developing and using/selling an exploit won't be deterred by needing a special cable to get a UART console, whereas a security researcher might appreciate the simpler access.

So long as it doesn't weaken the actual security model, companies should make their products as easy to analyze as possible imo.

Google Pixels generally have the best support for alternate OSes, especially from a security POV. See CalyxOS and GrapheneOS, which primarily/only support Pixels thanks to their ability to re-lock the bootloader.

I doubt third party Android distributions pose any real threat to Google given that 99% of people will stick to the default.