How Gmail came to stop supporting CSS animations

Did you know that not so long ago, Gmail supported CSS animations? Well, sort of. Up until June 2016, the desktop webmail of Gmail supported CSS @keyframes declarations. So you could declare the following animation in a <style> tag in the <head> of your email, and Gmail would keep it intact.

@keyframes foo {
 from { background:red; }
 to { background:black; }
}

The problem is that, in itself, such a declaration is useless. In order to call an animation in CSS, you need the actual animation CSS property.

<div style="animation:foo linear 1s;"></div>

But Gmail didn’t support the animation property. So that was all pretty pointless. I shared my frustration a few times on Twitter, without thinking too much about it.

Later that year, in may of 2016, I was fiddling around in Gmail trying to make sense of its CSS support. And I realized that instead of being pointless, the @keyframes support could be a real security issue.

Because Gmail was not just supporting CSS @keyframes declarations. It was keeping the name of the declaration intact. This meant that, theoretically, you could override any CSS animation that the webmail used. And while Gmail is pretty sober in terms of visible animations, it still uses quite a few.

I wrote a small script to get all the elements that have an animation style, and got a dozen of result. Those animations were referencing about as much @keyframes declarations. Most of these animations were only called during very specific actions in the interface of Gmail, outside of an email view. But one of them, named gb__a, was quite interesting.

@keyframes gb__a {
 0%  { opacity:0 }
 50% { opacity:1 }
}

This animation uses the opacity property to create a fading effect. It is used in the upper right hand corner of Gmail when you open the little pop ups with your app, your notifications or your account information.

A fade in animation when you click on “Your notification” in the top right hand of Gmail. In practice, this animation only lasts 0.2 second, so you might have never even noticed it.

This was perfect! This meant that for the split moment this animation was playing, I could apply any styles that Gmail allowed. I could change the width and height of that element, change its background color, and apply a background image to display some content.

At that moment, I knew that what I found was pretty serious. Having read other stories of email security like this one by Justin Khoo, I was definitely willing to report this. Turns out Google has a handy and memorable URL to report vulnerabilities: goo.gl/vulnz. After reading tips from Google to write a good bug report (and what doesn’t qualify as a bug), I made a prototype of an email to show how the vulnerability could be exploited. I imitated Google’s email design to make a somewhat convincing notification email inviting a recipient to click on the top right hand icons.

The email I sent to Google along my Vulnerability Report.

And if you clicked on any of the top right icons, here’s what you would see.

I reported this on May 20, 2016, and immediately received an automated response. Three days later, I got a personal response from a Google employee that they were looking into it. Two days after, I received another personal response asking me to send the test email to a specific address.

And then, on June 7, I received the following email:

Hello,
Thank you for reporting this bug. As part of Google’s Vulnerability Reward Program, the panel has decided to issue a reward of $1337.
[…]
Regards,
Google Security Bot

That was such a pleasant surprise. This is still to this day probably one of my proudest email geek achievement.

A few days later, Gmail started filtering all @keyframes declarations. And that’s how Gmail came to stop supporting CSS animations.

I wanted to tell this story two years after because I think it’s still a good example how important security is in the email world.

  • Google is taking Gmail security very seriously. This is visible at multiple levels, from their memorable report URL to their financial reward. My experience with Google has been in huge contrast to one of my previous experience with another email client where I was almost laughed at for much more serious issues. If you’re an email client maker, you should want the good guys (and girls) to report an issue. So you should make everything in your power to make reporting bugs easy and attractive so that people want to take some of their time to report you an issue.
  • In a webmail, a lot of CSS features can become vulnerabilities. There’s a good chance that CSS @keyframes didn’t even exist at the time Gmail’s parser was written. This doesn’t mean that @keyframes and animation can’t be supported safely in a webmail. But a webmail should always be cautious about what they support. Thus, a restrictive black list (that only allows a subset of styles) is still the best way to go. We might never see the same level of support of CSS in emails than on the Web, and it’s probably a good thing.