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
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 firstname.lastname@example.org 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
(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.
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).
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.