Ghostery is Malware ?

I'm using Firefox 26.0 on Win 7 x64. If you want, I could try v5.1.0 and see if the bug happens again.

 

Oh, sorry for confusion, the spreadsheet linked is the original study (the one that's been done several years ago), not areweprivateyet latest run. I'll upload December one and we can chat about that.

 

https://www.dropbox.com/s/jmg5v7xba7o805b/analysis.december.2013.xls Is Ghostery executed aggregation results for the last AWPY execution run.

While reviewing this spreadsheet, I did find a single exception Ghostery makes for all trackers. The exception is made for a flash specific file called "crossdomain.xml", here is a link explaining what its purpose is: http://www.ookla.com/support/a21097566/What-is-crossdomain-xml-and-why-do-I-need-it-

In essence, Flash requires this file to execute any content that may be linked on a remote domain. This is specific to video playing functionality and is excepted in Ghostery as to not break videos from various sources like YouTube or whatever.

 

@fixanoid: Thank you for the spreadsheet .

In the latest spreadsheet you posted, some HTTP requests seem to be selectively blocked. For example, doubleclick.net has 4 HTTP requests (vs. a baseline of 1709 for no extension). Can you give some insight on why the number of requests to doubleclick.net isn't 0, for example?

 

Its the crossdomain.xml requests that were allowed through, at least for Ghostery. Not sure why others would let them slip.

Excel spreadsheet is generated from the actual databases produced during the execution runs. I'd upload those too, but they are pretty big (100mb+). In them tho, you can see which requests exactly where let through and thats the data I've looked at to find crossdomain.xml exception.

 

Thank you for the explanation .

If it's quick and easy to do, could you give me a website where doubleclick.net is allowed by Ghostery (assuming the user is blocking that tracker)? I'd like to see what the Ghostery user interface shows, as well as how RequestPolicy handles it.

 

Crossdomain.xml Invites Cross-site Mayhem (2008 )

 

This covers a different issue unrelated to tracking. The main complaint explained is that any resource from a site could be embeded if crossdomain is set to be global. In terms of tracking, using crossdomain.xml would be a new low for whoever does it and to date I havent seen it used as a tracker.

 

Here are domains where there was a crossdomain.xml loaded from doubleclick.net:

http://www.edmunds.com/
http://www.investopedia.com/
http://grooveshark.com/
http://live.wsj.com/

 

@fixanoid: Thank you for your response . I tested http://www.investopedia.com/, and it does indeed download crossdomain.xml from doubleclick.net (well, actually from pubads.g.doubleclick.net), exactly as you said it would. I also verified that Ghostery blocked everything else from doubleclick.net except for crossdomain.xml. Ghostery's user interface, when using "Reveal tracker source URL lists by default (in the findings panel)" in Advanced options, does accurately portray which requests to doubleclick.net are blocked.



I also verified that RequestPolicy v1.0.0b3 can be used to block all requests to doubleclick.net, so there is added value in using RequestPolicy in default-allow mode in conjunction with Ghostery.

P.S. I feel like taking a bath after seeing all the trackers that http://www.investopedia.com/ wants to load (35 when Ghostery is paused) .

 

I did a little testing on Firefox and verified that the requests for crossdomain.xml can carry cookies and Referer. Since the information would be processed server side, users wouldn't know if that is happening or not.

Unless blocked/limited by other means, flash content (which may not be visibly obvious to the user, flash isn't just about movies) can start by default and if cross-domain communications are involved that request for crossdomain.xml can happen immediately. Which means the scenario mentioned in the first paragraph above can occur the moment you visit a websites.

If the request for crossdomain.xml is allowed to happen and that file contains rules that permit it (the typical case), the flash content will be allowed to communicate further with the cross domain. Those communications can be used for tracking purposes, detailed monitoring of how the user interacts with the flash content, delivery of ads, etc. So we're really talking about two different potential threats that are related.

I have flash locked down and I don't feel like messing with my config. However, I looked at the source code of the Investopedia.com home page and spotted a jwplayer setup that appears to use Google IMA (https://developers.google.com/interactive-media-ads/):

This appears to be the type of thing privacy conscious users would want to block... targeted advertising and feedback being exchanged with a third party ad network (and arguably one of the worst ones).

If one blocks the request for crossdomain.xml, they will block the cross-domain flash communications that subsequently occur. So that is one safe way to protect yourself. An important question here, which I don't know enough to answer properly, is whether blocking that request is the only way for filtering extensions to properly block certain kinds of flash communications. Somewhere I read that crossdomain.xml is also used to determine whether custom protocols and socket communications are allowed. Which are the types of things I think HTTP filtering extensions wouldn't be able to interpret and filter well.

So at this point I'm thinking that requests for crossdomain.xml should not whitelisted across the board and they should be blocked when they are to a domain that is known for targeted advertising, tracking, etc. If the user wants to make an exception they should be able to of course.

Thoughts?

 

@TheWindBringeth: Thank you for your further analysis . My thoughts are that using RequestPolicy v1.x in default-allow mode to block requests to undesirable domains isn't a waste of time even when using Ghostery (or similar); RequestPolicy v1.x lets one use specific Allow rules for a given domain that override more general Block rules, if needed. So, for example, I have a RequestPolicy Block rule that blocks requests from any domain to domain *.doubleclick.net. If this were to break desired functionality at a given site, such as Investopedia.com, I could create an Allow rule that would allow requests from *.investopedia.com to *.doubleclick.net.

 

I may have not been too clear about uses of crossdomain.xml. First allow me to detail how crossodmain.xml is called upon: Lets say you visit blah.com and it embeds a video player from videoplayer.com, but the video is served from videocontent.com. The first thing Flash will do is request crossdomain.xml from videocontent.com and videoplayer.com. This is done without any programming whatsoever -- a sub-system check from Flash application itself. This means that this is not a programmed action. If this fails for any reason, the video will never be pulled or shown to the user.

Specifically in Ghostery, when blocking is on, only crossdomain.xml will be allowed to load, nothing else from a blocked tracker. General case for this could be tested on any of the sites I've provided above. Because crossdomain.xml is allowed through, the video (or whatever other content it may be) will continue working because it receives the correct permissions. If it wasn't allowed to load, the content would not be shown even if its unrelated to a tracker. This matters because a usual video display sequence are like this:

1. live.wsj.com loads a player from content.wsj.com
2. video player will then start loading advertising frameworks built as modules for flash. This is when the crossdomain.xml calls will permit the Flash application to know that it may continue loading whatever it needs.
3. Actual frameworks will not get loaded, and in general video players are smart enough just to move on.
4. At some point actual video content will get loaded from whatever.
5. User sees video.


One more note specific to Ghostery. In general, even for crossdomain.xml and even with Set-Cookie header, Ghostery will strip the cookie and/or disallow access to its contents -- this part depends on how you've configured Ghostery.

 

I use Ghostery. I would never use malware on my machines. I do have to pause its protection sometimes so that some webpages can function correctly. One example is I have to pause it's protection to download the update for Adobe Flash, or i'm forced to install the McAfee security tool with it because it blocks the window to untick McAfee.

 

I would expect the request for videocontent.com/crossdomain.xml. Regarding the request for videoplayer.com/crossdomain.xml, may I ask what makes you believe that will happen?

I'm not satisfied with the material I've read and the limited testing I've done. However, those suggest that the Flash application will make a "do I need crossdomain.xml?" decision by comparing a) scheme:hostort of the data request, to b) scheme:hostort used to acquire the swf making the data request. For example: http://stackoverflow.com/questions/...-a-swf-from-a-domain-that-is-not-the-domain-o

That is my understanding too.

This (the underlined part) is what I've sought clarification on. In order for that to be true, *all* other types of (cross-domain) flash initiated communications *must* be exposed to the browser and through its mechanism for allowing extensions to block it.

I've watched traffic and observed flash dependent HTTP requests (other than for crossdomain.xml) that can be blocked via AdblockPlus rules. I'm assuming Ghostery would also be able to block those. So I'm not questioning the idea that some post-crossdomain.xml-request flash originated http communications with trackers will be blocked by Ghostery. Its the cases where Ghostery (and/or other extensions too, mind you) wouldn't be able to do so that concern me. More specifically, I'm wondering if there is such a case that could be clipped by blocking crossdomain.xml. Some things, such as this crossdomain.xml allow-access-from attribute (http://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/CrossDomain_PolicyFile_Specification.pdf) give me pause:

Because I would expect alternate protocol/port traffic to get around filtering extensions.

I think I need to spend some more time on this to get a better feel for those scenarios, but feel free to comment. I will throw out one more question if I may:

How are you monitoring what gets past the various extensions when you test them? If there were alternate protocol/port traffic with a known tracker domain, would you detect and count it?

 

Both Firefox and Chrome route all Flash initiated traffic through them, so blocking extnesions do see this traffic and are able to monitor and block it.

There are several good tools out there tho Fiddler and Charles proxy are the ones we generally rely on.

 

I'm not in a position to discuss the Flash in Chrome context. As for the Flash in Firefox on Windows XP & 7 contexts, I can test and verify things. Here is one Flash test, which uses RTMP and RTMPT on several ports:

http://www.therealtimeweb.com/index.cfm/2004/10/2/fms-port-tester

I've focused on the first swf. Quick checks indicate that the outbound connections on XP are coming from plugin-container.exe, and on Windows 7 they are coming from the low integrity player process. For fun and as a sanity check I wrote a simple instrumentation extension last night. Should capture the same as Ghostery but I have to go back over the code to double check that. I don't see any of that traffic coming through its interfaces/observers. For both reasons I don't think Ghostery will be able to block it.

It seems as though that Flash traffic isn't of a type to trigger crossdomain.xml requests (even when the page & swf are on other domains). However, it demonstrates traffic that presents a problem for filtering extensions I think.

 

@fixanoid: Do you have any info on possible leaks when using Ghostery with HTTPS Everywhere? See Filtering extensions might leak if HTTPS Everywhere is installed.

 

I'll need to retest these conditions since this is very different setup, but AFAIK this is all routed through browser as well.

 

To my knowledge, there are no known problems with this setup, that said, there is a priority challenge meaning that if Ghostery acts upon a request, it may override what HTTPS rules are set, tho this would not cause a tracker leak.