false positives

The example this guy gives to show the "benefit" (since it's of no benefit to anyone except insurance companies, snoops and other assorted control freaks) of the system and "that it works" is completely bizarre...

"In a simplistic but real example, he said, the software noticed two people separately reported their cars, registered at the same address, had been damaged at the same time."

Let's put this in another way... a man gets struck by lightening, then later in the same day he gets struck by lightning again. While this is certainly unfortunate, and we might consider him especially unlucky, we can't actually infer that the two events are in any way related, whether it's because of him being especially unlucky, cursed by a vengeful deity, because he's looking for attention, or whatever. Once he's had his first lightning strike of the day, which we could write as 1/p_strike, his chance of having another lightning strike in that day is still the same: 1/p_strike (give or take a few hours).

So to get back to this "expert"'s example, for every person who has damage done to their car on a given day, and calling the probability that this happens is 1/p_damage, then if say there are 1000 reports of damage every day, then 1000/p_damage of them will be unfortunate enough to have two accidents that they need to report. There is nothing suspicious about this at all!

Either this person has no understanding of basic statistics, or they are deliberately lying. Either way, I would not pay anything for advice from this person.

@Trolly Badger

"but none of it usable in a commercial proprietary product"

Ah, that old canard. Maybe you've never heard of the LGPL? Many fine bits of free software give you the option of using either the full GPL (if you want to extend/modify the code) or the LGPL (if all you want to do is use the code, unmodified, as a library to link against). As the GNU website puts it very succinctly: "using the Lesser GPL permits use of the library in proprietary programs".

As for your suggestion that many commercial/proprietary bits of code have GPL code in them without following the rules, well it's hardly the fault of the software license that there are greedy/lazy developers out there who see no problem selling plagiarised code for profit. Is it?

@What a load of turd.

> When a re-sent packet comes along with a completely different CRC from the first then it's

> quite obvious that something dodgy is up

It's trivial to create a new packet with the same CRC as the original.. the CRC is simply the remainder in a polynomial division (in GF_2), so a small bit of linear maths is all that's required to calculate a constant term to add to your new packet so that it has the same CRC as the original.

@May already be defeated:

> I think some firewalls already deal with this e.g. from Checkpoint SmartDefense

> you would get the message "Retransmitted data does not match original data".

It really depends on where Mallory is situated. If she's doing egress filtering on your connection to make sure that you're not sending secret messages, then it's a valid point. Packets with transmission errors are, by definition, going to have different contents in general, though. If Mallory is close to you, then she has a better chance of detecting that the error rate on your transmission link is higher than it should be... Someone eavesdropping at the far end has slightly less chance of determining this because each node the packet passes through has a cumulative chance of inserting an error. With the internetworks being quite reliable, and getting more so, though, using error packets becomes more detectable, no matter where Mallory is situated.

There are more interesting algorithms out there

Any noisy channel can be used for stego. There's nothing in particular that makes this idea stand out as interesting. As pointed out by several posters, this is quite easy to detect, particularly if the parties try to get a lot of bandwidth from the channel by giving up any attempt to make the retransmitted packet look like a slightly-mangled version of the original (or vice-versa). Anyone suggesting using this for bittorrent traffic obviously has no idea about how bandwitdh-limited subliminal channels have to be.

A more interesting system, IMO, is Rivest's chaffing/winnowing system:

http://people.csail.mit.edu/rivest/Chaffing.txt

The chaffing/winnowing system could be used on top of any communications channel, so it would be easy to implement on top of the retransmission system. Both parties would have to have to have to be running a synchronised message authentication algorithm (either a secret algorithm, or a known algorithm seeded with a shared secret key or nonce) so they can flag a retransmission as containing stego data at one end, and recognise it as such at the other. This would make the system more robust in the face of genuine transmission errors, but as noted with the basic system, you're still generating more noise than would be normal, which will betray your use of the channel to transmit more information.

Yet another option would be to encode your message as a function of the data actually being transmitted. If you're uploading a web page, you could build, say, a Huffman tree or markov model based on the word or character frequencies in the document. Your message could then be encoded in a compressed form by using shorter codes for any word appearing in the document. You could then send an unsolicited retransmission containing your message that's been compressed relative to the main stream and an authentication code to show that the retransmission contains a subliminal message. Throwing in a few more "chaff" retransmissions (which would fail the message authentication code) makes the job of analysing the substance of the subliminal channel more difficult. This is a bit more interesting (again, IMHO) and should use less retransmissed packets than the schemes described in the article, but it's still of fairly limited use..

so what you're saying ...

is that you could make more money with a flop?

@Robert Grant

> 3) The ratings system - which is all Arnie is in favour of reinforcing here - is there to help parents, not usurp them. If this isn't obvious to you, then I suppose no reasoning will help.

