On Wed, Jun 29, 2016 at 02:30:34PM -0700, flux wrote: > My thoughts were more along the lines of mitigative travel protection > crossing borders and such. Like, you can boot to decryption but if the device > is seized, no valid decryption can actually be performed. But as you say, > depending on your situation that could be disadvantageous. I additionally > just enjoy the idea of separating keys from locks regardless of the encrypted > state of those keys.
FWIW, I support this feature request as well. Search the archives for previous discussion early 2015 (Caspar Bowden indicated his support for the feature, before he passed.) Overreliance on a boot nuke feature would, as pointed out, be unwise. But as a journalist, I can easily imagine a scenario where I am crossing a border, am asked/ordered to decrypt my laptop, and I prefer to nuke the hard drive rather than comply. Sure, border officials might image the disk first, but how many laptop users have such a feature? I think of it like TLS. Arguing that X.509 certificate infrastructure is broken and not (very) trustworthy doesn't mean we should insist Qubes return to a non-HTTPS website. It's a layer of protection, one of many. So I support this feature request, while noting the priority is low. jmp -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20160629230142.GA1116%40fedora-21-dvm. For more options, visit https://groups.google.com/d/optout.
