Https-everywhere: Native program for Linux that forces HTTPS on all apps at OS level

Created on 9 Oct 2020 · 2Comments · Source: EFForg/https-everywhere

Type: feature request

Sorry if this isn't the right place to discuss this (since it's about a separate app), but I think it's worth talking about this.

Does EFF plan on porting HTTPS Everywhere to run natively on an OS like Ubuntu?
It would be great to have SSL preference / enforcement across all apps on the OS, not just browsers.
Especially if Manifest V3 (#17268) ends up introducing limitations on the extension. But also for use on email clients, messenger apps, etc. If the idea is to give more freedom and control to users, it makes sense to have it in a way that can protect the entire system without limitations, right?

If not, does anyone know of a good alternative for Linux? I've found SSL Enforcer but it seems it's not even open source (which is essential for any privacy app), and it's only available for Windows and Mac.

Here's a list of potential features that could be implemented (in case anyone would be willing to).
It wouldn't need the per-site rule-set complexity with constant manual updating; I believe just focusing on good generic functionality would be more than enough. Here's what I think it could be:

BG process which auto-starts with OS by default. It captures network requests from all programs not listed as ignore.
Any insecure HTTP requests from the native apps are automatically upgraded to HTTPS if possible.
A blocked HTTP HTML page can be redirected to the app page (like the extension currently does) with the buttons to allow.
Icon in systray may have these states (from lower to higher precedence):
- hidden: (if possible) or inactive
- upgrade: some requests have been upgraded
- insecure: some requests couldn't be upgraded, and have fallen back into insecure mode
- block: some requests couldn't be upgraded, and have been blocked
List of exceptions allows editing the override of the settings below on:
- URL patterns, like domains or specific URLs, resource types, etc
- programs (with option to also apply the permission to child processes)
- program "AND" pattern combination (has precedence)
A setting allows successful upgrades to be silent or info (sets icon in systray) or ignore (don't try to upgrade).
Logs are accessible in the systray app.
The other setting allows to specify behavior for "fallback to insecure when HTTPS not available". It can be:
- silent: allows HTTP without any visible notices
- info: activates an icon in systray when any HTTP requests have been made
- warn: allows HTTP and activates icon and notification in systray;
  
  only appears once per domain on a session (other URLs on same domain are logged, but don't trigger a notification)
- verbose: like previous, but appears for every URL; sub-resources still don't trigger the notification again
- prompt: systray notification, you must allow manually; allowing might also apply to sub-resources;
  
  buttons to allow temporarily or permanently for the domain/program combination;
  
  if there's no answer in the timeout, it's blocked
- block: blocks without explicit notification, but systray app icon changes; it can be accessed to check log and allow

For Linux, there's no much need to have a GUI app; setting can be just text files as usual (except for the easy-access "allow domain" buttons in the prompt/block notifications). UI can be limited to simply have a good systray integration working well in multiple DEs like GNOME and KDE Plasma.

TL;DR I think focusing on a good free-software native app and using the browser extension to "advertise" it (like AdGuard does) is the best way to work around any limitations Google may impose on the future, while allowing the people who care about privacy to be able to do it without restrictions. Sure it would be a lot of work, but you guys are probably the ones who can make it work well.
What do you think?

feature-request

Source