This bugzilla issue, part of Bug 1540175, has the following goals:

• create the new WebComponents that implement the abuse reporting UI (based on the UX design https://mozilla.invisionapp.com/share/SAQVI963UPX)

• integrate the abuse report WebComponents into the about:addons page (e.g. add a "Report" action in the "list addons" item options to start a report flow for that addon, as shown in this UX design screen: https://mozilla.invisionapp.com/share/SAQVI963UPX#/screens/350753161, and the small post-"abuse report submittion" banner as shown in: https://mozilla.invisionapp.com/share/SAQVI963UPX#/screens/350753167)

• integrate submission of the abuse reports to the AMO API

Hi Philip,
while working on implementing the abuse report UI based on the UX designs, I noticed that none of the screens is currently showing where the "suggestions" (additional content related to some of the abuse report "reasons") should be made visible to the user.

Based on the text included in the document that lists the content for this panel (reasons, examples and suggestions), my guess is that the user should see the suggestions before the report submission (because the texts seems to provide details about what the user should do before or instead of reporting an abuse) and so in the meantime I opted to made it visible in the panel "submission mode" right above the textarea, but I wanted to explicitly double-check this with you.

The attached screenshot shows how one of these suggestions currently looks like in UI currently implemented in the patch attached to this bug.

Besides the above scenario, there are also a couple of other scenarios that are not currently explicitly part of the screens from the UX design and I was wondering how we want to handle them:

• in case of an error received during the submission to the AMO server (e.g. because of connection issues, or an error received from the server), how/where in the panel should the error message visible to the user?

• the abuse report panel looks like a "modal" for the "about:addons" page but not for the entire Firefox instance, and so it doesn't prevent the user from interacting with the rest of the Firefox UI. I was wondering: what if the user tries to start a new abuse report flow while an abuse report panel is still opened for a previously started abuse report? what would be a reasonable way to handle this scenario from a UX perspective?

Hi Joni,
for the attached patch we will need the following SUMO pages to be redirected from the url formatted as ""https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/":

• reporting-extensions-and-themes-abuse
• change-your-default-search-settings-firefox
• customize-firefox-homepage

Thanks in advance for your help

In answer to your questions:

• Perfect place to show the "Suggestions" copy. Sorry I hadn't mocked that up for you.

• My first instinct would be to show the error at the top of the modal, using our message bar component from the design guide: https://design.firefox.com/photon/components/message-bars.html

• Ideally, the user would start where they left off: If I had started the flow on one tab and filled in a bit of text in the "Describe..." field, stopped, and restarted on a new tab a few minutes later, I would hope that the text would be there waiting for me. But, that might not be ideal for a number of reasons! So... I'm not sure. New tab, start from scratch? Or new tab, continue from where you left off? What's possible?

(In reply to Luca Greco [:rpl] from comment #3)

Hi Joni,
for the attached patch we will need the following SUMO pages to be redirected from the url formatted as ""https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/":

• reporting-extensions-and-themes-abuse
• change-your-default-search-settings-firefox
• customize-firefox-homepage

Thanks in advance for your help

Sure, we've already set up redirects, so I think they might already be linked from somewhere in the UI. Do you want to use these same ones or do you want brand new ones? There's no downside on our end, so it's up to you.

• https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/reporting-extensions-and-themes-abuse
• https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/prefs-search (redirects to change-your-default-search-settings-firefox)
• https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/activity-stream (redirects to customize-firefox-homepage)

Depends on D26906

Depends on D27294

(In reply to Joni Savage ("need info" me) from comment #5)

Sure, we've already set up redirects, so I think they might already be linked from somewhere in the UI. Do you want to use these same ones or do you want brand new ones? There's no downside on our end, so it's up to you.

• https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/reporting-extensions-and-themes-abuse

This one is still failing to redirect for me, the url as formatted by the attached patches is the following one:

• https://support.mozilla.org/1/firefox/68.0a1/Linux/en-US/reporting-extensions-and-themes-abuse

Do you mind to check if for you the above formatted url is redirecting as expected?
(and if you spot anything wrong in the above url)

• https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/prefs-search (redirects to change-your-default-search-settings-firefox)

Thanks, prefs-search sounds ok to me, and it is redirecting as expected too, and so no need to create a new one for this SUMO page.

• https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/activity-stream (redirects to customize-firefox-homepage)

For this one I would prefer to use one that is not named "activity-stream" (also this one wasn't redirecting for me when I tried it), let's create a branch new (e.g. named customize-firefox-homepage or prefs-homepage).

This patch contains a new jsm file which provides some helpers to be used for the
abuse report submission in the UI components related to abuse reporting,
and a new xpcshell test that unit test these helpers.

Forgot to add back the needinfo on comment 8.

As part of the addon abuse report submission request parameters (see https://addons-server.readthedocs.io/en/latest/topics/api/abuse.html#post--api-v4-abuse-report-addon-) the (hashed) client ID should be submitted.

:gfritzsche, are we okay with this? Do we need to get approval from data stewards or legal on this?

We as a team don't have an opinion on this, but the data stewards or policy owners might.
Chris, as a data steward, do you have input here?

All new or changed Data Collections require Data Collection Review. This is especially needful if we're using identifiers, or are allowing users to provide free text that we will then collect.

I don't see a bug under the meta bug 1540175 where Trust is involved in a discussion or Data Collection Review is being tracked. :rpl, can you ensure that this happens?

(In reply to Luca Greco [:rpl] from comment #8)

• https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/reporting-extensions-and-themes-abuse

This one is still failing to redirect for me, the url as formatted by the attached patches is the following one:

• https://support.mozilla.org/1/firefox/68.0a1/Linux/en-US/reporting-extensions-and-themes-abuse

Do you mind to check if for you the above formatted url is redirecting as expected?
(and if you spot anything wrong in the above url)

We had a trailing space in our entry which I've corrected. The same URL you have should work now. Let me know if it isn't.

• https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/activity-stream (redirects to customize-firefox-homepage)

For this one I would prefer to use one that is not named "activity-stream" (also this one wasn't redirecting for me when I tried it), let's create a branch new (e.g. named customize-firefox-homepage or prefs-homepage).

I've created one for https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/prefs-homepage. Let me know if this redirect isn't working for you.

Depends on D27294

Hi Chris,
as we agreed last week over IRC, I'm attaching the data review request for the abuse reporting data collection.

(In reply to Chris H-C :chutten from comment #17)

Comment on attachment 9060107 [details]
data-review-request-bug-1543377.md

Preliminary notes:

The answer to Q2 says "Allowing add-ons to submit abuse reports". I think
that means "Allowing users to submit user reports".

yeah, that's a typo, my apologies.

What is the purpose behind using a hashed client_id? What questions will its
inclusion help you answer?

The hashed client_id will be used to verify if a report is more likely genuine.

Per PRD document:
To verify that an abuse report is genuine, Firefox will send a clientID (hashed) along with the data.
AMO will then call a service to check that there’s telemetry data that verifies the user has had the
add-on installed recently.
...
Unverified reports will still be received and stored, but verified reports will carry more weight
for the admins.

...
Result: datareview-

Please provide the name of someone who will be responsible for this data
collection.

Also, I think we're going to have to get Trust's sign-off on collecting this
data. It's very similar to Crash Reports, and has a clear opt-in story, so
we're almost certainly going to be able to collect it. But I'd like some
clarity about why.

I'm adding a needinfo assigned to David to look into these last two (responsible
for the data collection and Trust's sign-off).

(In reply to Luca Greco [:rpl] from comment #18)

(In reply to Chris H-C :chutten from comment #17)

Comment on attachment 9060107 [details]
data-review-request-bug-1543377.md

Preliminary notes:

The answer to Q2 says "Allowing add-ons to submit abuse reports". I think
that means "Allowing users to submit user reports".

yeah, that's a typo, my apologies.

Q2 was meant to be:
"Allowing users to submit abuse reports"

(In reply to Luca Greco [:rpl] from comment #18)

Unverified reports will still be received and stored, but verified reports will carry more weight 
for the admins.

This doesn't sound very well thought out. If I notice a questionable extension and report it instead of installing it, my report will be taken less seriously since I never installed it?

(In reply to Andrew Swan [:aswan] from comment #20)

(In reply to Luca Greco [:rpl] from comment #18)

Unverified reports will still be received and stored, but verified reports will carry more weight 
for the admins.

This doesn't sound very well thought out. If I notice a questionable extension and report it instead of installing it, my report will be taken less seriously since I never installed it?

Personally I wasn't reading that "verified reports will carry more weight" as something that maps exactly to "unverified reports will be taken less seriously", but I don't really know the details of how the reports are going to be processed and "weighted" on the server side.

It may be useful to needinfo someone involved on the design of the AMO side of this feature (I think Stuart or Mat may be able to give us more details about this).

(In reply to Luca Greco [:rpl] from comment #21)

(In reply to Andrew Swan [:aswan] from comment #20)

(In reply to Luca Greco [:rpl] from comment #18)

Unverified reports will still be received and stored, but verified reports will carry more weight 
for the admins.

This doesn't sound very well thought out. If I notice a questionable extension and report it instead of installing it, my report will be taken less seriously since I never installed it?

Personally I wasn't reading that "verified reports will carry more weight" as something that maps exactly to "unverified reports will be taken less seriously", but I don't really know the details of how the reports are going to be processed and "weighted" on the server side.

It may be useful to needinfo someone involved on the design of the AMO side of this feature (I think Stuart or Mat may be able to give us more details about this).

Verification should mainly be seen as a way to look to improve the signal to noise ratio.

agray -- regardless of the implementation (in this bug), the policy question around collecting this requires approval by Trust (hence the NI for you).

This is the same type of collection that occurs via AMO, just via their client rather than our website.

(In reply to Chris H-C :chutten from comment #17)

Comment on attachment 9060107 [details]
data-review-request-bug-1543377.md

Preliminary notes:

The answer to Q2 says "Allowing add-ons to submit abuse reports". I think
that means "Allowing users to submit user reports".

What is the purpose behind using a hashed client_id? What questions will its
inclusion help you answer?

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for

the ultimate data set available publicly, complete and accurate?

Yes. This collection is documented in the addons server documentation:
https://addons-server.readthedocs.io/en/latest/topics/api/abuse.
html#submitting-an-add-on-abuse-report

Is there a control mechanism that allows the user to turn the data

collection on and off?

Yes. The user is free to not submit an abuse report.

If the request is for permanent data collection, is there someone who

will monitor the data over time?

No one is mentioned as being responsible for the data that will be
collected. datareview-

Using the category system of data types on the Mozilla wiki, what

collection type of data do the requested measurements fall under?

Category 4, Highly Sensitive. This report contains a free-form text field of
contents that the user provides. This might include any information at all.

Is the data collection request for default-on or default-off?

Default off. Users must opt in.

Does the instrumentation include the addition of any new identifiers?

Yes. The hashed client id is, I think, new.

Is the data collection covered by the existing Firefox privacy notice?

I think so, but I'm not sure.

Does there need to be a check-in in the future to determine whether to

renew the data?

No. This collection has no expiry mechanism.

---

Result: datareview-

Please provide the name of someone who will be responsible for this data
collection.

After discussing with David about this, the responsible for the data collection should be:

• Stuart Colville
  (because the data collection is part of the services provided by AMO).

Also, I think we're going to have to get Trust's sign-off on collecting this
data. It's very similar to Crash Reports, and has a clear opt-in story, so
we're almost certainly going to be able to collect it. But I'd like some
clarity about why.

As an additional correction from what specified in the data review request:

• message (The body/content of the abuse report) is now optional when a reason property is specified

And I didn't explicitly mentioned in the data review request that the textarea where the user may
type the value for the "message" property has the following text as a placeholder:

Note: Don’t include personal information (such as name, email address, phone number, physical address).
{ -vendor-short-name } keeps a permanent record of these reports.

(In reply to Luca Greco [:rpl] from comment #24)

As an additional correction from what specified in the data review request:

• message (The body/content of the abuse report) is now optional when a reason property is specified

and the reports submitted from the integrated abuse report panel always include a reason (and so message
is always optional for reports submitted from the panel integrated into Firefox).

I'm responding for Alicia. This looks ok to me.

https://hg.mozilla.org/mozilla-central/rev/9bee4151da91
https://hg.mozilla.org/mozilla-central/rev/e70459131e5a
https://hg.mozilla.org/mozilla-central/rev/274e9115edf0
https://hg.mozilla.org/mozilla-central/rev/d15c62c6826b

Verified as fixed using Windows 10x64 and macOS 10.14.5 and latest Fireofox Beta and Nightly for both Themes and Extensions using all abuse reporting panels for every abuse report reason.