search

arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
9.98k stars 511 forks source link

sticky: extensions #294

Closed Thorin-Oakenpants closed 6 years ago

Thorin-Oakenpants commented 6 years ago

:exclamation: please try to NOT start discussions in here, start a new issue instead. ONLY use this thread to report extensions - thank you

Use this issue for extension announcements: new, gone-to-sh*t, recommendations for adding or dropping in the wiki list 4.1: Extensions. Stick to privacy and security related items, and do not mention legacy extensions

:small_orange_diamond: Added Web Extensions

:small_orange_diamond: Pending Web Extensions

:small_orange_diamond: Rejected If you strongly disagree, then by all means, bring it up

...

Atavic commented 6 years ago

FacebookTrackingRemoval barely tested here (no FB), but I trust the dev.

edit: Not interested in Extensions that pander to a single site. The adblocking and cosmetics of hiding elements can already be done (uM, uBo .. heck, even Stylus). The link clicking/tracking can also be done not that I have uber investigated it, but rules can be created I'm sure. So unless I'm missing something.. nah - Thorin

Decopi commented 6 years ago

Please, I would like to submit to be added to the list, Peter Snyder add-on (WebApiManager): https://addons.mozilla.org/en-US/firefox/addon/webapi-manager/

Edit: It is already listed above in the pending section - Thorin

Atavic commented 6 years ago

User Agent Switcher

I know current policy for spoofing, so I'll silently keep an eye on this webext.

Edit: Godamn it - no UA rubbish - Thorin

Decopi commented 6 years ago

Another suggestion, ClearURLs, Kevin Roebert:

https://addons.mozilla.org/en-US/firefox/addon/clearurls/

The main difference of this add-on, first is an open source, and second it has 65 rules against average of 13 rules of other similar adds-on.

Edit: added to the list above, and am testing it out myself - Thorin

2glops commented 6 years ago

In fact : https://addons.mozilla.org/en-US/firefox/addon/clearurls/

Thorin-Oakenpants commented 6 years ago

ClearURLs has some possible issues (all resolved now: April 2018)

[1]

  "web_accessible_resources": [
      "siteBlockedAlert.html",
      "log.html"
  ]
KevinRoebert commented 6 years ago

Hi, I'am the owner of ClearURLs. I want to answere your questions:

you need to set an extension permission exception for cookies in order to be able to log. It doesn't use IDB, but somehow the cookie setting blocks storage of log data

We're saving the log with the following two functions:

/**
* Function to log all activities from ClearUrls.
* Only logging when activated.
* The log is only temporary saved in the cache and will
* permanently saved with the saveLogOnClose function.
*
* @param beforeProcessing  the url before the clear process
* @param afterProcessing   the url after the clear process
* @param rule              the rule that triggered the process
*/
function pushToLog(beforeProcessing, afterProcessing, rule)
{
    if(logging)
    {
        log.log.push(
            {
                "before": beforeProcessing,
                "after": afterProcessing,
                "rule": rule,
                "timestamp": Date.now()
            }
        );
    }
}

/**
* This function is triggered by the event windows.onRemoved and tabs.onCreated
* and will save the log permanently to the local storage.
* We only save the log anticyclically based on performance.
*/
function saveLog()
{
    if(logging)
    {
        browser.storage.local.get('resetLog', function(data) {
            if(data.resetLog)
            {
                log = {"log": []}; // Delete the old log
                browser.storage.local.set({"resetLog": false});
            }
            else
            {
                browser.storage.local.set({"log": JSON.stringify(log)});
            }
        });
    }
}

We're only save a log when the user activate the logging function. From default the logging is disabled, because it is only a feature for debugging and to make suggestions for new rules.

it has web_accessible_resources [1] which on the face of it seems ok. The log is viewed internally, not sure about the alert part. Can someone look into this?

The altert part is only a html site, that inform the user, that a whole domain was blocked, because of ad-tracking, like doubleclick{dot}net.

E.g. for alert page on doubleclick

bit weird: the counter keeps going up and up per page - eg on reddit it blocks 2 items, then go next page and it climbs to 4 etc. It starts from scratch on a new tab+reddit etc. I'd rather have it PER page, not a running total. That way you can see if anything is blocked or not.

