It's also a good example of why being a company "likely to be around for a while" isn't worth a damn. Mergers and buy-outs happen, to small companies and large, and it renders all those nice platitudes as to why commercial products are so much "safer" to go with into meaningless drivel.
I agree with the specification point, and agree that the lowest level API should be as basic (and standard) as possible. Then, once you have that, you can layer whatever higher-level architecture you like on top, as the low-level drivers are "just there" and will "just work".
However, this doesn't help applications, necessarily. I would argue to help apps writers, you need to standardize the glue between layers, such that sound and commands can be passed from one layer to another in a predictable manner. Innovators can always add new commands that are parsed by their own injectable layer.
I would also argue that it's impossible to chain userland software a-la JACK via the kernel efficiently, as you've a double context switch per element in the chain. Since transforms are CPU intensive, you want to do the fewest composite transforms possible, which means a software mixer should be something you can chain, which means that the heavy-lifting mixer needs to be in userspace.
(Either that, or you're going to need LADSPA and LV2 support in the kernel, plus some way of coaxing "smart" sound cards into supporting such effects. Since the kernel developers would force the first coder who tried to submit such a patch to walk the plank, I don't see it as likely.)
This would leave the low-level mixer for mixing between kernel threads (rather than between applications per-se) and normalizing the inputs. If we're not having to normalize values anywhere else in the process, we should end up with improved quality and less latency. (Anything that mucks with precision hurts quality, and any operation at all hurts latency.)
Given the reputation of the Chinese and Russian mafias, getting to the Supreme Court without heavy investment in the defense industry will be a challenge in itself.
The biggest problem is that any system involving target nodes sending ACKs or NAKs would allow traitor nodes to statistically determine where the ACKs or NAKs originate, no matter how carefully disguised the node. This means that some percentage of the nodes (especially a large percentage of edge nodes) would have to be proxy servers rather than just routing the packets. It's the only way to disguise the sources.
After that, it becomes easier. If all nodes do NOT have a unique address (but have a unique address within a given scope), and double NAT all connections (thus translating between one scope and the next), trojans and logic bombs that call home will identify N possible machines, where N is the number of non-overlapping scopes in the darknet. If N is large enough, it becomes impractical to investigate them all.
Another method is to remove the uniqueness requirement altogether. If there are M nodes that could be referred to, and each router just shotgun blasts the packet to all of them, there are NxM possible nodes that could be referred to. This relies on all nodes in the darknet using highly secure sequence numbers, such that there is a very low probability of the address fragment plus next expected sequence number being the same for two different nodes. To make sure this confuses watchers, simply have all nodes (including the intended recipient) that receive such a packet forward it until the TTL is reached OR the packet hits a router it has already passed through. (In either case, it would be dropped.)
The scattering approach means nobody can be sure of who the destination is. Each of the possible destinations will receive (eventually, by some path or other) either all the packets or most of them. Statistical analysis will tell you nothing about which one is the one that actually processed the data, since that merely becomes a process of sniffing the wire rather than being a terminal point.
(Essentially, it's a re-invention of old fat-wire ethernet, where your computer linked in with a T-piece and just sniffed for the packets intended for you.)
This would be costly on bandwidth, unless all connections were multicast (so there's only one packet per physical wire). You can't use IPSec with standard multicast (as it's a UDP-based protocol), but you CAN emulate multicast in software over TCP. You can ALSO emulate IPSec-style opportunistic encryption over UDP in software. Either way works.
Yes, that is a risk. When the end server is itself a traitor node, the traitor node will obviously know when the file is being accessed. Depending on how good a given darknet is, you then have several possible vulnerabilities:
The packets may have information which expose information about the originator (username/password, system-specific headers, etc)
If the packets are not altered en-route, passive traitors within the darknet can be used to track where the packet goes (by timestamp if encrypted only within the darknet, by hash if encrypted end-to-end or not encrypted at all)
The data may contain some kind of trojan or logic bomb that calls home when processed (eg: there was a vulnerability at one point in MS' IE where JPEGs could contain embedded executable code)
This doesn't even scratch the surface of all the problems that could arise. Some COULD be defeated. eg:
If, in addition to end-to-end opportunistic IPSec, you used point-to-point opportunistic IPSec as well, there would be no way of correlating any two packets.
So long as the outside edge of the darknet is limited and the only part of the net to have any kind of unambiguous ID (everything internal being transitory and lasting for less than the lifetime of a typical connection), and so long as everything internal to the darknet was based around Content-Addressable Networks* (rather than host-addressable networks), a call-home trojan or logic bomb can never identify where it is.
*Content-Addressable Memory was developed and actually worked, but was an engineer's nightmare and was abandoned. A content-addressable network would be even harder to develop. Think about how little traction Service Location and Service Announce protocols have for any service other than VoIP and videoconferencing.
Originally, IPv6 mobile networks and mobile IP were supposed to reconfigure upstream routers and have hosts change which IP address they were to direct to, so as to eliminate forwarding hosts and keep latencies down. It proved too resource-intensive (router tables could potentially double in size and the necessary security infrastructure would chew through memory like nothing else on Earth) and too complex for most OS' (addresses become transient during a connection and that does nasty things to the socket semantics).
However, the characteristics of CAM and early IPv6 transient addressing are EXACTLY what you want in a darknet - plausible deniability and untraceability.
This article on the BBC news website was pointed to by a link saying "China lends SCO $10bn". Turns out it was a different SCO. Thank all the gods (and ceiling cat)!
You're basically talking about nodes that turn traitor. You can apply The Byzantine General's Problem to solve that. The system should remain secure provided that in a system of N nodes, more than (N/2)+1 nodes can be trusted. (Which means the smallest safe network has 5 nodes where 4 are guaranteed secure.)
However, partial discovery is sufficient for something like a download, in which case the problem changes slightly. You only need a certain fraction of the information in order to guess the rest. (This reminds me a bit of the problem that the 2DEM encryption mode tried to solve - they showed that using too simple a mode can leave the skeletal structure of an image intact, even though the high level information is scrambled.)
How much information is too much information? You'd need to ask an expert in such matters. The real problem comes in if the packet number is predictable, because then the collaborator nodes can NACK packets they haven't seen and force the resend to come to them.
I'd say more than (N/2)+1 nodes in the main body of the network AND more than (N/2)+1 edge nodes MUST be absolutely trusted to have any level of security. (I believe in TOR's case, these are the same.) Where partial information is a threat, it's going to depend on how much information is needed to rebuild the original data. The Byzantine General's problem suggests one over half the nodes is sufficient, but where a partial compromise is a threat, you're probably looking at three-quarters plus one before the compromise is small enough to not pose problems.
Frankly, you're MUCH better off using some sort of encryption layer. Opportunistic encryption means there's no exposure of the identity of either endpoint. It's less secure, nominally, but you're not wanting something watertight against people who have every packet. You want something watertight against someone who has an indeterminate (and probably small) fraction of the packets. Plenty of secure key-exchange algorithms out there. Oh, then you'd need endpoints that supported such an encryption system.
Fortunately, the hard part is done. Most OS' have some level of IPSec support and IPSec has an opportunistic encryption mode.
To judge from the complaints that frequently get posted to the GENEALOGY-DNA mailing list, even the experienced big-name DNA corps screw up on even testing a few dozen STRs. The chances of fouling up somewhere along the entire genome seems extremely high. Thus, redundant testing seems a really good idea - at least until they improve their methods.
On the other hand, there probably IS a huge market for risk analysis. The DNA analysis market is pretty much glutted, but there's not much out there for DNA analysis for the average person at the moment.
It is worth bearing in mind that the sorts of studies done might not pick up all of the secondary genetic data needed - markers whose presence doesn't alter the probability of a condition UNLESS the primary marker is also present. Simply doing a gigantic "diff" isn't going to pick those up, as their presence isn't always important.
Then, there are conditions with multiple genetic triggers. Chronic fatigue has seven, according to a BBC report a while back, each of which produces a different condition with essentially identical symptoms but which respond to different treatments. (Unless there's genetic overlap, I would assume this means there are 5040 potential conditions that could be produced from these markers.)
Then, on top of all that, some conditions may occur but be too mild to notice. There are claims that autism is far more common than currently thought and certainly, the UK diagnoses it twice as often as the US (implying that either closer examination DOES yield more positives, or that us British are just strange). There's also a claim that many, if not most, people have some degree of synaesthesia. But is it useful to know that there's a very high risk of being normal?
(Ok, ok, Slashdotters might want to know if there's a genetic danger of becoming normal, but ASIDE from that...)
It would seem to me that conditions such as autism and synaesthesia follow something close to a Poisson distribution, with the vast bulk of people at close to no effect. Even if they're absolutely guaranteed the effect, they'll never notice.
Unless studies into risk go far, far beyond the horribly basic and naive results you get at the moment, the results are useless. And that kind of massive data-crunching analysis is something that Beowulf clusters and BOINC clients are going to be very good at......provided an answer even exists. If the severity isn't present in the DNA, then the risk is useless.
I'd (almost) rather use a darknet built over SMTP than use Freenet, which is horribly, horribly, painfuly, agonizingly sloooooow!
TOR, to me, seems to be about the right sort of level of speed and security. I know of no obvious problems with it (other than you can't use applets that call home). This is not to say it's perfect, or that people shouldn't do research, but if there is a benchmark that systems should reach or exceed, I'd consider TOR to be the one to beat, not Freenet.
There are other overnets and underlays which, if you added encryption and randomized routing, would become darknets. Very interesting stuff and very useful in this paranoid age.
Possible, but if the hand was flat and the meteor struck at a tangent, it would also cause gravel burn and not much more.
Also possible is that the meteor had partially disintegrated a little further up and he was grazed by a tiny flake (basically an amalgam of your theory and mine).
A direct strike seems very unlikely. The scar is too long, for a start. The hand would be incapable of either deflecting the meteor OR moving fast enough out of the way.
It'd surely be a function of initial size, initial velocity, initial trajectory and initial composition.
The faster the initial velocity, the greater the friction and therefore the greater the temperature in the upper atmosphere and therefore the greater the burn-off.
The shallower the initial trajectory, the more atmosphere the rock would pass through and therefore the greater the total deceleration experienced from friction and the greater the burn-off.
If the rock is porous or otherwise not particularly well held together, the less heat and the less turbulence needed to break the rock apart into smaller fragments.
There are probably other factors I'm not thinking of here, but since these are the factors used in asteroid impact calculators for determining the effects of an impact, as developed by professional astrophysicists, and since there's no obvious reason to exclude any of these for small meteors or meteorites, it seems logical enough to consider them factors for this sort of strike.
It seems reasonable, in this case, to assume the meteor struck the kid tangentially. In that case, the velocity of the strike would be almost immaterial, as it would not be in contact long enough for any significant heat transfer and there would be no significant transfer of momentum or kinetic energy. I suspect, but can't prove, that a direct hit would have had a terminal velocity in at least one other sense.
There are all kinds of needs in the various worlds of the police, detective agencies, spy agencies, supremacy groups, monitoring groups, pressure groups, political groups, etc, that would LOVE to have packet sniffing software installed 100% legally on the computers and/or modems of opponents and rivals.
Maybe the BBC can start by selling their software for injected targeted ads to US ISPs.
It sounds a good idea and very practical. You wouldn't need anything protruding from the aircraft, since most jet engines have bypasses - you can use the frame for that.
Slashdot Mirror
It's also a good example of why being a company "likely to be around for a while" isn't worth a damn. Mergers and buy-outs happen, to small companies and large, and it renders all those nice platitudes as to why commercial products are so much "safer" to go with into meaningless drivel.
I thought it was "Emacs, Emacs, Emacs!" or "Developers, developers, developers!"
I agree with the specification point, and agree that the lowest level API should be as basic (and standard) as possible. Then, once you have that, you can layer whatever higher-level architecture you like on top, as the low-level drivers are "just there" and will "just work".
However, this doesn't help applications, necessarily. I would argue to help apps writers, you need to standardize the glue between layers, such that sound and commands can be passed from one layer to another in a predictable manner. Innovators can always add new commands that are parsed by their own injectable layer.
I would also argue that it's impossible to chain userland software a-la JACK via the kernel efficiently, as you've a double context switch per element in the chain. Since transforms are CPU intensive, you want to do the fewest composite transforms possible, which means a software mixer should be something you can chain, which means that the heavy-lifting mixer needs to be in userspace.
(Either that, or you're going to need LADSPA and LV2 support in the kernel, plus some way of coaxing "smart" sound cards into supporting such effects. Since the kernel developers would force the first coder who tried to submit such a patch to walk the plank, I don't see it as likely.)
This would leave the low-level mixer for mixing between kernel threads (rather than between applications per-se) and normalizing the inputs. If we're not having to normalize values anywhere else in the process, we should end up with improved quality and less latency. (Anything that mucks with precision hurts quality, and any operation at all hurts latency.)
I think they now say Cricket was invented in Holland or some other foreign country where they can't possibly make tea right.
The mice wanted to recoup the cost of getting Earth built and were wagering the sunspots at Las Vegas.
Given the reputation of the Chinese and Russian mafias, getting to the Supreme Court without heavy investment in the defense industry will be a challenge in itself.
The biggest problem is that any system involving target nodes sending ACKs or NAKs would allow traitor nodes to statistically determine where the ACKs or NAKs originate, no matter how carefully disguised the node. This means that some percentage of the nodes (especially a large percentage of edge nodes) would have to be proxy servers rather than just routing the packets. It's the only way to disguise the sources.
After that, it becomes easier. If all nodes do NOT have a unique address (but have a unique address within a given scope), and double NAT all connections (thus translating between one scope and the next), trojans and logic bombs that call home will identify N possible machines, where N is the number of non-overlapping scopes in the darknet. If N is large enough, it becomes impractical to investigate them all.
Another method is to remove the uniqueness requirement altogether. If there are M nodes that could be referred to, and each router just shotgun blasts the packet to all of them, there are NxM possible nodes that could be referred to. This relies on all nodes in the darknet using highly secure sequence numbers, such that there is a very low probability of the address fragment plus next expected sequence number being the same for two different nodes. To make sure this confuses watchers, simply have all nodes (including the intended recipient) that receive such a packet forward it until the TTL is reached OR the packet hits a router it has already passed through. (In either case, it would be dropped.)
The scattering approach means nobody can be sure of who the destination is. Each of the possible destinations will receive (eventually, by some path or other) either all the packets or most of them. Statistical analysis will tell you nothing about which one is the one that actually processed the data, since that merely becomes a process of sniffing the wire rather than being a terminal point.
(Essentially, it's a re-invention of old fat-wire ethernet, where your computer linked in with a T-piece and just sniffed for the packets intended for you.)
This would be costly on bandwidth, unless all connections were multicast (so there's only one packet per physical wire). You can't use IPSec with standard multicast (as it's a UDP-based protocol), but you CAN emulate multicast in software over TCP. You can ALSO emulate IPSec-style opportunistic encryption over UDP in software. Either way works.
Yes, that is a risk. When the end server is itself a traitor node, the traitor node will obviously know when the file is being accessed. Depending on how good a given darknet is, you then have several possible vulnerabilities:
This doesn't even scratch the surface of all the problems that could arise. Some COULD be defeated. eg:
*Content-Addressable Memory was developed and actually worked, but was an engineer's nightmare and was abandoned. A content-addressable network would be even harder to develop. Think about how little traction Service Location and Service Announce protocols have for any service other than VoIP and videoconferencing.
Originally, IPv6 mobile networks and mobile IP were supposed to reconfigure upstream routers and have hosts change which IP address they were to direct to, so as to eliminate forwarding hosts and keep latencies down. It proved too resource-intensive (router tables could potentially double in size and the necessary security infrastructure would chew through memory like nothing else on Earth) and too complex for most OS' (addresses become transient during a connection and that does nasty things to the socket semantics).
However, the characteristics of CAM and early IPv6 transient addressing are EXACTLY what you want in a darknet - plausible deniability and untraceability.
This article on the BBC news website was pointed to by a link saying "China lends SCO $10bn". Turns out it was a different SCO. Thank all the gods (and ceiling cat)!
You're basically talking about nodes that turn traitor. You can apply The Byzantine General's Problem to solve that. The system should remain secure provided that in a system of N nodes, more than (N/2)+1 nodes can be trusted. (Which means the smallest safe network has 5 nodes where 4 are guaranteed secure.)
However, partial discovery is sufficient for something like a download, in which case the problem changes slightly. You only need a certain fraction of the information in order to guess the rest. (This reminds me a bit of the problem that the 2DEM encryption mode tried to solve - they showed that using too simple a mode can leave the skeletal structure of an image intact, even though the high level information is scrambled.)
How much information is too much information? You'd need to ask an expert in such matters. The real problem comes in if the packet number is predictable, because then the collaborator nodes can NACK packets they haven't seen and force the resend to come to them.
I'd say more than (N/2)+1 nodes in the main body of the network AND more than (N/2)+1 edge nodes MUST be absolutely trusted to have any level of security. (I believe in TOR's case, these are the same.) Where partial information is a threat, it's going to depend on how much information is needed to rebuild the original data. The Byzantine General's problem suggests one over half the nodes is sufficient, but where a partial compromise is a threat, you're probably looking at three-quarters plus one before the compromise is small enough to not pose problems.
Frankly, you're MUCH better off using some sort of encryption layer. Opportunistic encryption means there's no exposure of the identity of either endpoint. It's less secure, nominally, but you're not wanting something watertight against people who have every packet. You want something watertight against someone who has an indeterminate (and probably small) fraction of the packets. Plenty of secure key-exchange algorithms out there. Oh, then you'd need endpoints that supported such an encryption system.
Fortunately, the hard part is done. Most OS' have some level of IPSec support and IPSec has an opportunistic encryption mode.
You've GATA me there. I'm out of puns.
To judge from the complaints that frequently get posted to the GENEALOGY-DNA mailing list, even the experienced big-name DNA corps screw up on even testing a few dozen STRs. The chances of fouling up somewhere along the entire genome seems extremely high. Thus, redundant testing seems a really good idea - at least until they improve their methods.
On the other hand, there probably IS a huge market for risk analysis. The DNA analysis market is pretty much glutted, but there's not much out there for DNA analysis for the average person at the moment.
It is worth bearing in mind that the sorts of studies done might not pick up all of the secondary genetic data needed - markers whose presence doesn't alter the probability of a condition UNLESS the primary marker is also present. Simply doing a gigantic "diff" isn't going to pick those up, as their presence isn't always important.
Then, there are conditions with multiple genetic triggers. Chronic fatigue has seven, according to a BBC report a while back, each of which produces a different condition with essentially identical symptoms but which respond to different treatments. (Unless there's genetic overlap, I would assume this means there are 5040 potential conditions that could be produced from these markers.)
Then, on top of all that, some conditions may occur but be too mild to notice. There are claims that autism is far more common than currently thought and certainly, the UK diagnoses it twice as often as the US (implying that either closer examination DOES yield more positives, or that us British are just strange). There's also a claim that many, if not most, people have some degree of synaesthesia. But is it useful to know that there's a very high risk of being normal?
(Ok, ok, Slashdotters might want to know if there's a genetic danger of becoming normal, but ASIDE from that...)
It would seem to me that conditions such as autism and synaesthesia follow something close to a Poisson distribution, with the vast bulk of people at close to no effect. Even if they're absolutely guaranteed the effect, they'll never notice.
Unless studies into risk go far, far beyond the horribly basic and naive results you get at the moment, the results are useless. And that kind of massive data-crunching analysis is something that Beowulf clusters and BOINC clients are going to be very good at... ...provided an answer even exists. If the severity isn't present in the DNA, then the risk is useless.
They might also give results at the drop of an 'AT.
I'd (almost) rather use a darknet built over SMTP than use Freenet, which is horribly, horribly, painfuly, agonizingly sloooooow!
TOR, to me, seems to be about the right sort of level of speed and security. I know of no obvious problems with it (other than you can't use applets that call home). This is not to say it's perfect, or that people shouldn't do research, but if there is a benchmark that systems should reach or exceed, I'd consider TOR to be the one to beat, not Freenet.
There are other overnets and underlays which, if you added encryption and randomized routing, would become darknets. Very interesting stuff and very useful in this paranoid age.
Ideally, you'd also ensure it had a negative energy density. Then, when it supernovas, you will flood the universe with exotic matter and wormholes.
If it's true, then think more in terms of terror forming. The Earth's ocean currents are showing some dramatic changes as a result of global warming.
That depends on who you test.
Possible, but if the hand was flat and the meteor struck at a tangent, it would also cause gravel burn and not much more.
Also possible is that the meteor had partially disintegrated a little further up and he was grazed by a tiny flake (basically an amalgam of your theory and mine).
A direct strike seems very unlikely. The scar is too long, for a start. The hand would be incapable of either deflecting the meteor OR moving fast enough out of the way.
You just need one very tall man (over 10') or one stretched on the rack to the required height, a hammer and a stopwatch.
It'd surely be a function of initial size, initial velocity, initial trajectory and initial composition.
The faster the initial velocity, the greater the friction and therefore the greater the temperature in the upper atmosphere and therefore the greater the burn-off.
The shallower the initial trajectory, the more atmosphere the rock would pass through and therefore the greater the total deceleration experienced from friction and the greater the burn-off.
If the rock is porous or otherwise not particularly well held together, the less heat and the less turbulence needed to break the rock apart into smaller fragments.
There are probably other factors I'm not thinking of here, but since these are the factors used in asteroid impact calculators for determining the effects of an impact, as developed by professional astrophysicists, and since there's no obvious reason to exclude any of these for small meteors or meteorites, it seems logical enough to consider them factors for this sort of strike.
It seems reasonable, in this case, to assume the meteor struck the kid tangentially. In that case, the velocity of the strike would be almost immaterial, as it would not be in contact long enough for any significant heat transfer and there would be no significant transfer of momentum or kinetic energy. I suspect, but can't prove, that a direct hit would have had a terminal velocity in at least one other sense.
There are all kinds of needs in the various worlds of the police, detective agencies, spy agencies, supremacy groups, monitoring groups, pressure groups, political groups, etc, that would LOVE to have packet sniffing software installed 100% legally on the computers and/or modems of opponents and rivals.
Maybe the BBC can start by selling their software for injected targeted ads to US ISPs.
It sounds a good idea and very practical. You wouldn't need anything protruding from the aircraft, since most jet engines have bypasses - you can use the frame for that.
I wouldn't want a seat anywhere near the plane if the bird swerves between the engine and the fuselage.
Replace the gunpowder in the cartridge with RDX, hollow out the centre of the bullet and add a rocket motor. All set.
Given this nasty bastard hunted by means of bird strikes, I think there are a few birds in New Zealand who would disagree.