No longer possible to report an erroneously labeled phishing site

RESOLVED DUPLICATE of bug 441624

Status

()

defect
P4
normal
RESOLVED DUPLICATE of bug 441624
12 years ago
5 years ago

People

(Reporter: wgianopoulos, Assigned: sdwilsh)

Tracking

({regression})

Trunk
Firefox 3 beta3
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 -
wanted-firefox3 +
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)

Details

Subject says it all.
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: --- → Firefox 3 M10
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Severity: major → normal
Priority: -- → P4
Not going to continue to block on this, please renominate with reasons why we can't ship with this in final
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
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?
Flags: blocking-firefox3- → blocking-firefox3?
(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. 
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.
Flags: blocking-firefox3? → blocking-firefox3-
Duplicate of this bug: 444438
I think this is actually Bug 415846 (which I would really like to see fixed...)
Duplicate of this bug: 448103
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.
Duplicate of this bug: 448103
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.
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.
Flags: blocking1.9.0.12?
Flags: blocking-firefox3.5?
I hear Shawn is working on safebrowsing code... Shawn can you take a look at this?
Assignee: nobody → sdwilsh
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 :)
(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?
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.
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.
(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.
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.12?
Flags: blocking-firefox3.5?
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.
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!).
Flags: wanted1.9.0.x? → wanted1.9.0.x-
I agree!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 441624
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.