Currently, reportURL for phishing and malware tables both points to Google. For addition of new tables from extension, we should be able to assign reportURL per-table (including maybe disable report feature if the data provider doesn't have a user facing page for this).

I think the problem here is that reportURL doesn't actually properly work per table. People will report sites that aren't blacklisted yet so they have no corresponding table. If we support multiple malware/phishing providers I think our only option is to set up our own page and then have a backend that handles the submissions to all our list providers.

I think that's right. Fortunately it is already redirecting through us so no client changes will be needed.

Doug, do you know who could own the Mozilla-webserver-side of this?

We would need to ask a favor from either Sylvie V's team (IT) or Mark Mayo (cloud services).

Alternatively, we could get a PM from Mark's team (Bill Maggs) or platform (Martin Best) to wrangle everyone for us.

Over to sworkman for triage.

Francois, do you know who from Services could look at this? (Assuming comment #2 is right).

If you're looking for someone to build a service to collect and aggregate reports from users, then you should probably talk to Toby.

Toby, flagging this with you.

Can we do a quick meeting to make sure I understand exactly what we need? My calendar is up to date.

Not a super high priority right now. Let's circle back around Nightly 43/44. Thanks Toby!

Until we have multiple phishing/malware providers, we don't need this.

WONTFIX implies the bug will never be fixed (and a patch to do so would be rejected immediately). I do not think that's the case here. For one, your comment starts with "Until..." which is quite different from "never".

(In reply to Gian-Carlo Pascutto [:gcp] from comment #13) > WONTFIX implies the bug will never be fixed (and a patch to do so would be > rejected immediately). I do not think that's the case here. The other issue (which the new title should highlight) is that this is ultimately a bug about creating a new cloud service to receive reports from users and forward them on to Safe Browsing providers. It doesn't really fit in this Product/Component.

After talking to Hector, it turns out that what we need is a way to expose the table/provider that caused the interstitial page to show up. This will also be useful if we implement the opt-in URI reporting to Safe Browsing providers.

The support for this was added as part of bug 1366384.