Product decision regarding HTML/CSS email and digital signatures

[Kai Engert]

Summary:

We have a conflict of objectives related to HTML/CSS email rendering
(make emails look pretty) and digital signatures (ensure the shown
message matches what the author sent).

We're currently unable to provide a solution that perfectly handles both
aspects.

We need to make a decision which aspect is more important for the
default behavior - because in internal discussions we haven't yet been
able to find a consensus.


Details:

CSS offers conditional rules, this can be used to show different
contents based on properties of the user's computer, for example screen
size/resolution. This is often used to use a different rendering on
desktop computers and mobile devices.

In 2019 security researchers had reported an attack based on these
mechanisms.
https://bugzilla.mozilla.org/show_bug.cgi?id=1530106


When replying to an HTML/CSS email in HTML mode, if quoting the original
message and including the original CSS rules, Alice can be tricked to
digitally sign contents that Alice cannot see.

An attacker Eve, who knows which devices are used by Alice and Bob, can
carefully prepare messages to trick them, simply by requesting a
response to an email that Eve sends to Alice.

After obtaining a response from Alice, Eve forwards the message to Bob.
Then Bob sees contents that Alice didn't see, and falsely concludes that
Alice deliberately signed it.

A complete solution to this problem is difficult.

In an ideal world that only cared about security but didn't care about
visual appearance, we could simply strip away all visual styling, and
display and edit all messages as plain text. However, users (and members
of the Thunderbird team) expect Thunderbird to support pleasant display
rendering of styled email content.

As a middle ground to remedy the attack scenario, we have implemented
code that strips all the conditional CSS rules - and keep all other
HTML/CSS styling.

This fix to the problem has been shipped with Thunderbird 78 and is
currently active by default.

Note that we have implemented the solution independent of whether
digital signatures are used or not, based on the argument that it would
be confusing that digitally signed messages behave differently than
messages that haven't been signed.

Also note, even when showing received messages, we're currently
disabling the conditional rules, too. This creates consistency between
reading and composing a reply. And we don't know if the message that we
received was specially prepared by an attacker, so it seems reasonable
to remove the attacker's ability to trick what we see.


Since the release, we received bug reports that complain about
unexpected message display, see this bug and its duplicated:
https://bugzilla.mozilla.org/show_bug.cgi?id=1659362

The reports caused Magnus to suggest that we display the security
protections, see the patch he attached.

I feel uncomfortable accepting that patch, my preference is to keep the
protection attempt and accept the degraded layout.


Recently the situation got worse, because of the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1675507

The bug that causes the truncated message contents is also reported here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1680084

With this, the suggestion to turn off the security protection has been
raised again.


We have the following options:


(a) secure but degraded layout by default

If we continue to strip conditional CSS, the layout of some emails will
continue to be different than expected (for a desktop).

Because of bugs in the sanitization code, we might continue to see bugs
such as 1675507, and the best we can do is try to address them each time
we identify a new bug.


(b) disable protection by default, higher priority for correct display

With this option, we'd accept Magnus' patch to disable stripping of
conditional CSS by default.

Users who want to be protected against the content confusion attacks
described by the researchers, would need to be aware of this attack, and
manually change the preference to enable the protection (strip
conditional CSS):



We should make a decision, a or b, for the stable Thunderbird 78.x branch.



For future Thunderbird versions (version 2021), we could consider to
develop feature improvements, that more actively involve the user in
this decision.

Ideas:

- notify the user whenever a message contains conditional CSS,
similar to the remote content notification

- offer the user the choice to strip or keep

- the notification and choice should be presented both when reading
and replying/fowarding a message

- allow the user to configure the choice in preference


I'd welcome your feedback on this topic.

Thanks
Kai
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[Kai Engert]

On 03.12.20 14:37, Kai Engert wrote:
> The reports caused Magnus to suggest that we display the security
> protections, see the patch he attached.

typo:

"disable" the security protections

[Rob Lemley]

