A more efficient matching engine for HTTPS Everywhere | Hacker News Reader

A more efficient matching engine for HTTPS Everywhere

remusao.github.io

70 pointspythux23 comments

> 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.

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.

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.

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...

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

Interesting project! As far as I can see it only approximately converts the rules right? Since the iOS Content Blocker does not look granular enough to express the rulesets semantics fully.

Out of curiosity, how did you handle exclusions? Also, are you generating one "block list" per ruleset? Or merging them into a single blocklist?

I'm only converting rules that are just a host whitelist. I ignore rules that are more complex, since those don't translate.

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

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

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

almost

Of course it's needed, regardless of the existing coverage from existing websites. HTTPS provides confidentiality but also integrity and may be used to provide authenticity.

The addon is entirely related to existing coverage of websites because all it does is replace http urls by https ones if they exists. It doesn't magically add https to sites that don't support it.

All those people who downvoted me don't understand neither HTTPS nor how this addon works. The addon is only at value when you request an HTTP url for a website that doesn't automatically redirect you to the HTTPS url. It's almost useless since the vast majority of websites automatically redirect you.

I thought the extension sends you directly to the https version, that is similar to how HSTS works, and securitywise alot better that http redirects.

It doesn't yet, but theoretically it could redirect http URLs to archive.org/archive.is, which have https.

Of course it doesn't magically add https. I never said it did. As you said it enforces use of https instead of http. That is what I said was necessary. The three reasons that is necessary were what I listed.

I use it to block HTTP by default.

Firefox can do this with some config currenty.

On firefox you can do that anyway by setting dom.security.https_only_mode to true in about:config.

No need for an additional addon unless you need to handle specific exceptions.

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...

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

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

I have some config (afaik found it on ghacks sometime ago) in Firefox that breaks the entire website if it has any HTTP url in it. I rarely see broken websites.

Reply on news.ycombinator.com