Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP URLs opened from bookmarks should not be upgraded to HTTPS #17

Open
fmarier opened this issue Dec 20, 2017 · 7 comments
Open

HTTP URLs opened from bookmarks should not be upgraded to HTTPS #17

fmarier opened this issue Dec 20, 2017 · 7 comments

Comments

@fmarier
Copy link
Contributor

fmarier commented Dec 20, 2017

Here's another case that seems to be upgraded unnecessarily:

  1. bookmark an HTTP-only site, for example http://bholley.net/blog/2015/mozpromise.html
  2. use the awesomebar to navigate to it
  3. notice how you are taken to https://bholley.net/blog/2015/mozpromise.html
@fmarier
Copy link
Contributor Author

fmarier commented Dec 22, 2017

Actually, the problem seems larger than the above scenario.

On 0.4.3, if I do the following

  1. type Ctrl+l to focus the address bar
  2. clear the existing contents
  3. type "http://example.com"

then I am taken to "https://example.com" instead of "http://example.com".

@Rob--W
Copy link
Owner

Rob--W commented Dec 22, 2017

This is due to limitations of the extension API. For bookmarks I could try to detect whether a host name is bookmarked, and if if so, if there is at least one https-URL before redirecting.

For the case of non-bookmarked domains, there is no side channel that I can use to determine whether the user typed "http://" or nothing.
Would the ability to forcidbly navigate to http (e.g. typing "h example.com" -> "http://example.com") be a good option for you?

@cben
Copy link

cben commented Dec 22, 2017 via email

@Rob--W
Copy link
Owner

Rob--W commented Dec 22, 2017

@cben That bug hasn't been closed yet. Though even if the linked bugs get resolved (i.e. we can distinguish typed navigations from non-typed navigations), then we still have the problem of detecting typed example.com from typed http://example.com.

@fmarier
Copy link
Contributor Author

fmarier commented Dec 22, 2017

I'm starting to suspect that perhaps the best way to replicate the original behaviour would be to use the code from the original add-on to make a patch in gecko directly (behind an about:config pref).

@Gitoffthelawn
Copy link

I think, at the least, this extension needs an option to allow opening http bookmarks with http.
I regularly go through http bookmarks to see if https is available for them, and manually update them if available. I (unfortunately) have hundreds of http bookmarks, and adding all their domains to this extension (and deleting them as they convert to https) would be time consuming.

BTW, another useful extension to create would be one that goes through all bookmarks and sees if https is available for them. The only trick is that a screenshot would have to be taken of both the http and https versions to compare them. Some sites will load on https, but the content is broken.

@Rob--W
Copy link
Owner

Rob--W commented Dec 31, 2019

(this is off-topic)

BTW, another useful extension to create would be one that goes through all bookmarks and sees if https is available for them. The only trick is that a screenshot would have to be taken of both the http and https versions to compare them. Some sites will load on https, but the content is broken.

This is something that can easily be done with an extension. But instead of using a screenshot, I would suggest to just confirm that the request succeeds successfully, or at most compare the response text. Comparing by screenshots is complicated and easily defeated when the result has dynamic content, e.g. embedded adverts.

To get started with developing extensions, see https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions
and for your specific use case, see https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Work_with_the_Bookmarks_API

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants