Orwell and his mentor, Huxley, were trying to describe very different or even opposite dystopias. What we're ending up with is "mostly all of the above".
Would be interesting to see if any old laptops from 15-20 years ago had such switches.
As for 'airplane mode' radio cutoff switches, those are going away in favor of purely software controlled transceivers. On Thinkpads, I think the 2012 models were the last to have the switches.
A virtualization system is an OS with a strange ABI and an ill-defined API.
If you define virtualization as Intel style HVMs. Even with that, libvirt exists to create a standard interface. It can be used for HVM and PVM. Qubes takes it further with the Odyssey framework.
Except that having a compromised guest -- temporary or permanent -- still leaves you with a core system and isolated guests that are uncompromised.
What you're not getting is that when the Qubes devs say "security is not a boolean", they mean that in the prevention sense as well: Guests will likely be compromised by risky tasks, but attacks are still prevented from succeeding against the isolated parts. The fact that Qubes automates and GUIs some of the advanced hardware features in doing so doesn't alter that fact. You will get as much GUI convenience as security will bear, which is why cut-paste has an extra step and drag-and-drop (between guests) is unsupported. They even made file copy less convenient in some cases when the slight possibility of an exploit popped up; that is a preventative mindset.
Few of those relate to Priv or Info vulns. Instead of listing every entry the same, here is a more accurate chart: http://www.cvedetails.com/vuln...
And Xen is based on qemu
Um... Xen is not based on qemu, it uses qemu's device model and BIOS for HVM guests. Xen emphasizes PV guests for general operation and security, and that's what Qubes uses by default. OTOH, HVMs are a hassle to use even in Qubes and they are known to have security issues on all x86 platforms. So... excuse you, lol.
Remove the stuff in the above list that is DoS, HVM-dependant, non-x86, needs qemu running in dom0, etc., and there is hardly anything there to hyperventilate over. Secure configurations of Xen do not operate qemu HVM features from the privileged (dom0) domain, they use unprivileged stub domains instead. One "severe" CVE in 2015 was related to qemu, but it affected almost no one (certainly not Qubes users) because of this fact.
I'll also repeat what I said about Xen vs monolithic kernel-based security back in November:
Linux has racked up 3X the number of CVEs over 5.0 so far this year, compared to Xen. And of those, Xen had zero with a score of 8.0 or higher -- while Linux had a staggering six. Xen has had only two of these (both 8.3) ever, so looking back to Jan. 2015 is being very, very kind to Linux. I think what the CVE charts are showing is an inherent mitigation effect due to structural features of type-1 hypervisor.
OpenBSD, which doesn't support many desktop-related features, is a rarely-encountered odd duck; Not sure it fits into this conversation. FWIW, Qubes has an abstraction layer that allows Xen to be replaced with other isolation mechanisms. Among all the Qubes discussion about possible alternatives, I see no mention of using an OpenBSD host (although some people express interest in it as a non-GUI guest for proxy vms etc). It would be interesting to see someone try it.
I'm not aware of any browser that can withstand a determined and resourceful hacker. Browsers are huge beasts that are 80% attack surface. So I'll continue to fault Chrome for its memory use and other bad habits, and keep using Firefox.
I'll go further and point out that Pwn2Own folks obviously like using VMs to provide security when browsing, since they are putting VMware in the mix. And that hypervisor was originally designed for administrative convenience and full utilization of hardware, not security (now they are trying to make it a security platform, bless 'em). OTOH, Xen has long touted its security focus and has a really tiny attack surface so I'm happy to be using that in Qubes OS as well.
Code signing is not a good policy. It creates a false layer of trust...
It creates a layer of trust that fails passively which is exactly what people need when they cannot check a billion details about what's running in their systems. You seem to be advocating active security measures, IOW keeping umpteen antisocial numbskulls with ninja hax0r text-mode window managers and other frippery on retainer at great expense. Its also the kind of mentality that actually lends appeal to clusterfucks like Intel ME, and tries to stuff every PC user into only completely opposite roles: you have to be either full-time hacker or proverbial grandma. Fuck that!
The handwaving about secure boot and TPMs is also really special. It sounds like "Get off my lawn!". Qubes already has an open implementation of firmware verification that only requires memorizing a short phrase. Having machines authenticate themselves to users (instead of only the reverse) is a quite natural extension of what they're already doing.
Letting a system go out of date for years because of "stability" reasons will get you hacked, as you are not keeping up with the security updates.
Yeah, way to show you don't know the difference between upgrades and updates. I'll leave you on that brilliant note.
Of course, because no one ever heard of people downloading infected software from compromised distribution sites. And that's just for starters... what about the ability of security software to validate installed apps?
And the fact that you're cozy with your boyscouts-at-the-NSA image has exactly what bearing on this issue? There are people at all levels of society who try to spread malware and they will even fuck around with your LAN to do it.
No, sorry.... The norm for software distribution has to be app authors signing their code and distributing it in a form where verification happens automatically. If you have to tell users they cannot have both verification and current releases then the software ecosystem is sick.
And note that large FOSS authors like LibreOffice and Mozilla do not operate their own PPAs. They leave it up to fourth parties whom even most/.ers have never heard of before. Linux software distribution methods are too much of a hassle even for large FOSS projects. This should be a clue as to why non-libre products cannot grow on these non-platforms (in fact, there are hardly any robust desktop apps from any sector): If you want to have hope of reaching a large segment of a Linux distro's users, you have to hope that your app gets into a default or pre-approved repository and even then your fanbase will be isolated from exciting developments, stuck with stale versions, unless they also suffer the idiocy of upgrading the OS yearly and the high incidence of their systems becoming inoperative.
FOSS platforms need to find ways to facilitate direct relationships between app developers and users - safely. Most are seriously not in ANY sense trying to do that, and instead just get in the way.
Oops! From the readme: -- As a general rule, you are recommended to install LibreOffice via the installation methods recommended by
your particular Linux distribution (such as the Ubuntu Software Center, in the case of Ubuntu Linux). Th is is because it is usually the simplest way to obtain an installation that is optimally integrated into your system. Indeed, LibreOffice may well be already installed by default when you originally install you r Linux operating system.
This "stand-alone" LibreOffice installer is provided for users in need of previews, having special needs,
and for out-of-the-ordinary cases. --
They recommend against direct user installs! Who knew?! And BTW, to most people your 'easy' command line install looks like you had an epileptic seizure at your keyboard.
Oh, almost forgot to mention... You just installed unsigned code.
There was an epic one from last week where 4 unwanted pizza deliveries showed up at this person's door before the pranker started shouting "GIMMEE MY PIZZA!" and obscenities at the family. But it got pulled.
IMO, the real problem is font rendering characteristics emanating from FOSS systems. Bootup a basic fedora or debian system and what you will see fonts that are WIRY as all heck. Turning on subpixel rendering and hinting doesn't help enough, IMO. You can attack the problem with a font like Cantarell, which is nicer but also a real oddball. Or you can change your rendering to match a system like OSX using an out-of-date patch called 'infinality'... http://www.infinality.net/
Ubuntu, interestingly enough, seems to be an exception to this rule. Its rendering loses a lot of that wiry look. Its a significant improvement though still not quite as good as OSX or Windows. Its not surprising that infinality has a preset to emulate Ubuntu as well as other OSes.
IME has always been a buggy piece of shit with absolutely no visibility by anyone outside of Intel or without strict NDAs, that is a fair statement. I have no experience with AMDs equivalent to speak of. But IME was always a black box of vague claims, poor implementations, bugs and secret sauce. That devices have embedded FW is unavoidable in this day and age, it's a fact of life and people need to get over it (I'm looking at systems companies who are allergic to software). But normally that embedded FW has a fixed function, is scope limited such that it can be reasonably tested and verified by the design teams and "must work". It's not like a more typical software development model (even for BIOS or UEFI) where if they have to release a patch they will do it. Updating IME can be sketchy given where it's fingers may lie in a design. IME seems to confuse all those boundaries and I haven't worked with anyone who has liked it.
Confusing BIOS and UEFI into this discussion is distracting, they are generally unrelated (but again, given the sketchy scope of IME, there are tie-ins).
Agreed. GP is kneejerk Intel fanboy blather and automatically runs to attack AMD as if TFA intended to play favorites. Intel dominates the market and sets the trends, so stop being a baby about criticism when an article focuses on them.
IME remains a black box, that can talk with the network and is therefore open to attack. Its not a part of the trusted computing base, but has control over it.
Most CFLs have a color rendering index (CRI value) of about 80, while an incandescent is close to 100 so close to the full spectrum is represented. Gaps in the spectrum lead to eyestrain, odd skin tones, etc.
Most LEDs have a CRI of 82-85, just a bit better. But increasingly there are models with "High CRI" of 90 or above. I've got the TCP ones and stuff looks great under them... they also dim down to almost nothing with no buzzing at all. Here is a more expensive model with a CRI of 95. The TCPs were the same price as the Maxlites until a couple months ago, but I think the TCPs may be better because the mfg has taken care to rate its R9 value.
Note those two bulbs have a 3000K "color temperature"... they are not as yellow-orange as normal incandescent bulbs. If you like the "normal" 2700K temp then your choices for high-CRI LEDs become plentiful and you can just pick them up at Home Depot or Lowes.
The color AND quality of sunlight can also be reproduced very well by LEDs.
Well, maybe the un-Sony-fication of the PC industry will be a good thing. More experimental vendors like Purism are emerging, and they aren't catering to impulsive consumerism.
Endpoint (i.e. PC) security is abysmal and could be taken in several new directions if there was more research done on open hardware, adding security context to UIs and such. Heck, we don't even have PCs and mobiles that represent keys, certs and signatures as first-class objects.... An MS Excel spreadsheet on a Linux desktop is more likely to be properly represented and handled than is a PGP key (on any OS).
Why not sell people on devices that have on/off switches on all mics and webcams? On wireless transceivers?
There's lots of room for differentiation in this field.
Slashdot Mirror
https://www.whonix.org/wiki/Ab...
This is probably the safest way to use Tor.
They claim the specific Intel CPUs they picked do not support AMT: https://puri.sm/forums/users/t...
They have also been very up-front about the ME binary blob used with Intel CPUs. The hope was to eventually get Intel to open their code.
Orwell and his mentor, Huxley, were trying to describe very different or even opposite dystopias. What we're ending up with is "mostly all of the above".
Physical switch on the mic you can turn off or on. Perhaps with a nice indicator light.
These are showing up on at least one laptop brand: https://puri.sm/librem-15/
Would be interesting to see if any old laptops from 15-20 years ago had such switches.
As for 'airplane mode' radio cutoff switches, those are going away in favor of purely software controlled transceivers. On Thinkpads, I think the 2012 models were the last to have the switches.
A virtualization system is an OS with a strange ABI and an ill-defined API.
If you define virtualization as Intel style HVMs. Even with that, libvirt exists to create a standard interface. It can be used for HVM and PVM. Qubes takes it further with the Odyssey framework.
Except that having a compromised guest -- temporary or permanent -- still leaves you with a core system and isolated guests that are uncompromised.
What you're not getting is that when the Qubes devs say "security is not a boolean", they mean that in the prevention sense as well: Guests will likely be compromised by risky tasks, but attacks are still prevented from succeeding against the isolated parts. The fact that Qubes automates and GUIs some of the advanced hardware features in doing so doesn't alter that fact. You will get as much GUI convenience as security will bear, which is why cut-paste has an extra step and drag-and-drop (between guests) is unsupported. They even made file copy less convenient in some cases when the slight possibility of an exploit popped up; that is a preventative mindset.
Few of those relate to Priv or Info vulns. Instead of listing every entry the same, here is a more accurate chart:
http://www.cvedetails.com/vuln...
And Xen is based on qemu
Um... Xen is not based on qemu, it uses qemu's device model and BIOS for HVM guests. Xen emphasizes PV guests for general operation and security, and that's what Qubes uses by default. OTOH, HVMs are a hassle to use even in Qubes and they are known to have security issues on all x86 platforms. So... excuse you, lol.
Remove the stuff in the above list that is DoS, HVM-dependant, non-x86, needs qemu running in dom0, etc., and there is hardly anything there to hyperventilate over. Secure configurations of Xen do not operate qemu HVM features from the privileged (dom0) domain, they use unprivileged stub domains instead. One "severe" CVE in 2015 was related to qemu, but it affected almost no one (certainly not Qubes users) because of this fact.
I'll also repeat what I said about Xen vs monolithic kernel-based security back in November:
Linux has racked up 3X the number of CVEs over 5.0 so far this year, compared to Xen. And of those, Xen had zero with a score of 8.0 or higher -- while Linux had a staggering six. Xen has had only two of these (both 8.3) ever, so looking back to Jan. 2015 is being very, very kind to Linux. I think what the CVE charts are showing is an inherent mitigation effect due to structural features of type-1 hypervisor.
OpenBSD, which doesn't support many desktop-related features, is a rarely-encountered odd duck; Not sure it fits into this conversation. FWIW, Qubes has an abstraction layer that allows Xen to be replaced with other isolation mechanisms. Among all the Qubes discussion about possible alternatives, I see no mention of using an OpenBSD host (although some people express interest in it as a non-GUI guest for proxy vms etc). It would be interesting to see someone try it.
I'm not aware of any browser that can withstand a determined and resourceful hacker. Browsers are huge beasts that are 80% attack surface. So I'll continue to fault Chrome for its memory use and other bad habits, and keep using Firefox.
I'll go further and point out that Pwn2Own folks obviously like using VMs to provide security when browsing, since they are putting VMware in the mix. And that hypervisor was originally designed for administrative convenience and full utilization of hardware, not security (now they are trying to make it a security platform, bless 'em). OTOH, Xen has long touted its security focus and has a really tiny attack surface so I'm happy to be using that in Qubes OS as well.
You're sssuuuuuch a brave iconoclast!
/popcorn_time :D
Code signing is not a good policy. It creates a false layer of trust...
It creates a layer of trust that fails passively which is exactly what people need when they cannot check a billion details about what's running in their systems. You seem to be advocating active security measures, IOW keeping umpteen antisocial numbskulls with ninja hax0r text-mode window managers and other frippery on retainer at great expense. Its also the kind of mentality that actually lends appeal to clusterfucks like Intel ME, and tries to stuff every PC user into only completely opposite roles: you have to be either full-time hacker or proverbial grandma. Fuck that!
The handwaving about secure boot and TPMs is also really special. It sounds like "Get off my lawn!". Qubes already has an open implementation of firmware verification that only requires memorizing a short phrase. Having machines authenticate themselves to users (instead of only the reverse) is a quite natural extension of what they're already doing.
Letting a system go out of date for years because of "stability" reasons will get you hacked, as you are not keeping up with the security updates.
Yeah, way to show you don't know the difference between upgrades and updates. I'll leave you on that brilliant note.
Of course, because no one ever heard of people downloading infected software from compromised distribution sites. And that's just for starters... what about the ability of security software to validate installed apps?
And the fact that you're cozy with your boyscouts-at-the-NSA image has exactly what bearing on this issue? There are people at all levels of society who try to spread malware and they will even fuck around with your LAN to do it.
No, sorry.... The norm for software distribution has to be app authors signing their code and distributing it in a form where verification happens automatically. If you have to tell users they cannot have both verification and current releases then the software ecosystem is sick.
And note that large FOSS authors like LibreOffice and Mozilla do not operate their own PPAs. They leave it up to fourth parties whom even most /.ers have never heard of before. Linux software distribution methods are too much of a hassle even for large FOSS projects. This should be a clue as to why non-libre products cannot grow on these non-platforms (in fact, there are hardly any robust desktop apps from any sector): If you want to have hope of reaching a large segment of a Linux distro's users, you have to hope that your app gets into a default or pre-approved repository and even then your fanbase will be isolated from exciting developments, stuck with stale versions, unless they also suffer the idiocy of upgrading the OS yearly and the high incidence of their systems becoming inoperative.
FOSS platforms need to find ways to facilitate direct relationships between app developers and users - safely. Most are seriously not in ANY sense trying to do that, and instead just get in the way.
Oops! From the readme:
--
As a general rule, you are recommended to install LibreOffice via the installation methods recommended by
your particular Linux distribution (such as the Ubuntu Software Center, in the case of Ubuntu Linux). Th
is is because it is usually the simplest way to obtain an installation that is optimally integrated into
your system. Indeed, LibreOffice may well be already installed by default when you originally install you
r Linux operating system.
This "stand-alone" LibreOffice installer is provided for users in need of previews, having special needs,
and for out-of-the-ordinary cases.
--
They recommend against direct user installs! Who knew?! And BTW, to most people your 'easy' command line install looks like you had an epileptic seizure at your keyboard.
Oh, almost forgot to mention... You just installed unsigned code.
The EFF has Privacy Badger. Blur and Disconnect are two other options.
Adblock plus and Ghostery are partnered with the ad industry.
Here is some of the evidence: IP cam trolling!
https://www.youtube.com/watch?...
https://www.youtube.com/watch?...
https://www.youtube.com/watch?...
https://www.youtube.com/watch?...
There was an epic one from last week where 4 unwanted pizza deliveries showed up at this person's door before the pranker started shouting "GIMMEE MY PIZZA!" and obscenities at the family. But it got pulled.
IMO, the real problem is font rendering characteristics emanating from FOSS systems. Bootup a basic fedora or debian system and what you will see fonts that are WIRY as all heck. Turning on subpixel rendering and hinting doesn't help enough, IMO. You can attack the problem with a font like Cantarell, which is nicer but also a real oddball. Or you can change your rendering to match a system like OSX using an out-of-date patch called 'infinality'... http://www.infinality.net/
Ubuntu, interestingly enough, seems to be an exception to this rule. Its rendering loses a lot of that wiry look. Its a significant improvement though still not quite as good as OSX or Windows. Its not surprising that infinality has a preset to emulate Ubuntu as well as other OSes.
According to Youtube the webcams are much more entertaining than printers:
https://www.youtube.com/watch?...
Here is one where the victim calls cam tech support, and tech is clueless:
https://www.youtube.com/watch?...
And some commentary on the quality of Forbes' science reporting... http://blogs.agu.org/wildwilds...
Thank you for having a username that trolls "mdsolar" and his arrogant and obviously bought & paid for trolling.
Yes, the name pairs well with the link to Rupert Murdoch's WSJ editorial page. That's like using Fox News as a reference on a solar story.
IME has always been a buggy piece of shit with absolutely no visibility by anyone outside of Intel or without strict NDAs, that is a fair statement. I have no experience with AMDs equivalent to speak of. But IME was always a black box of vague claims, poor implementations, bugs and secret sauce. That devices have embedded FW is unavoidable in this day and age, it's a fact of life and people need to get over it (I'm looking at systems companies who are allergic to software). But normally that embedded FW has a fixed function, is scope limited such that it can be reasonably tested and verified by the design teams and "must work". It's not like a more typical software development model (even for BIOS or UEFI) where if they have to release a patch they will do it. Updating IME can be sketchy given where it's fingers may lie in a design. IME seems to confuse all those boundaries and I haven't worked with anyone who has liked it.
Confusing BIOS and UEFI into this discussion is distracting, they are generally unrelated (but again, given the sketchy scope of IME, there are tie-ins).
Agreed. GP is kneejerk Intel fanboy blather and automatically runs to attack AMD as if TFA intended to play favorites. Intel dominates the market and sets the trends, so stop being a baby about criticism when an article focuses on them.
IME remains a black box, that can talk with the network and is therefore open to attack. Its not a part of the trusted computing base, but has control over it.
Most CFLs have a color rendering index (CRI value) of about 80, while an incandescent is close to 100 so close to the full spectrum is represented. Gaps in the spectrum lead to eyestrain, odd skin tones, etc.
Most LEDs have a CRI of 82-85, just a bit better. But increasingly there are models with "High CRI" of 90 or above. I've got the TCP ones and stuff looks great under them... they also dim down to almost nothing with no buzzing at all. Here is a more expensive model with a CRI of 95. The TCPs were the same price as the Maxlites until a couple months ago, but I think the TCPs may be better because the mfg has taken care to rate its R9 value.
Note those two bulbs have a 3000K "color temperature"... they are not as yellow-orange as normal incandescent bulbs. If you like the "normal" 2700K temp then your choices for high-CRI LEDs become plentiful and you can just pick them up at Home Depot or Lowes.
The color AND quality of sunlight can also be reproduced very well by LEDs.
VM guests can be better isolated than air gaps.
Physical interfaces are usually more complex and exploitable than the interfaces available from a locked-down hypervisor.
I2P is more effective at this. Every user relays packets for the network, so your own packets are mixed in with network traffic.
http://www.theguardian.com/com...
Egads.
Well, maybe the un-Sony-fication of the PC industry will be a good thing. More experimental vendors like Purism are emerging, and they aren't catering to impulsive consumerism.
Yet, they are still voters. The implication here is that representatives must trick their constituents continually.
I'd rather have a population that feels the results of their own decisions personally, and therefore has a chance to wise up.
Endpoint (i.e. PC) security is abysmal and could be taken in several new directions if there was more research done on open hardware, adding security context to UIs and such. Heck, we don't even have PCs and mobiles that represent keys, certs and signatures as first-class objects.... An MS Excel spreadsheet on a Linux desktop is more likely to be properly represented and handled than is a PGP key (on any OS).
Why not sell people on devices that have on/off switches on all mics and webcams? On wireless transceivers?
There's lots of room for differentiation in this field.