This reminds me of an old 486 upgrade chip for the 386DX that was pin compatible. It would run the same speed as a 386DX, but one had to install a.SYS driver in MS-DOS to turn on the internal clock-doubling and such. No driver, no performance gain.
I wonder if it is the same stuff, where the CPU is fed some sequence to have it allow access to the full cache and such. Of course, I will be almost 100% sure that this driver will be not something open-sourced, so expect the performance boost by "unlocking" the chip to be only in Windows, and no other OS.
I just hope Intel doesn't spread this crap beyond the bottom of the barrel chips where profit margins are razor thin. For the low-end market where price is everything, maybe. However, for mainstream i5 and i5 chips, much less Xeons -- hell no.
I can see these put into use for keeping communications operational, should the Kessler Syndrome come into play making LEO impassible (courtesy nations like China showing off their target practice skills and the resulting space debris).
Another use would be bandwidth for populated areas, so traffic wouldn't have to be bounced off a satellite just for region to region traffic.
I'd disagree with you about Android's Exchange support. As of 2.2, the only encryption Android supports is encrypting apps stored on the memory card. Android has no encryption support of data whatsoever, and this by itself is a deal killer.
Of course this can be easily remedied two ways: LUKS if one wanted to dedicate segments or an entire memory card for device level encryption, or CFS/EncFS based for file by file encryption similar to what Windows Mobile 6.0 and newer does on the memory card.
Of course, this aside, even if the Android's Exchange support is lackluster, TouchDown picks up where the device might have left off, but the lack of data encryption is a big demerit for Android devices in the enterprise.
I wonder how long a card like this will last in an average wallet, perhaps facing demagnetization, wear and tear, and other issues of being in a pocket and constantly jostled around.
However, it it can handle that, this could be a great thing to have, as not just a credit card, but as an authentication device. Punch your PIN, punch a challenge phrase, give the vendor the response, and that will do a lot to minimize credit card fraud.
Of course, skimmers with cameras will still be an issue -- just videotape the person typing on the card and not the PINpad, and if it uses an active cryptographic handshake, run a MITM attack.
The $50,000 question: What can Windows Phone 7 come up with that nobody else has, and make people willing to be locked via contract to two years with the device?
Before Windows Phone 7, WM was a great and extremely secure OS, next to BlackberryOS. It supported remote kills, encrypted the memory card in a simple, but elegant and secure fashion, allowed one to reset their password if forgotten on the road, supported a lot of applications (when Handango was the main way to purchase mobile programs), was easy to program for, and so on.
It is understandable that Microsoft wants to go from an open courtyard to a walled garden, especially with all the brickbats they have taken over the years (deserved and undeserved [1].)
As of now, we have a number of distinct platforms for writing smartphone apps, and each is different from each other by a large degree: We have Objective C for iOS, Java for Android/BlackberryOS, XNA or Silverlight for Windows Phone 7, and C++ for Symbian (IIRC). XBox coders will be fine with XNA for the platform, but iOS and Android app writers will not bother because it is a completely different platform and architecture.
Developers are looking at the numbers right now and growth rates. If I were to place my bets on a business application, it would be the tried and true BlackberryOS. If I wanted business users and consumers, it would be iOS. If I wanted consumers and some small business, Android. Where does Microsoft fit in here?
There is one niche I see Windows Phone 7 will be good for is Exchange support. I'm sure it will support encryption, remote kill, password changes, password complexity, and all that. However, is superb Exchange support good enough to get the phone into the enterprise, jostling out Blackberries and iPhones [2]? IMHO, it needs more than that to be a viable platform.
Microsoft makes some high quality products, but that isn't good enough. They have to grab market from entrenched companies and fight with Android for customers, both business and end user. I can see MS gunning at RIM for the enterprise users, but they have a fight on their hands for other markets.
[1]: A lot of Windows problems are not Microsoft's fault. They are due to application developers who do the absolute minimum to get code shipped with security as a distant afterthought. I'm sure there would be a lot fewer cases of compromised Windows PCs if application developers wrote their code to not crash if DEP was turned on globally, and allowed ASLR to function.
[2]: Apple is getting better with encryption, especially for Exchange. The only thing the iPhone is missing is the ability to set it so it erases itself if it does not get a network signal after "X" amount of time like Blackberries do. Similar with functionality to erase itself if the SIM card is removed or changed out.
Nope, more likely it will call the police when it senses what you want to do to the person on the other end of the line after you just transferred for the fifth time, been on hold for six hours, and have everyone from your boss to the CEO staring you down at your desk.
1: The newer models come with 512GB-1TB of SSD, and automatically place data either on the SSD, the FC drives, or the SATA platters depending on how much it is used. If the chunk of data is used all the time, it sits on the SSD. This helps a lot with the bottleneck of a lot of machines needing to access the same data block with deduplication. This is different from other disk solutions, as the NetApp chooses the "tier" of disk for you. However, a lot of servers don't put out the throughput requiring someone to select between T1 and T2 disks, so for this, the NetApp is fine. Carve your LUNs out, carry on.
2: NetApp's WAFL system has been around saving butts for a long time. People don't realize this until you walk in and see that a junior admin blew away/net, and is looking at you with the deer in the headlight glance. A quick move from a snapshot directory, and nobody is the wiser.
3: You can put two NetApp SAN clusters in two geographically disparate locations and have them send changes via the WAN. This way, DR can be automated and made quite fast.
4: SANs are a lot more than just a bunch of disks shoved in a rack. They tend to be very intelligent of where data is placed, and on the backend, at least use RAID 6, where more than two drives have to fail at the same time for data to get lost. Almost all have multiple controllers, so if one path via the network fabric gets stomped on, machines are still able to access their LUN via the second one.
This isn't to say the NetApp is for everyone. If someone just needs a bunch of disk and no other features, a BackBlaze pod or a tower full of eSATA JBOD drives may be good enough. However, if one has a number of machines and is doing large amounts of random I/O, having an enterprise grade SAN goes without saying.
The US is lucky in one respect: Unlike most of Europe where citizens 18-20 have to go into the army or other duty for two years, US citizens really only have two duties: Jury duty and voting. No, there is no law forcing people to the polls, but by not voting, people are letting people who are likely dumber than themselves, or the lobbyists and their ad firms behind the attack ads decide the election.
If you are a US citizen, vote. If you like neither candidate, write someone in. It doesn't matter what side you are on, just go, do your research for the candidates, and go vote./rant.
Also, is this over a 3G/3.5G with separate data and voice, or true 4G where everything gets packetized and pushed over IP? I might be able to see someone with Exchange who gets a lot of Excel spreadsheets pushed to their device having more network traffic than a voice call, but a push or IMAP IDLE notification doesn't take that much bandwidth by itself.
And guess what the lusers will do? They will beg Congress for more laws to "protect" them from the evil bogeyman, or put the blame on Microsoft for having an "insecure" OS. In reality, the only OSes can protect against the Dancing Bunnies security issue are closed and locked operating systems.
Ultimately, due to Joe Sixpack and Trojans that the future of desktop operating systems eventually will look like ChromeOS or iOS. No root or administrative access anywhere to be found (even for clued users), perhaps some rudimentary multi-user capability, but there will be no "#" prompt to be found anywhere. Development machines will either be special machines that are unlocked, or will run a hypervisor. You won't find a true root/Administrator level access anywhere, except enterprise level servers. Machines will enforce this by not booting from OS media unless the OS image is signed, and the OS volumes (C: for Windows, / and/usr) for UNIX will be encrypted, unlocked by the TPM on boot.
Apple also might not have the resources to support another language. Objective-C is essentially Apple's (Well, technically NeXT's) baby, so if Apple decides to make a language change, it is their decision, and theirs alone. If Apple wanted to start using BEGIN and END statements a la Pascal in the next objective-c release, they can and nobody can tell them otherwise.
By absorbing Flash and making it a supported language, Apple would either have to walk lock-step behind Adobe with every change they do to ActionScript, or fork and have a version that "mostly" works, forcing developers to have to make sure they don't do something that isn't supported, or may cause a crash or incompatibilities later on.
Instead, what would seriously sell would be the ability to take Java bytecode made to run in the Dalvik VM for Android, and convert that into Objective-C source code. Of course, this is a lot harder than it sounds, but if someone is able to make a tool like this where software companies can have essentially one code base for Android and iOS, it would rake in the cash big time.
App pirates are the bane of the Apple Dev Team, the JB scene, the Android modding scene, application writers, and end users.
What I want to see is Apple having an anti-piracy mechanism separate from the jail. Android's method of checking if the user is licensed is good. I have another proposal as well:
During the legit app install process, the app sends a SHA-256 hash of the IMEI or device ID of the device it is running on to Apple. It gets a signed certificate back similar to how Apple does the SHSH process for OS revisions. Then on future runs of the app, it just checks the ID versus the cert and if it doesn't match, checks the app store if it is authorized to run. If not, it prompts the user to be purchased. Of course, there are ways around this with ease, but this forces the app pirates to crack every app and every update.
There is also the plausible deniability aspect. Say someone manages to find a remote hole into the iPhone and grabs confidential information. If the phone is not jailbroken, the person shrugs, says to blame Apple because his device has been enforcing Exchange policies including remote kill switches. If it is JB-ed, regardless of the quality of Cydia and other items, the blame will stop with the employee because "he hacked his phone."
It is also mathematically impossible to make a 100% secure symmetric crypto algorithm if the key is shorter than the data being enciphered. However, we can make something that won't be broken even after the universe dies a heat death.
Same with devices. Look at the PS3. It took 5 years for any notable breaks to happen, and as time goes on, it will become harder and harder because it will be easier to embed the critical startup keys in layers of epoxy and tamper-resistant circuitry that can't be dealt with without a chip fab with uncapping capabilities.
Don't forget #8: If Apple really wants to declare war on the JB scene, they could easily implement a tattle-tale device or some form of check to see if a phone is JB-ed or not. If so, its ESN gets banned off all networks, device reset, and because of this, it won't be able to be activated. Earlier iPhones could be hacktivated, but the 4 would be pretty much rendered into spare parts by this.
Knowing the right way to handle a zombie apocalypse may come in handy. Most people are quite unprepared, and will think someone murmuring "braiiins" is a political candidate canvassing the neighborhood for this election year.
Plus, a class like this is always a nice thing to take for an elective -- everyone loves a cold one.
TBH, the only thing that really helps with malware infections is having good backups, and a well practiced method of restoring data, either just grabbing a couple files, or a complete bare metal restore from boot media or a PXE server. The ideal media for backups is something that can be set to read-only like tapes or WORM media like optical. This way, malware can't alter the contents once written.
AV programs are nice, and sometimes they do catch a Trojan or two, but I've cleaned a lot of systems where the AV service was happily running side by side with the botnet client. Since a lot of new Windows malware encrypts sectors and parts of the OS to screw up safe mode booting, the only real way to get rid of a lot of infections is to save as much data off to an external drive, dd if=/dev/zero of=/dev/sda to completely zero out the drive (or even better HDDErase), repartition, and reinstall the OS and applications.
This is why I urge people to get a backup utility that is able to do backups daily automatically, preferably from a backup server.
I'd say that isn't the case. Exploits with browsers or add-ons can easily compromise a machine just as badly as an open port. Browser and add-on security is still in its infancy while network security has matured over a number of years. So even with the Maginot line of network stuff, all it takes is one add-on programmed by the lowest bidder to open internal systems wide open.
The only real fix I know of? AdBlock is your first line of defense. If you want to be sure, run your Web browsing in a VM whose changes get dumped when you finish a browsing session.
There are ways the US government can do some in advancing Internet security as a whole. Some that come to my mind (usual long list):
1: Subsidizing an OATH compatible OTP system. Perhaps get Aladdin/SafeNet or RSA to make tokens which support numbers that change every 30 seconds, and apps for devices. Now, a thief has to do more than just slurp a password to compromise a bank account. They would have to actively mess with the Web browser. This leads to #2.
2: A ZTIC-like system. This way, transactions are confirmed actively, so malware present on the system can't actively transfer money even if a bank account's password is compromised. This can be a hardware device, or a phone app.
3: Crypto contest for a RSA successor. RSA has stood strong, but another public key algorithm that is quantum computer resistant is needed. Of course, this isn't an easy task, compared to making symmetric key algos.
4: A backbone between businesses similar to NIPRnet, but for civilian transactions.
5: A civilian CAC for client certificates, with good mechanisms in place to deal with cards that are lost, stolen, locked out due to bad PIN retries, or accidentally microwaved.
6: SELinux's successor. Preferably a hybrid between it and AppArmor. The more technology in keeping applications to just what they need to run, the better.
7: This isn't directly Internet affecting, but perhaps find some R&D into backup technologies? It used to be a while back that companies were through about backups, and if you even thought about being a sysadmin, you knew how to do dumps, tars, full/incremental/differential backups, tape rotations (grandfather/father/son), offsite tapes, and so on. These days, people don't even bother with backups, and if they do, they think the cloud can do it, forgetting the time it takes to suck all that info back through a WAN connection on restore. Yes, backups are boring as all get-out, but in case other security measures fall apart, backups are what one uses to piece things back together.
RAM access is in nanoseconds (10^-9). HDD seek times are in milliseconds (10^-3) of a second. Registers are about 10 times as fast as RAM.
So, computers will have a massive speedup the less we use hard disks as part of the core computing cycles. Primary and "secondary" RAM for temporary and permanent storage, then have the HDD that runs with non-blocking DMA I/O in the background as a backup. This way, the hard disk's glacial speeds (relative to RAM access) are not slowing the machine down for day to day operations.
What I see as an attack vector are third party add-ons. You can have a secure browser, but if an add-on gets compromised, it is all for naught.
What it really will take is hooks to OS level protection for the Web browser. Microsoft got something right with the low security mode of IE7/IE8 in Vista/W7, but it would be good to be able to isolate add-ons completely from each other on the OS basis so they don't even share the same memory space as the browser, and absolutely no filesystem space, unless the user wants to save cache or objects (saved games or whatnot.) Essentially, the only thing most add-ons need is to be fed code from the Web page, and given space to render their interactive output.
That is why I use eTokens for my PGP keys. I have mine configured so a few guesses will lock the user password, a few more will lock the admin password and render the data on the token permanently unusable unless someone has a chip fab with uncapping facilities at their disposal.
Trick is to have multiple tokens, and at least two keys. One key is generated on the token, and another key is copied onto all the tokens. This way, one can encrypt data with just the token-generated keys, as well as use the key that was copied onto it as the private key for E-mail. Since all the keys are allowed to revoke each other, if one of the eTokens gets lost or destroyed, that key can be marked as unusable and life go on with the remaining cards.
Reducing the amount of guesses on a passphrase to only a few pretty much gets rid of the brute force issue. Of course, someone can rubber-hose the passphrase, but that is a different issue altogether.
Even better, why not go to a true PKI infrastructure?
User gets a smart card, the government certifies the smart card is his/hers, and other authorities sign certificates relating to that person (like the person graduated, is over the age of 21, is able to drive, is not a felon, etc.) For things like criminal record status, those certificates could be SLCs refreshed daily or hourly (which is better than worrying about a CRL mechanism.)
Lost smart card? The user previously saves a revocation certificate which is then pushed out, then the user gets another card and gets it re-signed with certificates.
This would be a privacy boon. A bar can scan the smart card, notice there is a cert saying the guy is over 21, and that is enough information under the law to allow someone to drink. No need to know the person's address, birth date, or other information.
Same with getting a job. There can be certificates saying the person isn't a felon, has graduated from college at a certain time, etc. No other prying info needs to be dug up, because those certs (assuming a solid CA trustworthiness chain) prove the critical bits of info.
Of course, this would kill ID theft. Someone applies for a bank account with someone's name, bank asks that a random nonce be signed with key id 0xdeadbeef with a fingerprint of $WHATEVER and a 8192 bit keylength. It is extremely doubtful the ID thief would be able to be able to sign the nonce. Instead, the thieves would have to attack the endpoints (cards and users), the PKI structure, or the crypto algorithms themselves in order to impersonate someone.
Depends which HP we are talking about. I'm hoping the HP of today is like the HP of the 80s and 90s with kick-butt research, calculators that could be used as bludgeons against the zombie hordes while still being able to calculate the critical numbers in building a bridge, PA-RISC workstations which were great performers, and the maker of unkillable printers (I know people who buy up LJ 3s and 4s that are 10+ year old, put them in service and they are still going strong.)
I'm just hoping this is the HP that is the HP of today.
Slashdot Mirror
This reminds me of an old 486 upgrade chip for the 386DX that was pin compatible. It would run the same speed as a 386DX, but one had to install a .SYS driver in MS-DOS to turn on the internal clock-doubling and such. No driver, no performance gain.
I wonder if it is the same stuff, where the CPU is fed some sequence to have it allow access to the full cache and such. Of course, I will be almost 100% sure that this driver will be not something open-sourced, so expect the performance boost by "unlocking" the chip to be only in Windows, and no other OS.
I just hope Intel doesn't spread this crap beyond the bottom of the barrel chips where profit margins are razor thin. For the low-end market where price is everything, maybe. However, for mainstream i5 and i5 chips, much less Xeons -- hell no.
That does make me curious... what embedded OS would something like this run? A version of INTEGRITY RTOS is probably my guess.
I can see these put into use for keeping communications operational, should the Kessler Syndrome come into play making LEO impassible (courtesy nations like China showing off their target practice skills and the resulting space debris).
Another use would be bandwidth for populated areas, so traffic wouldn't have to be bounced off a satellite just for region to region traffic.
I'd disagree with you about Android's Exchange support. As of 2.2, the only encryption Android supports is encrypting apps stored on the memory card. Android has no encryption support of data whatsoever, and this by itself is a deal killer.
Of course this can be easily remedied two ways: LUKS if one wanted to dedicate segments or an entire memory card for device level encryption, or CFS/EncFS based for file by file encryption similar to what Windows Mobile 6.0 and newer does on the memory card.
Of course, this aside, even if the Android's Exchange support is lackluster, TouchDown picks up where the device might have left off, but the lack of data encryption is a big demerit for Android devices in the enterprise.
I wonder how long a card like this will last in an average wallet, perhaps facing demagnetization, wear and tear, and other issues of being in a pocket and constantly jostled around.
However, it it can handle that, this could be a great thing to have, as not just a credit card, but as an authentication device. Punch your PIN, punch a challenge phrase, give the vendor the response, and that will do a lot to minimize credit card fraud.
Of course, skimmers with cameras will still be an issue -- just videotape the person typing on the card and not the PINpad, and if it uses an active cryptographic handshake, run a MITM attack.
The $50,000 question: What can Windows Phone 7 come up with that nobody else has, and make people willing to be locked via contract to two years with the device?
Before Windows Phone 7, WM was a great and extremely secure OS, next to BlackberryOS. It supported remote kills, encrypted the memory card in a simple, but elegant and secure fashion, allowed one to reset their password if forgotten on the road, supported a lot of applications (when Handango was the main way to purchase mobile programs), was easy to program for, and so on.
It is understandable that Microsoft wants to go from an open courtyard to a walled garden, especially with all the brickbats they have taken over the years (deserved and undeserved [1].)
As of now, we have a number of distinct platforms for writing smartphone apps, and each is different from each other by a large degree: We have Objective C for iOS, Java for Android/BlackberryOS, XNA or Silverlight for Windows Phone 7, and C++ for Symbian (IIRC). XBox coders will be fine with XNA for the platform, but iOS and Android app writers will not bother because it is a completely different platform and architecture.
Developers are looking at the numbers right now and growth rates. If I were to place my bets on a business application, it would be the tried and true BlackberryOS. If I wanted business users and consumers, it would be iOS. If I wanted consumers and some small business, Android. Where does Microsoft fit in here?
There is one niche I see Windows Phone 7 will be good for is Exchange support. I'm sure it will support encryption, remote kill, password changes, password complexity, and all that. However, is superb Exchange support good enough to get the phone into the enterprise, jostling out Blackberries and iPhones [2]? IMHO, it needs more than that to be a viable platform.
Microsoft makes some high quality products, but that isn't good enough. They have to grab market from entrenched companies and fight with Android for customers, both business and end user. I can see MS gunning at RIM for the enterprise users, but they have a fight on their hands for other markets.
[1]: A lot of Windows problems are not Microsoft's fault. They are due to application developers who do the absolute minimum to get code shipped with security as a distant afterthought. I'm sure there would be a lot fewer cases of compromised Windows PCs if application developers wrote their code to not crash if DEP was turned on globally, and allowed ASLR to function.
[2]: Apple is getting better with encryption, especially for Exchange. The only thing the iPhone is missing is the ability to set it so it erases itself if it does not get a network signal after "X" amount of time like Blackberries do. Similar with functionality to erase itself if the SIM card is removed or changed out.
Nope, more likely it will call the police when it senses what you want to do to the person on the other end of the line after you just transferred for the fifth time, been on hold for six hours, and have everyone from your boss to the CEO staring you down at your desk.
The Netapp box does a lot more than deduping:
1: The newer models come with 512GB-1TB of SSD, and automatically place data either on the SSD, the FC drives, or the SATA platters depending on how much it is used. If the chunk of data is used all the time, it sits on the SSD. This helps a lot with the bottleneck of a lot of machines needing to access the same data block with deduplication. This is different from other disk solutions, as the NetApp chooses the "tier" of disk for you. However, a lot of servers don't put out the throughput requiring someone to select between T1 and T2 disks, so for this, the NetApp is fine. Carve your LUNs out, carry on.
2: NetApp's WAFL system has been around saving butts for a long time. People don't realize this until you walk in and see that a junior admin blew away /net, and is looking at you with the deer in the headlight glance. A quick move from a snapshot directory, and nobody is the wiser.
3: You can put two NetApp SAN clusters in two geographically disparate locations and have them send changes via the WAN. This way, DR can be automated and made quite fast.
4: SANs are a lot more than just a bunch of disks shoved in a rack. They tend to be very intelligent of where data is placed, and on the backend, at least use RAID 6, where more than two drives have to fail at the same time for data to get lost. Almost all have multiple controllers, so if one path via the network fabric gets stomped on, machines are still able to access their LUN via the second one.
This isn't to say the NetApp is for everyone. If someone just needs a bunch of disk and no other features, a BackBlaze pod or a tower full of eSATA JBOD drives may be good enough. However, if one has a number of machines and is doing large amounts of random I/O, having an enterprise grade SAN goes without saying.
The US is lucky in one respect: Unlike most of Europe where citizens 18-20 have to go into the army or other duty for two years, US citizens really only have two duties: Jury duty and voting. No, there is no law forcing people to the polls, but by not voting, people are letting people who are likely dumber than themselves, or the lobbyists and their ad firms behind the attack ads decide the election.
If you are a US citizen, vote. If you like neither candidate, write someone in. It doesn't matter what side you are on, just go, do your research for the candidates, and go vote. /rant.
Also, is this over a 3G/3.5G with separate data and voice, or true 4G where everything gets packetized and pushed over IP? I might be able to see someone with Exchange who gets a lot of Excel spreadsheets pushed to their device having more network traffic than a voice call, but a push or IMAP IDLE notification doesn't take that much bandwidth by itself.
And guess what the lusers will do? They will beg Congress for more laws to "protect" them from the evil bogeyman, or put the blame on Microsoft for having an "insecure" OS. In reality, the only OSes can protect against the Dancing Bunnies security issue are closed and locked operating systems.
Ultimately, due to Joe Sixpack and Trojans that the future of desktop operating systems eventually will look like ChromeOS or iOS. No root or administrative access anywhere to be found (even for clued users), perhaps some rudimentary multi-user capability, but there will be no "#" prompt to be found anywhere. Development machines will either be special machines that are unlocked, or will run a hypervisor. You won't find a true root/Administrator level access anywhere, except enterprise level servers. Machines will enforce this by not booting from OS media unless the OS image is signed, and the OS volumes (C: for Windows, / and /usr) for UNIX will be encrypted, unlocked by the TPM on boot.
Apple also might not have the resources to support another language. Objective-C is essentially Apple's (Well, technically NeXT's) baby, so if Apple decides to make a language change, it is their decision, and theirs alone. If Apple wanted to start using BEGIN and END statements a la Pascal in the next objective-c release, they can and nobody can tell them otherwise.
By absorbing Flash and making it a supported language, Apple would either have to walk lock-step behind Adobe with every change they do to ActionScript, or fork and have a version that "mostly" works, forcing developers to have to make sure they don't do something that isn't supported, or may cause a crash or incompatibilities later on.
Instead, what would seriously sell would be the ability to take Java bytecode made to run in the Dalvik VM for Android, and convert that into Objective-C source code. Of course, this is a lot harder than it sounds, but if someone is able to make a tool like this where software companies can have essentially one code base for Android and iOS, it would rake in the cash big time.
App pirates are the bane of the Apple Dev Team, the JB scene, the Android modding scene, application writers, and end users.
What I want to see is Apple having an anti-piracy mechanism separate from the jail. Android's method of checking if the user is licensed is good. I have another proposal as well:
During the legit app install process, the app sends a SHA-256 hash of the IMEI or device ID of the device it is running on to Apple. It gets a signed certificate back similar to how Apple does the SHSH process for OS revisions. Then on future runs of the app, it just checks the ID versus the cert and if it doesn't match, checks the app store if it is authorized to run. If not, it prompts the user to be purchased. Of course, there are ways around this with ease, but this forces the app pirates to crack every app and every update.
There is also the plausible deniability aspect. Say someone manages to find a remote hole into the iPhone and grabs confidential information. If the phone is not jailbroken, the person shrugs, says to blame Apple because his device has been enforcing Exchange policies including remote kill switches. If it is JB-ed, regardless of the quality of Cydia and other items, the blame will stop with the employee because "he hacked his phone."
It is also mathematically impossible to make a 100% secure symmetric crypto algorithm if the key is shorter than the data being enciphered. However, we can make something that won't be broken even after the universe dies a heat death.
Same with devices. Look at the PS3. It took 5 years for any notable breaks to happen, and as time goes on, it will become harder and harder because it will be easier to embed the critical startup keys in layers of epoxy and tamper-resistant circuitry that can't be dealt with without a chip fab with uncapping capabilities.
Don't forget #8: If Apple really wants to declare war on the JB scene, they could easily implement a tattle-tale device or some form of check to see if a phone is JB-ed or not. If so, its ESN gets banned off all networks, device reset, and because of this, it won't be able to be activated. Earlier iPhones could be hacktivated, but the 4 would be pretty much rendered into spare parts by this.
Knowing the right way to handle a zombie apocalypse may come in handy. Most people are quite unprepared, and will think someone murmuring "braiiins" is a political candidate canvassing the neighborhood for this election year.
Plus, a class like this is always a nice thing to take for an elective -- everyone loves a cold one.
TBH, the only thing that really helps with malware infections is having good backups, and a well practiced method of restoring data, either just grabbing a couple files, or a complete bare metal restore from boot media or a PXE server. The ideal media for backups is something that can be set to read-only like tapes or WORM media like optical. This way, malware can't alter the contents once written.
AV programs are nice, and sometimes they do catch a Trojan or two, but I've cleaned a lot of systems where the AV service was happily running side by side with the botnet client. Since a lot of new Windows malware encrypts sectors and parts of the OS to screw up safe mode booting, the only real way to get rid of a lot of infections is to save as much data off to an external drive, dd if=/dev/zero of=/dev/sda to completely zero out the drive (or even better HDDErase), repartition, and reinstall the OS and applications.
This is why I urge people to get a backup utility that is able to do backups daily automatically, preferably from a backup server.
I'd say that isn't the case. Exploits with browsers or add-ons can easily compromise a machine just as badly as an open port. Browser and add-on security is still in its infancy while network security has matured over a number of years. So even with the Maginot line of network stuff, all it takes is one add-on programmed by the lowest bidder to open internal systems wide open.
The only real fix I know of? AdBlock is your first line of defense. If you want to be sure, run your Web browsing in a VM whose changes get dumped when you finish a browsing session.
There are ways the US government can do some in advancing Internet security as a whole. Some that come to my mind (usual long list):
1: Subsidizing an OATH compatible OTP system. Perhaps get Aladdin/SafeNet or RSA to make tokens which support numbers that change every 30 seconds, and apps for devices. Now, a thief has to do more than just slurp a password to compromise a bank account. They would have to actively mess with the Web browser. This leads to #2.
2: A ZTIC-like system. This way, transactions are confirmed actively, so malware present on the system can't actively transfer money even if a bank account's password is compromised. This can be a hardware device, or a phone app.
3: Crypto contest for a RSA successor. RSA has stood strong, but another public key algorithm that is quantum computer resistant is needed. Of course, this isn't an easy task, compared to making symmetric key algos.
4: A backbone between businesses similar to NIPRnet, but for civilian transactions.
5: A civilian CAC for client certificates, with good mechanisms in place to deal with cards that are lost, stolen, locked out due to bad PIN retries, or accidentally microwaved.
6: SELinux's successor. Preferably a hybrid between it and AppArmor. The more technology in keeping applications to just what they need to run, the better.
7: This isn't directly Internet affecting, but perhaps find some R&D into backup technologies? It used to be a while back that companies were through about backups, and if you even thought about being a sysadmin, you knew how to do dumps, tars, full/incremental/differential backups, tape rotations (grandfather/father/son), offsite tapes, and so on. These days, people don't even bother with backups, and if they do, they think the cloud can do it, forgetting the time it takes to suck all that info back through a WAN connection on restore. Yes, backups are boring as all get-out, but in case other security measures fall apart, backups are what one uses to piece things back together.
I should rephrase:
RAM access is in nanoseconds (10^-9). HDD seek times are in milliseconds (10^-3) of a second. Registers are about 10 times as fast as RAM.
So, computers will have a massive speedup the less we use hard disks as part of the core computing cycles. Primary and "secondary" RAM for temporary and permanent storage, then have the HDD that runs with non-blocking DMA I/O in the background as a backup. This way, the hard disk's glacial speeds (relative to RAM access) are not slowing the machine down for day to day operations.
What I see as an attack vector are third party add-ons. You can have a secure browser, but if an add-on gets compromised, it is all for naught.
What it really will take is hooks to OS level protection for the Web browser. Microsoft got something right with the low security mode of IE7/IE8 in Vista/W7, but it would be good to be able to isolate add-ons completely from each other on the OS basis so they don't even share the same memory space as the browser, and absolutely no filesystem space, unless the user wants to save cache or objects (saved games or whatnot.) Essentially, the only thing most add-ons need is to be fed code from the Web page, and given space to render their interactive output.
That is why I use eTokens for my PGP keys. I have mine configured so a few guesses will lock the user password, a few more will lock the admin password and render the data on the token permanently unusable unless someone has a chip fab with uncapping facilities at their disposal.
Trick is to have multiple tokens, and at least two keys. One key is generated on the token, and another key is copied onto all the tokens. This way, one can encrypt data with just the token-generated keys, as well as use the key that was copied onto it as the private key for E-mail. Since all the keys are allowed to revoke each other, if one of the eTokens gets lost or destroyed, that key can be marked as unusable and life go on with the remaining cards.
Reducing the amount of guesses on a passphrase to only a few pretty much gets rid of the brute force issue. Of course, someone can rubber-hose the passphrase, but that is a different issue altogether.
Even better, why not go to a true PKI infrastructure?
User gets a smart card, the government certifies the smart card is his/hers, and other authorities sign certificates relating to that person (like the person graduated, is over the age of 21, is able to drive, is not a felon, etc.) For things like criminal record status, those certificates could be SLCs refreshed daily or hourly (which is better than worrying about a CRL mechanism.)
Lost smart card? The user previously saves a revocation certificate which is then pushed out, then the user gets another card and gets it re-signed with certificates.
This would be a privacy boon. A bar can scan the smart card, notice there is a cert saying the guy is over 21, and that is enough information under the law to allow someone to drink. No need to know the person's address, birth date, or other information.
Same with getting a job. There can be certificates saying the person isn't a felon, has graduated from college at a certain time, etc. No other prying info needs to be dug up, because those certs (assuming a solid CA trustworthiness chain) prove the critical bits of info.
Of course, this would kill ID theft. Someone applies for a bank account with someone's name, bank asks that a random nonce be signed with key id 0xdeadbeef with a fingerprint of $WHATEVER and a 8192 bit keylength. It is extremely doubtful the ID thief would be able to be able to sign the nonce. Instead, the thieves would have to attack the endpoints (cards and users), the PKI structure, or the crypto algorithms themselves in order to impersonate someone.
Depends which HP we are talking about. I'm hoping the HP of today is like the HP of the 80s and 90s with kick-butt research, calculators that could be used as bludgeons against the zombie hordes while still being able to calculate the critical numbers in building a bridge, PA-RISC workstations which were great performers, and the maker of unkillable printers (I know people who buy up LJ 3s and 4s that are 10+ year old, put them in service and they are still going strong.)
I'm just hoping this is the HP that is the HP of today.