IMHO, the precedent would be the "Allow remote content in messages" preference, which defaults to "off" (do not allow remote content). That's already changing how messages are displayed, prioritizing security over pretty.

--

Rob Lemley
Thunderbird Release Engineer
r...@thunderbird.net - :rjl
-*- #thereisonlyxul -*-

[Dirk Steinmetz (rsjtdrjgfuzkfg)]

I'm stylish, reply to me!

[Kai Engert]

On 03.12.20 22:02, Dirk Steinmetz (rsjtdrjgfuzkfg) wrote:
>
> I think we should either alter CSS to be scoped to the div the quote
> lives in (probably hard, but there seem to be some JavaScript libraries
> that claim to do that), quote in a separate HTML document (iframe and/or
> attachment) or strip all styles when quoting. The latter would also make
> quoting excerpts more stable.

Note that scoping CSS to the inline reply part wouldn't fix the security
issue that was described.

Kai

[Axel Grude]

Dear Kai Engert,

when you say "conditional rules" are you referring to @media stuff? I think that should degrade gracefully if some plain "ground rules" are added, too.

Just curious as one of my main Add-ons (SmartTemplates) deals with external HTML templates and style sheets a lot.

regards,
  Axel

Axel Grude
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips

Subject:Product decision regarding HTML/CSS email and digital signatures
From:Kai Engert <ka...@kuix.de>
To:Tb-Pl...@mozilla.org <tb-pl...@mozilla.org>
Sent: Thursday, 3/12/2020 13:37

[Axel Grude]

Dear Dirk Steinmetz (Rsjtdrjgfuzkfg),

LOL - I see what you did there. I have one user who uses dark themes and gets funny behavior too. One of my pet peeves is people adding unscoped / anonymous rules, such as

body {
  background-color: "something fancy"
}

p { margin: 0; }

that kind of really grinds my gears because no matter how deep in a thread they fill spoil the experience for everybody else. I usually lay down some tips such as.

• style your own sh!t. put it in a div and scope your rules.
• never style background color without also styling text color (and vice versa) on the same level
  
• leave my paragraph spacings alone!!! Paragraphs are semantic and have a reason for being spaced. Computers are not typewriters.
  
• be nice. try not to use !important.
  

but it is kind of hard to complain to average users who do not understand specificity and scoping. Dark themes threw a complete new spanner in the mix.

Since I support an (commercial) Add-on that allows adding style sheets via templates I often have a lot of troubleshooting to do.

What's your guys opinions on styling body? One thing my Add-on currently does (and the Stationery Add-on didn't) is to completely nuke the <body> element of any template, but as a new feature I want to extract the attributes and re-inject them as that is what most users expect.

regards,
  Axel

Axel Grude
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips

Subject:Re: Product decision regarding HTML/CSS email and digital signatures
From:Dirk Steinmetz (Rsjtdrjgfuzkfg) <thunderb...@rsjtdrjgfuzkfg.com>
To:Tb-Pl...@mozilla.org <tb-pl...@mozilla.org>
Sent: Thursday, 3/12/2020 21:02

Hi Kai & everybody else,

I think this is likely a symptom of the bigger problem of CSS-preservation in replies.

I'm personally in the "text-only" camp, so take my feedback with a grain of salt. But coming from purely a end user expectation perspective, I see many problems when preserving CSS without scoping it to the reply part – independently of security concerns.

For example, try replying to the attached email with default Thunderbird settings: you end up with black text on black ground and Thunderbird's background color picker in a broken state. That is not a security issue, but definitively not a nice user experience.

I think we should either alter CSS to be scoped to the div the quote lives in (probably hard, but there seem to be some JavaScript libraries that claim to do that), quote in a separate HTML document (iframe and/or attachment) or strip all styles when quoting. The latter would also make quoting excerpts more stable.

No idea about standard compliance and support from web mailers and other email clients, though – I assume stripping would lead to the most consistent results across clients, while at least some clients will probably choke on frames – but I have not tested anything.

