SUB may have side effects of setting flags that XOR may not depending on the CPU.

WSJ Gift Link: https://www.wsj.com/finance/currencies/crypto-billionaire-ac...

Doesn't seem to be working.

Fixed (above)

WSJ Gift link: https://www.wsj.com/world/asia/cambodia-cybercrime-rise-why-...

WSJ Gift link: https://www.wsj.com/tech/personal-tech/anthropic-mythos-secu...

> Fixing the human readable address encoding would help

Yes! They need an alternate encoding form that distills to the same addresses.

My machines Link-local IPV6 address is "fe90::6329:c59:ad67:4b52%8"

If I try to paste that into the address bar in Edge or Chrome (with the https://) it does an internet search on that string! No way around it.

I have to do workarounds like: "http://fe90::6329:c59:ad67:4b52%8.ipv6-literal.net:8081/

All to test the IPv6 interface on a web server I'm running on my local machine.

Blame the WHATWG for that. They're the reason that v6 addresses in URLs are such a mess. http://[fe90::6329:c59:ad67:4b52%8]:8081/ should work, but doesn't because they refuse to allow a % there. (This is really damned frustrating, because link-locals are excellent for setting up routers or embedded machines, or for recovering from network misconfigurations.)

If it's on the same machine then just use http://[::1]:8081/. Dropping the interface specifier (http://[fe90::6329:c59:ad67:4b52]:8081/) works if the OS picks a default, which some will. curl seems to be happy to work. Or just use one of the non-link-local addresses on the machine, if you have any.

The other frustrating part of this is that it makes it impossible to come up with your own address syntax. An NSS plugin on Linux could implement a custom address format, and it's kind of obvious that the intention behind the URL syntax is that "[" and "]" enter and exit a raw address mode where other URI metacharacters have no special meaning. In general you can't syntax validate the address anyway because you don't know what formats it could be in (including future formats or ones local to a specific machine), so the only sane thing to do is pass the contents verbatim to getaddrinfo() and see if you get an error.

But no, they wrote the spec to only allow a subset of v6 addresses and nothing else.

I very much didn't test it, but this patch might do the job on Firefox (provided there's no code in the UI doing extra validation on top):

  --- a/netwerk/base/nsURLHelper.cpp
  +++ b/netwerk/base/nsURLHelper.cpp
  @@ -928,3 +928,3 @@ bool net_IsValidIPv4Addr(const nsACString& aAddr) {
   bool net_IsValidIPv6Addr(const nsACString& aAddr) {
  -  return mozilla::net::rust_net_is_valid_ipv6_addr(&aAddr);
  +  return true;
   }

An IPv6 literal hostname in a URL must be surrounded by square brackets.

Chrome and Edge still do a search on it in my default search engine even with []

https://[fe80::5ad6:9567:26b7:763b%18]:8081/

Even Hacker News doesn't think it's a link

On Mozilla Firefox after reenabling the separation into URL and searchbar it reports: "Invalid URL – Hmm. That address doesn’t look right. \n Please check that the URL is correct and try again." What does the '%' mean in there?

For link-local addresses, the part after % identifies the link. It's platform-specific - in Linux it's the interface name and in Windows it's an ID number.

Yes. It’s a Mac problem. That’s why Macs do the worst at pwn2own. It’s compounded by the fact that Mac users deny that there are problems in their beloved OS.

cat is a file concatenation utility. UNIX people know to view text files with more.

"Last Witness to President Abraham Lincoln Assassination on 'I've Got A Secret' Television Show"

https://www.youtube.com/watch?v=1RPoymt3Jx4

I've had conversations with people born in the 19th, 20th, and 21st centuries!