662213 - Stop using firefox/its-a-trap.html and firefox/its-an-attack.html

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Mehdi Mulani [:mmm] (I don't check this)]

We plan to remove firefox/its-a-trap.html and firefox/its-an-attack.html from the UrlClassifier DB which would mean that users would see firefox/its-{a-trap,an-attack}.html without warning.

I'm not sure what the exact course of action should be. (i.e. leaving the pages around for old users) My thought was to relocate them to different subdomain to avoid the problem in bug 662046, suggestions are definitely welcome though :)

At the least, we should stop using these links in other places, as they will no longer bring up the warning dialog.

Comment 1

[Doug Turner (:dougt)]

mehdi,

so you want to move:

http://www.mozilla.com/firefox/its-a-trap.html

to some other non-mozilla.com domain, and you want to update everything mozilla.com/* that points to it to point to the new site?

Comment 2

[Mehdi Mulani [:mmm] (I don't check this)]

(In reply to comment #1)
> mehdi,
> 
> so you want to move:
> 
> http://www.mozilla.com/firefox/its-a-trap.html
> 
> to some other non-mozilla.com domain, and you want to update everything
> mozilla.com/* that points to it to point to the new site?

Yes. The page could move to something like testing.mozilla.com but moving to completely non-mozilla.com domain makes the solution clearer.

It would make sense to update everything on mozilla.com/* to point to the new site except old versions of Firefox will still see mozilla.com/firefox/its-a-trap.html as a bad page, so perhaps we need to change the wording on those pages?

Comment 3

[Doug Turner (:dougt)]

mike - who should own this?

Comment 4

[Laura Forrest]

Hi Doug or Mehdi - I'd like to help out here were needed. Can either one of you suggest next steps for this bug?

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Mehdi, I think there's an error in your analysis of bug 662046 and the impact of this is smaller than described.

Landing bug 669410 will eliminate any measurable difference.

If bug 669410 doesn't land, making this change will cause a tiny performance improvement for users hitting mozilla.com the first time, but only potentially in a next Firefox version when the old link is removed from the SafeBrowsing DB.

So it's a tiny thing by now, but maybe good to do anyway. Having stuff on our main website that we ourselves are actively marking as badware could come back to haunt us at some point.

Laura: make a copy of those 2 webpages on a domain that is not mozilla.com and not a xyz.mozilla.com domain that's actively used, relink those pages wherever they are referenced on mozilla.com, and add a redirect from the old pages to the new ones.

I think that should give the correct warning on the old Firefoxes and allow the new ones to take the fast path on mozilla.com.

Comment 6

[mcbmoz]

John and I just discussed during a purge project, so assigning to John - can you help the team understand why we are keeping these pages active. 

Thanks to all for raising excellent points around negative messaging, etc.

~cb

Comment 7

[John Slater]

I'm clearly not up to speed on what's going on with these pages. Last I heard, they were linked to from within the product and thus were very important to keep live. If that's not true, then I don't have any vested interest in whatever happens to them...I just don't want broken links, that's all.

(I'm unassigning myself from ownership of this bug, btw.)

Comment 8

[mcbmoz]

(In reply to John Slater from comment #7)
> I'm clearly not up to speed on what's going on with these pages. Last I
> heard, they were linked to from within the product and thus were very
> important to keep live. If that's not true, then I don't have any vested
> interest in whatever happens to them...I just don't want broken links,
> that's all.
> 
> (I'm unassigning myself from ownership of this bug, btw.)

Thanks John! I think we need to determine the owner for these pages. Assigning back over to Mehdi. 

Fred, any ideas?

Comment 9

[Kevin Brosnan [Ex-Mozilla]]

I know we as QA have several manual tests that rely on having known bad pages. Mozilla.com has http://www.mozilla.com/en-US/firefox/phishing-protection/ and sumo https://support.mozilla.com/en-US/kb/How%20the%20phishing%20and%20malware%20protection%20in%20Firefox%20works

Comment 10

[Fred Wenzel [:wenzel]]

Hm, not sure I understand this yet. Either the pages are still useful, then why don't we keep them where they are? Or they're not useful anymore, then we can remove them -- but we'd need to remove links like the ones mentioned in comment 9 as well.

Who are the "old users" mentioned in comment 0 (i.e., what browser versions are we talking about?) If support has ended for these versions, then I don't see a problem with breaking those links (or redirecting them to some FAQ)--that's what not supporting those versions means, after all.

Comment 11

[Doug Turner (:dougt)]

see comment #1 and the last part of comment #5.


We need to move "its-a-trap.html" to its own domain.


so:

1) think up a neat name, like its-a-trap.com or something.
2) register it
3) move the "its-a-trap.html" file over to that domain
4) remove its-a-trap.html from mozilla.* sites

Morgamic, who should own this now?

Comment 12

[Gian-Carlo Pascutto [:gcp]]

>Last I heard, they were linked to from within the product and thus were very >important to keep live.
....
>I know we as QA have several manual tests that rely on having known bad pages

As explained in comment 5, "add a redirect from the old pages to the new ones.". Firefox versions at least up to 8 will use the old pages, we should not break those yet.

Comment 13

[Fred Wenzel [:wenzel]]

Anthony, thanks for picking this up. If that's the easiest, we can keep it inside mozilla.com and just point the new domain's docroot at that directory -- keep in mind that for this, you'd need to make all the relative URLs absolute.

If that's too dirty, we'll need to make some standalone HTML/CSS, but we'd probably not be able to put a mozilla.com-style download button on there, so the first option seems preferable.

I'm going to file an IT bug to get our domain registered.

Comment 14

[Fred Wenzel [:wenzel]]

Anthony: "itisatrap.org" has been registered. Full steam ahead! :) Anything else you need to make this happen?

Comment 15

[Anthony Ricaud (:rik)]

Created a folder for itisatrap.org. I'm gonna open a bug to get a dev site set up.

Comment 16

[Anthony Ricaud (:rik)]

So I needed a bit more tinkering to get a configuration working on my laptop. Should be ready for testing. Opened bug 681945 to track the setup.

Comment 17

[mcbmoz]

(In reply to Anthony Ricaud (:rik) from comment #16)
> So I needed a bit more tinkering to get a configuration working on my
> laptop. Should be ready for testing. Opened bug 681945 to track the setup.

Ping! Hey Anthony can you provide an update?

Comment 18

[Anthony Ricaud (:rik)]

We're waiting on bug 681945 now.

Comment 19

[Matthew N. [:MattN]]

Note that the transition from mozilla.com to mozilla.org means that these pages are now visible without attack warnings if the user navigates directly to .org ie. though a google search.  This may lead users into thinking that the safe browsing service is not working. See https://www.mozilla.org/firefox/its-a-trap.html

What's the ETA for the new domain to be up and running?  If it's going to be a while then maybe we should update the UrlClassifier database to reflect the mozilla.org domain.

Comment 20

[mcbmoz]

Hey Anthony, can you give an update on this bug. I noticed that part of the problem seems to be fixed over in bug 681945

Comment 21

[Anthony Ricaud (:rik)]

Chrissie: We are closer to get the test servers set up but not there yet. It's in IT hands.

Matthew: It's not clear to me if the UrlClassifier is tied to a Firefox release. If it's just an online database, it would be good to update it.

Comment 22

[Gian-Carlo Pascutto [:gcp]]

>Matthew: It's not clear to me if the UrlClassifier is tied to a Firefox release. 
>If it's just an online database, it would be good to update it.

The test pages are forcefully inserted into the database at the moment Firefox starts up, so this has to be fixed in the code. I will make a bug for this.

Old Firefoxes that navigate to mozilla.org/firefox/its-a-trap.html directly will never get the warning.

Comment 23

[Gian-Carlo Pascutto [:gcp]]

>What's the ETA for the new domain to be up and running?  If it's going to be a 
>while then maybe we should update the UrlClassifier database to reflect the 
>mozilla.org domain.

Tracking this in bug 693389.

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I don't see that the itisatrap.org website will cover both the its-a-trap and its-an-attack pages. Can you please clarify what the real goal is for this single domain is and how we can cover the other page?

Comment 25

[Gian-Carlo Pascutto [:gcp]]

The new domain (whatever the name) should contain both pages. The goal for it is that it avoids pages marked as malware/phishing sharing a domain with our real content pages.

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks for the clarification Gian-Carlo.

Comment 27

[Doug Turner (:dougt)]

This bug is no longer urgent from our side, but i am depressed that it has taken this much time.  What is going on?

Comment 28

[John Slater]

(In reply to Doug Turner (:dougt) from comment #27)
> This bug is no longer urgent from our side, but i am depressed that it has
> taken this much time.  What is going on?

Anthony, can you update?

Comment 29

[mcbmoz]

Anthony, ping, can you provide an update on where you are with this bug?

Comment 30

[mcbmoz]

Anthony, we would like this in the 4.7 release. If it's not possible, please update in the bug as to why and the steps you will take to get it into X.X release (fill in with the release).

Comment 31

[mcbmoz]

Moving to 4.8, Anthony, please update with status and if you can't make it into 4.8, please reassign to James or Steven.

Comment 32

[Anthony Ricaud (:rik)]

To make this easier to deploy and have no relation to the mozilla.org codebase, I'm gonna create a static copy of these pages. This can be done in 4.8 but the deployment may not be done in 4.8.

Comment 33

[mcbmoz]

(In reply to Anthony Ricaud (:rik) from comment #32)
> To make this easier to deploy and have no relation to the mozilla.org
> codebase, I'm gonna create a static copy of these pages. This can be done in
> 4.8 but the deployment may not be done in 4.8.

Thanks Anthony! Let's do a check-in on Monday, before 4.8, and figure out next steps for deployment.

Comment 34

[mcbmoz]

Anthony, did this make it into the release yesterday? Can you provide an update?

Comment 35

[Laura Forrest]

If the work has been done, let's get this live. 

Anthony - please comment and explain next steps.

Comment 36

[Anthony Ricaud (:rik)]

The work was done on my part last Friday. We need IT to setup the site which is tracked by bug 681945. Maybe I'll have to do a few tweaks to the code during the setup but that shouldn't be the case.

Comment 37

[Kadir Topal [:atopal]]

Can we get an update on this? Looks like bug 681945 is fixed.

Comment 38

[Gian-Carlo Pascutto [:gcp]]

The real site https://bugzilla.mozilla.org/show_bug.cgi?id=710597 is still nowhere to be seen, so I can't update the DB.

Comment 39

[mcbmoz]

@atopal @gcp just pinged Jake to update Bug 710597 with a status, so we can update over here too. Thanks for touching base.

Comment 40

[Laura Forrest]

I'm moving this to "future" for now to help us track our weekly releases better, but please put back into a milestone once action from the Web Team is needed. 

Thanks!

Comment 41

[Anthony Ricaud (:rik)]

Yeah, the website is live.