The Knights Hospitalers (I think, could have been Templars) had a fortress that was never conquered. Attackers would be bottlenecked, relative to defenders, were forever being harassed on the flanks and faced numerous blind corners.
Simply build a reproduction of this fortress around the White House. They can build a moat around it, if they like. Ringed by an electric fence. Oh, the moat needs sharks with lasers. Any suggestion for shark species?
The great thing about this is that the White House can remain a tourist attraction. Everyone loves castles, and taking blindfolded and handcuffed tourists through the maze of twisty little passages (all alike) would surely be a massive draw. BDSM is big business these days.
The polygraph is just a modern version of Trial by Ordeal. Where about the only thing modernized is the type of witchcraft it detects.
It has the reliability and reputation of tealeaf-reading. Actually, more people probably believe in mysticism than lie detectors.
Under these circumstances, any organization relying on polygraph testing deserves everything it suffers. Believe Mystic Meg's advice on lottery numbers? You aren't entitled to a refund on either. Same applies here. Such devices should have been consigned to the scrap yard (and/or the museum of failed criminology) decades ago.
It's no more easy to be sympathetic to the ex-cop. The fact that he's basically correct is irrelevant. First, he's milking the market. Ten greenbacks for a digital book that's likely to be yanked by officialdom. Even Dangermouse was content with one. Besides, most of the tricks are well-known and meditation can take care of the rest.
From the looks of it, the guy also harasses negative reviewers. That's definitely strike two.
And I'm willing to bet that he has abused authority a few times himself. That's becoming par for the course.
Nonetheless, despite despising the lot, police harassment and the de-facto classification of failings within authority are absolute no-go areas and that supersedes my dislike of Doug Williams and his profiteering.
Option #1: Include all organisms that are "alive" by some definition at two points in time (A and B) are alive at any point in time between A and B.
This eliminates all definitions that exclude known states for organisms. Which is most of them. All five "life processes" can be suspended in most/all organisms for indefinite periods of time. Since they are indefinite, you cannot assume any finite span of time being involved and therefore it is not the possession of properties that matters, only the potential for possession.
In fact, everything has to be written as potentials, in this model. There is nothing in this model which states that any feature has to exist simultaneously with any other feature.
Option #2: Abandon all notions of "life" entirely and go from the ground up.
There is fundamentally no distinction between living and non-living. All matter is "non-living", any concept of "life" has to be an abstract, non-physical concept that isn't binary but a gradation. In other words, it's not a property something has, it is a magnitude of a property of a collection of properties that something has. This model is necessary if you adhere to the deep oceanic origin of life theory. In this model, life formed in the deep oceanic trenches from an iron/sulphur matrix around which organic molecules (some sinking from the surface, some formed at the trench level) were bound. Since there is no binary living/non-living state in this model, this proto-proto-life must have a non-zero magnitude. (It is clearly more than the non-living structures around it, since it is a gateway to life, but it is clearly less than anything we'd classically consider "living".)
I would argue that in this model, anything that meets the classic five life processes meets or exceeds some threshold boundary, which you are entirely at liberty to call 1.0. Quasi-living things cannot equal or exceed this threshold value, definitely living things cannot fall below it. Furthermore, since all known living organisms contain processes that are critical to the function of the organism and which must have evolved at some point (something only living systems are capable of), all sub-processes of any living organism must have non-zero life, no matter how simple. (In computing terms, if you only have a notion of programs, then threads, procedures, functions, etc, are program-lites but still programmatic in nature.)
You will notice that in neither of these have I actually specified what a living organism must possess. In the first case, there must only be potentials for processes that are counter-entropic, but there is no formal description of what those processes would be. I don't need them to define life, I only need to know that counter-entropic behaviour of some sort is a non-zero possibility. In the second case, I don't even bother considering entropy. It is sufficient that there be a process which, by stepwise refinement, can be shown to be a valid sub-process at some depth of analysis of life. It simply doesn't matter if it organizes into something that is living in some sense we don't know about, just as in programmatic terms you don't care what links to a library file. If it contains some identifiable sub-process that has the potential to be a key part of a living thing, then it has non-zero life and whether that life meets some criteria or other can be left to biologists and philosophers.
These are, in my arrogant opinion, superior to classical definitions because I'm not looking at a specific something and calling it a benchmark. Which, from the perspective of early science, meant humans. If you like, I'm looking only at the fundamental specifications involved and saying that if there is non-zero overlap and that overlap is necessary (but not necessarily sufficient) for life, then whatever possesses that overlap possesses enough to be considered on the spectrum.
I accept, completely, that this still doesn't guarantee covering everything. It does cover ALife and AI (provided that
I would agree, except that most users live in outright denial, rarely (if ever) learn correctly from mistakes and frequently prefer to ignore their suffering until the harm is truly excessive.
Better critical thinking techniques need to be taught in school, along with practices that impede cognitive dissonance.
Further, there need to be recognized groups that have the authority to mentor those who aren't clued up.
If someone decided to stand on the curb for a long time, they'd probably be reported for suspicious activity. Casing a place is a very common precursor to a break-in. I see no reason for the monitoring of a private webcam to be treated any differently in that regard.
A more likely scenario would be for a criminal to drive past at night, see the car gone, and then check the internal cameras of the house for any activity to determine if it's easy to rob. If there's no baby, there's likely no babysitter either. It's just wardriving with intent.
A third scenario is that the criminals have got something equivalent to packet sniffing for speech. Back in the old pre-common-SSL days, it was common enough for a hostile packet sniffer to log packets that contained a field that was in credit card number format. You didn't have to break in to get all the personal data, you just grabbed it as it went by. You wouldn't then sit there waiting for interesting tidbits of information, you'd simply have your zombie botnet collect interesting-looking sound snippets. It doesn't have to recognize the words, just the patterns. We know for certain the security services had that in 2003 as part of Echelon and Moonpenny, and probably had that as far back as the late 1990s. It would be gross incompetence on the part of anyone dealing with IT security to blithely assume it's not reached the cybercriminal domain.
Hell, just the fact that the intelligence services can sniff for interesting data is a serious risk these days. Both British and American authorities have done some ethically questionable undercover work that (at best) bordered the criminal. And they're some of the better ones. Blatantly criminal endangerment, blackmail and other corrupt practices are widespread.
I could build a device that is, by default, secure against remote intrusion. That's easy. I haven't, because the NSA wants to ban public encryption and GCHQ wants to declare all secure devices terrorist command-and-control centres. I'd rather not be a target for a hellfire missile, thank you very much.
But if I can do it, anyone with half a wit and a credit card can. It's not hard. It's not cheap, but it's not hard.
Such a device aught to be mandatory on eCommerce systems and a minimal version aught to be mandatory on all networked appliances (fridges, toasters, cameras, air conditioning, nuclear reactors....) - that it isn't IS gross incompetence. That the security agencies want to prohibit such technology is gross negligence.
IPSec and SK/IP are usable by ordinary people, and since all applications can work over those, all applications can have secure and usable cryptography.
That's not the problem. The problem is that if it's not used by a critical mass of people, it doesn't do any good. Until people are forced, kicking and screaming, to not broadcast every private thought with the entire world, nothing will happen. I'll see you on the 6Bone before I'll see the average Joe so much as clicking a button in their own interest.
Agreed. Better to fix IPSec and have every packet encrypted - with keys when possible, opportunistically as fall-back - when communicating with any other computer for anything.
One of the advantages of IPSec is that absolutely everything is encrypted. Thus, any packet sniffer out there (be it by a credit card thief, the NSA - who may also be credit card thieves, or anyone else) can't look for context to decide what packets to grab. There is no context. That means having to decrypt absolutely everything, including DNS lookups, spam emails, everything. Since keys expire frequently, the value of the data has to be extraordinary to be worth the cost of the effort.
The main disadvantage of IPSec is that it doesn't replace the unencrypted channel for the user, it's a distinct channel. That's bad. You don't want a trojan sneaking onto the computer and simply echoing all the juicy gossip over the plain wire.
The second disadvantage is that it's a very heavy protocol. Sun's SK/IP was lighter and it might be worth investigating why it was dropped and whether it might be a better choice.
The final disadvantage is that most implementations use crypto functions that are no longer regarded as secure or are horribly slow. Not that that matters anyway, as to get it to override the user-visible open channels, you'll have to rewrite it anyway.
The first requirement is that auditing must involve (0.5 x participants) + 1 who are not compromised, the minimum number guaranteed under The Byzantine General's Problem to result in provably correct information being transmitted to/from the head of the development team (who must also not be compromised).
The second requirement is that the audit not be done directly. In the case of seL4, the proof was done mathematically. In the case of extreme programming, development is done by producing test harnesses (essentially the same thing as the mathematical proof) which the code must comply with in order to pass inspection. Code itself is often very difficult to validate by inspection, inspecting the reasoning/logic is much cleaner and it's easier to prove that the inspection is itself correct.
The third requirement is that you must be able to establish that "traitor code" within the system, provided it is sufficiently small, cannot compromise security. In other words, there should be no single point of security failure, where a traitor module could transmit sufficient data to compromise the entire system. Obviously, there can always be sufficient traitor modules to betray the secrets between Alice and Bob. Nor is there any way to prove you have eliminated all of them. What you have to prove, however, is only that your detection threshold for such code is below the minimum number of such modules needed for a third-party to intercept Alice's lunch plans with Bob. Anything below threshold is unimportant.
This doesn't require you to use lots of duplicate code. It requires only that no block of code guaranteed to run gets to access clear-text and any form of network or storage device. Ever. Clear-text handling code should be able to read data, process it and hand it directly over to the next module. Nothing more. Then it doesn't matter what else it tries to do, it can't do anything toxic. Ideally, you'd write such code in its own totally isolated process that is loaded and run by the main program. If it's a distinct process, ideally under a non-privileged user, you can lock it down. Give it absolutely minimum rights to do what you specify and nothing more. It shouldn't have network access of any kind, for example, since it isn't to access any network.
Because nothing clear-text escapes that container, even via leakage over the heap or stack, it doesn't matter what has been added to the network code. There's nothing sensitive that can be leaked to third-parties at that point, if the cryptography is good.
Now, as previously noted, all this code is being audited by formal or semi-formal methods that have, themselves, been audited. This is still necessary, because the firewall isn't perfect. It's good, but a rootkit or hypervisor can see into the memory of multiple processes and can thus cross-contaminate without ever altering the code itself. The audit won't stop that, but it'll stop any code being added that assists in such a process.
Now, can you stop a third-party hypervisor at all? No. You cannot. That's what makes the NSA and GCHQ bleats so infuriating. If they were actually competent, they wouldn't care about what software you used, they could obtain anything they wanted in the clear anyway. It betrays severe incompetency and if there's anything more annoying than a spy agency conducting industrial espionage and moral supervision of the citizens of a country, it's a hopelessly incompetent spy agency conducting (largely successful) industrial espionage and moral supervision of the citizens of a country... whilst asking for assistance in doing so.
To get much more secure, to actually block software running outside the OS itself, you need far better security than you can achieve in software. With software, there is always something that can look in from outside. And if it can look in, it can both intercept and inject at every point in the code. Nothing, not even the data stream, can be assured. To go further, you must abandon plug-and-pray commodity hardware. If you want guaranteed inte
A dark satellite made from an ultrablack material or using a stealthy topology simply isn't going to be seen. By anyone.
Ion engines are slow, but they don't give off any tell-tale glare.
The southern hemisphere has very little in the way of monitoring - a satellite traversing any great circle other than equatorial will be difficult-to-impossible to track.
This is not a likely threat, on a scale from one to ten, the seriousness is sqrt(-1). Nonetheless, it's not zero.
That may be true in theory, but Iran succeeded in hijacking a US drone via a GPS attack. Thus, whatever authentication exists is not actually in use. The US, for reasons known only to them, hate encryption. Any encryption. By anyone. Including themselves. For much of the war in Afghanistan, drone camera signals were unencrypted and omnidirectional, leading to video footage being circulated. Slashdot covered the issue in the early days of the war.
If the US military are too stupid to encrypt drone GPS systems and drone video feeds in an open war, they can't be trusted to do anything right.
The FBI wants to ban private encryption, essentially banning eCommerce, eBanking, UNIX, foreign languages, medical implants, boolean operators...
The mere fact that the director could state this in public and not be fired by the time he'd finished speaking is all the proof you need that Americans - and indeed any post-Babbage civilizations - are expendable in the eyes of the civil (uncouth?) service.
Which should be no surprise. The difference in social influences, culture and thus attitude between the paranoid schizophrenic survivalists and the paranoid schizophrenic security agency staff is pretty much nil.
And the government always obeys the law? Further, if the facility exists, anyone can turn the jitter back on. It's no different from what we've been saying about backdoors - once they exist, anyone can use them. There's also risks of social engineering attacks against those running satellites. And, since no software is perfect (and no radiation proofing is perfect), the satellites may spontaneously add jitter, enable encryption (with a gibberish key), or simply activate their steering jets, putting them on an incorrect and/or elliptical orbit, screwing up calculations. (ie: physical jitter)
This is ignoring the solar storm/jamming/gamma ray burst/collision with space junk range of issues, as they're discussed elsewhere and aren't really pertinent to the jitter issue.
One of the common problems with any aircraft design is that you can't have backups for everything. There simply isn't the capacity, unless you double the size of the aircraft and thus eliminate all of the benefits of having a backup engine (perhaps the most critical system to have a backup of). Thus, some level of failure is inevitable.
(Even if you have backups, that won't necessarily save your skin. The DH98 Mosquito could fly perfectly fine on one engine, but crashes from engine failure still happened. The Space Shuttle, on at least one occasion, lost two or more of the five onboard computers. There's a limit to what you can do in these sorts of cases.)
All flight is, inherently, dangerous. That's the nature of the beast. You can improve safety, which is always a good thing to do, but improvements will be asymptotic to a value below perfectly safe. How much below is unclear, I don't think anyone has really done that calculation. Nonetheless, whatever it is, there's declining returns after a given point. Commercial manufacturers tend to put a ballpark figure on what's an acceptable number of deaths per thousand (miles|hours) of flight and will invest to around that level of safety. Understandable - more than that gets very expensive very quickly but won't affect sales, aircraft usage or aircraft reputation.
Now, high atmospheric/suborbital/orbital/space travel is a great deal worse. Engines have to cope with vastly higher pressures, which means that much smaller defects can be disastrous. You've far worse radiation to contend with, so control circuits have to be better screened and radiation-hardened. They also have to cope with far greater G forces, vibrations from hell, variations in temperature that they're not going to like, and (since atmospherics can be nasty) survive (without producing erroneous signals) plasmas and electrical discharges that aren't always predictable and not always that well understood.
In this particular case, it looks from the amateur footage that claims to be of the accident (you can never be sure) that the engine ruptured. The engine, as I understand it, was a new type. Probably smarter to do the first flight unmanned for that, but that's easy to say now. My guess would be that the engine casing had not been properly made and failed. Not enough to total the aircraft at high altitude, but enough to make a complete mess of things. Again, it's only a guess, but that sounds like the engine wasn't yet full power. If it had been, I doubt there'd have been anything large enough for the video cameras to film.
Engine casings are tough to make flawlessly. You can do limited testing with ultrasonics and assorted remote sensors, and those'll find a lot of flaws, but the only known way to test if an engine is working perfectly is to fire it up to maximum power and hold it there until the fuel runs out or it explodes. If it's still intact, it was fine. It probably isn't now, though.
The solution necessarily involves three mechanisms:
* Determining what is present * Fetching what is absent * Isolating everything that is build-specific
The "tradition" established by CPAN, CPyAN and CTAN is that source packages should specify dependencies - not only the software name, but the range of versions permitted. Archives should then permit requests for specific versions.
Isolation (such as by root jailing) deals with file path issues, software interactions, etc. All the build system should be able to see is the software the build system needs. Nothing more.
Determining what is present is more complex. The software must see what options exist that are compatible and then, through build flags, defaults and user queries, determine which of those options to actually use. If you're using Windows and have GnuWin32, Cygwin and MinGW installed, it's no good just asking if Gnu build tools are to be used.
Installs and deinstalls are platform-specific, it's best if generic package installers for each platform took care of the databases and links. If you can find any. Seems to be a shortage in useful tools.
There's software for auto-detection of necessary libraries (cmake is probably the best, since it's more portable than autoconf).
If you've the source tree, then you should require one single platform-dependent package containing cmake, gnu make, curl or wget, grep, cut and associated libraries, along with a text file containing a list of dependencies, where to get them and where to put them.
Your build system then scans for everything needed. If you've got it, it uses it. If you don't, it fetches the source, builds it and installs it.
This is not rocket science. Gentoo has been doing something similar for a very long time, so has Perl, so has Cygwin and Cygwin-based packages like OSGEO4W.
Yes, it's slow. Yes, it means the browser maintainer has to have a text editor. Yes, it's going to be as painful and agonizing as installing X11R4 or GateD. I did both. On a 386SX-16. Uphill. Both ways. In the snow. If you can't write your code properly to begin with, get off my lawn!
No problem. Since they require that, you get contractor rates. Plus per diem for the travel. The petrol and wear-and-tear on your car to Germany will be tax-deductable. The remainder of expenses can be billed to the vendor. You send them the estimate in advance, then when they refuse (which they will, because it'll be a hell of a lot more than the cost of a Windows license and probably not too far from the cost of the computer in its entirety if you choose the right places to stay), sue the bastards for breech of contract.
Would you win? Probably not, but the cost of the lawsuit would be a hell of a lot more than the cost of your expenses sheet. That would put them in an interesting position. If they win, they lose. Hey, corporations have been doing this for centuries, it's about time geeks had a go. It seems to be a very profitable racket.
Slashdot Mirror
The Knights Hospitalers (I think, could have been Templars) had a fortress that was never conquered. Attackers would be bottlenecked, relative to defenders, were forever being harassed on the flanks and faced numerous blind corners.
Simply build a reproduction of this fortress around the White House. They can build a moat around it, if they like. Ringed by an electric fence. Oh, the moat needs sharks with lasers. Any suggestion for shark species?
The great thing about this is that the White House can remain a tourist attraction. Everyone loves castles, and taking blindfolded and handcuffed tourists through the maze of twisty little passages (all alike) would surely be a massive draw. BDSM is big business these days.
You mean, you've discovered politicians do one intelligent thing? Albeit for stupid reasons.
The polygraph is just a modern version of Trial by Ordeal. Where about the only thing modernized is the type of witchcraft it detects.
It has the reliability and reputation of tealeaf-reading. Actually, more people probably believe in mysticism than lie detectors.
Under these circumstances, any organization relying on polygraph testing deserves everything it suffers. Believe Mystic Meg's advice on lottery numbers? You aren't entitled to a refund on either. Same applies here. Such devices should have been consigned to the scrap yard (and/or the museum of failed criminology) decades ago.
It's no more easy to be sympathetic to the ex-cop. The fact that he's basically correct is irrelevant. First, he's milking the market. Ten greenbacks for a digital book that's likely to be yanked by officialdom. Even Dangermouse was content with one. Besides, most of the tricks are well-known and meditation can take care of the rest.
From the looks of it, the guy also harasses negative reviewers. That's definitely strike two.
And I'm willing to bet that he has abused authority a few times himself. That's becoming par for the course.
Nonetheless, despite despising the lot, police harassment and the de-facto classification of failings within authority are absolute no-go areas and that supersedes my dislike of Doug Williams and his profiteering.
We have two options here.
Option #1: Include all organisms that are "alive" by some definition at two points in time (A and B) are alive at any point in time between A and B.
This eliminates all definitions that exclude known states for organisms. Which is most of them. All five "life processes" can be suspended in most/all organisms for indefinite periods of time. Since they are indefinite, you cannot assume any finite span of time being involved and therefore it is not the possession of properties that matters, only the potential for possession.
In fact, everything has to be written as potentials, in this model. There is nothing in this model which states that any feature has to exist simultaneously with any other feature.
Option #2: Abandon all notions of "life" entirely and go from the ground up.
There is fundamentally no distinction between living and non-living. All matter is "non-living", any concept of "life" has to be an abstract, non-physical concept that isn't binary but a gradation. In other words, it's not a property something has, it is a magnitude of a property of a collection of properties that something has. This model is necessary if you adhere to the deep oceanic origin of life theory. In this model, life formed in the deep oceanic trenches from an iron/sulphur matrix around which organic molecules (some sinking from the surface, some formed at the trench level) were bound. Since there is no binary living/non-living state in this model, this proto-proto-life must have a non-zero magnitude. (It is clearly more than the non-living structures around it, since it is a gateway to life, but it is clearly less than anything we'd classically consider "living".)
I would argue that in this model, anything that meets the classic five life processes meets or exceeds some threshold boundary, which you are entirely at liberty to call 1.0. Quasi-living things cannot equal or exceed this threshold value, definitely living things cannot fall below it. Furthermore, since all known living organisms contain processes that are critical to the function of the organism and which must have evolved at some point (something only living systems are capable of), all sub-processes of any living organism must have non-zero life, no matter how simple. (In computing terms, if you only have a notion of programs, then threads, procedures, functions, etc, are program-lites but still programmatic in nature.)
You will notice that in neither of these have I actually specified what a living organism must possess. In the first case, there must only be potentials for processes that are counter-entropic, but there is no formal description of what those processes would be. I don't need them to define life, I only need to know that counter-entropic behaviour of some sort is a non-zero possibility. In the second case, I don't even bother considering entropy. It is sufficient that there be a process which, by stepwise refinement, can be shown to be a valid sub-process at some depth of analysis of life. It simply doesn't matter if it organizes into something that is living in some sense we don't know about, just as in programmatic terms you don't care what links to a library file. If it contains some identifiable sub-process that has the potential to be a key part of a living thing, then it has non-zero life and whether that life meets some criteria or other can be left to biologists and philosophers.
These are, in my arrogant opinion, superior to classical definitions because I'm not looking at a specific something and calling it a benchmark. Which, from the perspective of early science, meant humans. If you like, I'm looking only at the fundamental specifications involved and saying that if there is non-zero overlap and that overlap is necessary (but not necessarily sufficient) for life, then whatever possesses that overlap possesses enough to be considered on the spectrum.
I accept, completely, that this still doesn't guarantee covering everything. It does cover ALife and AI (provided that
If they're wardriving, very easily. It's called nmap.
I would agree, except that most users live in outright denial, rarely (if ever) learn correctly from mistakes and frequently prefer to ignore their suffering until the harm is truly excessive.
Better critical thinking techniques need to be taught in school, along with practices that impede cognitive dissonance.
Further, there need to be recognized groups that have the authority to mentor those who aren't clued up.
If someone decided to stand on the curb for a long time, they'd probably be reported for suspicious activity. Casing a place is a very common precursor to a break-in. I see no reason for the monitoring of a private webcam to be treated any differently in that regard.
A more likely scenario would be for a criminal to drive past at night, see the car gone, and then check the internal cameras of the house for any activity to determine if it's easy to rob. If there's no baby, there's likely no babysitter either. It's just wardriving with intent.
A third scenario is that the criminals have got something equivalent to packet sniffing for speech. Back in the old pre-common-SSL days, it was common enough for a hostile packet sniffer to log packets that contained a field that was in credit card number format. You didn't have to break in to get all the personal data, you just grabbed it as it went by. You wouldn't then sit there waiting for interesting tidbits of information, you'd simply have your zombie botnet collect interesting-looking sound snippets. It doesn't have to recognize the words, just the patterns. We know for certain the security services had that in 2003 as part of Echelon and Moonpenny, and probably had that as far back as the late 1990s. It would be gross incompetence on the part of anyone dealing with IT security to blithely assume it's not reached the cybercriminal domain.
Hell, just the fact that the intelligence services can sniff for interesting data is a serious risk these days. Both British and American authorities have done some ethically questionable undercover work that (at best) bordered the criminal. And they're some of the better ones. Blatantly criminal endangerment, blackmail and other corrupt practices are widespread.
I could build a device that is, by default, secure against remote intrusion. That's easy. I haven't, because the NSA wants to ban public encryption and GCHQ wants to declare all secure devices terrorist command-and-control centres. I'd rather not be a target for a hellfire missile, thank you very much.
But if I can do it, anyone with half a wit and a credit card can. It's not hard. It's not cheap, but it's not hard.
Such a device aught to be mandatory on eCommerce systems and a minimal version aught to be mandatory on all networked appliances (fridges, toasters, cameras, air conditioning, nuclear reactors....) - that it isn't IS gross incompetence. That the security agencies want to prohibit such technology is gross negligence.
Users aren't allowed to secure their own devices. Didn't you get the memo from GCHQ?
http://www.ft.com/cms/s/2/c89b...
Encryption and security of any kind are ipso facto creating a terrorist command-and-control centre, apparently.
Yes. Not that I know of.
IPSec and SK/IP are usable by ordinary people, and since all applications can work over those, all applications can have secure and usable cryptography.
That's not the problem. The problem is that if it's not used by a critical mass of people, it doesn't do any good. Until people are forced, kicking and screaming, to not broadcast every private thought with the entire world, nothing will happen. I'll see you on the 6Bone before I'll see the average Joe so much as clicking a button in their own interest.
Agreed. Better to fix IPSec and have every packet encrypted - with keys when possible, opportunistically as fall-back - when communicating with any other computer for anything.
One of the advantages of IPSec is that absolutely everything is encrypted. Thus, any packet sniffer out there (be it by a credit card thief, the NSA - who may also be credit card thieves, or anyone else) can't look for context to decide what packets to grab. There is no context. That means having to decrypt absolutely everything, including DNS lookups, spam emails, everything. Since keys expire frequently, the value of the data has to be extraordinary to be worth the cost of the effort.
The main disadvantage of IPSec is that it doesn't replace the unencrypted channel for the user, it's a distinct channel. That's bad. You don't want a trojan sneaking onto the computer and simply echoing all the juicy gossip over the plain wire.
The second disadvantage is that it's a very heavy protocol. Sun's SK/IP was lighter and it might be worth investigating why it was dropped and whether it might be a better choice.
The final disadvantage is that most implementations use crypto functions that are no longer regarded as secure or are horribly slow. Not that that matters anyway, as to get it to override the user-visible open channels, you'll have to rewrite it anyway.
The first requirement is that auditing must involve (0.5 x participants) + 1 who are not compromised, the minimum number guaranteed under The Byzantine General's Problem to result in provably correct information being transmitted to/from the head of the development team (who must also not be compromised).
The second requirement is that the audit not be done directly. In the case of seL4, the proof was done mathematically. In the case of extreme programming, development is done by producing test harnesses (essentially the same thing as the mathematical proof) which the code must comply with in order to pass inspection. Code itself is often very difficult to validate by inspection, inspecting the reasoning/logic is much cleaner and it's easier to prove that the inspection is itself correct.
The third requirement is that you must be able to establish that "traitor code" within the system, provided it is sufficiently small, cannot compromise security. In other words, there should be no single point of security failure, where a traitor module could transmit sufficient data to compromise the entire system. Obviously, there can always be sufficient traitor modules to betray the secrets between Alice and Bob. Nor is there any way to prove you have eliminated all of them. What you have to prove, however, is only that your detection threshold for such code is below the minimum number of such modules needed for a third-party to intercept Alice's lunch plans with Bob. Anything below threshold is unimportant.
This doesn't require you to use lots of duplicate code. It requires only that no block of code guaranteed to run gets to access clear-text and any form of network or storage device. Ever. Clear-text handling code should be able to read data, process it and hand it directly over to the next module. Nothing more. Then it doesn't matter what else it tries to do, it can't do anything toxic. Ideally, you'd write such code in its own totally isolated process that is loaded and run by the main program. If it's a distinct process, ideally under a non-privileged user, you can lock it down. Give it absolutely minimum rights to do what you specify and nothing more. It shouldn't have network access of any kind, for example, since it isn't to access any network.
Because nothing clear-text escapes that container, even via leakage over the heap or stack, it doesn't matter what has been added to the network code. There's nothing sensitive that can be leaked to third-parties at that point, if the cryptography is good.
Now, as previously noted, all this code is being audited by formal or semi-formal methods that have, themselves, been audited. This is still necessary, because the firewall isn't perfect. It's good, but a rootkit or hypervisor can see into the memory of multiple processes and can thus cross-contaminate without ever altering the code itself. The audit won't stop that, but it'll stop any code being added that assists in such a process.
Now, can you stop a third-party hypervisor at all? No. You cannot. That's what makes the NSA and GCHQ bleats so infuriating. If they were actually competent, they wouldn't care about what software you used, they could obtain anything they wanted in the clear anyway. It betrays severe incompetency and if there's anything more annoying than a spy agency conducting industrial espionage and moral supervision of the citizens of a country, it's a hopelessly incompetent spy agency conducting (largely successful) industrial espionage and moral supervision of the citizens of a country... whilst asking for assistance in doing so.
To get much more secure, to actually block software running outside the OS itself, you need far better security than you can achieve in software. With software, there is always something that can look in from outside. And if it can look in, it can both intercept and inject at every point in the code. Nothing, not even the data stream, can be assured. To go further, you must abandon plug-and-pray commodity hardware. If you want guaranteed inte
The Viking version was the sunstone, which was not much bigger than an old-fashioned pocket watch.
A dark satellite made from an ultrablack material or using a stealthy topology simply isn't going to be seen. By anyone.
Ion engines are slow, but they don't give off any tell-tale glare.
The southern hemisphere has very little in the way of monitoring - a satellite traversing any great circle other than equatorial will be difficult-to-impossible to track.
This is not a likely threat, on a scale from one to ten, the seriousness is sqrt(-1). Nonetheless, it's not zero.
That may be true in theory, but Iran succeeded in hijacking a US drone via a GPS attack. Thus, whatever authentication exists is not actually in use. The US, for reasons known only to them, hate encryption. Any encryption. By anyone. Including themselves. For much of the war in Afghanistan, drone camera signals were unencrypted and omnidirectional, leading to video footage being circulated. Slashdot covered the issue in the early days of the war.
If the US military are too stupid to encrypt drone GPS systems and drone video feeds in an open war, they can't be trusted to do anything right.
The FBI wants to ban private encryption, essentially banning eCommerce, eBanking, UNIX, foreign languages, medical implants, boolean operators...
The mere fact that the director could state this in public and not be fired by the time he'd finished speaking is all the proof you need that Americans - and indeed any post-Babbage civilizations - are expendable in the eyes of the civil (uncouth?) service.
Which should be no surprise. The difference in social influences, culture and thus attitude between the paranoid schizophrenic survivalists and the paranoid schizophrenic security agency staff is pretty much nil.
And the government always obeys the law? Further, if the facility exists, anyone can turn the jitter back on. It's no different from what we've been saying about backdoors - once they exist, anyone can use them. There's also risks of social engineering attacks against those running satellites. And, since no software is perfect (and no radiation proofing is perfect), the satellites may spontaneously add jitter, enable encryption (with a gibberish key), or simply activate their steering jets, putting them on an incorrect and/or elliptical orbit, screwing up calculations. (ie: physical jitter)
This is ignoring the solar storm/jamming/gamma ray burst/collision with space junk range of issues, as they're discussed elsewhere and aren't really pertinent to the jitter issue.
Apparently, they're the good guys in the Book of the Three Letter Agencies.
One of the common problems with any aircraft design is that you can't have backups for everything. There simply isn't the capacity, unless you double the size of the aircraft and thus eliminate all of the benefits of having a backup engine (perhaps the most critical system to have a backup of). Thus, some level of failure is inevitable.
(Even if you have backups, that won't necessarily save your skin. The DH98 Mosquito could fly perfectly fine on one engine, but crashes from engine failure still happened. The Space Shuttle, on at least one occasion, lost two or more of the five onboard computers. There's a limit to what you can do in these sorts of cases.)
All flight is, inherently, dangerous. That's the nature of the beast. You can improve safety, which is always a good thing to do, but improvements will be asymptotic to a value below perfectly safe. How much below is unclear, I don't think anyone has really done that calculation. Nonetheless, whatever it is, there's declining returns after a given point. Commercial manufacturers tend to put a ballpark figure on what's an acceptable number of deaths per thousand (miles|hours) of flight and will invest to around that level of safety. Understandable - more than that gets very expensive very quickly but won't affect sales, aircraft usage or aircraft reputation.
Now, high atmospheric/suborbital/orbital/space travel is a great deal worse. Engines have to cope with vastly higher pressures, which means that much smaller defects can be disastrous. You've far worse radiation to contend with, so control circuits have to be better screened and radiation-hardened. They also have to cope with far greater G forces, vibrations from hell, variations in temperature that they're not going to like, and (since atmospherics can be nasty) survive (without producing erroneous signals) plasmas and electrical discharges that aren't always predictable and not always that well understood.
In this particular case, it looks from the amateur footage that claims to be of the accident (you can never be sure) that the engine ruptured. The engine, as I understand it, was a new type. Probably smarter to do the first flight unmanned for that, but that's easy to say now. My guess would be that the engine casing had not been properly made and failed. Not enough to total the aircraft at high altitude, but enough to make a complete mess of things. Again, it's only a guess, but that sounds like the engine wasn't yet full power. If it had been, I doubt there'd have been anything large enough for the video cameras to film.
Engine casings are tough to make flawlessly. You can do limited testing with ultrasonics and assorted remote sensors, and those'll find a lot of flaws, but the only known way to test if an engine is working perfectly is to fire it up to maximum power and hold it there until the fuel runs out or it explodes. If it's still intact, it was fine. It probably isn't now, though.
I absolutely agree.
The solution necessarily involves three mechanisms:
* Determining what is present
* Fetching what is absent
* Isolating everything that is build-specific
The "tradition" established by CPAN, CPyAN and CTAN is that source packages should specify dependencies - not only the software name, but the range of versions permitted. Archives should then permit requests for specific versions.
Isolation (such as by root jailing) deals with file path issues, software interactions, etc. All the build system should be able to see is the software the build system needs. Nothing more.
Determining what is present is more complex. The software must see what options exist that are compatible and then, through build flags, defaults and user queries, determine which of those options to actually use. If you're using Windows and have GnuWin32, Cygwin and MinGW installed, it's no good just asking if Gnu build tools are to be used.
Installs and deinstalls are platform-specific, it's best if generic package installers for each platform took care of the databases and links. If you can find any. Seems to be a shortage in useful tools.
There's software for auto-detection of necessary libraries (cmake is probably the best, since it's more portable than autoconf).
If you've the source tree, then you should require one single platform-dependent package containing cmake, gnu make, curl or wget, grep, cut and associated libraries, along with a text file containing a list of dependencies, where to get them and where to put them.
Your build system then scans for everything needed. If you've got it, it uses it. If you don't, it fetches the source, builds it and installs it.
This is not rocket science. Gentoo has been doing something similar for a very long time, so has Perl, so has Cygwin and Cygwin-based packages like OSGEO4W.
Yes, it's slow. Yes, it means the browser maintainer has to have a text editor. Yes, it's going to be as painful and agonizing as installing X11R4 or GateD. I did both. On a 386SX-16. Uphill. Both ways. In the snow. If you can't write your code properly to begin with, get off my lawn!
No problem. Since they require that, you get contractor rates. Plus per diem for the travel. The petrol and wear-and-tear on your car to Germany will be tax-deductable. The remainder of expenses can be billed to the vendor. You send them the estimate in advance, then when they refuse (which they will, because it'll be a hell of a lot more than the cost of a Windows license and probably not too far from the cost of the computer in its entirety if you choose the right places to stay), sue the bastards for breech of contract.
Would you win? Probably not, but the cost of the lawsuit would be a hell of a lot more than the cost of your expenses sheet. That would put them in an interesting position. If they win, they lose. Hey, corporations have been doing this for centuries, it's about time geeks had a go. It seems to be a very profitable racket.
Depends. If you can charge interest on the refund, this could be fun.
So the take-home message is that if you don't want Comcast to cut your head off, you don't send them any messages until they sign up to the agreement.