Comment by laumars | Hacker News Reader

Comment by laumars | Hacker News Reader

Parent Full thread

While we're at it, let's all abandon HTML5 and have every browser doing their own thing, because people occasional fall for fake anti-virus ads. </sarcasm>

We can't stop social engineering like that - it's completely unavoidable. Which is why banks and payment providers regularly tell people not to follow links asking for bank details (etc). Yeah it sucks that The Onion got hacked that way, but your argument is doesn't fix that. Your argument is nothing more than cutting of your nose to spite your face (ie advocating an inconsistent platform for legitimate e-mails despite anchor tags working on every client already).

At least if e-mail was completely redesigned, then we could have banks provide a unique cert that hangs in the e-mail header and can support the authenticity claim of the sender (I'm sure there's ways around that idea I've just presented - but that was just off the top of my head. Any such design would obviously need to be thoroughly thought out)

I think he's saying we should instead have text-only e-mail, because that's both standard and has a tiny attack surface.

That doesn't fix anything either. Many clients make URLs clickable (even with text-only emails) and even if those clients didn't do that, someone will just copy and paste a URL into the address bar without looking. Given that the average user isn't an expert on domain names, it's not actually that hard to trick them into thinking that face.book.com isn't the same as facebook.com (and even those that are savvy enough to know the difference might misread the link and get fooled occasionally).

So like I said before, it's impossible to prevent social engineering.

It's impossible to prevent all cases of social engineering with a purely technical solution, this is true. But that doesn't mean that we should disregard how much easier phishing attacks are with the advent of HTML mail. The goal here is not so much to stop social engineering dead in its tracks as to prevent some of the low-effort attacks that do happen.

But again, I refer you to my HTML5 example. Should we dumb down what websites are capable of rendering to prevent social engineering via the web?

What you're proposing is making things harder to work in the hope that human intelligence will prevail. But the problem is that these cases are where human intelligence has failed, so making things harder is just counter productive. And this is why you can't prevent social engineering from happening and why crippling technology and creating a worse user experience just to try catch a few fringe cases is just a backwards approach to handling the issue.

Instead what we need is methods in place to verify the authenticity of senders and better education to users so that don't make silly mistakes like installing random "virus scanners" from web ads or clicking strange URLs in e-mails (and the URLs themselves could be standardised. eg no sub-domains become clickable, to prevent people falling for face.book.com).

But again, I refer you to my HTML5 example. Should we dumb down what websites are capable of rendering to prevent social engineering via the web?

Strawman; we're talking about email, where the combination of header forging and HTML mis-labeling are what's really dangerous, not web pages.

No, we're talking about social engineering and the principle is the same regardless of whether it's e-mail or websites. You take a page -be that of an e-mail or website- make it look legitimate, and get people to follow dodgy links or download dodgy programs. You see the same thing with Facebook malware as well (which spreads by social engineering). So maybe we should close Facebook apps down.....actually, I'd be in favour of that last point hehehe.

Claiming this is a straw man argument only demonstrates how unwilling you are to view this from another's perspective. At least I've listened to your arguments and come up with potential workarounds.

The very fact that in HTML, a URL can look like a totally legitimate URL (the part between the > and the &lt), and yet the "a href=" could be anything, makes HTML a bad idea for email, where headers can be easily forged. Sure people can (and do) copy and paste, but having it in HTML just makes it that much harder to check a URL. Don't even get me started about the "onmouseover" events that can further obscure the true href.

I'd already addressed the hypertext argument in this discussion somewhere. And that point is one of the reasons why I want HTML standardised in e-mails, so we can remove the potentially harmful things like that from the e-mail spec and make it simpler for developers to create formated content (that's also safe for the end users) which will be rendered correctly across the various clients.

So yes, I do agree with you that anchor tags are misused in phishing mail, but let's make that a reason to fix the specification rather than just ignoring the issues completely (or worse yet, officially removing HTML and then letting 3rd party developers invent their own broken specs and us ending back exactly where were are now).

As for your comment about mouse over events, you can't have Javascript in HTML e-mails so that point is completely irrelevant.

Reply on news.ycombinator.com