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.

Caused mainly by high quality tea. Coffee drinkers are thus entirely a figment of the imagination.

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 there exists a mapping that could, in principle, be used to convert physical life into ALife and vice versa), but it doesn't cover Isaac Asimov's speculation of silicon lifeforms unless there is a key component of the biology of such life that mirrors the biology of known carbon-based life. Just one component is enough, true, but a totally xenobiological system which has zero correspondence with known systems would not be recognizable by these approaches.

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 intercept-proof technology, you have to understand the Orange Book. Not just the software but the hardware as well MUST be verified to B2 standards or above. If you're paranoid, start at A1 and work your way up through the ceiling. If you're going to do that, seL4 is the obvious starting point, although you could probably debug BareMetal OS to the required security level.

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.