Just to be clear here, Geek-9pm seems to think that UEFI Secure Boot, which is designed to prevent unauthorized modifications to the boot executable on the UEFI partition is a anti-theft device. This seems to be a result of trying to imagine what the feature does based entirely on the name (Secure Boot) Rather than taking the rather unorthodox approach of actually looking up what it does.
Secure Boot does not perform any form of user authentication. The authentication and code signing certificates are for the boot executable.
UEFI does cover 'user-authentication' things in the same way as BIOS passwords, and works similarly to EFI. However it's notable that:
UEFI is managed and specified by the Unified EFI forum, created in 2005. Intel's involvement was the creation of the original EFI, which started in 1998 with the "Intel Boot Initiative". The UEFI forum is led by representatives from AMD, AMI, Apple, Dell, HP, IBM, Insyde, Intel, Lenovo, Microsoft, and Phoenix technologies. Neither EFI/IBI nor UEFI appear to provide any "anti-theft" capabilities. At least nothing beyond standard BIOS passwords. UEFI systems can be setup with pre-boot applications that support things like biometrics if desired.
but reduces the liability with stolen data. Under US law it is illegal to have your corporate laptop stolen, unless you have a way of dealing with the problem to protect customers privacy.
Part of that is related to the new secure boot feature of Windows 8. And I understand the Intel has no plans to make it work on Android devices.
UEFI nor secure boot do either of these things. They do not provide any data protection on the system. It is, of course, possible for Pre-boot applications to be installed on the UEFI partition to support features such as encryption and/or biometrics. For the Surface for example, Windows 8 supports a Preboot "bitlocker". It needs to be enabled and used, though.
It is also not in any way related to Secure Boot. It is a good example of the use of Pre-boot applications added over top of the standard Boot logic.
And I understand the Intel has no plans to make it work on Android devices.
Android has had full-device encryption for
a while .
At any rate I do not like any of these mobile devices or tablets. The reason is because people think they are easy to program. This could be the case, but I've found their programming capabilities to be complete, hacked-together garbage, bogged down with red-tape, restrictions, and "developer licenses".
Consider, for example, a simple case. a mobile receipt printer being used by somebody with a tablet.
This is something I have had to look into myself and the fact is that the entire mobile ecosystem is a gigantic ball of garbage when it actually comes down to
doing things that matter.
This is partly the blame of the manufacturer in that the device doesn't seem to have any support for any OS other than Windows and Linux. Which seems fine until we notice that the Windows support is x86 only and the Linux support is only by patching the kernel and basically re-building android yourself to add the appropriate device support. However as far as I can tell no similar mobile printers support mobile systems- so I'm not even really sure what they are doing. They may be designed for use with "Full PC" laptops, rather than tablets. Which is fine until we come to the problem where Tablets are the cool way to do business now and everybody wants to be able to handwrite values into their tablet and have it be sent to the database and then have a receipt be printed on the spot.
Another issue is that moving from a desktop environment to a tablet requires that- despite the hardware being similar- so many things be re-written that it completely defeats the purpose. A "App" designed to run on a Tablet cannot reference ANY external libraries at all except those that are themselves designed specifically for use on mobile. Which seems reasonable except when we are talking about things that have nothing to do with the user-interface; additionally it prevents any such "App" from ever interacting directly with any database at all.
The only method of communication actually supported is HTTP. In our specific case this means that in order to support a tablet device, we would need to setup a third server, specifically for serving only on-site tablets. a server for the ancient system, a server of the new postgres database, and one for a web server (or of course they could be on one machine that was powerful enough, but it's still more crap that would need to be written and maintained. And that doesn't even go into the details about apps requiring signing.