On 11/02/2016 06:38 PM, [email protected] wrote: > [...] >> 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. And that's exactly why they spam their single-sign-on solution everywhere, and that's why I don't like to use it. Otherwise, beyond compromising each and every client computer, I don't see how a big-ass-company could pose the threat you try to shield against.
> [..let's skip the branded identity thing..] >> 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). Still, your threat model has not been fully described. Let me clarify: you are saying "there may exist a site which, compromising my AppVM, gains intelligence on my identity on other sites". Which is a nice assumption, and as me and Simon said, is exactly the meaning of AppVMs: isolating failure. If I'm using a "dangerous" site or clicking a "dangerous" link, I'd better use a different AppVM to make sure that any malware infections I may encounter don't steal any sensitive data. But then you propose to go full-nuclear on this threat model, arguing that "every appvm is compromised" and "every website is malicious", which I think are a little stretched tinfoil-hat assumptions. While your proposal can technically be done, this does not automatically create neither a threat model that fits the defense nor a compelling reason to implement that. Somebody, earlier this year, suggested to encrypt the image file of the virtual hard disks of any AppVM; while this can technically be done, he failed to provide a sound threat model this proposal would shield against, because dom0 cannot be "telepiloted" into doing anything, lacking networking, and having a standalone agent that does that many things, with all the possible variables, is really really hard (and then you have the cheaper thermorectal cryptanalysis). He did not account for increased slowdown, which can already be felt with many AppVMs open without single-machine encryption, and ultimately his proposal did not gain traction. I'd like you to reconsider your submission, better describing the threat model you have in mind, so we (casual readers) can better understand why we should sponsor your proposal. Last, reading your answer to Simon's e-mail, I feel that a reasonable incarnation for your threat model could be aggressive online advertising; and I'm sorry to inform you that your proposal would not protect against that, unless one uses a different TOR circuit for each "dom0 browser tab", since big ad networks already track users without any assumptions on the client, but by approximate ip geolocation, time fingerprinting (both latency and time-of-day), and other techniques that don't necessarily rely on client cooperation. Does your proposal really harden agains a real threat, or is it something that should be done only because it could be done? Btw, thank you for taking the time to write us your proposal and replying to our e-mails. -- 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/5398b074-1ad6-f7da-636c-c6510b2a132c%40gmx.com. For more options, visit https://groups.google.com/d/optout.
