Linked by Thom Holwerda on Sat 3rd Nov 2012 01:11 UTC, submitted by Panajev
Apple "Earlier this week Apple fired Scott Forstall, the architect of its iOS platform, and handed his duties over to the company's chief industrial designer, Jonathan Ive. Ive and Forstall had an infamously chilly working relationship, and one of their biggest disagreements was over the role of so-called 'skeuomorphic' design in Apple's products. Forstall, like his mentor Steve Jobs, favored it; Ive disliked it. To many observers, Forstall's forced exit looks like a vindication of Ive's stance. But if he wants to continue Apple's enviable trend of innovation, he'd be a fool to throw the baby of skeuomorphism out with Forstall's bathwater." Hoped for a thorough article on the benefits of skeuomorphism - got the age-old and intrinsically invalid excuse 'because it sells'. Windows isn't he best desktop operating system because it sells so well. Lady Gaga isn't the best artist because she sells a lot of records. This argument is never valid, has zero value, and adds nothing to what should be an interesting discussion.
Thread beginning with comment 541008
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

BluenoseJake,

"If you can turn it off, it isn't mandatory. OEMs are not required to turn it on, so it isn't mandatory."

I'm not sure how you are deducing that OEMs are not required to turn it on? OEMs are obligated to turn it on as stated in the windows 8 client system requirements:


http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.a...


"Mandatory. Secure Boot must ship enabled Configure UEFI Version 2.3.1 Errata B variables SecureBoot=1 and SetupMode=0 with a signature database (EFI_IMAGE_SECURITY_DATABASE) necessary to boot the machine securely pre-provisioned, and include a PK that is set and a valid KEK database. The system uses this database to verify that only trusted code (for example: trusted signed boot loader) is initialized, and that any unsigned image or an image that is signed by an unauthorized publisher does not execute. The contents of the signature database is determined by the OEM, based on the required native and third-party UEFI drivers, respective recovery needs, and the OS Boot Loader installed on the machine. The following Microsoft-provided EFI_CERT_X509 signature shall be included in the signature database:"


There is alot more information there. They disable unauthorised main-board flashing. They say over and over again the ways a user cannot bypass secure boot without disabling it.


"Mandatory. No in-line mechanism is provided whereby a user can bypass Secure Boot failures and boot anyway Signature verification override during boot when Secure Boot is enabled is not allowed. A physically present user override is not permitted for UEFI images that fail signature verification during boot. If a user wants to boot an image that does not pass signature verification, they must explicitly disable Secure Boot on the target system."


They even go so far as prohibiting OEM system tools from being secure booted.

"Mandatory. UEFI Shells and related applications. UEFI Modules that are not required to boot the platform must not be signed by any production certificate stored in "db", as UEFI applications can weaken the security of Secure Boot. For example, this includes and is not limited to UEFI Shells as well as manufacturing, test, debug, RMA, & decommissioning tools. Running these tools and shells must require that a platform administrator disables Secure Boot."



As we know, MS was heavily criticised for banning all other operating systems on computers where they hold a monopoly, so they added a clause for disabling secure boot on non-arm systems.


"Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems."


I'm posting this in the hopes that the information is useful to you, but I recognise this isn't the right place to be debating secure boot. On the next secure boot article that comes up, I'll probably be there ;)

Edited 2012-11-04 22:42 UTC

Reply Parent Score: 4