Tracking newsletter recipients

[Kai Engert]

I would like to raise an issue regarding privacy and Mozilla's email
newsletters.

Background
==========
Since about mid 2012, the emails I've been receiving contain tracking
links that look like
http://click.e.mozilla.org/?qs=[80 digit hex code]

It's impossible to know which link is behind that tracking link, without
actually clicking it.

Initially I had hoped that it was merely a mechanism to count the number
of clicks by newsletter receipients. But after talking to other
newsletter receipients, I learned that each receipient receives
different tracking links. I conclude that Mozilla uses a system, which
allows to individually track each newsletter recipient, who clicked
what.

I complained by filing
https://bugzilla.mozilla.org/show_bug.cgi?id=772788

In comment 4 Winston Bowden explained the purpose of the tracking links:
> However, for full transparency - for other newsletters (like Firefox &
> You), we do use a tracking link to ensure email delivery. It's
> important so that we can cleanse our list of inactive subscribers.
> That's an important (and unfortunate) component of delivering bulk
> email to ISPs. For those publications, we offer both an HTML version
> and a text-only. Users who do not want a personalized URL have the
> option of selecting the text-only version of campaigns during the
> opt-in.

I was offered the choice to change my subscriptions to text-only.
Indeed, when receiving text-only messages, I get the emails in plain
text. Unfortunately, that system isn't working reliably. Repeatedly
afterwards I've received tracking links, again, as documented in the
bug.


Discussion
==========
As a reminder, here are Mozilla's privacy principles:
http://www.mozilla.org/en-US/privacy/


Principle 1: "No Surprises. Only use and share information about our
users for their benefit and as spelled out in our notices."

Question: How do users individually benefit from being email tracked?


Principle 2: "Real Choices. Educate users whenever we collect any
personal information and give them a choice whenever possible."

Questions: Does Mozilla clearly explain that you'll be tracked by email
at the time of subscribing, if using the defaults? Do users have a real
choice, if we are vague and require them to opt out of html?


Principle 3: "Sensible Settings. Establish default settings that balance
safety and user experience appropriately."

Questions: Is "being tracked" a sensible default setting for email? Is
it right to tie that setting to a user's choice of HTML vs. Text? Is it
right to use a system that allows users to accidentally have their opt
out choice reverted? Shouldn't Mozilla rather use a system where the
default is opt in, and where users are switched to the opt in setting,
whenever there is uncertainity about their preferences, because of
technical malfunctions?


Principle 4: "Limited Data. Collect and retain the least amount of user
information necessary. Try to share anonymous aggregate data whenever
possible, and then only when it benefits the web, users or developers."

Question: What data are we collecting? Where do we document that?


Thanks to Gerv who suggested to write this email and who proposed some
of the questions.

Regards
Kai

[Gervase Markham]

On 24/01/13 12:49, Kai Engert wrote:
> I would like to raise an issue regarding privacy and Mozilla's email
> newsletters.

Hmm. Looking at the sparseness of the archives, this list may be dead.
Let's see who's still around but if you get no traction, we may have to
go elsewhere...

Gerv

[sst...@mozilla.com]

Yeah, this forum is not used at all, really. Lets rope some folks into this discussion and use this as the place to archive it, though. This *is* an appropriate place for non-private privacy-policy related discussions.

-Sid

[sst...@mozilla.com]

[Gervase Markham]

OK. Rope away, Sid! :-)

Gerv

[sma...@mozilla.com]

Hi Kai,

Thanks for opening the discussion. Trying to find the right balance for transparency and choice within the constraints of email delivery is something we've been working on for a while, and I know we've still got some issues to work out, so I appreciate your asking the questions.

Starting with the problem you mentioned in the bug, it seems to have been caused by the integration of our email system with the Mozillians Phonebook. Winston and Jess are working to fix it. You (and all Mozillians) should receive an email later this week to help explain what you can do to make sure your preferences are set correctly.

Regarding the discussion on the privacy principles, I'll try to answer each of your questions below.

Re: Question: How do users individually benefit from being email tracked?

I think the benefit to users is really just deliverability - being able to receive the newsletter you requested in your inbox. I know that doesn't sound like a very exciting benefit, but the reason behind it is that Internet service providers use open and click as a factor to decide how they deliver an email. From what I understand, if we don't remove the non-responders (those who haven’t opened or clicked an email in six months or more), all of our emails have a higher chance of going into the spam filter, or not being delivered at all (our IP address and sender information can be blocked at the domain level).

