do noscript/httpsb negate the need for disconnect/ghostery etc?

In reading it seems like there are all combinations of privacy extensions in use out there and not alot of clarity. I'ma confessed noob so if i any assumptions I am making are grossly wrong please let me know.

I use noscript with FF and httpsb with chromium and have been trying those in combination with things like ghostery and disconnect, more to test things like ghostery/disconnect. I have noticed that ghostery/disconnect both tell me they are blocking things even when I have noscript/httpsb blocking everything which makes me wonder, which addon/extension is blocking what first?

Also, I am fairly new to HTTPSB and am liking it so far but I has lead me to wonder, does/did noscript block CSS/IMG/iframes/cookies (esp cookies) also? and does that feature negate the need for many of these other things like ghostery and noscript and cookie blockers?

 

No. NoScript, RequestPolicy etc. do not negate the need for Ghostery, etc.

https://www.wilderssecurity.com/showpost.php?p=2312099&postcount=17
https://www.wilderssecurity.com/showpost.php?p=2327885&postcount=24

To test browser connections for yourself in Firefox, use Network Monitor. It's probably best to clear the browser cache before you test a given site; I use Clear Recent History for quick access.

 

Yes, but that does not apply to HTTPSB, IMO.

1. HTTPSB comes with a selection of huge hosts files that block probably more than Ghostery etc.
2. Even if you have to allow a normally blocked host in order to make a site work properly, HTTPSB offers a very granular control of what exactly you allow (cookies/CSS/Images/scripts/plugins/XHR/frames/other).
3. HTTPSB offers domain- or site-level scopes for its rules. Thus, such rules are effectively sandboxed for the respective site and not applied to others. In the newest version the site-level scope can be chosen as default.
4. Beyond its cookie control HTTPSB offers a deletion of local storage, referer control and a timed deletion of the browser cache in oder to get rid of ETags.

Conclusion: With HTTPSB Ghostery etc. is superfluous.

 

I agree with this post. I tested HTTPSB with Disconnect a while ago and there is nothing left for Disconnect to block. Almost all pages has a zero counter in Disconnect. I guess I tested it wrong, maybe Disconnect still haven't finished updating. Maybe I'm not wrong after all. However, test made by gorhill proved that HTTPSB blocks more than Disconnect even though you only used the blacklist of HTTPSB. I do however use HTTPSB with Adblock Plus to remove ads that HTTPSB can't remove.

 

That is something I wasn't sure yet, so I went to check, and I can confirm that if multiple extensions do listen to net requests, all of them will be given the opportunity to inspect all net requests, even those net requests which have been cancelled by one of the extensions.

As per Chrome API, it appears the most recently installed extension is called first, so if you installed Disconnect after HTTPSB, Disconnect will be given the opportunity to inspect and cancel a request first, then HTTPSB will also be given the opportunity to inspect and cancel the (maybe already cancelled) request.

This is good, this means all extensions which inspect net traffic can do their job of reporting accurately that traffic. It takes only one extension to cancel a request.

