Qubes-Whonix integration - Specific use-cases causing redundant warning messages

[Aekez]

Qubes OS version:

Qubes 4.0.

Affected component(s):

@adrelanos
This issue is about Whonix integration in use-cases that only make sense on Qubes, or Qubes-like virutal systems. Packages used:
qubes-template-whonix-ws-14-4.0.0-201803131521.noarch
qubes-template-whonix-gw-14-4.0.0-201803131452.noarch

---

Steps to reproduce the behavior:

Two minor irritations in Whonix-ws-14
Warning messages that normally are good, but in some scenarios are redundant and becomes a problem, albeit minor since it's mostly a user experience issue requiring an extra click. But using the below examples, over time, these become A LOT! of accumulated clicks.

• Popup warning redundancy in some use-cases

  • A redundant warning message comes up if you want to open Whonix using below commands, i.e. if you commonly use a specific website and want to keep it clean every time. The redundancy becomes the problem if these are used on a daily basis and the user is quite well aware of the warning already.
    • qvm-run --dispvm=whonix-ws-14-dvm 'xdg-open https://duckduckgo.com'
    • qvm-run --dispvm=whonix-ws-14-dvm 'xdg-open https://www.youtube.com'
  • This isn't limited to dispvm's, but the practical use makes more sense with dispvms, since above use-cases are meant to be completely remove any trace, and also preferably not logging in (i.e. using YouTube without login).
  • A documented means or easier access to disable the warning would be desirable.

• Warning message at top-full-screen redundancy in some use-cases

  • As it is known, using Whonix in fullscreen is normally bad to anonymity, but if said Whonix-VM is strictly only used for dispvm's, without putting in private information such as login, then should full-screen be less of a problem, right? For example if the Whonix dispVM is only used to Stream video or music content, and for nothing else, and when shutdown it becomes completely clean again. In these scenarios, the full-screen warning appearing becomes a bit annoying and redundant.
  • Going by the assumption that full-screen anonymity makes little sense in this scenario, for as long the user does not login or do anything that fingerprint them needlessly.
  • A documented means or easier access to disable the warning would be desirable.

Expected behavior:

Tighter integration into Qubes and adjusted for different use-cases. Warning messages being more situational aware.

Actual behavior:

Warning messages are very broad and appear in situations where they are not needed.

General notes:

Work is also being done, albeit slowly right now, at QCC on making it easier to use a bookmark manager from an offline secure AppVM. Then using commands like:

• qvm-run-in-vm --dispvm=whonix-ws-14-dvm 'xdg-open https://duckduckgo.com'
• qvm-run-in-vm --dispvm=whonix-ws-14-dvm 'xdg-open https://www.youtube.com'

becomes a problem too, because the popup message will appear every time.

A functioning offline AppVM for bookmarks would also remove the need to keep any bookmarks in Whonix/Firefox itself, and would also make it easier to use dispVM's with bookmarking at the same time. Finding a way around this warning message is therefore very desireable if using a splitVM for bookmarks.

---

Related issues:

[adrelanos]

config to disable, see:
https://github.com/Whonix/open-link-confirmation/blob/master/etc/open_link_confirm.d/31_default.conf

Popup warning redundancy in some use-cases
qvm-run --dispvm=whonix-ws-14-dvm 'xdg-open https://duckduckgo.com'

I will implement: "on first invocation of open-link-confirmation in Qubes DispVM, skip asking for confirmation".

How does that sound?

Warning message at top-full-screen redundancy in some use-cases

Please provide steps to reproduce. I don't know yet which component / application is generating a full screen popup message. Before that, I cannot answer.

As it is known, using Whonix in fullscreen is normally bad to anonymity, but if said Whonix-VM is strictly only used for dispvm's, without putting in private information such as login, then should full-screen be less of a problem, right?

If it's by Tor Browser... Wrong assumption. When it was still warning vs fullscreen... In worst case, one time in full screen and a new DispVM with full screen could be correlated. In doubt please move that discussion to Whonix forums for wider input.

QCC

QCC?

A functioning offline AppVM for bookmarks

See also - not yet tested by me:
https://github.com/rustybird/qubes-split-browser

[adrelanos]

config to disable, see:
https://github.com/Whonix/open-link-confirmation/blob/master/etc/open_link_confirm.d/31_default.conf

Popup warning redundancy in some use-cases
qvm-run --dispvm=whonix-ws-14-dvm 'xdg-open https://duckduckgo.com'

I will implement: "on first invocation of open-link-confirmation in Qubes DispVM, skip asking for confirmation".

How does that sound?

Warning message at top-full-screen redundancy in some use-cases

Please provide steps to reproduce. I don't know yet which component / application is generating a full screen popup message. Before that, I cannot answer.

