Anatomy of a "feature" - should JavaScript be allowed to change a web link *after* you click on it?

Filed Under: Featured, Vulnerability

A young web coding enthusiast from Manchester, UK, recently published a thought-provoking hackette intended to highlight the risks of relying only on "look before you click" while browsing the web.

With a brief and unexceptional-looking line of JavaScript, he reminds us that the URL your browser displays when you hover over a link isn't necessarily where you will end up.

Your click destination can be changed by his script even after you you click it:

If you've done any JavaScript programming, or delved into the source code of any web pages, you'll know that the <a href="..."> tag is how HTML specifies a hyperlink, and that the onclick attribute is how you tweak the behaviour of the browser when the user clicks a link.

You'll routinely encounter a number of onxxxx attributes used in modern web programming, such as:

  • onmouseover: when you move onto an element, such as a menu
  • onmousemove: when you move around over an element
  • onmouseout: when you move off an element
  • onmousedown: when you press the primary mouse button
  • onmouseup: when you release the primary mouse button
  • onclick: after a mousedown followed by a mouseup

The animated buttons, active menus, popup calendars and general razzamatazz we expect from 21st-century cloud applications all rely on this sort of event-driven programming, where the browser sits in a loop waiting for you to do something, and then reacts promptly as soon as possible after you do.

Without these event hooks, browser-based apps would be so different from the desktop applications we're familiar with that they'd be unintuitive and largely unusable.

The next bit of the trick involves using the onclick event to change the href attribute of the link you just clicked.

When an HTML page is loaded, the href, or hyper-reference, of each link is what was specified in the href attribute of each <a>, or anchor, tag in the HTML source file:

You'd think, or perhaps hope, that these links would be somehow sacrosanct, so that the browser could display them when you hovered over them, and thus indicate precisely where you would end up if you were to click.

→ A legitimate-looking URL isn't necessarily trustworthy, since most infected websites don't belong to cybercrooks, but are hacked sites used to serve up malware or poisoned links while letting someone else take the blame. But it's still reasonable to assume that the link you see is the link you'll get, not least because this would force dodgy URLs to look dodgy up front.

Sadly, the web hasn't adopted that sort of simple and straightforward honesty.

Browsers, in fact, used to make it really easy to suppress the display of a click destination, simply by setting the onmouseover event to a dud operation, such as onmouseover="return true;" to tell JavaScript to report success without actually doing anything.

That doesn't work any more, for security reasons, but there is plenty of other "legitimate trickery" in use out there, most of which we accept as a necessary evil (or perhaps as an invisible and irrelevant part) of today's browsing.

Google, for instance, lets you hover over a link to reveal its final destination:

But it doesn't take you directly to the designated URL when you click, as you can see if you right-click to open the link in a new tab:

Instead, you are diverted through one of Google's interstitial links that keeps track of which users are doing what, where and when.

That's the price you pay for Google's admittedly very powerful, uncannily accurate, immensely useful and free-as-far-as-money goes search engine.

But the issue, as our young Mancunian suggests, is, "Should our browsers work this way?"

In particular, the issue he's thrown into the spotlight, namely changing the destination of a link after you have clicked on it, seems to be a race condition too far.

You wouldn't expect airline security to allow passenger A to go through the security check and then to swap places with passenger B who had not.

You wouldn't expect a shop to show you a price of $99 on your credit card slip, ask you to approve payment, and then quietly bill you a completely different amount.

Is it time for browsers to get stricter about how and what they display, and how much manipulation of status information is allowed using JavaScript?

Should there be an option to show you precisely which URL you are going to when you click, so that you can at least try to make an informed decision about it, no matter how hard that might be?

Or should we simply accept the comfort and apparent simplicity of a slick-and-quick web browsing experience, even if it leaves the door open for chicanery?

Tell us what you think in the comments...

PS. Although Naked Security comments ask for a name and email address, you don't have to identify yourself. You can use the name "Anon" and leave the email address blank if you like.

, , , , ,

You might like

