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

Change log 0.6.0.0 to 0.7.9.3

Raymond Hill edited this page May 9, 2014 · 1 revision

More recent change logs.


0.7.9.3

  • Opera requires that Youtube works out-of-the-box:
    • A site-level scope for Youtube is created at install time.
    • I decided to do this for all flavors of Chromium, not just Opera.
  • Small improvements to the Remove all function in Rule manager:
    • No longer remove whitelisting of css and image rules in global scope (if they exist): that was a bit radical (users who really want these gone are just two clicks away at most from literally removing all rules.)
    • Scopes are completely flushed from memory. They used to hang around ready to be brought back to life, which is nice when playing with the scope menu in the popup, but not nice when user expects a clean slate after using Remove all.
      • This was most confusing for users who checked the Auto create temporary site-level scope option.
  • So mainly this version was to pass Opera store review process (Youtube must work at first install), I don't plan to release this one to the Chrome store, as I want to wait for a fix to issue #166.

0.7.9.2

  • Emergency fix: Due to latest changes regarding scopes, a portion of code which was not revised caused HTTPSB to fall into allow-all/block-exceptionally mode.
    • More technically, that piece of code was to whitelist all requests from behind-the-scene scope if the scope was not found. With latest changes, the behind-the-scene scope was indeed never found, and because of this the whitelist-all default rule for behind-the-scene scope was created in the global scope.
  • If you were working in block-all/allow-exceptionally mode, please do click the "all" matrix cell to toggle it back to red (if ever it is now green as in allow-all/block-exceptionally mode), and lock the change.
    • Also, you may want to check your behind-the-scene matrix: Out-of-the-box, this matrix is in allow-all/block-exceptionally mode, so as to not interfere with the browser operation and other installed extensions. If you never changed the behind-the-scene matrix from its out-of-the-box default and you find that it is currently in block-all/allow-exceptionally mode, reset it to its original state by clicking the "all" matrix cell to turn it green, than lock the matrix.
  • Sorry. The changes re. scopes was a big change, and I failed to revise this one portion of code.

0.7.9.1


0.7.9.0


0.7.8.0

  • New feature (beta): Preset recipes available from the popup menu. HTTPSB will display all relevant recipes given the state of the matrix. Clicking on a recipe will import its rules in order to enable a specific feature on a web page:
    • Preset recipes
    • For example, for a web page with an embedded -- but blocked -- Youtube video, the popup will offer the import of a "Youtube" recipe which should enable the embedded video to play properly.
    • Consider this feature beta.
    • There are very few preset recipes for now but I do hope more will be contributed by the community, for the benefit of the community.
      • Pull requests for useful recipes will be greatly appreciated.
      • I will soon provide here a link to a wiki page which describe the syntax.
    • Currently, only recipes available: Youtube, Vimeo, Disqus, Livefyre (as 3d parties).
    • I will work to add more useful recipes and make quick minor updates in the coming days to make these available.
    • It is a convenient feature for everybody, but primary motivation is to help less advanced user to not give up on the extension.
  • Added new preset lists of blocked hosts:
    • Adblock+ EasyList
    • Adblock+ EasyPrivacy
    • Fanboy's Annoyance List
    • Fanboy's Enhanced Tracking List
    • Important note: HTTPSB extracts and uses ONLY filters which correspond to blocking an entire domain from the Adblock-filter lists, since HTTPSB doesn't support finer granularity beyond type of request/hostname.
    • Added block-facebook.txt for those who do not want Facebook to have the ability to track them.
      • Since preset blocked hosts are omnipresent (they are seen by all scopes), it is more convenient and efficient to block Facebook using such a preset list.
  • In the Settings page, for each preset lists in use, HTTPSB now displays the number of entries used and the total number of entries present. Less entries might be shown as "used" because of duplicate entries in two or more lists.

0.7.7.1


0.7.7.0


0.7.6.1


