476596 - Malware "why is this site blocked" button does not take me to safebrowsing diagnostic page

Status: RESOLVED FIXED

(Camino Graveyard :: Security, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

STR:

1) Visit a malware site (or test site, like http://ianfette.org/)
2) Click "Why is this site blocked?" button

ER: End up on http://www.google.com/safebrowsing/diagnostic?site=http://www.ianfette.org/&hl=en (or some permutation thereof)
AR: End up on http://www.mozilla.com/en-US/firefox/phishing-protection/

The phishing button should end up at the mozilla.com page (until we fix bug 451092), but the malware button should not.

Comment 1

[Christopher Henderson]

Attachment: Fix v1.0

Adds a |showMalwareDiagnosticInformation| method to BWC that sends the user to the Google malware page for the current site. Uses the same Firefox pref name and value (after filling in the placeholders).

Comment 2

[Sean Murphy]

Comment on attachment 374538 [details] [diff] [review]
Fix v1.0

Looks great Hendy, r=me.  Very sorry it took me so long to get to this!

The #import line fails to patch successfully with the latest BWC source.  Since my delay is the reason, I'm attaching a refreshed patch...

Comment 3

[Sean Murphy]

Attachment: Refreshed Patch v1.0

Just refreshed Hendy's patch to fix a failed #import line hunk.

Comment 4

[Christopher Henderson]

Thanks for the review, Sean. Your refreshed patch will apply if the patch for Bug 475201 has been checked in, but it's in and out of the tree. My original patch can be applied when the other patch has not been checked in (which is most of the time at the moment).

Comment 5

[Stuart Morgan]

Comment on attachment 376760 [details] [diff] [review]
Refreshed Patch v1.0

>+  [filledURL replaceOccurrencesOfString:@"{moz:client}"
>+                           withString:[XULAppInfo name]
>+                              options:NULL
>+                                range:NSMakeRange(0, [filledURL length])];
>+  [filledURL replaceOccurrencesOfString:@"{moz:locale}"
>+                           withString:locale
>+                              options:NULL
>+                                range:NSMakeRange(0, [filledURL length])];

The :-alignment needs fixing here.

sr=smorgan with that change (for whichever version). However, if this conflicts with the flashblock bug let's not land this yet, since I don't want to force a respin of that patch to add to all its other woes ;)

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #5)
> sr=smorgan with that change (for whichever version). However, if this conflicts
> with the flashblock bug let's not land this yet, since I don't want to force a
> respin of that patch to add to all its other woes ;)

I've been maintaining an up-to-date version of that patch already, so I'll just update my version to unbitrot it and land this bug; heaven knows the fewer ready patches not landed, the better.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Checked in with the : all lined up.

I'll file another bug (or comment in an existing one, if I can find an appropriate one) about making the phishing "why was this site blocked" URL point somewhere else when we have the somewhere else ready.