Better network errors when "block unencrypted requests" is enabled

[strugee]

Currently if you visit an HTTP site with HTTPS Everywhere blocking all unencrypted connections, you get an "unable to connect" error. It'd be nice if the extension did something more useful, like displaying a page that said "Unencrypted request blocked" or something.

[jeremyn]

I don't know the code where this happens, but from observation, "Block all unencrypted requests" seems to just rewrite unencrypted HTTP URLs to HTTPS. So it's not that the add-on is blocking the request, it's that server can't process it. You can see this in your "localhost" issue #8242 .

So this isn't really something HTTPS Everywhere can do, or if it is, it would require some weird detective work. I think this issue should be closed. What do you think?

[strugee]

@jeremyn yeah, that seems to be what's happening. But I don't think it'll require a lot of detective work - after all, the extension knows when it's rewritten a URL. If it rewrites HTTP -> HTTPS and then notices a network error immediately after, it seems safe to assume it was due to the rewrite.

[jeremyn]

The add-on doesn't think about things in that way. It's not watching or tracking connections. It normally just watches outgoing requests, sees if the URL matches a regex in one of the rulesets, and if so it rewrites the URL however the matching ruleset wants. For "Block all unencrypted requests" mode I assume it just rewrites any leftover unencrypted HTTP requests to HTTPS.

Think about the localhost example again. If your computer isn't running any local server and you get an error at https://localhost, is "Unencrypted request blocked" appropriate? No, because it suggests that the plain HTTP request would have worked.

To implement your idea, the add-on would have to try the plain HTTP connection first and see what happens. This is bad for privacy and would require some sort of new tracking and evalution logic in the add-on that doesn't exist right now.

[strugee]

@jeremyn maybe the error should be adjusted to "Upgrading unencrypted connection failed" or something like that. That being said I'd argue that "Unencrypted request blocked" doesn't imply HTTP would have worked - there would have been an outbound request no matter what had HTTPS Everywhere not "blocked" it. Whether or not the request would've succeeded is orthogonal.

If we added some text below "Unencrypted request blocked" that said something to the effect of, "it's possible that disabling 'block all unencrypted requests' and trying again will fix this issue," would you be OK with that?

[jeremyn]

A question is, what information do you want to user to learn from any of these messages? They already know the URL was rewritten because they can check the address bar or dev tools. They already know the HTTPS site doesn't work because it's reporting an error like "Invalid certificate" or "Unable to connect". I think what you are trying to tell the user is, "This request would have returned a valid response if HTTPS Everywhere hadn't rewritten the request from HTTP to HTTPS using the 'block everything' rule". Is that right?

[strugee]

They already know the URL was rewritten because they can check the address bar or dev tools.

Users won't think to do this. I'm a web developer and even I only barely thought to check the URL bar - getting an error on localhost when I knew my server was running was extremely confusing. Regular users will have no idea what was going on.

I think a large part of the difference in thinking here stems from the fact that AFAICT you're assuming that users will be able to figure out that HTTPS Everywhere's "blocking" mode actually just unconditionally rewrites everything to HTTPS. I don't think that's a valid assumption.

"This request would have returned a valid response if HTTPS Everywhere hadn't rewritten the request from HTTP to HTTPS using the 'block everything' rule".

Roughly, yes. Mostly I just want it to be clear to the user that the failure was caused by HTTPS Everywhere. I'm pushing for "Unencrypted request blocked" because I think that's the easiest to understand - even though it's not technically true in the sense that HTTP requests aren't being blocked, they're being rewritten, it matches the text of the option that the user enabled much better and is thus clearer. Or in other words, it's easier to understand even if it's not 100% accurate.

[jeremyn]

Right, so in order to know

"This request would have returned a valid response if HTTPS Everywhere hadn't rewritten the request from HTTP to HTTPS using the 'block everything' rule".

We need to gather this info:

• Did the plain HTTP request work? yes/no
• Did we rewrite the URL because of the fallback rule? yes/no
• Did the HTTPS request work? yes/no

The error message we're discussing then displays if the answers are "yes", "yes", and "no". Is that right? If so, we have the privacy and tracking problems I discussed in #8239 (comment).

