saljam

the reason i use this (and just a container with -v $HOME:$HOME before) is to get an environment with all the command line tools i'm familiar with from debian, instead of using something like homebrew. in general, i mostly trust these with access to my home directory. a bonus is that i can throw it away and rebuild it easily if i need to.

i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.

the arabic writing is also crazy, so i have no idea what author was going for.

have you actually looked at the map?

there a whole inset panel for israel, and not a single mention of palestine.

i used to slip mine in a manilla envelope whenever i needed to take it home from the office and i hadn't brought my backpack with me. our stationary cupboard was well stocked with these!

i mainly use apple devices, but never put anything on icloud before adp came out.

yes of course - but in this case the "unexpected" prompt is presented to the attacker, not the user.

> You can mitigate this by including PCRs that sign the kernel and initrd

nope! the trick the article is describing works even if the kernel and initrd is measured. it uses the same kernel, initrd, and command line.

the reason this trick works is that initrds usually fall back to password unlock if the key from the tpm doesn't work. so the hack replaces the encrypted volume, not the kernel, with a compromised one. that is:

1. (temporarily) replace encrypted volume with our own, encrypted with a known password.

2. boot the device.

3. the automated tpm unlock fails, prompting for a password.

4. type in our password. now we're in, using the original kernel and initrd, but it's our special filesystem, not the one we're trying to decrypt.

5. ask the tpm again for the key. since we're still using the original kernel, initrd, and command line, we should now get the key to unlock the original encrypted volume.

the way to fix this is to somehow also measure encrypted volume itself. the article points to suggestions of deriving a value from the encryption key.

I developed it mainly on Firefox on macOS. I'd love to figure out why it didn't work for you. Do you get anything on about:webrtc while trying to connect?

The QR code is generated client side.

The website uses Google's.

On command line it's an option and Google's is default. I'd like to make the signalling server also a STUN server at some point.