The top rated private schools are often top rated because they drill for standardized exams. :(

I know a huge number of people who went to private schools not because mom and dad were motivated but because it was fashionable. It can easily go both ways.

That said... if you find a private school who boots kids out who don't meet certain academic requirements... even if the kids parents are rich an powerful, this is a great option. That way, if your students are hurting the rest of the class, you can call the parents and they'll quickly sort out the problems.

I actually really like middle class private schools as opposed to upper class ones since middle class ones generally have students whose parents sent them there because of academic reasoning as opposed to fashion.

haha sorry... too little too late from me. I haven't check mail in ... forever :)

Thank you for posing that question, I regularly attack people for simply bashing governments and not offering a alternative. After all, it's easy being a critic, you just have to point out the problems and not offer solutions.

I didn't know the details of the attack, but like most "news worthy items" the details were unimportant to the reporter of the article I read. So I was short in information. I have worked with/for (subcontractor of a subcontractor twice removed or something) and found that it's often a miracle Lockheed could accomplish anything. In order to score new projects, the people who would have been worth anything to begin with were taking off of projects regularly in order to be placed on new projects since the second Lockheed scored one project, they'd start posturing for the next claiming "You'll have the brainiacs that did this on your project"... so they'd get at most 3 months on each project. What's left afterwards are burnt out guys or guys that weren't really that good to brag about in a sales room.

I have to admit, I don't know an alternative. Usually I'm quick to think of something, but given the scale of a project like this, I'd say there's no company suited for this and it would be far more intelligent to focus on having in-house resources for this. People may complain about "big government", but in reality, in situations like this one, often the best solution is simply to do it yourself. :(

I am a system level developer who has implemented encryption technologies used in top-secret environments. Also I have worked on mobile device development at a system level for many years. I can't detail my credentials, but for as much as anyone else on Slashdot can be considered reliable, ... well you take it from there.

1) So far as I know, the only "smart phone" OS which has been "properly audited" was the specific versions of BlackBerry OS which is used by Obama. This does not include all versions of Blackberry OS... only the versions which have been specifically audited and approved for use on his phone. This does not mean that the OS is secure, the NSA audit on the code was performed too quickly for my tastes. It just means that the majority of "obvious holes" are not present. This completely rules out the newer QNX based OS for Blackberry since there is absolutely no possible way that much code could be properly audited in the time which it has been available. On top of that code audits are only a small part of what you need to do to secure a few million lines of code which is heavily communication oriented. Of course, running a simply security auditor on the OS helps as well, but I wouldn't bank on that either. An OS needs years of testing at a single revision before it can be truly solid.

2) Android may or may not be secure. It's extremely unlikely. If however you want Android and can't live without it, make sure to use only OS images which are hash check verified (MD5, SHA...) from Google directly. If the phone can't run the stock OS, DON'T USE IT! The reason for this is that the OEMs often update and modify code before putting it on the phones. They are feature oriented, not security oriented. Google Nexus would be a decent choice for this.

3) Don't even consider Windows, Symbian or iOS based phones. iOS is the safest of those three, but lacks pretty much all the features you're interested in. So far as I know, Apple doesn't even care about a "trusted platform" as the cost of maintaining a trusted platform is WAY TOO HIGH and would never yield the profits Apple demands from products. Windows and Symbian just aren't about trusted in the first place and the serious short comings in the Symbian "Development process" make it far too susceptible to being able to be hacked. Without decent development tools and kernel level debugging (which Symbian simply lacks for the most part) it's not possible to harden an OS. Also since Symbian never made use of things like "Test driven development", any change in one place could wreck 100 things elsewhere ... and often did.

4) Never EVER allow users to install apps... ESPECIALLY ON A JAVA PHONE meaning Blackberry or Android. This is because Java is insanely easy to hack. Yes, I know Oracle and Sun say otherwise... but I recall Yugo also calling their cars safe. Voluntarily installing an app which replaces the class loader on the system is enough to hack the entire thing. There are hundreds of other ways to hack Java which is obvious to me an others that can be exploited with a simple malicious chunk of code in an app. Also, since Java based platforms don't generally allow sandboxing, the apps all kind of have access to override system resources and interfere with each other.