Another way of thinking about this is that:

Mostly I just want it to be clear to the user that the failure was caused by HTTPS Everywhere.

is not directly true. The request failed for any of the various reasons requests fail. The user would have gotten the same failure if they typed that HTTPS URL into the address bar themselves. "Blaming" the failure on HTTPS Everywhere requires the analysis and information gathering above.

[strugee]

@jeremyn hey, so sorry. This fell off my radar for some reason.

I think you're missing the point I'm making. You're getting hung up on making sure that the error message is technically accurate, but what I am proposing is that we lie about knowing that an HTTP request would've worked, because it will be the truth 95% of the time. Thus, the first question above ("did the plain HTTP request work") is irrelevant.

The user would have gotten the same failure if they typed that HTTPS URL into the address bar themselves.

But they didn't. You're taking a very small and focused view of the world here. That's fine, but I'm stepping back and looking at the broader picture: if the user types http://example.com, the request will work. If the user types http://example.com and HTTPS Everywhere upgrades it, and https://example.com fails, HTTPS Everywhere has caused the error. It's cause and effect. The request would've worked unless HTTPS Everywhere's "blocking" mode was enabled, period.

Now, that doesn't mean that it's HTTPS Everywhere's fault. But it was caused by HTTPS Everywhere.

Do you see the distinction I'm making? Without the information gathering you've proposed, the error message will be accurate in 95% of cases, and I don't really think it's a big deal if it's not completely correct in the other 5%. It's a big usability win in the majority case versus a very minor inaccuracy in the minority.

[jeremyn]

I'm not sure what you are arguing for here. We are not going to rewrite a browser's error page to some error page we made up. I'm not even sure that that's technically possible, my guess/hope is that browsers don't let add-ons lie about page errors. At "best" we might add a suggestion in the extension UI that they could try disabling the rule or add-on. I'm against that too. Novice users should not be encouraged to disable parts of the add-on, and technical users will already know that they can.

[strugee]

We are not going to rewrite a browser's error page to some error page we made up.

This was what I was suggesting, yes. However if you're really against changing browser error pages (which I bet you can do in Firefox; I'd forgotten HTTPS Everywhere worked in Chrome too and assume it wouldn't work there) the same effect could be achieved by having a little informational popup from the icon that said "unencrypted request blocked" or something.

Novice users should not be encouraged to disable parts of the add-on, and technical users will already know that they can.

This argument does not apply when the relevant part of the addon comes disabled out-of-the-box.

[jeremyn]

To sum up, what you want is:

• If a user has enabled "Block all unencrypted requests", and
• The page fails to get a response because of "Unable to connect", "Secure connection failed", maybe a time-out, or any other connection-type failure, and
• The URL was rewritten using the fallback "Block all unencrypted requests" rule, then
• HTTPS Everywhere should generate (at minimum) a UI pop-up saying something like "Unencrypted request blocked".

Is that right? If so then I would say no. If you really disagree with that, then we can ask someone else.

[strugee]

@jeremyn yes, that's correct. (I assume when you say "the URL" you mean the URL in the address bar, not a subresource URL.)

Why do you say no? It's a huge usability win IMO and I don't see any downsides.

[jeremyn]

I don't think the popup would be helpful and in fact, as we've discussed, it could be misleading. I don't know who its target audience is.

@Hainish Can you take a quick look at this feature request and let us know what you think? You can just look at #8239 (comment). I don't think we want this but I could be mistaken about its value.

[Hainish]

I think this adds some complexity to the code without a whole lot of utility. Having the red icon I think should be enough to alert a user that the 'Block all unencrypted requests' is enabled. I might be inclined to include it if a PR is made, depending on how it's implemented, but I don't think it's an outstanding issue.

[strugee]

Hey, sorry for the delay (again). The red icon provides good information but isn't sufficiently noticeable to actually help - remember, users don't notice passive indicators (see for example The Emperor's New Security Indicators which, while about a different icon, demonstrates the same problem).

I also still stand by my point that if we phrase any warning carefully, we can make it not (egregiously) misleading while still matching the text that already exists in the icon menu ("block all unencrypted requests").