Yeah, this is a feature-bug :P. We will change this in the next update. So the counter will counts only the blocked fields on a page, not on a tab like now.

I am available for any questions.

Thorin-Oakenpants commented 6 years ago

Thanks @KevinRoebert I am not a developer, so excuse my ignorance.

Are you using the right storage API, because a cookie permission should not be needed AFAIK. other web extensions do not have this issue storing some local non-IDB data - I guess it depends where. Yes you would need one if it were IDB - see 1406675 and the work around ( https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1.1-Setting-Extension-Permission-Exceptions ). It's not critical, because I can easily set a site permission exception on the UUID

FYI: WEs can access their own storage regardless of prefs using the storage API (+permission). 1

Although this API is similar to Window.localStorage it is recommended that you don't use Window.localStorage in extension code. Firefox will clear data stored by extensions using the localStorage API in various scenarios where users clear their browsing history and data for privacy reasons, while data saved using the storage.local API will be correctly persisted in these scenarios.

1source: @earthlng: our resident code wizard

Web Accessible Resources - see this issue for more info. The UUID which is unique to each install of a web extension, can be exploited in some cases. Other extensions do not require this for their UI popups, etc. Is it possible to do away with them. AFAICT, you're not injecting or doing anything to web content, just blocking requests - right? So we should be safe (told you I am not an expert!).

Good to know about the counter

Thorin-Oakenpants commented 6 years ago

@KevinRoebert Here is a comment by gorhill (the dev of uBo and uMatrix) that shows you how to bypass using web accessible resources - all over my head, but there ya go :)

Edit: OK, looks like you're injecting that alert into web pages. This could be a problem. Not your fault - it's Mozilla's fault for using a UUID per install and not masking/hiding it properly

KevinRoebert commented 6 years ago

Edit: OK, looks like you're injecting that alert into web pages. This could be a problem. Not your fault - it's Mozilla's fault for using a UUID per install and not masking/hiding it properly

I do not directly injecting the alert into web pages. The progress is the following:

  1. ClearURLs detects a blocked domain.
  2. ClearURLs rewrite the asked url to var siteBlockedAlert = browser.extension.getURL('./siteBlockedAlert.html'); (the addon intern alert page).
  3. Firefox do not visited the asked domain, firefox visited the rewritet addon intern domain.
  4. So the displayed url is something like that: moz-extension://9b334143-726d-4afb-8aa4-930b025ae4b5/siteBlockedAlert.html

This is the code for the rewrite:

/*
 * Cancel the Request and redirect to the site blocked alert page,
* to inform the user about the full url blocking.
*/
if(result.cancel){
     return {
          redirectUrl: siteBlockedAlert
      };
}

And will be evaluate here on line 7:

/**
* Call by each Request and checking the url.
*
* @type {Array}
*/
browser.webRequest.onBeforeRequest.addListener(
    clearUrl,
    {urls: ["<all_urls>"]},
    ["blocking"]
);
Thorin-Oakenpants commented 6 years ago

Thanks for the info :+1: I saw an image on AMO (the third one) and to me it looked like the alert was placed in the web page in lieu of a blocked element or something - it doesn't reach the edges of the page. Sorry if the term "inject" is not correct (told ya I was a dummy) :)

Thorin-Oakenpants commented 6 years ago

Added Forget Me Not | GitHub to the list above to keep an eye on etc.

This may get closer to the all-in-one persistent storage extension I am dreaming of. Blacklist all (delete after domain no longer open), whitelist (keep), greylist (session only) etc. But it has issues due to FF limitations such as FPI, containers, PB mode, localStorage by host (FF58+) being the main ones.

It does have some extra items such as history, form data, service workers, certs, IDB - but they're listed under clear all. So far the ONLY thing cleaned by domain is cookies (and localStorage in FF58+), and you can do that with C-AD. Still, worth keeping an eye on maybe.

Atavic commented 6 years ago

Nano Adblocker Beta is out, I hope someone will test it as I do.

ghost commented 6 years ago