As it is known, using Whonix in fullscreen is normally bad to anonymity, but if said Whonix-VM is strictly only used for dispvm's, without putting in private information such as login, then should full-screen be less of a problem, right?

If it's by Tor Browser... Wrong assumption. When it was still warning vs fullscreen... In worst case, one time in full screen and a new DispVM with full screen could be correlated. In doubt please move that discussion to Whonix forums for wider input.

QCC

QCC?

A functioning offline AppVM for bookmarks

See also - not yet tested by me:
https://github.com/rustybird/qubes-split-browser

[adrelanos]

Already implemented:
Whonix/open-link-confirmation@b20a6ef

Package upgrades will come at a later time.

[adrelanos]

Already implemented:
Whonix/open-link-confirmation@b20a6ef

Package upgrades will come at a later time.

[Aekez]

I will implement: "on first invocation of open-link-confirmation in Qubes DispVM, skip asking for confirmation".

How does that sound?

Looks pretty much perfect! A mention of this first warning can be included in the new (yet to be made) Qubes doc on how to set up a split BookmarkVM, then this should work pretty well together. Cheers for getting it done so fast too! :)

---

Please provide steps to reproduce. I don't know yet which component / application is generating a full screen popup message. Before that, I cannot answer.

As requested I looked further into the reproduceability of the full-scren warning, and after some new testings today it might not be as big a problem as first thought, here is the observations below:

• It looks like this, the yellow panel;
  
• It can be reproduced by using the alt+space and then pressing f while the window is being focused, or manually entering a new fresh Whonix AppVM or DispVM into fullscreen, of which VM's where the user has not yet clicked 3 times on the "ok" button yet.
  • Clicking the X mark cancel button (next to the ok button), 15 times made no results in changes, the warning kept coming back every time full-screen was entered.
  • But three tests show clicking 3 times on the "ok" button will disable the warning message.
  • The user might by mistake think the message can't be disabled when clicking the X mark and might not realize they need to click the "ok" button 3 times to disable it.
• One suggestion here could be to include a small text in the warning to click "ok" 3 times as the warning appears to disable if user is hellbent on needing full-screen?
  • Another minor suggestion could be to maybe include a link to read up on the caveats of full-screen so the user can read up the pros and cons of full-screen before they go on ahead to disable the warning.
• For now at least I'm speculating whether to include the step in the upcoming doc that users can disable it by clicking ok 3 times, i.e. while pointing at the Whonix frontpage as a local no-internet file (when preparing the dispVM in the AppVM-dvm) file:///usr/share/homepage/whonix-welcome-page/whonix.html
  • But I definitely don't want to make a doc that breaks Tor anonymity in undesired ways, let alone putting any users who read the doc in harms way. As you suggested, I'll start a discussion on the Whonix forums, which I'll commit to do before publishing any doc.

---

See also - not yet tested by me:
https://github.com/rustybird/qubes-split-browser

Indeed this definitely looks pretty much the same concept I'm trying to archive, with some differences. I still need to look at the details to find further similarities and differences, but it definitely is the same concept. Thanks for sharing this, maybe I can talk with rustybird about some of these ideas and differences too once I find time to work further on this (after upcoming cramming/exams). Feel free to join in on the discussion if you got the time/interest. Maybe we should make a new Qubes-OS issue for that intention soon? There are some things left which might be worth discussing and/or working on, i.e.

• Making it work with any AppVM, DispVM, StandaloneVM's, Whonix or Non-whonix alike.
• How to make it seamless, for example between Whonix Bookmarks and non-Whonix Bookmarks, without risking the user sending the bookmark into the wrong VM.
• Finding best existing (or making) a bookmark manager that works really well with Qubes (making a new manager is out of my league though, if a new manager is the decided approach then I would need help with that if anyone is interested in it, as I'm mostly restricted to bash programming).
  • Though it is already confirmed that it can easily be made so that any bookmark manager will work, but some of the nice features rustybird made probably won't work the same (or at all) on any random bookmark manager given their differences. So some discussion might be due on which manager to recommend as well (i.e. giving user-choice among different managers, with pros and cons).

---

QCC?

It's the acronym for the volunteer Qubes Collaboration Community, but that acronym isn't well known (nor is the community for that matter). I should probably have used the full-name since the world is overflowed with new acronyms everyday since it isn't easy to keep track of all those new (and many) acronyms, I apologize.

---

If it's by Tor Browser... Wrong assumption. When it was still warning vs fullscreen... In worst case, one time in full screen and a new DispVM with full screen could be correlated. In doubt please move that discussion to Whonix forums for wider input.

Thanks for this, I will definitely reconsider my assumptions to get a better more clear understanding. I'll post on the Whonix forums as suggested once I've done some further preparation by reading up more on Whonix/Tor on this topic, so at least the FAQ are out of the way.

---

Wrapping up a conclusion to this comment in order to keep the on-topic integrity of the issue - The first warning message when using qvm-run looks resolved, and the second warning message when going full-screen can be worked around with an additional doc step, but also has some suggestions that can be considered.

[Aekez]

I will implement: "on first invocation of open-link-confirmation in Qubes DispVM, skip asking for confirmation".

How does that sound?

Looks pretty much perfect! A mention of this first warning can be included in the new (yet to be made) Qubes doc on how to set up a split BookmarkVM, then this should work pretty well together. Cheers for getting it done so fast too! :)

