Who wants dynamic dancing animations and code in their emails? Everyone! says Google Having last year axed its scanning of Gmail messages after years of withering privacy criticism, Google has decided to court controversy again in this area. Now it is extending its much-loved Accelerated Mobile Pages (AMP) technology to email inboxes. In a blog post on Tuesday, Gmail product manager Aakash Sahney announced …
I'll pass and stick with my "text-only" email
Some of us fondly remember the days of 7-bit ASCII emails. And have configured their email clients to do text-only and ignore this new-fangled penchant for all-singing, all-dancing, intrusive HTML.
Some people may find this appealing.
Not I. A hundred, thousand times not I.
Yet ANOTHER reason to *NEVER* *VIEW* *MAIL* *AS* *HTML*.
because, scripting and style sheets are next. you KNOW it's coming! And embedded ADS in your e-mail, courtesy "whatever free e-mail service" you send/receive with.
Don't doubt me. Consider the following:
a) we can just block the web ads and still view the content
b) an operating system with ADS in it?
c) subscription-based OFFICE programs?
d) An annual fee just to use an OS?
I can see the possibility of click-through ads to view your e-mail (particularly with HTML mail viewers). Or, WORSE, click-through ads to SEND mail!
icon because paranoia
Yeah, HTML is just HTML. Add in CSS and media queries and you've got a nice little device sniffer that tells the sender exactly what capabilities your device has. And that's just off the top of my head, the people who are good at this stuff will have hundreds of better, cleverer ideas.
I'm with the tin-foilers on this one!
" I'm pretty sure the OP meant one that doesn't make any kind of outbound HTTP call when viewing the message."
that's one, but there are many things that style sheets can do that pose a potential problem. there's also HTML5 content (yes I really wanted to see that streaming video when I opened an e-mail) and things like that. But style sheets can have script-like behavior, too. They can get really large, and really complicated. And, of course, loading the style sheet across 'teh intarwebs' identifies YOU as the mail recipient, even if all it does is check to see that you have the latest version with a 'HEAD' request.
a style sheet can, for example, passively determine what your screen resolution is. Content that uses a particular style can then (theoretically) use this information to "phone home" that info on you. I forget the exact details on how it works, it has something to do with being able to manage auto-sizing column widths as one possible usage. I've actually worked on customer web pages that do this. Don't ask me HOW it works, it was confusing enough fixing the existing page so it would look right on a phone in portrait mode, or on a desktop or a 'slab' in landscape mode, with their varying aspect ratios and screen sizes [yes it works perfectly now!]. And I didn't have to change the style sheet - I embedded 'style' info into the HTML.
So using this information, indirectly determined from the style sheet setup, EVEN WITH SCRIPT TURNED OFF, it should be possible to 'nuke out' what some of the hardware is that you have on your computer. That doesn't even include font embedding or other potential danger items. There have been vulnerabilities with web fonts in the past, after all.
it's like a potential side-channel attack. You know, like Meltdown and Spectre.
seriously isn't the USER-AGENT bad enough in external HTML requests? Only now, it's e-mail spam doing this (in particular, spammed malware). And THOSE are the people who will leverage it.
icon, because, paranoia (again)
Add in CSS and media queries and you've got a nice little device sniffer that tells the sender exactly what capabilities your device has
All you need is an MUA that renders external images and you have webbugs. You don't even need CSS for that one. (Or an MUA that respects the onerror event, though I'd hope that one which doesn't render external images also doesn't follow onerror.)
Of course, MUAs that respect CSS often provide other webbug channels, such as background-image.
And HTML emails make phishing a lot easier.
Good lord, AMP is such a blight.
""I have plenty of concerns about AMP, both technical and ethical," he wrote in a post on news aggregator Lobste.rs. "But when we joined the AMP trial, we immediately saw higher user engagement on our AMP pages."
In other words, he's making an "ends justify the means" argument. "Sure, AMP is fraught with technical and ethical problems, but it gets us more revenue, so everything's good!"
AMP in email? Whatever. Those emails will remain invisible to me -- I don't allow HTML rendering or any automatic accessing of any outside data (even from the same place as the email was sent from).
"BEFORE any proper patches for Meltdown and Spectre"
That's weird. I was under the distinct impression that the timer resolution making those exploits possible has been not so much reduced but rather obliterated in Palemoon specifically, and that the other browsers also did more or less the same thing already. What exactly are you on about...?
I was under the distinct impression that the timer resolution making those exploits possible has been not so much reduced but rather obliterated in Palemoon specifically, and that the other browsers also did more or less the same thing already.
There are many timing channels for Javascript. Eliminating them all is probably infeasible (without crippling Javascript, and users willing to do that are already blocking it). There's ample research on this, and I've posted a link to the best-known paper before, if you want to search for details.
I don't believe I've seen a Javascript Meltdown exploit. Meltdown is a subset of the Spectre class, but all the Javascript Spectre exploits I've seen have been reading unprivileged data.
"the timer resolution making those exploits possible has been not so much reduced but rather obliterated in Palemoon specifically, and that the other browsers also did more or less the same thing already"
or so they say...
but the thing is, it doesn't eliminate the potential threat. It helps to mitigate what we currently know about the proof of concept algorithm. It is still possible, if you know enough about an OS or an application, to obtain information about it using a side-channel attack, if you repeat the operation sufficiently enough. I have personally used low resolution timers to check performance. if you test 10,000 operations with a timer that has 10msec or even 100msec accuracy, you can still determine how much time was spent doing those operations with reasonable accuracy. you won't be able to time a single operation, but you can time 10,000 of them. And THAT means an exploit will simply have to run LONGER to get a meaningful result, and target what it looks at a bit more carefully.
Google claims AMP is fast for mobile platforms.
Know what's even faster than that? Google simply not permitting advertisers to deliver dynamic content- that no user, in the history of the world, has ever wanted or needed to see- in ads. Guess we'll see that happening, oh, the next never or so.
>Know what's even faster than that? Google simply not permitting advertisers to deliver dynamic content- that no user, in the history of the world, has ever wanted or needed to see- in ads.
The user is not the customer, though, the advertisers are. Google will implement features that advertisers want until the consumers walk away.
Or written by teenagers who who have never seen a PC get owned by email
Or, judging by my nephew (mid 20's), never using the email client on his PC or phone, preferring to instead use webmail.
Which is why I get queries on the (rare) occasion that my webmail server drops out.
If you have to use Google search, use encrypted.google.com instead - I see no AMP (thanks timecop1818)
> Had I been given that tip earlier, my life might be entirely different. I find AMP to be such a usability nightmare that I switched to Bing. No, really.
Yeah, thankfully this news story prompted me to decide I should pull my finger out and actually do something about it (especially as I follow a lot of news links from Twitter). So I've updated my adblock list (to block the AMP JS - particularly amp-ads) and created a Greasemonkey/Tampermonkey script to detect AMP pages and send me to the canonical URL instead: Remove AMP from my browsing
I have Gmail set to deliver mail to my email client via IMAP. My email client is not a web browser. I have turned HTML and such off. I will never see their dancing ads. Should Google try to get around this, by, oh, giving static sending email using IMAP to my email client, I will kill my Gmail accounts.
Jsu to confirm what you're saying because I think you know more about this than I do.
This AMP thing only happens (at the moment) if viewed through a web browser which allows javascript to run. If an email client is set to display pages in html, with external content disabled (default for Outlook, Safari etc) would you get the AMP content or not?
That would depend on the email client. Some don't do JavaScript at all, some can do JavaScript but might have problems with AMP. Some can do just about everything that a web browser can do. I avoid the question by just turning off everything which isn't plain text and basic attachments. No viewing pix or PDFs in the mail, I _must_ download the attachment... if I feel like it. It's amazing how often I don't feel like it. Doing things this way means that macros and such cannot run until I download the attachment and open it with the appropriate application,which I do only in certain very specific circumstances. It means that .EXEs are instantly visible. It makes things difficult for phishers and other fraudsters. It also exposes the kind of person who insists on using HTML and JS tricks to tart up email in an. attempt to hide the fact that they're useless gits. All that I see is the plain text, no pix, no colors, no singing, no dancing, just the text. There would be a reason why I hate webmail and decline to use it.
Please, Google, once you have got this AMP malarky running smoothly in Gmail, can you roll out ActiveX and Flash in email too? In fact, why not make native code run as well, straight over email, it would be super neat. Even greater would be if we didn't have to click on anything before it ran either, that's such a drag.
"In fact, why not make native code run as well, straight over email, it would be super neat."
Outlook used to have that feature, you could embed a sound file in your mail which would then be saved to disk and played... even if it had the extension .exe. (Explanation: The Windows API-Call to play a sound internally maps to the API-call to execute a program. So you could convince Outlook that it's a sound via the MIME-Type, but effectively you could send a native program.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
