Skip to content
This repository was archived by the owner on Nov 15, 2017. It is now read-only.

Change log

Jump to bottom
Raymond Hill edited this page Jul 17, 2014 · 994 revisions

Starting with version 1.0.0.2, the log will now be at the Releases page. This is the proper Github way to release versions. Thanks to mikhaelkh for the tip.

1.0.0.1

1.0.0.0

0.9.9.1

0.9.9.0

0.9.8.0

0.9.7.1

The end

  • Can't help it: I keep wondering how to improve it.
  • Priority: To not let feature creep turn this into a mess.

0.9.7.0

0.9.6.0

0.9.5.6

0.9.5.5

0.9.5.4

0.9.5.3

0.9.5.2

0.9.5.1

0.9.5.0

  • Release date: 23 May 2014
  • New feature: When installing the extension for first time, users will be presented with a list of "flavoured" configurations to help them get started
    • Breakage refers to the likeliness of web pages to not render and/or behave as expected
      • Block all / allow exceptionally (default mode) => Security: very high, Breakage: high
      • Allow all / block exceptionally => Security: medium, Breakage: medium low
      • Ad blocker-like => Security: low, Breakage: low
      • NoScript-like => Security: high, Breakage: high
      • RequestPolicy-like => Security: medium high, Breakage: high
      • Block nothing / report everything => Security: none, Breakage: none
    • These are merely starting points, user can customize at will afterward
    • For users who already have an existing implementation, this setup page can still be accessed from the About tab in the dashboard: click the Start from scratch... button.
    • Important: Keep in mind that loading a predefined configuration is similar to restoring all your settings and data, which means everything will be overwritten.
      • So if you just want to just try these configurations, be sure you have a back up of your data.
  • Fixed a bug in the parsing of cosmetic filters which prevented exception filters to work.

0.9.4.4

And while I have your ear, I want users to be reassured that the new cosmetic filters feature is not a "broken implementation" as suggested by Wladimir Palant. It's pure fabrication.

Similarly, his "potentially significant hang when the page loads" "concern" is pure nonsense, given that ABP does magnitudes worst to inject its thousands of CSS rules. In worst case scenarios, HTTPSB does at most a couple hundreds iterations, which consist of tightly optimized look-up operations (fast) in order to narrow the number of CSS rules to inject to a handful.

Injecting the CSS rules IS the expensive operation, hence you want to minimize this as much as possible. ABP injects 20,000 of these CSS rules indiscriminately, so expressing "concerns" that HTTPSB may end up looping 500 times performing fast look-up operations is just plain intellectual dishonesty.

Everything is in the open on Github, with time stamps, etc. Any developer who can read javascript will be able to confirm everything I wrote in my original article. I wish this will happen.

My only mistake was to think the ABP developers would be happy I found and shared a solution to their problem of indiscriminately injecting 20,000 CSS rules on every page and frames on that page.

0.9.4.3

0.9.4.2

0.9.4.1

  • Release date: 18 May 2014
  • Fixed a couple of quirks (here and here) in the implementation of ABP cosmetic filters.
    • It doesn't affect at all benchmark results shown there).

0.9.4.0

0.9.3.0

  • Release date: 17 May 2014
  • New feature: Due to popular demand, I added a new option in the Settings tab: "Blocked frames color (any valid CSS color):" along with a text input field to enter a valid CSS color value.
    • Default is rgba(204, 0, 0, 1), i.e. as it was before internally.
    • Example of valid CSS color values: silver, #c00, rgba(192, 192, 192, 0.2) (note the opacity value), etc.
    • Reference for CSS color: http://www.w3.org/TR/css3-color/#html4
    • Beware: I personally believe that hiding blocked frames from view is a bad idea (hence my resistance to implement the feature). So whether blocked frames are visible or not is now completely up to you.
    • If you really want to completely render invisible blocked frames, the CSS color name is transparent.
    • As of now there is no code to validate whether the CSS color you enter is valid. If is not valid, result will likely be invisible blocked frames, so be careful.
    • To reset to factory color, just empty the input filed and press return: the field will be filled with factory color rgba(204, 0, 0, 1).
    • I have to admit, it is a nice feature to have... I ended using it, my color: rgba(204,204,204,0.8).
    • Note: After v0.9.3.0 was published, my-password-is-password found a fix for the slight visual glitch visible in the pattern. It's not worth to release a new revision just for this, but I will include the fix in the next release.
  • More work on performance and code review.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/135: "Change the colour of the blocked frame to grey".

