HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
EFForg
https-everywhere
JavaScript2013–2022
EFForg / https-everywhere · Archived

https-everywhere

A browser extension that encrypts your communications with many websites that offer HTTPS but still allow unencrypted connections.

Web DevelopmentSecurity & PrivacyNetworking
Explore on GitHubRead Hacker News discussions
15Distinct people
15Mentions
0Explicit recommenders
3.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A browser extension that encrypts your communications with many websites that offer HTTPS but still allow unencrypted connections.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year15 dated mentions

Observed mentions: 2013-12-06 13:26:28 UTC to 2022-07-15 17:10:07 UTC.

01232013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC110
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC000
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC303
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC303
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC312
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101

What Hacker News says

15 sources
fuglede_·Jul 15, 2022
Here's a small historical curiosity: In HTTPS Everywhere, the functionality used to be call "Block all HTTP requests" but when that functionality was changed (back in 2016 [0]) to not block connections to non-HTTPS hidden services, it was renamed to "Block all unencrypted requests". I just checked, and indeed Tor Browser 11.5 does not block non-HTTPS connections to hidden services, even when in "HTTPS-Only" mode. Thankfully. [0]: https://github.com/EFForg/https-everywhere/pull/4370
In Tor Browser 11.5: automatic censorship detection, HTTPS-Only by default and more
hcs·Aug 10, 2020
Encrypt All Sites Eligible doesn't prevent http to .onion sites. See the check here: https://github.com/EFForg/https-everywhere/blob/bcaf7bdecf14... Edit: Which is not to say that there aren't rules forcing some .onion sites to https, there are. Encrypt All Sites Eligible (httpNowhereOn) just knows it doesn't have to worry about un-rewritten http .onion addresses. So it really is a good idea to turn it on, and think hard before allowing an exception.
In How malicious Tor relays are exploiting users in 2020
oefrha·Jul 11, 2020
Continued: Results: out of 1112 plain HTTP links, 642 are available over HTTPS; out of those 642 entries, 143 redirect to HTTPS, 307 serve identical response from the HTTPS version, and 178 serve almost identical response (using the <=1% content length difference criterion); the remaining 14 entries with slightly wider Content-Length gaps tend to be visually identical too upon manual inspection. So we can pretty safely claim that more than half of the submitted plain HTTP links can be HTTPS instead. (We can't be 100% confident without further inspection though, since a page that responds over HTTPS just fine might have mixed content issues that prevent it from working at full capacity.) Detailed results are available at [4]. By the way, I also tried to match the plain HTTP links against HTTPS Everywhere's rulesets[5], but coverage is rath
Read the rest
er poor since the rulesets are user-contributed; I only got around ten matches out of the 1112 links. At the end of the day I can't say this little analysis is in any way useful... Let's just hope more people submit HTTPS when possible. I did notice that certain HN darlings, e.g. pg's blog, are still on plain HTTP without HTTPS counterparts. Also, the "Legal" and "Apply to YC" links in the footer are plain HTTP links; apparently haven't been touched in ages. [0] https://pastebin.com/raw/qxVjjEyA links.csv.00 [1] https://pastebin.com/raw/3ZWgTJqh links.csv.01 [2] https://pastebin.com/raw/jxRjwfwT links.csv.02 [3] https://pastebin.com/raw/bpsq9DZG analyzer.py [4] https://pastebin.com/raw/hkzZ0m5f upgradability.csv [5] https://github.com/EFForg/https-everywhere/tree/master/src/c... (Sorry about the pastebin.com links. I don't want to have this HN account associated to my real world identity, including my GitHub account and personal sites, so I had to use a non-ephemeral anonymous file host. The raw data file containing all aggregated links is too large for an anonymous paste, so it was split up into three pastes; the data analysis script automatically downloads all of them and assembles them into a single file.)
In Tell HN: 6.3% of HN top submissions in plain HTTP, more than half upgradable
greglindahl·Jan 9, 2017
I've always wanted a browser extension, perhaps built on Decentraleyes[1], which replaces the amp code with code that drops ads and trackers and just shows text and images. For bonus points you could look at httpseverywhere[2] and transform the google.com cached urls back to the originals. Alas, it's rare to find a phone browser that supports extensions. 1: https://github.com/Synzvato/decentraleyes 2: https://github.com/EFForg/https-everywhere
In You can't disable Google AMP
pfg·Nov 4, 2016
Unfortunately, that would break a large number of sites out there. Some serve different content (as in: not what the visitor would be expecting) on HTTPS, many would have mixed content warnings, etc. Just take a look at the ruleset used by the HTTPS Everywhere extension[1] to get a sense for how much of the web would break in weird ways if browsers decided to do this today. This'll happen eventually, but with 50% of page loads using HTTPS, we're not quite there yet. [1]: https://github.com/EFForg/https-everywhere/tree/master/src/c...
In Here’s to more HTTPS on the web
jgome·Apr 3, 2015
It bothers me that "HTTPS Everywhere" calls https://check.torproject.org to check for tor: https://github.com/EFForg/https-everywhere/blob/master/src/c... I don't want my browsing calling random websites at any moment... whatever the reason for it. Can this be made optional, please? Also, slashdot (the desktop version) has problems with this browser extension :( Other than that, thank you very much for your great work, to everyone involved in the project :)
In HTTPS Everywhere Version 5: Sixteen New Languages and Thousands of New Rules
extrapolate·Apr 2, 2015
Good point! It looks like all of the rules are here[1], so as long as there is oversight by the EFF, their repo isn't compromised, someone doesn't put out a fake build, etc., we should be safe. Also it looks like[2] some rules are built in such a way that only the protocol is changed and the domain is left as-is. [1] https://github.com/EFForg/https-everywhere/tree/master/src/c... [2] https://github.com/EFForg/https-everywhere/blob/master/src/c...
In HTTPS Everywhere Version 5: Sixteen New Languages and Thousands of New Rules

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.