> And that's why you can use many appVMs in the first place. You share the
But that is not the point. First of all, unless your life depends on it, it will be very unlikely that you are actually paying enough attention to where you use which identity. A click on the wrong link can already screw it up because then site X read the tracking data placed on site Y and site X shouldn't know about what you were doing with Y... So you need some sort of white-listing to technically prevent those mistakes. Yes this can be done in different AppVMs and that is exactly what I am proposing here. It's about making what you describe much more convenient without a single drawback in security. > 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) Um, that is a bold statement, do you have any data to back that up? Maybe Amazon indeed doesn't talk to Facebook (yet), but no one is stopping them either. Facebook definitely has an interest to read your Amazon visits because this way they can link your true identity to your fake profile... for instance. > are, in fact, the very same entity (fb and whatsapp, gmail and youtube). True, and for those you will want to use the same identity (it get's complicated quite quickly which is why I am proposing to aid the user with this chore). > 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. Maybe, but here we have the same issue again. I have other things in my head than trying to remember which sites shares what data with whom and which idenity I have to use where and which AppVM to start for it, it's just insane... This needs to be much simpler. > 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. I think you entirely misunderstand my proposal or maybe I wasn't clear enough. My proposed "dom0" browser has no network at all. In fact, it can't do anything you couldn't do manually already. The point is to automate it. This dom0 browser frontend will know which identity belongs to which domain and which AppVM should be used for each identity and what your passwords & cookies were. It also feeds this data to each AppVm on startup so they can completely be disposable... The "real" browsers still run in AppVMs. > 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 What do you mean by "co-exist"? If I use them at the same time in the same browser/VM I might as well just use one single identity because there is no way to know if either of them wasn't compromised or linked in ways I didn't want. I don't see how identities can co-exist (I am also not talking about sign-in data, I am talking about fake "me"'s, fake people so to speak who consume services to protect the real identity; I simply see no use case of why you ever want to share identities within the same AppVM or browser/site). > really need that many isolated VMs? third, why would you need to move > this complexity in dom0? Because dom0 is the only place where this can meaningfully exist. Think of it as a different way of organizing the AppVM windows (not in the XCFE panel's, but instead as real tabs in a dom0 browser) and a lot of infrastructure code to help you with identity management. Cheers -- 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/1f43fe6b-39dc-4898-ba5b-b066c4e1be84%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