So I think it would be a good idea to fix the underlying issue first (how CSS is handled in replies) – that would imho improve both security and usability. :)

That being said, it might be reasonable to also sanitize CSS to fix situations in which users receive a 'forged' mail and/or add a warning/prompt when signing mails with media queries. I personally prefer erring on the side of security for all default values and agree with Rob that we have precedent here.

Kind regards,
Dirk / rsjtdrjgfuzkfg


Am 03.12.20 um 21:33 schrieb Rob Lemley:

[Axel Grude]

that's crazy. Did the attached mail actually leak CSS into the main Email??

wow, I never thought of that. I guess that's one downside of showing attachments inline. Should they be style-stripped?

Axel

Axel Grude
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips

Subject:Re: Product decision regarding HTML/CSS email and digital signatures
From:Dirk Steinmetz (Rsjtdrjgfuzkfg) <thunderb...@rsjtdrjgfuzkfg.com>
To:Tb-Pl...@mozilla.org <tb-pl...@mozilla.org>
Sent: Thursday, 3/12/2020 21:02

Hi Kai & everybody else,

I think this is likely a symptom of the bigger problem of CSS-preservation in replies.

I'm personally in the "text-only" camp, so take my feedback with a grain of salt. But coming from purely a end user expectation perspective, I see many problems when preserving CSS without scoping it to the reply part – independently of security concerns.

For example, try replying to the attached email with default Thunderbird settings: you end up with black text on black ground and Thunderbird's background color picker in a broken state. That is not a security issue, but definitively not a nice user experience.

I think we should either alter CSS to be scoped to the div the quote lives in (probably hard, but there seem to be some JavaScript libraries that claim to do that), quote in a separate HTML document (iframe and/or attachment) or strip all styles when quoting. The latter would also make quoting excerpts more stable.

No idea about standard compliance and support from web mailers and other email clients, though – I assume stripping would lead to the most consistent results across clients, while at least some clients will probably choke on frames – but I have not tested anything.

So I think it would be a good idea to fix the underlying issue first (how CSS is handled in replies) – that would imho improve both security and usability. :)

That being said, it might be reasonable to also sanitize CSS to fix situations in which users receive a 'forged' mail and/or add a warning/prompt when signing mails with media queries. I personally prefer erring on the side of security for all default values and agree with Rob that we have precedent here.

Kind regards,
Dirk / rsjtdrjgfuzkfg


Am 03.12.20 um 21:33 schrieb Rob Lemley:

IMHO, the precedent would be the "Allow remote content in messages" preference, which defaults to "off" (do not allow remote content). That's already changing how messages are displayed, prioritizing security over pretty.

On 12/3/20 8:42 AM, Kai Engert wrote:

On 03.12.20 14:37, Kai Engert wrote:

The reports caused Magnus to suggest that we display the security
protections, see the patch he attached.

typo:

"disable" the security protections
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[Kai Engert]

On 03.12.20 22:16, Axel Grude wrote:
> when you say "conditional rules" are you referring to @media stuff?

Yes. We're currently filtering:
- @media
- @document
- @supports
- @import

> I
> think that should degrade gracefully if some plain "ground rules" are
> added, too.

Does that mean, in your opinion it should be fine to strip those, if the
document author was careful?

[Axel Grude]

Does that mean, in your opinion it should be fine to strip those, if the document author was careful?

 Yes. you can't have both (encryption and dangerous rules). having said that, standard CSS rules should be supported as far as possible.

You can still craft stuff using visibility / negative margins and possibly animation, which I do not think can be reliably detected via an algortihm though.

What's your thought on iFrames? Are they currently allowed?

Axel

Axel Grude
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips

Subject:Re: Product decision regarding HTML/CSS email and digital signatures
From:Kai Engert <ka...@kuix.de>
To:Tb-Pl...@mozilla.org <tb-pl...@mozilla.org>; Axel Grude <axel....@gmail.com>
Sent: Thursday, 3/12/2020 21:51

