While the question could have been phrased better, it isn't as simple as you make it out to be.
You know that the starting velocity is zeroish(maybe a little bit of taxiing; but negligible) and that the end velocity is 240mph; this makes calculating average acceleration over those 300 feet trivial; but it doesn't much help you in determing the actual shape of the acceleration/time graph.
It is quite possible, for instance, that an electrical system has a nearly perfectly constant acceleration, while getting the same out of a steam driven system(whose volume is presumably changing continuously) would be some fairly tricky plumbing.
From an airframe maintenance perspective, I assume that it is the sharp spikes of peak acceleration that cause the most trouble, and those are what a system capable of neatly constant acceleration could avoid...
Multiple factors are certainly useful, it's just that biometrics are a really shitty one, with more dangers than upsides.
Passwords are pitifully weak; but at least they are trivially changable and may be generated in numbers limited only by your patience.
Crypto keys are like passwords; but without the weakness, it's just that standard pattern humans are essentially incapable of memorizing them. A promising candidate for building physical tokens on; but impractical on their own.
Biometrics are somewhat more entropic than most passwords; but the number that any one person can possess is strictly limited and pretty much not subject to change, barring surgery or maiming. Also, they are extremely difficult to "turn off". Your fingerprints are all over the place. You shed DNA in PCR-able quantities constantly. Were biometrics to become common, you would simply trust several scanners a day to not be gathering enough data to spoof you, rather than just enough to authenticate you.
For remote use, biometrics have to be crunched down into a number, typically somewhere between a password and a crypto key in strength; because you can't exactly send an iris over the network. No better than a smartcard, RSA key, etc. save being a bit harder to lose.
The only thing biometrics are good for is making it even easier to track people, which is hardly a laudable goal.
How cute. The WSJ has dug up somebody who thinks that only governments are capable of "regulation".
States generally reserve the most dramatic flavor of regulation for themselves "Don't do X, or men with guns will put you in a cage"; but corporations, particularly monopolists and oligopolists, are easily capable of exerting influence on par with fines, taxation, censorship and almost any other flavor of regulation short of that promising imprisonment or death....
Biometrics are pretty dubious for widespread use. They sure do add that "just like the movies" flavor to flashy secure facilities(and, as long as their use is rare, they are likely to be stolen only in the most targeted of attacks); but the majority of them are dangerously weak(and impossible to change).
Were they to be used widely, it would be a matter of months before huge numbers of people had their biometric data skimmed with enough resolution that fakes could be constructed with relative ease(imagine the problem of ATM card skimmer devices, already cheap and common, spreading to biometric verification systems: is that "broken" biometric verification setup on the door/atm/whatever actually broken, or transmitting high resolution scans of your fingerprints to some gang even now?) If you do get skimmed, what are you going to do about it?
As long as they are largely a novelty, confined to a few specific situations, you really have to be Somebody Important for your prints to be pulled off your glass at the bar and used to access your system; but, if you try to use it at a population level, the probability that attacks will become widespread rises enormously.
Oh, I explicitly acknowledged that the present situation is kind of gross; but the world is full of bad software being made to work well enough for use by means of external hacks catering to its weaknesses.
Unless dealing with OSS you know well enough to fix without breaking, or a vendor who actually gives a fuck about you, the cost/benefit for appeasing unreasonable black-boxes is generally better than that of trying to beat them into submission directly. Makes purists cry; but it gets stuff done.
Trouble is, it isn't an either-or. Mathematics makes perfectly good philosophy fodder; but it is also quite useful in designing seeker algorithms for your totalitarian killbot. And the equilibrium between philosophers and totalitarian killbots is not a stable one...
I would hope, for any remotely adequate mechanical engineer or industrial designer, (or heck, even an interior designer) "potential wear, degradation, and derating of the surface coatings on parts in mechanical contact" wouldn't even fall into the category of "reacting to a 'can't happen' condition; but simply count as standard diligence.
Now, I can imagine the organizational dysfunction where the guy speccing finishes might be told "low cost, attractive, applies to metal and aesthetically compatible with leather", without being told that his finish really has to be dielectrically stable for the lifetime of the product, while, at the same time, the guy who knows that the hooks must not short the device has no say in the finish selection...
The flaw is certainly in the cover(using two physically separated hooks, rather than a single piece of metal, would not have been rocket surgery and would have provided dielectric strength high enough to resist pretty much any voltage that wouldn't also kill the user.) However, we really have no way of knowing whether the cover maker failed to follow amazon's orders, whether amazon failed to issue the correct orders, or who was responsible for considering the situation where the + hook and the - hook are not separated by an LED and current limiting resistor.
If amazon didn't think about it, or naively thought that a thin layer of cheap paint would do, they fucked up. If the cover maker looked at a design document that said "Connecting hooks must be electrically separate" and said "eh, one painted part is cheaper than two physically disconnected parts, paint'll do." then they fucked up.
Obviously it is pretty hacky for a game to make specific demands concerning filesystem/OS configuration(with things like Big Serious Applications it is at least expected, if annoying); but it sounds like the present save format is a problem that could be solved with a RAMdisk...
Not the crazy-expensive hardware kind, just a software one carved out of system RAM. If an entire world-state is only 10ish MB, you could store plenty on just a small slice of any reasonably modern system's RAM, and that should take care of the speed problems. You would want to dump to disk from time to time, to avoid issues in the event of power loss; but doing a block-level dump of the entire RAMdisk to a single image file on HDD should, again, be pretty fast for smallish RAMdisks...
Yours is actually a pretty good argument for this sort of 'price-increases-as-development-progresses' model, which I've seen with a few other indy game titles as well.
At some point in development, the product is polished enough to be worth playing around with, to some people, and isn't totally, egregiously crashy. Release at a low price, with those caveats noted. Those who wish can pay less, track progress from this point forward; but know that they are putting up with bugs and the risk that development will stall.
As development progresses, the price gradually goes up; because the product is better and the risk that the product will never reach 1.0 has declined. At 1.0(obviously, numbering conventions vary, some products aren't "1.0" until about "3.5 SP4"; but "1.0" as in "finished") charge full price.
Especially in recreational markets there is nothing wrong with selling inferior or unfinished goods; provided that you are honest about what you are selling...
I'd assume that(barring the existence of some sort of unlock-for-registered-owner mechanism, which wouldn't be impossible) the point isn't to help you, the one specific person whose laptop just got stolen; but to gradually phase "stealing laptops" out of the list of things that are economically viable by upping the odds that the thief will get nothing but a brick for their time...
They may well have added some 3G-related silicon; but the CPU is very much inside the "shielded to keep the FCC off our backs" compartment of basically all systems. I assume that they simply baked the necessary hooks into their CPU/chipset for the system to interact with the cell modem, even if turned "off" and brick itself if so ordered.
Architecturally, I'm assuming that this builds on Intel's "Active Management" integrated service processor, which has been featured in mostly corporate models, with gradually increasing capabilities, for some years now.
Well, it finally gives us the technological basis for the "Fritz chip" that the geriatric pawn of the media cartels of the same name wanted back in the day. Progress!
Don't worry, just as the TPM ultimately trusts the user, rather than hiding its secrets even from its owner, I'm sure this system is 100% aligned with the owner's interests and has no other uses...
While I ordinarily find the "zOMG correlation != causation" brigade to be a trifle tiresome, there is a good bit of evidence from other studies that people find ideologically conformant information comfortable and ideologically nonconformant information uncomfortable(albeit to varying degrees: your fundamentalist of any stripe can barely restrain himself frothing at the mouth over the fact that nonconformant information even exists. Joe user just tends to change the channel).
Now that there is a media outlet for almost any political persuasion, it is quite reasonable to suspect that people are congregating around channels reporting from their preferred reality. Trouble is, of course, that there is only one reality actually out there, and it has numerous pitfalls and teeth. We ignore it at our peril.
Under cover of darkness, employees of the Museum of Natural history broke in and appropriated the exhibit to add to their world-renowned dinosaur collection...
It is true that DRM is pretty much hopeless(though some DRM is less hopeless than other DRM) and, more importantly, Netflix streaming is about the lousiest possible source for piracy, even if it was entirely open: streamed at real time only, from a catalog of stuff that studios deem low-value enough to licence for peanuts(if Netflix can afford to let you stream an unlimited amount for $7 a month, the licensing can't be costing them much, on top of bandwidth and storage). Never mind the fact that quality can drift unpredictably, depending on the bitrate that the streaming client thinks you are currently capable of.
As an attack source, even if totally unsecured, netflix streaming is about as attractive as analog video tapes. Somehow, the studios still insist. Even with DVDs, which are known to be broken to hell and back, they still keep slapping CSS on them, despite the obvious futility.
I'm not saying that DRM actually works; but just that studio DRM requirements will prevent an OSS netflix streamer more or less forever.
The summary makes the incredibly naive and misleading mistake of conflating online trial-and-error attacks with offline hash attacks.
Against a system you do not control, the system has total power over how frequently you may try a username/password combination, how informative it is about your success/failure(ie. does it just say "no" does it say "wrong password" does it say "username not recognized"?), as well as being able to, if it wishes, just start ignoring all attempts from your IP/terminal or all attempts against a specific account(subject to the risk of denial of service techniques exploiting this). In this scenario, the difference between a terrible password and an OK password is enormous. The 12345 or 'password' are quite likely to be simple enough to crack by trial and error, even against a remote system. Modestly more complex ones will either be impossible or require days/weeks of low-speed guessing, or careful guessing from multiple hosts.
With an offline hash attack, you have total control over the hashes, and the only limiting factor in how fast you can attack them is your computer(and hash attacks generally parallelize really well). Here, the difference between a terrible password and a merely mediocre one will likely be less than the refresh rate of the attacker's monitor, and the difference between an OK password and a superb one will still be fairly small. Only a password so good that it is basically a nonstandardized type of private key will be of any use. However, offline hash attacks only happen against compromized systems, you can't get the hash table otherwise. They are an excellent argument for not re-using passwords, since systems get cracked all the time; but they are of only limited relevance in discussing the importance of password complexity, or lack thereof, for online attack scenarios...
That ChromeOS is not necessarily going on to the brightest of futures; but that it serves a number of valuable purposes to Google:
1. Serious 'dogfooding': Google's business is pushing 'web' and 'webapps' and whatnot, both to sell adsense impressions and to steal MS's lunch money to keep them from subsidizing their search arm until it becomes a real threat. Building an OS around this exclusively allows them to bundle in a few neat features(widespread single sign on without a corporate IT team, some interesting security/sandboxing stuff, easy restoration/backup) and also forces them to think carefully about how all common user use cases can be addressed in a 'web' way. Does HTML5 need something else? Do we have to get serious about NaCl? Is Flash still necessary, etc. Assuming the program doesn't rack up serious losses, it makes sense as an R&D project.
2. Possible basis for moving Android applications/features into larger form factors: I can imagine two possibilities: 1. ChromeOS, as noted above, is an R&D project about what a web browser needs to be able to do to fulfill the desired use cases. Android has a web browser. Therefore, roll what you've learned into Android's web browser and call it a day. 2. Android, in effect, consists of a java-esque(but don't call it Java(tm)) bunch of applications running in a VM on top of a relatively spare linux base. ChromeOS consists of a browser running on top of a fairly spare linux base. It would not exactly be rocket surgery to use the browser/HTML as a "windowing environment" in which dalvik VM applications from Android can be embedded, just like the Java applets of old. Throw in a way for the user to full-screen an embed, if it is designed for a larger screen, integrate Android's notifications into the system(given the R&D about sandboxing and security in the browser, in point #1, you could conceivably allow the Dalvik embeds to interact with the DOM of the page, present Android system notifications/address book, etc. as JS accessible elements, etc.)
3. The "big business IT for small business" pitch: With a competent IT team, and some investments in servers and AD and stuff, an enterprise IT department can already to centralized data storage, remote application access, single sign on, etc. If you have enough users, the cost/user isn't bad; but it isn't trivial, and there some costs that are fixed enough that things get more expensive in $/user, as you get smaller. So, a lot of small outfits basically make do either with painfully expensive consultant setups-and-pray-it-doesn't-break-so-we-don't-have-to-call-him-back or seriously ghastly "just a bunch of computers and some good luck, plus sneakernet". So, Google says: "Hey, subscribe to Google Apps for business for $/person/year and get all Google apps, a Gmail storage and interface for mail from your own domain, and seamless single sign on and backup on any "ChromeOS" device on the market! Since the hardware requirements are low, our numerous hardware partners have netbooks, laptops, desktops, even virtualized option cards for full laptops(analogous to Dell's "Latitude ON" card). If one breaks, just toss it and get another one, you'll be back up and running in 10 minutes just by opening the box and typing in your username and password. No IT guy!(except to keep your network up...)"
The DoD has actually been somewhat more active than the government generally in alt-energy research.
Partially, I'd assume that this stems from the simple fact that, when your oil products have to be shipped to you through hostile territory, you are already experiencing the sorts of prices that peak oilers have in mind(never mind something really dramatic, like enemy infiltrators blowing a few gulf coast refineries just before starting a hot war...)
Partially, I'd assume that it stems from the fact that the military has years of experience with blowing off popular opinion. Politically, admitting anything more than "Maybe we'll have to switch from oil to Clean Coal: America's Power(tm) to sustain our God-given lifestyle" will get you lynched and not reelected. Within military R&D circles, you have a better chance of hiding behind the flag and getting your work done.
That, in addition to OSS's usual superiority on the server side vs. the desktop side, there is the ugly-but-not-at-all-little-for-Netflix issue of DRM.
You cannot build a DRM system that is both "OSS" in any useful sense and effective(you can certainly use OSS parts; but ultimately there will have to be a proprietary obfuscated portion or hardware tivoization and/or secrets if the DRM is to be more than a toy, disabled by using the --obey_DRM=no build option). There is simply no compromise to be had here. DRM attacks user freedom, OSS promotes it. Regardless of your stance on the validity of one or the other, they are not compatible.
Somebody with server operations on the scale of Netflix would be insane to not be using OSS, and it certainly never hurts to cultivate a good relationship with your suppliers; but we can expect an OSS client at approximately the point the sun expands and engulfs the inner planets(or when chinese holocube knockoffs with a bit-for-bit blu-ray rip of every movie ever made are selling for $10 on every street corner, at which point the studios might finally realize that stopping people from ripping streams is hardly worth the trouble). A tivoized linux client device has already been available for some time, and a proprietary client for linux might even appear, should linux get the market share needed; but OSS, not so much.
While I don't like Google any more than you do, I'm less worried about Android. Only a subset of Android devices are tied to Google in any useful way. Since Android is available as a largely apache licenced middleware stack for the GPLed kernel(plus whatever proprietary apps and drivers the vendor feels like shipping), assorted "Android" devices have sprung up like mushrooms that are about as connected to Google as a Gentoo box is to Linus Torvalds. By contrast, every box of Windows sold is money right into Redomond's coffers and, as of now, isn't shy about phoning home.
The real problem will be expectations RE: 3rd party applications. "Android" succeeds, in part, on very non-PC-like hardware because it promises nothing about support for historical linux applications(plus, the only historical applications tend to either be server stuff, that you wouldn't run on a tablet except as a stunt, or geek stuff that geeks are welcome to try to get working if they want to).
Windows, on the other hand, has a huge amount of well known legacy applications, and when a product is sold as "Windows" people expect that it, and the disk they just got at best buy, will work on it. Trouble is, the vast majority of those 3rd party applications will suck without a proper mouse and keyboard. Not much MS can do about that.
There isn't anything much wrong with the NT kernel(I'm sure hardcore geeks and purists could pick some nits; but the same could be said of linux.), nor does MS have no ability to design a new touchable shell; but making 3rd party stuff not just tear you out of that shell and poke you in the eye with how much they suck would be somewhere between heroic and impossible.
This, I suspect, is why Apple, with their iPhone, Google(de facto, they don't actually stop you) with Android, and MS with Windows Phone 7, enacted a "no legacy" policy.
Even better than a secret algorithm, which are generally bad juju, you might as well just use well-known and well tested cryptographic techniques: Each unit's service backdoor would be its MAC address, signed with an HP private key(stored with the same care reserved for SSL root certs and the like). The unit would just have to know its own MAC address and HP's public key to be able to verify the validity of the signature...
While there is a logical place for support accounts, particularly with fancy enterprise junk where phoning home to the mothership when things go sour is considered a feature; but hardcoded passwords are an amazingly stupid way of setting them up.
Even a superb hardcoded password is going to sneak out eventually, even if only after the units start to be scrapped(but before all of them leave production). At a bare minimum, the hardcoded password would have to be unique per unit. Even better, use something like a cryptographic challenge/response system, so even an attacker with silicon level access can only learn HP's public key, which is useless, and HP can still do their thing.
Because of the needs of humans, passwords have their place; but for anything automated/serious, cryptographic techniques are the only way to go. Anything else is pitifully amateurish.
Or, in what can only have been a black joke on Redmond's part, Microsoft's "Rights Management Services"... Somebody was stroking a white cat and laughing insanely when they hit upon that one...
Slashdot Mirror
While the question could have been phrased better, it isn't as simple as you make it out to be.
You know that the starting velocity is zeroish(maybe a little bit of taxiing; but negligible) and that the end velocity is 240mph; this makes calculating average acceleration over those 300 feet trivial; but it doesn't much help you in determing the actual shape of the acceleration/time graph.
It is quite possible, for instance, that an electrical system has a nearly perfectly constant acceleration, while getting the same out of a steam driven system(whose volume is presumably changing continuously) would be some fairly tricky plumbing.
From an airframe maintenance perspective, I assume that it is the sharp spikes of peak acceleration that cause the most trouble, and those are what a system capable of neatly constant acceleration could avoid...
Multiple factors are certainly useful, it's just that biometrics are a really shitty one, with more dangers than upsides.
Passwords are pitifully weak; but at least they are trivially changable and may be generated in numbers limited only by your patience.
Crypto keys are like passwords; but without the weakness, it's just that standard pattern humans are essentially incapable of memorizing them. A promising candidate for building physical tokens on; but impractical on their own.
Biometrics are somewhat more entropic than most passwords; but the number that any one person can possess is strictly limited and pretty much not subject to change, barring surgery or maiming. Also, they are extremely difficult to "turn off". Your fingerprints are all over the place. You shed DNA in PCR-able quantities constantly. Were biometrics to become common, you would simply trust several scanners a day to not be gathering enough data to spoof you, rather than just enough to authenticate you.
For remote use, biometrics have to be crunched down into a number, typically somewhere between a password and a crypto key in strength; because you can't exactly send an iris over the network. No better than a smartcard, RSA key, etc. save being a bit harder to lose.
The only thing biometrics are good for is making it even easier to track people, which is hardly a laudable goal.
How cute. The WSJ has dug up somebody who thinks that only governments are capable of "regulation".
States generally reserve the most dramatic flavor of regulation for themselves "Don't do X, or men with guns will put you in a cage"; but corporations, particularly monopolists and oligopolists, are easily capable of exerting influence on par with fines, taxation, censorship and almost any other flavor of regulation short of that promising imprisonment or death....
Biometrics are pretty dubious for widespread use. They sure do add that "just like the movies" flavor to flashy secure facilities(and, as long as their use is rare, they are likely to be stolen only in the most targeted of attacks); but the majority of them are dangerously weak(and impossible to change).
Were they to be used widely, it would be a matter of months before huge numbers of people had their biometric data skimmed with enough resolution that fakes could be constructed with relative ease(imagine the problem of ATM card skimmer devices, already cheap and common, spreading to biometric verification systems: is that "broken" biometric verification setup on the door/atm/whatever actually broken, or transmitting high resolution scans of your fingerprints to some gang even now?) If you do get skimmed, what are you going to do about it?
As long as they are largely a novelty, confined to a few specific situations, you really have to be Somebody Important for your prints to be pulled off your glass at the bar and used to access your system; but, if you try to use it at a population level, the probability that attacks will become widespread rises enormously.
Oh, I explicitly acknowledged that the present situation is kind of gross; but the world is full of bad software being made to work well enough for use by means of external hacks catering to its weaknesses.
Unless dealing with OSS you know well enough to fix without breaking, or a vendor who actually gives a fuck about you, the cost/benefit for appeasing unreasonable black-boxes is generally better than that of trying to beat them into submission directly. Makes purists cry; but it gets stuff done.
Trouble is, it isn't an either-or. Mathematics makes perfectly good philosophy fodder; but it is also quite useful in designing seeker algorithms for your totalitarian killbot. And the equilibrium between philosophers and totalitarian killbots is not a stable one...
I would hope, for any remotely adequate mechanical engineer or industrial designer, (or heck, even an interior designer) "potential wear, degradation, and derating of the surface coatings on parts in mechanical contact" wouldn't even fall into the category of "reacting to a 'can't happen' condition; but simply count as standard diligence.
Now, I can imagine the organizational dysfunction where the guy speccing finishes might be told "low cost, attractive, applies to metal and aesthetically compatible with leather", without being told that his finish really has to be dielectrically stable for the lifetime of the product, while, at the same time, the guy who knows that the hooks must not short the device has no say in the finish selection...
The flaw is certainly in the cover(using two physically separated hooks, rather than a single piece of metal, would not have been rocket surgery and would have provided dielectric strength high enough to resist pretty much any voltage that wouldn't also kill the user.) However, we really have no way of knowing whether the cover maker failed to follow amazon's orders, whether amazon failed to issue the correct orders, or who was responsible for considering the situation where the + hook and the - hook are not separated by an LED and current limiting resistor.
If amazon didn't think about it, or naively thought that a thin layer of cheap paint would do, they fucked up. If the cover maker looked at a design document that said "Connecting hooks must be electrically separate" and said "eh, one painted part is cheaper than two physically disconnected parts, paint'll do." then they fucked up.
Obviously it is pretty hacky for a game to make specific demands concerning filesystem/OS configuration(with things like Big Serious Applications it is at least expected, if annoying); but it sounds like the present save format is a problem that could be solved with a RAMdisk...
Not the crazy-expensive hardware kind, just a software one carved out of system RAM. If an entire world-state is only 10ish MB, you could store plenty on just a small slice of any reasonably modern system's RAM, and that should take care of the speed problems. You would want to dump to disk from time to time, to avoid issues in the event of power loss; but doing a block-level dump of the entire RAMdisk to a single image file on HDD should, again, be pretty fast for smallish RAMdisks...
Yours is actually a pretty good argument for this sort of 'price-increases-as-development-progresses' model, which I've seen with a few other indy game titles as well.
At some point in development, the product is polished enough to be worth playing around with, to some people, and isn't totally, egregiously crashy. Release at a low price, with those caveats noted. Those who wish can pay less, track progress from this point forward; but know that they are putting up with bugs and the risk that development will stall.
As development progresses, the price gradually goes up; because the product is better and the risk that the product will never reach 1.0 has declined. At 1.0(obviously, numbering conventions vary, some products aren't "1.0" until about "3.5 SP4"; but "1.0" as in "finished") charge full price.
Especially in recreational markets there is nothing wrong with selling inferior or unfinished goods; provided that you are honest about what you are selling...
I'd assume that(barring the existence of some sort of unlock-for-registered-owner mechanism, which wouldn't be impossible) the point isn't to help you, the one specific person whose laptop just got stolen; but to gradually phase "stealing laptops" out of the list of things that are economically viable by upping the odds that the thief will get nothing but a brick for their time...
They may well have added some 3G-related silicon; but the CPU is very much inside the "shielded to keep the FCC off our backs" compartment of basically all systems. I assume that they simply baked the necessary hooks into their CPU/chipset for the system to interact with the cell modem, even if turned "off" and brick itself if so ordered.
Architecturally, I'm assuming that this builds on Intel's "Active Management" integrated service processor, which has been featured in mostly corporate models, with gradually increasing capabilities, for some years now.
Well, it finally gives us the technological basis for the "Fritz chip" that the geriatric pawn of the media cartels of the same name wanted back in the day. Progress!
Don't worry, just as the TPM ultimately trusts the user, rather than hiding its secrets even from its owner, I'm sure this system is 100% aligned with the owner's interests and has no other uses...
While I ordinarily find the "zOMG correlation != causation" brigade to be a trifle tiresome, there is a good bit of evidence from other studies that people find ideologically conformant information comfortable and ideologically nonconformant information uncomfortable(albeit to varying degrees: your fundamentalist of any stripe can barely restrain himself frothing at the mouth over the fact that nonconformant information even exists. Joe user just tends to change the channel).
Now that there is a media outlet for almost any political persuasion, it is quite reasonable to suspect that people are congregating around channels reporting from their preferred reality. Trouble is, of course, that there is only one reality actually out there, and it has numerous pitfalls and teeth. We ignore it at our peril.
Under cover of darkness, employees of the Museum of Natural history broke in and appropriated the exhibit to add to their world-renowned dinosaur collection...
It is true that DRM is pretty much hopeless(though some DRM is less hopeless than other DRM) and, more importantly, Netflix streaming is about the lousiest possible source for piracy, even if it was entirely open: streamed at real time only, from a catalog of stuff that studios deem low-value enough to licence for peanuts(if Netflix can afford to let you stream an unlimited amount for $7 a month, the licensing can't be costing them much, on top of bandwidth and storage). Never mind the fact that quality can drift unpredictably, depending on the bitrate that the streaming client thinks you are currently capable of.
As an attack source, even if totally unsecured, netflix streaming is about as attractive as analog video tapes. Somehow, the studios still insist. Even with DVDs, which are known to be broken to hell and back, they still keep slapping CSS on them, despite the obvious futility.
I'm not saying that DRM actually works; but just that studio DRM requirements will prevent an OSS netflix streamer more or less forever.
The summary makes the incredibly naive and misleading mistake of conflating online trial-and-error attacks with offline hash attacks.
Against a system you do not control, the system has total power over how frequently you may try a username/password combination, how informative it is about your success/failure(ie. does it just say "no" does it say "wrong password" does it say "username not recognized"?), as well as being able to, if it wishes, just start ignoring all attempts from your IP/terminal or all attempts against a specific account(subject to the risk of denial of service techniques exploiting this). In this scenario, the difference between a terrible password and an OK password is enormous. The 12345 or 'password' are quite likely to be simple enough to crack by trial and error, even against a remote system. Modestly more complex ones will either be impossible or require days/weeks of low-speed guessing, or careful guessing from multiple hosts.
With an offline hash attack, you have total control over the hashes, and the only limiting factor in how fast you can attack them is your computer(and hash attacks generally parallelize really well). Here, the difference between a terrible password and a merely mediocre one will likely be less than the refresh rate of the attacker's monitor, and the difference between an OK password and a superb one will still be fairly small. Only a password so good that it is basically a nonstandardized type of private key will be of any use. However, offline hash attacks only happen against compromized systems, you can't get the hash table otherwise. They are an excellent argument for not re-using passwords, since systems get cracked all the time; but they are of only limited relevance in discussing the importance of password complexity, or lack thereof, for online attack scenarios...
That ChromeOS is not necessarily going on to the brightest of futures; but that it serves a number of valuable purposes to Google:
1. Serious 'dogfooding': Google's business is pushing 'web' and 'webapps' and whatnot, both to sell adsense impressions and to steal MS's lunch money to keep them from subsidizing their search arm until it becomes a real threat. Building an OS around this exclusively allows them to bundle in a few neat features(widespread single sign on without a corporate IT team, some interesting security/sandboxing stuff, easy restoration/backup) and also forces them to think carefully about how all common user use cases can be addressed in a 'web' way. Does HTML5 need something else? Do we have to get serious about NaCl? Is Flash still necessary, etc. Assuming the program doesn't rack up serious losses, it makes sense as an R&D project.
2. Possible basis for moving Android applications/features into larger form factors: I can imagine two possibilities: 1. ChromeOS, as noted above, is an R&D project about what a web browser needs to be able to do to fulfill the desired use cases. Android has a web browser. Therefore, roll what you've learned into Android's web browser and call it a day. 2. Android, in effect, consists of a java-esque(but don't call it Java(tm)) bunch of applications running in a VM on top of a relatively spare linux base. ChromeOS consists of a browser running on top of a fairly spare linux base. It would not exactly be rocket surgery to use the browser/HTML as a "windowing environment" in which dalvik VM applications from Android can be embedded, just like the Java applets of old. Throw in a way for the user to full-screen an embed, if it is designed for a larger screen, integrate Android's notifications into the system(given the R&D about sandboxing and security in the browser, in point #1, you could conceivably allow the Dalvik embeds to interact with the DOM of the page, present Android system notifications/address book, etc. as JS accessible elements, etc.)
3. The "big business IT for small business" pitch: With a competent IT team, and some investments in servers and AD and stuff, an enterprise IT department can already to centralized data storage, remote application access, single sign on, etc. If you have enough users, the cost/user isn't bad; but it isn't trivial, and there some costs that are fixed enough that things get more expensive in $/user, as you get smaller. So, a lot of small outfits basically make do either with painfully expensive consultant setups-and-pray-it-doesn't-break-so-we-don't-have-to-call-him-back or seriously ghastly "just a bunch of computers and some good luck, plus sneakernet". So, Google says: "Hey, subscribe to Google Apps for business for $/person/year and get all Google apps, a Gmail storage and interface for mail from your own domain, and seamless single sign on and backup on any "ChromeOS" device on the market! Since the hardware requirements are low, our numerous hardware partners have netbooks, laptops, desktops, even virtualized option cards for full laptops(analogous to Dell's "Latitude ON" card). If one breaks, just toss it and get another one, you'll be back up and running in 10 minutes just by opening the box and typing in your username and password. No IT guy!(except to keep your network up...)"
The DoD has actually been somewhat more active than the government generally in alt-energy research.
Partially, I'd assume that this stems from the simple fact that, when your oil products have to be shipped to you through hostile territory, you are already experiencing the sorts of prices that peak oilers have in mind(never mind something really dramatic, like enemy infiltrators blowing a few gulf coast refineries just before starting a hot war...)
Partially, I'd assume that it stems from the fact that the military has years of experience with blowing off popular opinion. Politically, admitting anything more than "Maybe we'll have to switch from oil to Clean Coal: America's Power(tm) to sustain our God-given lifestyle" will get you lynched and not reelected. Within military R&D circles, you have a better chance of hiding behind the flag and getting your work done.
That, in addition to OSS's usual superiority on the server side vs. the desktop side, there is the ugly-but-not-at-all-little-for-Netflix issue of DRM.
You cannot build a DRM system that is both "OSS" in any useful sense and effective(you can certainly use OSS parts; but ultimately there will have to be a proprietary obfuscated portion or hardware tivoization and/or secrets if the DRM is to be more than a toy, disabled by using the --obey_DRM=no build option). There is simply no compromise to be had here. DRM attacks user freedom, OSS promotes it. Regardless of your stance on the validity of one or the other, they are not compatible.
Somebody with server operations on the scale of Netflix would be insane to not be using OSS, and it certainly never hurts to cultivate a good relationship with your suppliers; but we can expect an OSS client at approximately the point the sun expands and engulfs the inner planets(or when chinese holocube knockoffs with a bit-for-bit blu-ray rip of every movie ever made are selling for $10 on every street corner, at which point the studios might finally realize that stopping people from ripping streams is hardly worth the trouble). A tivoized linux client device has already been available for some time, and a proprietary client for linux might even appear, should linux get the market share needed; but OSS, not so much.
While I don't like Google any more than you do, I'm less worried about Android. Only a subset of Android devices are tied to Google in any useful way. Since Android is available as a largely apache licenced middleware stack for the GPLed kernel(plus whatever proprietary apps and drivers the vendor feels like shipping), assorted "Android" devices have sprung up like mushrooms that are about as connected to Google as a Gentoo box is to Linus Torvalds. By contrast, every box of Windows sold is money right into Redomond's coffers and, as of now, isn't shy about phoning home.
The real problem will be expectations RE: 3rd party applications. "Android" succeeds, in part, on very non-PC-like hardware because it promises nothing about support for historical linux applications(plus, the only historical applications tend to either be server stuff, that you wouldn't run on a tablet except as a stunt, or geek stuff that geeks are welcome to try to get working if they want to).
Windows, on the other hand, has a huge amount of well known legacy applications, and when a product is sold as "Windows" people expect that it, and the disk they just got at best buy, will work on it. Trouble is, the vast majority of those 3rd party applications will suck without a proper mouse and keyboard. Not much MS can do about that.
There isn't anything much wrong with the NT kernel(I'm sure hardcore geeks and purists could pick some nits; but the same could be said of linux.), nor does MS have no ability to design a new touchable shell; but making 3rd party stuff not just tear you out of that shell and poke you in the eye with how much they suck would be somewhere between heroic and impossible.
This, I suspect, is why Apple, with their iPhone, Google(de facto, they don't actually stop you) with Android, and MS with Windows Phone 7, enacted a "no legacy" policy.
Even better than a secret algorithm, which are generally bad juju, you might as well just use well-known and well tested cryptographic techniques: Each unit's service backdoor would be its MAC address, signed with an HP private key(stored with the same care reserved for SSL root certs and the like). The unit would just have to know its own MAC address and HP's public key to be able to verify the validity of the signature...
While there is a logical place for support accounts, particularly with fancy enterprise junk where phoning home to the mothership when things go sour is considered a feature; but hardcoded passwords are an amazingly stupid way of setting them up.
Even a superb hardcoded password is going to sneak out eventually, even if only after the units start to be scrapped(but before all of them leave production). At a bare minimum, the hardcoded password would have to be unique per unit. Even better, use something like a cryptographic challenge/response system, so even an attacker with silicon level access can only learn HP's public key, which is useless, and HP can still do their thing.
Because of the needs of humans, passwords have their place; but for anything automated/serious, cryptographic techniques are the only way to go. Anything else is pitifully amateurish.
Or, in what can only have been a black joke on Redmond's part, Microsoft's "Rights Management Services"... Somebody was stroking a white cat and laughing insanely when they hit upon that one...