1078098 - Clarify bugzilla.mozilla.org Privacy Policy

Status: RESOLVED FIXED

(Privacy Graveyard :: Privacy Policies, task)

Description

[Mark Côté [:mcote]]

tl;dr We should formally agree upon and record the reasoning behind the current, de facto BMO privacy policy, which is to hide email addresses from unauthenticated users in the HTML UI but to expose them publicly via Bugzilla's standard WebServices.

One source for the current BMO de facto policy is the account-creation page[1], which has "three things to know and do".  Item 2 says "Bugzilla is a public place, so what you type and your email address will be visible to all logged-in users".  This statement is at best vague, if not misleading.

Stating that data "will be visible to all logged-in users" implies, although admittedly does not openly state, that said data will *not* be visible to unauthenticated, that is, anonymous, users.  For email addresses, this is partly true.  The UI (HTML) does not display email addresses unless you are logged in.  The various WebService APIs (XMLRPC, JSONRPC, REST) *do*, however, return email addresses to anonymous users.

The part about "what you type" is nonsensical; comments make up the bulk of what users "type", and they are visible to both logged-in and anonymous users (unless they are confidential, which is rare).  The main difference between being logged into a basic account and being anonymous is that emails are hidden from anonymous users (at least in user fields; nothing stops someone from writing an email address into a comment or other free-form field).

There is also a Privacy Policy link in very small letters at the bottom of every BMO page which leads to Mozilla's "Websites, Communications & Cookies Privacy Notice"[2].  The "Contributors" section of "Things you should know" states that "If you contribute to Bugzilla, Mozilla Reps, or our code base, then your email address and possibly your name will be publicly available to all internet users".  Later it says "If possible, we try to minimize contact information that is publicly displayed."  That's accurate, if general, and is essentially what we do on BMO.

What's not clear is the specific reasoning behind why we hide emails in the UI but not via the WebService APIs.  The fact that they are visible via WebServices was filed as bug 520448 on 2009-10-04; it was resolved INVALID with the reasoning (from Max Kanat-Alexander, a Bugzilla Assistant Project Lead at the time) "I believe the entire API system leaks emails when you are not logged in, which is intentional. I'm not aware of any spammer's spiders which can read API documentation."  Thus it appears that the main reason we hide addresses in the UI is to avoid dumb email-scraping spammer bots; we are not concerned with trying to stop scripts specifically designed to extract emails via the WebService APIs.  I think this reasoning is sound, since anyone can create a Bugzilla account if they have an email address, and the latter are easy enough to obtain that this is not a real impediment to a Bugzilla-specific email-scraper script.  If, however, this thinking has changed in the last five years, then we should address that, both in policy and in code.

I don't know if this belongs in the Mozilla Privacy Notice, or on the BMO account-creation notice, or in a new specific BMO privacy policy, but I think we should be upfront with our reasons, in part because it's useful as a guide to designing Bugzilla extensions and third-party tools (such as Review Board; see bug 1058786).  Lastly, Max was not, to my knowledge, a Mozilla employee, and BMO, unlike the upstream Bugzilla code and website, and despite hosting bugs for the project, is clearly a Mozilla property, so this should get sign off from someone in Mozilla's legal department.

Regardless of what we do here, BMO's account-creation page really needs to be cleaned up.  I'll file that separately, to be done after we have agreement on the above.

[1] https://bugzilla.mozilla.org/createaccount.cgi
[2] https://www.mozilla.org/en-US/privacy/websites/

Comment 1

[Merwin]

Mark,

Laura flag this for me yesterday.  Can you guys put your head's together and give us an assessment of whether the email access through the WebServices API should be different than the UI?  There are two issues here: 1) whether the threat model is different between the two and 2) whether there is any added value in allowing emails to be public for the API.  Putting aside the threat question, we should only make these available to individuals who are not logged in if there is a good reason to do so. I'm inclined to think that, given recent concerns with the availability of personal information in Bugzilla, the policy should be consistent across both and should require that users be logged in.

If you guys give us that assessment, we can then discuss and decide if changes are necessary to the privacy language.  At a minimum, I think you are correct that the "what you type" language needs to change.

Please grab time on my calendar if you want to discuss.

- Marshall

Comment 2

[David Lawrence [:dkl]]

FWIW, modern versions of Bugzilla (BMO included) can turn on filtering of email addresses in webservice API calls by simply flipping a param in the admin UI. It is different than the UI in the instead of omitting the email address value altogether, it cuts off the address from the @ to the right. So [e-mail] would become dkl. We still include the real name as well. 

I mentioned a while back to glob that we should turn on the param and start filtering and he made the statement (correct me if I am wrong, glob) that we cannot do it suddenly as all clients would still be expecting the full email value to be returned and may cause breakage.

We could, however, give some ample notice far and wide and then in the near future turn on email filtering. We would then be in line with the UI policy as well.

Just a thought.
dkl

Comment 3

[:glob ✱]

(In reply to David Lawrence [:dkl] from comment #2)
> I mentioned a while back to glob that we should turn on the param and start
> filtering and he made the statement (correct me if I am wrong, glob) that we
> cannot do it suddenly as all clients would still be expecting the full email
> value to be returned and may cause breakage.

this is true; it would break some things in a way that would be difficult/impractical to work around.
i would prefer for us to continue to return full email addresses via the API.

i don't think that changing this setting will deter anyone from harvesting emails from bugzilla.  we allow anyone to create an account, so there's next to no barrier presented to someone who wants to use the api to scrape for email addresses.  ie. we'd be breaking clients for no net gain.

Comment 4

[Mark Côté [:mcote]]

Indeed, while I cannot give a bulletproof reason for why we should leave emails in unauthenticated API access, I *can* give a specific reason for why they are not in the UI: spam bots can easily harvest them.  It is extremely unlikely that a generic email-harvesting bot would be able to get them from the API; they would undoubtedly have to be specially crafted to do this.  And if somewhere were to do that, which admittedly requires nothing other than reading the API docs, it would be no harder (in fact, probably easier) to create a BMO account and just have the HTML-scraping bot log in first.  So from the point of email harvesting through generic bots, for spam or other reasons, there is effectively 0% more risk in having emails returned to unauthenticated API users than not.

I also don't want to say that breaking apps that rely on unauthenticated access to emails is a show-stopper; we have broken apps in the past and will again if necessary.  What I *do* want to be perfectly clear on is the rationale behind hiding them in the API, if we were to go that route, and I want to avoid any false pretenses of anonymity.  If it's trivially easy (as it is) to create a BMO account and grab addresses, hiding them from unauthenticated API access effectively does nothing aside from improve consistency and possibly buy us some PR.  That said, I do not discount the value in good PR (and the harm of bad).

Comment 5

[Merwin]

Looping back around on this. In sum, there is no added value to anonymizing the emails for unauthenticated users (where as there is value to anonymizing them in the UI) and changing this now would break some things. This would weigh in favor of the current approach. I'm fine with that. Mark, as the "data steward" for Bugzilla, can you sign off on that?

The Privacy Policy accurately describes what is happening with the API, so no changes are necessary there.  The language on the account creation page does need to change however to accurately reflect what is occurring with the API.

Comment 6

[Mark Côté [:mcote]]

Yup, that sounds good.  We'll keep functionality as it is right now: emails are not shown in the UI to anonymous/unauthenticated users, but they'll be present in API responses, for both anonymous and authenticated users.  I also agree that the current Privacy Policy is in line with this; as I previously mentioned, it's general, but the place to be more specific is in on the account-creation page, which I'll fix up soon.

Thanks for your input!