While I personally despise Blackberry having tried it a few times and felt like I was using junk, if you must have these features, you should use their hardened and audited system.

Not the QNX version... too new... too many hacks... not enough testing etc...

He might end up with Blackberry based on QNX which is not the secure BlackBerry which the NSA and those guys cleared for Bama.

Blackberry on QNX is a thoroughly untested system based on a nearly full rewrite of the operating system which we all know suffered from severe rush to market syndrome. Meaning that there is no possible way a product which is almost certainly a million lines of code or more has been thoroughly tested for security. I mention in previous comments that QNX runs an in-house TCP/IP stack which almost certainly is exploitable. It runs in a separate process from the kernel, but it's still not the IP stacks used by millions and tested by every security lab on earth. The way you know for sure that it's got holes in it is that no one has reported holes on it. What this means is, no one has put it to the test yet. Or we could be expected to simply believe that QNX wrote every line of code perfect and they never had a bug... ever.

I've worked with QNX (with them directly on project with many many developers on their side as well as mine) and learned that QNX, just like other companies is not perfect. The only reason why they're secure is that we don't know what the holes are yet.

Let's not forget the Java platform which really does make it wonderfully hackable. Java provides so many possible ways to install rootkits and trojans that unless they found a way to run each app in a separate process, it's hopeless.

So... if people want to steer the reader well... they should recommend the old Blackberry stuff... it'll be years before we can consider this to be secure.

Pre-QNX BB was pretty secure... but with the whole rewrite, there is absolutely no possible way a device with that much code changed and that little use so far can be secure. I justify it above.

The new BB based on QNX is not tested for security yet. Yes... they did internal testing and all that and QNX has a history for being secure for the most part, but with several million new lines of code to compose the full rewrite of black berry's software, there's no possible way they could have tested that phone for any reasonable level of security in that time.

Also please keep in mind that QNX develops their own TCP/IP stack which I personally have used for about 20 years. And after having access to the OS source (and having worked closely with QNX on software projects for years) I don't feel confident that their stack is as secure as they say it is. Remember that QNX is one of the hardest operating systems on the planet to perform system level debugging on. This makes it very hard to properly audit the stack. It is however a user-mode stack which means there's less chances of kernel level "root kits".

Also, the phone is based on Java which is not very hard to hack... a simple "friendly" app can easily replace the JAVA class loader and pretty much run key loggers and such without a problem.

The only thing which appears to make BB secure is their advertising. They tell us all how secure they are and we feel secure with them. Without a proper code audit, I wouldn't ever consider them secure.

1) Who compiled it (a release manager at the OEM who is the lowest paid guy on the team)?
2) Who reviewed it (no one)?
3) Who audited it (no one)?
4) Is the OS signed and locked to the phone (nope)?
5) Can an OEM slipstream device drivers or system level code onto the device (yes)?
6) Can app developers slipstream drivers or system level code onto the device (usually)?

Unless you can be 100% sure that the guy who compiled release of the OS was actually aware of what they were doing with regards to security (less than 10% chance), it is entirely possible the phone should not be considered secured.

Both you and the poster above are kinda screwey in terms of thinking.

First of all... while implementing security code in VHDL or Verilog is possible and has been done, the CPU is just not a big risk in this case. You can use a CPU from a company you're sure is fishy and so long as the software above it is written properly, it should make no difference. It's not really even a matter of cost. Encryption is a software feature... security in general is software oriented. In a system such as Android where the processor itself doesn't even run the executable code but instead runs code JITed for the processor, it's even less relevant. I can write 10 pages on this to prove my point, but it's a waste of time.

On the other hand, there's nothing that says that a second microcontroller couldn't be hidden in the phone which runs a second network session in the background. Still, there is too much dependence on software and things like keys and such that would make it impossible for this to be an issue if the software is written properly.

It would just be stupid to waste time developing a malicious CPU if you can just install what you want on the phone itself as software.

Score a major government security contract?

Never understood why the hell companies like Lockheed score multi billion dollar deals that they are thoroughly unsuited for.