Hi Raffaele,

On 3 February 2018 at 17:09, Raffaele Florio <raffaeleflo...@protonmail.com>

> 1) I partially agree. Can you explain better please?

The "make firefox" rule uses wget to get a few files.  Is this because you
don't want to distribute signatures on Github?  Ideally, it would use local
files only.

2) I don't consider this case an issue. This extension is designed to block
> and redirect non whitelisted URLs, that is opened through the browser (e.g.
> with the shell, interactively, etc..). Evidently you restored non
> whitelisted URLs. So qubes-url-redirector did its job.

Well, it crashed my machine... I had to reboot the whole thing.  It would
be nice if it did something more graceful when presented with 20 links at
the same time, even if it is just asking for confirmation.

Also, I think your tool could be quite useful for several different use
cases.  Perhaps it's better to have the default configuration being
unobtrusive, but allow the user to switch on more defenses if they like.

> 3) In the plan there is a quick settings feature (there is a GitHub issue)
> to handle such type of scenario.


> 4) This option adds a lot of complexity and "DispVM" automatically become
> a sort of "SessionVM". Furthermore this option increase, greatly, the
> complexity and there is the need to communicate with Dom0. It only knows
> about which VM is alive.

I agree, but I do think it's worthwhile.  It might need some minor changes
to Qubes infrastructure.  For instance, qvm-run --dispvm could be amended
to return the name of the new VM on stderr, which could be re-used down the

> 4.1) Nonetheless I can add an option (in quick settings) to define a
> handler VM associated with the current tab. However you can already open in
> specific VM (also DispVM,) a link, through context menu entries. I don't
> consider this a vital and very useful feature. I consider the currently
> granularity, sufficient. However I'll wait for other opinions and Qubes
> 4.0, because in the old post [0] I was warned about substantial change
> regarding the privilege that permits a VM to choose which VM should handle
> an action.

I do think it's valuable to make these easy (i.e. few clicks, and few
choices during the normal course of things).  And I do think VM re-use is
important, since VMs use so much resources.  Qubes 4.0 adds a new
confirmation window by default, but the user can control its behaviour with
Qubes RPC policy rules.

One possible solution would be to add a new type of Qubes RPC rule: present
the user with the most recently opened DispVM to use as a default (that
they can change before clicking OK).  It might look something like this:


$anyvm $dispvm ask,reuse

(I think this idea needs a bit more thought!)

Kind regards,

You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to