On Tuesday, January 23, 2018 at 11:30:08 PM UTC-5, Syd Brisby wrote: > some considerations: > > * Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in > both CPU & RAM). So running Qubes software on them at a productive speed will > be a challenge. > > * You're saying that laptop hardware specs are a problem for users. But > remember we had the problem of wireless modules still broadcasting after > being turned "off". So we needed laptops with wireless hardware switches to > be more certain that we couldn't be hacked. But now you are asking us to > again trust ordinary laptops and tablets that may not have hardware switches. > > * In reality, you are also changing from "deployment and virtualization" as a > single point of failure to "wireless" as the single point of failure. For > example, WPA2 has been declared insecure (hackable), with WPA3 being > necessary as a replacement. But, amazingly, WPA2 is still being "patched" by > manufacturers who think it's still acceptable - so how long will it take for > WPA3 to become ubiquitous?
Not sure how WIFI own encryption would be a single point failure, be it WPA2 or not, which I fully agree was a mess from the start. Is it not one a fair number of reasons we all use some combo of HTTPS VPN SSH TOR etc? Would anyone here connect to the net without such a combo even just to surf regardless of the inherent black box network security? Regardless of the connection medium be it radio waves via wifi bluetooth a network patch cable would it really matter? At my house I use a pi as a radius server so I am quite happy I got my patches for the wpa and not just sitting for 8 months waiting to get a unproven wpa3 rolled out. Not to mention that if wifi upgrades match android it will take 5-7 years before unsupported code is no longer in wide spread use. (I also use separate networks for things like TV IOT etc and data I consider higher value.) Back on the subject of Qubes Air: I could see connecting to a Raspberry cube or USB Armory Qube etc in a separate Zone via coms thru a VPN proxy VM qube connection. I think this works to handle the above stated PDF scenario or as even a way as a further isolation from a badusb infected drive containing files. I can also see it being a way to expand it into a decentrailized network of managed qubes with differing levels of security much like our current single PC Qubes OS presently offers. Qubes has to be removed from any specific platform such as X86 or even the hypervisor unless we will always be at the mercy of their security practices etc.. Best not to be permanently married but rather a dating relationship. The key would be ensuring one zone could not compromise another zone if proper workflow security practices are enforced/followed. Much how we handle data transfers between domains/qubes of different trust/security levels i.e red vs black etc... IMO once a level is chosen it would nice if rules could be enforced to prevent data flow rather than relying on the user to remember the proper flow. IMO this becomes a priority with increased domains zones qubes etc.. That data can only flow in the proper direction without explicit work. Its critical to understand that what the qubes OS is today would not be what would necessarily be running on these other zones but it also does not dismiss them from running it either. You have to remove the idea of being what the entire QUBES OS we have today . Anyways I liked the thought process and vision of the writeup. -- 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6702b77f-10cc-4d8b-b76a-fb2fa486f16a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
