>> - add Tor Browser first startup popup to ask whether security slider >> should be set to safest [2] [3] - Qubes users will be asked that when >> creating a new Whonix-Workstation AppVM and each time they start a >> DispVM - unless they preseed the answer to the question by changing a >> configuration file as described in the popup. > > A popup on every Whonix-based DisposableVM start is an issue.
Correction: - Currently at every start of Tor Browser in a Whonix-based DisposableVM. - Not at every start of a Whonix-based DisposableVM when staring arbitrary applications such as xfce4-terminal. It's one click to start Tor Browser in DispVM. And another yes/no to set security slider to maximum. Also that popup already contains instructions how to disable that popup with whatever setting one prefers, which can be done in TemplateVM. (And adding a feature to have the setting in home folder in DisposableVM template home folder would also be easy.) Not too bad? The improvement possible here would be DispVM start menu entry: - Tor Browser (AnonDist) - default security slider VS. - Tor Browser (AnonDist) - maximum security slider Saves one click. It's nice but I'd prefer to keep this as future work. > Persistent compromise is less of an issue in > DisposableVM, but on the other hand JS could still be used for some > fingerprinting. > Alternative idea: have a firstboot wizard that preseed it in > DisposableVM template. Most users don't ever start DisposableVM template or is it automatically started at some point? - if DisposableVM template is automatically started: then this is doable - if not DisposableVM template is not automatically started: what action to take at start of DispVM? > Basically the same thing but only saving the > setting without starting the actual browser. Should not be too hard. TemplateVM is automatically started after installation. Should first run wizard auto start in Whonix-Workstation TemplateVM? > Yet another idea, from [2]: use two menu entries for DisposableVM case > specifically. It isn't clear to me how to distinguish it at menu level, > but it shouldn't be hard to figure out (qubes menu scripts change may be > needed). I wouldn't know how to create a "show only in DispVM" menu entry but that sounds good if we had such a feature. >> - disable whonixcheck “Connecting to Tor…”, “Connected to Tor.” messages > > No notifications at all? Ok. (I need to adjust tests for this change) sdwdate-gui will replace notification. > - From time to time, there is also big whonixcheck dialog when it timeout. > Does this change applies to that dialog too? Yes. (That dialog will still be shown on manual start of whonixcheck.) > Hmm, I have two thoughts about it: > 1. Isn't exposing Whonix Gateway name leaking some potentially > de anonymization info? It can be retrieved only after full compromise of > that VM (command execution), but still. Agreed, not ideal. Simplified we do something like this: NAME="$(/usr/bin/qubesdb-read /name)" /usr/bin/qrexec-client-vm "$gateway" whonix.NewStatus+$NAME" shutdown" So we don't need to know the actual name of the gateway. Ideally we would have a qrexec interface "send this over qrexec to whatever NetVM I am connected to". While we are at it, that the VM finds out its own name and sends it over qrexec also isn't great. Would be better if the receiving VM would be told the sender by qrexec so a compromised sender VM cannot make up any names. Is that possible? Or even already possible? VMs connect to the correct UpdatesProxy VM, even though it does not know it by name? > 2. How about using TCP socket for it instead? Now that we have qrexec based implementation, given how long we needed to get there, and troubadour's (creator of sdwdate-gui / sdwdate-gui-qubes) limited availability nowadays, I don't think we can witch to a network based client/server architecture. > 2a. This could break if you put something between Whonix Workstation and > Whonix Gateway (for example VPN). But in that case automatic discovery > of netvm would break too. Would also break since sdwdate connects to onions which isn't possible when having a VPN in the middle. This configuration is out of scope. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/17b2c0b0-0955-cc90-f03b-3cdfc5ce109c%40whonix.org.
