The two key things are:
-Mandating/nagging updates: only MS nags the users so much. To be fair, MS has been unfairly characterized as having a less secure platform than they really due thanks to their user base being lazy and trying to avoid updates, and that's a tough problem.
-Duration of updates. Because MS never really implemented a sane way to do in-place updates, they have to go into this 'limbo' state to install updates. Other platforms can install updates behind the scenes. Even if they do require a reboot or decide it's best to do a reboot even if not strictly required, none of the update activity blocks normal usage. A reboot to do updates is exactly the same length of time to reboot without updates.
Problem is that it is pure concept and mock up for now. Without an actual implementation, it's hard to judge how 'seamless' it truly ends up being and then also how hard is it for a developer to use correctly. There are incredible mockups from companies on a daily basis that never get realized. It's one idea to have a good idea on how something should work, it's another to actually make that happen.
Another issue is that in the mobile arena in particular, app persistence is actually rare compared to desktop. Users are being trained to not care that an app they were running has completely lost state while not being tended to. I think this is sad, but unfortunately for companies like Ubuntu the strategy seems to work.
Finally, Canonical has an awfully steep uphill batle to fight. If all it took were a compelling technical platform, WebOS would have gotten much further. Ecosystem and all the facets of the phone platform users take for granted (e.g. massive battery optimizations) will kill them if done wrong.
Basically, I fully expect this to go the Ubuntu TV way, nowhere.
And other platforms (e.g. Ubuntu) handle this by recognizing when a package was installed to fulfill a dependency and implements an 'autoremove' to remove packages acquired to fulfill a requirement that has since been uninstalled.
In the datacenter, applications *shouldn't* care about one OS instance rebooting. In practice, many do and companies find it cheaper to just fix it at the platform layer. I think this mindset is decreasing however so the datacenter uptime issue becomes less and less important.
However, in the consumer electronics space, it is killer. I woke up a windows 8 laptop to have it *immediately* start rebooting to install patches. I really wanted to use it *then* but I had to wait 15 minutes, no prompting, no nothing; just straight to a 'please wait' screen. If that had been a business presentation, that would have royally screwed me. This is not exclusive to MS though. I frequently try to whip out a PS3 game I haven't played for a while and the console won't even let me play it single player until I endure an update process that makes me *wish* it were windows.
The problem being that most of the stuff that would be needed to fix the horrible humanitarian problems of the day are not matters of science. The same people and equipment that *can* perform this research quite probably can't be redirected in a meaningful way to address those problems.
For example, monsanto research yields great advances in food production... that are subsequently constrained to protect their business interests. Better for the world to suffer than they not get compensated fully for everything. In the 'first world', you got to figure out a way to get the scientific research without playing into models subverted by greed. Not a problem that science can overcome.
Additionally, the best science can hope to do is produce gobs of food to effectively dump on the populace. We've been able to do enough along those lines to know how that ends up, those in power still control the supply, but local capacity for food production is reduced. People are still hungry, but now are more dependent that before on outside help just to get to status quo. The critical problem is beyond the realm of science to address, corrupt and/or powerless legitimate leadership resulting in abuse of what relatively small amount of resources are there.
Which is why the paradigm has to change. Day to day, you should be plugging in at home at work, maybe at places like grocery store and restaraunts with available 220v outlets that are not too bad to add to existing stores. If at lunch you can't find an outlet, no big deal, you've been charging 4 hours prior and you'll be changing for another 4 hours before going home.
Supercharging stations like this only make sense for people on long haul trips that don't have enough intervening downtime to do anything else.
Beating out nVidia and AMD is marginally surprising, but OpenGL ES support in Windows I'd figure to be the lowest priority 3D interface to implement for Windows, behind Direct3D and OpenGL. MS' attempt at targeting the lower end market is still emphasizing Direct3D, with OpenGL on Windows mostly only mattering for the occasional game engine and engineering application. OpenGL ES on Windows I'm thinking is a very very small slice of potentially interested parties.
You don't have VT on a serial port.
Although it seems pointless to me in general. The concern about VT in kernel vs. userspace is more religious than practical. The concerns about poor font behavior and such are overblown for a console that, in practical terms, is the console when things go wrong and not generally for day to day use nowadays.
If 99% of sites didn't put such a restrictive short length on their password length.
I can remember and don't mind typing a pretty long sentence, but then the site generally complains because of the spaces or because I exceeded something silly like a 33 character limit.
I will also say that some forbid special characters, some require. If you are going to stick me with no more than about 12 characters and refuse use of symbols like & and $, it's asinine. If you see that I have a 48 character password and complain that not one of them is 'special', you are impairing my ability to use a memorable password of appropriate length...
So my experience is all Linux based, but practically speaking that is all the open source software that is embraced by the distribution vendor with the vendor having full source. For example, most ppa repositories in ubuntu are only compiled for x86, even though they are generally open source because no one is doing a build server for other platforms. Let's exacerbate the issue by assuming a successful endeavor would have commercial, proprietary applications along for the ride (e.g. Netflix). The vendor must do builds per platform. You say debian so you can whip out all the less prolific architectures, but this is Ubuntu, you won't find a Ubuntu for Alpha because Canonical doesn't bother maintaining that build infrastructure.
The original point was that MS enabled use of a single *codebase* even if the vendor must recompile. *IF* true (I haven't actually bothered doing much Windows development at all, much less their mobile efforts), then you are conceding the same scenario is there: common codebase, unique builds. Linux is more convenient by having a much wider breadth of software in the distribution repositories, but the value prop for third party commercial projects is actually similar in this specific regard.
Unlike Android, you can be confident that if you turn off the online search, your phone will not send lots of data about you to the world-champion data-miners.
Oh really?
Face it, any corporate sponsored endeavor looking to compete with Google is going to resort to some of these tactics to extract profit since their ability to actually charge for the product itself is pretty well tanked.
I will say I'm perfectly willing to believe Android can be easily outdone in terms of UI functionality (hell, Palm did it with WebOS). App and manufacturer ecosystem is going to be a severely uphill battle. Canonical's past announcements have left plenty of room to doubt the viability of this announcement (Ubuntu TVs anyone?) so I'm not getting my hopes up that Ubuntu is the one to deliver me from the relatively mediocre android experience.
And you think a binary for x86 Ubuntu desktop is going to run on an ARM Ubuntu smartphone? Now if you say 'but they'll have dev environments that are processor agnostic', but that's also precisely the value prop of Windows 8 vs. RT in the scenario where 'metro' is used.
Not an apt analogy. Traditional hard drives still contain the vast vast vast majority of data in the world. Even if every last consumer device were 64 GB of SSD and no one bought any laptop/desktop anymore, all the data they care about would still be on magnetic disks at google/apple/dropbox/mega/azure/ec2/etc...
Just because a developer puts out a *workaround* to avoid exacerbating a problem, does not mean they were the ones to make the mistake first.
Notably, I personally know of UEFI implementations where in any way messing with the method to get into setup is impossible from the running OS. It is perfectly possible and reasonable to have a frimware that can keep itself whole and allow a user to be confident that no matter what the OS does, they can trivially reset to defaults. I know developers that exceedingly careful about the efi variable space and how it musnot t impact the ability to recover.
The concept of 'SecureBoot' is inherently unable to accommodate user keys very well. The reason being that abilitiy to write the keystore from the OS in a straightforward manner makes it, by definition powerless.
Now it could be mucked with so that for desktop systems you request some one-time passphrase from firmware setup and then use that in the OS to push your key. For servers you could use ability to authenticate to serive processor as a key (complication being that it would have to be a credential beyond the reach of IPMI KCS type interfaces, since that's not securable.
Ultimately though, the whole concept of secureboot as the mechanism to always protect the boot seqence is flawed. Thinking about the larger picture proves this out. The more precisely a security mechanism can model the authentic intent of the authorized user, the better. SecureBoot as defined can only model the vendors intent, which has to be fairly wide open. Some people have said that this could protect the integrity of SELinux, but then again malicious policy data could be fed in. You could argue that perhaps they can at least be tamper-evident with an audit log, which is critical but not ambitious enough.
What they should have emphasized was a mechanism where the frimware and OS work together with the TPM. The authorized OS takes ownership of the TPM and from then on the boot process be protected in that way. Offline attacks can be meaningly mitigated to a significant degree, which SecureBoot really cannot. The OS would require passphrase to sign kernel, initrd, and loader configuration file. The model wouldn't scale up beyond that, but the likes of LUKS could actually meaningfully take it from there to assure tamper-proof fielsystem and hibernate memory images.
Even if distinct divisions, it's going to be related. If you take it at face value, they are claiming the common brand of "Rackspace" is expected to mean something and this change is specifically to make their offering more what one would intuitively expect.
I suspect that this is probably more about avoiding a scenario where Rackspace advances the state of Openstack too fast. The faster Openstack matures, the less value their proprietary add ons provide. I've seen this repeatedly in the corporate open source world, some amount of fear, desperation, or genuine enthusiasm has them make big waves around open source. Then one or more of several scenarios play out. It could be the company doesn't get as much out of the community as they thought they would (e.g a relatively niche area or one generally devoid of development skill). It could be the company realizes they don't have any advantage without a unique software offering. It could be that they experience enough success they feel they don't 'need' the community anymore and divest from the project to try to keep others from reproducing their success. In this case, perhaps they aren't seeing the industry-wider openstack effort not changing EC2's dominance in any significant way. Perhaps they think they are carrying the important part of the project and if they aren't getting quality stuff in exchange, they are better off going it alone.
From a technical perspective, Openstack base distribution really isn't all that much as yet. It's more about having a critical mass of people having some significant consensus. Thus far it is more a political phenomenon than a technical achievement as of yet . In fact, even in their aspirations the project isn't really too large a technical endeavor. When companies realize that, they are actually very tempted to skip the chatter to reach consensus and write something on their own in less time than it would take to debate all the details in the open. We are talking about a relatively small potential market compared to most proven open source projects (the natural consequence of a project explicitly tasked with enabling consolidation into fewer systems and people). Openstack stands a very real risk of fading back into obscurity with the bulk of the leadership moving back behind closed, proprietary doors.
Additionally, once 'defeated', secureboot is trivially advertised. It's just a firmware flag that suggests that SecureBoot validation were done. A malicious low level attack could set the flag. That means it is useless as a mechanism to work against the end-user in the scenario where SecureBoot is optional, they can always put a UEFI loader in that falsely advertises SecureBoot before moving on. This design strongly suggests it isn't intended as a DRM feature (or else is among the dumbest ever attempted).
The kernel can execute ring 0 instructions. Your initrd can't.
Yes it can. It just makes a new 'ring 0' (e.g. qemu). The best SecureBoot can really hope to do is be tamper-evident in certain ways. E.g. if MS dictated that a key issue is contingent upon the application showing a certain logo, then you could educate *some* users that if they see anything but the Windows logo before their Windows system boots, it isn't to be trusted. It's nonsense to push the Secureboot goal further than that. Of course you can eventually display a Windows desktop, no matter how much you try in the SecureBoot methodology, it just can make it obvious. The key part is no feasible way to jump from Vendor assured non-customizable content to end-user sealed/signed/whatever content without the Vendor somehow blessing your key. For example, you think you've done well by LUKS protecting your drive and have Secureboot to say the kernel is *a* valid (note, not necessarily the last one you laid down), but someone injects malicious plymouth theme/tooling to MITM your passphrase to install a trojan prior to boot...
Basically, we still have no way to protect against offline atack of disk contents where the authorized user may use the system after the attack is begun.
The practical answer to that concern would be why is the kernel so damn special. You could hijack any number of equally important processes, security wise. init, sshd, apache, any shell, web browser, whatever. Replacing kernel pages in reality isn't really that important if you have access to the entire suspend image...
Slashdot Mirror
Sony has been attempting to kill the Used game market for years now.
For sony, the good news will be, they kill the used ps4 game market. The bad news, they also kill the new ps4 game market.
What is wrong with WPA2 with long passphrase?
The two key things are: -Mandating/nagging updates: only MS nags the users so much. To be fair, MS has been unfairly characterized as having a less secure platform than they really due thanks to their user base being lazy and trying to avoid updates, and that's a tough problem. -Duration of updates. Because MS never really implemented a sane way to do in-place updates, they have to go into this 'limbo' state to install updates. Other platforms can install updates behind the scenes. Even if they do require a reboot or decide it's best to do a reboot even if not strictly required, none of the update activity blocks normal usage. A reboot to do updates is exactly the same length of time to reboot without updates.
Problem is that it is pure concept and mock up for now. Without an actual implementation, it's hard to judge how 'seamless' it truly ends up being and then also how hard is it for a developer to use correctly. There are incredible mockups from companies on a daily basis that never get realized. It's one idea to have a good idea on how something should work, it's another to actually make that happen. Another issue is that in the mobile arena in particular, app persistence is actually rare compared to desktop. Users are being trained to not care that an app they were running has completely lost state while not being tended to. I think this is sad, but unfortunately for companies like Ubuntu the strategy seems to work. Finally, Canonical has an awfully steep uphill batle to fight. If all it took were a compelling technical platform, WebOS would have gotten much further. Ecosystem and all the facets of the phone platform users take for granted (e.g. massive battery optimizations) will kill them if done wrong. Basically, I fully expect this to go the Ubuntu TV way, nowhere.
You mean like what happens all the time in a suspending laptop already? Or when you get SIGSTOPPED?
And other platforms (e.g. Ubuntu) handle this by recognizing when a package was installed to fulfill a dependency and implements an 'autoremove' to remove packages acquired to fulfill a requirement that has since been uninstalled.
In the datacenter, applications *shouldn't* care about one OS instance rebooting. In practice, many do and companies find it cheaper to just fix it at the platform layer. I think this mindset is decreasing however so the datacenter uptime issue becomes less and less important. However, in the consumer electronics space, it is killer. I woke up a windows 8 laptop to have it *immediately* start rebooting to install patches. I really wanted to use it *then* but I had to wait 15 minutes, no prompting, no nothing; just straight to a 'please wait' screen. If that had been a business presentation, that would have royally screwed me. This is not exclusive to MS though. I frequently try to whip out a PS3 game I haven't played for a while and the console won't even let me play it single player until I endure an update process that makes me *wish* it were windows.
The problem being that most of the stuff that would be needed to fix the horrible humanitarian problems of the day are not matters of science. The same people and equipment that *can* perform this research quite probably can't be redirected in a meaningful way to address those problems. For example, monsanto research yields great advances in food production... that are subsequently constrained to protect their business interests. Better for the world to suffer than they not get compensated fully for everything. In the 'first world', you got to figure out a way to get the scientific research without playing into models subverted by greed. Not a problem that science can overcome. Additionally, the best science can hope to do is produce gobs of food to effectively dump on the populace. We've been able to do enough along those lines to know how that ends up, those in power still control the supply, but local capacity for food production is reduced. People are still hungry, but now are more dependent that before on outside help just to get to status quo. The critical problem is beyond the realm of science to address, corrupt and/or powerless legitimate leadership resulting in abuse of what relatively small amount of resources are there.
It also happens in Linux. Don't have Windows handy at the moment, but I'd be surprised if Firefox on OSX and Linux has it but Windows did not.
Which is why the paradigm has to change. Day to day, you should be plugging in at home at work, maybe at places like grocery store and restaraunts with available 220v outlets that are not too bad to add to existing stores. If at lunch you can't find an outlet, no big deal, you've been charging 4 hours prior and you'll be changing for another 4 hours before going home. Supercharging stations like this only make sense for people on long haul trips that don't have enough intervening downtime to do anything else.
Beating out nVidia and AMD is marginally surprising, but OpenGL ES support in Windows I'd figure to be the lowest priority 3D interface to implement for Windows, behind Direct3D and OpenGL. MS' attempt at targeting the lower end market is still emphasizing Direct3D, with OpenGL on Windows mostly only mattering for the occasional game engine and engineering application. OpenGL ES on Windows I'm thinking is a very very small slice of potentially interested parties.
You know you don't need to press Ctrl for sysrq combos right?
Every server has one or close enough (e.g. SOL).
You don't have VT on a serial port. Although it seems pointless to me in general. The concern about VT in kernel vs. userspace is more religious than practical. The concerns about poor font behavior and such are overblown for a console that, in practical terms, is the console when things go wrong and not generally for day to day use nowadays.
If 99% of sites didn't put such a restrictive short length on their password length. I can remember and don't mind typing a pretty long sentence, but then the site generally complains because of the spaces or because I exceeded something silly like a 33 character limit. I will also say that some forbid special characters, some require. If you are going to stick me with no more than about 12 characters and refuse use of symbols like & and $, it's asinine. If you see that I have a 48 character password and complain that not one of them is 'special', you are impairing my ability to use a memorable password of appropriate length...
So my experience is all Linux based, but practically speaking that is all the open source software that is embraced by the distribution vendor with the vendor having full source. For example, most ppa repositories in ubuntu are only compiled for x86, even though they are generally open source because no one is doing a build server for other platforms. Let's exacerbate the issue by assuming a successful endeavor would have commercial, proprietary applications along for the ride (e.g. Netflix). The vendor must do builds per platform. You say debian so you can whip out all the less prolific architectures, but this is Ubuntu, you won't find a Ubuntu for Alpha because Canonical doesn't bother maintaining that build infrastructure. The original point was that MS enabled use of a single *codebase* even if the vendor must recompile. *IF* true (I haven't actually bothered doing much Windows development at all, much less their mobile efforts), then you are conceding the same scenario is there: common codebase, unique builds. Linux is more convenient by having a much wider breadth of software in the distribution repositories, but the value prop for third party commercial projects is actually similar in this specific regard.
Unlike Android, you can be confident that if you turn off the online search, your phone will not send lots of data about you to the world-champion data-miners.
Oh really? Face it, any corporate sponsored endeavor looking to compete with Google is going to resort to some of these tactics to extract profit since their ability to actually charge for the product itself is pretty well tanked. I will say I'm perfectly willing to believe Android can be easily outdone in terms of UI functionality (hell, Palm did it with WebOS). App and manufacturer ecosystem is going to be a severely uphill battle. Canonical's past announcements have left plenty of room to doubt the viability of this announcement (Ubuntu TVs anyone?) so I'm not getting my hopes up that Ubuntu is the one to deliver me from the relatively mediocre android experience.
And you think a binary for x86 Ubuntu desktop is going to run on an ARM Ubuntu smartphone? Now if you say 'but they'll have dev environments that are processor agnostic', but that's also precisely the value prop of Windows 8 vs. RT in the scenario where 'metro' is used.
Not an apt analogy. Traditional hard drives still contain the vast vast vast majority of data in the world. Even if every last consumer device were 64 GB of SSD and no one bought any laptop/desktop anymore, all the data they care about would still be on magnetic disks at google/apple/dropbox/mega/azure/ec2/etc...
Just because a developer puts out a *workaround* to avoid exacerbating a problem, does not mean they were the ones to make the mistake first. Notably, I personally know of UEFI implementations where in any way messing with the method to get into setup is impossible from the running OS. It is perfectly possible and reasonable to have a frimware that can keep itself whole and allow a user to be confident that no matter what the OS does, they can trivially reset to defaults. I know developers that exceedingly careful about the efi variable space and how it musnot t impact the ability to recover.
The concept of 'SecureBoot' is inherently unable to accommodate user keys very well. The reason being that abilitiy to write the keystore from the OS in a straightforward manner makes it, by definition powerless. Now it could be mucked with so that for desktop systems you request some one-time passphrase from firmware setup and then use that in the OS to push your key. For servers you could use ability to authenticate to serive processor as a key (complication being that it would have to be a credential beyond the reach of IPMI KCS type interfaces, since that's not securable. Ultimately though, the whole concept of secureboot as the mechanism to always protect the boot seqence is flawed. Thinking about the larger picture proves this out. The more precisely a security mechanism can model the authentic intent of the authorized user, the better. SecureBoot as defined can only model the vendors intent, which has to be fairly wide open. Some people have said that this could protect the integrity of SELinux, but then again malicious policy data could be fed in. You could argue that perhaps they can at least be tamper-evident with an audit log, which is critical but not ambitious enough. What they should have emphasized was a mechanism where the frimware and OS work together with the TPM. The authorized OS takes ownership of the TPM and from then on the boot process be protected in that way. Offline attacks can be meaningly mitigated to a significant degree, which SecureBoot really cannot. The OS would require passphrase to sign kernel, initrd, and loader configuration file. The model wouldn't scale up beyond that, but the likes of LUKS could actually meaningfully take it from there to assure tamper-proof fielsystem and hibernate memory images.
Even if distinct divisions, it's going to be related. If you take it at face value, they are claiming the common brand of "Rackspace" is expected to mean something and this change is specifically to make their offering more what one would intuitively expect. I suspect that this is probably more about avoiding a scenario where Rackspace advances the state of Openstack too fast. The faster Openstack matures, the less value their proprietary add ons provide. I've seen this repeatedly in the corporate open source world, some amount of fear, desperation, or genuine enthusiasm has them make big waves around open source. Then one or more of several scenarios play out. It could be the company doesn't get as much out of the community as they thought they would (e.g a relatively niche area or one generally devoid of development skill). It could be the company realizes they don't have any advantage without a unique software offering. It could be that they experience enough success they feel they don't 'need' the community anymore and divest from the project to try to keep others from reproducing their success. In this case, perhaps they aren't seeing the industry-wider openstack effort not changing EC2's dominance in any significant way. Perhaps they think they are carrying the important part of the project and if they aren't getting quality stuff in exchange, they are better off going it alone. From a technical perspective, Openstack base distribution really isn't all that much as yet. It's more about having a critical mass of people having some significant consensus. Thus far it is more a political phenomenon than a technical achievement as of yet . In fact, even in their aspirations the project isn't really too large a technical endeavor. When companies realize that, they are actually very tempted to skip the chatter to reach consensus and write something on their own in less time than it would take to debate all the details in the open. We are talking about a relatively small potential market compared to most proven open source projects (the natural consequence of a project explicitly tasked with enabling consolidation into fewer systems and people). Openstack stands a very real risk of fading back into obscurity with the bulk of the leadership moving back behind closed, proprietary doors.
Additionally, once 'defeated', secureboot is trivially advertised. It's just a firmware flag that suggests that SecureBoot validation were done. A malicious low level attack could set the flag. That means it is useless as a mechanism to work against the end-user in the scenario where SecureBoot is optional, they can always put a UEFI loader in that falsely advertises SecureBoot before moving on. This design strongly suggests it isn't intended as a DRM feature (or else is among the dumbest ever attempted).
The kernel can execute ring 0 instructions. Your initrd can't.
Yes it can. It just makes a new 'ring 0' (e.g. qemu). The best SecureBoot can really hope to do is be tamper-evident in certain ways. E.g. if MS dictated that a key issue is contingent upon the application showing a certain logo, then you could educate *some* users that if they see anything but the Windows logo before their Windows system boots, it isn't to be trusted. It's nonsense to push the Secureboot goal further than that. Of course you can eventually display a Windows desktop, no matter how much you try in the SecureBoot methodology, it just can make it obvious. The key part is no feasible way to jump from Vendor assured non-customizable content to end-user sealed/signed/whatever content without the Vendor somehow blessing your key. For example, you think you've done well by LUKS protecting your drive and have Secureboot to say the kernel is *a* valid (note, not necessarily the last one you laid down), but someone injects malicious plymouth theme/tooling to MITM your passphrase to install a trojan prior to boot... Basically, we still have no way to protect against offline atack of disk contents where the authorized user may use the system after the attack is begun.
The practical answer to that concern would be why is the kernel so damn special. You could hijack any number of equally important processes, security wise. init, sshd, apache, any shell, web browser, whatever. Replacing kernel pages in reality isn't really that important if you have access to the entire suspend image...