60 Responses to Anatomy of a "feature" - should JavaScript be allowed to change a web link *after* you click on it?

  1. Biffo · 930 days ago

    Completely wrong! Both the Java bug & the Google snooping & recording are wrong - which is why I very seldom use Google.

  2. Kim TD · 930 days ago

    wow, I thought sooner or later, someone might figure it out... But it would be extremely hard for a lay person to check every website click, still the link could be hijacked later... Wouldn't it be possible, to enforce browser to notify user when the link changed? Advanced users can turn this option off, but lay person can sleep a bit easier?
    Thanks for sharing this.
    By the way, I saw you talked a few times at Infosec events ;)

    • J2897 · 930 days ago

      "Wouldn't it be possible, to enforce browser to notify user when the link changed?"

      Yes, with the RequestPolicy add-on for Firefox.

      • Solenoid · 930 days ago

        Excellent, thank you J2897!

        I'm learning what RequestPolicy does, and how it is recommended to be used along with NoScript for secure Firefox browsing.

        This may have answered, in a way, the question that I posted earlier which is now further down the page, though I'm unsure. This is a good discussion among comments.

    • spryte · 930 days ago

      I agree wholeheartedly!
      As one who is one several mailing lists, I am considering removing my self from several which provide neat iconic links to sites I am not familiar with or are fully obfuscated.
      As you say: "A legitimate-looking URL isn't necessarily trustworthy..."

  3. Barney · 930 days ago

    Hackers will always be ahead of browsers' capabilities for foiling their exploits. There are many (most?) people who will click on a link without checking that the underlying URL is bogus or not, let alone realise that their click has been hijacked in this way, so ideally browsers should do everything they can to detect this sort of trickery.

  4. Josi · 930 days ago

    In my opinion: Block JS on all Pages you do not fully trust. Use the noscript addon or similar to disable them. There are much more things you can do with javascript in the browser, this is just a small more or less cosmetical issue.

    • The problem with "Block JS on all pages you do not fully trust" (which IS a good starting point, depending on your definition of "fully trust") is that these days, a lot of the attacks actually come from pages which you might use and which require JS.

      We've finally reached a point on the www where you have to trust that ALL the sites you visit haven't been the victim of an attack or compromise. With this kind of JS hackery, a ne'er-do-well could find a way to inject the JS into a popular site, and unless that site checksums their data, nobody would likely notice until at least one person got hit with the malicious payload. If there's no malicious payload (it's for exfiltrating business data or substituting affiliate ad banners, or clicktracking), such a scheme could go on for months before someone noticed (unless they were running the RequestPolicy plugin or something similar).

  5. How is this a 'hackette', it's basic stuff a 5yo knows.

    • Paul Ducklin · 930 days ago

      Three observations:

      1. I think the word "hackette" is an ideal label for this sort of thing, and an excellent turn of phrase...if I do say so myself.

      2. I will wager that very few five-year-olds know quite as much as you suggest about JavaScript events.

      3. Did you read the headline and spot the question mark?

      This isn't about whether you think the item of discussion is widely known by very young children (which is something of an irrelevancy in this case), but whether browsers should make this sort of thing easy, and whether we ought to expect and to tolerate it.

      • ColonelFazackerley · 930 days ago

        Hackette looks fine to me. One implication of "hack" is that the method may be a bit ugly. The diminutive ending suggests it's minor. This feature is both a bit ugly and minor.

      • Balthazar · 930 days ago

        I knew it when I was five. I'm 39 now.

    • 4caster · 930 days ago

      LeibowitzCandle, that is an arrogant comment. I consider myself quite streetwise at recognising internet fraud, but I have learnt something today. If you were to conduct a survey you would find that few people even know that a URL appears when you hover over a link. I do it all every time except from sources that I know I can trust. If the URL is different from the link described in the text of an email, for example, I immediately smell a rat. But for the URL to be false has never entered my head till today. I cannot think why a legitimate company like Google would want to disguise the name of a site so that the user is taken to a different site from the one chosen.

      • Rahul · 924 days ago

        Google doesn't and would never re-direct us to a different site .The question that arises in your case is about the user's privacy.

      • Casual · 924 days ago

        Idem here. Never thought of a third possibility. Always trusting my instincts on checking the URL would be enough to know whether the destination would be legitimate or not.
        As for Google, I've noticed they started doing the link redirection not long ago. To be frank, it's quite annoying. They love collecting info from everything, everywhere. I wonder what they do with this.

  6. Should there be an option to show you precisely which URL you are going to when you click, so that you can at least try to make an informed decision about it, no matter how hard that might be?

    Yes, and ideally this should also apply to shortened URLs. (Following your airline analogy, when I go through an airport gate onto an aircraft I expect to be taken to the destination shown on the gate.)

    How practical that would be I am not sure.

    Meanwhile, is it possible to write an addin to prevent browser's onclick events changing URLs?

    • Hearth · 930 days ago

      Agreed. URL shortening always bothers me - the browser (or a plugin) should be able to expand the full URL to enable making an informed decision. This would be particularly useful when these are chained, such as is common on twitter, eg; -> -> -> final destination.

      Forcing the browser to inform users about actual URL destinations would also circumvent possible CDATA: url injection hacks as well.

  7. MontyMcG · 930 days ago

    LeibowitzCandle is just showing off his/her superiority, which, unfortunately, had the opposite effect. To answer your question-- ABSOLUTELY YES!!-- one SHOULD be told EXACTLY where a specific link will take one if it's clicked on. To do otherwise is dishonest and unethical.

  8. Richard · 930 days ago

    There are many other ways to achieve the same effect without changing the href when the user clicks the link - "location.href = url; return false", "location.assign(url); return false", "; return false", etc.

    Fixing them all would break a large part of the web. Even if it's possible to fix them, who's going to pay for people to go back and fix pages from 2003?

    • Balthazar · 930 days ago

      "Even if it's possible to fix them, who's going to pay for people to go back and fix pages from 2003?" - Those who run web sites using the features, unless they fix the pages themselves, in which case they won't have to pay anything.

  9. Bob · 930 days ago

    To answer the author - yes, this is bad news, and web browsers and mail clients should adapt ASAP.

  10. tian · 930 days ago

    Most modern web applications are preventing the default behaviour of clicks on links or a buttons in a form with JavaScript. This is an accepted principle in website design - frameworks like jQuery even offer easy ways to prevent the default actions a browser would take after clicking a link or submitting a form. As developer you need to be able to do this to create modern webapps. If browsers would not allow it, many websites especially if they rely heavily on JavaScript, like Gmail or Facebook, would stop working.
    What browser could do is warn the user when a link was clicked and the link target was changed with JavaScript, but I think this would get annoying pretty quickly and most people would turn the browser feature off.

  11. J2897 · 930 days ago

    You can bypass Facebook's cloud-based spyware by right-clicking the link, selecting 'Copy Link Location', then pasting it into the address bar of a new tab. It will probably work on Google+ too.

  12. Jakob · 930 days ago

    I don't consider this to be a security problem at all. You can only do the link manipulation if you have the possibility to execute javascript code in the context of the site. However, an attacker able to do this can also directly redirect the user to a malicious site using javascript (window.location =""). This doesn't even require the user to click on a link at all.

    • Balthazar · 930 days ago

      There may be entry points where hackers could inject javascript code where the window.location won't do the trick. For instance in an e-mail, or perhaps places where a web site incorporate third party code like in an ad or something, which may be protected against the window.location method. The point is that there are so many different possibilities, web site administrators may not have thought of them all.

  13. Anonymous · 930 days ago

    A real, non-joke site wouldn't do this. If it did, it's already been compromised, and whoever did it could have done something worse than this.

    The only place I can think this of where this would be a real problem is if anyone ever thought it would be a great idea to enable JavaScript received in E-mail messages. Then, someone could manipulate one of those "Your password has been compromised! Click here to change it!" links to send you somewhere you weren't expecting. However, if JavaScript were fully enabled in E-mail like that, the sender could also just set window.location to take you anywhere without your input.

  14. Jack Wilborn · 930 days ago

    This type of programming is what causes problems. I would hope they would not do this, like ordering something and then getting something else!

  15. David · 930 days ago

    "Bait and switch" is universally recognized as deceptive, and equally widely held as illegal and unacceptable. Seems to me that this is nothing more than a browser-enabled version of the age-old practice. While I'm not one to normally opt for "big-brother" type controls, I feel that this is a feature that should not be allowed/supported at all. It isn't needed, and it isn't appropriate.

    There is no valid reason for changing the user's choice after the fact. You should be serving that link up with whatever dynamically generated URL is needed in place, before the click event is even offered. If you can't manage your context-sensitive any better than that, you should be doing something else for a living.

  16. Phil R · 930 days ago

    It would seem possible for there to be an inobtrusive warning indicator when the URL contains an onclick event that may change the href to something other than that which is held against the anchor tag. Or merely a config option for Block, Prompt or Ignore. In the same way as hundreds of other security options are dealt with.
    This sort of functionality is key to most websites so should remain - but users should be more aware.

  17. Solenoid · 930 days ago

    I use NoScript or NotScript for this and other reasons, which cripples most sites that I don't frequent or trust, until I choose to allow resources. Admittedly not foolproof, but it's better than automatic and uninformed usage.

    To answer your question, No. I don't think that should be allowed, but is. As an available conjunction within the diverse abilities of the code, I feel it's like dividing by zero in math: you can write it on paper, but it doesn't make it computationally meaningful or useable elsewhere.

    My questions: Is it possible to create a browser add-on that selectively disables offensive JavaScript vulnerabilities like that one? i.e., allows other scripts to run but overlooks certain functions as you so choose.

    Or, is there something like that already available even?

    Thanks Mr. Ducklin. FYI, I'm older than 5 years and did not previously know this in detail. Maybe I should hire a 5yo, or an unhelpful assistant with an equivalent maturity.

  18. **EJ** · 930 days ago

    What do we think? I can't imagine many would believe this should be allowed or is necessary. It obviously should be done away with. Securing users is tough enough without skewing the game even farther in support of the scammers.

  19. Rich · 930 days ago

    Perhaps we just need a little more transparency. The browser could provide a pop-up saying, "You are being redirected to ... OK?" Or maybe provide a button on the toolbar to enable/disable Javascript. Yes, this lets you right-click/download images the owner's tried to protect but you can do that anyway.

    Trouble is this sort of thing tends to appeal only to techie types; the average user's just interested.

  20. ccc · 930 days ago

    A lot of websites use this legitimately, many of which have been for countless years. By the way, that script isn't changing the link after you click it. It is changing the active tab/window address UPON clicking.

    Technically, if you used an onmouseup() to change the tab/window location, it would be AFTER the click. :P

    • Paul Ducklin · 930 days ago

      Well, the "onclick" event funtion is called after the click event has it is, indeed, happening *after* you click. (By which I mean that it is the click that causes the change.)

      And IIRC the "onmouseup" event always precedes the "onclick" event.

      (It has to - a click is defined as a mousedown followed by mouseup within a certain time, *and not followed by another mousedown/mouseup pair within another certain time*, behaviour which would trigger the "ondblclick" event.)

      I think you will find that clicking the mouse once causes the following three events in the following sequence:


  21. Grep · 930 days ago

    A lot of website functions feature javascript applets, and links within those will simply (in chrome) display "javascript: someFunction();". I think that the kind of redirecting discussed in the article is of course bad, but is it a similar thing for someone to just write a bad javascript application that looks (with a picture, or something) like a link to something useful, but isn't? All you would have to do is name the function something innocuous, then be redirected after clicking to a compromised site. Or, it could be used in a phishing attack, similar to the login buttons below the comment field. Could someone trick you into clicking on the login button, and be shown a login screen that looks exactly like the real thing, but isn't? Please let me know if I'm totally wrong - thanks :)

  22. Allan D · 930 days ago

    Interesting article which brings out a lot of worries. The problem seems to be the usual where you have to weight between usability versus security.

    I hardly think that browsers can lock down this "feature" in such a way that it actually makes any sense.

    As soon as this problem has been fixed then what about if the line

    this.href = "; is changed to

    document.location.href = ";;
    return false;

    then to the enduser the problem is the same, but for the browser developer, how can it possibly handle the situation and provide the enduser with a feasible solution?

  23. Ancient Brit · 930 days ago

    Anything that reduces vulnerability (as a default) for the general user is IMHO necessarily A Good Thing, even if more knowledgeable hackers bitch about having to turn something on (or off). Caveat venditor, IMHO.

  24. Anon · 930 days ago

    Google Chrome shows the true link at the bottom anyway

    • Robert · 930 days ago

      I think you have missed the point here?

      Most browsers, not just Google Chrome, show the "true" link, but this technique changes what that "true" link is as you click. Before you click every browser, including Chrome, will only show you the "original true link". Once you have clicked the new link is substituted and you are taken to that link with no time or chance for a human to react to the changed link and cancel the action.

  25. FR · 930 days ago

    Javascript is a programming language, it can do what it is specified to be able to do. Programming languages are useful primarily to the they give free reign to programmer creativity and imagination. Limiting the ECMAScript spec is not the solution to this problem.

    Browsers are applications whose security settings can and do have huge consequences for the safety of their users.

    The Browser is where these problems should be prevented, as Kim TD mentions.

  26. Steve-o · 930 days ago

    While I find this interesting, I think it is also acceptable. Reading and writing code is impressive to a layperson like me. Perhaps browsers could display more of this code you mention, as a view option (not on for everyone), for those interested in reading and deciphering the links. I would leave the feature off and continue with my browsing.

  27. Steve-o · 930 days ago

    My stance is like, I don't think a few bad links should ruin the experience or dictate the future of all the other good links. I don't think it's worth the resources to deal with, create rules and enforcement policies and agencies to follow through with said enforcement. I don't think I can bring my own bottle of water on a plane because of a few people (less than one hundred). I have to pay extra for any new car because reverse camera's were mandated because of a few careless people (less than ten). I can't get an ar-15 with a 16 round clip because of... okay, I don't really know how many people and that's another subject and I don't really want any firearms, but it's sort of illustrative of over-reaction cutting intro freedom. Freedom isn't the same as safe and secure. I realize this is a security site, so I may be in the minority in my opinion.

  28. müzso · 930 days ago

    Most browser vendors are at some level affiliated with advertising companies. It would be surprising if any browser implemented a URL security policy as strict as suggested any time soon.

  29. It's easy for web savvy people to scoff and moan, most users have trouble understanding a word is a link to another site (eg the word BANK might when clicked take you to a porn site) if we now have to explain that even hovering to check the word BANK shows a <a href="" target="_blank"> address the address may change users will give up either ignoring security all together and just risking it and relying on ani-virus software or will stop using the web (not everyone is as addicted as me) I think it's unfair to blame stupidity - the web is complicated, users need help and this is confusing, so yes, a link should link to where it says - it should be clear and unambiguous and software developers should ensure this is the case rather than trying to be clever

  30. Anon · 930 days ago

    Not sure there's any point worrying about this. Most people aren't savvy enough to be able to sanity check whether a site "looks dodgy" by eye, and even those who are could be easily blindsided by a trusted website that had been compromised. There's also the point that anyone who can edit the javascript on a page to do dubious things like this can probably do when they want without relying on the user clicking anything anyway.

    Those that care enough can deal with this using noscript and the like. For the rest of the world the quick-and-slick experience is too important to do without.

  31. John Baxter · 930 days ago

    When they get around to it, the New York Times will probably have a lot of fun with this, stretched out over several weeks.

    The internet industry should remember that if the public stops trusting "the web" they will use it much less, and practitioners--honest and otherwise--will go bankrupt.

  32. Sam · 930 days ago

    I use this 'feature' to protect email links with encryption - click the link and it decrypts the relevant email address and displays it in a proforma. The email address never appears in clear in the web page so protecting it from scavengers. So I would miss this if it were blocked - though my security hat tells me it should probably be stopped.

  33. James Nelson · 930 days ago

    Even people who are internet-savvy could be caught by this one, so something should be done about it. Maybe it should be Java that does it in some way.

    My system is on wifi and not wired by LAN to the modem. So any time I have my suspicions, I just switch off the wifi switch before clicking. Then I can see where they want me to go.

    It's a bit like a phishing attempt.

    Part of the trouble is that not many computer users really know what is happening.

    • Lee · 928 days ago

      "Part of the trouble is that not many computer users really know what is happening." Yes, like you just mentioned Java, which is completely different than the topic at hand - JavaScript. Part of knowing what is happening is just taking a few seconds more and actually reading what is being said.

  34. Phoenix301 · 930 days ago

    Agreed with tattooed mummy, I am kind of like dora the explorer when it comes to JavaScript / HTML etc. I know a couple (very few) bits and pieces of the "language" but by no means do I really understand it. I have known for ages that I can hover over something and see a URL in the bottom of the browser window, and once upon a time I knew the very basics of turning a word into a link in HTML. I can tell you right now that my very basic knowledge is an exception to the huge, and I mean HUGE majority of users, and yet I didn't have a clue that this was a tactic!'s easy for anyone that knows their way through JavaScript/webdesign or have a tech background to see something like this no problem, but I can almost guarantee that if you walked up to to someone randomly and asked the question "Should JavaScript be allowed to change a web link after you click on it" they wouldn't even know what JavaScript is or means, let alone the concept of a link changing.

  35. njorl · 930 days ago

    I think it's important that search engines continue to be allowed to use the technique in their results pages. Of course, I wish to see the address of the page that Google (or any alternative search engine) has found, and, no, I don't want to wade my way through Google's tracking cruft, with its "%20"s etc..

    However, I do not object to Google's tracking of which results I choose; I understand that Google, somehow, derives revenue from the information, which means I can search without paying, but my choice (and those of the legions of other searchers) help Google to improve the ordering of the results, and thus, over time, make the searches more effective for all of us.

    Perhaps we can have a white list of sites that are permitted to manipulate links. Aside from search results, in what other context would we want to see an address other than the link's true destination?

    On the other hand, if the link is a (or similar service) one (which, ordinarily, is not manipulated with JavaScript), the browser could help us by showing, in addition, the address to which would bounce us.

  36. woodelf · 930 days ago

    Sorry for me it's all too complicated and basically it comes down to "trust" - do you trust the referring site?
    Yes, I do now hover on links before clicking but often just see a JavaScript:something - so if I'm on a page I don't know I very often don't click-on from there.
    I use WOT as a guide and will frequently immediately cancel a navigation if WOT pops a warning.

  37. I'll keep it simple. NO!!!!!!!!!
    Would you like if I smacked you after I told you I wouldn't?
    Go on though I won't hit you.

  38. Jason · 929 days ago

    What I find ironic is that this site/blog does the same click redirecting that it is "highlighting" in this blog post. Go to the "You Might Like" and hover over a link. You see a nice clean link (if you're in Chrome, at the bottom). When you click, you actually get taken to a "" link which then redirects to the story. Guess you had better be careful with Sophos... never know where they're redirecting you.

  39. Lee · 928 days ago

    Yes, it is a security feature that should be fixed but as many have mentioned, some fixes would "break the Web". But it should be clear by now that generally economics take precedent over security, whether on the Net or in the physical world.

  40. Arerifx · 926 days ago

    I think Is it time for browsers to get stricter about how and what they display, and how much manipulation of status information is allowed using JavaScript?..I agree

  41. roy jones jr · 925 days ago

    lol, break the web? What does that even mean?
    I've spotted the "this link isn't really the link you're clicking before", its just that now they are taking it to a new level. The browsers do need to adjust. If for nothing else to help the consumer side of things. The reason this is happening doesn't matter (marketing, advertisement). Do they think I'm going to "impulse" buy a Nissan GTR?

  42. hkoncke · 924 days ago

    Let's be honest.
    Most users around the world don't have the sligthlest idea of links, not good nor evil ones.
    Here, reading this article, we all are more or less somehow tech-prone, or we wouldn't be reading this.
    Browsers and most other pieces of software should be developed with common plain users, not technicians in mind. So, playing tricky games on links don't seem to be a very good idea, just in case some of these common users learn a little bit about knowing where his/her browser will go after a click.
    Moreover, I really don't want having to worry constantly about what will happen when I click on a link. Yes, I always read the shown url at the bottom line, and yes, I realized Google plays some tricks on this. But I don't like it.

  43. Rahul · 924 days ago

    Can an add-on or plugin be written to fix this issue?

  44. anon · 885 days ago

    Maybe I am a lay person that didn't learn this at 5 y/o. Personally, unfortunately... I see a lot ppl just clicking on links & not worrying about integrity of sites. I guess that needs to be the "first" mannerism that needs to change.

    Personally, I find all of this intriquing. I want to learn more!!!

    My question is what about when you have software like Norton that tells you "this site is ok?"

    Clearly, I'm not on your level so be nice if electing to answer.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog