1779640 - Use a finer grained permission level for reading and updating messages, maybe even for getting just the headers.

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, enhancement)

Description

[Andreas]

Attachment: current_messages_read_permission.png

Steps to reproduce:

For my ThirdStats add-on I'm iterating over all messages and I only need to process data from message headers to create statistics. To query the messages, I use the messagesRead permission.

Actual results:

The messagesRead permission gives access to both, the message header and body. So when a user installs my ThirdStats add-on, they currently have to agree to "Read your email messages and mark or tag them". But all the add-on needs is "Read your email message headers". It doesn't process the email body at all.

Expected results:

I would love to have a permission granting only reading access to the message headers, e.g. messagesHeaderRead. When a users installs my add-on, they should only need to agree to "Read your email messages headers".

Comment 1

[Mark Banner (:standard8)]

I think one of the potential problems with going finer grained is that the user doesn't necessarily know what "message headers" are. Nor would they necessarily understand what is in them.

The obvious example is the subject - even without the message body, you can sometimes get a lot of information/context about what the email is about. Likewise with who it is from. Some systems (e.g. bugzilla), also include additional headers with potentially private information that you might not want to share with an add-on.

Comment 2

[Andreas]

Thank You, Mark, for your thoughts. So if I understand you correctly, your first point would be more of a documentation / communication issue, which would be solved with a good formulation of the permission description. I don't think the user needs to understand, what a message header technically is, only that it contains the additional data to the message itself (which I assume everybody understands who uses email). As an example, the following permission description would be explanatory enough for me as a user:

messagesHeaderRead
Read your email messages headers (e.g. recipients, date and author), excluding the actual content of the message.

As for your second thought, I agree with you. There may and will still be sensitive data in the message headers. But nevertheless imo it is a strong improvement regarding data economy (is that the right word? In German we call it "Datensparsamkeit").

Comment 3

[Mark Banner (:standard8)]

(In reply to Andreas from comment #2)

messagesHeaderRead
Read your email messages headers (e.g. recipients, date and author), excluding the actual content of the message.

In my opinion this is not enough. You would have to make it something like (e.g. subject, recipients, date, author, thread details, other potentially sensitive message data) by which time it is getting unwieldy especially for a short message. Having an explainer doc wouldn't really help as most people wouldn't look at it. If you wanted something short, then I think it'd be something like Read potentially sensitive information from your message but not the actual body which would probably be confusing in itself.

I agree in general that having finer-grained permissions is better, but my own feeling on this specific case is that it is too hard to clearly distinguish what the separate parts are and the nuances with respect to privacy - which is what we're trying to protect here.

Comment 4

[Andreas]

I see your point. Personally as a user I wouldn't mind a longer description of the permission (I would even appreciate it) but of course I understand that is has to be short and simple. From the point of view of an addon dev, the best and most transparent solution would be to being able to define, which attributes are really processed by the add-on (e.g. only date, author and recipients) and this would be reflected in the permission message the user agrees to. Just an idea, a possible manifest would be sth like this:

"permissions": {
	"accountsRead": true,
	"messagesRead": ["date", "author", "recipients"],
	"storage": true,
	"downloads": true
}

I understand that this is too much of a breaking change, but would provide great transparency.

In addition: Is there a particular reason why reading messages and mark or tag them is the same permission? Marking or tagging is kind of a writing action, as I understand it. Maybe this could be separated into messagesRead and messagesMarkOrTag.

Comment 5

[John Bieling]

I agree that we need an extra permission for updating a message (changing any of these: https://webextension-api.thunderbird.net/en/102/messages.html#messages-messagechangeproperties) but it probably has to be different from changing the actual message (which currently is not possible via webExt API). Would that alone solve the issue for you (removing the "write" access from the messagesRead permission)?

I have not made up my mind about the messageReadHeaders permission yet.

Currently you have access to these standard headers:
https://webextension-api.thunderbird.net/en/102/messages.html#messages-messageheader

• We could introduce a messageReadBasicHeaders permission, which gives you access to the WebExt MessageHeader but not to getRaw() or getFull. These headers should be listed in the permission description: subject, to, from, cc, bcc, date, size, flagged, junk, read, tags.

• We could limit getFull() to return headers only (or add getHeaders()) and add messageReadAllHeaders.

• Alternative: A messageReadHeaders permission similar to the host_permission, where the developer explicitly request headers. But what about the basic MessageHeader? Should size, flagged, read, tags be always available (because it is Thunderbird meta information) and subject, to, from, cc, bcc, date stripped, if not requested?

Comment 6

[Andreas]

Thank you John for sharing your thoughts and suggestions.

Would that alone solve the issue for you (removing the "write" access from the messagesRead permission)?

That alone would be a great improvement for me, yes. Still my original issue is having the possibility to show the user, that the add-on they're about to install won't read the content of their emails.

• We could introduce a messageReadBasicHeaders permission... [...] We could limit getFull() to return headers only (or add getHeaders()) and add messageReadAllHeaders.
• Alternative: A messageReadHeaders permission similar to the host_permission, where the developer explicitly request headers...

Both points are great suggestions and would solve the issue for me!

But what about the basic MessageHeader?

Well I would prefer being able to even strip those meta information, if they are not needed. But I would totally be fine with having those meta information always available.

Comment 7

[Mark Banner (:standard8)]

(In reply to John Bieling (:TbSync) from comment #5)

• We could introduce a messageReadBasicHeaders permission, which gives you access to the WebExt MessageHeader but not to getRaw() or getFull. These headers should be listed in the permission description: subject, to, from, cc, bcc, date, size, flagged, junk, read, tags.

I think my concern would still be how to message this. Although these can be seen as "headers", I just realised that when you look more from a user's data privacy perspective (rather than technical groupings), there's multiple different groups, for example:

• to, from, cc, bcc are all to do with the user's contact network and could be used to build a map of contacts over time - even if addressBooks permission hasn't been granted.
• subject, flagged, tags, junk could all be used to build up a picture of what's in the email, without actually reading the email contents.
• date could be used to build up a picture of when you normally send email (i.e. when you're active), use this in combination with the contact information and you can also build up a picture of when they are active.

So I think, if we want to split it in a message headers vs body kind of way, then we need to somehow communicate this - concisely in the permissions dialog. Also remember, that listing individiual headers will potentially be a visibly longer list with different locales.

• Alternative: A messageReadHeaders permission similar to the host_permission, where the developer explicitly request headers. But what about the basic MessageHeader? Should size, flagged, read, tags be always available (because it is Thunderbird meta information) and subject, to, from, cc, bcc, date stripped, if not requested?

Tags and flagged aren't necessarily TB meta information. That's information the user has added about the email, and which could point to information about the email, depending on what other information it can be combined with. In some ways you could say that even having the folder an email is in might give some information about that email (e.g. if I have a folder called "Bugmail" with an email in then you know what that email is about).

(Side Note: if we're worried about backwards-compatibility, we could always use manifest v3 as time to introduce/change permission structures).

Comment 8

[John Bieling]

Attachment: Bug 1779640 - Add messagesUpdate permission for messages.update(). r=#thunderbird-reviewers

Depends on D193793

Comment 9

[John Bieling]

I did think about this for quite some time now, and I decided that I will not go below the messagesRead permission level. I will however decouple updating a message from the pure read access by introducing the messagesUpdate permission.

When we talk about messages, the smallest data set is the MessageHeader and even that includes a lot of additional information (tags, folders, flagged, ...) and striping that from the object will make the API overly complicated. In the end, it boils down to this:

• only a small group of users understands the concept of message headers
• everybody understands that you need to read messages in order to analyze them
• those who DO understand headers and who might request to grant access only to these are probably capable to read the source of your add-on to see that you are not doing strange things
• the worrying factor here is probably exfiltrating data, and we did address this by enforcing review of add-ons requesting the messagesRead permission (and we did introduce the sensitiveDataUpload permission to indicate to users that an add-on is in fact moving data elsewhere)

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9f5fb0333c01
Add messagesUpdate permission for messages.update(). r=mkmelin,ikey