-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-03-13 22:09, Chris Laprise wrote: > On 03/12/2017 06:09 PM, 7v5w7go9ub0o wrote: >> On 03/12/2017 12:45 PM, Andrew David Wong wrote: >>> On 2017-03-11 19:41, Unman wrote: >>>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise >>>> wrote: >>>>> On 03/11/2017 11:56 AM, Unman wrote: >>>>>> On Sat, Mar 11, 2017 at 04:43:41PM +0000, sm8ax1 wrote: >>>>>>> 7v5w7go9ub0o: >>>>>>>> Yep! And ISTM this is an argument for using dispvms >>>>>>>> to handle mail (or any other WAN-exposed >>>>>>>> client/server): start a dispvm; copy mail client and >>>>>>>> mail "file" into it; do your mail; copy out and save >>>>>>>> the updated mail file (which is text); flush away the >>>>>>>> dispvm - all handled by a script(s). >>>>>>> How do you figure that's less of a pain in the ass >>>>>>> than typing a sudo password? >>>>>>> >>>>>> You're missing the point - that procedure is trivial to >>>>>> set up in Qubes and addresses real security concerns. >>>>>> Just putting a password on root access, or requiring some >>>>>> dom0 interaction doesn't. >>>>>> >>>>>> This is important - security IS a pain in the ass. Qubes >>>>>> can make it less so. >>>>>> >>>>> Yes, sm8ax1 got you there. :) >>>>> >>>>> DispVMs are nice to have when we think that certain >>>>> operations carry threats. But its ridiculous to expect a >>>>> typical user to do a majority of their tasks in them. >>>>> >>>> No, it isn't ridiculous to expect a typical user to work in >>>> disposableVMs. I've set up a number of users with a range of >>>> experience, and they are very comfortable with this. If the >>>> implementation is kept hidden generally speaking everything >>>> goes fine. Some scripting to make things easier, and support >>>> is probably no greater than usual ,except for "that funny >>>> copy thing". I've said this before. >>>> >>>> Set up right I don't think that Qubes is outrageously >>>> difficult to use, even with disposableVMs doing most of the >>>> heavy lifting. But that's a separate issue. >> >> >> >> Agree with all of this. Working in a DispVM (e.g. browser, or >> mail) is the same experience as working in a VM. Only difference >> is clicking a script to start it up; inform the script of the >> DispVM to work in; and telling the script to shutdown (copy >> updates) at the end - in my case by entering a <n/l> >> >> >>> I'd be interested in hearing more about this (in a separate >>> thread, perhaps). >>> >>> In particular, no one has, to my knowledge, attempted to rebut >>> the arguments I advanced against the "doing everything in >>> DispVMs" approach here: >>> >>> https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J >> >> RATS! I missed that. >> >> >>> Granted, that was almost two years ago, and some of the things >>> I wrote there no longer apply. However, I still haven't seen a >>> strong case made *in favor* of this approach to begin with. I >>> would like to see one. >>> >> >> This is the first I've seen your 4/1/15 note - sorry - wish we >> could have discussed it then. You have the basic idea except for >> the vital point of what happens at end of DispVM session (copying >> as few as possible user files back to a VM or Vault). I take your >> point 4 on space, and point 6 on RAM and CPU usage. >> >> I disagree on critical point 5. >> >> For example running a browser in a VM is indeed "more secure" >> than running it in a VM because only specific updated files >> (bookmarks - places.sqlite) are retained and copied back to the >> vault at end of session; no other user-land files (and surprise >> relics) are copied back; this is contrary to what is presumed in >> that write up. If if the bookmarks weren't changed, simply flush >> the DispVM away. >> >> Doing mail in a DispVM is also "more secure" for the same reason >> - only specific updated files are retained at end of session - no >> other user-land files (and relics) are copied back to a VM. This >> is key, and why this is more secure. >> >> At startup, the user configuration file (.Thunderbird) is copied >> into the DispVM, followed by the latest volatile user data >> files. >> >> (If there is need to permanently change something in the user >> configuration - I haven't in years - one simply starts up the >> DispVM/tbird proggy, makes the configuration change doing no >> mail, usenet, etc., and promptly copies the newly changed, whole >> user configuration back to the vault, followed by immediate >> shutdown.) >> >> Also disagree on your second part of 6; I've been using this and >> other DispVM scripts since Q2.0 or Q2.1; I've become lazy as they >> just work! Infrequently I'll get a "failed to start" DispVM >> message, in which case I'll start one manually and tell the >> script to use it (script pauses 'til the DispVM is up and >> running). >> >> And also on point 6; yes there is a startup delay, but it is a >> completely acceptable trade off to me for the reassurance and >> relaxed comfort of running mail, browser, etc. in a DispVM. >> >> Thank you for the thoughtful analysis of 4/1/15; apologies for >> not responding at that time. > > Without a fleshed-out concept and implementation details, there is > not much to criticize or praise. >
I agree. > But with the focus on email and browsing thus far, I'm getting the > impression this involves restraining the user from using the system > as a normal PC and becoming cloud-centric for personal data. Only if "cloud-centric" means that the "StorageVM" is functioning like cloud storage. > It can isolate particular (but not many) user-facing processes from > the risk of network protocols (but not so much from the risks of > document/data parsing...not without degradation). > This sounds right to me. > If that is the case then it sounds OK for certain audiences. But > expecting users in general to go for this may be going several > bridges too far. > Largely agree (details in other reply). - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYx4lvAAoJENtN07w5UDAwHuMQAK6Ve/KGMa1/7b9t2OyuLyN/ bkE5DIa4TXE+KF3gcq3vR9M32aQzt/Ej6+g/BeYLLT3yVt4wFmwPSjAI+15u8H0x k7sgW5Hp1h/d4bRevxM7sL7PCSOYOkcRkw5DIOMKFoD1TMjH3pj74kgz5IGCspYr kLLNR91cW5haxH83XmQN34WwWZsPHNvhbI1XidmyeFSjccQdRKNDRgxKhl4zNEX0 HlFlPNSRuC5avlQod9f3CtYPPl1b51Q/b8H2xK5VsS+bZRG2HSyUnhuA584bGbkC dY7KB28kYKD0EYhTJF+PMdj/T0tRdn25/C+1KrWLGmkxA37CVwPoCRu+/RTAiKBa 86aLHkLxUpBa2YKUpDGtjL4djwjZJJrOIr0ge66ozFdPNFkdX4zZ1hV2x8/7T0kM lL8Cxx8XGs8K7lGS2NcWpMufN+hCDjBmA5QDpzYxSnLDg5uwfT4i/2E3bTh5Nub4 ZyxIRJoAtQouiJvLfPz/6a8MSGtfl6DrSLP2ZXKgVnFD9bUrLtX7U1qyGBujzw/I wHkGPm5LYoyPiG+oW4vvrUTp4eBnSts/kkaREEK6f71JUFBDnLNizL2R1gu5EqTG +yq9xzH3/fAK3XDf6ko7Pk/CWnFk7EN6fJPnsDI78zOhekhiblfdCxfrmJaC4IN4 Tmro62t8JdJFbMvpvag3 =PHEA -----END PGP SIGNATURE----- -- 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/48cffbce-23f5-0ab9-71fe-9343fc95a1f4%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
