1210897 - Compatibility History of add-ons is based on the add-on ID not the add-on in the developer's profile

Status: RESOLVED WORKSFORME

(addons.mozilla.org Graveyard :: Developer Pages, defect)

Description

[(no longer active)]

STR:

1. Have user 1 create an extension with id "x@y".
2. Have user 1 submit the extension to AMO, and then remove it from AMO.
3. Have user 2 submit another extension with id "x@y" and submit in to AMO.
4. From the add-on page (example: <https://addons.mozilla.org/en-US/developers/addon/geckoprofiler/edit>) click "Compatibility Reports" (example: <https://addons.mozilla.org/en-US/firefox/compatibility/reporter/jid0-edalmuivkozlouyij0lpdx548bc%40jetpack>)
5. See the full history of the add-on's compatibility including items from what user 1 has done.

This is leaking data from user 1 to user 2 so I'm marking the bug as private.

The problem seems to be that the URL is constructed based on the add-on ID and we don't verify whether the logged in user has the right to see the entries in the table.

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

Compatibility reports aren't considered private, so anyone can find them if they know the add-on ID. We don't publicize them anywhere (I think).

Not sure if this is a real problem. I'd be more concerned if users were posting private information in those reports, but I haven't seen any instances of this.

Comment 2

[(no longer active)]

(In reply to Jorge Villalobos [:jorgev] from comment #1)
> Compatibility reports aren't considered private, so anyone can find them if
> they know the add-on ID. We don't publicize them anywhere (I think).

Is that true?  If I open <https://addons.mozilla.org/en-US/firefox/compatibility/reporter/jid0-edalmuivkozlouyij0lpdx548bc%40jetpack> without having logged in, I get an error page.

> Not sure if this is a real problem. I'd be more concerned if users were
> posting private information in those reports, but I haven't seen any
> instances of this.

Yeah, that's fair.  I'm not sure how severe this is in practice.

Comment 3

[Adam Muntner [:adamm] (use NEEDINFO)]

Anyone have a reason to be opposed to removing the 'Security-Sensitive Client Services Bug' flag?