tracking issue: WebExtension port (aka. Firefox Quantum / Firefox 57+ support)
myrdd opened this issue · 86 comments
Starting with Firefox 57+, only WebExtension Add-Ons will run in the browser. RequestPolicy needs to be ported to the WebExtension API.
You want to help with this transition? The first thing you can do is to install the “Development Channel” version [1] of RequestPolicy Continued and to report any bug you encounter with this specific channel. Thank you.
[1] RPC dev-channel: on the bottom of page https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/ [Edit, 2018-04-04] https://sslsites.de/requestpolicy.256k.de/requestpolicy-nightly.xpi [Edit, 2018-10-25] https://requestpolicy.256k.de/requestpolicy-nightly.xpi
In layman's terms, what would this mean for RP ?
Will it continue to work, or require major rewriting to do so ?
Can we users expect the same level of functionality, or will it be somehow restricted by this change?
Thanks.
@myrdd I agree, some explaination would be just wonderful, because not everyone has time and experience to get through all the docs and understand all the consequences.
In WebRequest documentation I've not seen anything that would actually prevent the RP from blocking a request, but I don't know how much of the requests will actually be exposed through it - for instance, can we block requests of plugins?
I'm also concerned about some details of Chrome's implementation:
Moreover, only the following schemes are accessible: http://, https://, ftp://, file://, or chrome-extension://. In addition, even certain requests with URLs using one of the above schemes are hidden, e.g., chrome-extension://other_extension_id where other_extension_id is not the ID of the extension to handle the request, https://www.google.com/chrome, and others (this list is not complete).
I've not found anything about that in firefox wiki, but I've not looked for it too much yet, just read the Chrome's verstion.
TL;DR / Very short answer: There's no need to believe RP is going to discontinue to work. Some major rewriting might be necessary in the long term. I will make sure that RP won't lose functionality.
Mozilla's aim of the announcement was to start discussion with the community. The discussion is about the WebExtensions API, a „new browser extension API“.
Right now the technologies used to create extensions are XUL and XPCOM. Creating an API doesn't mean that the old technologies are dropped.
Still, we are not sure if XUL/XPCOM is dropped in a few years or not, so I think it's important that the API provides access to all functionality needed by add-on developers. I believe that someday Mozilla's future Layout Engine Servo, which is still experimental, will replace the current Layout Engine Gecko, which is used in Firefox and SeaMonkey. Servo is completely rewritten, and afaict it does not implement XPCOM. Now, what I believe is that Mozilla wants to develop the WebExtensions API independently from the underlying technology so that it can be supported by both Gecko and Servo extensions.
In my opinion Servo is a great project, but also the programming language it's written in, Rust, which has been developed by Mozilla Research as well. Having a browser with Servo/Rust someday in the future will be a great effort.
Now, what does this mean for RequestPolicy? It means we need to make sure that anything needed by RP will be supported by the WebExtensions API.
The XUL technology is not that important to RequestPolicy. However, the XPCOM technology is. One very important part of XPCOM used by RP is nsIContentPolicy.shouldLoad. The corresponding API to that function is WebRequest.onBeforeRequest. Still, the API isn't equivalent to shouldLoad yet. The parameters I need to request are definitely aRequestOrigin (the origin URI) and aContext (e.g. the HTMLElement in the DOM); maybe also aContentType and aRequestPrincipal.
I've updated the first comment to represent my current knowledge. Input and investigation welcome.
Just to give an update, I'm currently working on a WebExtension version of RPC.
All those willing to help me with the transition to WebExtensions, please install the “Development Channel” version [1] of RPC, and report any bug you encounter. Thank you.
[1] on the bottom of page https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/
@myrdd Is it intended that Firefox still takes the extension as not-e10s-compatible?
@genodeftest yes, RPC still isn't e10s-compatible. compatibility will come with the migration to webext.
Is it correct that the version in the dev channel is 1.0.beta12.4, while the currently released version is 1.0.beta13.0?
This wasn't intended. Seems like I misread the documentation, so release/beta channels are really separated: users on the dev channel won't get an update if a new release version is released, even if the version number and release date are newer. However, the only difference between the newest dev-channel version and the beta13 is the version number (and a fixed UI test), as shows the diff. Thanks for the notice anyway.
@myrdd I hope you can port / rewrite RPC for Firefox 57.
Input and investigation welcome.
In my opinion, a good place to start reading is Aris (who created "Classic Theme Restorer")
clear explanation here:
"Legacy add-ons like CTR will stop working when Mozillas XUL/XPCOM support ends with Firefox 57
release"
Aris-t2/ClassicThemeRestorer#299
There are several very helpful links there.
In addition to the links in Aris' article see also these 3:
"Add-ons/Firefox57"
https://wiki.mozilla.org/Add-ons/Firefox57
This is Mozilla's Official wiki (but as it is a wiki it changes, so keep checking).
Andy McKay, who is very influential in the move to WebExtensions, has
posted on some Official Mozilla blogs (you can search for them).
This post, from his personal blog, gives a clear insight as to WHY
he is so keen on WebExtensions.
http://www.mckay.pub/2016-11-26-innovation/
"Stuff we can remove when XPCOM extensions are no longer supported"
https://bugzilla.mozilla.org/show_bug.cgi?id=1347507&format=default
See the "Depends on:" field, there are dozens of Bugs there.
As I am cautious, I moved all my important Profiles, in April 2017
(while Firefox Release was version 52), to the ESR 52.x.x
Nightly is already at version 57 and I expect 'things to break'.
DJ-Leith
I've released a new pre-version on the development channel. It introduces many code changes necessary for WE migration. The pre-version does not contain new features, and it's not a WE yet. Please install and test the pre-version: https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/versions/beta
@myrdd : I'm running your pre-version for about a week without visible functionality issues.
On every start, I get these lines printed to console:
console.debug:
[RequestPolicy] starting up
console.info: [RequestPolicy] [POLICY] PolicyManager::loadUserRules loading user rules
console.info: [RequestPolicy] [POLICY] PolicyManager::loadSubscriptionRules: official / allow_extensions
console.info: [RequestPolicy] [POLICY] PolicyManager::loadSubscriptionRules: official / allow_sameorg
console.info: [RequestPolicy] [POLICY] PolicyManager::loadSubscriptionRules: official / allow_mozilla
console.info: [RequestPolicy] Will update subscription: official allow_extensions
console.info: [RequestPolicy] Will update subscription: official allow_sameorg
console.info: [RequestPolicy] Will update subscription: official allow_mozilla
console.info: [RequestPolicy] Will update list: official
console.info: [RequestPolicy] Updating [SubscriptionList official https://raw.githubusercontent.com/RequestPolicyContinued/subscriptions/master/official.json]
Also, since today I'm getting this error message printed to console/syslog:
console.error:
[RequestPolicy] Fatal Error:
console.dir:
Message: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIURI.asciiHost]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://rpcontinued/content/lib/request.js :: Request.prototype.isInternal :: line 76" data: no]
Stack:
Request.prototype.isInternal@chrome://rpcontinued/content/lib/request.js:76:1
NormalRequest.prototype.isInternal@chrome://rpcontinued/content/lib/request.js:160:14
self.process@chrome://rpcontinued/content/lib/request-processor.js:262:17
self.shouldLoad@chrome://rpcontinued/content/main/content-policy.js:60:16
This happened 5 times today, but I cannot tell you when it happened, i.e. I don't have a reproducer.
@genodeftest which browser and version are you using?
Nevermind, I found the problem. It ought to be solved in the next pre-release.
Thanks!
@genodeftest which browser and version are you using?
That was Firefox 56.0 x86_64 from Fedora 26 repositories.
It took quite sometime to find this tracking bug as others are closed but still mentioned in bugs/tickets elsewhere. I did comment on one but not others.
The latest prerelease version does not bootstrap correctly, see #862.
Hello,
I'm glad to see that RP maintenance is still handled by someone.
Actually I did not see this ticket before a few days ago, and had started on rewriting RP in WebExtension myself (with my little JS experience).
I thought it would require a complete rewrite for the transition from XUL/XPCOM. But from reading this conversation, it seems not.
I don't even see how Firefox is going to trash the old model anytime soon, with so much extensions not being migrated yet.
Hi @LiamZ
and had started on rewriting RP in WebExtension myself
did you publish some code? are you interested in helping me with migrating? i could need some help :)
I thought it would require a complete rewrite for the transition from XUL/XPCOM
not all code needs to be rewritten. of course, all the api stuff must be changed, but I'm doing it step-by-step.
I don't even see how Firefox is going to trash the old model anytime soon, with so much extensions not being migrated yet.
I think they will…
I didn't publish anything yet.
I just have a WebExtension written from scratch that displays a panel similar to the official one.
A request count is displayed too (I found that easier to setup than I thought).
But all that is just a small part.
I would be glad to be of help.
I'll have trouble understanding the existing XPCOM code, having never made an add-on myself.
I'll check the dev channel to see if I'm able to assist.
If someone can't wait for the WebExtension, there is uMatrix that can prevent CSRF and protect privacy by blocking third-party requests.
And also uBlock Origin's expert mode. I don't think RequestPolicy is much different here so I'm not sure whether it will just be duplicate work.
And also uBlock Origin's expert mode. I don't think RequestPolicy is much different here so I'm not sure whether it will just be duplicate work.
The main, inherent difference between RP and all other blockers I know is the "other origins" feature.
Sharing as one who has used RP and then RPC quite a bit. While I did use uorigin and some of the other extensions as well, I found the interface easier. I haven't tried out umatrix and probably would hang around to see if the WE port gets completed before trying something else.
What I found easy (after the initial learning curve) is that RPC gives a great service. One of the few quibbles I have is sometimes I have to give *.domainname for origin and sometimes *.domain.subdomain or something along those lines and it's a bit of hit and trial at times to see which will work to get rid of third-party requests to a site.
@shirishag75 I totally agree with you, RPC is a great tool but sometimes it is difficult to find which domain to allow to not screw up entirely a website (for instance CDN or any domains used to serve CSS or images).
Maybe after the port one possible enhancement may be to indicate what kind of resources is queried from a given domain. The WE API gives these info in the details param of webRequest.onBeforeRequest (see the type attribute which is a webRequest.ResourceType).
If you folks agree with that, the best would be to open a separate issue I guess :-)
I plan to finish WE transition by the end of Feb'18 at the latest. If you are a developer, please consider helping with the transition. Thank you @jrrdev for your contributions so far! 👌 :)
I just wanted to let you know, that I am really looking forward to see RequestPolicy in Firefox Quantum! It's the best add-on I a have and now I can't use it. So sad :-(.
When I click on the URL at the top of this page, I do not see a "developer channel" link.
If I go to https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/versions/beta then all I see are "This add-on is not compatible". Downloading a file and doing a manual install does not work.
Upgrading to 57 is the only way to combat the Spectre bug in Firefox.
@yellowpattern wrote:
Upgrading to 57 is the only way to combat the Spectre bug in Firefox.
If you are not using Firefox 57, you really should be using Firefox ESR 52.x, which is safer to use and not affected by at least one of the Spectre bugs.
If I go to https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/versions/beta then all I see are "This add-on is not compatible".
What browser and version are you using? Navigate to about:support if you don't know.
@myrdd : I can reproduce the "This addon is not compatible" issue with Firefox 57, which is expected.
JFTR I made a blog post about RPC at https://flossexperiences.wordpress.com/2018/01/06/site-genuiness-and-requestpolicy-continued/ . While this probably is not the best place to mention it, I am tired hence putting it here. Feel free to comment if there might be something I missed.
@genodeftest you're right, that's expected.
@shirishag75 if you want, you can create a new wiki page called "external resources" and put a link to your blog post there. :)
I've created issue #884, which should be quite easy to work on with just a little JS knowledge.
FYI - there are 2 addons which work on FF57. This and this.
Source: https://addons.mozilla.org/en-US/firefox/search/?q=RequestPolicy
And uBlock Origin works quite similar, if you configure it that way (remove all lists, set "external requests" to "deny" for all sites).
uBlock Origin in advanced mode or uMatrix both have RequestPolicy functionality. However RequestPolicy had similar interface as NoScript so it was easier to understand. Hope the F57 version doesn't differ much.
@myrdd I can't find a pre-release version for F57 in AMO even trough it says in description. Is there one currently ? If not please let us know if/when we can help with beta tests.
I really appreciate your time and effort. Thank you for continuing the addon.
uBlock Origin in advanced mode or uMatrix both have RequestPolicy functionality.
Mostly. They do not have the concept of "other origins".
I can't find a pre-release version for F57 in AMO even trough it says in description. Is there one currently ?
The pre-release version is not yet Fx57+ compatible.
If not please let us know if/when we can help with beta tests.
I will. Thank you! :)
They do not have the concept of "other origins".
At least uBlock Origin has.
There's a toggle for resources from third-party sites.
Let's please discuss RP and other addons there: #692 (comment)
I guess we just have to wait. it out. There doesn't seem to be any new commits after the last commit on 18th December 2017 https://github.com/RequestPolicyContinued/requestpolicy/commits/develop
New pre-release available here: https://addons.mozilla.org/en-US/firefox/addon/requestpolicy-continued/versions/1.0.beta13.2.2106.r3a96ef0aa.pre
No new features, just a step towards the WE port.
Thanks to @jrrdev, who contributed to this pre-release.
From now on, the pre-releases will be available here:
https://sslsites.de/requestpolicy.256k.de/requestpolicy-nightly.xpi
Be sure to disable or uninstall any other RP/RPC versions!
A new pre-release is available. Please install/use it and report any issues.
(weApi.storage and weApi.privacy.network are done, see #893)
I get an error about compatibility when I attempt to install it:
What is the plan about the first (pre-)release that is supposed to work with Firefox > 56 ?
I am just a user not a developer.
@myrdd what is the version of requestpolicy.xpi at https://sslsites.de/requestpolicy.256k.de/requestpolicy-nightly.xpi
I had to do the following -
$ wget https://sslsites.de/requestpolicy.256k.de/requestpolicy-nightly.xpi
--2018-05-21 07:14:04-- https://sslsites.de/requestpolicy.256k.de/requestpolicy-nightly.xpi
Resolving sslsites.de (sslsites.de)... 80.67.16.21
Connecting to sslsites.de (sslsites.de)|80.67.16.21|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 394409 (385K) [application/x-xpinstall]
Saving to: ‘requestpolicy-nightly.xpi’
requestpolicy-nightly.xpi 100%[=================================================>] 385.17K 271KB/s in 1.4s
2018-05-21 07:14:07 (271 KB/s) - ‘requestpolicy-nightly.xpi’ saved [394409/394409]
$ mkdir requestpolicy
shirish@debian:~$ mv requestpolicy-nightly.xpi requestpolicy
and then -
$ cd requestpolicy/
~/requestpolicy$ unzip requestpolicy-nightly.xpi
I did see this in install.rdf -
<!-- Firefox -->
<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>45.0</em:minVersion>
<em:maxVersion>56.*</em:maxVersion>
</Description>
</em:targetApplication>
I am trying to figure out the versioning of requestpolicy-nightly.xpi and not knowing where to look as well as a Changelog.
Update - I found the version info. as RequestPolicy Continued 1.0.beta13.2.2277.r4d80b1f76.pre but that was by installing it :(
I ran the new version under Firefox 52.8.0 and this is what firefox tells me under the hood -
$ firefox
1526867826034 addons.xpi WARN Failed to call uninstall for rpcontinued@amo.requestpolicy.org: Error: Unknown add-on ID rpcontinued@amo.requestpolicy.org (resource://gre/modules/addons/XPIProvider.jsm:8303:11) JS Stack trace: DirectoryInstallLocation.prototype.getLocationForID@XPIProvider.jsm:8303:11 < this.XPIProvider.processPendingFileChanges@XPIProvider.jsm:3409:31 < this.XPIProvider.checkForChanges@XPIProvider.jsm:3745:19 < this.XPIProvider.startup@XPIProvider.jsm:2830:25 < callProvider@AddonManager.jsm:237:12 < _startProvider@AddonManager.jsm:790:5 < AddonManagerInternal.startup@AddonManager.jsm:976:9 < this.AddonManagerPrivate.startup@AddonManager.jsm:3033:5 < amManager.prototype.observe@addonManager.js:65:9
1526867826034 addons.xpi WARN Attempted to remove rpcontinued@amo.requestpolicy.org from app-profile but it was already gone
console.log: [RequestPolicy] starting up
console.error:
[RequestPolicy] Error when saving to storage! Details:
console.dir:
Object
- lastAppVersion = 52.8.0
- lastVersion = undefined
console.dir:
Message: Error: Invalid type <undefined>. Value is "undefined".
Stack:
PrefBranch.prototype.set@chrome://rpcontinued/content/bootstrap/api/storage/pref-branch.js:52:23
CachedSettings.prototype.set/<@chrome://rpcontinued/content/app/storage/cached-settings.js:91:17
CachedSettings.prototype.set@chrome://rpcontinued/content/app/storage/cached-settings.js:90:13
VersionInfoService.prototype.startupSelf/<@chrome://rpcontinued/content/app/services/version-info-service.js:98:20
console.error:
[RequestPolicy] [app.services.versionInfo] Failed to initialize VersionInfoService
console.dir:
Message: Error: Invalid type <undefined>. Value is "undefined".
Stack:
PrefBranch.prototype.set@chrome://rpcontinued/content/bootstrap/api/storage/pref-branch.js:52:23
CachedSettings.prototype.set/<@chrome://rpcontinued/content/app/storage/cached-settings.js:91:17
CachedSettings.prototype.set@chrome://rpcontinued/content/app/storage/cached-settings.js:90:13
VersionInfoService.prototype.startupSelf/<@chrome://rpcontinued/content/app/services/version-info-service.js:98:20
I am on Debian testing and have only two options -
$ apt-cache policy firefox-esr
firefox-esr:
Installed: 52.8.0esr-1
Candidate: 52.8.0esr-1
Version table:
60.0.1esr-1 100
100 http://cdn-fastly.deb.debian.org/debian experimental/main amd64 Packages
*** 52.8.0esr-1 900
900 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages
100 http://cdn-fastly.deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
or
$ apt-cache policy firefox
firefox:
Installed: (none)
Candidate: 60.0.1-3
Version table:
60.0.1-3 100
100 http://cdn-fastly.deb.debian.org/debian unstable/main amd64 Packages
RPC is the only one which is keeping me from jumping onto firefox 60.x
Have another query, why can't we have all the issues under WE port https://github.com/RequestPolicyContinued/requestpolicy/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22WebExtension+port%22 put up so people know what is being worked upon .
Hi, does this project need a hand? If so, how can I help?
seems to have stalled, I downloaded the add-on today again just to see if there had been any difference -
$ wget -N https://sslsites.de/requestpolicy.256k.de/requestpolicy-nightly.xpi
Saw when it was last put up there -
$ ls -lh requestpolicy-nightly.xpi
-rw-r--r-- 1 shirish shirish 386K Apr 27 12:11 requestpolicy-nightly.xpi
And then installed it thinking maybe a new version might have come in but no, seems to be stuck at RequestPolicy Continued 1.0.beta13.2.2277.r4d80b1f76.pre which I had tried before :(
fourpoint7: If you have the time simply choose a task from
https://github.com/RequestPolicyContinued/requestpolicy/milestone/19
and keep everyone updated.
myrdd: Any signs of life? :)
This plugin I miss the most... There is an attempt of minimum barely usable re-implementation: requestblock.
umm... it seems @myrdd has started picking pace again. See #754 (comment) , https://requestpolicy.256k.de/requestpolicy-nightly.xpi . I extracted the .xpi (which is an archive) and the manifest.json reads version": "1.0.beta13.2.2447.r20582e0a6.pre so at least one more release was made. I do see that he has also being doing commits regularly so hopefully be the end of the year or whenever we should have a brand new release sometime soonish (that's what he seems to be aiming for).
nightly build has version number 1.0.beta13.2.2462.r2f19aa957.pre - where is the 1.0.beta14.0 ?
@cheggerdev you have to build it yourself using nodejs/npm. I did it sometime back but it still falls short of being able to install on firefox 57 or/and later :( even after allowing unsigned extensions (which is bad policy security-wise. ) I think you will find my instructions on the issue referenced above, issue 900.
I care about getting this fixed, so I'm offering USD 50 via FreedomSponsors to the first person who fix it.
You can also join me and throw in a few bucks there and we'll get it fixed faster :)
If you fix this issue (see my acceptance criteria there) please use that site to request your payment.
I cannot install a nightly build. Firefox blocks the installation because the verification failed.
Error message (German language):
you can fix that by going in about:config and looking for xpinstall.signatures.required , toggle it to false.
But that still would not fix it if you are using it in firefox 60. I think it works in firefox 52.0.x series only.
shirishag75: No, does not work for me. I still get the same error. Even a restart of Firefox (Version 56) does not work.
One other thing you can try is to open the browser console as I had, see #900 if you still get the issue then you know the problems that are there. From what little I know of firefox anything from firefox 53 and later is/was supposed to be web-ext friendly .
I have shared one of the popular web-extensions that I use tree-style-tab as to how it is -
https://paste.debian.net/1047280/
the .xpi file that you have before you is nothing but an archive or more commonly a .zip file of sort. You could easily rename it from request-policy.xpi to request-policy.zip and see how the two extensions differ.
There are at least three bugs that you would need to fix/port over that I know that need fixing before it could be called a web-extension -
#863, #891, #893, #894 are the four bugs that need to be fixed . Martin has made some documentation so you or whoever wants to wet their feet wet in https://github.com/RequestPolicyContinued/requestpolicy/wiki/Setting-up-a-development-environment and https://github.com/RequestPolicyContinued/requestpolicy/wiki/Building , there are other pages but do not know how relevant they would be after Mozilla re-used web-extension add-ons which are used by other browser vendors.
See https://wiki.mozilla.org/WebExtensions#Status and they have put whole lot of documentation and care into giving budding extension developers a leg up. See https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Getting_started_with_web-ext and https://github.com/mdn/webextensions-examples
In a nutshell, if you succeed at making a web-extension porting it other browsers in theory should be a child's play. The benefit to users and developers is that dodgy extensions are easily called out, the reality may be a bit more complex.
Browser Console brings these error messages:
1539617398541 addons.xpi WARN Add-on rpcontinued@non-amo.requestpolicy.org is not correctly signed.
1539617398541 addons.xpi WARN Download of https://requestpolicy.256k.de/requestpolicy-nightly.xpi failed: signature is required but missing
I think you have not really read the above messages, 4-5 bugs need to be fixed before it can be firefox 57+ compatible, till that time it will NOT work.
See https://github.com/RequestPolicyContinued/requestpolicy/milestone/19
I know that. I am using Firefox 56.
if you look at his commits he is still fighting the fallout from Firefox 48.0.x still.
https://github.com/RequestPolicyContinued/requestpolicy/commits/develop
Same problem here with Fx 48.0.2, no matter what is set in xpinstall.whitelist.required and xpinstall.signatures.required version 14.0 refuses to install.
@wilkowy your best bet is to make a new issue, share how you built it, if possible share the SHA1sum of the built extension and the output in browser-console when you try installing it in firefox 48.0.2 . Do make sure you have his latest commit shared last around 12 days ago which results in a build version 1.14.0 and not any lower version. Hopefully @myrdd may be able to help you.
@cheggerdev @wilkowy yes, please report your build & install problems in a new issue. Include the versions of the installed build requirements as well as the exact git commit you're using in your report. And, as @shirishag75 mentioned, you best add the sha1sum as well.
with Fx 48.0.2, no matter what is set in
xpinstall.whitelist.requiredandxpinstall.signatures.requiredversion 14.0 refuses to install.
depending on the firefox updating mechanism of your firefox installation you might need to lock some preferences to prevent updates: (you need to do this e.g. if you've installed any firefox release from here.)
// this file must start with a comment!
lockPref("app.update.auto", false);
lockPref("app.update.enabled", false);
FYI I started documentation on different installation methods on the wiki:
https://github.com/RequestPolicyContinued/requestpolicy/wiki/Installing
to keep this issue clean, from now on please use #902 for anything doc/wiki-related
btw @shirishag75 I use to read comments in my mailbox, and this way I don't get notified about edits on your comments, even if made few minutes after. pls try to put all info into the comment before publishing the comment.
Is there any progress since October 2018?
Is there any progress since October 2018?
I don't think so, see https://github.com/RequestPolicyContinued/requestpolicy/commits/develop
Sadly, no 😞 but thank you for passing by once again. This tells me I'm not the only person missing this add-on. 👀
I'm about to improve (once again) my personal time and priorities management.
BTW, friendly ”pings“ are often motivational to me 😉
I like to send a friendly ping to you Martin.
The time has come, as I'm still of FF56 only for RPC. But now they disabled a lot of my add-ons and at least this forces me to update to the latest FF. I think many are reading here, without logging on. I especially created an account for this comment.
I will miss RPC a lot. Maybe I switch my current profile to waterfox.
Thanks and cheers from Germany too.
@SiliconAlley I started using uMatrix which has similar features to block third-party requests, in addition to cookies and JavaScript. It also has a protection to avoid leaking the Referer HTTP header for better privacy. It may help you as an alternative addon to RequestPolicy.
Thanks @baptx, installed on my company notebook already, where I run the latest FF and miss RPC.
Just to mention here: Mozilla will fix add-on signing issue for older Firefox versions
@SiliconAlley try setting xpinstall.signatures.required to false. This disables signing requirement.
@SiliconAlley @wilkowy : This setting will only have an effect on nightly/alpha and some custom builds of Firefox (e.g. the version shipped with Fedora Linux).
Just to share @myrdd did release a new pre-release of RPC yesterday. I renamed it as 1.0.beta14.1.2485.r6d27d1e5.pre.xpi as that commit id was mentioned in manifest.json for the release. While it still doesn't get installed it I am sure @myrdd made some more changes, for us it would be usable only when the whole thing is ported to the webextension. FWIW, I did toggle xpinstall.signatures.required to false in about:config but still was unable to install it. Best of luck to @myrdd to getting the other pieces of the extension ported to changes in mozilla upstream. Hope it will work with Firefox 68.0.x the latest ESR stable from mozilla .
Hello @myrdd! I normally wouldn't post a low-value comment like this, but you did specifically say this: 😄
Sadly, no 😞 but thank you for passing by once again. This tells me I'm not the only person missing this add-on. 👀
I'm about to improve (once again) my personal time and priorities management.
BTW, friendly ”pings“ are often motivational to me 😉
Barely a day goes by (yes, still in December 2019) that I don't miss this extension. I've been using "Third-Party Request Blocker" (https://addons.mozilla.org/en-US/firefox/addon/tprb) but...it's just not the same.
Is there anything a non-developer can do to help make RPC a reality again? Pretty please? 😄
@SiliconAlley I started using uMatrix which has similar features to block third-party requests, in addition to cookies and JavaScript. It also has a protection to avoid leaking the Referer HTTP header for better privacy. It may help you as an alternative addon to RequestPolicy.
Since uMatrix is not supported anymore, I am using uBlock in advanced strict mode and NoScript to block JavaScript. For cookies blocking I am currently using the built-in cookies blocker of Firefox in strict mode. Blocking the Referer HTTP header can be done with the addon Header Editor (which supports request and response headers).
There are pages mentioning that uBlock can be used as a replacement to RequestPolicy:
https://github.com/gorhill/uBlock/wiki/Advanced-user-features
https://github.com/gorhill/uBlock/wiki/Dynamic-filtering