FSF recommendations for free OS distributions considering Secure Boot
fsf.org
fsf.org
> This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine.
That's because like pretty much everyone who is not the FSF, Ubuntu has not actually carefully read the part of GPLv3 that deals with software that requires signing in order to install. Almost everyone just seems to skim through that section, sees something about having to provide keys, and then moves on. They don't read the definitions that define the terminology used in that section, and so have no clue whatsoever about what they have just read means.
I can kind of excuse it when it is just random end users or individual software developers who don't understand the license they are using...but one of the leading Linux companies!?
Another place you see this problem is in discussion of the incompatibility between Apple's App Store and GPLv3. There are people who still think the signing requirements have something to do with it. They do not. The problem is Apple's terms and conditions, which Apple requires end users to agree to before being allowed to use the store, count as additional terms under GPL (both v2 and v3) that are incompatible with GPL. The GPLv3 restrictions on distributing signed code without the signing keys would only apply to GPLv3 code that Apple ships bundled with iOS devices.
Please give them more credit. Apparently, they have even discussed it with the FSF. From https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035...:
Edit: failing to quote this sensibly.
In response to: "Have you talked to the FSF about their position on this? They're the sole copyright holder of grub 2, so any position they'd publicly take would be pretty relevant in terms of potential legal action."
The reply: "I haven't been privy to all the mails on this, but in the ones I saw, the responses were distinctly equivocal at best. They certainly didn't say that we were safe, rather the reverse."
I have discussed this matter both with folks like Richard Fontana (involved in SFLC, general counsel for Red Hat, and one of the drafters of the GPL v3) and Eben Moglen (SFLC, FSF, and one of the drafters of the GPL v3) and their understandings of key provisions was not only different but incompatibly so.
Here's the problem: the SFLC's official view, which is also the view of many developers who use the BSD-license, is that the BSD license does not allow a license change on the original code, but only allows restrictions to be placed on new code. Therefore if you write a program and release it under the BSD license, I can change the license to the GPL (any version) when, and only when, I actually make copyright-worthy changes to the code. Anything short of that and I am impermissively sublicensing your code, as prohibited in US copyright law. Now, slowly read the GPL v3, section 7, on additional terms.
Section 7 outlines a few areas where additional restrictions are permitted, and also addresses additional permissions. Since the work as a whole must be licensed according to the GPL v3, this would apply to any modules the work is dependent on, by the terms and definitions of the GPL v3, and additional permissions must be removable without changing the code. Earlier drafts allowed these permissions to be removed only when changing code but this was removed in a later draft. The BSD license does not allow this, and therefore it is incompatible. OTOH, the MIT license does allow it and so is compatible. Oops.
Except that everyone agrees the licenses are compatible. Moglen says that basically you can claim anything you want but nobody can sue you for it (sorry, I am not betting my house on that). Fontana says that the license was intended to be compatible and therefore must be read to be compatible, that one cannot safely convert BSD files to the GPL without modifying them, and that the GPL v3 should be read to accommodate this restriction. What a mess that opens up. Now we have to read the GPL as explicitly authorizing things it says it does not authorize.
So given my time trying to figure the GPL v3 out (and I have slowly read it more than a few times) I will give Ubuntu the benefit of the doubt here. The GPL v2 has problems too, but I would pick the problems of a license which is, perhaps, too simple over one which is undeniably too complex.
Now, my reading of the GPL v3 here is that Ubuntu would only possibly be off the hook but every distributor of Ubuntu-certified computers would have to release their keys. Moreover I am not convinced entirely that if a distributor failed to that Ubuntu could not be held accountable. If it's copyright infringement, Ubuntu is a vicarious infringer unless they did everything reasonably within their power to stop it. They have the power to require the vendor to distribute the keys, and they have a financial incentive. That makes them responsible. Worse if they told any distributor "you don't have to distribute your keys" that might make them guilty of Grokster-style contributory infringement.
I am not convinced Ubuntu would be safe at all. More likely depending on what was in the agreements, they might be held accountable along with the distributor.
Pretty much ok with Fedora and Ubuntu making the best of a somewhat bad situation. I wish they'd just fix the standard to allow multiple signatures on code and extensions, though. With that, Secure Boot would be basically all positive.
But Fedora's solution achieves both, so there's no need to leave GRUB2 for UEFI.
a. User turn ON a switch to enter "OS Install mode"
b. User install the OS of his choice. During installation the installer read a motherboard specific key from the BIOS and sign his bootloader/kernel/drivers using that key.
c. User turn OFF the "OS installation switch". System is save (at least as long as the OS in choice is not a Redmnond one)
Is there any fundamental problems with this approach?
Of course, you're also assuming that securing the end-user is the actual goal of UEFI. ;-) I can see legitimate situations where a corporation would want to ensure that their employees aren't tampering with their hardware.
Of course, I think it's fairly obvious by now that one of the main reasons that MS is pushing UEFI at this point is to prevent Android from being installed on "Windows" hardware.
Of course, i totally agree with you on that the reall reasons is for MS and hardware manufactures is trying to control MY hardware.
All non-mainstream operating system projects would be able to request keys from this organization and boot without having to resort to tinkering in UEFI hardware from multiple vendors.
One can dream.
As a possible scenario: what if the Windows 8 private signing key leaked because it was used in Terminal Server somehow - do you want the FSF revoking the Microsoft signing key, thus invalidating UEFI signed drivers (necessary for boot) from hundreds of OEM's?
We can shortcut all this by supporting www.coreboot.org
1. Flip the machine over. 2. Remove battery. 3. Flip the "developer's mode" switch.
http://www.windowsfordevices.com/images/stories/samsung_secu...
Also, anyone having physical access to your Chromebook can flip that switch and compromise your machine. While you can set a bios setup password to guard against someone flipping the secure boot switch.
Gain physical access to Any machine, and all security bets are off.
> While you can set a bios setup password to guard against someone flipping the secure boot switch.
Actually, that's a good point. But what if the attackers has physical access and simply reflashes the BIOS?
That's not guaranteed. For example, see Droid Milestone's locked bootloader and XBox 360 (recently broken with a cpu bug).
>But what if the attackers has physical access and simply reflashes the BIOS?
Security is all about raising the bar, reflashing takes a lot more time and effort than flipping a hardware switch and inserting a USB key.
Also, a physical switch is harder to implement in a consistent manner for low margin OEMs(who all buy the firmware from the same source), thus a software setting is better. For example, including such a switch on a tablet like the Microsoft Surface Pro will increase the costs and restrict design.
I was originally going to say, "Well, that's a different matter entirely."
It's not really, though. It's taking longer and longer for people to hack "secured" hardware.
The lesson of the PS3 still stands, though. If you let the hacker community install what they want, then they may not even bother to hack your hardware, unless you piss them off. The economics of hacking and security works like the economics of guerrilla warfare. You don't set up a highly visible and attractive high value target for an enemy that greatly outnumbers you. Doing that is just stupidity.
Guerrilla warfare is just as much about knowing what to cede as it is knowing what to attack.
Is it really that hard to go into the bios settings to change a setting? Already most people who want to boot a different OS have to do that to change the boot order to boot from DVD first.
http://www.windowsfordevices.com/images/stories/samsung_secu...
Displaying or dismissing such a notification needs to be built into the hardware in such a way that the OS wouldn't be able to interfere. There should also be a read-only channel for applications running on the OS to access the signing status to enable security programs.
Sandboxing has become increasingly popular and Microsoft is really the last one to the party. Most users (myself included) are happy with sandboxing. Apple has implemented this with great effect across its ecosystem.
All the actors are private organizations. No one is forcing anyone to buy a computer that enforces any of these restrictions. The FSF should try to understand why if this is such an important issue there does not seem to be a large market for Linux desktops. If there is a private actor can step in and provide the machines. If not, then you can always build your own.
One thing that will be interesting to see is if GPLv3 software slowly withers given that many embedded device makers will be unable to use it. I guess another cause may be Apple's continued rise as a platform of choice for both tablets and desktops/laptops.
But they're not. Desktop Linux can't win in the market, so they're trying to change the rules by whining.
While the FSF seems happy with the root Fedora is taken, it is interesting that every suggestion they make will make user's life harder.
I realise that they want to make software more free, and that this is broadly all Microsoft's fault, but I'll be honest as the years go by, I just get... tired. I just want to be able to install Linux as easily as Windows, and have it just work. I don't want to have to install extra keys.
1) If the user can, but is scared away by a disingenuous message saying "Do you want to make your computer less secure by installing a non-Microsoft key (y/n)?", that would still be bad.
2) They can't on ARM-based machines that have a Windows certification.
You cannot install an alternative OS on an iPad either which comes with a locked bootloader. Why is this such a big deal on Windows RT tablets only?
Second, I and others have complained about Apple's lockdown for years. There's more leverage right now in pressuring others not to follow their example.
Now ARM boot restrictions from Microsoft directly affects me, as soon i can't buy any ARM based machine, given the way the markets work. And in the future it is a big possibility that i can't buy any other PC and put any OS that i like without pay directly or indirectly money to Microsoft. And i can see some foreign governments to use this technology to control the OS that her citizens runs, and install backdoors.
So yes UEFI secure boot is a treat to my freedom and not only my freedom to run the OS of my choice.
Why not? Why do you plan to purchase a Windows RT tablet then?
>Now ARM boot restrictions from Microsoft directly affects me, as soon i can't buy any ARM based machine, given the way the markets work.
So you think Windows RT tablets will be such a success that you won't be able to buy any Android tablets at all?
For the thousandth time: I know a computer user who almost had a $300k sum stolen because his laptop was owned. He has had to resort to having a second laptop used exclusively for accessing his business bank accounts in order to feel some security. He's not dumb: he makes more money than virtually anybody reading this and has an undergrad in math.
The computer security model for most users is incredibly broken. The alternate to secure boot is something like an ios app store for all apps. Users simply want to be able to run their computers without having to be constantly paranoid about spyware and malware. Microsoft is at least trying to do this, but the eff pretty much dismisses these very real concerns.
edit: for the record, I spelled fsf as eff before having my first cup of coffee.
You're saying "Microsoft is at least trying to do this" about a company that continues to hold up fixes to known exploits (maybe not publicly known, but it takes only a single person...) until a convenient patch day, but manages to push own idea of security which breaks other peoples' systems onto the whole industry (strangely those other systems are not affected to the same degree). That's what I would call a very real concern.
From my experience with the "typical user", migrating my gf's laptop from Windows to Ubuntu did more for security than any bootloader hardening could do. And it required no hardware update either...
They need more privileges for hiding itself from antivirus software, SmartScreen and MMSRT.
Bootloader signing is going to do NOTHING against the current threat model, which is all in the much higher levels.
Yes, an ios-app-store for all apps model IS effective against the current threat model (but also harmful to the computing economy at large). Secure boot, at this point, does ESSENTIALLY NOTHING against any of the worms / trojans out there.
http://www.chmag.in/article/sep2011/rootkits-are-back-boot-i...
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_...
http://www.computerworld.com/s/article/9217953/Rootkit_infec...
I recommend reading atleast the first link.
Here's one juicy bit:
TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.
When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.
The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.
The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.
The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.
TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.
All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.
Another bit:
The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.
But I don't think UEFI is going to make much of a difference, even against the next version of TDL4; In order to get installed in a system in the first place, it had some administrator permissions. What's to stop it from getting those permissions on win8?
From this article, the boot sector lets it hide better and earlier in the process -- but it wouldn't have been less scary to ordinary people even if it couldn't infect the boot sector.
Don't get me wrong, we need bootloader protection like this. However the approach that is being taken is wrong. This is the UAC of boot loader protections.... A half-assed measure that if Microsoft actually looked at what everyone else was doing they would have supported something different.
Consider the following scenario:
Spear-phishing attach aimed at the right individual compromises their computer through an IE exploit (never happens, right?) and steals the bootloader private key.
What's the response? If the key cannot be changed then overnight this fancy new protection has been rendered no protection at all. The key can then be sold for top dollar to malware programmers. The solution for the user will be to wait a few months and then buy a new computer.....
So you are right that the sort of implementation we are talking about will not make much of a difference long-term, but for a different reason: it offers no long-term security if the key cannot be rotated.
I don't doubt that something could be designed right, but I do doubt that such a design in security-critical aspects of computing will arise with Microsoft's cooperation.
so you modify the boot loader, but now that is dead. so you modify ... what? now we're "done", there isn't any further down the stack to go, this is the "base" of the "trusted computing base". hooray!
While it's true that with a trusted computing base (and tower), you could turtle all the way down to the boot, but unless something is already wrong (which can and will go wrong the same way even if you have a trusted base), UEFI secure boot should ONLY ever save you from pre-boot INFECTIONS, which I suspect are non-existent.
The best it could do for you for higher level attacks is make it harder for the malware to hide.
the best you can hope for is locking out unsigned code. we have platforms that do that, like chrome OS and iOS. after many years, it seems they continue to work! but when we try and take this security technique that we know works and move it onto the computers that everyone uses, we are met with much wailing and gnashing of teeth.
Now, that's where the problem lies, not with the unsigned boot sector. On the existing win7 system, rewriting the boot sector and loading unsigned drivers are essentially equivalent permissions (elevating from the former to the latter requires one reboot).
> the best you can hope for is locking out unsigned code. we have platforms that do that, like chrome OS and iOS. after many years, it seems they continue to work!
At the expense of JITs on ios; and chrome OS doesn't yet have enough experience in the wild.
Also, locking out unsigned code doesn't stop stuff like "return oriented programming".
> when we try and take this security technique that we know works and move it onto the computers that everyone uses, we are met with much wailing and gnashing of teeth.
A chain of trust is known as a security technique that DOESN'T work, regardless of what it protects -- SSL forgeries are rampant, and the vulnerability is not in the algorithms.
The UEFI secure boot makes a small difference in real security. It will easily become as trustworthy as SSL certificates, meaning, not at all. And if the key ever leaks or is broken ... there is essentially no recourse other than buying a new computer.
There are ways to secure the boot in a way that's helpful for security without limiting choice. UEFI secure boot is not one of them.
Using Windows these days just seems like asking for trouble on the spyware/malware front. Some of it is your machine getting owned, other times its just missing a checkbox on a program install that installs a browser bar that does God knows what.
My Macbook Air is pretty much my computer of choice these days (with very little third party software). Soon Apple will require sandboxing on the Mac App Store too. Linux of course also being a much better choice than Windows from a security point of view.
On the browser front I can't see myself using anything other than Chrome. Part of this is feature-related and the whole one process per tab thing but it's also the most security-conscious browser IMHO (disclaimer: I work for Google but not on Chrome).
We haven't had any machines "owned" at all...
Sorry, but a basic principle of security is to assume that you are already 'owned'.
A better basic principle is guard all your doors, windows (excuse the pun) and cracks religiously (proactive).
Also: how does secure boot prevent your laptop from being "owned?". It doesn't. I will bet a significant fraction of that $300k that the exploit used against your friend was not pre-OS malware.
The basic problem is that the GPL cannot live up to it's goal in all cases unless it is backed by both a) software patents and b) a software patent license under the terms of the GPL. Absent that all you have is a license that allows you to do some things otherwise prohibited by copyright law. You have no restrictions beyond copyright law.
The problem here is that copyright law doesn't ban all copying and distribution. Notable cases in the US which allowed verbatim copying of part of source or object code in commercial products as fair use include Oracle v. Google and Lexmark v. SCC. In both cases the court basically said that 17 USC 102(b) precludes using copyrights to ban control secondary markets of practical tools.
So I read this as that in US law you do not need the copyright owner's permission to distribute software that links to a copyrighted library. If I want to link to GNU Readline with my proprietary app, 17 USC 102(b) protects me regarding US law, provided I dont distribute Readline myself. But hey, virtually every Linux distro ships with Readline so, what does it matter?
I don't know how fruits-of-labor jurisdictions address this issue but there is likely to be some line that prevents this as well. Otherwise Microsoft could say "Nobody can distribute MinGW for Windows 8 because no longer give permission to link against our system libraries for that version." No court in the world will give Microsoft that level of power, ergo I doubt the FSF has anything close to that either.
As for what Microsoft did, I think the key case would be Chamberlain v. Skylink. There is going to be no DMCA issue with breaking secure boot because you can't show that this is access control in the way the DMCA intends it. If you can jailbreak your ARM tablet that will be seen as fair use even if it involves literal copying (see the US Copyright Offices opinion on fair use regarding jailbreaking iPhones by copying/modifying iOS). If not, at least there has been enough press for you to consider yourself fairly warned in advance. IOW, it's a technical measure, not one backed by force of law.
I don't mind the GPL v2. It's a relatively simple license. There is some ambiguity (if I statically link your GPL v2 module in my program and provide the source just for your module is that allowed?) but for the most part that's pretty minor.
The GPL v3 is a nightmare and I try hard to avoid touching it. I don't care how many times I slowly read the license, it never makes sense to me.
For example..... Can you include a 2-clause BSD-licensed module in a GPLv3-licensed program? If the BSD license is interpreted not to allow sublicensing or passing on only a subset of rights to the code (this is the official view of the Software Freedom Law Center btw), does that render the licenses incompatible as per the additional terms (particularly the additional permissions) requirements in section 7 of the GPL v3?
With the GPL v2 everyone had a general idea of what it meant and lawyers only really argued around the edges. With the GPL v3, I don't think anyone understands it. And the driver of this problem is the FSF trying to push copyright enforcement where, quite frankly, it doesn't belong.
So what you saying is that just because you know some smart guy that owns a lot of money, UEFI is a good solution for fighting malware. I'm not so sure that UEFI is really gone help your friend to be more secure ... maby feel more secure though, which of course is a valid point but probably not because he will see thru it. Maby you friends laptop was due to a bootloader hack but there is easier ways to hack computer then that. I'm not saying that we shouldn't try to do anything about the risks but not this way, because this do only do it harder for everyone else.
What text are you drawing that conclusion from? It strikes me that they deliberately pass up the opportunity to disparage the security explanation for secure boot: "This claim ignores the fact that we need protection from them." Not "This claim is total BS."
The FSF statement acknowledges the security concern and brings up a competing concern. They ask that computer makers balance the two competing needs, and state that the plans for implementing secure boot on x86 will satisfy both needs. That's definitely not the blindly one-sided position you seem to think it is.
Was this unfortunate gentleman's laptop subject to unauthorised access by means of a compromised bootloader/bios? I have heard of very few exploits of that nature (but I'm not involved in supporting large numbers of machines).
Think of it like a VM loader, an OS running in a VM may not even be able to find out if it's running on Linux or Windows, but the host can transparently see everything going on in the guest OS.
Maybe because those who boot into environments endorsed by the FSF don't have a malware problem. I certainly don't.
That doesn't make me insensitive to other people's problems. But I have no sympathy for those who face such problems because they chose to.
I'll take it seriously when bootloader malware become the dominant model, because only difference is being harder to detect. Each and every malware I've seen is perfectly happy with user-level permissions and privilege escalation from within the OS and, once UEFI becomes the norm, I suspect signing keys will leak anyway.
Agreed.
> The alternate to secure boot is something like an ios app store for all apps.
That's not the only alternative, though. Having a way to simply notify users of a signing status change would be enough.
Again, a multi-thousand word essay on the topic of secure boot and lambasting Microsoft about the locked bootloader in the ARM tablets(which many of the same people think are going to crash and burn anyway).
Meanwhile, like in the RedHat and Mozilla blog posts about secure boot, not a peep about Apple or the iPad's locked bootloader which runs about 80% of ARM tablets.
Is this because Apple makes their own hardware so the FSF does not care? Or is it just their PR strategy that attacking MS is preferable due to media and people's favorable perception of Apple?
If ARM becomes dominant the idea that Microsoft can simply restrict access because that's how it was done in the past (even citing Apple as an example) simply means they can restrict a majority of all hardware sold from running a different system, extending their monopoly control through partnership agreements to a new generation of hardware.
Generally, PC compatibles boot an OS from a sector on the hard drive and provide a standard interface to the bootloader to hardware (BIOS, PCI enumeration, and now UEFI). While ARM is now beginning to adopt a similar boot system (in UEFI on RT devices) it's not carrying with it the openness we once enjoyed with PCs. This is the problem.
If iPads take over computing and desktops(along with Microsoft) die, won't the same scenario play out? Also, if ARM becomes dominant, won't a secton of the ARM devices be iPads and Android tablets? Why do you think Windows RT tablets will be the majority?
>While ARM is now beginning to adopt a similar boot system (in UEFI on RT devices) it's not carrying with it the openness we once enjoyed with PCs. This is the problem.
As an aside, ARM is different in the sense that each ARM SoC needs special drivers and coding.
Would you be satisfied only if every article complaining about the actions of one company also listed every single other company that has done something similar? That would be tedious, as the FSF has criticized lots of companies for crap like this.
They're calling out the platform which has no marketshare and making zero mention of the iPad which has around 60 million tablets sold. FYI that's an ARM device.
So you mean they think iPad users shouldn't have the freedom of choosing which software they run but Windows RT users need to? Right?
UEFI secure-boot is Microsoft pressuring other companies, companies that have no reason to restrict their users (thus reducing the perceived value of their devices) into making their devices tied to Microsoft software. That'll result in thin margins for hardware makers because they won't be able to differentiate and will have to compete in price. Microsoft, of course, is the only one who will benefit from this because they'll be the only source of software (and upgrades) for those devices.
In the 80's, PC makers were dumb enough to commoditize the hardware while Microsoft reaped the benefits of fierce competition. I wonder if tablet makers will be stupid enough to make that same mistake.
How does this distinction matter to the user of the iPad? They buy a tablet, they're able to run only what it came with. How is it better for them because Apple sells the hardware too?
>That's why I don't own an iPad.
Then don't buy a Windows RT tablet. It's not like they forced the OEMs to cancel their Android tablets. LG and HTC did that themselves without even making Windows RT tablets.
>UEFI secure-boot is Microsoft pressuring other companies, companies that have no reason to restrict their users (thus reducing the perceived value of their devices) into making their devices tied to Microsoft software. That'll result in thin margins for hardware makers because they won't be able to differentiate and will have to compete in price
Is dual booting phones and tablets such a big differentiator that people will pay a premium for them? Why do many Android tablets and phones come with locked bootloaders? Why doesn't Apple unlock the bootloader and sell more or sell for a higher price then? Hint: 99% of users don't care
>In the 80's, PC makers were dumb enough to commoditize the hardware while Microsoft reaped the benefits of fierce competition. I wonder if tablet makers will be stupid enough to make that same mistake
This really shows off your inexperience and lack of knowledge. It's the other way around, Dell and Compaq wouldn't exist today if not for MS licensing them MS-DOS when they didn't have to. Because of MS, Dell became a fortune 500 company in just 6 years. Go read about how they started.
>I wonder if tablet makers will be stupid enough to make that same mistake.
You mean they just continue to sell only Android tablets(which seem to be low margin by the way, so blame Google?)) and it's not really making them any good money. LG and HTC already dropped out.
Also you're ignoring how users reaped the benefits of commodotization of the hardware leading to the PC and internet revolution and are focusing on just MS' profits.
Actually, they buy an iPad. Much like you buy a Mac (which is just an exceedingly well designed and built x86 PC). Yet, people don't go to Apple stores to buy a PC - they go there to buy a Mac.
> Is dual booting phones and tablets such a big differentiator that people will pay a premium for them?
Thanks to licensing, it's more likely users will pay a premium for a tablet that doesn't dual boot, that cannot be upgraded and that cannot be repurposed to run anything other than older Microsoft software.
> Hint: 99% of users don't care
And, as we all know, millions of Lemmings cannot be wrong.
> This really shows off your inexperience and lack of knowledge.
I will regard that as an insult and not answer.
> Dell and Compaq wouldn't exist today
Like Commodore, Atari and Apple never existed, because, of course, because computers started to become useful with the advent of MS-DOS. In fact, the x86 PC (and Microsoft) would not exist in its present form if it weren't for Dell and Compaq and a host of other makers who built commodity hardware. Without this huge market, Microsoft would have to address a myriad of platforms and be unable to concentrate on a single one. Before it became clear the x86 PC would be the mainstream of home computing, they even backed the MSX consortium which was all about compatible (read "commodity") hardware running Microsoft software.
It's possible to differentiate around Android. It's not possible to do the same with Windows. It's simple as that.
If you could grasp the concept, you would have by now.
So, in the future, some people will buy a Windows RT tablet. If they want an ARM device, they can buy an Android tablet(hopefully not boot locked like many Androidf tablet).
>And, as we all know, millions of Lemmings cannot be wrong.
I never said they are right. I just stated a fact when you implied that the OEMs can sell dual boot as a feature for a premium.
>Like Commodore, Atari and Apple never existed, because, of course, because computers started to become useful with the advent of MS-DOS
Why is it not clear that Dell and Compaq are different from Commodore, Atari and Apple?
From Compaq's Wiki entry:
In November 1982 Compaq announced their first product, the Compaq Portable, a portable IBM PC compatible personal computer. It was released in March 1983 at $2995, considerably more affordable than the Canadian Hyperion. The Compaq Portable was one of the progenitors of today's laptop; some called it a "suitcase computer" for its size and the look of its case. It was the second IBM PC compatible, being capable of running all software that would run on an IBM PC. It was a commercial success, selling 53,000 units in its first year and generating $111 million in sales revenue. The Compaq Portable was the first in the range of the Compaq Portable series. Compaq was able to market a legal IBM clone because IBM mostly used "off the shelf" parts for their PC. Furthermore, Microsoft had kept the right to license the operating system to other computer manufacturers. The only part which had to be duplicated was the BIOS, which Compaq did legally by using clean room reverse engineering at a cost of $1 million.[12][13][14] Phoenix Technologies would shortly follow their lead, but soon "clone BIOSes" were available from many other companies who reverse engineered IBM's design, then sold their version to the PC clone manufacturers.
What about Dell then?
Dell traces its origins to 1984, when Michael Dell created PCs Limited while a student at the University of Texas at Austin. The dorm-room headquartered company sold IBM PC-compatible computers built from stock components.[7] Dell dropped out of school in order to focus full-time on his fledgling business, after getting about $300,000 in expansion-capital from his family.
In 1985, the company produced the first computer of its own design, the "Turbo PC", which sold for US$795.[8] PCs Limited advertised its systems in national computer magazines for sale directly to consumers and custom assembled each ordered unit according to a selection of options. The company grossed more than $73 million in its first year of operation.
The company changed its name to "Dell Computer Corporation" in 1988 and began expanding globally. In June 1988, Dell's market capitalization grew by $30 million to $80 million from its June 22 initial public offering of 3.5 million shares at $8.50 a share.[9] In 1992, Fortune magazine included Dell Computer Corporation in its list of the world's 500 largest companies, making Michael Dell the youngest CEO of a Fortune 500 company ever.[10]
>In fact, the x86 PC (and Microsoft) would not exist in its present form if it weren't for Dell and Compaq and a host of other makers who built commodity hardware.
It's clear that there would be no Dell or Compaq without MS licensing DOS to them. I am not saying MS did it for charity(they did it as a strategy that worked superbly well), but to imply that Dell and Compaq shouldn't have let MS commoditize hardware is not correct either. They didn't ship hardware to do charity work for MS. They made huge profits doing so.
>It's possible to differentiate around Android
Like what? Install bloated skins and junkware that can't be uninstalled? Atleast most Windows junkware is uninstallable. See HTC, their customers have zero loyalty to them and switched to Samsung.
Which Android OEMs are differentiating with great software and beating their rivals? Why are they utterly failing at competing with the iPad?
> It's simple as that.
>If you could grasp the concept, you would have by now.
You mean the concept that people are so sick of the OEMs Android modifications that they're willing to pay a premium for stock Android and still the OEMs ship their crap unless it's a Google device? Sounds like the reverse of what you claim is true.