The engagement (marketing) team uses individual open and click data to remove non-responders, so that those who want the email have a better chance of getting it. Offering the text only option actually increases the delivery risk (because we can't do the tracking and cleansing), but we offer it because we want to offer the choice of not being tracked.

Re: Questions: Does Mozilla clearly explain that you'll be tracked by email at the time of subscribing, if using the defaults? Do users have a real choice, if we are vague and require them to opt out of html?

We don't clearly explain it and I think we all agree that we should. Our plan is to add a "more info" link to our subscription pages so that those who are interested can read about the tradeoffs between html and text. To my knowledge, text vs. html is the best we can do to offer real choice in the current environment. I think our other option would be to put resources towards coming up with something new.

Re: Questions: Is "being tracked" a sensible default setting for email? Is it right to tie that setting to a user's choice of HTML vs. Text? Is it right to use a system that allows users to accidentally have their opt out choice reverted? Shouldn't Mozilla rather use a system where the default is opt in, and where users are switched to the opt in setting, whenever there is uncertainty about their preferences, because of technical malfunctions?

The reason html is the default is so that we can remove non-responders to increase deliverability. It doesn't sound like we can change that, but you raise a good point that we can be clearer about it. (see the question above and below this one for details).

Re: Question: What data are we collecting? Where do we document that?

From talking with Winston and Jess, we collect opens, clicks, bounces and unsubscribes. I don’t think that’s as well documented as it should be either. To fix that, we're updating the online privacy policy (see draft below) and would like to add the "more info" page I mentioned above.

Here's the draft privacy policy text:

Our HTML formatted emails may use clear GIFs (also known as web beacons or pixels) to compile information about your interaction with the email and the effectiveness of our campaigns, such as whether you opened the email. You can choose not to allow web beacons by selecting text only emails.

============

Kai, does that answer your questions? If you still have concerns, I'd be happy to talk more or help set up a call with Winston and Jess.

[sma...@mozilla.com]

On Thursday, January 24, 2013 4:49:07 AM UTC-8, Kai Engert wrote:

[Kai Engert]

On Fri, 2013-01-25 at 08:36 -0800, sma...@mozilla.com wrote:
> Trying to find the right balance for
> transparency and choice within the constraints of email delivery is
> something we've been working on for a while, and I know we've still got
> some issues to work out, so I appreciate your asking the questions.
>
> Starting with the problem you mentioned in the bug, it seems to have
> been caused by the integration of our email system with the Mozillians
> Phonebook. Winston and Jess are working to fix it. You (and all
> Mozillians) should receive an email later this week to help explain
> what you can do to make sure your preferences are set correctly.

I would like to ask that this isn't just about Mozillians. The scope is
all recipients of any Mozilla newsletter.

I just went to https://www.mozilla.org/en-US/newsletter/
and subscribed using a new email address.

I've chosen "text" format. I immediately received a welcome email, and
all the links in the email were tracking links!

While I appreciate your responses and your attempt to fix the reported
issues, I'd appreciate a commitment to avoid such issues in the default
scenario. If things go wrong, the systems should operate in the "don't
track" mode by default. And apparently I just found another place where
it doesn't work right yet. Oops?

> Re: Question: How do users individually benefit from being email
> tracked?
>
> I think the benefit to users is really just deliverability - being able
> to receive the newsletter you requested in your inbox. I know that
> doesn't sound like a very exciting benefit, but the reason behind it is
> that Internet service providers use open and click as a factor to
> decide how they deliver an email.

Could you please point us to a document where an ISP explains this in
more detail?

> From what I understand, if we don't
> remove the non-responders (those who haven’t opened or clicked an email
> in six months or more), all of our emails have a higher chance of going
> into the spam filter, or not being delivered at all (our IP address and
> sender information can be blocked at the domain level).

Here is something that I don't understand:

If an email doesn't reach the recipient, email "bounces". The computer
sending the original message will get an automatic reply from the
destination email server, informing the sender that delivery wasn't
possible.

Why isn't that sufficient to identify and remove nonworking email
addresses?

I'm surprised, but it sounds like you're saying, Mozilla is required to
"prove" to ISPs that newsletter recipients are indeed actively clicking
links. How does that technically work? Are you simply required to
produce a high level statistical summary with some numbers? Or does your
ISP require you that you give them access to your logs?

> The engagement (marketing) team uses individual open and click data to
> remove non-responders, so that those who want the email have a better
> chance of getting it. Offering the text only option actually increases
> the delivery risk (because we can't do the tracking and cleansing), but
> we offer it because we want to offer the choice of not being tracked.

Trying to be constructive, instead of using tracking links, why don't
you simply add a boilerplate to the bottom of each email?

It could say:

"We are required to remove all newsletters subscribers who haven't
reconfirmed their interest within the previous 6 months. Please click
here to open the page that shows your newsletter preferences, at least
once in 6 months. That will ensure you will continue to be subscribed.
[tracking link here]
If you ever believe you got unsubscribed, feel free to resubscribe using
the following link at any time.
[plaintext link, so cautious people can see this one is really a mozilla
link, not spam]

> Re: Questions: Does Mozilla clearly explain that you'll be tracked by
> email at the time of subscribing, if using the defaults? Do users have
> a real choice, if we are vague and require them to opt out of html?
>
> We don't clearly explain it and I think we all agree that we should.
> Our plan is to add a "more info" link to our subscription pages so that
> those who are interested can read about the tradeoffs between html and
> text. To my knowledge, text vs. html is the best we can do to offer
> real choice in the current environment.

I'd appreciate that.

> I think our other option would
> be to put resources towards coming up with something new.

Maybe my suggestion above turns out to be simple to do? Only one of the
links would have to be a tracking link (the one to go to the newsletter
settings), and users are being offered the full choice and control of
what they want to do, without tracking which other links they click.

> Re: Question: What data are we collecting? Where do we document that?
>
> From talking with Winston and Jess, we collect opens, clicks, bounces
> and unsubscribes. I don’t think that’s as well documented as it should
> be either. To fix that, we're updating the online privacy policy (see
> draft below) and would like to add the "more info" page I mentioned
> above.

How does Mozilla actually store these results? Do you have records,
where for each email address, you store the most recent date and time
when a user clicked one of the tracking links?

Do you also store IP addresses of users? If you do, I'd suggest that you
please change your system to immediately delete the IP addresses of
clicks.

> Here's the draft privacy policy text:
>
> Our HTML formatted emails may use clear GIFs (also known as web beacons
> or pixels) to compile information about your interaction with the email
> and the effectiveness of our campaigns, such as whether you opened the
> email. You can choose not to allow web beacons by selecting text only
> emails.

I think that text is incomplete. Some users may use an email client that
doesn't show remote images by default. (Thunderbird is one such client.)

But even if users have disabled remote images, which effectively
disables your web beacons, they are still being tracked whenever they
click a link. In my opinion that tracking mechanism should also be made
clear. In other words, if you want a simple text, you could simply say
that recipients will be tracked, unless they chose the text format.

Thanks and Regards
Kai

[Daniel Veditz]

On 1/25/2013 8:36 AM, sma...@mozilla.com wrote:
> Thanks for opening the discussion. Trying to find the right balance
> for transparency and choice within the constraints of email delivery
> is something we've been working on for a while, and I know we've
> still got some issues to work out, so I appreciate your asking the
> questions.

FWIW I had the same negative reaction to the click.e. links Kai did, and
I stopped clicking on the links. When I see something interesting I now
manually try to find it using the browser. I suspect my readership of
such links has gone down because I can't just click to open a tab to
read later, I have to be interested enough and have enough time at just
that moment to open the page or it slides into the past carried by the
river of mail.

They incidentally increased the spam score, because I junk lots of
incoming mail with similar links -- I guess click.e is a 3rd party
service used by other companies?

Is the information collected /by/ Mozilla, or does a 3rd party also have
access to the click information? I suspect the latter which is why I
stopped clicking. If it's a 3rd party I assume we had a legal and
privacy review, but I still don't trust it not to leak around.

I appreciate that the newsletter team is trying to do what they think is
the right thing here. Thank-you for considering our concerns. This is an
area where "Mozillians" are more sensitive than the broader public.

-Dan Veditz

[wbo...@mozilla.com]

Hi all,

Thanks for the great discussion / suggestions. For those who don’t know me, I manage the group that oversees are owned media channels: email, social and snippet.

Email delivery has changed a lot over the past few years. I’ve tried to give you some background below and answer the questions that have been posed.

Email delivery / engagement:
Open and click tracking are key to ensure emails are delivered. The issue is subscriber inactivity. If we’re emailing and recipients aren’t interacting, ISPs assume we’ve purchased a list of emails. Cleaning our list of inactive subscribers is a critical part of email engagement and you can’t do that if you don’t know who is reading / engaging with content. For example, if you’ve been on our list for 12 months and you haven’t opened an email, your inactivity is impacting the sender reputation of our IPs. The ISPs are taking that into account when deciding what to do with all of the email we send. Essentially, anyone’s inactivity influences the delivery of our email to those who want to receive the content.

Why do ISPs do this? They’ve found it to be the most reliable way of putting spammers in the junk folder and legitimate senders in the Inbox. Without basic data, we can’t segment our inactives from our actives.

But to be clear: Mozilla gives no information to ISPs directly. ISPs are looking at their own users’ inbox behavior and making decisions on which emails are spam and which are legitimate. We're simply keeping our list clean of non-active recipients.

Two articles that might interest you:

- http://www.spamresource.com/2009/09/domain-reputation-and-recipient.html
- http://www.email-marketing-reports.com/iland/2009/10/future-of-deliverability-1-role-of-user.html

Are IP addresses stored?
No. Not stored or recorded.

Tracking by default in welcome emails:
There’s a simple reason why this occurs. For many of our locales, we require a double opt-in. This means in order for a user to be added to the list, s/he must click a personalized link in the welcome email to confirm interest. Once that link is clicked, the subscriber is added to our list. We can’t complete the double opt-in without that functionality.

e.mozilla.org
e.mozilla.org is a subdomain. We use it exclusively for our email program. However, it’s true that this does work in tandem with our email engagement vendor and they store the data. But I’ll also add that any vendor we work with goes through an extensive security and privacy review.

Welcome emails - Text and HTML preferences
Good point. You’re seeing this behavior because a subscriber isn’t actually added to our master list that houses preferences until 24 hours later when a program runs. Until they’re on the master table, they’re in a “holding” status. That means that preferences aren’t actually applied until the nightly program runs and the subscriber is added to the master. So basically, at the time of that initial welcome email, the text vs HTML value hasn’t been passed. But you’re right – this isn’t a great user experience and we’re going to change the way that welcome email functions. Will keep you updated on the status.

Thanks again for the feedback,
Winston

On Thursday, January 24, 2013 4:49:07 AM UTC-8, Kai Engert wrote:

[wbo...@mozilla.com]

Hi all,

Thanks for the great discussion / suggestions. For those who don’t know me, I manage the group that oversees are owned media channels: email, social and snippet.

Email delivery has changed a lot over the past few years. I’ve tried to give you some background below and answer the questions that have been posed.

Email delivery / engagement:
Open and click tracking are key to ensure emails are delivered. The issue is subscriber inactivity. If we’re emailing and recipients aren’t interacting, ISPs assume we’ve purchased a list of emails. Cleaning our list of inactive subscribers is a critical part of email engagement and you can’t do that if you don’t know who is reading / engaging with content. For example, if you’ve been on our list for 12 months and you haven’t opened an email, your inactivity is impacting the sender reputation of our IPs. The ISPs are taking that into account when deciding what to do with all of the email we send. Essentially, anyone’s inactivity influences the delivery of our email to those who want to receive the content.

Why do ISPs do this? They’ve found it to be the most reliable way of putting spammers in the junk folder and legitimate senders in the Inbox. Without basic data, we can’t segment our inactives from our actives.

But to be clear: Mozilla gives no information to ISPs directly. ISPs are looking at their own users’ inbox behavior and making decisions on which emails are spam and which are legitimate. We're simply keeping our list clean of non-active recipients.

Two articles that might interest you:

- http://www.spamresource.com/2009/09/domain-reputation-and-recipient.html
- http://www.email-marketing-reports.com/iland/2009/10/future-of-deliverability-1-role-of-user.html

Are IP addresses stored?
No. Not stored or recorded.

Tracking by default in welcome emails:
There’s a simple reason why this occurs. For many of our locales, we require a double opt-in. This means in order for a user to be added to the list, s/he must click a personalized link in the welcome email to confirm interest. Once that link is clicked, the subscriber is added to our list. We can’t complete the double opt-in without that functionality.

e.mozilla.org
e.mozilla.org is a subdomain. We use it exclusively for our email program. However, it’s true that this does work in tandem with our email engagement vendor and they store the data. But I’ll also add that any vendor we work with goes through an extensive security and privacy review.

Welcome emails - Text and HTML preferences
Good point. You’re seeing this behavior because a subscriber isn’t actually added to our master list that houses preferences until 24 hours later when a program runs. Until they’re on the master table, they’re in a “holding” status. That means that preferences aren’t actually applied until the nightly program runs and the subscriber is added to the master. So basically, at the time of that initial welcome email, the text vs HTML value hasn’t been passed. But you’re right – this isn’t a great user experience and we’re going to change the way that welcome email functions. Will keep you updated on the status.

Thanks again for the feedback,
Winston

On Thursday, January 24, 2013 4:49:07 AM UTC-8, Kai Engert wrote:

[xxxagent...@gmail.com]

I have an idea for protecting our emails and meta-data from outside intruders.

First you create email paths for encrypted emails to travel through a series of users until it reaches a computer that can decrypt it.

Then you encrypt the emails and establish a long and randomly generated encryption key between each user.

You then have the encrypted email uploaded and downloaded by each computer along the path until it finally reaches the end receiver.

If users aren't sending emails have them either send random encrypted garbage to other computers or have them send another person's message down the line at intervals.

Of course each user would only see the emails that he has the encryption key to, and the other would be hidden.

All of this makes tracking meta data tracking useless since you can't tell whether each transaction is important data or garbage.

I'd like to help develop this. Please email me if you guys are interested.

-Best of Luck