Noscript blocking Dashlane extension Firefox 50
Noscript blocking Dashlane extension Firefox 50
I've just discovered that the latest Noscript is blocking the Dashlane extension in Firefox 50, causing it to not function at all. If I disable noscript, Dashlane works fine. This just seemed to happen recently, and from my limited investigation appears to be related to ABE blocking local connections. (not super technical )
I've tried the latest dev build and it still fails.
I've tried the latest dev build and it still fails.
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Noscript blocking Dashlane extension Firefox 50
I have this problem too. I disabled all the extensions in the firefox, finally discovered it is NoScript's fault. Finally, disabled the ABE & my password manager is working fine now.
I am using NoScript 2.5.9.1 with FF 50 32-bit. My password manager is sticky password.
PS: Is ABE essential to NS? Are there any repercussions?
I am using NoScript 2.5.9.1 with FF 50 32-bit. My password manager is sticky password.
PS: Is ABE essential to NS? Are there any repercussions?
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Noscript blocking Dashlane extension Firefox 50
Do you get any message from ABE in your Browser Console (Ctrl-Shift-J)?
So, if you disable ABE, now any site can access any resource on your local network.
You will also lose NoScript's DNT implementation. If you want DNT, be sure to turn that feature on in your browser if you haven't already.
By default, ABE is set to block CSRF to your local network. It blocks any requests to your local network that didn't originate from there. i.e. it prevents router tampering, websites playing with your local server(s), connections from websites to your computer, etc.im3or wrote:PS: Is ABE essential to NS? Are there any repercussions?
So, if you disable ABE, now any site can access any resource on your local network.
You will also lose NoScript's DNT implementation. If you want DNT, be sure to turn that feature on in your browser if you haven't already.
*Always* check the changelogs BEFORE updating that important software!
-
Re: Noscript blocking Dashlane extension Firefox 50
If ABE is blocking something, there should be details in the Browser Console (Ctrl+Shift+J), which we can use to help you craft an appropriate rule to allow Dashlane.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Re: Noscript blocking Dashlane extension Firefox 50
What I'm seeing in the log is the following over and over.
With this showing up from time to time as well:
Code: Select all
Firefox can’t establish a connection to the server at ws://127.0.0.1:15674/. (unknown)
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:17896/ <<< about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://127.0.0.1:17896/. (unknown)
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:21953/ <<< about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://127.0.0.1:21953/. (unknown)
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:32934/ <<< about:blank - 1}
Code: Select all
dashlane-extension:Error: Couldn't find the worker to receive this message. The script may not be initialized yet, or may already have been unloaded.
Stack trace:
send@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/worker.js:82:13
sendOrderToJs@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:245:70
sendOrderToAllFrames@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:249:70
KWTabController.prototype.sendOrderToAllFrames@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:665:62
activateDOMNodeInsertedEvents@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:589:64
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:454:94
KWTabsController.getCurrentTabController@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:770:66
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:454:2
notify@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/timers.js:40:9
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Noscript blocking Dashlane extension Firefox 50
Hmm...it seems to be hitting a few different port numbers. For testing, try putting this rule above the existing rule in the SYSTEM ruleset:
Code: Select all
Site 127.0.0.1
Accept GET
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Re: Noscript blocking Dashlane extension Firefox 50
This was happening before FF 50 for Windows. The problem started, actually - this morning, when I was still on prior version of FF. I've been ignoring the FF notifications to update to FF 40 the last couple of days.
So Dashlane stopped working - and, actually, to try to FIX this, I updated to FF 50, which obviously didn't help.
I think I noticed a recent update to NoScript? Currently I have NoScript 2.9.5.1 installed.
If there was just a change to NoScript in the last day, that may be the problem. An update to NoScript seems to have hit at about the same time as a new version of Firefox.
I am running FF 49.0.1 for Mac - and Dashlane is working on that platform with NoScript 2.9.0.14, not sure why it is so far behind.
It might help diagnose matters if the changelog at noscript.net included date/time and not just version number of updates, and/or if there were a straightforward way to tell when NoScript updates on a computer. Let me know if I am overlooking something.
Hope there is a fix soon.
Thanks.
So Dashlane stopped working - and, actually, to try to FIX this, I updated to FF 50, which obviously didn't help.
I think I noticed a recent update to NoScript? Currently I have NoScript 2.9.5.1 installed.
If there was just a change to NoScript in the last day, that may be the problem. An update to NoScript seems to have hit at about the same time as a new version of Firefox.
I am running FF 49.0.1 for Mac - and Dashlane is working on that platform with NoScript 2.9.0.14, not sure why it is so far behind.
It might help diagnose matters if the changelog at noscript.net included date/time and not just version number of updates, and/or if there were a straightforward way to tell when NoScript updates on a computer. Let me know if I am overlooking something.
Hope there is a fix soon.
Thanks.
Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Noscript blocking Dashlane extension Firefox 50
Sorry for the typo. Where I wrote:
I meant FF 50.I've been ignoring the FF notifications to update to FF 40 the last couple of days.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0
Re: Noscript blocking Dashlane extension Firefox 50
this seems to have fixed the issue.Thrawn wrote:Hmm...it seems to be hitting a few different port numbers. For testing, try putting this rule above the existing rule in the SYSTEM ruleset:Code: Select all
Site 127.0.0.1 Accept GET
This started recently, so I'm assuming either the latest Noscript or Firefox.
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Noscript blocking Dashlane extension Firefox 50
I get these:barbaz wrote:Do you get any message from ABE in your Browser Console (Ctrl-Shift-J)?
Code: Select all
[ABE WAN] Detected WAN IP 59.89.130.191
MozSocialAPI injectController: unable to attachToWindow for resource://light_plugin_acf0e80077c511e59ded005056c00008-at-kaspersky-dot-com/data/background/sandbox.html: TypeError: containingBrowser is null MozSocialAPI.jsm:84
Code: Select all
[ABE] < LOCAL> Deny on {GET http://localhost:45872/ <<< http://localhost:45872/, about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://localhost:45872/. (unknown)
[ABE] < LOCAL> Deny on {GET http://localhost:45872/ <<< about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://localhost:45872/. (unknown)
[ABE] < LOCAL> Deny on {GET http://localhost:45872/ <<< about:blank - 1}
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Noscript blocking Dashlane extension Firefox 50
Putting this into ABE options, as suggested, solves it for me too:
The existing rule allows any behavior from local, and denies everything else. This rule apparently allows any GET operation from anywhere to succeed, regardless of source - which seems like it might break a fair amount of ABE protection by allowing some operations to succeed?
Is this a safe thing to allow? What is the nature of typical external attacks on local that ABE is designed to prevent?
Did something change in NoScript, or did something change in a Dashlane update? According to Dashlane changelog, the most recent version of Dashlane for Windows - version 4.6.3 - was released on November 15 - 8 or 9 days before this problem surfaced. My dashlane executables seem to have been updated on or before that date. (The executables are in AppData\Roaming\Dashlane, not in Program Files.)
It's possible that NoScript was changed in advance to try to work around a problem the developers knew was coming in Firefox 50, but FF 50 was released before this problem occurred in NoScript. I was getting notifications to upgrade to FF 50 for a least a day before Dashlane/NoScript broke in FF 49.
I hope that makes sense. Here is a better timeline:
FF 49 - no problem
FF 49 - a day or so ago, I started getting notices to upgrade to FF 50
FF 49 - Dashlane breaks before I upgrade FF. This happened early on 11/23 (Pacific Standard Time)
FF 50 - I upgraded FF to try to fix the problem, but Dashlane is still broken
Then I came here.
Code: Select all
Site 127.0.0.1
Accept GET
Is this a safe thing to allow? What is the nature of typical external attacks on local that ABE is designed to prevent?
Did something change in NoScript, or did something change in a Dashlane update? According to Dashlane changelog, the most recent version of Dashlane for Windows - version 4.6.3 - was released on November 15 - 8 or 9 days before this problem surfaced. My dashlane executables seem to have been updated on or before that date. (The executables are in AppData\Roaming\Dashlane, not in Program Files.)
It's possible that NoScript was changed in advance to try to work around a problem the developers knew was coming in Firefox 50, but FF 50 was released before this problem occurred in NoScript. I was getting notifications to upgrade to FF 50 for a least a day before Dashlane/NoScript broke in FF 49.
I hope that makes sense. Here is a better timeline:
FF 49 - no problem
FF 49 - a day or so ago, I started getting notices to upgrade to FF 50
FF 49 - Dashlane breaks before I upgrade FF. This happened early on 11/23 (Pacific Standard Time)
FF 50 - I upgraded FF to try to fix the problem, but Dashlane is still broken
Then I came here.
Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Noscript blocking Dashlane extension Firefox 50
This looks like a NoScript bug. Thanks for the report
Better ABE exception, if it works, would be -
Better ABE exception, if it works, would be -
Code: Select all
Site 127.0.0.1 localhost
Accept GET from about:blank
*Always* check the changelogs BEFORE updating that important software!
-
Re: Noscript blocking Dashlane extension Firefox 50
Your suggestion
Does work, but there is a 10-15 second pause before Dashlane starts working. (It is gray till ready; then it turns green.) The console shows this:
But it still loads after all that.
By this point I don't know if what I have is correct. This is what I have for the SYSTEM ruleset:
Is that what you are proposing, or did I mess something up?
Code: Select all
Site 127.0.0.1 localhost
Accept GET from about:blank
Code: Select all
Could not read chrome manifest 'file:///C:/Program%20Files/Mozilla%20Firefox/chrome.manifest'.
Use of nsIDOMWindowInternal is deprecated. Use nsIDOMWindow instead. bootstrap.js:43:20
Warning: NetUtil.newChannel(uri) deprecated, please provide argument 'aWhatToLoad'
“nsICookieManager2.add()” is changed. Update your code and pass the correct originAttributes. Read more on MDN: https://developer.mozilla.org/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICookieManager2 my.js:156:5
[ABE WAN] Detected WAN IP 24.23.190.43
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:11456/ <<< http://127.0.0.1:11456/, about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://127.0.0.1:11456/. (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:15674/. (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:17896/. (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:21953/. (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:32934/. (unknown)
Key event not available on some keyboard layouts: key=“c” modifiers=“accel,alt” browser.xul
Key event not available on some keyboard layouts: key=“r” modifiers=“accel,alt” browser.xul
Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” browser.xul
By this point I don't know if what I have is correct. This is what I have for the SYSTEM ruleset:
Code: Select all
Site 127.0.0.1 localhost
Accept GET from about:blank
# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny
Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Noscript blocking Dashlane extension Firefox 50
Oops, my bad. This should work better -
Code: Select all
Site 127.0.0.1 localhost
Accept GET from about:blank 127.0.0.1 localhost
*Always* check the changelogs BEFORE updating that important software!
-
Re: Noscript blocking Dashlane extension Firefox 50
Yes! Errors gone, and extension initializes quickly.barbaz wrote:Oops, my bad. This should work better -Code: Select all
Site 127.0.0.1 localhost Accept GET from about:blank 127.0.0.1 localhost
Will there be a fix to NoScript making this change unnecessary? I'm guessing it would be a fix to how the default system LOCAL rule is currently being interpreted, rendering this extra rule obsolete (but perhaps harmless). I hope the changelog makes some mention of a fix in this area, and if you remember, could you update this thread after the fix, to tell us if we should delete this extra rule?
Thank you very much.
Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0