Mozilla's privacy choices for the "others"

[Un Virumbi]

Mozilla Corporation (Moco) has decided to use AWS instead of in-house servers for most of its services.

Prominent examples of services which are hosted in AWS (or likely to be hosted in AWS, by end of 2015) are:

[1] Firefox Crash Reports
[2] Firefox Health Report
[3] Firefox Auto-Update services
[4] irc.mozilla.org
[5] Firefox Downloads (FTP, HTTP(S))
[6] Telemetry
[7] Services powering daily automatic submissions such as Blocklist Ping, Addons Ping, Addons update checks

(Please note that the SSL endpoints of these services will be hosted in AWS as well. AWS, in theory, has full access to the certificates, IP addr of the client and any other information submitted by Firefox)

In addition to these, Google Apps handles the mail services for mozilla.com, Okta (a third party service hosted in AWS) handles SSO for Moco employees.

Given that cloud service providers such as Amazon are required to "co-operate" with US Govt agencies in secrecy and that any terms of contract between Amazon and Moco are irrelevant in this case, what steps are being taken by Moco to protect the privacy of non-American citizens ?

[Benjamin Kerensa]

Adding Sid Stamm who is probably in the best position to provide a solid
answer.

[:mrz]

> Given that cloud service providers such as Amazon are required to "co-operate" with US Govt agencies in secrecy and that any terms of contract between Amazon and Moco are irrelevant in this case, what steps are being taken by Moco to protect the privacy of non-American citizens ?

Isn't Mozilla (Corp) itself required to "co-operate" with the US government also?

Is the question more broad and instead what is Mozilla doing to protect the privacy of all its users, regardless of hosting provider?

[sst...@mozilla.com]

> Given that cloud service providers such as Amazon
> are required to "co-operate" with US Govt agencies
> in secrecy and that any terms of contract between
> Amazon and Moco are irrelevant in this case, what
> steps are being taken by Moco to protect the privacy
> of non-American citizens ?

> Adding Sid Stamm who is probably in the best position to provide
> a solid answer.

Actually, I'm not the right person for this, but I've asked our policy folks to weigh in. This is a question of policy and compliance and I do neither of those. I'm happy to talk about what our software does or should do, but don't know much about what we do with lawyers and governments.

-Sid

[mer...@mozilla.com]

Hi Un

Thanks for your question. It is important to know that there isn't really a distinction between what we may be required to do in response to a government request if the data was on our own servers in a colocation facility or if we opted to store the data elsewhere (with a cloud provider like Amazon, Rackspace, or Microsoft) - in all cases we, and all other entities, have to comply with the law. The distinction would be whether a cloud storage provider (like AWS) would challenge a government request in the same way that we might. This isn't something that we can know going into the relationship, but it is something that we consider when we opt to store data elsewhere.

Any time that we opt to use a third party vendor for data storage, we analyze how that vendor has stated that they respond to governmental inquiries among other privacy and security issues. We also consider things such as how robust those vendor's systems are to third party intrusions, what certifications and standards are implemented, whether the vendor allows for encryption and ownership of the encryption keys, and how generally to balance security, privacy, usability and performance of the service. Also, when we negotiate agreements, we attempt to include language around security and privacy to bolster our analysis. We then compare the overall solution to our in house ones to see whether we can do a better job.

The solutions you laid out were picked after this analysis and implemented to balance those interests.

In our products, we also design user control mechanisms that allow users to manage how their data is sent to us (and others), including turning off or not interacting with the services you listed. We also limit what data we collect in the first place and discard data once we don't need it.

Finally, we are always open to more ideas about how we might think about this problem. If you're interested in contributing your thoughts on this and other security and privacy problems around hosting data, we would value your contribution.

Thanks and happy new year -

Marshall Erwin

[Jorge Villalobos]

Would Mozilla be notified if the government "requested" any data from
these third parties?

Jorge

[Un Virumbi]

07.01.2015, 00:34, "sst...@mozilla.com" <sst...@mozilla.com>:
>  Actually, I'm not the right person for this, but I've asked our policy folks to weigh in.  This is a question of policy and compliance and I do neither of those. I'm happy to talk about what our software does or should do, but don't know much about what we do with lawyers and governments.
>
>  -Sid

A related question:

Is there a way to disable *all* such requests (Crash reports, update checks, various pings, ...) initiated by Firefox ?

[Kevin Brosnan]

Yes. Though it is not on topic for this discussion group.

Searching for Firefox disable (update ping, telemetry ping, Firefox health
report, crash reporter) will return relevant results.

Mozilla uses the data in aggregate to improve performance and stability. By
disabling those abilities you prevent your usage behavior from being
addressed.

Kevin Brosnan

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>

[Nikos Roussos]

On 01/07/2015 06:28 AM, mer...@mozilla.com wrote:
> Finally, we are always open to more ideas about how
> we might think about this problem.
> If you're interested in contributing your thoughts on this and other
> security and privacy problems around hosting data,
> we would value your contribution.

I guess the important issue here is that someone may trust Mozilla to
keep their data, but not Amazon. In most cases it doesn't make any
difference, but I can think of one example (Firefox Accounts) that this
may be more significant for many people.

--
Nikos Roussos
https://mozillians.org/u/comzeradd

[Un Virumbi]

12.01.2015, 18:48, "Kevin Brosnan" <kbro...@gmail.com>:

>  Yes. Though it is not on topic for this discussion group.
>
>  Searching for Firefox disable (update ping, telemetry ping, Firefox health report, crash reporter) will return relevant results.
>
>  Mozilla uses the data in aggregate to improve performance and stability. By disabling those abilities you prevent your usage behavior from being addressed.
>

Given that the number and types of pings change, I am now required to keep track of various pings and how they change over time to protect my privacy. This isn't something I expect from a "product" which claims to be actively working to protect the privacy of users irrespective of their nationality, .... (Please note that I trust Mozilla but I *don't* trust Amazon)

If a single pref/button can disable all such pings and submissions, it would be a huge improvement over the current situation (I would imagine that this would be a requirement for things such as Tor Browser)

Telemetry/FHR unification project introduces a persistent UUID per profile. It isn't clear whether this UUID will be re-used for other purposes or other pings. I would rather disable all such pings and submissions than keep track of which combination of them is safe.

[Benjamin Kerensa]

All of these pings are opt-in unless your using Nightly.

[Gijs Kruitbosch]

Ehm, I'm pretty sure we will check for updates on release by default.
Less sure about FHR and crashreporter, but I was under the impression
both were opt-out.

Un Virumbi, naive question: would you really want to include the update
ping in disabling this? (ie no longer getting automated updates)
Seems to me like its privacy issues (which are very small) shouldn't
outweigh the risk of running a version with known security issues.

~ Gijs

[Ehsan Akhgari]

On 2015-01-14 6:29 AM, Gijs Kruitbosch wrote:
> Ehm, I'm pretty sure we will check for updates on release by default.
> Less sure about FHR and crashreporter, but I was under the impression
> both were opt-out.

FHR is opt out:
<https://dxr.mozilla.org/mozilla-central/source/services/healthreport/healthreport-prefs.js#21>

Crash reporter is controlled by a build time option
<https://dxr.mozilla.org/mozilla-central/source/configure.in#6063> that
is on by default.

> Un Virumbi, naive question: would you really want to include the update
> ping in disabling this? (ie no longer getting automated updates)
> Seems to me like its privacy issues (which are very small) shouldn't
> outweigh the risk of running a version with known security issues.

Well, to be fair, there is no right choice when choosing between privacy
and security. It would be nice if we ensure that update pings do not
have any potential privacy issues associated with them so that users who
feel they need to take action against this type of issue do not have to
disable updates.

[Robert Strong]

On Wed, Jan 14, 2015 at 10:41 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

The app update ping only contains data that is needed to serve the right
update for the system. Example from my system:
AUS:SVC Checker:checkForUpdates - sending request to:
https://aus4.mozilla.org/update/3/Firefox/38.0a1/20150113030205/WINNT_x86-msvc/en-US/nightly/Windows_NT%206.3.0.0%20(x64)/default/default/update.xml?force=1

The values of 'default' are for partner builds to differentiate them from
our builds.

Cheers,
Robert

[Mook]

(Apologies to governance@; this isn't the right place for this, but
unfortunately going off-list and replying to just rstrong feels wrong
too. Setting f-up to privacy@ since that looks safely dead, but
mail/new shenanigans might prevent proper functioning there.)

Please remember that you still send cookies; here's what I got out of
Firefox debugging itself as I went to Help -> About:

optimizelySegments=%7B%22245875585%22%3A%22direct%22%2C%22245617832%22%3A%22none%22%2C%22246048108%22%3A%22false%22%2C%22245677587%22%3A%22ff%22%2C%22869421433%22%3A%22true%22%7D;
optimizelyEndUserId=oeu1421293036707r0.8592334519134582;
optimizelyBuckets=%7B%7D;
__utma=150903082.1914521133.1421293040.1421293040.1421293040.1;
__utmb=150903082.2.10.1421293040; __utmc=150903082;
__utmz=150903082.1421293040.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmt=1

So it's got Google Analytics and Optimizely; both are for tracking.

Steps:
1) New download of latest release, 35.0
2) Start with firefox -profile (empty directory) -offline
3) Turn on browser + remote debugging; open the browser toolbox in
Network tab.
4) Click on Try Again in the first run page to go online and trigger things
5) Help -> About Firefox.

I have not checked the addon update ping; that presumably has similar
behaviour. Being privacy-oriented there would likely involve fetching
updates for each addon separately over a period of time to avoid the
ability to track people by the combination of addons they have installed.

Quick scan of things with timestamps in prefs: app update; addon update;
telemetry; FHR; sync; openh264 / gmp; safebrowsing; phishing. Not sure
if things like social that I've disabled involve pings.

When trading between user privacy and designing a better web site, user
privacy lost. (It should be obvious, but: I believe the right choice
here would be a request with no identifying information beyond the build
of Firefox in use, the OS it's running on, and the source IP address so
it can send the response.)

--
Mook

[Robert Strong]

Thanks for looking at whether cookies are still being set Mook! I didn't
bother to look since I had asked for that to be removed several times
several years ago, I was told it wasn't needed since other data collection
mechanisms were in place (at the time the blocklist ping), and I was
assured that it was being removed. *sigh*

Robert

On Wed, Jan 14, 2015 at 8:15 PM, Mook <
mook.moz+nntp.n...@gmail.com.please-avoid-direct-mail> wrote:

> (Apologies to governance@; this isn't the right place for this, but
> unfortunately going off-list and replying to just rstrong feels wrong too.
> Setting f-up to privacy@ since that looks safely dead, but mail/new
> shenanigans might prevent proper functioning there.)
>
> On 01/14/2015 11:08 AM, Robert Strong wrote:
>

[Ehsan Akhgari]

On 2015-01-15 12:04 AM, Robert Strong wrote:
> Thanks for looking at whether cookies are still being set Mook! I didn't
> bother to look since I had asked for that to be removed several times
> several years ago, I was told it wasn't needed since other data collection
> mechanisms were in place (at the time the blocklist ping), and I was
> assured that it was being removed. *sigh*

We should have a test in place that ensure we're not sending these
cookies. :/

[Robert Strong]

I am fairly certain I could disable cookies on the client side to work
around this and make it an option for each app since some apps will likely
want cookies. I'd much prefer it if this was done on the server and thereby
avoid more client code / complexity. If you are referring to testing the
server that test would need to be outside of build tests of course.

Robert

On Thu, Jan 15, 2015 at 1:10 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

[Robert Kaiser]

Ehsan Akhgari schrieb:

> Crash reporter is controlled by a build time option
> <https://dxr.mozilla.org/mozilla-central/source/configure.in#6063> that
> is on by default.

But nothing is sent from it without a dialog asking you.
But yes, starting with a few weeks ago, the crash reports including bits
and pieces of user memory that can contain everything including very
private information is being sent to and handled in Amazon-hosted systems.

KaiRo

[Andrew Sutherland]

On Thu, Jan 15, 2015, at 04:28 PM, Robert Strong wrote:
> I am fairly certain I could disable cookies on the client side to work
> around this and make it an option for each app since some apps will
> likely
> want cookies. I'd much prefer it if this was done on the server and
> thereby
> avoid more client code / complexity. If you are referring to testing the
> server that test would need to be outside of build tests of course.

I'm not sure which you're referring to in regards to client complexity,
but note that Firefox OS ended up adding "mozAnon" to XMLHttpRequest to
allow requests to avoid sending cookies/auth headers. Even if the ping
doesn't use XHR (which does seem to have a native-ish constructor
available?
https://dxr.mozilla.org/mozilla-central/source/dom/workers/XMLHttpRequest.cpp#1639),
it seems likely much of the plumbing could be reused. If you're talking
about the settings stuff, that is of course different.

Andrew

[Robert Strong]

Complexity as in more code and allowing consumers the ability to use
cookies if they want. I'm tempted to just go with no cookies for app update
and consumers can just add any additional details to the url.

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

Robert