Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
On 08/08/2017 03:59 PM, taii...@gmx.com wrote: > FYI: Having different VM's using the same template doesn't really matter > as they all have the same browser fingerprint. If your primary concern is browser fingerprinting, you should just use Tor Browser. Other browsers don't attempt to hide your browser fingerprint, especially the most fingerprintable part, your IP address. But browser fingerprinting isn't many people's primary concern, I think. I use browsers in separate AppVMs for compartmentalization. So if one browser gets compromised (or if a website uses css tricks to guess my browser history, etc.), the attacker won't be able to obtain any information about what's going on in browsers in other AppVMs. -- 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/f0b802c4-a6d6-4781-f9f6-ec2328778f3b%40micahflee.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
FYI: Having different VM's using the same template doesn't really matter as they all have the same browser fingerprint. -- 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/562a6e9e-1386-8282-8bae-07c955958142%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
On 11/04/2016 10:59 AM, Simon wrote: > Hi Alex, > > Alex wrote : >> On 11/03/2016 11:37 AM, Simon wrote: If you use keepassx you may >> want to use its auto-type feature, which is designed exactly to >> prevent password theft by keylogger-only or clipboard-monitor-only >> malware. Auto type works by typing random parts of the password via >> simulated keystrokes and other parts via copy-and-paste, making the >> life of password stealing malware writers miserable ;) >> > > Do you mean that KeepassX auto-type feature works in a cross-AppVM > way? No, it does not - it works this way by design, which is not specifically made for Qubes but for any windowing gui environment (also windows, osx). So you can use auto-type inside a single AppVM (where you have both keepassx and your browser), but you cannot use it cross-appVM because of Qubes' window content redirection. I don't know exactly how it works on linux, but I think it just sends window messages, so it works on the local X windows inside an AppVM, but it will not automatically do anything qubes-related. > The only way it should be possible would be to store Keepass(X)'s > database alongside with the browser, but in this case I see no > substantial benefits over using the browser's own password management > DB (unless we are talking about an application without similar > feature, like handling SSH password for instance). I do use it for other applications, so I like to have it all centralized and easily portable/syncable without having a bunch of text files. Like I said in an earlier e-mail, I also like the increased practical security with respect to browser-kept credentials - it surely is not much of a protection, since owning the browser you can reach local files/programs, but it just makes this difficult and hardly applicable to everybody. The reasoning is, if you develop an exploit to gather all passwords kept by Firefox or Chrome, it may just be some javascript exploit. If you get to run arbitrary code as the tab user it often gets much more complicated; you are more likely to stop at gathering passwords kept in the internal DB rather than go full-nuclear on trying to access every password keeper that may be installed, in any version that may exist, to convince it in giving you all of the passwords. Database files from password keepers are usually encrypted, so the browser exploit can't just copy any *kdbx file it finds... That's what I mean by saying "it's not secure, it's just much more unlikely as an attack". > [...] > What I'm talking here is about a user-friendly way to open an > untrusted link from a sensitive AppVM into an untrusted AppVM, this > should actually not involve the clipboard at all but be a simple, > classical right-click operation. This indeed seems a nice idea. I can see the problem in implementing that; the interfaces for opening an URL are all but standard, sadly :( something like Android's Intent system, ported to a desktop OS, would provide a single tapping point to intercept the action (and, in our case, ask the user "do you want to open that in a dispVM?") > I do not think there is really any risk of wrong manipulation here: > personally I do not remember having mistakenly right-clicked on a > file and opened it in a disposable VM or sent it to another VM when I > just wanted to open it locally using a simple left-click. I agree. >>> One should not do any change to their Whonix AppVM, so everyone >>> uses the same, and an app running in the AppVM, no matter how >>> malicious it is, cannot access anything outside of the AppVm >>> without having to break Xen isolation first and cannot apply any >>> modification of it which will survive an AppVM restart. >>> >>> So I'm quite confident that there is no easy way to remotely >>> distinguish two Whonix AppVM instances or identify one. >> Which is nice, if your threat model is trying to identify the AppVM >> and not the user behind it - which is usually false. >> >> While identification of the client device is one of the way of >> identifying people it's not the only way, and usually the goal is >> not the identification of the client device itself. For an easy >> example, that's why spies in hollywood movies connect to the net >> from public WiFi hotspots, hotels, airports, but not from home. > > From my understanding, there is actually two level of correlation > when you want to convict someone: > > 1) You demonstrate that it was the same machine which was used for > all incriminated actions. 2) You demonstrate the link between the > suspect and the machine. > > In your statement, for n incriminated actions, you would need to > demonstrate n times the involvement of the suspect which can be very > hard, if not impossible. > > It is far easier to demonstrate that the same computer has been used > for all of the n incriminated actions (either actively by putting > some tracking bug on it or passively by correlating various > information for instance), no matt
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
Hi Alex, Alex wrote : On 11/03/2016 11:37 AM, Simon wrote: If you use keepassx you may want to use its auto-type feature, which is designed exactly to prevent password theft by keylogger-only or clipboard-monitor-only malware. Auto type works by typing random parts of the password via simulated keystrokes and other parts via copy-and-paste, making the life of password stealing malware writers miserable ;) Do you mean that KeepassX auto-type feature works in a cross-AppVM way? In one dedicated, networkless AppVM I have Keepass (sadly started some time ago with the new DB version which, AFAIK, is still not supported by KeepassX :( ), in another network-enabled AppVM I have the browser (or any other software for that matters). As per my understanding there is no way for the Keepass(X) software to emulate keystrokes on the browser's interface, unless I missed something very important in Qubes' architecture. The only way it should be possible would be to store Keepass(X)'s database alongside with the browser, but in this case I see no substantial benefits over using the browser's own password management DB (unless we are talking about an application without similar feature, like handling SSH password for instance). Besides it is incredibly annoying to operate this way. I am not some prime target of the NSA ^^, and I doubt many of the people using qubes will be... So you want to be safe, but you still want the convenience... The right way is to block the link, unless it refers to a white-listed domain for this identity. No, the right way is to propose people an option in the browser's right-click menu offering them to open this link in an untrusted VM (similar to the "Send to another VM" or "Open in a disposable VM" option in the file manager). I agree with you that, IMHO, the right-click followed by 'A', Ctrl+Shift+C, Alt-tab, Ctrl+T, Ctrl+Shift+V, Ctrl+V and finally Enter "shortcut" sequence to achieve the same task currently could and should be improved in terms of usability for Qubes to reach a wider audience. But I do like the fact that I have to make so many mistakes in order to copy my data from the "pr0n" VM to the "work-boss" VM... But if I have to copy a pr0n link from a 4chan greentext to another pr0n tab I only have to ctrl+c / ctrl+v like I used to do with plain fedora. I'd strongly disagree with any simplification of inter-vm generic clipboard sharing. I'd agree with some easier facilities for centralized (trusted, without networking) PasswordDatabaseVM. But I'll doubt I'll be using it; I like to keep a "porn" keepass database on the porn VM, many work keepassx db on their respective VM, and so on, to further avoid having a simple "autotype" open the wrong URL. I'm not talking about clipboard sharing by itself, which I also consider to be good as it is now (unless maybe the minor fact that it overwrites the default common shortcut to paste something in a terminal, but that's really not big deal). What I'm talking here is about a user-friendly way to open an untrusted link from a sensitive AppVM into an untrusted AppVM, this should actually not involve the clipboard at all but be a simple, classical right-click operation. I do not think there is really any risk of wrong manipulation here: personally I do not remember having mistakenly right-clicked on a file and opened it in a disposable VM or sent it to another VM when I just wanted to open it locally using a simple left-click. The only real risk of wrong manipulation is to directly open the untrusted link in the sensitive VM. The current situation does not help against that, actually it even encourage to do such wrong practice by making it more difficult to open a link in a different AppVM. I do use i3wm as my window manager, and have only 1 monitor with the vertical-split layout; all the others are tabbed, and it works great. It may well emulate the concept of "dom0 browser". Thank you for this confirmation. I never used such windows manager myself, but this was indeed my assumption. I hope Mara will have the opportunity to check this :) ! One should not do any change to their Whonix AppVM, so everyone uses the same, and an app running in the AppVM, no matter how malicious it is, cannot access anything outside of the AppVm without having to break Xen isolation first and cannot apply any modification of it which will survive an AppVM restart. So I'm quite confident that there is no easy way to remotely distinguish two Whonix AppVM instances or identify one. Which is nice, if your threat model is trying to identify the AppVM and not the user behind it - which is usually false. While identification of the client device is one of the way of identifying people it's not the only way, and usually the goal is not the identification of the client device itself. For an easy example, that's why spies in hollywood movies connect to the net from public WiFi hotspots, hotels, airp
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
On 11/03/2016 11:37 AM, Simon wrote: >> I am using UNIX pass, but it has the same flaw. If you copy passwords >> this way they won't automatically get purged from the AppVM, which >> under the assumption that any AppVM is completely compromised at all >> times, is not much of a big deal, but still it would be nicer if the >> password was cleared or even better never copied to the clipboard... > > I think this may be a good point, maybe not of the highest priority > compared to other Qubes issues, but nevertheless a good point even if > from my point of view this could completely uncorrelated from your > tabbed AppVM idea. > > What I understand from your sentence would be a feature like a keyboard > shortcut which, instead of putting the content of the global clipboard > into the AppVM clipboard as Ctrl+Shift-V currently does, would instead > simulate the keystrokes corresponding to the current global clipboard > content (a kind of macro). If you use keepassx you may want to use its auto-type feature, which is designed exactly to prevent password theft by keylogger-only or clipboard-monitor-only malware. Auto type works by typing random parts of the password via simulated keystrokes and other parts via copy-and-paste, making the life of password stealing malware writers miserable ;) > >> Besides it is incredibly annoying to operate this way. I am not >> some prime target of the NSA ^^, and I doubt many of the people using >> qubes will be... So you want to be safe, but you still want the >> convenience... The right way is to block the link, unless it refers to >> a white-listed domain for this identity. > > No, the right way is to propose people an option in the browser's > right-click menu offering them to open this link in an untrusted VM > (similar to the "Send to another VM" or "Open in a disposable VM" option > in the file manager). > > I agree with you that, IMHO, the right-click followed by 'A', > Ctrl+Shift+C, Alt-tab, Ctrl+T, Ctrl+Shift+V, Ctrl+V and finally Enter > "shortcut" sequence to achieve the same task currently could and should > be improved in terms of usability for Qubes to reach a wider audience. > But I do like the fact that I have to make so many mistakes in order to copy my data from the "pr0n" VM to the "work-boss" VM... But if I have to copy a pr0n link from a 4chan greentext to another pr0n tab I only have to ctrl+c / ctrl+v like I used to do with plain fedora. I'd strongly disagree with any simplification of inter-vm generic clipboard sharing. I'd agree with some easier facilities for centralized (trusted, without networking) PasswordDatabaseVM. But I'll doubt I'll be using it; I like to keep a "porn" keepass database on the porn VM, many work keepassx db on their respective VM, and so on, to further avoid having a simple "autotype" open the wrong URL. >> The advantage is the same as going back to IE6 times when each tab was >> its own window and having windows with several tabs in addition to >> this madness. I don't see how you can not see the advantage of having >> all browser tabs over all AppVMs organized in a dom0 browser interface >> as tabs in comparison to having tons of floating windows with sub-tabs >> each ;). > > I suppose everyone have their own taste ;). Personally, I prefer to have > windows belonging to different sensitivity levels to be clearly > separated from one another. > > Have you looked toward tabbed windows managers? I do not know if there > is anything which would suit your needs, but their idea as per my > understanding is to handle several windows as tabs. This would however > put two tabs layer instead of one. I do use i3wm as my window manager, and have only 1 monitor with the vertical-split layout; all the others are tabbed, and it works great. It may well emulate the concept of "dom0 browser". >> Are you so sure that your AppVM doesn't have an unique fingerprint >> that potentially could be exposed via a malicious website, browser >> extension or the browser? > > One should not do any change to their Whonix AppVM, so everyone uses the > same, and an app running in the AppVM, no matter how malicious it is, > cannot access anything outside of the AppVm without having to break Xen > isolation first and cannot apply any modification of it which will > survive an AppVM restart. > > So I'm quite confident that there is no easy way to remotely distinguish > two Whonix AppVM instances or identify one. Which is nice, if your threat model is trying to identify the AppVM and not the user behind it - which is usually false. While identification of the client device is one of the way of identifying people it's not the only way, and usually the goal is not the identification of the client device itself. For an easy example, that's why spies in hollywood movies connect to the net from public WiFi hotspots, hotels, airports, but not from home. As I stated in other messages, it's deceptively easy to get carried on to pure paranoia. Model your threat
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
Hi Mara, mara.kuens...@gmail.com wrote : Which is why my idea would be to host Mozilla Sync Service in each App You can already do such thing, the main point being to have each of your Firefox instances to either point to different Sync services or share the same service but use different credential. This way, you can ultimately prevent Firefox from having to store anything locally : Firefox data goes to Sync, downloads you would like to keep goes in your network-less storage AppVM, and everything in the browsing AppVM gets wiped at each AppVM restart. The only limitation for now, as I said in my previous email, is I don't know a way to set an AppVM to use a volatile storage on a day-to-day basis to enforce no modification to remain persistent between AppVM restart except those explicitly allowed through Firefox Sync (and a manual setting when one explicitly needs to modify it: update the add-ons, save a new browser setting, etc.). Using environments as much stateless as possible seems to be one of the goal pursued by Qubes team if I understand their research documents correctly, so even if it not possible right now (unless someone say it is?) I guess sooner or later it will be. I am using UNIX pass, but it has the same flaw. If you copy passwords this way they won't automatically get purged from the AppVM, which under the assumption that any AppVM is completely compromised at all times, is not much of a big deal, but still it would be nicer if the password was cleared or even better never copied to the clipboard... I think this may be a good point, maybe not of the highest priority compared to other Qubes issues, but nevertheless a good point even if from my point of view this could completely uncorrelated from your tabbed AppVM idea. What I understand from your sentence would be a feature like a keyboard shortcut which, instead of putting the content of the global clipboard into the AppVM clipboard as Ctrl+Shift-V currently does, would instead simulate the keystrokes corresponding to the current global clipboard content (a kind of macro). Besides it is incredibly annoying to operate this way. I am not some prime target of the NSA ^^, and I doubt many of the people using qubes will be... So you want to be safe, but you still want the convenience... The right way is to block the link, unless it refers to a white-listed domain for this identity. No, the right way is to propose people an option in the browser's right-click menu offering them to open this link in an untrusted VM (similar to the "Send to another VM" or "Open in a disposable VM" option in the file manager). I agree with you that, IMHO, the right-click followed by 'A', Ctrl+Shift+C, Alt-tab, Ctrl+T, Ctrl+Shift+V, Ctrl+V and finally Enter "shortcut" sequence to achieve the same task currently could and should be improved in terms of usability for Qubes to reach a wider audience. Thanks for uMatrix, I didn't know that one. But yes this is pretty much what I imagined also to happen, just in dom0 (which is more trustworthy to me), not in an AppVM. If you would like to filter URLs accessed by a browser without trusting neither the browser nor its AppVM, you may want to setup some web proxy VM between your AppVM and the Firewall VM. The same way the Firewall VM is configurable from Dom0, you could imagine that the proxy could be configurable too to define a per-AppVM white and black lists. The advantage is the same as going back to IE6 times when each tab was its own window and having windows with several tabs in addition to this madness. I don't see how you can not see the advantage of having all browser tabs over all AppVMs organized in a dom0 browser interface as tabs in comparison to having tons of floating windows with sub-tabs each ;). I suppose everyone have their own taste ;). Personally, I prefer to have windows belonging to different sensitivity levels to be clearly separated from one another. Have you looked toward tabbed windows managers? I do not know if there is anything which would suit your needs, but their idea as per my understanding is to handle several windows as tabs. This would however put two tabs layer instead of one. To be able to get one single layer of tabs, you would need to have the browser itself and its rendering engine clearly separated, so you can have the browser (with no Internet access) running in Dom0 handling different rendering engine for each tabs, each being able to run in the same or different tabs (the tab color would then help to distinguish among the AppVM as windows border colors currently do). Chrome used to rely on individual processes for each tab for a long time now, AFAIK it is still an ongoing work on Firefox due to its history (addon compatibility was a great issue). Nevertheless, even with this basis in place I suspect this would still require a huge amount of work to get such tight integration correctly done.
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
On 11/02/2016 01:38 PM, mara.kuens...@gmail.com wrote: 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. On this point, the fact that you are entering your username+password on the website (because the "wrong" VM you're using doesn't have that cookie/ID on file) should be a strong cue that you may be in the wrong VM. Plus, Qubes is constantly displaying the VM name at the top of the window... you should be checking it whenever you start a new activity. OTOH, robust whitelisting (taking third-party sites into account) in general would be a nice feature to have. But I'm thinking this needs to be a browser-level feature, not OS-level, because the problem is mostly specific to web browsing. Chris -- 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/18bae3eb-1839-0454-5c44-cc83a8bfced7%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
> 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. Well honestly "proposal" is probably too much credit for the time I spent on it so far and I mainly wanted to probe for the idea more. I think I am going to write a true proposal that can actually be reviewed and your input definitely helps to guide that effort, which is also why I asked that question in the first place. And I am not actually sure I will address a threat model, since it doesn't really do more than you can do manually. It is really more about regaining the convenience while maximizing the additional privacy and security Qubes OS technically provides, you see... But I agree that it is required to be much more specific and clear but I can't do that so quickly in a mail, so I will take this conversation and address the issues raised in a more structured manner ^^. Thanks & 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/4c300108-99c2-46db-b68d-981ce97cea1b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
On 11/02/2016 06:38 PM, mara.kuens...@gmail.com 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 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/5398b074-1ad6-f7da-636c-c6510b2a132c%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
Hi Simon, > several AppVMs, each one dedicated to a different activity, or as I > prefer to refer it myself: to different sensitivity levels. See my reply to Alex, maybe that explains why this is exactly what I was talking about ;). > - You may have a dedicated Firefox instance still having the infamous > Flash plugin installed when you need to access some websites requiring Yes but this could and would be all included in this dom0 browser interface. > - Use (X)KeePass in a separated, isolated and dedicated AppVM. I suggest > you to create a "Web" or "Firefox" group, and then create a different I am using UNIX pass, but it has the same flaw. If you copy passwords this way they won't automatically get purged from the AppVM, which under the assumption that any AppVM is completely compromised at all times, is not much of a big deal, but still it would be nicer if the password was cleared or even better never copied to the clipboard... Which is why my idea would be to host Mozilla Sync Service in each AppVM and the let the dom0 browser fill this Sync Server with the passwords belonging to the corresponding identity... > website: you will *not* open this link in the same AppVM but instead > copy/paste it in your "Random surf" AppVM. Would this site be malicious Yes but people WILL click the link. It's not a sane assumption to make. Besides it is incredibly annoying to operate this way. I am not some prime target of the NSA ^^, and I doubt many of the people using qubes will be... So you want to be safe, but you still want the convenience... The right way is to block the link, unless it refers to a white-listed domain for this identity. Or even better, pipe it back to dom0 and open it in a new tab & AppVM under the right identity... (this kind of integration is what I am proposing) > password database is to first hack the forum, and use it as a pivot to > then be able to hack your computer and get access to your file system. How he does it is basically immaterial to me as I assume that all AppVMs are evil all the time. The point is to separate them properly so only one identity gets compromised. I want to add that it is generally unlikely that a disposable AppVM with the right configuration will actually be compromised, but it helps to assume them to be to get a better picture of the impact it would have and to minimize that impact. > (https://addons.mozilla.org/en-US/firefox/addon/secure-login/) so > Firefox does not dumbly automatically fill any password field without Yes this looks good. > like uMatrix or NoScript which allow to better control third-party Thanks for uMatrix, I didn't know that one. But yes this is pretty much what I imagined also to happen, just in dom0 (which is more trustworthy to me), not in an AppVM. > It *may* be possible to implement a way to handle different AppVM in > different tabs instead of different windows, but I'm not sure to see any > real advantage of this. The advantage is the same as going back to IE6 times when each tab was its own window and having windows with several tabs in addition to this madness. I don't see how you can not see the advantage of having all browser tabs over all AppVMs organized in a dom0 browser interface as tabs in comparison to having tons of floating windows with sub-tabs each ;). > instance, personally I set it to not display reduced windows in the > Alt-Tab menu, so I can focus on the window I am currently working with. I don't think any of those suggestions really helps with the problem. All in all I think Qubes OS in general lacks a good UI for what it is doing, but I also understand that you have to start somewhere. But in the end the way Qubes does AppVM and identity management at the moment is truly terrible, but it works. All I want to do is to come up with a plan to improve it ^^. > be useful to have them volatile on a day-to-day basis, and turn them > non-volatile only to update Firefox's modules or save a change in its I think the Mozilla Sync Server could be of help here... > To be honest I did never investigated this, I'm not sure what the > concrete threats there are. Are you so sure that your AppVM doesn't have an unique fingerprint that potentially could be exposed via a malicious website, browser extension or the browser? In that case, even using the same base template for disposable VMs could be a privacy disaster (I am not sure Qubes OS has taken any steps, like maybe "Tails", to actually mitigate fingerprinting in disposable VMs) On top of that have you ever tried to use Panopticlick? Even tails gets more or less uniquely fingerprinted primarily via the non-standard browser window size when it is maximized and also because it seems to apply some uncommon browser settings that maybe only tail users have... > UUID you really should just use the same UUID as a lot of other people That requires you to know the UUID, also UUID was more a token for "fi
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
> 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.
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
mara.kuens...@gmail.com wrote: 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 [...] I think what would solve this dilemma is a custom dom0 browser layer. The way this can work is as follows: Hi Mara, While I agree with you on your assumptions, I completely disagree on your conclusion. What should actually solve this dilemma is to use several AppVMs, each one dedicated to a different activity, or as I prefer to refer it myself: to different sensitivity levels. This way indeed, you can consider that a website at some sensitivity level may have access to full information belonging to this same sensitivity level, but if you design this correctly this should not be a major issue. So, first make a list of your different on-line activities and the sensitivity of information stored / transmitted in each cases (if you need some ideas, there was a very interesting article from Joanna describing the process: you should quickly find and recognize it thanks to the spaghetti-like diagram it contains ;) ). Then, you may want to apply different setups to Firefox depending on the needs and the trust level. For instance: - You may want to apply maximum paranoia on your random surf AppVM, - You may want to be a bit more permissive in your shopping AppVM so NoScript will not break a payment process right in the middle, leaving you uncertain about how many times you will be charged. - You may have a dedicated Firefox instance still having the infamous Flash plugin installed when you need to access some websites requiring it. - Etc. Decide how you may want to store your logins and passwords. Here are two possible solutions, but there are other ones of course: - Use (X)KeePass in a separated, isolated and dedicated AppVM. I suggest you to create a "Web" or "Firefox" group, and then create a different sub-group for each of you AppVM so everything stays clean and organized. - Use Firefox integrated password management. Before you scream, do not forget that all activity in this Firefox will be limited to the same sensitivity level. For instance, you are in your "Public forums" AppVM, someone posts a link to a third-party website: you will *not* open this link in the same AppVM but instead copy/paste it in your "Random surf" AppVM. Would this site be malicious and steal your password database, it would miserably fail (without mentioning Firefox "paranoid" settings in this AppVM). The only way for someone to actually gets its hand on your Firefox password database is to first hack the forum, and use it as a pivot to then be able to hack your computer and get access to your file system. At this point, installing a keylogger or a malicious Firefox extension becomes just trivial, so avoiding to use Firefox password store will be of no help and if you design your AppVMs correctly then all the efforts deployed by the attacker will be done quite in vain since he will not actually gain any new valuable information. If you use Firefox password management, I would however still recommend you to use the Secure Login extension (https://addons.mozilla.org/en-US/firefox/addon/secure-login/) so Firefox does not dumbly automatically fill any password field without requiring any human intervention (I find it a shame it still acts this way by default): this prevents you against online stealing of your password store content and require the attacker to either exploit the browser or get his hands on your file system. The two are not exclusive. Actually, if you use Firefox password store (and I find it really more convenient than doing a dozen Ctrl-Shift thing each morning just to identify myself on random public websites, but YMMV), I would strongly recommend to keep at least a backup of these passwords in some password safe like (X)KeePass. There are still a some other points you mention in your bullets I did not addressed until now: * Trying to visit a non-white-listed website Basically, you are responsible of what you do with your own computer. There are several Firefox modules (plus Qubes' firewall) which should help you to ensure that you do not use an AppVM from a certain sensitivity level to access websites belonging to other ones. Modules like uMatrix or NoScript which allow to better control third-party requests seem like a must here. * You always use a new VM for each tab It *may* be possible to implement a way to handle different AppVM in different tabs instead of different windows, but I'm not sure to see any real advantage of this. If you have too many windows opened (which indeed happens very quickly with Qubes), do not hesitate to use your windows manager feature to handle them: - Assign specific activities to your workspaces (or de
Re: [qubes-users] Special (Secure) Browser Frontend for Qubes?!
On 11/01/2016 11:02 PM, mara.kuens...@gmail.com 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 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/60dabd54-6ffa-ca65-256f-a1e1a7c44a33%40gmx.com. For more options, visit https://groups.google.com/d/optout.