EDIT: Just to check further I decided to test one URL from my collection of URLs of bloated sites used for test cases (http://www.msnbc.com/), and Disconnect reported 0 requests. HTTPSB reports "www.googletagservices.com", something I would expect Disconnect to report. Even for the unblocked "content" section, Disconnect reports 0 requests, while HTTPSB reports 52 requests. I don't know what to think. (methodology: install HTTPSB w/ out-of-the-box settings, then install Disconnect with out-of-the-box settings).

 

That's what I noticed when I tested it a while ago. Disconnect lists zero in many sites I tested.

 

After installing HTTPSB i wiped away Disconnect and Ghostery. But I kept ADB because some ads are not being intercepted by HTTPSB.

 

Same here. I think there are two cases where Adblock has an advantage:

1. Ads imbedded as text - here's where the Adblock hiding rules come into play.
2. Ads/webbugs/scripts (not 3rd party) that are, e.g., on subdomains which are also whitelisted in HTTPSB or are specific elements contained in the Adblock filter lists. Example: If you whitelist the nytimes.com domain, graphics8.nytimes.com is also whitelisted. Adblock blocks several images on that subdomain with filters like .com/adx/ or .com/ads/$image,object,subdocument. That's something HTTPSB can't do - unless you know exactly that you should blacklist that subdomain (or, at least, the images therein). EDIT: Another related example: You also have to whitelist js.nyt.com in order to make the website work properly. Adblock blocks a script with the filter ||nyt.com/js/mtr.js - for whatever reason.

That's why I think that Adblock with its proven filterlists is still a good supplement.

 

Your point #2 applies also to Ghostery, etc. With scripting allowed on nytimes.com (it's necessary if you want to view user comments on stories), Ghostery blocks 3 "beacon" elements on nytimes.com, two of which are identified as WebTrends scripts.

Here are some relevant quotes from me from the first link in my first post:

 

Okay, but Adblock still covers #1 while Ghostery does not.

I think we'll agree that HTTPSB blocks all 3rd party requests. For the cases in #2: it's hard to tell if Adblock with the relevant filterlists or Ghostery/Disconnect are superior. There are also performance considerations, and I hesitate to add more extensions than necessary as this would worsen the fingerprinting problem.

 

i tested with Panopticlick using only HTTPSB and i found out out i was the only one in this quadrant of the galaxy to use this particular settings of browser.

so there goes my anonymity. lol

 

Correct . That's why I use Adblock Plus also. Quoting from myself:

I use NoScript, RequestPolicy 1.0 in default-allow mode, Adblock Plus (EasyList + EasyPrivacy), and Ghostery.

 

But many other characteristics are relevant. I didn't mean to say that using just one extension guarantees your anonymity

 

When I test Panopticlick with Firefox, it doesn't report my Firefox extensions. It does report my Firefox plugins though. Is it different with Chrome?

 

maybe it's the little tweaks and settings i adjust in Chrome with the inclusion of the only one extension i use: HTTPSB.

i'm just fresh meat for the grinder. lol
---

Chrome comes with flash and PDF , pretty much all i need for plugins.
anyway, Panopticlick does not seem to detect the Flash and PDF built-in plugin in Chrome.

 

No, it's not. I might be overcautious here. But the Panopticlick method is not the only one used. So who knows ...

Anyway, more important is the performance argument, and the fact that I don't see any benefit to add another extension if it overlaps with the other extensions by, say, 99%. And if a site doesn't work because you have to allow something, it gets harder if you don't know which extension is the culprit.

 

Unless you whitelist that site

 

Adblock Plus with EasyList + EasyPrivacy fails to cover a lot of social media type of trackers. So you either need additional Adblock Plus subscription(s) to cover those, or you need to add another extension such as Ghostery. With Ghostery it's easy to allow a given tracker either across all sites, or within a given site, if necessary; I'm not sure the same can be said about Adblock Plus. Ghostery can use surrogate scripts; Adblock Plus cannot use surrogate scripts, as far as I know.

 

I get "one in 82,150 browsers" (strangely number goes down with each refresh, down to under 70,000 after ten refreshes)... What was your number?

(Linux Mint/Chromium here, not exactly the most common setup)

Edit: I do get "one in 18,524" with Firefox and NoScript, and this time the result doesn't change if I refresh.

Edit: That's fun: not blocking cookies on Firefox contributes 0.44 bits of identifying information, while blocking them on Chromium (using HTTPSB) contributes 1.94 bits of information...

 

From Ghostery developer fixanoid from http://webapps.stackexchange.com/qu...onality-of-disconnect-and-facebook-disconnect:

Same applies to Adblock Plus vs. Ghostery.

 

HTTPSB blocks the ads at a most acceptable level in my case, without the need for AB+. It's just that it does it "differently" than AB+, in that I might see a patterned box with text in it where the ad would normally be. The benefit of only using HTTPSB...one less extension. That I see as a good thing. I had Ghostery and I removed that as well. All I use for active content filtering is:

• HTTPSB
• HTTPS Everywhere
• Edit This Cookie - an awesome cookie controller that allows for individual flagging (blocking) of cookie types under a given domain).

 

Example of Ghostery's click-to-play feature

 

That's a nice feature. That got me thinking about HTTPSB... There is already the concept of temporary rules and the convenience of "recipes", so if now a user had the ability to easily click from a list of these preset recipes to apply to the current page, it would become possible to also easily enable disqus (or whatever else common recipe might be convenient).

 

Thanks for mentioning that. I was wondering if HTTPSB provides some level of referer control and didn't notice it before. The description in the 0.7.3.0 Change-log (https://github.com/gorhill/httpswitchboard/wiki/Change-log) makes it sound useful but also a bit coarse and intertwined with request permissions.

I think #2 generalizes to: the ability to create more granular rules that match more of or other portions of the request URL. A host, be it the first party site you are visiting or a first party subdomain or even a third party, may serve both "acceptable" and "unacceptable" things. The ability to surgically block the unacceptable ones can be useful. It can also be useful to have global block rules which match just specific script filenames, portions of URL paths, etc because those rules can apply regardless of hostname. They have the potential to block something you'd want blocked even if the hostname hasn't [yet] found its way into one of the popular hostname blacklists.

The generic ability to subscribe to lists prepared/maintained by someone else (anyone you choose) is another very useful feature, especially for those who don't have the time or ability to maintain their own rules. Conceptually at least, it allows a user to find a list maintained by someone with similar objectives and tolerance for breaking things (default and mainstream lists will always be somewhat conservative due to the plethora of users who won't tolerate breaking). It can also allow for things like a friend/relative maintaining the rules used by their friend/relative.

When I asked in the other thread if that includes Websocket requests I received what seemed like an implicit/indirect "yes" (https://www.wilderssecurity.com/showpost.php?p=2322001&postcount=149). However, I'd like to see a more explicit and absolute answer. Could someone provide one?

Here is a test site: http://www.websocket.org/echo.html. A script loaded from [noparse]www.websocket.org[/noparse] attempts to establish a Websocket connection to echo.websocket.org. For testing purposes, you'd want to allow [noparse]www.websocket.org[/noparse] activity but block the Websocket related communications with echo.websocket.org. Which would be the request to [noparse]echo.websocket.org/?encoding=text[/noparse] that contains the Upgrade:websocket header (occurs when you hit the Connect button) and also the subsequent Websocket transmissions (occurs when you click the Send button). If the upgrade request is blocked I don't think the later should/would happen.

 

"I had assumed these were related to websockets" is not an "implicit/indirect yes", it is an explicit admission that I made a wrong assumption.

Now re. webSocket I just tested with the tool you linked to, and I confirm that these do not go through webRequest API.

Now I see that webSockets have their own scheme, 'ws://', and the Chrome API states:

The webRequest API only exposes requests that the extension has permission to see, given its host permissions. Moreover, only the following schemes are accessible: http://, https://, ftp://, file://, or chrome-extension://​