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 threats before shopping for the right tinfoil hat. > > Panopticlick and online-activities tracking is yet another wide subject. > I invite you to check the answer I wrote there on this subject: > https://security.stackexchange.com/a/138525/32746 Thank you for the link, it's been an interesting reading. And it happens that my browser from this AppVM I'm replying from is unique among the ~170K browsers panopticlick has ever tested. Yay! From what I can see, WebGL + canvas + fonts are the main conveyors of uniqueness bits, but I cannot easily disable them without severely compromising my browsing experience. So let me sum this thread up: I'd have to severely cripple my browsing experience to hide from some unspecified tracking but then I'd love to simplify the UI around the browser, thus paving the way for more inter-vm mistakes... Mmm I think I'll pass :D -- 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/18e5c764-11c3-5068-671a-6027ac3b60d1%40gmx.com. For more options, visit https://groups.google.com/d/optout.
