We are no longer providing signed and updated development builds for Adblock Plus. But if you want to try out the latest features you can use the unsigned builds from GitLab CI, they won’t automatically update and might get disabled as you restart your browser though.
End of 2019, the Chrome Webstore began to manually review each submission with delays varying from days to months. Also the Chrome Webstore refuses new submissions while there is a pending submission in review. This just doesn’t work for a continuous release channel like our development builds. As a consequence our development builds on the Chrome Webstore became useless.
Only a small subset of our users are on Firefox nowadays, hence the number of development build users on Firefox became vanishingly small. Moreover, providing development builds for Firefox has been a challenge recently, as Mozilla changed the distribution method twice in two years. So at this point, there isn’t much incentive to keep up a complex development build infrastructure for Firefox only. We apologize to our few remaining development build users on Firefox.
For our own QA we moved to testing the unsigned builds generated by our CI. There are some caveats but at least we are in control of the builds, and the builds are available instantly.
For users who want to try out the latest features, our development builds have not been very useful recently. Most of the time our development builds contained the same code as our release builds, since new changes land in our development branch (next), and then make their way into our staging branch (master) and into our development builds as we start testing an upcoming release.
On the upside, this is no longer an issue with the builds from our CI as there are builds for each revision in every branch. On the downside, being distributed off-store those builds can only be installed in development mode, and don’t automatically update, which renders them rather unpractical for normal usage.
]]>http://
URLs will stop syncing. If you are a filter list maintainer affected by this change, you can migrate any of your current subscribers over by following the steps below:
http
s
://
URL, the next step would be to migrate your existing subscribers. In order to do this, add the special comment ! Redirect: <URL>
at the top of the old filter list (still being served over unencrypted HTTP!), replacing the <URL>
part with the new subscription URL. For example, if your old list is at http://example.com/list.txt
and you have made the new list available at http
s
://
new.
example.com/list.txt
, the comment would be ! Redirect: http
s
://
new.
example.com/list.txt
. The next time the extension attempts to synchronize the old subscription, it will automatically replace it with the new one.In order to make the transition as smooth as possible for any filter list maintainers still on unencrypted HTTP, we are going to allow a period of at least 31 days starting today before we make the switch in the release version.
As always, any feedback about this change is welcome.
]]>http://
URLs will stop syncing. If you are a filter list maintainer affected by this change, you can migrate any of your current subscribers over in a few simple steps.]]>$~collapse
(element collapsing is enabled by default, the tilde negates the option) blocked requests without hiding the associated element, causing a placeholder to show up. Historically, this made it more difficult for some websites to detect the presence of an ad blocker. However, this filter option is currently largely unused. Hence we decided to unsupport that feature (core#1).
On Firefox, the $object-subrequest
filter option only targeted requests sent by content that is managed by plugins like Flash. However, other browsers never allowed extensions to distinguish requests loading the component managed by a plugin from subsequent requests sent by that component. So on Chromium-based browsers, the $object
and $object-subrequest
filter options always had the same effect. With the decrease in relevance of plugins like Flash, and lack of cross-browser support, there is now a stronger case for consistent filter behavior across browsers than slightly more fine-grained request matching on Firefox only. So with this change (core#6), the $object
filter option will match all requests related to plugins on all browsers.
Note that filters using the $collapse
or $object-subrequest
filter options will become invalid and have no effect in upcoming versions of Adblock Plus. We advise filter list authors to update their filter lists, removing any $collapse
filter option and replacing any $object-subrequest
filter option with the $object
filter option.
These changes are now visible in the development builds of as of 3.5.2.2320, and will be released with Adblock Plus 3.6 for Chrome, Firefox and Opera.
]]>$collapse
or $object-subrequest
filter options will become invalid and have no effect. We advise filter list authors to update their filter lists, removing any $collapse
filter option and replacing any $object-subrequest
filter option with the $object
filter option.]]>Furthermore, the Checksum
special comment is no longer supported (issue 6849). In fact, checksums weren’t verified anymore since Adblock Plus 3.0 for Firefox, and never were verified on any other browser. The usefulness of such a checksum is extremely limited in modern days. Filter list authors may want to remove the checksum (if any) from their filter lists. Doing so is backwards-compatible since checksums never were mandatory.
Checksum
special comment is no longer supported.]]>$rewrite
filter option to rewrite the URL of a resource instead of blocking it.
When Adblock Plus matches a request URL with a filter that has the $rewrite
option, it will transform the URL following the provided rule, and tell the browser to load the resource using this new URL instead.
The syntax of the rewrite rule is as follow: you specify a string that serves as a template for the new URL. $n
gets substituted with the regular expression n-th submatch of the filter. This is the exact same syntax as JavaScript’s String.prototype.replace() function. If the resulting URL is relative (i.e. it doesn’t have a host), the origin of the original query will be used as the base. In any case, if the new URL doesn’t share the origin, the rewrite will be considered as being failed and initial query will be let through.
Furthermore, $rewrite
filters are ignored for requests of the type SCRIPT
, SUBDOCUMENT
, OBJECT
and OBJECT_SUBREQUEST
, for security reasons.
This option is convenient to modify or strip query parameters.
Example:
||example.com/ad.gif$rewrite=/puppies.gif
This will simply rewrite the requests for “example.com/ad.gif” to be a request for “example.com/puppies.gif”
/(^https?:\/\/example\.com\/page-123\.php)\?.*/$rewrite=$1
This will rewrite the request to example.com/page-123.php stripping the query string: $1
matches “example.com/page-123.php”.
/(\/article\.asp\??)(.*&)?tracker=[^&]*&?(.*)?/$rewrite=$1$2$3
The will remove the “tracker” query parameter from the request URL.
Update (2019-04-19):
Starting with Adblock Plus 3.5, the $rewrite
filter option can also redirect the request to a set of internal resources. Starting with Adblock Plus 3.5.2, the $rewrite
filter option can only be used with internal resources. For more information, read the updated documentation.
$rewrite
filter option to rewrite the URL of a resource instead of blocking it.]]>xn--i-7iq.ws
) to Unicode (e.g. i❤.ws
), so that filters could be written using the Unicode representation (rather than Punycode).
The assumption was that filter list authors feel more comfortable spelling out internationalized domains in their native alphabet (rather than bothering about an obscure representation like Punycode). However, in practice the opposite was the case, since when inspecting the source code, the DOM or HTTP requests, internationalized domains are encoded as Punycode. Things got particularly confusing with Unicode characters that can be constructed in different ways, resulting in different Punycode, but looking the same when rendered as Unicode. Furthermore, since other ad blockers didn’t implement these semantics, some filter lists are currently specifying filters/domains redundantly both with Punycode and Unicode encoding.
Therefore we decided to require domains in filters being encoded as Punycode, starting with Adblock Plus 3.2 (and development builds as of 3.1.0.2050), which as a side effect also makes Adblock Plus a little bit more efficient (issue 6647).
There is a script, filter lists authors can use in order to convert existing filter lists.
]]>Suppressing the first run page was possible before as of Adblock Plus 2.6.10 through 2.9.1. However, the mechanism used there was specific to legacy Gecko extensions, and therefore is no longer supported since the migration to Web Extensions. If you used the old mechanism to suppress the first run page you should update your configuration now.
As an example, the following file, if saved to the respective location (operating system dependant), will cause the first run page to not show upon installation, and adds EasyPrivacy as a default filter subscription:
{
"name": "<name>",
"description": "Managed storage manifest for Adblock Plus",
"type": "storage",
"data": {
"suppress_first_run_page": true,
"additional_subscriptions": [
"https://easylist-downloads.adblockplus.org/easyprivacy.txt"
]
}
}
You have to substitute <name>
in the manifest above and its filename with the respective ID of either the Adblock Plus release version or development builds (whichever you use):
Adblock Plus release version: | {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} |
Adblock Plus development builds: | devbuild@adblockplus.org |
For reference, you can also suppress the first run page (since 1.9) and add additional default subscriptions (since 1.12) in a similar way, in Adblock Plus for Chrome.
]]>$csp
filter option is supported.
The $csp
filter option allows for the injection of additional Content Security Policies, which in turn allow for requests, frames, images, scripts and more to be blocked.
You might ask why this is useful, since we can already block requests. Well, the reason is that $csp
filters block things in a fundamentally different way which is harder for websites to circumvent. That said, $csp
filters are less fine-grained than traditional request blocking filters and so should be used as a last resort.
In fact, using a $csp filter is rather a sledgehammer approach, for example the filter ||example.com^$csp=script-src 'none'
will block all JavaScript (including inline) from running in documents loaded from the domain example.com.
$csp
filter option is supported. The $csp
filter option allows for the injection of additional Content Security Policies.]]>We are sorry for the inconvenience, but hope to keep people interested in testing our development builds and give us feedback in order to ensure the quality of Adblock Plus.
This situation is frustrating. For reference, not too long ago, we had to move our development builds to AMO, since Firefox 43 and above would no longer load extensions that haven’t been signed by Mozilla. Just later AMO allowed unlisted extensions to be signed for self-distribution. Finally they are now requiring us to migrate again to that distribution mechanism, without even providing a way to properly migrate our development build users!
]]>There are some drawbacks here. Most notably, the user interface will be more limited than what you are used to. The work improving the options page is almost done and should land soon, other parts of the user interface will follow. Still, disabling individual filters won’t be back for a while, which is why we are re-enabling any filters you might have disabled in subscriptions. Disabled custom filters will be automatically replaced by comments. We also remove any automatic backups (not the manual backups) you might have, these degrade Firefox performance and currently cannot be recovered anyway.
The other important drawback is very limited Android support. There is ongoing work both on our and Mozilla’s side here, so things should improve very soon.
]]>