there's an extremely common mistake made which needs to be pointed out: the clue is in the phrase "This kind of top-down thinking". the fundamental assumption is that there is a concept of "more privilege is required than before" to achieve privileged tasks. people imagine that security is hierarchical - that the further towards "the top" you get, the more access you are permitted. this is simply NOT TRUE. the classic example is "root", which is a drastic binary oversimplification which is simply very convenient.

so, people invent new security systems, but they invent them without actual proper thought towards design, and they invent them thinking that this "top down" hierarchical approach is the only way. thus, new APIs have to be invented.

there is another way: it's called SE/Linux (and there's a variant called SE/Android). SE/Linux follows the FLASK model, which basically says that based on the current context, the current application, that a new executable is given a COMPLETELY new security context, where the new privileges have to be explicitly given. the most important implication of this model is: it absolutely does not matter how "powerful" you were in the previous context - the one that fires up the new executable; the new one is literally a completely and utterly separate security context.

to give an example: take a 5 Star General, and send him to a security base. when he gets there, standard security procedure: they take away his passport and all his credentials, and they give him a security pass (a new context). that security pass has a pre-prepared set of restricted corridors and rooms that the 5 Star General can go to. he can go to the conference room, and the bathroom. if he tries to leave without returning the security pass, he has no passport, and no papers.

this incredibly powerful security model - FLASK basically fits on top of an OS *without* interfering with it. it's particularly fascinating because it can watch which programs exec() other programs, and it can watch what APIs those programs use.... *without* needing to actually modify those programs.

basically what i'm saying is that the problem that cyanogen is trying to solve already has a way in which it can be solved, if the SE/Android team haven't already solved it. and that's because, under SE/Linux and SE/Android, you can operate both the normal "root access" system *in parallel* with SE/Linux. all you need to do is create a FLASK security context which restricts access to only those applications that *should* be accessing the restricted APIs. you don't need to modify the applications, nor do anything special to the underlying OS.

