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.
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.
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...
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.
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?
> 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.
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.
24 comments
[ 3.8 ms ] story [ 71.0 ms ] threadNo need for an additional addon unless you need to handle specific exceptions.
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
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 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.
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.
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.