401645 - No longer possible to report an erroneously labeled phishing site

Status: RESOLVED DUPLICATE of bug 441624

(Toolkit :: Safe Browsing, defect, P4)

Description

[Bill Gianopoulos [:WG9s]]

Subject says it all.

Comment 1

[Mike Connor [:mconnor]]

Not going to continue to block on this, please renominate with reasons why we can't ship with this in final

Comment 2

[Reed Loden [:reed]]

Do we really want to make it impossible for users to report errors with the phishing/malware database? This seems like a large regression from Firefox 2... If google were to screw up something, how would they get reports that the affected site shouldn't be in the blacklist?

Comment 3

[Johnathan Nightingale [:johnath]]

(In reply to comment #2)
> Do we really want to make it impossible for users to report errors with the
> phishing/malware database? This seems like a large regression from Firefox 2...
> If google were to screw up something, how would they get reports that the
> affected site shouldn't be in the blacklist?

That's not the situation we're in, here.  The "This site is not a Web Forgery" menu item still exists on phishing sites, and the "request a review" link in the malware error page text accomplishes the same goal there.

What's missing is a "This site is not a web forgery" link in the *phishing* error case, which should be a relatively simple, low risk change, but I agree with the assessment that it is not blocking. 

Comment 4

[AndrewM]

If it's decided not to implement the 'This site is not a web forgery link' in the phishing error page in time for Fx 3, how about adding text like this:

'Web site owners who believe their site has been reported as a phishing site in error may request a review by clicking Help > This isn't a web forgery...'

It's not very discoverable otherwise.

Comment 6

[Ian Fette (Google)]

I think this is actually Bug 415846 (which I would really like to see fixed...)

Comment 8

[John Barberio]

Quote from http://www.microsoft.com/windows/windows-vista/features/IE7-anti-phishing.aspx - "You can report any phishing sites or false positives to the Phishing Filter right from your browser."

I think anything that makes FF more annoying than IE7 is a bad thing.

Comment 10

[John Barberio]

From discussion in the duplicate bug, it appears that Google's diagnostic pages are currently not being updated. Coupled with Bug 435726 preventing viewing source, it gives the impression of their being false positives when there aren't. And results in a lot of user confusion. Firefox should probably try to give a more detailed reason for why the site was blocked.

Comment 11

[Ian Fette (Google)]

This is still a problem. In FF3 and later, if you go past the interstitial you can effectively no longer report a false positive. There is a "report phishing" link instead of a "report error" link. Can this please be addressed? We're seeing a lot of users who are reporting false positives as false negatives, and this is an issue for users.

Comment 12

[Samuel Sidler (old account; do not CC)]

I hear Shawn is working on safebrowsing code... Shawn can you take a look at this?

Comment 13

[Ian Fette (Google)]

Sorry, just to follow up I was looking at FF3.0.11 - in 3.5 this appears to be fixed by adding buttons to the red bar at the top. So all I can say is good luck on getting 3.5 out of the door soon :)

Comment 14

[Shawn Wilsher :sdwilsh]

(In reply to comment #12)
> I hear Shawn is working on safebrowsing code... Shawn can you take a look at
> this?
Do we actually want to bother making a branch patch for this if it's fixed in 3.5 and that's due our RSN?

Comment 15

[Ian Fette (Google)]

Depends -- how aggressive are you going to be with the 3.5 upgrade? If you expect most users to be on 3.5 within 1-3mo then I would say probably not. If it's going to be a longer upgrade cycle, then if it's not a huge chunk of code to port over I would appreciate it, but not complain (too loudly) if that didn't happen.

Comment 16

[John Barberio]

It's considered good practice to backport security related fixes to 'old' versions that are expected to still be used. It's not uncommon at all for people to not upgrade to the 'latest and greatest version', or take their time in upgrading. For instance if there's functionality they use that isn't working in the new version yet.

Comment 17

[Shawn Wilsher :sdwilsh]

(In reply to comment #16)
> It's considered good practice to backport security related fixes to 'old'
> versions that are expected to still be used. It's not uncommon at all for
> people to not upgrade to the 'latest and greatest version', or take their time
> in upgrading. For instance if there's functionality they use that isn't working
> in the new version yet.
This isn't a security fix, but more of a nuisance fix.  We also generally have most of our users updated to the latest release quite quickly.

With that said, knowing which bug fixed this for 1.9.1 would be helpful.

Comment 18

[Johnathan Nightingale [:johnath]]

I fixed this in bug 441624, but I don't think we should take it on 1.9.0 since it adds several strings, changes behaviour, and we're about to have the improved version out there anyhow.

Comment 19

[Samuel Sidler (old account; do not CC)]

You had me at "strings".

I think this can be resolved as a DUPE of bug 441624 or FIXED by it. The 1.9.0.x version of it is WONTFIX. We'll just promise to ship 3.5 to our users as fast as possible (oh, hey, that's what we always promise!).

Comment 20

[Shawn Wilsher :sdwilsh]

I agree!