[Dirk Steinmetz (rsjtdrjgfuzkfg)]

Hi *,

first off: sorry for the unreadably black mail on the list for those of
you with HTML and inline attachments enabled. My attachment was more
contagious than intended: I disabled all HTML stuff in my productive
Thunderbird profile, and attached a test mail not thinking it would leak
into the main thing...

That shows that the status quo is not rendering as users intend, though :P

@Kai

> Note that scoping CSS to the inline reply part wouldn't fix the
> security issue that was described.

I thought the problem was that the attacker can alter the message sent
by the victim, so in the example from the bug the signed email would read

> I declare war

With CSS scoping, the message would instead read something like

> Thanks, I'm fine!
>
> Attacker wrote:
>> I declare war

So there is still some room for an attack, like hoping that the victim
replies only with a vague reference to the quote ("I approve this.").
The attacker can still control their quote to display differently for
different recipients. So warnings or sanitization are reasonable additions.

But I don't see how the attacker can take over the whole mail with
scoping to the inline parts?

Of course, scoping does not retroactively fix the issue for recipients
of emails that were signed in the past, or with other clients having
similar issues, if you mean that?

> Does that mean, in your opinion it should be fine to strip those, if
> the document author was careful?

I'm not the one asked, but imho proper CSS will degrade gracefully if
you remove @media or @supports queries, but you might loose features
like a proper print layout.

@document is deprecated anyway, so it should not hurt to remove.

I'm unsure about unconditional @import, though – if we forbid it we
might force everyone else to not use it, so it's not a problem. But if
the world decides that Thunderbird is not important enough to suppress
innovation, our users will have to pay the price.

And all that being said, I'm not sure how common proper CSS is these
days. Being 'proper' seems to be on the decline – for example, proper
HTML should fall back without JavaScript, but many 'modern' websites do
not even display a error message.

@Axel:

> What's your guys opinions on styling body?

I'd argue that style in emails is already so far out of our control that
we cannot make any rules. For external things (!= local user), we should
contain the issue to ensure that Thunderbird's editing features always
work as intended. I personally would be fine with removing all styles in
replies, but I prefer text-only mails anyway, so scoping might be a
better solution for 'normal' people.

For internal things, like templates, I would not make fixed rules. That
being said, recommending clean CSS that will properly interact with
Thunderbird's features (quoting, styling, etc.) is definitively a good
idea. Good design can't hurt. ;)

Kind regards,
Dirk

Am 03.12.20 um 22:59 schrieb Axel Grude:

>> Does that mean, in your opinion it should be fine to strip those, if
>> the document author was careful?
>
>  Yes. you can't have both (encryption and dangerous rules). having said
> that, standard CSS rules should be supported as far as possible.
>
> You can still craft stuff using visibility / negative margins and
> possibly animation, which I do not think can be reliably detected via an
> algortihm though.
>
> What's your thought on iFrames? Are they currently allowed?
>
> Axel
>

> *Axel Grude <mailto:axel....@gmail.com>*

