Page 1 of 2
Unexpected ABE behaviour since FF 16
Posted: Wed Oct 10, 2012 11:26 am
by Mad55
I'm using NoScript 2.5.7 and this ABE rules in USER to limit facebooks datamining:
Code: Select all
Site facebook.com *.facebook.com facebook.net *.facebook.net fbcdn.com *.fbcdn.com fbcdn.net *.fbcdn.net
Accept from *.facebook.com *.facebook.net *.fbcdn.com *.fbcdn.net facebook.com
Anon
In Firefox 15.0.1 I could type in "
https://www.facebook.com" in addressbar and was logged in into facebook. Now after updating to Firefox 16 I end up on the welcome landing page. If i press F5 or "reload page"-button, I'm logged in again. If I re-enter the address, I still end up on welcome landing page.
If I disable NoScript, I can type in "
https://www.facebook.com" and I'm automatically logged in.
I can verify this behaviour in Aurora build 17.0a2 also.
Re: Unexpected ABE behaviour since FF 16
Posted: Wed Oct 10, 2012 11:48 am
by Thrawn
Mad55 wrote:I'm using NoScript 2.5.7 and this ABE rules in USER to limit facebooks datamining:
Code: Select all
Site facebook.com *.facebook.com facebook.net *.facebook.net fbcdn.com *.fbcdn.com fbcdn.net *.fbcdn.net
Accept from *.facebook.com *.facebook.net *.fbcdn.com *.fbcdn.net facebook.com
Anon
In Firefox 15.0.1 I could type in "
https://www.facebook.com" in addressbar and was logged in into facebook. Now after updating to Firefox 16 I end up on the welcome landing page. If i press F5 or "reload page"-button, I'm logged in again. If I re-enter the address, I still end up on welcome landing page.
If I disable NoScript, I can type in "
https://www.facebook.com" and I'm automatically logged in.
I can verify this behaviour in Aurora build 17.0a2 also.
First things first: you can use a leading dot to cover both the domain and its subdomains. So, your rule could collapse to:
Code: Select all
Site .facebook.com .facebook.net .fbcdn.com .fbcdn.net
Accept from .facebook.com .facebook.net .fbcdn.com .fbcdn.net
Anon
Secondly, I can't reproduce this; if I'm logged in to Facebook, then I can type in the address and I'll still be logged in.
However, since ABE logs all activity to the Error Console (Ctrl + Shift + J or Tools - Web Developer - Error Console), can you look in the Info section and post any related messages? Most likely you need to add another domain to your rule.
Re: Unexpected ABE behaviour since FF 16
Posted: Wed Oct 10, 2012 12:36 pm
by Mad55
I modified ABE rule like you said and found following output in error console on accessing facebook via address:
Code: Select all
[ABE] <.facebook.com .facebook.net .fbcdn.com .fbcdn.net> Anonymize on {GET https://www.facebook.com/ <<< moz-nullprincipal:{dacad0e7-7c2a-4dee-874c-f791d9d64374} - 6}
USER rule:
Site .facebook.com .facebook.net .fbcdn.com .fbcdn.net
Accept from .facebook.com .facebook.net .fbcdn.com .fbcdn.net
Anonymize
If i reload the page, no new ABE message appears.
Re: Unexpected ABE behaviour since FF 16
Posted: Wed Oct 10, 2012 9:00 pm
by Giorgio Maone
It seems they started assigning unique origins to URLs opened from the address bar (previously the origin was chrome:something).
Code: Select all
Site .facebook.com .facebook.net .fbcdn.com .fbcdn.net
Accept from .facebook.com .facebook.net .fbcdn.com .fbcdn.net
Anon INC
Should work (it drops cookies from inclusion requests, e.g. "Like" buttons).
Re: Unexpected ABE behaviour since FF 16
Posted: Wed Oct 10, 2012 11:32 pm
by Thrawn
This looks a lot like
my Gmail problem.
Re: Unexpected ABE behaviour since FF 16
Posted: Thu Oct 11, 2012 7:44 am
by Mad55
Giorgio Maone wrote:It seems they started assigning unique origins to URLs opened from the address bar (previously the origin was chrome:something).
Code: Select all
Site .facebook.com .facebook.net .fbcdn.com .fbcdn.net
Accept from .facebook.com .facebook.net .fbcdn.com .fbcdn.net
Anon INC
Should work (it drops cookies from inclusion requests, e.g. "Like" buttons).
This works perfectly!
Re: Unexpected ABE behaviour since FF 16
Posted: Thu Oct 11, 2012 10:37 am
by F-3000
Mad55 wrote:Code: Select all
[ABE] <.facebook.com .facebook.net .fbcdn.com .fbcdn.net> Anonymize on {GET https://www.facebook.com/ <<< moz-nullprincipal:{dacad0e7-7c2a-4dee-874c-f791d9d64374} - 6}
I keep getting similar block with everything I have ABE rule with, when trying to enter the site.
Code: Select all
Pyyntö {GET https://www.facebook.com/ <<< moz-nullprincipal:{be16eb15-7026-4ae9-97f2-47334b0ec6d9} - 6} suodattanut ABE: <.facebook.com .fbcdn.net .facebook.net .ea2d.com> Deny
Code: Select all
Site .facebook.com .fbcdn.net .facebook.net .ea2d.com
Accept from .facebook.com .fbcdn.net .ea2.com .facebook.net mindjolt.com .satumaa.eu
Deny
Re: Unexpected ABE behaviour since FF 16
Posted: Thu Oct 11, 2012 10:53 am
by Thrawn
F-3000 wrote:
I keep getting similar block with everything I have ABE rule with, when trying to enter the site.
<snip>
Code: Select all
Site .facebook.com .fbcdn.net .facebook.net .ea2d.com
Accept from .facebook.com .fbcdn.net .ea2.com .facebook.net mindjolt.com .satumaa.eu
Deny
Hmm...you could change it to Deny INC, as suggested earlier, instead of just Deny, but this is cropping up more and more. Looks like it will need a more thorough workaround.
What about changing it to something that will match all web traffic, but not the special moz-nullprincipal origin? Anyone have any comments on this?
Code: Select all
Site ...
Accept from ...
Deny from ^https?://.* ^about:.*
Re: Unexpected ABE behaviour since FF 16
Posted: Thu Oct 11, 2012 11:48 am
by Giorgio Maone
Thrawn wrote:
What about changing it to something that will match all web traffic, but not the special moz-nullprincipal origin? Anyone have any comments on this?
I'm working to identify browser "initial" loads (such as those from the URL bar, from bookmarks and from the search box) which were previously shown as originating from chrome and now have unique origins.
As soon as I can do it (if it's possible) I'm gonna treat them as "same origin", as it was before.
Re: Unexpected ABE behaviour since FF 16
Posted: Thu Oct 11, 2012 12:02 pm
by F-3000
Giorgio Maone wrote:As soon as I can do it (if it's possible) I'm gonna treat them as "same origin", as it was before.
I hope it'll be possible. Until then, I'll just turn the USER-rules off.
Re: Unexpected ABE behaviour since FF 16
Posted: Fri Oct 12, 2012 1:44 am
by GµårÐïåñ
I love how mozilla keeps screwing with this. How many times now they have flip flopped on this?
Re: Unexpected ABE behaviour since FF 16
Posted: Fri Oct 12, 2012 1:56 am
by Thrawn
Giorgio Maone wrote:
I'm working to identify browser "initial" loads (such as those from the URL bar, from bookmarks and from the search box) which were previously shown as originating from chrome and now have unique origins.
As soon as I can do it (if it's possible) I'm gonna treat them as "same origin", as it was before.
That sounds good for fixing the old behavior. Even if possible, though, I don't think it will fix the Gmail manifestation of this issue (linked above), because that opens a new page (with moz-nullprincipal origin) in response to clicking on a page element. I've encountered it when opening email attachments with Google Docs, and also when switching to a delegated account.
I can PM my Gmail account details if that would help investigate it.
Re: Unexpected ABE behaviour since FF 16
Posted: Mon Oct 15, 2012 3:03 am
by Thrawn
Update: My ABE rule is now preventing me from logging into Gmail at all. I've had to disable the rule.
Code: Select all
[ABE] <.google.com .google.com.au .youtube.com> Anonymize on {GET https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/?shva%3D1&ss=1&scc=1<mpl=default<mplcache=2#inbox <<< https://mail.google.com/mail/?shva=1#inbox, moz-nullprincipal:{4fc66ebb-f80f-4b84-911e-f58b6c4c2d28} - 6}
USER rule:
Site .google.com .google.com.au .youtube.com
Accept from .google.com .google.com.au .youtube.com
Accept from ^moz-nullprincipal:\{.*}
Anonymize
Re: Unexpected ABE behaviour since FF 16
Posted: Mon Oct 15, 2012 9:57 am
by F-3000
Thrawn wrote:Code: Select all
Accept from .google.com .google.com.au .youtube.com
Accept from ^moz-nullprincipal:\{.*}
Does this really work? I mean both, two Accept-lines, and the moz-nullprincipal?
Re: Unexpected ABE behaviour since FF 16
Posted: Wed Oct 17, 2012 4:23 pm
by Giorgio Maone
Should be fixed in
latest development build 2.5.8rc2, thank you.