Wednesday, February 21, 2018

The TLS apocalypse reaches Power Macs and TenFourFox FPR6b1 available (plus: let's block nuisance JavaScript)

TenFourFox Feature Parity Release 6 beta 1 is now available for testing (downloads, release notes, hashes). FPR6 has speculative but high-confidence fixes for freezes on Facebook due to a corner case with our little-endian typed array emulation and occasional crashes with textboxes which seems to be due to a glitch with getting the current CoreGraphics context. The ATSUI font blacklist has been expanded (fixing TurboTax and the Los Angeles Times) and performance has been improved slightly, URL bar handling has been tuned up and is snappier, the AltiVec routine used for YUV conversion and scaling has been tweaked to reduce unaligned loads (cutting three SIMD instructions per pixel), and I've done some manual hinting in JavaScript for when the branch predictor evicts the result. There are several new DOM features which get us a couple extra HTML5 points on benchmarks and fix sites like the Home Depot; finally, there is also one big new feature which is currently not yet exposed in the UI and I'll talk about this in a moment.

Partial work on native date pickers (with eventually time pickers) and support for idle callbacks (allowing better performance and scheduling of JavaScript tasks) is in FPR6, but they're not finished yet and therefore not enabled. The native date-time pickers use the standard NSDatePicker control instead of the XUL-based one in current versions of Firefox. Since we don't have to deal with a Windows or GTK version, we can just use the operating system controls built into Mac OS X and eliminate a lot of date management code by simply relying on the OS implementation; I have a prototype control working but haven't hooked it up to the input field yet (for simplicity, it will act as a OS modal window). Idle callbacks and support for requestIdleCallback exist in the WebIDL but don't connect to anything and there is only a skeleton implementation which does not yet function. The expected timeframe for these is somewhere around FPR7 or FPR8 and I will be working on them up until then; both of these are features I expect to see more use of, and we should support.

Unfortunately, unless you already have TenFourFox, you won't be able to download it: the "TLS apocalypse" has come to Power Macs running OS X. No browser that was previously available for PPC OS X can download TenFourFox now that SourceForge is mandating minimum TLSv1.1 support: Classilla, Safari 4, Safari 5, Camino and Firefox 3.6 all only support TLSv1.0. For that matter, TenFourFox didn't support TLSv1.1 or TLSv1.2 until version 31, when both were enabled (Mozilla added support in Firefox 27), and Safari didn't add support until version 7. The only other browser that supports TLSv1.1 or better on PPC OS X is Leopard WebKit when you also install the updated Security framework, and of course WebKit shells linked against those components, but it doesn't run on Tiger and it is also hosted on SourceForge.

SourceForge, however, is just following along with the general trend of removing TLSv1.0 support (SSLv2 and SSLv3 support have of course long since been deprecated on just about every major site). On February 22 -- tomorrow -- Github will end support for anything prior to TLSv1.2 and certain cryptographic algorithms. (If you are using a Power Mac to develop with a Github project, you'll need to upgrade your git and dependent components. I'm looking at providing those pieces as a way of facilitating development.) As the number of browsers limited to TLSv1.0 (and eventually v1.1) diminishes on the Web, more and more sites will remove support and be inaccessible to Power Macs with the default browser. Eventually this will impact things like the QuickTime Enabler which relies on the OS to download movie data, which someday no longer can.

I think it's a critical base feature that a Power Mac be able to bootstrap itself and download TenFourFox without having to use another computer. There is no way I can host several hundred megabytes on Floodgap itself, let alone deal with thousands of weekly downloads, but maybe we can just host a tool to handle the download instead. If you looked in that SourceForge directory already, you saw a new file: the TenFourFox Downloader. Grab it, copy it to one of your computers and see if it can fetch FPR5. It should be able to because it has all the pieces necessary to do so, including updated encryption and certificates, and using it should be self-explanatory. Assuming people report no problems, the Downloader will go live in a week or so and be offered from the main TenFourFox page to users on unencrypted HTTP who are using any non-WebKit browser other than TenFourFox, as well as systems without Leopard WebKit (TenFourFox and Leopard WebKit users will get regular HTTPS links as the site offers currently). While you could use the Downloader to do your version updates, it's really intended just to help new users starting from scratch to get off the ground.

Meanwhile, I'm in the midst of converting Floodgap to HTTPS, and https://gopher.floodgap.com/ is already live (and gets an "A" grade from Qualys SSL Test). However, even though the HTTPS/TLS version of Floodgap will support the latest security practices, there will always be an unencrypted version of Floodgap since I serve lots of old systems that don't even speak SSL. While I think the resurgence of the Gopher protocol means that Gopher is likely the best place for old computers to live, since it's a trivial protocol to implement, there's clients for even very limited systems like the Commodore 64(!), and lots of people in the retrocomputing hobby are rediscovering it, I'll still always offer alternatives to allow old systems to still be as useful as they can be and that means a perennial HTTP fallback just in case. That's what makes the Downloader a viable option.

Back to the invisible new feature. Google's Chrome group announced that they are now blocking "annoying" and "disruptive" ads in the browser. I think it should be applauded that Google is paying attention to this, but bear in mind Google is a media-advertising company first, and this move is a pre-emptive strike to make people not reach for adblockers as much. Instead, they'll rely on Google's adblocker, which, of course, will increasingly comply with the rules to not be as "annoying" and "disruptive" and still show you ads.

I don't care if ads are shown or not, personally. Sites need to make a buck to stay open, but if they're going to make that buck by being indiscriminate about what ad networks they use and inconsiderate of the burden they place on their viewers, then they should expect to be blocked. On our older, slower and more resource-limited systems, annoyances are not merely limited to obnoxious images and pop-over-under-arounders, but also larding sites up with additional processing from web scripts. This processing rarely benefits us directly, is usually used to spy on us, increases page load times and can bring the browser to its knees if multiple scripts are competing for the CPU because of JavaScript's "run to completion" semantics. But this isn't what Google wants to block, because these sorts of spy scripts are how they and their allied advertisers acquire their analytics.

Thus, may I present TenFourFox's basic adblock. Calling it adblock is sort of a misnomer because it's really a script block, but those scripts are usually loading ads or ad support libraries, so it achieves a similar effect. Basic adblock is implemented as a simple internal built-in blacklist. This blacklist is implemented at the "caps" level in the browser in C++, so it runs at native code speeds and can check very quickly (far, far faster than any adblock add-on, even Bluhell Firewall), and entries in the blacklist not only are marked as restricted and unable to execute code, but because they are marked as restricted, other components referencing them like adblocker-blockers also are unable to execute. The blacklist contains many common ad networks and "monetization" systems, as well as tag aggregators, user "engagement" and analytics systems, cryptocurrency miners and certain other types of arguable malware, all the major categories that make our lives online hell. The browser speeds up because there are many fewer scripts competing for resources, there are fewer pauses for garbage collection and there is less memory in use, and overall browsing performance improves.

The basic adblock is just that: basic. There is no claim that it is complete, nor will there ever be such a claim. Ads such as cooperative sponsorships that simply load images and aren't script-based, for example, will still appear (and, arguably, should; there's no easy way to distinguish such things programmatically). It's possible to add an imageblocker implemented in a similar fashion as well, but this would rapidly get into a situation where the overhead of scanning for these images exceeds the overhead of just displaying the images themselves (whereas the overhead of many of the scripts we block far exceeds any CPU time spent checking for them). For that matter, some scripts may just simply not be in the list yet. Similarly, the adblock is designed so that the functionality of a given site should remain basically the same whether it is enabled or not, which is why I haven't added entries for things like Disqus because they are part of the comments functionality on many sites, and Disqus may display some ads.

