<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all,<br>
<br>
There are two important improvements I'd like to get into HTTPS
Everywhere soon, but I have been too swamped with Let's Encrypt work
to get them done. These would be great volunteer projects:<br>
<br>
<blockquote><a class="moz-txt-link-freetext" href="https://github.com/EFForg/https-everywhere/issues/1771">https://github.com/EFForg/https-everywhere/issues/1771</a><br>
Settings window freezes Firefox for a long time / sometimes
crashes it.<br>
</blockquote>
My preferred fix for this is to simply remove the settings window.
It shows all the rulesets at once, which is somewhat meaningless
when we have 15k+ rulesets. That's also redundant with the HTTPS
Everywhere Atlas. The one setting from that window that we probably
want to keep is "Reset to Defaults," which should be moved into the
primary window anyhow. The settings window is accessible through
"Enable / Disable Rules" in the HTTPS Everywhere icon menu, *and* by
clicking "Settings" from the Firefox Extensions page, so we'd have
to pull it out in both places.<br>
<br>
The alternative is to modify the settings page so that it doesn't
show any rulesets when it first opens, and then only loads rulesets
in response to a query. This is more complicated to write, and there
are probably still some queries that will load so many rulesets they
will freeze the browser.<br>
<br>
<blockquote><a class="moz-txt-link-freetext" href="https://github.com/EFForg/https-everywhere/issues/1775">https://github.com/EFForg/https-everywhere/issues/1775</a><br>
HTTPS Everywhere uses too much memory<br>
</blockquote>
Beyond the settings window problem, HTTPS Everywhere just consumes
too much memory. We should approach this in a disciplined way: Pick
a set of 100 sites and run a memory profile of HTTPS Everywhere as
it loads them, then attack the largest sources of memory use first.
We should probably also do CPU profiling, as there are big wins to
be had there. This is an issue across both Firefox and Chrome, but I
think Firefox has a bigger problem, since Nick Semenkovich has
already done a lot of great work on speeding up the Chrome
extension. Unfortunately I don't have any experience profiling
Firefox extensions, so we need someone who either has that
experience or wants to put in the time to learn it.<br>
<br>
Thanks,<br>
Jacob<br>
</body>
</html>