bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.
VERIFIED FIXED

Status

www.mozilla.org
General
VERIFIED FIXED
11 years ago
6 years ago

People

(Reporter: dcamp, Assigned: sgarrity)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
The malware detection feature flags http://www.mozilla.com/firefox/its-an-attack.html as malware, similar to the its-a-trap.html for safebrowsing.  We should probably have content there for non-ffx3 browsers.

Reed mentioned disabling the redirects for this page.  The malware protection will block redirects from a flagged page, so it might not be necessary to do that.
I took the its-a-trap page and modified a couple of things just for playing around. It's only on the trunk for now. Over to Steven to come up with a much better version of the page and new images, etc. pkim, I guess we'll need /firefox/malware-protection/ like we have /firefox/phishing-protection/?

Sending        trunk/.htaccess
Adding         trunk/en-US/firefox/its-an-attack.html
Transmitting file data ..
Committed revision 6643.
Assignee: nobody → steven
Duplicate of this bug: 396543
Pascal brought up a good point in Bug 396543 - why is this not a localized page?  Meaning, why isn't it using the /$locale/firefox/its-an-attack.html structure?
(In reply to comment #3)
> Pascal brought up a good point in Bug 396543 - why is this not a localized
> page?  Meaning, why isn't it using the /$locale/firefox/its-an-attack.html
> structure?

It can't be localized because "http://www.mozilla.com/firefox/its-an-attack.html" is hardcoded into Firefox as a test page, and if that page redirects to another site, that new site will not be detected as the same page. Also, dcamp has mentioned that the malware blocking code stops redirects from happening, so that's another strike against localized versions of the page.
Yeah, my question was more "why are we hardcoding that string into firefox instead of a localized version?"  but it might be too late for that now.
I think reed's second point is the kicker.  Malware blocking doesn't let redirects slip past, since that would be an easy way to avoid blacklists - spam a URL and then redirect to some randomized-DNS.  We might do some kind of once-off magic on the actual page (JS localization, anyone?) but it feels like the typical locale-based-redirect approach will fail here (unless we yank the current entry page from the blacklist, and instead add the 50 localized landing pages instead).
if we can't change the location, this page should be served uncached with PHP localization and not javascript
The original comment says "we should probably have content there" and we do so I'm resolving this.  If someone wants to talk about l10n we can do that in another bug.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
What clouserw said: verified FIXED
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
Product: Websites → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.