Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's next Google? Dropping SMTP support?

eschnou.com

Post reply on HN
Print view View original

251–260 of 263 posts

Re: What's next Google? Dropping SMTP support?

#251

Post by loup-vaillant »

pyre wrote: post #246
loup-vaillant wrote: post #237

Earlier quoted context omitted.

A ridiculously cheap and powerful alternative to HTML (or any other static format for that matter), would be a bytecode format intended to be executed in a sandboxed virtual machine. Possibly something like Flash. That should give you all the bells and whistles you could possibly want with a document format. Now, there still are some loose ends about various screen sizes, preferred font family and size, and of course…

Really? Flash is more secure than HTML? Maybe we should just embed Java applets in emails? This still doesn't solve the "click a link that takes them elsewhere" issue that was brought up.

I did say "sandboxed", did I not? Just have your VM refuse to download anything before you click somewhere, and let it compute the relevant URL so it can show it to you the way Firefox does. If this is too harsh, then relax the restriction to only download to, say, the domain name of the current main URL. If this is still too harsh, then have a NoScript like button to relax restrictions manually, on a case by case basis.

It would disable any form of cross scripting by default, which in my opinion is a better state of affairs than HTML alone is right now (now, you can embed an external image in a web page, and bam, Facebook knows what you read).

Re: What's next Google? Dropping SMTP support?

#252

Post by loup-vaillant »

philwelch wrote: post #249
loup-vaillant wrote: post #243

Earlier quoted context omitted.

Microsoft's products cost money (minus piracy), and fought Free Software, which is also Gratis most of the time. Google is already Gratis (the ads don't count as a price in most people's minds).

I was referring more to IE, which was bundled with the OS to circumvent Netscape's business model.

Ah. Maybe it was because IE sucked for a long time, compared to Firefox?

Re: What's next Google? Dropping SMTP support?

#253

Post by philwelch »

loup-vaillant wrote: post #252
philwelch wrote: post #249

Earlier quoted context omitted.

I was referring more to IE, which was bundled with the OS to circumvent Netscape's business model.

Ah. Maybe it was because IE sucked for a long time, compared to Firefox?

Gmail sucks too now (to give an example) but it's much harder to provide a viable alternative if you're an open source project or a startup. There will never be a Firefox of web mail, much less a Firefox of search engines.

Re: What's next Google? Dropping SMTP support?

#254

Post by laumars »

raylu wrote: post #244
laumars wrote: post #229

Earlier quoted context omitted.

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…

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).

Re: What's next Google? Dropping SMTP support?

#255

Post by ernesth »

DanI-S wrote: post #185
ernesth wrote: post #179

Earlier quoted context omitted.

And with SMTP down 80% from its top in 2004 or imap down 58%, the question of the op should seem perfectly legitimate to you.

Clearly not, since SMTP and IMAP are still in far greater use than RSS and XMPP ever were. But do you think that question will never be legitimate? Will we still be using SMTP in 2113? Google is planning to be around for a long time. What percentage of the resources of your organization do you devote to supporting old technologies in limited use?

Of course, IMAP and SMTP might be replaced by better protocols in the future (as POP3 was). However, my point was that the fact that the search trend for a protocol is downhill does not mean it is no longer used and should be scrapped. I argue that XMPP is in wider use than it has ever been. And that RSS has not been replaced by anything yet. Hence stopping their support in favour of a locked proprietary platform is bad and explaining this move by google trends is absurd.

Re: What's next Google? Dropping SMTP support?

#257

Post by wtetzner »

thoughtcriminal wrote: post #222
wtetzner wrote: post #192

Earlier quoted context omitted.

> No company should have such a big impact on your life > Several months ago I moved everything to the Microsoft ecosystem. So now Microsoft has such a big impact on your life? Wouldn't it make more sense to spread things out over a variety of services?

Wouldn't it make more sense to spread things out over a variety of services? For reasons of workflow efficiency, no.

You're right, but that conflicts with "No company should have such a big impact on your life."

Re: What's next Google? Dropping SMTP support?

#258

Post by npsimons »

laumars wrote: post #229
raylu wrote: post #214

Earlier quoted context omitted.

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…

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.

Re: What's next Google? Dropping SMTP support?

#259

Post by npsimons »

laumars wrote: post #254
raylu wrote: post #244

Earlier quoted context omitted.

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…

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.

Re: What's next Google? Dropping SMTP support?

#260

Post by laumars »

npsimons wrote: post #259
laumars wrote: post #254

Earlier quoted context omitted.

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…

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.

Post reply on HN