---

Please provide steps to reproduce. I don't know yet which component / application is generating a full screen popup message. Before that, I cannot answer.

As requested I looked further into the reproduceability of the full-scren warning, and after some new testings today it might not be as big a problem as first thought, here is the observations below:

• It looks like this, the yellow panel;
  
• It can be reproduced by using the alt+space and then pressing f while the window is being focused, or manually entering a new fresh Whonix AppVM or DispVM into fullscreen, of which VM's where the user has not yet clicked 3 times on the "ok" button yet.
  • Clicking the X mark cancel button (next to the ok button), 15 times made no results in changes, the warning kept coming back every time full-screen was entered.
  • But three tests show clicking 3 times on the "ok" button will disable the warning message.
  • The user might by mistake think the message can't be disabled when clicking the X mark and might not realize they need to click the "ok" button 3 times to disable it.
• One suggestion here could be to include a small text in the warning to click "ok" 3 times as the warning appears to disable if user is hellbent on needing full-screen?
  • Another minor suggestion could be to maybe include a link to read up on the caveats of full-screen so the user can read up the pros and cons of full-screen before they go on ahead to disable the warning.
• For now at least I'm speculating whether to include the step in the upcoming doc that users can disable it by clicking ok 3 times, i.e. while pointing at the Whonix frontpage as a local no-internet file (when preparing the dispVM in the AppVM-dvm) file:///usr/share/homepage/whonix-welcome-page/whonix.html
  • But I definitely don't want to make a doc that breaks Tor anonymity in undesired ways, let alone putting any users who read the doc in harms way. As you suggested, I'll start a discussion on the Whonix forums, which I'll commit to do before publishing any doc.

---

See also - not yet tested by me:
https://github.com/rustybird/qubes-split-browser

Indeed this definitely looks pretty much the same concept I'm trying to archive, with some differences. I still need to look at the details to find further similarities and differences, but it definitely is the same concept. Thanks for sharing this, maybe I can talk with rustybird about some of these ideas and differences too once I find time to work further on this (after upcoming cramming/exams). Feel free to join in on the discussion if you got the time/interest. Maybe we should make a new Qubes-OS issue for that intention soon? There are some things left which might be worth discussing and/or working on, i.e.

• Making it work with any AppVM, DispVM, StandaloneVM's, Whonix or Non-whonix alike.
• How to make it seamless, for example between Whonix Bookmarks and non-Whonix Bookmarks, without risking the user sending the bookmark into the wrong VM.
• Finding best existing (or making) a bookmark manager that works really well with Qubes (making a new manager is out of my league though, if a new manager is the decided approach then I would need help with that if anyone is interested in it, as I'm mostly restricted to bash programming).
  • Though it is already confirmed that it can easily be made so that any bookmark manager will work, but some of the nice features rustybird made probably won't work the same (or at all) on any random bookmark manager given their differences. So some discussion might be due on which manager to recommend as well (i.e. giving user-choice among different managers, with pros and cons).

---

QCC?

It's the acronym for the volunteer Qubes Collaboration Community, but that acronym isn't well known (nor is the community for that matter). I should probably have used the full-name since the world is overflowed with new acronyms everyday since it isn't easy to keep track of all those new (and many) acronyms, I apologize.

---

If it's by Tor Browser... Wrong assumption. When it was still warning vs fullscreen... In worst case, one time in full screen and a new DispVM with full screen could be correlated. In doubt please move that discussion to Whonix forums for wider input.

Thanks for this, I will definitely reconsider my assumptions to get a better more clear understanding. I'll post on the Whonix forums as suggested once I've done some further preparation by reading up more on Whonix/Tor on this topic, so at least the FAQ are out of the way.

---

Wrapping up a conclusion to this comment in order to keep the on-topic integrity of the issue - The first warning message when using qvm-run looks resolved, and the second warning message when going full-screen can be worked around with an additional doc step, but also has some suggestions that can be considered.