Project

General

Profile

Haketilo 2.0 first pre-release (version 2.0-beta1)

Added by koszko 6 days ago

You can now grab the new Haketilo from the Releases page.

Provided are:

  • source tarball
  • .xpi build for Mozilla-based browsers (unsigned)
  • .zip build for Chromium-based browsers
  • Signify signatures
  • PGP signatures

You might want to take a look at the list of most important changes:

  • Haketilo now accepts Hydrilla API responses with JSON schema version specified as 2.x. Some of the features (permissions, see below) are not fully supported, though.
  • Haketilo no longer blocks the use of eval() in injected scripts. This currently affects all payloads, regardless of the permissions set.
  • Injected scripts can now make HTTP requests that bypass CORS rules. This also currently affects all payloads, regardless of the permissions set.
  • https://hydrilla.koszko.org/api_v2/ is now used as the default scripts repository address. Haketilo will update from the old address automatically.

It is also now possible to solve ReCAPTCHA challenges with exclusively free/libre JavaScript using Hacktcha, a captcha client developed for Haketilo. You can try it out by visiting the ReCAPTCHA demo page and installing Hacktcha from the extension's popup.

Note: Haketilo aims to protect you from nonfree JavaScript but it can not yet stop cookies and other mechanisms from being used to track you.

The future of Haketilo

A careful evaluation of the Mozilla Add-on Policies showed that a signed version of Haketilo for Mozilla browsers can no longer be delivered. The main reason is the following rule:

Add-ons must not relax web page security headers, such as the Content Security Policy.

To be able to modify sites in the desired way Haketilo has to replace Content-Security-Policy HTTP headers with its own. There currently exists no alternative solution which would not limit the extension in an unacceptable way.

In addition, several other policies as well as the limited WebExtension APIs have been posing serious obstacles. Due to these problems, a decision has been made to instead develop Haketilo as an HTTP proxy.

2.0 will be the last feature release of Haketilo as a browser extension.

Haketilo v3.0 is going to be a tool incorporating the popular mitmproxy and also sharing some of the code with Hydrilla. This will hopefully also allow more web browsers to be used with it regardless of their WebExtension support.


Comments

Added by jacobk 4 days ago

Haketilo moving away from being a browser extension seems like it would reduce the number of people who download it. Installing an extension is so easy (when it's signed), but every time I've used mitmproxy or other HTTP proxies, I've found it complicated to set up (though, I haven't used a proxy in a long time). Would it be possible, long term, to bundle the proxy as part of the web browser? I think it would be better to have an extension, even if it had limited functionality, but I don't know the details of how much effort that would take, so maybe it's not worth it.

Also, I found a page that seems to suggest that modifying CSP headers might be allowed in this case: https://discourse.mozilla.org/t/add-ons-policy-changes-2021-q-a/89654/1 (https://archive.ph/rkMEh or document.write(document.getElementsByTagName("noscript")[0].innerHTML); (Strangely view-source:https://discourse.mozilla.org/t/add-ons-policy-changes-2021-q-a/89654/1 seems to load forever.))

Q: Does " Add-ons must not relax web page security headers, such as the Content Security Policy" include addons that:

    Are designed to do specifically that - for example, CORS Everywhere,
    Add-ons that require relaxing security headers to be functional, such as an extension adding/modifying security headers (e.g. Referer) when accessing an API from background page which is normally inaccessible due to server-side CSRF protection or,
    a userscript loading extension using script tag/eval that replaces CSP?

A: Add-ons related to web development that are explicitly built and described to interact with those headers (e.g. CORS Everywhere) continue to be permitted. This is considered an edge case of the rule. Developers of such extensions should make an effort to clearly describe the security impact and ensure that users don’t accidentally have these security headers disabled while not actively using the add-on.
We’ve seen a number of add-ons that relax the CSP or remove certain headers out of convenience to enable certain functionality. This isn’t great because the protections website authors have put into place are being relaxed, which may have unintended consequences.
One example mentioned above I’d like to provide a bit more detail on, if you are setting a Referer header to achieve a specific result when making a singular request, this is not something disallowed by the policy. With this approach you are not relaxing security headers.

Have you asked Mozilla about this Q&A entry (not sure how the signing process works)? I'm not totally sure what is meant by "related to web development", so I guess Mozilla can deny it if they want. It would probably be good to have a mechanism by which the extension can be signed by another entity in addition to Mozilla, that browsers shipped with FSDG distros (Trisquel, etc.) trust in the way they currently trust Mozilla (Then again, maybe a waste of time if the extension is ultimately going away anyway).