In addition, I had a firm rule while constructing the blacklist that if there is any ambiguity of what exactly is being blocked during the testing of an individual entry, or the entry causes a site to lose important features or fail to properly load, then that entry won't be added. Even when basic adblock is visibly exposed to users, it will never be enabled by default for exactly this reason. But the beauty of this scheme is that it's additive: if what's there (and it will be expanded) is not enough, you can use private browsing mode to block even more tracking scripts, or you can add an adblocker on top of basic adblock for even greater restrictions, depending on your taste and how much overhead you want to devote to that purpose.

To test it out, I first recommend either disabling or entirely removing any existing adblock or anti-tracker add-ons before you update so you can see basic adblock in its truest form. Update to FPR6b1, and in about:config set tenfourfox.adblock.enabled to true (you don't need to restart the browser). Open the MacOS Console (i.e., Console.app) and load a typical media website. Wow, look at what gets blocked! If you don't care for the running tally spamming your system log, set tenfourfox.adblock.logging.enabled to false. Logging will be disabled when the feature is released and finally exposed to users in the TenFourFox preference pane, but the log this option generates will be necessary if you need to report a site that basic adblock seems to disable or cause malfunctions on. I'm interested to hear your comments and how it interacts with other privacy add-ons, even though I myself am now surfing "naked" with only basic adblock so that I can try my own dogfood. I will be adding entries up until the FPR7 beta since the feature is not officially released yet, but once it becomes public (likely FPR7), new entries will only be added during the beta-test period to reduce regression risk from improperly or incompletely screened additions.

FPR6 final is scheduled for March 12.

15 comments:

  1. Just want to say thanks for everything that you do.

    ReplyDelete
  2. The combined effect of turning off the traditional ad blocker (or in my case: reducing the number of filter lists significantly) plus a lightweight basic add block is most welcome. Example: The Facebook Timeline takes ~60 seconds to complete loading in FFPR5 with uBlock origin (on a 1.67 GHz G4 and my personal FB profile, YMMV). It takes 45 seconds with the new setup. For comparison, it takes a little over 60 seconds on Safari 5+Leopard Webkit (with extensions disabled). The TFF downloader is a good idea and works well.

    ReplyDelete
    Replies
    1. I haven't had a chance to make any measurements, but TenFourFox feels more snappy after I disabled the adblocker I was using and enabled the new basic adblock. Thanks, Cameron!

      Delete
  3. I usually don't run adblocks. Sites need to survive. So I don't run adblock on my work computer, and on my only Intel machine at home, I also don't run it.

    But on my legacy machines, I also update the hosts file with the lists kept on the internet. It makes everything much faster!

    Shiunbird

    ReplyDelete
    Replies
    1. This is not unlike that and probably achieves a similar effect.

      Delete
  4. NOT BAD BOSS! I've been using Adblock Plus (which catches a lot), but there's obviously a cost in performance. This is really quite adequate. Is Might be nice to see if a Toggle could be put in, in case one needs to go to a site that won't let you past without seeing it (a lot of government jobs like the Post Office have popup-dialogs that use very similar code to ads and I usually have to disable all adblock to view them and interact.

    Can this become a default in FoxBoxes?? They really need it. I just manually added the code to the prefs.js on a few FoxBoxes and the difference was massive (on Twitter - it ran at least 50% faster).

    Lastly, an addon worth saving to the vault is Google Search Link Fix ( https://github.com/palant/searchlinkfix ). Removes all tracking data from both Google and Yahoo search results when both clicking through and copying links.

    ReplyDelete
    Replies
    1. Yes, the toggle will be in the preference pane, and yes, it will be exposed as an option in foxboxes in an upcoming version of TenFourFoxBox.

      Delete
  5. P.S. On another matter, have noticed a lot of jpgs in sites that can't handle newer color profiles and show-up in crazy inverted Cyan+Magenta Negative. Have been using the built-in color-manager, and for the most part it works, but it seems something has changed. Is there a way to disable (or assume sRGB) on another level, than gfx.color_management?

    ReplyDelete
    Replies
    1. Please open a ticket on Tenderapp with a couple of sites so we can have a look.

      Delete
  6. Not sure how applicable this is for Tiger, but http://sevan.mit.edu/ has a much newer version of OpenSSL up 1.0.2 in full-package form. Would this BREAK anything else in Tiger??

    ReplyDelete
    Replies
    1. The version of OpenSSL in 10.4 is 0.9.7; I am not aware that 1.0.2 is binary compatible, so I'm not sure it's a drop-in replacement. You should keep the old dylib around if you intend to switch them out in case it does break things.

      Delete
    2. BTW tried it - and it installs (in /usr/pkg) and it runs, but doesn't see to link up with curl wget, so something is broken in the background. Will keep playing with it though and see if their is a way to make a new system pathway with it. Eventually nothing will work in the system (timesync/iTunes, etc). Might be a good thing if can be installed as a replacement. The good news is it comes with all needed libraries, binaries and patch-aliasing so might be a good option. More word as I have it.

      Delete
  7. Hi! I can't test FPR6 right now but I'm sure basic adblock will be awesome! ;-)
    In the mean time, I'd like to share my experience in testing speed with usual ads & scripts blockers extensions: I've been using Ghostery for years and NoScript (also disabling most of its functionalities, I felt it too complicated...) and found TFF was the most speedy with those extensions off, but kept Ghostery for a while as AdBlock was often detected by the websites.
    Then I discovered uBlock Origin and uMatrix and TFF got a lot speedier!
    Now they're on all my computers.
    The last crucial step for performance optimization on my Mini G4 1.25 GHz was adding Decentraleyes (which downloads CDNs and keep them at hand), reaching minus 20s load on heavy sites (compared to with those 3 extensions disabled).
    I'm curious to know if any of you use Decentraleyes and if you have some concern about it (security? some downside I'm not aware of?)
    And as always, thanks for the great work! :-)

    P.S.: are there any statistics on how many total downloads each TFF version gets? (i.e. How many users around the world?)

    ReplyDelete
  8. Well a LOT of Tiger users and devs/former-devs are interested in fixing this. Put up a discussion on Macintosh Garden, and got two very useful replies and also Sevan (who does the mit packages) is interested in corresponding about a real OpenSSL patch. This could be useful to TenFourFox also, because even with it's enhanced SSL, you are still at the mercy of the system clock for security certificates and a proper fix will make life easier for everyone.

    ReplyDelete
  9. Great new feature! Speed ups all round - especially since I'd stopped using NoScript as it degraded performance of late.

    ReplyDelete

Due to an increased frequency of spam, comments are now subject to moderation.