No, RTFA. This is about criminalising the sale of certain titles to people under the notional age. It says that it's not the parent's decision whether or not they want their precious playing Diorama of Debbie Does Dallas or whatever--it's up to the government. If that ain't usurping, I think one of us needs to get a new dictionary.

another solution

Pass your XML through a validator to make sure it's well-formed before trying to parse it. I know that's often not seen as practical, but it's in keeping with the whole XML standard thingie: if it ain't well-formed, then it shouldn't be processed, end of story. Of course, even though that's what the standard says should happen, lots of programs have problems when presented with malformed XML.

I was wondering if an if ($child=fork) { sleep $timeout;. kill $child } pattern would work, but judging by the article the child might still never get to handle the signal. Maybe terminating with extreme prejudice (kill -9) would work. Anyone know for sure?

Anyway, interesting article. Definitely something to be aware of when working with XS modules, though it may not always be obvious to the programmer that the library is actually calling C routines to do the work. Most of the time, probably, but maybe not all...

foo! to all this nonsense

Come and visit my new site weapons.com where you'll be able to buy spoons, sharpened library cards, bic pens and razors in a dual pack (some assembly required; be careful not to cut yourself!), white spirit, icicles (please be sure to order in conjunction with liquid nitrogen!), toenail clippers, individual sugar sachets (unlike other retailers, there is no per-customer limit!), peanuts and plastic bags.

We are currently experiencing a backlog in fulfilling orders for atlatls, as these have to be hand-crafted. We apologise for any inconvenience.

fair review? hardly

Somehow you've managed to take all the bad things about this format and phrase them in a positive light, while simultaneously taking Flash to task for what are often eminently sensible design decisions. Let me give some examples:

> There is no frame-based animation

Which you talk up as a positive because it's what programmers are used to. So I'm guessing that this will be of no use to graphic designers who are accustomed to working with timelines, actions that start at a particular time in same and suchlike. You spent the whole of the preceding paragraph berating the Flash way of doing things because it ...

> basically encourages bad code, you can bury code in a literally infinite number of

> places - external files, movie clips, timeline frames, frames within movie clips.

> It gets ugly very fast.

There are reasons why you might want to put code in different places. The main reason is that there is a timeline-based model and you will want to put whatever code you have as close to where it will be used as possible. As for the other places mentioned, I wonder if you've never heard of a thing called modularity? Perhaps if I explained that a movie clip can be modularly reused to control a sprite animation, for example? Would that help to demystify the code placement for you?

> Silverlight apps can be built with anything from C to Ruby.

So in other words, whereas Flash offers a platform-independent environment (wherever there's a suitable rendering engine ported), Silverlight will allow you to embed raw fscking machine code output from a C compiler? WFT? I take it that this means that Silverlight users will have to have have a hefty bunch of .NET support installed before this will work, and that they'll have to rely on its sandboxing mechanisms to ensure that any rogue code won't simply take over their systems. Ludicrous!

As for that last paragraph, please decide if you're a fanboi or an apologist. Pick one and stick with it.

how to store data in a sieve

step 1: freeze the data collection.

ha you almost had me there

Until the bit about lambda functions! Now if only they'd implement first-order closures ...

@Testing children.

> Ironically a fundamental aspect of science is the empirical measurement of things...

Equally ironically, a fundamental aspect of quantum mechanics is that by measuring a system, you change it. How low do you want to go?

correct answer for B

could be either, assuming that's a Norwegian Blue pictured on the left-hand side...

poor headline

OK, so I use Linux, and I consider it more secure than Windows, so I guess I'm open to complaints of blind fanaticism here, but I've got to agree with several comments here that the vulnerability described isn't really anything of the sort. If I'm reading things correctly, all that's being described here is a kmem-based method of building rootkit-like behaviour. In fact, this is neither a new technique nor a new attack. At best, all the technique can achieve is hiding an existing attack. It does not (again, at least as far as I've read) point to an exploit which can be used to actually gain control of the machine.

As for the HFS exploit, I think there is probably more justification in calling it a potential exploit, but again, bugs in filesystem mount code are not exactly new, and have, to my knowledge, always been very much theoretical as opposed to something that has much of a chance of actually being workable "in the wild". That said, I don't know much about how OSX works. If (and only if) OSX formats USB sticks using HFS then I'd have to upgrade the risk from "theoretical" to "quite practical", but it would still require the user to insert a dodgy USB disk, meaning it's most likely only useful as a targetted physical attack (where the attacker either has physical access to the machine, or can trick someone who has into inserting the device) rather than being of any use as a means of spreading virus or worm functionality.

All in all, very little to see here... let's move along.

"with a view to seizing CCTV evidence"

Bit of a Freudian slip, methinks. Surely "securing" the evidence would be more appropriate. Unless the intention is actually to make sure that the police are the only ones who are allowed to have the video tape/disk/file?

I sincerely hope that anyone in possession of CCTV footage make sure they make their own copy before providing a copy to the police. As many people have pointed out here before, the police don't have a very good track record when it comes to such footage.