rm -fr /*

ah you've heard of the openmoko and the openpandora, then? how long did their designs take, and did the components go end-of-life in one case before they'd completed the design? :)

the micro-engineering board being referred to is this:
http://rhombus-tech.net/community_ideas/micro_engineering_board/
that's what's being shipped. although the tablet itself using rapid prototyping for the casework shouldn't be too far behind.

yup. that's about the long and short of it. although it's at first consideration a complete pain for system designers on both sides of the interface - a nuisance for CPU Card designers because they have to substitute extra ICs such as USB-to-SATA in cases where they pick a SoC that doesn't have SATA - and bewilderment for I/O Board designers because why would they use a CPU Card in e.g. a tablet that has features they don't need such as Ethernet?? - the alternatives are absolute chaos.

the advantage: you can tell the average end-user "just buy one of these, it will work".

the alternative: think about this scenario as it is in many other standards such as Q-Seven , where you allow ethernet to be "optional" and you allow the I/O boards to "recreate" ethernet say using USB-to-Ethernet. how do you route that? well, if you think about it what you have to do is actually put down an Ethernet Hub IC on *every single I/O board*, and some sort of crazed switching, as well as put down a USB-to-Ethernet converter IC and probably a USB Hub IC as well... because the designers of the I/O board will never know if an end-user is going to plug in a CPU Card that has native Ethernet or is expecting it to be left up to the I/O Board using USB.

now expand that chaos out to SATA as well, as well as any other interfaces, and you can see immediately that a non-optional standard results in instant chaos. it's fine for Q-Seven (well... it's not. not really) where the expectation is that the Q-Seven Cards will never be removed from their carrier boards, but then why build a standard where the end-user is never expected to upgrade their system without needing a specialist degree in engineering in order to assess if the upgrade will even work?

the guiding principles behind the EOMA standards are: it must be SIMPLE, it must be OPEN, and it must work in HUGE volume.

the A10 is out-of-date so we're using the pin-compatible A20 instead. dual core ARM Cortex A7.

why didn't they post stories on slashdot?? then they would have got some attention. in fact... hang on: why have i *never* seen an article on h-online cross-referenced anywhere, and why have i *never* seen them in a google search??

well thank god he wasn't naked.

how about... just accepting that the country's bringing up kids who are dumb, and being happy with that? by contrast: in japan, kids are taught to be able to do mental arithmetic at lightning speed. tests involve flashing up 6-digit sums for 1/3 of a second every couple of seconds.

hmmm... is this the password that by default if you've never set it is set to the 1st 4 digits of your Social Security Number, like it is for Bell South? and how many retries are you allowed on the login? it's not 9,999 is it? and what are the first 3 digits of a SSN? why that'll be the area you were born, which probably closely match with the area code of the telephone number. that just leaves 2 digits left to guess...

there's a story i heard about the origins of linux, which was told to me a few years ago at a ukuug conference by a self-employed journalist called richard. he was present at a meeting in a secure facility where the effects of "The Unix Wars" were being exploited by Microsoft to good effect. the people at the meeting could clearly see the writing on the wall - that the apx-$10,000s cost of Unixen vs the appx-$100s of windows would be seriously, seriously hard to combat from a security perspective. their primary concern was that the [expensive] Unixen at least came with source: microsoft was utterly proprietary, uncontrolled, out of control, yet would obviously be extremely hard to justify *not* being deployed in sensitive government departments based on cost alone. ... so the decision was made to *engineer* a free version of Unix. one of the people at the meeting was tasked with finding a suitable PhD student to "groom" and encourage. he found linux torvalds: the rest is history.

now we have SE/Linux - designed and maintained primarily by the NSA.

the bottom line is that the chances of this speculation being true - that the NSA has placed back-doors in GNU/Linux or its compiler toolchain - are extremely remote. you have to bear in mind that the NSA is indirectly responsible for securing its nation's infrastructure. adding in backdoors would be extremely foolish.

the problem with the proposal that you've created is that if the phone is hacked then any number of one-off closed accounts can be created and transferred from your "actual bank account". what this tells us is that the actual problem is the concept of trying to use a general-purpose processor which is capable of running unverifiably-complex general-purpose software as a method of payment. it.... just.... doesn't.... add... up.

what's the very next article right here on slashdot? an article about how the inventor of PGP cannot properly implement ZRTP, a security application for smart phones. clinkle - starting from scratch - on a payment system for smart phones, making it a high-profile target. this is going to end well.

the PDP-11 is awesome. i believe its instruction set was the inspiration for the 6800 (http://en.wikipedia.org/wiki/Motorola_6800#MC6800_microprocessor_design yes it was) which then resulted in the 68000 all the way up to the 68040, processors which both commodore and amiga used to great effect up until the early 90's. at imperial college we didn't write a compiler for 68000 or even x86, we wrote a compiler for the PDP-11 instruction set.

the other thing is: if they're still running PDP-11's in large geometries (.35 micron or even bigger) then chances are it'll be much more robust and less prone to random radiation hits/changes. the kind of thing you really really REALLY want to be still working and under computer control is the "emergency shutdown" procedures in the event of a radiation leak. the LAST thing you want is one of the bits changing a floodgate to "open" instead of "shut" due to a random gamma ray flipping a bit somewhere.

it depends on what you're concerned about. if you're concerned about server presence in general because you're developing software that you absolutely do not want the NSA to be able to either track or take down, then you don't want a server - at all. that's when you should consider funding gittorrent, which is a TRULY peer-to-peer distributed git system. git is "considered" to be "peer-to-peer" because it is possible to *manually* distribute the git repository. each git repository - a peer - is completely free and independent of every other git repository - a peer - and it is possible to use HTTP, SSH and even email or carrier pigeon to transfer commits between one of those "peers" and another "peer". what is missing - what the concept of gittorrent brings to the table - is the means to AUTOMATICALLY transfer commits between previously UNKNOWN (i.e. DHT-discoverable) peers in an effectively unkillable, decentralised and secureable fashion.

if on the other hand you merely want a place to push and pull from then there are plenty of options, but the one that i've found to be absolutely superb is gitolite. from a management perspective the fact that you can control read/write access on not only a per-repository basis but also a per-branch basis is something that's amazingly useful, but it also simplifies both user and management usage because there is only one user: gitolite. the trick is in the use of ssh commands and the creation of a special authorized_keys file (which is created and managed via a git commit hook). as a result, there is no need to create multiple POSIX users: just one [gitolite], and the users only need one git clone username: gitolite. if you need a web interface you can always point gitweb at it.