It seems that the UK government
recently passed a law that makes it illegal to be unable to decrypt what the law enforcement entities think is encrypted:
But it’s worse than that. Much worse. You’re not going to be sent to jail for refusal to give up encryption keys. You’re going to be sent to jail for an inability to unlock something that the police think is encrypted. Yes, this is where the hairs rise on our arms: if you have a recorded file with radio noise from the local telescope that you use for generation of random numbers, and the police asks you to produce the decryption key to show them the three documents inside the encrypted container that your radio noise looks like, you will be sent to jail for up to five years for your inability to produce the imagined documents.
This is just insane.
Edit: The law was created several years ago, but the blog post somehow made me think it was more recent.
See also Steve KempÃ¢â‚¬â„¢s weblog Ã‚Â» Blame it on rock and roll
See also Re: voting on sponsorship
See also Microsoft Windows Vista – They did it all wrong
I came across this article today and really found it noteworthy:
Original title: Why Airport Security Is Broken—And How To Fix It
Kip Hawley, TSA head from July 2005 to January 2009, writes about how the current TSA procedures came into being, how he failed at some of his goals (to make the checks less annoying) during his involvement and what could be done to fix procedures. I especially liked these points:
By the time of my arrival, the agency was focused almost entirely on finding prohibited items. Constant positive reinforcement on finding items like lighters had turned our checkpoint operations into an Easter-egg hunt. When we ran a test, putting dummy bomb components near lighters in bags at checkpoints, officers caught the lighters, not the bomb parts.
(also quoted on LWN.net)
And this one:
The public wants the airport experience to be predictable, hassle-free and airtight and for it to keep us 100% safe. But 100% safety is unattainable.
I think the most important thing he mentioned is the fifth and last of his action items to improve both experience by passengers and security:
5. Randomize security: Predictability is deadly. Banned-item lists, rigid protocols—if terrorists know what to expect at the airport, they have a greater chance of evading our system.
He got it nailed there, in my opinion: If security measures are predictable, the loopholes in it are also predictable, so you basically give attackers a handbook of what to avoid when planning the attack. This, by the way isn’t limited to physical security and air travel, but also applies to IT security (though it is much easier to hide your IT security measures and make them somewhat unpredictable that way, then it is to do so with physical security and passenger screening on airports.
See also No related posts
Well, I normally despise of thinks like this link collection, but I thought I might add it anyway, since these are useful links for me and if I don’t post them here, I’m likely to forget where to find them in the near future:
- Sean Finney has a nice post about storing the list of parameters a (shell) script got in a way that it can be restored later. Quite handy if your script walks through the arguments parsing them (and consuming them while doing so) but you want to be able to display them in a helpful way if the parsing fails at some point.
- A while ago, Ingo Jürgensmann had a post that helps retrieving files from lost+found after a filesystem check, provided that you run his helper script on a regular basis. The same approach can also be used if you have a backup of all files, but lost the sorting work you did after the backup was done. This is possible because running the script can be done more often then you would normally do backups.
- He also has a small post about mtr oddities when IPv6 comes into play
- Adeodato Simó wrote about databases and when timestamps that store the timezone information really are more useful then timestamps that don’t.
- Adeodato also has a short post on using ssh as a socks proxy, which can be quite handy if you are behind a firewall.
Update: Fixed link to Ingo’s file retrieval from lost+found article. Thanks to Patrick Schoenfeld who pointed me at the wrong link.
Also thanks to the anonymous poster who found an alternative way to store and (in a way) restore commandline parameters. The solution doesn’t work in an as general way as that by Sean Finney et al., but it is much shorter and therefore interesting for where it can be used (when you control how commandline parameters are processed). See comments on this post for details.
See also Link collection 2009/05/18
See also Another link collection 2009-06-22
See also Dual boot and full encryption – Part 2
In the recent online article heise online – IFA special – Force-Feedback-Weste mit Kitzelattacke, Heise News (a german IT news site) had a really nice caption under one image showing a new force-feedback vest by Philips. The image looks like this:
The german caption is: “Philips’ Force-Feedback-Weste ermÃ¶glicht tÃ¶dliche Kitzelattacken in PC-Shootern.”
Translation to english is: “Philips Force-Feeback-Vest allows deathly tickling-attacks in PC-Shooters.” (Means First-Person-Shooters).
Nice. That’s at least a pleasant way of dying: Being tickled to death.
Of course, the article itself clears up the misunderstanding: The vest is more tickling than “punching” the player, even if his game-ego is killing most ferociously.
See also Init HackFest / New init systems in Debian
See also The DM GR