Devs, how much would the community have to raise to pay for plausible deniability implementation in 4.2?
P.S. Please add ARRR and a ZEC Z-address to the donations page. XMR ring sigs might have been cracked… and we don’t want to end up like the CA truckers.
What would this look like to you? The key piece of plausible deniability is that you can reasonably deny that you knew about it. From what I’m understanding in this thread, you want to hide information when crossing borders, and if there were a way to do that that was baked into Qubes and you used it, that wouldn’t hold up anymore.
My preferred schema: PD at the qube level, hot-swapping at dom0 level…
When Qubes is installed it setups an encrypted space allocated for PD (whether user uses it or not).
When user sets up a Qube they can flag it to be included in the PD layer if PD is active.
From dom0, user can hot-swap into PD layer via a hotkey + creds (activate PD layer). Depending on the creds entered the PD layer vault space is decrypted to the outer or inner layer (Like Veracrypt). Qubes flagged to be included in the PD pool are now bound to the PD layer vault space.
It needs to be setup such that once qube is setup, bad actors could not know if the qube is included in the PD pool.
This would allow for qubes to run in parallel… some in PD… some in overt layer… leaving plenty of red herrings.
Ideally more than 2 passwords could be surrendered to bad actors (meaning PD space could have 3 or more passwords, taking to different layers).
.
The sandboxed architecture of Qubes seems it would adapt well to PD at the qubes level.
We already have working implementations with Veracrypt. Qubes 4.1 already has storage pools. Now it just needs a PD layer vault space setup by default when installed, so all Qubes installs look equal. And then some rails to decrypt and bind to the PD vault when hot swapped.
Interesting idea. I think it’s possible, but not sure if this would be on the priority list or not. I wouldn’t use plausible deniability in the name/description but more of a encryption/hidden AppVMs.
Let the community vote with their crypto. Setup a crypto address just for PD implementation. Determine the dev cost, and the goals that need to be hit… and the timeline.
If goal is hit, devs do it. If not, after the timeline, devs use the crypto for further development of other priorities.
P.S. Hear me now, believe me later… You will find yourself in several situations over the next 10 years, where you will be eternally grateful you had the foresight to segment your computing to a PD layer. Especially being that you work on tech the “terrorists” use.
P.P.S. Add more crypto options to the donations page please. Many in this dystopian prison the world has spiraled into refuse to feed the beast that is killing them (the banking system). I’ve sent you XMR… but I’m not counting that XMR will not get doxed in the future. Add zk-snarks coin options. (ARRR & ZEC Z address at the min.)
I doubt that you have a working implementation with Veracrypt that
provides PD of qubes in hidden volumes. (I may have missed where you
posted details of your approach.)
It’s somewhat difficult to hide the existence of a hidden volume - you
seem to suggest that a solution is to provide a hidden volume by
default.
The result will be that an adversary will start from the position that
the volume exists, and is in use.
Almost all Qubes users will be using SSDs, or USBs - either is likely to
be using trim and wear levelling, and that in itself will impact PD. I
don’t know if you have considered this, or if you have taken steps to
mitigate that risk. If you have I would be interested in the details.
In another post I already proposed a solution (there), but you never gave your opinion.
Can you elaborate please ? I’m no SSD expert. Isn’t the internal SSD firmware hiding “old data” from us ?
Also, wouldn’t OPAL drives mitigate that risk, when the hidden partition is mounted ? Again, I’m no OPAL expert, I still have to try this so I’m only “thinking out loud”.
Unman, are you suggesting, that even if slower, a spinning drive would be more secure? if someone could take apart computer?
No, rotating disks are even harder to secure.
Some security researchers have found that even after many erasures/rewrites, original data can be read.
That’s why it’s often said to hammer or drill your rotating disks before throwing them away.
Also, the physical media can be seen as “mechanical” storage : think about old vinyl disks (scratch), or even a tag in a tree, or a mark in a rock.
AFAIK, flash chips can’t be read “from outside” an OS (with microscope or other means).
And AFAIK again, the embedded/internal SSD firmware encrypts data on the chips (well, should).
So extracting NAND chips to put them in another SSD is not supposed to work.
As I posted for the topic opsec
watch old spy movies / training films and adapt the teachings to modern times.
Opsec: watch old spy movies / training films and adapt the teachings to modern times.
my favorite
#1 Undercover (Ca 1940’s) - YouTube
For this topic: The film quotes like that: “dont bring your equipment with you when you enter enemy country, the office will send it later to you when you established good cover”
So to cross the border to enemy country you just carry a laptop with windows, some application software, libreoffice, tons of science papers of a field you have some knowledge of.
Qubes gets installed later using an usb stick or tftp from your favorite openwrt-hotel router, or you have an ssd hidden somewhere else - not in your shoe!
Other good teaching : check for the labels in your clothing
→ use the right keyboard on your laptop (a hebrew keyboard in an arab country could cause serious trouble).
Just get the right sense of awareness and think for yourself. Many things are universal.
It would be great to have an under cover mode like you find in new kali.org.
What about copy cat-ing this for qubes dom0?
The under cover mode was lots of work, I am sure, but beeing open source qubes could take it and adapt it.
Under cover just radiates “nothing to see here” if bystanders see the screen.
But this is enough to convince a more or less stupid security officer (he would not be a security officer if he was sharp minded) who wants you to present your running laptop as “batteries could be bombs” or for some other stupid protocol he needs to follow.
Also under cover mode is a funny to joke to present to people who dont know kali.
cheers
Look at this, it is cool, the file manager of the window manager looks and feels 80% of windows explorer and more funny changes.
It is not just a wallpaper
To quore my favorite spy training film: “Blown cover!” 
Look at the picture
“Debian users” at the start menue…
Booom blown cover
It should really look like the windows system.
Rename applications and icons.
One should compare tails camouflage with kali under cover.
I would tend to use kali under cover as this is actively maintained and qubes could just fork the modifications for the window manager (gnome based iirc) used.
Developing and maintaining an under cover mode is much work so why wasting energy here when you can just port the modifications and improvements kali does to their under cover mode to a qubes fork of the kali under cover mode.
The qubes project is understaffed and additional tasks worsen the situation.
The cover should be good, also ctrl, alt back space should be there with a task manager showing some fake renamed Tasks 
So I would suggest to use kali.org under cover.
You need kali also to clean up the smoking debris of your crashed qubes-os, so get used to kali in times of peace as you need it in times of war
Rubber hose fs had a file called beatings to explain this issue, which can be solved by having layers to reveal while the existence if additional layers could be hidden sucessfully.
So after they got your cat pics present the password for your cat porn
This is something, but it is greatly insufficient. It only passes the absolute most basic eye test. It does very little to address the true value of an integrated plausible deniability system with Qubes.
It’s worth bring up for sure, but falls far short of what I think is needed.
Definitely Qubes devs should not be working on an undercover GUI mode, as that is a band-aid solution.
If you have an invisible partition that can’t be detected by adversaries, you would get tortured regardless of whether you had one or not, so why not have one? At least then you can give up a password to make the torture stop.
I tried and I give up.
For sure but the process if “getting cought” starts with the basic eye.
Nobody spots you on the street and starts to toture you. It starts with the basic eye.
In my favorite spy training film, the spy was arrested for carrying a hand gun which has been found at a routine search at a train station. A good spy does not need a gun, as nobody notices him as being somehow special, and here comes the basic eye…
You can not always do the stunt of “letting your office ship your material using a safe house or a dead drop”. = you freshly install qubes and download your data VMs somehow.
So if you are operating in $enemy country you just need that amount of basic cover when someone passes by when you work in the library on your “thesis”.
While traveling I often use libraries to have a quiet space with a desk, internet and electricity.
Are you a spy then? Or journalist?