Hi Mara,
[email protected] 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.
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 ^^.
I agree with you, for now I consider Qubes to be really in its infancy
so I do not expect it to offer the same level of sophistication than
more mature Linux distributions do.
Qubes goal is security, and in this domain it offers unique features
that those more mature ditros cannot offer, the rest will most certainly
come in its own time, I'm confident about this :)!
As for plans, I'm not involved in devs but there are some publicly
available information, like:
- Qubes OS usability and UX: https://www.qubes-os.org/doc/usability-ux/
- Qubes OS high-level roadmap:
https://github.com/rootkovska/qubes-roadmap
Qubes developers are not sleeping or wondering what to do ;), even if I
guess that new ideas and suggestions are always welcome.
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.
This does not apply however for other AppVMs, where if I'm not wrong
Firefox add-ons for instance gets assigned random UID upon installation.
Those IDs would allow to distinguish two otherwise identical AppVM, or
link two different AppVM running the same template. However the attacker
must have access to the file-system since, AFAIK, those ID are not
normally available to web pages scripts.
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
Be aware however that if you modify the Firefox bundled in your Tails
distro, it will then not be 100% identical to other people's Tails
browser. Depending on your actual threat this may be something you may
want to take into consideration.
Yes but also dead slow :P. I was more thinking of...
Yes, security is always a matter of compromise :).
Regards,
Simon.
--
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/105e2283c2f57b4dfd3cee5f2585eae6%40whitewinterwolf.com.
For more options, visit https://groups.google.com/d/optout.