0.7.6.0

  • New feature: Auto-create temporary site-level scope (disabled by default, enable from Settings page)
    • When a user creates a site-level scope, he effectively sandboxes the whitelist/blacklist rules to apply only to web pages matching that scope.
    • Example of how this feature works (assuming out of the box settings):
      • User visits http://arstechnica.com/security/2014/01/more-researchers-join-rsa-conference-boycott-to-protest-10-million-nsa-deal.
      • Temporary site-level scope http://arstechnica.com automatically created.
      • Just for demonstration purpose, let's say you are in a hurry so you whitelist "all" (top-left cell) in order to be able to post a comment without having to hunt which specific rules are needed (you will take the time to do so later):
        • This very permissive (temporary) rule would make security conscious users uneasy, however, in this case it applies only to web pages which URL address starts with http://arstechnica.com.
    • Another virtuous side-effect of sandboxing ruleset using site-level scopes (or to a lesser extent domain-level scopes) is to minimize the spurious reloading of other pages when you change rules for one page. Example:
      • Whitelist twitter.com in one page in global scope.
      • Many other pages reload because they were also requesting resources from twitter.com (a typically ubiquitous hostname from which resources are pulled from countless web pages).
      • If you sandbox the rules to only one web site, adding or removing rules will only affect web pages of the same web site.
    • Therefore, auto-creating temporary scope for every page you visit enhance security and convenience (this enhances security as long as you don't start to whitelist "all" on every web page you visit...)
    • Keep in mind the site-level scope created is temporary, unless you persist it (padlock).
      • Currently planning a future option to flush temporary scopes and rules after x minutes of being unused, in order to avoid runtime bloat of temporary scopes/rules.
    • Turning on the auto-creation of site-level scopes is pointless if you use HTTPSB in an allow-all/block-exceptionally mode.
  • Feature change: The "Process behind-the-scene HTTP requests" checkbox in the Settings page is gone:
    • Users will now have to use the matrix to tell HTTPSB how to filter behind-the-scene requests ("BtSR").
    • For first time installations, the BtSR matrix is in allow-all mode.
    • For existing installations, if "Process behind-the-scene HTTP requests" was...
      • Not checked: BtSR matrix is set to allow-all mode.
      • Checked: BtSR matrix is set to block-all mode.
      • However, HTTPSB will leave the BtSR matrix unchanged if it concludes the user has fiddled with it.
  • The behind-the-scene matrix can now be accessed from any of HTTPSB web pages, not just the Statistics page.
  • Added another third-party list of blocked hosts: http://winhelp2002.mvps.org/hosts.txt (turned off by default).
  • Fixed https://github.com/gorhill/httpswitchboard/issues/137.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/126.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/124.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/119.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/105:
    • The fix is to copy whatever rules from global (and possibly domain-level) scope which is relevant to the newly created scope. Here is the logic of the copy-rules algorithm:
      • Copy whitelist rules only if they are relevant to the web page for which a scope is newly created.
      • Copy all blacklist and graylist rules.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/73

0.7.5.0

  • New feature: Ability to use the matrix on behind-the-scene requests (issue #122).
    • Since the matrix reflects the network traffic of a web page, in order to access the matrix for behind-the-scene requests I had to pick a web page to allow for this.
    • The web page picked is the Statistics page. So if you go to the Statistics page, HTTPSB's popup menu will show the matrix populated according to behind-the-scene requests.
    • A default scope called http://chromium-behind-the-scene is created by default for behind-the-scene rules.
    • Important read to prevent any misunderstanding: Behind-the-scene requests
    • Remember, whitelist/blacklist rules in the matrix for behind-the-scene requests will apply only if the option "Process behind-the-scene HTTP requests" is enabled on the Settings page.

0.7.4.2


0.7.4.1


0.7.4.0


0.7.3.1


0.7.3.0

  • New privacy option: In Settings page, "Remove third-party HTTP referer information for non-whitelisted hostname".
    • The HTTP referer is a potential threat to privacy. This option allows to have the HTTP referer header removed when these two conditions are met:
      • The domain name of the referer is different than the domain name of the request.
      • The hostname of the request is not whitelisted.
    • For example, let's say:
      • www.foo.com requests an image from images.bar.com
        • If bar.com is not whitelisted, the referer information is removed
        • If bar.com is whitelisted, the referer information is NOT removed
      • www.foo.com requests an image from images.foo.com
        • the referer information is NOT removed
  • The list of preset blacklists has been moved from the Statistics page to the Settings page.
    • Because really, these are settings.
  • Two new counters added to the Statistics page (in order to make you feel good about using HTTP Switchboard):

0.7.2.0

  • Completed the Rule manager. Three new buttons at the top:
    • "Commit All":
      • All temporary scopes and rules will become permanent.
      • All scopes and rules marked for deletion will be deleted.
    • "Revert All":
      • All temporary scopes and rules will be removed.
      • All scopes and rules marked for deletion will be unmarked.
    • "Remove All":
      • All scopes and rules will be deleted (you must confirm).
    • To mark a scope or rule for deletion, click on the item.
    • As before, you can import/export rules.
  • Regarding https://github.com/gorhill/httpswitchboard/issues/104: I can't fully test the problem there as this requires OSX, and I have no access to a Mac. Any assistance in debugging on OSX is welcomed. I did take care of a problem on Windows-based Yandex browser though, whereas the layout of the toolbar at the top was broken, resulting in the extension becoming rather unusable.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/103
    • Got rid of Bootstrap dependency.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/102
  • Fixed https://github.com/gorhill/httpswitchboard/issues/101

0.7.1.2


0.7.1.1

  • Updated third-party preset blacklists to their latest version.
  • Made Dan Pollock's blacklist active by default for a new install (it was off by default).
    • It's a high quality blacklist, carefully maintained, it deserves to be used out of the box.

0.7.1.0

  • Important: UI change:
    • UI changes
  • Locking down the status of a matrix cell:
    • The padlock icons used to lock down a cell status are gone.
    • You can lock down the status of all cells in the matrix using the single padlock button at the top.
    • Using the single padlock button at the top won't affect temporary rules which are not currently displayed in the matrix. Only the rules which are present in the current matrix will be locked down.
  • Better scoping, now three scope levels:
    • Global: no change, as before.
    • Domain: new. Example: https://*.google.com.
      • This will take care of a lot of pain when creating rules for those domain names which offer many various services. Best example is google.com. I don't want to be tracked by google.com (not whitelisted globally), but I do want google.com and associated subdomains to be whitelisted when visiting one of its subdomains.
      • Creating a per-site ruleset for https://plus.google.com, https://support.google.com, https://translate.google.com, etc. was a real burden.
      • Now I can create one per-domain ruleset, https://*.google.com, to take care of all the previous per-site rulesets.
    • Site: no change, as before. Example: https://plus.google.com.
    • Scoping is now temporary by default. Use top padlock button to make it permanent.
      • This opens the door to this interesting feature: Auto site-scope temporarily (request from a user, thought it was a good idea). Will see if I include this in this release.
    • Scope lookup at request eval time is now smarter: Example: If visiting https://facebook.com, per-site ruleset http://facebook.com will be used if it exists. However, the reverse is not true.
  • New feature: Auto-whitelisting of the domain of the visited web page. Default is off. Go to Settings... page to turn it on.
    • I personally advise against, but some people really want it. So be it.
    • A reminder: blocking frame by default prevent that kind of problem.
  • Smarter smart reload:
    • Blocking formerly unblocked requests won't result in a page reload, except for scripts (because they need to be disabled).
    • So for example, if I block previously unblocked images, there is no need to reload the page, as the already loaded images are not affecting the page's behavior, just its look.
  • Page can be force-reloaded from the popup menu.
    • This means you can now apply and see the result of your changes without having to close the popup menu.
  • Now using Font Awesome instead of PNG icons wherever possible.
    • This simplifies styling a lot: size, colour, etc. through CSS.
  • Fixed:

0.7.0.0

  • Important: UI change (as per issue #87):
    • A new column has been added in the matrix: "css", which acts on/reports:
      • Stylesheets
      • Web fonts (these are no longer reported in the "other" column)
    • Adding a new column required that I revisited the visuals of the matrix, due to limited horizontal space.
      • Especially, the visual for the "permanent" status of a cell has changed in order to take up less horizontal space. It is somewhat more subtle, but we get used to it. (Spent hours trying to figure the best visual, and nothing else I tried worked IMO.)
    • Result is that now important stylesheet requests are no longer buried in the obscure "other" column.
      • I decided to also report web fonts in the "css" column, as these contribute, just like stylesheets, to the appearance of web pages.
    • The "css" column will default to being whitelisted (just like images).
  • Fixed https://github.com/gorhill/httpswitchboard/issues/91
  • Fixed https://github.com/gorhill/httpswitchboard/issues/87

0.6.9.0

  • Overhaul of cookie management code = robustness and performance enhancement.
  • New user setting: "[ ] Delete non-blocked session cookies [?] minutes after last time they have been used."
    • Because W3C: "A session cookie ... is erased when you end the browser session", except that in Chromium, this is not happening. This setting lets you make it happening.
    • FYI, session cookies are typically used to keep users logged in into a web site. So long as a session cookie still exists and is valid from the web site's point of view, you are still logged in.
  • Cookie janitor code is back: this gets rid of any unused cookies from non-whitelisted hostnames which might be present in your browser.
    • Be aware that some extensions use cookies which are created from hostnames which might not have been whitelisted.
      • For example, LastPass needs cookies from lastpass.com, so be sure to whitelist cookies for lastpass.com (by visiting LastPass web site, so that you can use HTTPSB matrix).
    • There is no way for the cookie janitor to know whether a stale cookie was created by an extension or a web page, so if an extension misbehave, it could be because of cookies being deleted under its feet (all cookie managers will potentially interfere, this is not specific to HTTPSB). The fix is to identify and whitelist the hostname of the cookie, or to disable the "Delete blocked cookies" option.
    • The cookie janitor is easy going though, only non-whitelisted orphan cookies which have been stale for more than two hours will be removed.
  • Added tooltip for "other" header in the matrix to help people remember what is in this column.
  • New entries in context menu to quickly access "Rule manager", "Statistics", and "Settings" pages.
  • Improved navigation to extension pages: tab will become active if it is being reused (wasn't working before).
  • Third-party blacklists have been updated to their latest version.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/79
    • For some web site, there will still be a lot of cookie entries in the log in the Statistics page: this is because the site changes the value of cookies very often, it's not because HTTPSB over-report.

0.6.8.1


0.6.8.0

  • Third-party blacklists can now be selectively enabled/disabled (from the Statistics page).
    • So now you are free to browse the web naked if it is your thing.
  • Number of distinct entries in each third-party blacklist is now shown in the Statistics page.
  • Added two more third-party blacklists (from now on, newly added third-party blacklists will always be disabled by default):
  • While at it, simplified/cleaned up/improved legacy code from when third-party blacklists were downloaded from their remote location (which was not a polite thing to do).
  • New version/revision scheme: a fourth number is now used to denote when third party resources have been updated or when regression bugs are fixed.
  • Small fixes in blacklist names to ensure a click on a blacklist link will result in the blacklist being loaded in the browser, so that you can see its content.
  • Merged pull request https://github.com/gorhill/httpswitchboard/pull/84
  • Fixed https://github.com/gorhill/httpswitchboard/issues/78

0.6.7

  • No change for existing users. First time HTTPSB is installed, requests of type "other" are whitelisted by default. This is the best option given the last update in which stylesheets are treated as 'other' for 3rd-party hostnames. Even without this change in version 0.6.6, I had been leaning toward whitelisting by default the "other" column because it is often used also for web fonts.

0.6.6

  • Fixed https://github.com/gorhill/httpswitchboard/issues/76.
    • IMPORTANT: stylesheets (.css files) which are pulled from hostnames which do not match the domain name of the top web page will be reported as "other" in the pop-up menu matrix.
      • I realize many web pages which were displaying properly before this last update might now not display properly, but the reason they were displaying properly before is because requests (stylesheet) on which you had no control were made. Now you have full control.
      • Remember: if a web page doesn't display properly, it might be because the requests for stylesheets are blocked. Requests for stylesheet are counted in the "other" column. Example, three stylesheets at cbsistatic.com:
      • Three stylesheets shown in "other" @ "cbsistatic.com"
      • Remember: with this update, you are now in control of your privacy: you choose where your browser is allowed to connect.

0.6.5

  • Fix required in order to be able to run as an Opera add-on.
    • In Opera, onBeforeRequest can be called before the URL is bound to tab, thus preventing the blocking of inline javascript.
    • Maybe the above problem also affected Chromium/Chrome, so I pushed the new version to Chrome web store as well.
    • The fix is: if HTTPSB is unable to evaluate with 100% certainty whether javascript should be enabled, javascript will not be enabled.
    • Extension has been submitted to Opera add-on collection, it might take a few days before it shows up never mind, it was rejected, I figured the Chromium screenshots might cause an issue. Opera users can still install the extension manually though.
  • Fixed https://github.com/gorhill/httpswitchboard/issues/74

0.6.4

  • Fixed https://github.com/gorhill/httpswitchboard/issues/35 -- Read carefully:
    • HTTPSB no longer uses Chrome/Chromium settings to block inline javascript, because the way Chromium/Chrome's javascript blocker works is incompatible with how HTTPSB works. This means:
      • You won't see Chromium/Chrome's "javascript blocked" icon in the omnibar (do not panic).
      • Here are some links where you can test whether HTTPSB blocks javascript if you doubt: https://github.com/gorhill/httpswitchboard/issues/46.
      • On the positive side, you don't have to care about the initial Chromium/Chrome settings regarding javascript (so no more "IMPORTANT NOTE!" required).
    • How it works (for the technically inclined):
      • At startup time, HTTPSB creates two rules in Chromium/Chrome to allow javascript from everywhere (do not panic).
      • Then when the user opens a web page where inline javascript must be blocked, the following directive is added to the incoming response headers: Content-Security-Policy: script-src 'none'. This prevents inline javascript from running on the main page. (More details regarding Content Security Policy).
      • For external javascript, this is taken care as it always has been since the beginning, by cancelling the requests to fetch the external resource.

0.6.3

  • Context menu entries:
    • To temporarily whitelist all for domain of current page
    • To revert temporary permissions

0.6.2


0.6.1

  • Further fix to https://github.com/gorhill/httpswitchboard/issues/55:
    • Be less strict for when a subdomain can be collapsed:
      • Before: No subdomain could be collapsed if it, or one peer subdomain had at least one explicit block/allow rule in one if its columns.
      • Now: Only a subdomain which has at least one explicit block/allow rule in one of its columns can't be collapsed. Other rule-less peer subdomains are now collapsible.

0.6.0

Clone this wiki locally