0.9.2.1

  • Release date: 16 May 2014
  • This revision accommodates Opera web store.
  • No issue fixed, but as the extension is heading toward version 1.0, I will spend more time code reviewing (and making changes if needed), benchmarking (memory, cpu), etc.
  • For technically minded individual, changes can be seen in the commit history (I can't open an issue for every little code revision resulting from above-mentioned code review).

0.9.2.0

0.9.1.2

0.9.1.1

0.9.1.0

0.9.0.0

  • I care about backward compatibility, but apparently I failed this time. It has come to my attention that a user had its settings for auto-create scope disabled, despite me having put code in there to translate the old internal setting into the new one. I still do not understand how this code can fail, but in any case, my apologies for this fumbling. (I could fix the problem, but I suppose it is too late at this point, so simplest workaround is to go to the Settings tab a re-select your choice of scope auto-creation -- domain is now the preferred choice.)
  • Release date: 27 April 2014
  • Changed feature: You can now choose to auto-create domain- or site-level scopes (before only site-level scope was available).
    • I figure this was required as in general, a domain-level scope offers an optimal balance between usability and security.
    • The security gain from using global scope to using a domain-level scope is huge.
    • The security gain from using a domain-level scope to using a site-level scope is marginal in most cases.
    • The convenience gain of using a domain-level scope rather than a site-level scope is significant.
    • For instance, it is quite common for a web site which requires logging in to use HTTP redirect directives from one subdomain to another.
      • Example: log in on login.example.com, end up on members.example.com.
      • With a site-level scope set to login.example.com, the login operation would fail because whatever whitelist rules were created in the login.example.com scope do not apply to the members.example.com scope.
      • This is where domain-level scope is great, as whatever whitelist rules created in *.example.com apply both to login.example.com and members.example.com.
      • A real life example of this particular issue was raised recently: https://github.com/gorhill/httpswitchboard/issues/249 (French).
    • Therefore aute-creation of domain-level scopes is now considered the preferred way of using HTTPSB. Defaults are left unchanged though, as I want to further evaluate whether auto-scoping should be enabled out of the box.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/250: "Let the user choose whether site- or domain-level scopes should be auto-created".

0.8.9.3

0.8.9.2

0.8.9.1

0.8.9.0

  • Release date: 24 April 2014
  • New privacy feature: User-Agent spoofing.
    • Available in the Settings tab:
      • Enable/disable (disabled by default)
      • An input field to choose at which interval (minutes) to randomly pick a new user agent string
      • A text area so you can enter your own list of user agent strings from which to randomly pick
        • Enter nothing to blank the user agent string (not recommended)
        • Enter a single user agent string to force a particular one
        • Enter many to cycle randomly through them, as per your supplied interval
        • I put in a couple of default user agent strings I found while browsing around, but I suggest you pick your own user agent strings going forward. There are various sources out there: you choose.
        • Don't go overboard with the number of user agent strings, a handful of the top most common strings is just enough to accomplish the purpose.
        • Prefixing a line with # will cause the line to be ignored
    • Of interest: EFF: "Browser Versions Carry 10.5 Bits of Identifying Information on Average"
  • Version française maintenant complète après la révision finale de tailHey
  • Fixed https://github.com/gorhill/httpswitchboard/issues/100: "Ability to neutralize User-Agent string for enhanced privacy" (as per above)

0.8.8.2

0.8.8.1

0.8.8.0

  • Release date: 21 April 2014
  • New option in the Settings tab: "Auto delete unused temporary scopes".
    • Disabled by default.
    • Especially useful for users who have enabled "Auto create temporary site-level scopes".
    • A temporary scope (which has no permanent counterpart) won't be deleted immediately after the web page for which it applies is closed. It will linger a bit, and if it still unused after 20 minutes or so, it will then be removed from memory.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/229: "Auto-reload only current tab".
    • The user has now the choice to smart reload: None, Current, or All (default).
    • Just a reminder: smart reload ensures that only the pages which are affected by a change in the matrix will be reloaded. The feature here gives the user the choice of which set of pages are going to be candidates for smart reload.
  • I changed the appearance of the filtering switches when in their off state: These switches are kind of important, so they need to stand out more if switched off.

0.8.7.1

0.8.7.0

  • Release date: 18 April 2014
  • The master switch is gone.
  • A new "matrix filtering" switch is now available, and it is scope-based (see it as a master switch, but it applies only to the current scope).
    • Since now matrix filtering can be turned off for a specific scope, the chromium-behind-the-scene scope will come out-of-the-box with matrix filtering turned off, in order to guarantee that, out-of-the-box, HTTPSB does not interfere with the browser or other extensions.
    • There were cases of extensions being broken by HTTPSB despite the chromium-behind-the-scene scope defaulting to allow-all/block-exceptionally, because some of the hostnames the user was feeding another extension were ubiquitously blacklisted.
    • For existing users, matrix filtering will be on by default for all scopes, including the chromium-behind-the-scene scope, to ensure there is no change in behavior with your existing installation.
  • Adblock Plus filter syntax is now supported as user-supplied ubiquitous rules.
    • You can mix and match plain hostname rules with Adblock Plus filter rules.
    • "One hostname per line" becomes "One rule per line".
    • Respect proper and sane ABP-filter syntax and all should be fine.
      • Remember: garbage in, garbage out, so if you feed HTTPSB garbage rules, HTTPSB's behavior as a result is undefined.
    • Be mindful that not all ABP filter syntax is supported.
  • The HTTPSB entries in the browser's contextual menu (right-click) have been removed: I found out they were not working correctly due to the many changes which have happened since the contextual menu code was released. More thoughts are needed before I fix and put back these contextual menu entries. Probably not many users were relying on the contextual menu since nobody reported it wasn't working properly.
  • New wiki page for an overview of HTTPSB's filtering engine
  • Fixed https://github.com/gorhill/httpswitchboard/issues/234: "Per-scope switch to disable all ubiquitous blocked hosts".
  • Fixed https://github.com/gorhill/httpswitchboard/issues/232: "Allow user to supply his own ADP-compatible filters".

0.8.6.4

  • Release date: 15 April 2014
  • No changes for existing users.
  • Removed Fanboy lists from out-of-the-box default selected ubiquitous lists. Because this.
    • I personally use the Fanboy lists, however these are causing a bit too much material to be blocked, especially annoying for a new user who chooses to use HTTPSB in allow-all/block-exceptionally approach.

0.8.6.3

0.8.6.2

0.8.6.1

0.8.6.0

0.8.5.6

0.8.5.5

0.8.5.4

0.8.5.3

0.8.5.2

0.8.5.1

0.8.5.0

0.8.4.8

0.8.4.3 0.8.4.4 0.8.4.5 0.8.4.6 0.8.4.7

0.8.4.2

  • Fixed a bug which could potentially occur when loading the various ubiquitous lists, causing the extension to break:
  • Further performance and memory footprint improvements to the code dealing with Adblock Plus complex filters.
    • Reaching optimal performance is a requirement in order to support more complex filter syntax, i.e. wildcards, options, etc.

0.8.4.1

  • Fixed potential false negatives (in rare circumstances) when evaluating against Adblock+ complex filters.
  • Simplified Adblock+ complex filters-related code.

0.8.4.0

  • First, an apology for having dismissed too quickly a good suggestion a while ago.
  • Adblock Plus ("ABP") complex filters (those which parse into more than just "block a whole domain") can now be parsed and used to block web requests:
    • Optional, disabled by default. Can be turned on from Ubiquitous rules tab in the Dashboard.
    • Consider this a beta feature.
    • Especially handy for users who prefer to work in allow-all/block exceptionally mode
    • Not all ABP complex filters are parsed:
      • Those with options are currently ignored (working on it, as time permit).
      • Those with regular expressions are currently ignored (probably will support partially, i.e. * only): these are rare instances and their use is discouraged anyway).
      • Filters used to hide elements are ignored (undecided whether I will ever implement since it requires modifying the DOM).
      • Filters used to whitelist something -- like "acceptable ads" -- are ignored (will never implement).
    • ABP complex filters are not reflected in the matrix (except obviously for those which apply on a whole domain). There is no user interface to enable/disable a single ABP complex filter.
      • Rules from HTTPSB have precedence. If a request is evaluated as "allowed" by HTTPSB, it is then further evaluated using ABP filters.
      • The only way to disable a single ABP complex filter is to disable the parsing of all complex filters, or to disable the whole list in which the filter appears. ABP complex filters are not affected by preset recipes.
      • The number of requests effectively blocked by complex ABP filters is reported in the Statistics page in the Dashboard, so that you can get a sense of whether ABP filters are worth parsing and enforcing, given the extra memory use.
      • The added overhead of evaluating an ABP complex filter is small, around 30 µs. (I did not revise this yet to reflect the new timings.)
    • The main point of this feature is that you are still using ABP along HTTPSB, HTTPSB gets closer to be a complete replacement solution to ABP.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/198.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/197.

