No gods, no kings, no billionaires
After a year of writing for the Movie Blog, my good buddy Richard has started up a film-related web site of his own: Filmstalker.co.uk. (Films talker, geddit?)
He’ll be bringing you film news and reviews, and maybe even the odd podcast here and there. Although the site will cover all types of film, Richard has a particular interest in modern horror and eastern cinema, so he’ll probably be bringing you lots of goods from those directions.
Good luck, Richard!
Charlie Stross has just written about an attempt to steal his bank security details not via email, but over the phone:
Some bastard just tried to steal my bank account. I have no idea how they decided to target me, but from the sound on the line they’re running a call centre, and from the accent, they may not be based in the UK at all. If I had taken it on trust that my caller was from my bank and answered their questions, I would be in a world of hurt right now. I’m pretty sure they don’t have my bank details (I don’t leave statements lying around) but there’s one due real soon now that hasn’t arrived yet … and you can never be sure what’s happened to the mail that you haven’t received. Barclays aren’t a major high street presence in Scotland (they’ve got three branches in the whole country) and my phone number has the Edinburgh dialing code, so to be targeted that way implies that they knew beforehand that I am a Barclays customer and were just looking to fill in the gaps they need. Which is worrying. It implies they know more about me than they’d get by just sticking a pin in the phone book.
Something similar happened to us last year, but I’m not sure if it was an actual con, or just clueless behaviour on the part of Ikea. We had just bought our new kitchen, and paid for a large chunk of it with a new Ikea store credit card (to get the 15% discount). The following week, someone called us one evening claiming to be from a company representing Ikea, and wanting to gather some extra information to complete our “customer profile”. Sure. The conversation went something like this:
Them: So, to start with, could I take your Mother’s maiden name?
Me: No.
Them: Uh…we need that information to verify your identity.
Me: But you’re calling me. Surely you know who I am. Or are you just calling people at random?
Them: I understand, but we’re dealing with your personal information here, and the data protection laws won’t allow me to proceed unless I can confirm who I’m speaking to.
Me: Okay…so how do I know who I’m speaking to? You could be anyone.
Them I’ve already explained that we’re a company working on behalf of Ikea to help them complete their store card customer information records.
Me: And…?
Them: (Getting frustrated) Look, if you don’t believe me, I can put you through to my supervisor, and you can take it up with him.
Me: So what on earth is that going to prove? He could just be some bloke you’ve pulled in off the street. If I have no idea who you are, how am I supposed to know who he is?
Them: How about I give you our phone number then, so you can call us back.
Me: And that phone number could just be pulled out of a hat, too. I’d prefer to just call Ikea’s head office and ask them to put me through to you.
Them: But we’re not part of Ikea–we’re an external company acting on their behalf.
Me: We’re not going to get any further here are we? You have no way of proving who you are, and until you do I’m not going to give you any personal details. In fact, I’m going to hang up now.
There was something fishy about the call right from the start, and I tend to be pretty belligerent about companies calling us in the evening anyway. It might have been for real. We had just got an Ikea store card, and it’s plausible that Ikea (or an agent of theirs) would to do a follow-up call to pad out their customer database. But:
The best advice for a situation like this is what Charlie says at the end of his article: never disclose secret information — like your banking details or passwords — through a communications channel which you did not initiate for yourself.
The bad guys really are out there, and it pays to be on your guard when it comes to your money and identity at all times.
At dinner one day towards the end of last year, we noticed a strange smell.
“Alex,” I said, wrinkling my nose, “did you just fart?” (If you don’t have kids of your own, this will sound strange, but it’s true: parents can distinguish the smell of their kids’ farts. Also, we can usually tell by the smell of their breath and body odour when they’re about to fall ill.)
“No,” Alex said.
“Well it certainly smells like you farted.”
“I didn’t fart…I pumped.”
“You did what?”
“I pumped. A fart goes like, ‘brrrp’, and a pump goes like, ‘pffft’.”
“Ohhhkay.”
I’d never heard of the distinction before, but since then, we’ve had this definition confirmed by a number of sources around Edinburgh. I guess it must be a local thing…
I came across an amusing bug in IE6 last week. The existence of a bug in IE is no great surprise, but the way it manifests itself is quite interesting: with just a tiny bit of HTML and CSS, you can cause IE’s CPU usage to spike up to 100% and stay there, slowly leaking away memory. It seems unlikely that this has never been seen before, (especially as it doesn’t occur in the IE7 beta), but I couldn’t find a reference to it anywhere on the web, so I’m posting it here.
It starts off with a simple piece of HTML:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"><html>
<head>
<title>IE6 100% CPU test page</title>
</head>
<body>
<table>
<tr>
<td>
<p><span class="test">abcd efgh ijkl mnop</span></p>
</td>
</tr>
</table>
</body>
</html>Especially in table-based layouts, it’s not unusual to see a span wrapped in a p wrapped in a table cell. The problem kicks in, though, when you apply the following CSS:
<style type="text/css">
p {
padding:0.5em;
position:relative;
white-space:nowrap;
}
span.test {
padding:1em;
}
</style>Setting the position of the p is potentially unusual, and you might wonder why the white-space:nowrap is being applied to the paragraph rather than the span, but at least on the surface, it all looks kosher. Nuh-uh.
I’ve set up a test page with exactly this code in it. Try using IE6 to visit it. Does everything seem to be working as normal? How about if you try resizing your window to narrow it down…and down…until it’s just wide enough to hold the text. Oh no! It’s dead. Poor IE.
Now imagine the text in the cell being wider, or the table having several of those cells in a row, so that even at a normal window size the CPU usage spikes as soon as you load the page. Major bumcraft. This was a pig to track down and debug.
But even having reduced the problem to a simple test case, I’m still not sure why this should go wrong. It looks like IE’s rendering model is unable to resolve a circular reference between the p and the span when the forced width of the nowrap and the added paddings interact. But beyond that…mmmidunno. As always, it pays to be on your guard when dealing with IE and padding.
Update (20 Feb 2006): After playing around with this bug a bit more, I’ve found that it’s even worse than I’d first described. You don’t even need the p to be embedded in a table cell to bring IE down. Using the same CSS as above, the following HTML is sufficient (example 2):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"><html>
<head>
<title>IE6 100% CPU test page</title>
</head>
<body>
<p><span class="test">abcd efgh ijkl mnop</span></p>
</body>
</html>You don’t even have to use a p and a nested span, either. Although I haven’t tested every possible combination, it looks like any inline element nested within a block-level element shows the same behaviour, e.g. an em within a h3 or an a inside a div. If you nest a block-level element inside another block (e.g. a p inside a div, everything’s fine.
What’s even more amusing is if you remove the DTD from the HTML above, and watch what happens (example 3). IE still goes to 100% cpu, but it retains just enough spare capacity to refresh its display. This time, if you narrow the window down, the text disappears, and the window’s vertical scrollbar makes it look like the page has got enormously tall. But if you try scrolling up and down, the content is nowhere to be found. If fact, it looks like IE is still trying to figure out where the content should go, too: if you scroll part-way down the (blank) page, you’ll notice the scroll block jumping up and down like a confused monkey.
But then if you try to widen the window back to its original size, it freezes up completely again.
And yes, it also works if you place the style definitions inline, rather than in a <style> block (example 4):
<html>
<head>
<title>IE6 100% CPU test page</title>
</head>
<body>
<p style="padding:0.5em;position:relative;white-space:nowrap"><a style="padding:0.3em"
href="http://www.example.com">abcd efgh ijkl mnop.</a></p>
</body>
</html>If you needed another reason why it’s a really bad idea to allow visitors to use HTML in your blog comments section, well, there you go.
Over at Bloggie-nominated The Movie Blog, oft-proclaimed “Founder and Editor” John Campea is busy eliminating all traces of Richard Brunton, who wrote most of the site’s content last year. The other week, John told Richard (by means of an an article in the Hamilton Spectator) that he is now earning enough money from the site to quit his day job. Richard, who has received (I believe) approximately the cost of a sandwich and coffee in expenses from the site, went “WTF?” Whereupon John told him he was no longer needed.
Classy.