>usability is not a good reason to add or change anything. I suggest you switch to running Lynx on OpenBSD then. I guarantee you're running all kinds of horribly insecure stuff on whatever you're using to read this right now.
Usability has always been a top priority in Qubes and that is a major part of why it is such an excellent operating system. Why on Earth do you think they bothered making a GUI tool? Why don't they require a password for sudo? (Newcomers: that last one was a rhetorical question that I've already analyzed at length; please see older messages om this thread.) >Yes i'm a noob, but you still sound like a security nightmare to me. Security isn't a gut feeling thing. At least, not in the way you're doing it. Your gut needs to know what it's talking about first. > You lost me way earlier when you mentioned browser extensions Exactly my point. You don't understand at all what the purpose of the browser extension is. All it does is generate a token that Dom0 uses to look up something in its index. If you can't follow me trying to explain what the extension does (it generates a token of about 3 characters according to a specific set of rules, and appends them to the page title. That's it!), let me try instead to explain what it DOESN'T do: A. The extension would have no way of knowing if the Dom0 code was actually doing anything with a particular token. It wouldn't know if the Dom0 code was running. It wouldn't know whether or not the Dom0 tool was even installed. B. As per the above, it would receive no feedback or input from Dom0. C. It wouldn't be involved at all in handling the username / password (although I guess someone could write another extension to automate that as well. But this probably wouldn't be high on my list of priorities.) D. At no point would the extension cause any data whatsoever to be written to any files in Dom0 except perhaps in the form of a logfile (which the extension itself isn't aware of or capable of accessing.) E. At no point is the extension concerned with the keypress that activates the tool. It doesn't know or care when or how any of that stuff happens. It keeps providing index tokens all day long even if the password key combo is never pressed. F. It would be entirely optional. The password tool could function just fine without it, but would be vulnerable to a title spoofing attack (not as dire a threat as M. Ouellet thinks, but it's there) and it would require a bit more effort to set up your password list on Dom0 and keeping it running smoothly. G. The extension should be thought of as an *extra layer of armor*, not an extra point of failure in this setup. If someone exploits a bug that causes the extension to crash or behave erratically, the tool on Dom0 immediately stops providing passwords. It *can't* provide any passwords if it's been set up to use the tokens but they aren't being provided. H. Building on G, if someone manages to compromise your entire web browser such that they can either disable the extension (or control it) AND they can read your randomly generated salt... then yes, they could intercept your passwords on that VM. And this is what they could do in any other situation involving a catastrophic browser takeover. But you're better off in this situation vs. using the browser's built-in password manager, even an encrypted one. Vs. manually copy and pasting passwords from an offline VM, and it's roughly the same situation. I. Mistakes and misconfiguration should just result in nothing at all happening. Pressing the activation key for the tool while you're on the wrong site results in nothing happening except perhaps an error popup (that is handled by the Dom0 tool, not the extension.) > If my Mother can handle ctrl shift c, I'm sure you can too. This is akin to telling Joanna that your mother can handle running 5 different VMs in Virtualbox, so she can too--crazy window mixing from different VMs? OMG! That's a security nightmare! You've no idea what you're talking about, and Ouellet refuses to consider the version with an extension because he knows there is no plausible security hole. He doesn't like it because it's messy, and I agree, but open source software has rarely been driven forward by anything but people giving in and hacking together something kinda messy. Messy doesn't mean full of security holes, it just means... messy. And if you're telling me you use manual copy/pasting for everything, and you don't use persistent cookies, and you use a DispVM[1] for everything that requires a login, and you don't use a password manager, AND you have strong randomized passwords for everything, AND you have more than a couple dozen accounts, AND that you use your computer heavily, with a decent amount of DispVM restarts throughout the day... Well, I don't believe you. Nobody who tried use to do it all manually, with heavy usage over a prolonged period of time, could possibly think that copy/paste is sufficient. It's not even secure! Do it fast enough over a long enough period of time and you'll eventually slip up and paste the password somewhere it shouldn't be. That's the real irony here. Ergonomics count. You're supporting an approach that is, in the real world, less secure. Shane 1. Well neither do I at the moment; we really need multiple customizable DispVMs. -- 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/d2299fbc-0f80-4efb-a308-46d1c4b49373%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
