So how exactly would that harm your system if it were something anyone could turn off with a simple trip to the bios?
My main concern is that, although the spec does indeed require that the manufacturer must allow the user to turn off secure boot, Microsoft might not enforce this requirement very aggressively. There are tons of examples of buggy BIOSes and ACPI implementations which claim to be compliant with the ACPI spec but fail badly on Linux because of various severe bugs, all while somehow managing to pass Windows certification (because the Windows certification tests don't actually test alternative OSes).
Microsoft has no financial incentive to make sure that manufactuers adhere to the portion of the specification requiring that users be allowed to turn off secure boot. They could easily arrange for their test suites to refrain from rigorously checking whether or not the BIOS switch works.
The real story is going to be how something with (apparently) severe weaknesses became anyone's pet new crypto standard.
Oh my god, uninformed summary is uninformed. Please don't make it any worse with your (even more) uninformed comments.
I'm a cryptography researcher specializing in pairing-based cryptography. I know this subject well. Here's the real deal. Pairing-based cryptography is just as (in)secure as RSA. Nobody goes around thinking that 923-bit RSA keys are secure. RSA is very widely used. (The current world record for an RSA break is 768 bits, but 1024 bit keys have been disrecommended for a LONG time, and there are teams working on breaking 1024-bit RSA right now that expect to succeed within a few years.) Nobody really expected 923-bit pairing keys to be secure. Those keys are too short. It's nice that these researchers did this, and it's nice that we know exactly how hard it is to break a 923-bit key, but the only take-away lesson here is that short keys are insecure. It does not mean that pairing-based cryptography has "severe weaknesses" or that the whole concept of pairing-based cryptography is somehow insecure.
I repeat: the key broken in this study was short. The study's conclusions are not very surprising or indicative of any weakness in the underlying protocol.
Another gross misrepresentation in your comment is the insinuation that pairing-based cryptography is somehow anyone's "pet new crypto standard." The number of international standards documents dealing with pairings is exactly zero.
Since you didn't bother to provide any details, I have to guess what you mean by your three words. Anyone who's taken a compilers class knows that the word "compile" is a very general term; it would be no exaggeration to say that almost anything a computer does consists of compiling something in some form. Assuming you mean the iPad can't compile, say, C code (and that this is presumably a showstopper or at least a significant drawback), it's certainly true that if compiling code is one of your main requirements while traveling then an iPad will serve you poorly. But given the incredibly limited capabilities of any sort of rig along the lines of what the asker is proposing, I have a hard time believing that the ability to compile code is a major requirement for the person who was asking this question. It's not like a Raspberry Pi (or even an Eee PC) will be a beast at compiling.
If you have to, an iPad can be used for compiling C code, either indirectly (by sshing to a remote server), or directly by jailbreaking. So your use of the word "can't" is wrong. It would be much more accurate to say that compiling code on an iPad is difficult and that if this is one of your main requirements then you need to say so up front in order to receive useful advice in return. Certainly the vast majority of travelers don't have any sort of requirement to compile code on the go.
Also, Google Maps is curiously missing from your list. Maps was developed almost entirely in-house and dominates its market.