
A more efficient matching engine for HTTPS Everywhere - pythux
https://remusao.github.io/posts/efficient-https-everywhere-engine.html
======
londons_explore
> Lastly, I was surprised to observe that the Rust/WebAssembly version of the
> engine as currently shipped in HTTPS Everywhere seems to be slower at both
> initialization and operating than the previous JavaScript implementation.
> This seems to contradict the previous claims when this was first released.

I see this all too often... Some bit of code is slow, so a project is started
to rewrite it more efficiently. Along the way, a bit of scope creep happens,
and the final result is slower than the original. Since so much effort has
been invested into it, it gets deployed anyway.

~~~
BiteCode_dev
I see that in the Python and JS world sometimes.

The fact is, most scripting languages are written using a compiled one, often
C, under the hood.

And those implementations have been optimized for decades.

A lot of hot loops are such because of complex sorting, filtering, and so on,
and those are quite hard to do right.

Hence, it's possible to write a way slower implementation using C manually
than using the automatic way in Python or JS, not to mention the later has a
very good JIT.

If you add the fact some code may use crazy fast libs (like numpy in Python),
then you may end up in a situtation where you have to really know what you are
doing to implement a faster version.

However, somebody knowing what they are doing would measure and find the
bottle neck first before talking of a rewrite, and suggest it only if it's
worth it.

Which it can be, of course. Mercurial, Dropbox and Youtube are all good
stories about it.

But the junior thats been tasked to improve the UX is probably not the best to
advice you on the matter.

------
kd913
On firefox I just set dom.security.https_only_mode to true. There isn't really
a need for an additional extension for me.

The only cases where it becomes somewhat problematic for me is my router page
and local jupyter notebooks. Both can be served through other means.

------
bouk
I've written a janky Ruby script that automatically tries to convert the HTTPS
Everywhere rules into content blockers: [https://github.com/bouk/https-
everywhere-host-list/blob/mast...](https://github.com/bouk/https-everywhere-
host-list/blob/master/generate.rb)

It's used to create the host list for HTTP4All, my unofficial port of HTTPS
Everywhere to iOS
[https://itunes.apple.com/us/app/https4all/id1305430042?mt=8](https://itunes.apple.com/us/app/https4all/id1305430042?mt=8)

~~~
Jakob
Nice project! There is "Automatic HTTPS Upgrade" in the iOS Safari
(experimental) settings. Wouldn’t that do the same?

~~~
joombaga
That just switches to the SSL version of a site if it exists. It does nothing
to block an unsecured site.

------
npiit
HTTPS is already almost everywhere. This addon is pretty much unneeded in 2020
not to mention it did very little anyway.

~~~
everfree
You'd be very surprised how many websites you visit in a day that still don't
have HTTPS, if you stopped to check. Little academic sites, old tech blogs,
those trackers when you click a link in an email list that you signed up
for...

~~~
jobigoud
If a site doesn't support HTTPS the extension won't do anything.

~~~
pabs3
It has an option to block sites that don't do https (with options to
permanently/temporarily allow them.