> Music Production and Composition
> Thunderbird Add-ons Developer (QuickFolders

> <https://addons.thunderbird.net/thunderbird/addon/quickfolders-tabbed-folders/>,
> quickFilters
> <https://addons.thunderbird.net/thunderbird/addon/quickfilters/>,
> QuickPasswords
> <https://addons.mozilla.org/firefox/addon/quickpasswords/>, Zombie Keys
> <https://addons.thunderbird.net/thunderbird/addon/zombie-keys/>,
> SmartTemplate⁴
> <https://addons.thunderbird.net/thunderbird/addon/smarttemplate4/>)
> Visit my YouTube Channel <https://www.youtube.com/c/thunderbirddaily>
> for email productivity tips Get Thunderbird!
>> *Subject:*Re: Product decision regarding HTML/CSS email and digital
>> signatures
>> *From:*Kai Engert <ka...@kuix.de>
>> *To:*Tb-Pl...@mozilla.org <tb-pl...@mozilla.org>; Axel Grude
>> <axel....@gmail.com>
>> *Sent: *Thursday, 3/12/2020 21:51

>> On 03.12.20 22:16, Axel Grude wrote:
>>> when you say "conditional rules" are you referring to @media stuff?
>>
>> Yes. We're currently filtering:
>> - @media
>> - @document
>> - @supports
>> - @import
>>
>>
>>> I think that should degrade gracefully if some plain "ground rules"
>>> are added, too.
>>
>> Does that mean, in your opinion it should be fine to strip those, if
>> the document author was careful?
>>
>> Thanks
>> Kai
>
>

[Axel Grude]

(Attempting to reply with SHIFT to show good will on writing in text only)

This reminds me of another pet peeve. I often get asked for a way to re-style quotes
to "remove the ugly blue bar" at the side - that's from people who usually use HTML
mail. The objective thereby is usually to "make the email look clean like in Outlook".

I really can't understand that after working in corporate environments (I really
really dislike Outlook) for over a decade and witnessing people multi-coloring their
replies in order to create a somewhat "coherent thread". What's wrong with
automatically knowing that something was quoted?

I know this isn't really related to security aspects but it just seems opinions are
split on that front as much as HTML vs Text.

Axel

