IPv6 URL highlighting

[pisoj]

Checks

• [x] I have read the Wiki, searched the open issues, and still think this is a new feature.

Explain the problem clearly and succinctly:

If an HTTP link is contained within the URL field of a password entry it is normally highlighted and clickable. This, however, happens only if the URL uses IPv4 or a domain name, if it contains an IPv6 address, the URL must manually be copied to a browser.

Describe the solution you'd like:

IPv6 Textual representation

IPv6 address textual representation is specified in the section 2.2 of RFC 4291. In summary, address contains 8 segments of 16-bit hexadecimal values. Each segment is separated by :

• ABCD:EF01:2345:6789:ABCD:EF01:2345:6789

If a segment contains leading zeros like: 2001:0DB8:0000:0000:0008:0800:200C:417A They can be omitted as long as each segment still contains at least one character: 2001:DB8:0:0:8:800:200C:417A

Furthermore, if two or more segments in a row contains only zeros they can be compressed with ::

• 2001:DB8:0:0:8:0:0:417A -> 2001:DB8::8:0:0:417A

Note: It is only possible to use :: once in an address, so no: 2001:DB8::8::417A

There is one more way IPv6 address can be written. For convenience when translating between IPv4 and IPv6 the last 32 bits of an IPv6 address can be represented the same way as an IPv4 address: 64:ff9b::198.51.100.253.

IPv6 address inside a URL

In a URL, IPv6 address must be enclosed inside square brackets [ ]. For example: http://[2001:db8:800::200C:417A]:8080/foo

More details are avaiable in section 2 of RFC 2732

---

Expected behaviour

Of course, I do not expect full, spec compliant syntax validation of an IPv6 address. It is enough to check for square brackets [ ] in a URL. Additionally, if the protocol is not provided (there is no http://), but instead the user just typed address with or without brackets, it should open in the default browser while adding http:// at the same time. Please do not assume https, most websites will redirect to https if they support it, but websites which are http only won't normally redirect from https back to http.

• 2001:db8:800::200C:417A -> add http:// and brackets, open in the browser
• [2001:db8:800::200C:417A] -> add http:// and open in the browser
• [2001:db8:800::200C:417A]:8080 -> add http:// and open in the browser
• [2001:db8:800::200C:417A]/hello_world.html -> add http:// and open in the browser

Note: Adding http:// should be performed before opening the link, the value in the field should remain unchained, just as the user typed it in.

Also, I do not expect things which are clearly user's fault to work:

• 2001:db8:800::200C:417A:443 - port number mixed with the address
• 2001:db8:800::200C:417A/hello_mom.html - partial URL without brackets
• http://2001:db8:800::200C:417A/hello_mom.html - full URL but still without brackets
• etc.

Neither of these do I expect be clickable. The last two can be argued about, but I think a user using bare addresses probably understands these URLs are invalid.

Describe alternatives you've considered:

No response

Additional context:

No response

[ghost]

Additionally, if the protocol is not provided (there is no http://), but instead the user just typed address with or without brackets, it should open in the default browser while adding http:// at the same time. Please do not assume https, most websites will redirect to https if they support it, but websites which are http only won't normally redirect from https back to http.

I strongly object to this. If making any assumptions at all, these should be safe ones and not put the user at risk. You can still add http:// if that is what you mean.

[pisoj]

This is a topic that can be argued about. While I think that if a website has HTTPS and does not automatically redirect, it is webmasters fault I can also see the need to protect the user at all costs, more so since this is a password manager. The other side of things is that it will be annoying to specify http every time, especially for someone who might be self hosting and already uses VPN to encrypt all of their traffic, has rigorous VLANs and is just testing something.

It seems that the application already assumes HTTP for IPv4 addresses without an option to change it, at least in version 4.1.3. KeePassXC also assumes HTTP . Different behavior for IPv4 and IPv6 does not really make sense and switching the default for both will make existing users confused as to why their links suddenly stopped working.

I must say that I don't really care about this as long as there is an option to change it back to HTTP so I don't have to rewrite many of my links.

[ghost]

Maybe it would be better to split this from the IPv6 issue.

If the database entry features an explicit http:// I agree that should be respected. There could still be a warning indicator of some sort that it is insecure. In many cases http:// is simply used out of habit even when a website has long switched to HTTPS.

As for raw hostnames or IP addresses I would consider to use safe default behaviour and defaults are allowed to change over time. Browsers are also moving towards https:// as default assumption, so sooner or later you as a user have to be explicit about http:// anyways. Personally, I've always loathed non-explicit URLs and how modern browsers hide the scheme specifier. 😉

On a sidenote I consider it to use HTTPS better than HTTP even if the certificate cannot be verified etc. At least the transmitted data is encrypted somehow and protected against passive attacks whereas with HTTP there isn't any protection whatsoever. I wouldn't mind a switchable option to assume http instead of https as default but recommend the latter as default.