Re: Ideas for an Email Specification

Hi Charles,

Great overview. I insist that the whitelist seems much more safer to me. In
your blacklist version, users are in danger from steps 1 to 5 (which could
very likely span across years). My understanding of email security right
now is that you should not mess with email security.

I just ran a test (
https://gist.github.com/hteumeuleu/988a07d0a169917b1cccffb7096e407e) to see
what webmails were up to. And here are the results :

*Whitelist* (the webmail filters `*foo:bar*` and `*will-change:transform*`)

   - Gmail
   - Yahoo
   - Yandex
   - Outlook.com (new version based on Office 365)
   - Outlook.com (old version)

*Blacklist* (the webmail supports `*foo:bar*` and `*will-change:transform*`)

   - AOL Mail
   - Orange
   - SFR
   - LaPoste.net

One interesting thing to note is that among the whitelist webmails, all the
above except Yahoo support `*display:foo*`, meaning that they whitelist CSS
based on property names and not property + value (which is a bad idea in my
opinion).

To me, a whitelist seems closer to what's happening with browsers. A
browser has to actively develop a new CSS feature. An email client should
have to actively whitelist a new CSS feature. Developers are used to these
discrepancies on the Web. They'll get used to it on webmails as well.

Cheers,

-- Rémi


2016-07-11 15:14 GMT+02:00 Hall, Charles (DET-MRM) <
Charles.Hall@mrm-mccann.com>:

> This is what I think that looks like. Please feel free to correct any
> glaring inaccuracies or omissions.
>
> *Whitelist*
>
>    1. By default, no HTML element or CSS property is supported.
>    2. Email community – through a vetted documented process – requests a
>    feature support.
>    3. Document must contain a use case.
>    4. EACH email client vendor reviews request document and use case to
>    make determination for approval.
>    5. SOME email client vendors add feature to product development cycle.
>    6. Eventually, support appears in a single email client.
>    7. Much later (likely years), support appears in remaining email
>    clients that approved.
>
> The result is that there is still widely varied support at widely varied
> times based on use cases that had to be foreseen years earlier. This seems
> like the current state of email client vendors.
>
> *Blacklist*
>
>    1. By default, all HTML elements and CSS properties are supported.
>    2. As new HTML elements and CSS properties become available, EACH
>    email client vendor reviews specifications for any potential risk an misuse.
>    3. IF a legitimate risk is discovered, an email client vendor
>    publishes a documented specification of risk and reason to NOT support.
>    4. EACH email client vendor adopts this as standard.
>    5. Feature is not supported anywhere.
>    6. IF no risk is discovered, EACH email client vendor adds feature to
>    product development cycle.
>    7. Eventually, support appears in a single email client.
>    8. Much later (likely years), support appears in EACH email client.
>
> The result is that there is universal support for all HTML elements and
> CSS properties that pose no legitimate documented risk. The only thing that
> varies is the timeline of feature availability. This is more consistent
> with the current state of browser vendors – many of which are the same
> organizations as the email counterparts.
>
> If this is accurate, I prefer the blacklist model. It seems to put more
> burden on the email client vendor to prove why a feature should not be
> supported.
>
> Thoughts?
>
>
> *Charles Hall*
> UX Architect, Technology
>
> t / 248.203.8723  m / 248.225.8179
> e / charles.hall@mrm-mccann.com
> skype / charles.h.all
> 280 N Old Woodward Suite 300, Birmingham MI 48009
> w / www.mrm-mccann.com
>
> Creativity. Technology. Performance.
>
> On 7/10/16, 8:20 PM, "Chaals McCathie Nevile" <chaals@yandex-team.ru>
> wrote:
>
> On Fri, 08 Jul 2016 19:08:49 +0200, Rémi (HTeuMeuLeu) <remi@hteumeuleu.fr
> >
> wrote:
>
> Thank you all for your warm answers.
>
> I have a preference to lead discussions (I'm not sure Slack is suited for
> this, and I don't like Slack proprietary nature). There is already a
> Github group linked on this CG (https://github.com/W3CGHtmail), but I'm
> not sure how to joing…
>
>
> If you tell me your github user id I can sign you up.
>
> There's also the Wiki (
> https://www.w3.org/community/htmail/wiki/Main_Page).
> What would be the best way to discuss in detail everything ?
>
> Regarding CSS support, I believe a blacklist is a bad idea given the
> living and always evolving nature of CSS. Let's say that tomorrow Chrome
> introduces a `display:-blink-fullscreen` property that can display any
> element full screen. This would be bad for webmails security and should
> be blacklisted. But there's a good chance webmails would take a long time
> to add this to their blacklist. So a white list approach seems better to
> me (from a security standpoint).
>
>
> I think there is value to three things. The first is identifying what
> actually does work in what clients. There is some subset of HTML and CSS
> that pretty much works everywhere, some set of things that work in some
> places, and some that work in none.
>
> I think it's worth looking carefully at the things that work sometimes,
> and checking whether there is a good reason *not* to implement them, such
> as security.
>
> Equally, it would be worth looking at the things that aren't implemented,
> find out whether there is a good reason not to do so, and if there is a
> good use case for having them. In some sense there is always a use case,
> but for example "you can't write arabic without it" or "you can't make
> something accessible without this" seems a stringer reason to me than "I
> would like to use flexbox to make email appear in star shapes…".
>
> My idea for discussing CSS support was to take a list like this one (
> https://drafts.csswg.org/indexes/) and discuss every single properties,
> values, functions, at-rules and selectors and see if they make sense for
> emails (from a security standpoint once again). I don't want to cater
> for a minimal subset of CSS like the old Email Standards Project did (
> https://www.email-standards.org/). I want as much CSS support as
> possible. (And I want to use flexbox and CSS grids in emails, god damn
> it.)
>
>
> I hope you don't get flexbox in emails ;)
>
> Seriously, I agree that just finding a minimal set isn't much of a goal,
> but as Rouzbeh points out it may well be a useful task to do anyway, as a
> waypoint.
>
> cheers
>
> Chaals
>
> 2016-07-08 18:06 GMT+02:00 Rouzbeh Sarrafieh
> <rouzbeh.sarrafieh@gmail.com>:
>
> Agreed on the github/slack(gitter possibly to keep it open source or
> even
> the current IRC irc://irc.w3.org:6665/#htmail) . I think the blacklist
> idea is a good one as well as I've always referred to the campaign
> monitor
> list https://www.campaignmonitor.com/css/ to what I can't use vs can.
> This was already an idea back when the group was slightly more active
>
> https://www.w3.org/community/htmail/2015/04/30/taking-the-reductive-approach/
>
> Perhaps start anew setting a baseline spec to at least establish support
> for small to large screen layout/typography consistency across clients,
> possibly start small to build a logical minimum support of these things
> before moving on to trying to bring in the vast array of CSS props in? I
> feel this would be a less harrowing task for email providers and
> clients to
> integrate. Thoughts?
>
> Best,
>
> Rouzbeh Sarrafieh
>
> Rouzbeh Sarrafieh  //  Portfolio <http://www.rouzbeh.net>  //  LinkedIn
> <http://www.linkedin.com/in/rouzbehsarrafieh>   //  @rouzbeh84
> <https://twitter.com/rouzbeh84>
>
> On Fri, Jul 8, 2016 at 8:39 AM, Spellacy, Michael <
> Michael.Spellacy@tmp.com> wrote:
>
> + 1 Github and Slack. We might even attract more attention/help on
> GitHub. :-)
>
> Yes, agreed. Swell start.
>
> Regards,
> Spell
>
> On Jul 8, 2016, at 11:22 AM, Hall, Charles (DET-MRM) <
> Charles.Hall@mrm-mccann.com> wrote:
>
> Hi Rémi,
>
> This is a brilliant start. Perhaps we should move this conversation
> from
> the mailing list to another channel to start sharing resources and
> tracking
> progress. GitHub for code examples? Slack for conversations?
>
> I actually prefer to model the CSS supports as a blacklist instead of a
> whitelist. If we start with the premise that all CSS features,
> properties,
> selectors, and values should be supported, then it would be up to the
> vendors to reductively blacklist these and define the reasoning. As
> this
> list would ideally be shorter, it may be easier to version and iterate
> as
> support changed.
>
> Cheers,
>
> *Charles Hall*
> UX Architect, Technology
>
> t / 248.203.8723  m / 248.225.8179
> e / charles.hall@mrm-mccann.com
> skype / charles.h.all
> 280 N Old Woodward Suite 300, Birmingham MI 48009
> w / www.mrm-mccann.com
>
> <5D510C5C-1CCD-479C-A466-98D1FC580B9B[13].png>
> Creativity. Technology. Performance.
>
> From: "Rémi (HTeuMeuLeu)" <remi@hteumeuleu.fr>
> Date: Friday, July 8, 2016 at 8:16 AM
> To: "public-htmail@w3.org" <public-htmail@w3.org>
> Subject: Ideas for an Email Specification
> Resent-From: <public-htmail@w3.org>
> Resent-Date: Friday, July 8, 2016 at 8:17 AM
>
> Hello everyone,
>
> I believe that creating an Email Specification with guidelines for
> email
> client vendors could vastly help getting things standardized. Given the
> recent rebirth of this mailing list, I'd like to share a few random
> ideas I
> had in the past year of things that should be standardized across email
> clients.
>
> # HTML
> * How to embed an HTML email within a webmail or application. Some
> webmails like Gmail, Yahoo or Outlook.com <http://outlook.com> embed
> the
> HTML directly within the webmail. Others like AOL use an iframe.
> * Supported attributes. Given the immensity of JavaScript attributes
> that
> can be written directly inline (like "onload", "onmouseover", etc.), I
> believe the safest way to embed an HTML email within a webmail is to
> have a
> white list of supported attributes. I believe attributes like "id" and
> "class" should be supported. But for some reason, a webmail like Gmail
> removes this (even though it keeps styles targeting classes or ids).
> * Attributes prefixing. Supported attributes like class or ids should
> be
> prefixed in order to prevent an email to reuse styles from a webmail.
> This
> is done by webmails like Yahoo.
> * Supported elements. Listing elements that should or shouldn't be
> supported by webmails and email clients. For example, should a webmail
> support video or audio tags ? What are the security implications ?
> * Image blocking. Some webmails (like Outlook.com
> <http://outlook.com>) block
> images by replacing the image path in the src attribute with a dummy
> pixel
> image. Others (like Gmail, Yahoo or AOL) remove the src attribute. Both
> solutions have different results across browsers depending on other
> attributes present on the images.
>
> # CSS
> * Supported properties. Things like "position:fixed" should be removed
> for security reasons (a malicious email could easily position an
> element
> above the webmail's UI). What properties and values should be allow ?
> * Filtering guidelines. If a style has to be filtered, how should this
> happen ? Some webmails remove only the property concerned. Others the
> complete CSS rule. And others the complete style tag.
> * Styles prefixing. This follows the HTML guideline for attributes
> prefixing. But there's allow cases were prefixing needs to happen in
> CSS.
> For example, a webmail should prefix animations @keyframes declarations
> names (in order to avoid a malicious email to use same names as in the
> webmail's UI).
>
> Do you see more points that needs to be addressed ? My biggest question
> is how can we talk about this in a productive way. For example,
> listing all
> the CSS properties that should be supported in a webmail can be a huge
> task. Should we like open a Github issues somewhere and open a
> discussion
> for every single CSS property ?
>
> Cheers,
>
> -- Rémi
>
> This message contains information which may be confidential and
> privileged. Unless you are the intended recipient (or authorized to
> receive
> this message for the intended recipient), you may not use, copy,
> disseminate or disclose to anyone the message or any information
> contained
> in the message.  If you have received the message in error, please
> advise
> the sender by reply e-mail, and delete the message.  Thank you very
> much.
>
>
>
>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>   chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>
> This message contains information which may be confidential and
> privileged. Unless you are the intended recipient (or authorized to receive
> this message for the intended recipient), you may not use, copy,
> disseminate or disclose to anyone the message or any information contained
> in the message.  If you have received the message in error, please advise
> the sender by reply e-mail, and delete the message.  Thank you very much.
>