1008882 - "ignore this warning" for a phishing/malware site persists for the rest of the session

Status: RESOLVED INVALID

(Toolkit :: Safe Browsing, defect)

Description

[Petruta Horea [:phorea], Desktop Test Engineering]

Reproducible on:
- Firefox 30 beta 3 - 20140508121358
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
- latest Aurora 31.0a2 - 20140511004003
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
- latest Nightly 32.0a1 - 20140511030203
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0

Steps to reproduce:
1. Open the malware test page: http://www.itisatrap.org/firefox/its-a-trap.html
2. Select the "Ignore this warning" option -  the page content is displayed
3. From the infobar warning select the "Get me out of here!" option - home page is opened
4. Press browser's "Back" button - the previous page is re-opened

Expected results:
The infobar warning reappears to indicate that the page isn't safe.
or
The website is no longer loaded.

Actual results:
The website is loaded and the infobar warning is no longer shown.

Notes:
1. The issue is not a regression, it reproduces on Nightly 30.0a1 2014-03-08
2. The issue also reproduces on Mac OSX 10.8.5 and Ubuntu 13.10 32-bit

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

Monica - this one too, we've had a couple regressions found in FF30 beta testing, hopefully you're a good person to start the ball rolling on getting assignees for these.

Comment 2

[[:mmc] Monica Chew (no longer reading bugmail)]

Petruta, this appears in FF 29 release on Mac with the FF 29 test site: http://www.mozilla.org/firefox/its-an-attack.html

Are you sure this is a regression? Adding gcp, who might know more. These links were last touched in https://bugzilla.mozilla.org/show_bug.cgi?id=971240.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

The original comment already says it's not a regression - I guess you misread it?

These are probably long-standing bugs on the UX/XUL side.

Comment 4

[Petruta Horea [:phorea], Desktop Test Engineering]

Sorry, I only searched the regression range since the date bug 971240 landed. The earlier versions (FF 20) are displaying the warning on http://www.mozilla.org/firefox/its-an-attack.html (/its-a-trap.html) pages, but when the "Ignore this warning" option is selected, the pages are redirecting to http://www.itisatrap.org/firefox/its-a-trap.html.
That happens from FF 20 to FF 29.

From FF30 to FF32 - the mozilla.org pages are automatically redirected to itisatrap.org (from bug 971240)

Considering this, the current issue reproduces back to Firefox 20.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

This seems like fundamentally the same issue as bug 1008857.

The "load this site anyways" link just triggers a single load of the blocked page with LOAD_FLAGS_BYPASS_CLASSIFIER. I don't understand how that is causing subsequent loads to also bypass the classifier. I thought perhaps the cache might be causing this, but clearing the cache doesn't seem to fix it.

This isn't a regression (I can reproduce in Firefox 29) so I don't think we need to track it.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Alternative STR:
- visit http://www.itisatrap.org/firefox/its-a-trap.html
- click "ignore this warning" (-> phishing page loads normally)
- load http://www.itisatrap.org/firefox/its-a-trap.html in a new tab

Expected: page blocked, phising warning page
Actual: phishing page loads normally

Comment 7

[Gian-Carlo Pascutto [:gcp]]

The behavior in the topic is by design:
http://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#2628

Monica remarked on IRC that "get me out of here" (as in the STR) should probably be taken as a hint that we should not persist the unblock, but right now it doesn't do anything besides going to the homepage:
http://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#2687

Comment 8

[[:mmc] Monica Chew (no longer reading bugmail)]

Steve is working on fixing caching channel classifications in bug 1054572. From my reading of the the bypass in nsDocShell, I think that there is no further change needed to http2 caching because on bypass, channel classifier gets skipped entirely. However, I'm just flagging him here in case I'm wrong and something does come up.

Comment 9

[François Marier [:francois]]

The bypass is stored (for the duration of the session) in the permission manager for the whole domain.

So as far as I can tell, this is working as intended.