0.8.3.0

  • Assets used by HTTPSB can now be updated without having to wait for a new release of the extension.
    • From the About tab of the extension's Dashboard.
    • "Assets" refers to:
  • Significantly reduced memory footprint.
    • Not that there wasn't any memory leak, just that for this release, I chose to spend more time on code revision and refactoring instead of just features -- a necessary recurring task in order to ensure the code doesn't drift too far away from sanity. This allowed me to put to test and validate some ideas I was entertaining since a long time regarding memory footprint.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/179.

0.8.2.1

0.8.2.0

0.8.1.3

  • Workaround for Yandex's improper rendering of float element in toolbar of extension pop-up.

0.8.1.2

  • Fixed auto-whitelisting of Youtube at install time for Opera 19.

0.8.1.1

  • Minor revision: The mini pop-up menu in the pop-up of the extension giving access to Rule manager, Settings, Documentation and On/off buttons has been removed and the buttons are now directly accessible in the extension pop-up toolbar as Dashboard, Documentation and On/off buttons on the far right.

0.8.1.0

0.8.0.1

  • Replaced all preset recipes for Google various services with one single preset recipes which "unbreak" all Google various services.
    • Turns out, it's just way too much time-consuming to try and create specific set of rules for each specific Google service.
    • At least, it is scoped, so Google servers won't be pinged when not on a Google-owned web page.
    • That's the point of domain-level scopes anyway, so I will just use one for Google.

0.8.0.0

Clone this wiki locally