*Axel Grude <mailto:axel....@gmail.com>*
Music Production and Composition
Thunderbird Add-ons Developer(QuickFolders
<https://addons.thunderbird.net/thunderbird/addon/quickfolders-tabbed-folders/>,
quickFilters <https://addons.thunderbird.net/thunderbird/addon/quickfilters/>,
QuickPasswords <https://addons.mozilla.org/firefox/addon/quickpasswords/>, Zombie Keys
<https://addons.thunderbird.net/thunderbird/addon/zombie-keys/>, SmartTemplate⁴
<https://addons.thunderbird.net/thunderbird/addon/smarttemplate4/>)
Visit my YouTube Channel <https://www.youtube.com/c/thunderbirddaily> for email

productivity tipsGet Thunderbird!

> *Subject:*Re: Product decision regarding HTML/CSS email and digital signatures

> *From:*Dirk Steinmetz (Rsjtdrjgfuzkfg) <thunderb...@rsjtdrjgfuzkfg.com>
> *To:*Tb-Pl...@mozilla.org <tb-pl...@mozilla.org>
> *Sent: *Thursday, 3/12/2020 22:03

[Ben Bucksch]

First off, the "digitally signed" icon should be in the message header.
The message header should be inaccessible to email content. If email
content can anyhow alter the message header, that's a security bug.

Second, I agree with Dirk that replies must strip CSS. I strongly
recommend to pass quotes through the "simply HTML" sanitizer. That can
get rid of all this, and of a lot of other bugs that we had in the past
that applies only to replies, for similar reasons. A lot of bugs are cut
short by this. After all, when you quote, you don't want to see the
message in all its glory, but simply want to have the text to get the
context of the reply.

[Magnus Melin]

The particular issue discussed is an unusual one. Technically everything
is correct. It's more of finding the best way to mitigate a social
engineering attack. The researchers who found it don't have a proper
solution for it.

Even using plain text emails doesn't protect you fully, perhaps if you
fully force the viewing mode also to plain text. That's obviously not a
good solution though.

In the end it comes down to conflation of what "signed" means to the end
users: does it mean the *content* is "true" or not. Clearly no (you can
easily sign a lie), but how to make it clear. And how to let people who
want to rely on that true-ness to do so.

 -Magnus

[David Reagan]

Can I ask why this is specific to digitally signed messages? I'd think
it would work for unsigned messages as well. So I'd want the solution to
apply to them.

> - notify the user whenever a message contains conditional CSS,
>   similar to the remote content notification
>
> - offer the user the choice to strip or keep
>
> - the notification and choice should be presented both when reading
>   and replying/fowarding a message
>
> - allow the user to configure the choice in preference

Personally, I'd like to see all of those ideas implemented. That, plus a
"Why?" button/link that leads to well written explanation of the issue
aimed at non-technical users, would let security conscious users stay
secure, and those who just want pretty email to get their pretty email.

- David Reagan

[Kai Engert]

On 04.12.20 08:30, Magnus Melin wrote:
>
> In the end it comes down to conflation of what "signed" means to the end
> users: does it mean the *content* is "true" or not. Clearly no (you can
> easily sign a lie), but how to make it clear. And how to let people who
> want to rely on that true-ness to do so.

It's not about truth.

It's about being certain who said it, and what was said.

Kai

[Ben Bucksch]

Am 04.12.20 um 15:23 schrieb Kai Engert:

> On 04.12.20 08:30, Magnus Melin wrote:
>>
>> In the end it comes down to conflation of what "signed" means to the end
>> users: does it mean the *content* is "true" or not.

> It's about being certain who said it, and what was said.

Yes, this is a good way to look at it. As such, I think the signature
confirmation should be directly next to the sender. Because it's that
what TB and the CA asserts: That the message comes from this email
address, nothing more.

>> Clearly no (you can
>> easily sign a lie), but how to make it clear. And how to let people who
>> want to rely on that true-ness to do so.
>
> It's not about truth.
>

Right. But if we visualize it with a green checkmark, people think
(misunterpret it) that the sender is trusted.

Even worse when we say "verified". We here know that the sender was
verified, but less precise people might think that the content was
verified or at least that the sender ist trusted.

This is a very common misunderstanding. The misunderstanding is produced
by our UI.

I think a signature icon and "signature" wording would be much more
appropriate than a green checkmark or "verified" wording.

Ben

[John Bieling]

>
> Yes, this is a good way to look at it. As such, I think the signature
> confirmation should be directly next to the sender. Because it's that
> what TB and the CA asserts: That the message comes from this email
> address, nothing more.
>

And that the content of the email has not been altered.

[Magnus Melin]

On 2020-12-04 16:23, Kai Engert wrote:
> On 04.12.20 08:30, Magnus Melin wrote:
>>
>> In the end it comes down to conflation of what "signed" means to the end
>> users: does it mean the *content* is "true" or not. Clearly no (you can
>> easily sign a lie), but how to make it clear. And how to let people who
>> want to rely on that true-ness to do so.
>
> It's not about truth.
>
> It's about being certain who said it, and what was said.

That's the thing - if you don't need to care about the content being
"true", that doesn't matter. It's the conflation that you put more truth
behind the message just because it's signed that can cause problems.

 -Magnus

[Patrick Brunschwig]

I think that the problem lies even deeper. Dirk showed nicely (though
unintentionally) that CSS from a message part will leak into all other
message parts. And _that_ is the source of all problems. When it comes
to signed and/or encrypted messages, you can do all sorts of harm, for
example by wrapping a signed message part into an unsigned message part.
You'd then only need some nice CSS rules, to make the message look like
signed, but the message displayed is any arbitrary content.

If we could separate the message parts properly from each other - both
when displaying and when replying - then we would not need to try to
modify CSS rules. That would fix the root cause of all problems.

-Patrick

[Ben Bucksch]

Am 04.12.20 um 21:35 schrieb Patrick Brunschwig:

> I think that the problem lies even deeper. Dirk showed nicely (though
> unintentionally) that CSS from a message part will leak into all other
> message parts. And _that_ is the source of all problems. When it comes
> to signed and/or encrypted messages, you can do all sorts of harm, for
> example by wrapping a signed message part into an unsigned message part.
> You'd then only need some nice CSS rules, to make the message look like
> signed, but the message displayed is any arbitrary content.
>
> If we could separate the message parts properly from each other - both
> when displaying and when replying - then we would not need to try to
> modify CSS rules. That would fix the root cause of all problems.

I agree. We should have done that in TB 52 when the first slew of these
bugs hit.

It's not trivial - otherwise it would have been done 20 years ago - but
it's possible. Jörg has digged out some older bugs *1 that show this.
Please look particularly at bug 9942.

The right approach is to put message header, message body, and each
attachment, each in their own <iframe>, and then calculate the iframe
inner size, and set the iframe outer size to its inner size, i.e.
intrinsically sizing them. That allows all parts to scroll together as
one, and we can even finally scroll the message header. This is the only
real solution that I see.

Ben

*1

https://bugzilla.mozilla.org/show_bug.cgi?id=31052

https://bugzilla.mozilla.org/show_bug.cgi?id=1297653#c41 -->

https://bugzilla.mozilla.org/show_bug.cgi?id=9942

[Axel Grude]

I bet this has been suggested already (or may be a silly suggestion) but what about adding unique parent containers (div) and re-scoping all rules with parent selectors? (Obviously not gonna work with body rules but could it work with everything else?)

Axel

 

Axel Grude
Music Production and Composition

Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
Visit my YouTube Channel for email productivity tips

Subject:Re: Product decision regarding HTML/CSS email and digital signatures
From:Ben Bucksch <ben.b...@beonex.com>
To:Tb-Pl...@mozilla.org <tb-pl...@mozilla.org>
Sent: Friday, 4/12/2020 23:06

[Ben Bucksch]

Am 05.12.20 um 00:21 schrieb Axel Grude:

I bet this has been suggested already (or may be a silly suggestion) but what about adding unique parent containers (div) and re-scoping all rules with parent selectors? (Obviously not gonna work with body rules but could it work with everything else?)

It requires that you parse all CSS. And it doesn't help with things like `position: absolute`. CSS is just to powerful to sanitize properly.

[IT Support @ Henk]

On 03 Dec 2020 14:37, Kai Engert wrote:
> I'd welcome your feedback on this topic.

G'day Kai,

Thanks for bringing this up.

Our concern is more procedural. You are seeking people's opinion after
you've already changed the behaviour of the system in
https://bugzilla.mozilla.org/show_bug.cgi?id=1530106 which is now
causing undesired side effects. According to comment 95 in that bug, the
solution is also "very incomplete"
(https://bugzilla.mozilla.org/show_bug.cgi?id=1530106#c95,
https://bugzilla.mozilla.org/show_bug.cgi?id=1603299).

The change in behaviour in CSS handling was noticed here
https://bugzilla.mozilla.org/show_bug.cgi?id=1659362 and somehow a patch
to mitigate the issue has been pending for almost four months now.
Wasn't the mitigation proposed by Thunderbird's lead engineer? What is
your decision-making process in case of an incomplete solution (bug
1530106) with unwanted side-effects (bug 1659362 and duplicates)?

Seeking user involvement in this thread and
https://bugzilla.mozilla.org/show_bug.cgi?id=1680499 comes too late in
our humble opinion. The user community should have been involved before
changing the behaviour of the system. Not to mention the severe problems
that were caused with mail from Outlook
(https://bugzilla.mozilla.org/show_bug.cgi?id=1675507) which made some
help desk hotlines ring hot (the bug was filed by a Galician/Spanish
government authority).

Thanks for your consideration,

Robert

--
IT Support @ Henk
A good system administrator is one that has nothing to do, because everything works OK

[Onno Ekker]

I must admit I haven't read all the related bugs, but maybe it's
possible to send messages like this both in html as well as in plain
text and only sign the plain text version?

Onno

[Andrew Gallagher]

On 16/12/2020 19:25, Onno Ekker wrote:
> I must admit I haven't read all the related bugs, but maybe it's
> possible to send messages like this both in html as well as in plain
> text and only sign the plain text version?

I'm not sure this would be constructive. If you're signing a message,
you want to sign the version that your correspondent is going to read.
If you don't want your correspondent to read the HTML version of the
message, then why include it at all?

--
Andrew Gallagher