Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Norton Internet Security Toolbar conflict #57

Closed
jsamuel opened this issue Dec 22, 2011 · 4 comments
Closed

Norton Internet Security Toolbar conflict #57

jsamuel opened this issue Dec 22, 2011 · 4 comments

Comments

@jsamuel
Copy link
Member

jsamuel commented Dec 22, 2011

imported trac ticket
created: 2009-12-01 09:02:57
reporter: justin

A user reports:
repeatable conflict between RP v 0.5.12 and Norton Internet Security 10.1 v 17.1.0.19. RP v 0.5.8 did not produce the conflict....only since RP update to v 0.5.12 has conflict been observed. Upon update install for RP the NIS Tool Bar vanishes. Upon disable RP NIS Tool Bar is stable. Tried "temp allow on startup" which appeared to be reasonable work around. Until, I came across a site that prompted Tool Bar to vanish. I tried "allow all requests" with this site and info did not populate to white list.

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2011-01-07 13:40:02
author: justin

Using Fx 3.6.13, I installed a norton 360 trial which added an extension called "Norton IPS" (version 2.0) to Firefox. This didn't seem to have a toolbar with it.

Poking around more, it looks like Norton has a separate, free toolbar addon called "Norton Safe Web Lite" available at http://safeweb.norton.com/lite?MKTG_SEMID=1. This does indeed install a toolbar that !RequestPolicy causes some breakage with, though the toolbar doesn't disappear entirely.

Here's what I've seen so far when using RP with this toolbar:

  • The Norton icon is missing from the toolbar.
  • The toolbar made a handful of blocked requests of the form "symnst:..." -> "symnst:...", for example "symnst:ToolbarTemplate.css" -> "symnst:$norton_tb_mm_btn_pressed.png"
  • The toolbar's search box seems to be an ask.com search box where the results page makes requests to "symnst:" resources, for example "http://www.ask.com/web?q=test&o=15527&l=dis&prt=SWL&chn=&geo=US&ver=1" -> "symnst:sb_safeannotation.png"
  • The toolbar also "annotates" search results from other search engines such as google even when searched directly. Similar blocked destination URLs occur as with the ask.com search box in the toolbar itself. These blocked destinations appear to be icons for "OK" or "?" shown next to each search result.

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2011-01-07 14:01:19
author: justin

I opened IE and there was only the toolbar for "Norton Safe Web Lite". There was no separate toolbar for their intrusion prevention system (Norton IPS). So, I'm not going to be able to repeat the exact bug the user ran into without their exact product installed, which I don't have access to (I can't seem to easily locate a free trial of it).

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2011-01-07 14:36:41
author: justin

Extension IDs for these two extensions according to the "Extension List Dumper" extension:

  • Norton IPS 2.0
    {BBDA0591-3099-440a-AA10-41764D9DB4DB}
  • Norton Safe Web Lite Toolbar 1.2.0
    {203FB6B2-2E1E-4474-863B-4C483ECCE78E}

@jsamuel
Copy link
Member Author

jsamuel commented Dec 22, 2011

imported trac comment
created: 2011-01-07 15:12:38
author: justin

Fixed in r386. When "Norton Safe Web Lite Toolbar" is detected, all requests to "symnst:" are allowed. Tested on Windows 7 with Fx 3.6.13 and Fx 4.0b8. I think there may be some room for a race condition with Fx 4 because of the async !AddonManager functions. That is, I don't believe there's any guarantee that we'll have enacted the compatibility rules before requests for the toolbar's graphics are performed. If this is a problem for this toolbar, we'll probably run into it with other extensions at some point and so will need a more general solution. For now, this approach seems to work fine. If this comes back up, we can instead assume the extension is installed initially and then remove the compatibility rules once we determine it is not installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant