Page 10 of 11

Re: µMatrix thread

Posted: Thu Jan 04, 2018 4:00 pm
by kukla
All taken care of. Thanks. Btw, had saved that about:config entry "xpinstall.signatures.required set to false" two years ago, and tucked it away safely where I would never find it again. Very often it's easier for me to just google something than to look through everything I've saved or bookmarked.

Re: µMatrix thread

Posted: Tue May 22, 2018 4:04 pm
by kukla
uMatrix/tracker redirect problem:

Using AOL Mail--migrated from Verizon Mail. As of several days ago, when I try to login to AOL webmail, login.aol.com, both Ghostery (from which I can temporarily allow) and uMatrix block redirects to guce.advertising.com. When I logged in using Safari, allowing the redirect, I was presented with a new terms and conditions page, which I accepted, thinking that that would be the end of these redirects. But back on Firefox 52esr, with uMatrix 1.1.0, this redirect. blocked both by Ghostery and uMatrix is still occurring. First, beyond disabling uMatrix for the scope as it enters that redirect, I'm not finding a way to click through this redirect directly from the uMatrix block. Not seeing anything on the uMatrix block to allow. Plus have searched through all the Hosts files for guce.advertising.com, and come up empty handed. Tried entering guce.advertising.com in what is presumably the uMatrix whitelist, below the Hosts files, but it doesn't save.

Have checked with Virus Total, and guce.advertising.com comes up clean. But still, my main concern, no idea just how pernicious this particular tracker is. Any ideas on that? Have called AOL, but no one there seems to know anything. Even spoke to a "manager," who, unbelievably, didn't know what a tracker was. Seems there's no way around it besides allowing it.

Image


Image

Re: µMatrix thread

Posted: Tue May 22, 2018 4:34 pm
by GµårÐïåñ
It's an advertising system, and chances are due to the new GDRP rules, they are trying to show you an updated terms and conditions and privacy disclosures or whatnot and it is being detected as an advertising redirection (rightfully so given the context) and is blocking it.

Chances are if you go there and give them the compulsory, yea I got it bluh bluh, they will probably stop doing the redirect but that's just an educated guess. You could alternatively try and kill the advertising.com domain either globally or locally using uMatrix or uBlock (if you use it) and that should pretty much nullify it, although technically you could still get the redirect blocking page when the link is opened (seems to be what they are doing rather than loading it inline) but short of blocking the popup capability for that domain locally on aol, you are pretty much out of luck when it comes to seeing the block.

I could be wrong and hopefully Raymond will give us a hint on that if I am.

Re: µMatrix thread

Posted: Tue May 22, 2018 4:48 pm
by kukla
Chances are if you go there and give them the compulsory, yea I got it bluh bluh, they will probably stop doing the redirect but that's just an educated guess.
Nope, the redirect doesn't stop, even after agreeing to the new ToU. Goes by very quickly, but, with the scope greenlit, seeing something like TLS handshake with guce.advertising.com, so guessing that it needs to verify that the ToU have been accepted on each login.

As for
You could alternatively try and kill the advertising.com domain either globally or locally using uMatrix or uBlock (if you use it) and that should pretty much nullify it ...
Not sure that would work because of what I'm seeing (maybe) in the status bar, re. TLS handshake, noted above, on login. Maybe needs to do that verification on each login.

But no idea why the ToU are tied to an advertising domain. Here's are Ghostery's links to AOL Advertising (uMatrix blocks both links.)

https://apps.ghostery.com/apps/advertising.com

Re: µMatrix thread

Posted: Tue May 22, 2018 6:05 pm
by GµårÐïåñ
kukla wrote:Nope, the redirect doesn't stop, even after agreeing to the new ToU. Goes by very quickly, but, with the scope greenlit, seeing something like TLS handshake with guce.advertising.com, so guessing that it needs to verify that the ToU have been accepted on each login.
Well that is indeed horribly dumb and annoying. If it were me, I would just neuter the heck out of it and be done with it. But that's me.
Not sure that would work because of what I'm seeing (maybe) in the status bar, re. TLS handshake, noted above, on login. Maybe needs to do that verification on each login.
As dumb as their methodology seems to be, it would be unreasonable for them to assume that a person must validate each and every time, so my guess would be that if you did indeed neuter it, it won't affect your ability to use the system. The TLS handshake is just what happens on each and every visit you make to anything that is secure, that's just noise. Just because a site is making connections to or requesting access to a domain, doens't mean it needs it or has to do it for you to be able to use the system. If that was the case, pretty much adblocking would be null on the face of it, although some a-holes to try and bootstrap the ads to the page access and redirects but then again that's what surrogate scripts and nulled injected scripts are for to overcome it. But generally when you null access to a resource, it just fails to load that resource and not block/break the whole kit and caboodle (except where I noted just now which can be easily overcome).
But no idea why the ToU are tied to an advertising domain. Here's are Ghostery's links to AOL Advertising (uMatrix blocks both links.)
https://apps.ghostery.com/apps/advertising.com
I can with high level of confidence tell you that if you globally neuter advertising.com as I do in uBlock rules, you will never suffer anything adverse, but again, that's me. uB0 would simply kill this resource and make it fail silently and that's the end of that. I believe you can achieve that in uMatix as well, since it is more a general blocker (forgive me if I am wrong on this) than just a script blocker. I believe it operates more analogously to a ACL (aka Firewall) access system, similar to what RequestPolicy used to do. It has been a while since I have used uMatrix, as I find uB0 to suffice for my needs.

Re: µMatrix thread

Posted: Tue May 22, 2018 7:34 pm
by kukla
I can with high level of confidence tell you that if you globally neuter advertising.com as I do in uBlock rules, you will never suffer anything adverse, but again, that's me. uB0 would simply kill this resource and make it fail silently and that's the end of that.
Hmmm, unsure of how to do that with uMatrix and don't use uBlock. But just added guce.advertising.com to my local hosts file (/etc/hosts) with 0.0.0.0, and with uMatrix completely greenlit for the guce.advertising.com scope, AOL mail completley refused to load--showing a header with an extremely long string beginning "Request (GET https://guce.advertising.com/collect identifiers....(as in screenshot above) and ending with ABE: <local> Deny."

Was that NoScript ABE? As in, # Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny


Once I removed that addition to my local hosts, AOL mail loaded again. Not sure if this proves that AOL really doesn't want guce.advertising.com to fail, or if that simply wasn't the right way to do that.

EDIT: Also tried blocking guce.advertising.com with Little Snitch. Get Secure Connection failed. Beginning to think there's not much to do about this.

Re: µMatrix thread

Posted: Tue May 22, 2018 9:03 pm
by GµårÐïåñ
No, I don't mean the system host file, that is excessively limiting and I highly advise against that unless you are blocking well know, and long lived malware domains.

Anything else, should be handled within the browser layer. So you have more control over tweaking it and without potentially breaking your own system.

I just installed uMatrix, just for this in a clean profile. I added * advertising.com * block under Options > My Rules [SAVE][COMMIT] and then I got nothing from AOL, no redirects, no popup.

So give that a shot and let us know how it goes. In the meantime, hopefully Raymond will have a better/different suggestion.

Additionally, you CAN use ABE to achieve the same thing, but keep in mind, it is not trying to access anything local to you, just a cross domain, so you need to write your rule accordingly.

Re: µMatrix thread

Posted: Tue May 22, 2018 10:29 pm
by kukla
Thanks for spending time with this, and your testing. Added * advertising.com * block, but still getting the uMatrix block on login. Without having an actual AOL login (yuck, I rue the day I was forced by Verizon to start using this total AOL crap--never had any real issues with Verizon mail), you won't be able to exactly reproduce this issue, since the guce.advertising.com redirect appears only on entering a password and then logging in. So far, the only thing that works is to disable the uMatrix scope for that nonsense. Even tried not allowing cookies with that scope, but still seeing several cookies that appear to be related. Would like to see what happens by blocking those cookies, but they are inseparable from others which appear to be needed, so no way to do that.

Really wonder just how nefarious this tracker is, but don't seem to be able to find anything specifically about that.

Re: µMatrix thread

Posted: Wed May 23, 2018 11:06 am
by gorhill
kukla wrote:I'm not finding a way to click through this redirect directly from the uMatrix block. Not seeing anything on the uMatrix block to allow. Plus have searched through all the Hosts files for guce.advertising.com, and come up empty handed.
"How to get past "uMatrix has prevented the following page from loading": https://github.com/gorhill/uMatrix/wiki ... loading%22
kukla wrote:Tried entering guce.advertising.com in what is presumably the uMatrix whitelist, below the Hosts files, but it doesn't save.
The pane is named "Hosts files". The textbox is to import external hosts files through their URL address.

Re: µMatrix thread

Posted: Wed May 23, 2018 2:23 pm
by kukla
Thanks gorhill for the information on getting through the block, as well as what that textbox below the Hosts Files is for. Mistakenly assumed it was for some kind of whitelist.

Btw, here's someone else encountering the same dilemma--with no really satisfying solution in sight.

https://www.reddit.com/r/privacy/commen ... _aol_mail/

Re: µMatrix thread

Posted: Wed May 23, 2018 9:32 pm
by gorhill
kukla wrote:Btw, here's someone else encountering the same dilemma--with no really satisfying solution in sight.
I don't know why you say "no really satisfying solution in sight".

The poster found the actual proper solution: create a rule that will override the broader one. That's how uMatrix works, set narrower rules which override broader rules. I am guessing `advertising.com` is part of some of the enabled hosts files, which translates internally into a `* advertising.com * block`, and thus the rule `guce.advertising.com guce.advertising.com * allow` will override the broader block rule. This is exactly what the poster did and this solved his issue.

Re: µMatrix thread

Posted: Wed May 23, 2018 10:20 pm
by GµårÐïåñ
gorhill wrote:The pane is named "Hosts files". The textbox is to import external hosts files through their URL address.
Thank you for clarifying the nomenclature, I had misunderstood that as a system level host file, apologies.

Re: µMatrix thread

Posted: Fri May 25, 2018 1:36 pm
by kukla
Thanks gorhil, added guce.advertising.com guce.advertising.com * allow` and no longer get the uMatrix block.

I think what I meant by "no satisfying solution in sight" had more to do with the underlying issue, which is, as far as I can tell, guce.advertising.com is most likely a tracker, but needs to be allowed in order to proceed with the login.

Re: µMatrix thread

Posted: Sun Dec 22, 2019 2:56 pm
by kukla
Reviving this thread with a new uMatrix issue. (Mostly a rehash of a post at https://www.reddit.com/r/uMatrix/commen ... r_for_xhr/) that has gone unanswered, except for a recommendation to get to AOL webmail another way, which is unneeded. Thinking that maybe barbaz or someone else can shed some light on this.

Pertains only to Brave (have also asked at Brave discussions with zero replies) :

After latest Brave update to v.79.1.1.23, every site I visit suddenly shows 255.255.255.255 in the XHR column. I've done a bit of research into the meaning of the 255...but don't completely understand:
255.255. 255.255 is a special broadcast address, which means "this network": it lets you send a broadcast packet to the network you're connected to....https://serverfault.com/questions/21976 ... -168-1-255
Screenshot of AOL Mail scope with 255... allowed

https://i.postimg.cc/XqzmJGFN/u-Matrix- ... update.png

So far, as I browse, I haven't encountered any sites that require this to be allowed EXCEPT for AOL webmail, which if not allowed throws a Javascript error, and prevents me from logging in to my account.

As the 255.... appears to relate to the LAN, I would like to know what the privacy and security implications are, if any, of allowing 255.255.255.255 for XHR. I have no idea why Brave is now showing this, nor why AOL (for which I only have a negligible level of trust) won't allow me to login unless it is allowed. Perhaps someone might be able to provide an explanation (hopefully, not very technical ) of this new behavior, and whether I should continue allowing this.

Bottom line question: am I risking anything by allowing the 255...in the XHR column? Does allowing the 255...permit information from the LAN to go outbound? I can always get to my AOL webmail from other browsers, Firefox or Waterfox, but would like to understand what this is really about, if possible, and if there might be any way around this new behavior from Brave.

(MacOS 10.13.6/10.14.6)

Re: µMatrix thread

Posted: Sun Dec 22, 2019 3:18 pm
by barbaz
@kukla: Are you using NoScript in your Brave browser?