On 11/01/2016 11:02 PM, [email protected] wrote: > Hi, > > I am using Qubes daily for a while now. One thing I think is really > missing is some sort of identity management. This is most visible > when browsing. You shop something on Amazon, then go to check some > Facebook updates and look at WhatsApp. Then you browse Hacker News > click on this link and that link, end up on Wikileaks by accident > then look at which club to visit in the evening... Yes this is shit. > And that's why you can use many appVMs in the first place. You share the same identity on the same AppVM, and then you can create another in another AppVM. If the identity can be discarded safely, then you can use a DispVM.
There's little actual reason to use a hard-separate identity for each and every web service you visit; first because they don't usually talk to one another (i.e. amazon does not ask facebook for your info, nor does this happen the other way around) and second because many of them are, in fact, the very same entity (fb and whatsapp, gmail and youtube). Third because you usually want to present a "brand" identity of yourself around the web. Think of your personal blog or github account presented on your linkedin profile: this is a reinforcement of your "brand" identity, so you would like to share the connection between your github and your linkedin identities. > But convenience often wins over security/privacy. Not only do you > have to assume that all sites you visit within the same VM knows > everything you did in there, but also you have to assume they know > all the passwords for all the other sites you visit there and > basically have full control over that VM. If you don't assume that, > then why are you using Qubes in the first place... And that's why you should disable keeping passwords in-browser and use something like keepassx. Using it moves the security bar from 2 to 3 on a scale to 10... It's better than nothing, and you can have a separate keepassx AppVM for extremely sensitive passwords (and extremely frustrating user experience, but still..). > > I think what would solve this dilemma is a custom dom0 browser layer. > The way this can work is as follows: And that's actually the point why I'm replying to your e-mail; this is an idea as bad as it gets. The main reason why dom0 does not have networking, and should not have, is to prevent exposing data on *all* of the VM at once. As a side effect of this, the less software there is on dom0 the better. Your proposal flies straight in the face of this architectural principle. While I agree that your proposal makes sense from a user-experience point of view, I solved my multiple-identity problem simply with many appVM, that share some identities that can be shared together - say, the 5 e-mail accounts I have to use for work. TL;DR: first, do you really actually need to separate each and every identity you use? second, once you realize that many identities can co-exist (and indeed, sometimes you would like this to happen) do you really need that many isolated VMs? third, why would you need to move this complexity in dom0? -- Alex -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/60dabd54-6ffa-ca65-256f-a1e1a7c44a33%40gmx.com. For more options, visit https://groups.google.com/d/optout.