Concerning the WebApi Manager Firefox extension in the context of sites using IndexedDB when cookies are not blocked (Issue #294), among all its features there is one which deals with that, listed in the extension's Options / Storage / Indexed Database API item: blocking it forbids sites from using IndexedDB without altering Webextensions which need it, which is interesting at least until the arrival of Firefox 59 which is announced as resolving this issue.

verlain3 commented 6 years ago

Does Cookie AutoDelete works now with LocalStorage on Firefox 58 that came out today?

ghost commented 6 years ago

Does Cookie AutoDelete works now with LocalStorage on Firefox 58 that came out today?

And the answer is... yes! Provided the user has checked the option in Cookie Autodelete's settings' Localstorage Cleanup (Firefox 58+)

Forsaked commented 6 years ago

Does Request Control still work for you guys? It looks like it stopped working for me weeks ago, even with a vanilla profile no user.js and no other extensions it doesn't do anything with it basic rules or custom rules.

Edit: Running 58.0

Atavic commented 6 years ago

Request Control 1.7.1 on FF ESR 52.0 32-bit works: https://github.com/tumpio/requestcontrol/wiki/Testing-links

Thorin-Oakenpants commented 6 years ago

1.8.6 on FF57 seems to work for me: my little imdb stripper rule worked. I do know it was broken for one release about 2 months ago

crssi commented 6 years ago

@Thorin-Oakenpants would you mind to share this little imdb stripper rule?

Forsaked commented 6 years ago

Cross checked with work Computer, works fine here but not at home. Even with a new vanilla profile it doesn't seems to work there. I hope it is not Malwarebytes again, which f***ed up my last profile 4 weeks ago.

Edit:

Found the culprit! The basic rules after removing Request Control and adding it again worked, so i rebuild the sample rules from https://github.com/ghacksuserjs/ghacks-user.js/issues/149 and now they are working fine. Looks like something changed in the extension and my exported rules.json from before WE was somehow bad.

forteller commented 6 years ago

I would like to recommend adding the extension Redirect AMP to HTML. Google is trying to gather as much information about everyones browsing habits as possible, and to eat up as many web services as possible. Now they've gone so far as to host other peoples content for them. This is very destructive to the web, and your privacy. Read more about it here: https://danielmiessler.com/blog/google-amp-not-good-thing/

This extension redirects you away from AMP, so you don't use it yourself and don't link others to it when sharing the link. It's very important to send the message to newspapers and everyone that we don't want Google to own the web, we don't want AMP.

Thanks!

grauenwolfe commented 6 years ago

CSS Exfil Protection

Based on reading about this on Bleeping Computer earlier today. Anyone already familiar with this BS?

With the recent upgrades to the CSS language, CSS code has become a powerful tool that could be abused to track users on websites, extract and steal data from a web page, collect data entered inside form fields (including passwords), and even deanonymize Dark Web users in some scenarios.

Over the past month, three interesting research projects have tackled CSS as an attack vector, showing how this once benign language could be turned against users.

Article on Bleeping: CSS Code Can Be Abused to Collect Sensitive User Data

Thorin-Oakenpants commented 6 years ago

^^ continue it here: https://github.com/ghacksuserjs/ghacks-user.js/issues/343#issuecomment-363645884

crssi commented 6 years ago

FYI: If you block access to storage\temporary folder then you can't manage rules in "Header Editor" addon.

Cheers

crssi commented 6 years ago

No, no, you got me wrong. CSS Exfil doesn't have nothing with that. Its general. The sub folder "storage\temporary" in profile folder. I had for some reason (testing) for a long time now, deleted this folder and created a file with the same name, to block its usage. And in this case I can't manage rules in "Header Editor" addon. The same I had done long time ago with "storage\default", but now, for obvious reasons how WEs storage works (, this is not a case anymore.

Thorin-Oakenpants commented 6 years ago

that's an IDB folder (but IDB can also be used by web workers - eg think of uBO's web worker when searching for the block via logger in the 3rd party filters). I can't find the doc (I swear it was in MDN docs) about temporary folder use. It was an entry about those default-permanent-temporary storage folders - and from what I remember, the temporary one was nothing to worry about - I think it HAS to clean up after itself when finished. I should find that doc again.

this might have been it: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria - I can't tell because the whole Storage v2 is rolling out AFAIK (edit: yup, its changed a bit from memory - I think all the storage quota stuff is new and LRUs - page updated a month ago)

Users shouldn’t add their own directories or files under <profile>/storage. This will cause storage initialization to fail; for example open() will fire an error event.

GitCurious commented 6 years ago

For those who manage cookies: CookieBro https://addons.mozilla.org/en-US/firefox/addon/cookiebro/

I am only 'testing' Quantum in portable mode [mainly testing CSS replacements for CTR etc] as my daily browser is Waterfox 56 - yet I have also replaced my beloved [but now legacy] CookieKeeper with this addon in Waterfox as well.

Since yesterday (v2.0.1) individual cookies can now be whitelisted and protected from deletion - this was my one proviso before changing cookie managers.

It has many other features but critically (for me) it is very easy to use in addition to having individual cookie protection.

I save a few logins & prefs and auto-delete the rest.

ghost commented 6 years ago

For those who manage cookies: CookieBro

I discovered CookieBro yesterday, had a look, not bad, but incompatible with FPI First Party Isolation, and this is of course specific to FPI at this stage of Firefox (I think FF59 will make it possible, not sure).

Unfortunately CookieBro doesn't handle setting a site's cookie authorization to Session only. Take the scenario of a user who wishes to have all cookies blocked with exceptions for a few sites. The developer of CookieBro says to include *.* in the extension's Blacklist option and then to set a whitelist exception for a given site : but what happens if my wish is not to have a site whitelisted but only accepted for the session? i.e. userstyles.org : the site requires a cookie just to display, otherwise white page! I'm not going to whitelist userstyles.org just to be able to access it -> a sesssion-only cookie is the solution.

Be it reminded that with CookieBro, whitelist = allow, blacklist=block ... but session only is missing. That doesn't do the job completely.

I think Firefox's built-in cookie management accessible via Page Info is sufficient and not bothered by FPI. But true that having to click1 on the urlbar 'Show site information' button, then click2 'Show connection details' then click3 'More Information', then click4 (once on Page Info) on Permissions... to view/edit cookies permissions is fastidious . There is also the context-menu right-click 'View Page Info' .. but IMO access to a site's Page Info hasn't been thought in an optimized way, there's not even a keyboard shortcut (under Windows) as ctrl-I opens the sidebar... I mean : Page Info is essential, it should be treated as a priority by Firefox.

GitCurious commented 6 years ago

Cookiebro 2.2.0 - 2018-03-17

Decopi commented 6 years ago

I would like to suggest the "Temporary Containers" add-on by stoically:

https://addons.mozilla.org/en-US/firefox/addon/temporary-containers/ (edited by Thorin, the link syntax was fubared)

I was a container-user without add-ons. I generally believe that the less add-ons, the better. However, Container in Firefox is too basic/primitive in the sense that it has layout options but not functionality options. Even the Firefox' container add-on is very limited in functions. Everything related to containers in Firefox has to be manual, each website is handled manually (a nightmare). I hope to be wrong, but with this lack of functions, average users are going to use Firefox' containers in the wrong way.

For example, containers in Firefox have not the option to open every website in new separate different container. Neither have the option to clean the container when closing (after "x" minutes). In terms of privacy, this two functionalities are a must! Otherwise, is non sense to use only one container, the same container, for all websites. And the second function deleting everything, it avoids the need for other add-ons like cookie add-ons etc.

The "Temporary Containers" add-on by stoically has this two functions and many other functions. Also, is an Open Source:

https://github.com/stoically/temporary-containers/ - edited by Thorin. The syntax is [title](www.example.com) not [https://github.com/stoically/temporary-containers/](url)

And "Temporary Containers" is just 369.5 KiB (only 100 KiB more than Firefox add-on).

Thorin-Oakenpants commented 6 years ago

I'm still waiting for Containers & Container Extensions to mature, and I have concerns over sanitizing. There are no right or wrong answers, everyone's threat model may differ.

Here are some points to consider

So some login issues aside, FPI does everything and more that a container does, except...

Containers come shipped (default off for now?) with Firefox, and using them in conjunction for one off sites is perfectly acceptable (just like a one off Private Window)

Lets recap: we have FPI, Containers (with or without container extensions), and PB mode. These are called OAs (Origin Attributes)

Not sure if this is what is meant by double-keying or not, but FPI can work with Containers and PB mode. Note: Containers + PB mode can not. Without looking it up, it is something like this: (also see https://github.com/ghacksuserjs/ghacks-user.js/issues/240 )

Man.. I'm getting tired.... so I hope that answers a few questions about the FIRST part of your comment. Containers & FPI (& PB Mode) differ slightly in handling isolation/data/cleaning.

The second part of your post, about clearing data, I will address in a new comment - because, seriously, the mechanisms for clearing data by host DO NOT EXIST for all persistent data types (AFAIK, and I've been digging into this shit for months :) )

Thorin-Oakenpants commented 6 years ago

Neither have the option to clean the container when closing (after "x" minutes)

I need to investigate this. PB mode (which does not allow IDB) can destroy all PB mode related data (well, it's supposed to - cookies, localStorage, appCache, service workers cache, asm.js cache etc).

Can a container (which does allow IDB) actually clear only it's IDB stuff? I do not think so!!! How a container clears selective data depends on how it's doing it. How does PB mode know what to clear. I am thinking that extensions such as Temporary Containers are using the same APIs etc that other cleaners are using - eg Cookie Auto-Delete. And many persistent storage items do not have sufficient APIs to clear by host or time-range.

ghost commented 6 years ago

Containers : I've never used them, I even block all privacy.userContext.xxx Private Browsing (PB) : I never use it FPI : yes, yes and yes. Very strong, very.

Nice resume, @Thorin-Oakenpants , clear enough (especially for a Sunday morning!)

Thorin-Oakenpants commented 6 years ago

^^ TL;DR

This is all you need IMO

But...

And...

Thorin-Oakenpants commented 6 years ago

clear enough (especially for a Sunday morning!)

f*k .. I ended up writing a book

Nice resume

The word is summary.. a résumé is personal and outlines said person's background and skills. Maybe I should have done that instead, it'd be shorter :grin:

Decopi commented 6 years ago

Hi @Thorin-Oakenpants ! Thanks for your comments. I am sure that the author of "Temporary-Container" (@stoically) is the right person to address your comments. His add-on' page also includes illustrative texts. But please, allow me to share my opinion:

FPI is great, and the intention here never was to use Containers instead FPI!!!!!!!!!!! Both (FPI/Container) are two different things, created for two different needs. In fact, both are complementary, and in my opinion both should be used together for better (not best) privacy practices/benefits.

I agree with you about "containers not mature". But that is the reason I recommended @stoically add-on. At present time is the only add-on that today expands container functions. I am not saying that this is the holy grail. I am just suggesting this add-on because increases privacy/security, and because is the best option out there for containers. I understand that you don't see a real need for container. I was in contact with Mozilla' employees and other experts in FPI/Containers, and I am convinced about the utility. But as I said, the author of the add-on (@stoically) is the right person to address your arguments.

I also understand your general idea to replace containers by using PB tabs in normal mode. The problem is that for average users is unpractical. I know that your approach regarding privacy/security always is the best and the right to do. But sometimes we need to think in average users, and we need to think about alternatives (not solutions) for average users. Even if these alternatives are not solutions, are not perfect, are better but not best practices, if these alternatives increase privacy/security... then we should use it.

ghost commented 6 years ago

My problems with English. I did mean nice summary ...

It's not a book. Modern trend to squeeze and compress has its limit; when the topic is complex compressing exaggeratedly would inevitably omit the necessary info.

The topic is complex, the summary clarifies the ingredients, for me anyway.

Thorin-Oakenpants commented 6 years ago

Lets just clarify a couple of statements here

FPI is great, and the intention here never was to use Containers instead FPI

But if you're using FPI, then Containers ofter NOTHING you haven't already got, just stating the facts

In fact, both are complementary

There's nothing complimentary about them - FPI effectively overrides containers in the sense that the "container" is now useless as a data bucket, because everything is already isolated on a more granular level.

If you are talking about data cleaning, that's nothing other extensions can't already do (eg Cookie Auto-Delete), and already do in normal mode (I am not 100% certain that some ContextId data types that can't be cleared by host, can't be cleared by OA, so correct me if I'm wrong).

Yup, I know not everyone has the same strategy. For example, I block all cookies except for about 8 I keep of which 4 are for logins, and another 4 or 5 which are session only (to make some sites work). Those 4 logins, I do not care about 1st party tracking (i.e linking previous visits) because I logged in, they already know me by a unique id (an exception here would be multiple accounts on the same service, which I do not have = I would use the PB window trick).

Because cookies control 1st party localStorage and IDB (and because 3rd party cookies are blocked as well it blocks 3rd party access to almost all persistent data), because appCache has to ask for permission, because Service Workers are disabled .. I do not really have to worry about clearing data when I close a domain. That is, I do not have to really worry about 1st party tracking. And I clear almost all data on close (eg session cookies, IDB etc)

Until sanitizing gets it's cr*p together, this has been my strategy and that of the user.js since inception - do not collect anything unless it is absolutely required. But that's ME.

I have no issues with Containers, or extensions that enhance that in some fashion. Because not everyone will want to enable FPI, not everyone blocks all cookies by default.

At some stage, maybe I'll add a recommendation for those who do not use FPI, to consider TC - but first I want (and do not have the time) to investigate what it says it clears etc. In the meantime its added to the first post

Thorin-Oakenpants commented 6 years ago

^^ don't get me wrong, I just had a quick look at the AMO page. Its a great extension (and the idea is great), but its also incomplete (FF lacking APIs). I just need to "vet" it first .. so for now, its on the list, not on the wiki

Decopi commented 6 years ago

Hi @Thorin-Oakenpants ,

I read carefully all your comments. Again, thank you! I never will say you are wrong about FPI/Containers. But I will just say that your info doesn't match with the info I received from Mozilla's employee & other experts.

My understanding still is that FPI and Containers are two different things, with two different functions, for different needs etc... one is not better than the other... one is not replacing the other... and both are complementary. More important, my understanding is that the combination of FPI and Containers increases privacy/security, not in a perfect way, but in a very useful way for average users (not for expert users like you).

However, my original intention here was just to suggest an add-on. Period. I am not here to debate the concept of FPI or Containers. This is a very different conversation that should be kept only between you and expert tech guys.

Thank you again!

Thorin-Oakenpants commented 6 years ago

But I will just say that your info doesn't match with the info I received from Mozilla's employee & other experts

In what way? Without wanting to misquote anyone, what I have said on OAs is based, among other things, on chatting with Arthur Edelstein (key lead on the Tor Uplift) and he assures me, that while he's not 100% knowledgeable on all aspects of the coding, he was assured, that what he told me was correct, directly from one of the guys responsible for it at Mozilla (i.e the coder) - horse's mouth and all that.

As to their purpose and limitations - well of course they're different. One is superior/more-hardened for TBB, the other is something that grew out of an old add-on idea. The fact they use OAs is about the only thing in common.

and both are complementary. More important, my understanding is that the combination of FPI and Containers increases privacy/security

Please stop saying they're complimentary. In almost everything I have said, I am talking about containers. I think you might be saying containers but thinking about "Temporary Containers". Containers on their own do NOTHING more than FPI already does (and a PB mode window when needed). I also wouldn't include the word security - this is all about privacy.

I get where you coming from. I too am excited by new privacy measures. Having now taken a break and come back to it (new topic, yet to read), something crossed my mind. And this comes back to the 1st party tracking I was talking about earlier (i.e when you revisit a site in the same session), I would have to check, but if Temporary Containers assigns a new ContextId, then that would mean each instance of a same-domain visit would be a new isolation (obviously no existing tab of that domain should be open). So yes, if leveraged that way, then there is one example I can think of that this exceeds what FPI does, and since FPI also isolates other things, then in this ONE case so far, they're complimentary.

Not knocking anyone or anything here. Appreciate everyone's time and input :kiss:

Thorin-Oakenpants commented 6 years ago

note to self: https://addons.mozilla.org/firefox/addon/https-by-default/ is now a web extension - update wiki page

edit: @fmarier .. is https://bugzilla.mozilla.org/show_bug.cgi?id=1370388 now completed / redundant / fixed / irrelevant or wot? Or did HTTPS by default find a workaround? I see you have a fork of it, also, you reported that ticket .. so hence I'm asking you - just interested

PS: At what point do Mozilla change the default from http->https (80%+ of samples AFAICT from telemetry are https, surely its time to change it). Is there a ticket for this proposal? TIA

Decopi commented 6 years ago

I would like to submit to be added to the list, @Cowlicks add-on (Privacy Possum): https://addons.mozilla.org/en-US/firefox/addon/privacy-possum

The GitHub page (https://github.com/cowlicks/privacypossum) offers a nice description, also comparing PP with other similar privacy add-ons/extensions, showing PP advantages, added values etc.

Thorin-Oakenpants commented 6 years ago

Just some quick notes:

  1. cookie tracking - we already block 3rd party cookies. Also FPI isolates 3rd party cookies if you allow them, same with containers (per container). And uMatrix allows cookies blocking with whitelisting on a per scope level, and then there's Cookie AutoDelete and a hundred other cookie extensions

  2. ETags - we can already do this with a rule for Header Editor - or users can disable both disk+memory cache. The first solution is the best. The second can be a tad extreme (nothing in memory will cause extra traffic etc). A third solution is clearing cache eg say every 15 minutes via an extension but is not a perfect solution (time factors leave holes for repeat visits).

  3. Referers - Smart Referer is a dedicated referer extension that allows a per origin-destination level of control, with whitelists/greylists/blacklists etc (not actually using it myself, so slightly hazy on it)

  4. "fingerprinting" - uM (and uBO) can handle 3rd parties if used in "medium" or hardened mode or whatever they call it. Yes, not everyone uses it that way. And some 3rd parties are unavoidable no doubt (for the site to work). And there are 1st party FP scripts. Been subscribed to FPjs2 for years. Mozilla's RFP pref defeats most of this (fonts, multiple window metrics, hardware, timing, etc etc). The key to FP'ng is that it is a worst case scenario (always do your tests allowing all JS etc), but in really you control most if it by limiting JS and 3rd parties.

Not entirely sure what this extension brings to the table, except duplication and possibly interference with other extensions/methodologies (eg is talks about faking FP'ng stuff). Note: I have not installed it or checked it out (eg options).

grahamperrin commented 6 years ago

Maybe add Privacy Settings (@schomery) to https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions …

Thorin-Oakenpants commented 6 years ago

^^ Why? It doesn't add anything to what the user.js already covers (unless I'm totally missing something), and most of the settings cannot be flipped by Web Extensions (unless they increase prefs accessible via the Privacy API etc) as about:config is basically out of bounds for security reasons - see https://github.com/schomery/privacy-settings/issues/103 - only 6 of 16 settings available in 57+

Although I'm a little confused because I count 26 items on the AMO page's first image, but the description only lists 16 "items"

grahamperrin commented 6 years ago

… what the user.js already covers …

I assumed that the 'Extensions' page includes extensions that might be used in isolation (not necessarily with the user.js).

Thorin-Oakenpants commented 6 years ago

I get your point. Most extensions that do things FF can't eg in legacy FF there is no way to hide resource URIs, or in FF57+ how do you handle CSS Exfil, how do you do granular control of referers with a pref (you can't), or how do you build smart rule sets for HTTPS. etc

Since we're focusing on non-legacy extensions, Privacy Settings offers 6(?) pref tweaks (probably at least two more with FPI and RFP), and in the overall picture does almost nothing TBH - not knocking what Schomery has done at all, and AFAIK it's been abandoned (due to limitations in Web Ext). To me it's a false sense of privacy (but not due to the author)

The user.js on the other hand, offers 250+ settings that differ from default, and enforce another 90+ at default values. While it might not have a pretty interface, I do not wish to recommend an extension that may not be maintained anymore, and can confuse users (eg if its in the user.js at true, but they keep setting it to false in the extension, and so on)

grahamperrin commented 6 years ago

Thanks for clarification.

… 26 items on the AMO page's first image, but the description only lists 16 "items" …

At a glance: the first image is probably of a legacy version, something less than 0.2.6.