I think we'll disagree on the sufficiency of crypto, but we definitely agree on the necessity!

Would you say they're ordered? I so I'd want crypto first and laws second, if only because crypto takes less time to write (:-))

I quite agree, the technology changed, and we need to both change with it, and take advantage of it to create stronger guarantees. At the same time, we don't want to depend on a single point of failure.

I actually think we need a defence in depth. Guarantees offered by an arms-length postal service, technical means of testing the protections, legal protection from the law where the guarantees are breached, and enforcement of the law by independent, arms-lengths police under the oversight of a string court system. Add to that a technology that makes it impractical for a middleman to leak one's information, and protection against a security service demanding your keys without laying a 20-page "information to obtain" before a non-trusting judge.

We're not just protecting ourselves against the watchmen: we're also protecting against plain ordinary villains, ones who will snatch your letter out of your hand and go belting off down the street with the "Bow Street Runners" in hot pursuit!

--dave
I once took a safety-critical-systems course: from it's point of view, our email system is at least as horrible as post-cards, and perhaps even worse

We used to use paper envelopes with glued or wax seals, and the government guaranteed they would deliver the letter unopened. You could verify both in the era when that was current technology. For the king's spymaster to read your mail, he had to get an order from a judge to authorize it, and employ a fair bit of skill to replace the broken seal or envelope. Similarly, "pen registers" of who you communicated with also required judicial permission, but weren't detectable.

Over time the technology changed, but the guarantees held. They hold to this day.

Today we need the same guarantees for email, that a security service needs a court order, and that you can detect non-deliver or opening. This suggests a B>very different law than proposed here. The ACC should be saying

Because of changes in technology, the ACC has obtained access to a windfall of information without judicial oversight, in direct contradiction to existing law concerning the postal service.

While this has aided us in the investigation of serious and organised crime, it is arguably a breach of at least the spirit of the law. The ACC request the TIA act be amendeded to provide the same protections to Australian citizens as they have for postal mail.

ACC will, effective immediately, apply to the courts for retention orders for material it wishes to be kept, production orders for information which it wishes produced, currently called "metadata", and wiretap orders for information which is the content of messages. We understand this will have an effect on investigations which are proceeding illegally, but as guardians of the public, it behooves us to obey the law"

If you have a 97.54% chance of a "perfect" match on all those criteria, remember the birthday paradox. If you compare 23 people against one another, you get (23*22)/2 = 253 comparisons. Multiply 253 * 0.9754 and you get 246.7 correct, 6 wrong.

Six failures out of a pool of 23 (hijackers + passengers) is insane, and is therefore one of the reasons that the German Federal Security Service rejected my employers' facial recognition system many moons ago. Until we get to 1.0, the number of false positives will be more than we can manually re-inspect in time for them to make their plane.

This deserves to be widely labelled as an urban legend, and ridiculed.

I'd suggest money buys a more effective microphone, as one gets on the big newspapers and the big, high-readership sites, far more easily if you have the bucks.

It's on things like IETF discussions that money doesn't help as much, as it's hard to find people to astroturf on technical subjects, and they rapidly become well-known.

The intention is to convince the reader that they can't sue for the dead rat they found in their canned corn, so they won' t try.

A former employer shipped rat-enhanced corn once, and was both sued and fined for doing so. They became very thorough about warning the employees to watch out for furry critters in the plant (;-))

In a previous life, we passed around virtual machines rather than doing paperwork. Paperwork is to be sure you have a plan to solve the explosion-and-revert problem.Managing machines instead of paper allowed us to include a process for doing an immediate revert on explosion (;-))

The VMs we passed around were Solaris zones, so they were very lightweight. If I wanted to apply an emergency patch to production, I first applied it to an image, put an instance on pre-prod, a physical machine, and varied it into test. After the smoke-test, I varied it into the pool on the load-balancer, and watched it closely. If it fixed the problem and didn't explode, I put lots of instances on the production physical servers and put them into the load-balancer, quiescing the un-patched instances but not erasing them. If the patch blew up after all, I could revert to the previous buggy release as fast as the load-balancer could disconnect people. Not quite as fast as doing an atomic change on a single server, but fast.

This is a minor variant on some old unix norms: 1) you aren't prohibited from doing even silly things, as prohibitions will keep you from doing something brilliant. 2) You can do anything, but you can't hide what you did, 3) you can change things atomically while running, and 4) if you do something dumb, you can revert it immediately.

The process is a variant/predecessor of ITIL, with pre-set apply and revert steps for emergency changes, which are the high-value part of the whole ITIL change process. Non-emergency changes were a little more heavy-weight, as we tested the patch in an instance in QA, then did a simulated UAT overnight (it was automated, but exceedingly slow), reviewed the results and then the de-facto board decided if we could release the image to production, QA and dev. Your paper-oriented CAB does approve all patches to QA and dev, right? I'll bet they missed that part (:-))

--dave
I did once have a customer where I had to do paper-based CAB approvals, but that was because we weren't funded to have a proper dev, and had no QA at all. As you might guess, we still had at least one fiasco. I shortened the contract as much as I could without doing a no-bid in the middle.

According the wikipedia, the number of pictures being seen as the same with probability p is =sqrt(2d * ln(1/1-p)) If d is 52,000,000 and we use a 99% probability, then for each 21,884.6 pictures we get a false positive with a perfectly accurate matcher. And there are no perfect matchers.

This is a variant of the birthday paradox, where it only takes 100 people to get a 99.9% chance of them having the same birthday, and a mere 23 people to get a 50% chance [wikipedia].

The German Federal Security Service rejected facial matching years ago, for exactly this reason, when I was working for Siemens. The Americans did not, and supposedly stopped someone's grandma for being a (younger, male) terrorist.

If they use this, expect a week or so of everyone's grandma being arrested (;-))

--dave
Mathematicians, please feel free to check me on the numbers: I suspect I'm rather low...