Direct URLs in Google search results have been replaced with redirect URLs in the form of www.google.com/goto?url=<opaque base64 string>.
The base64 data appears to consist of a very basic protobuf structure, containing a long string of bytes in field 2 which presumably identify the URL.
Sometimes, these redirect URLs take a perceivable amount of time to load, which is very irritating.
> Sometimes, these redirect URLs take a perceivable amount of time to load, which is very irritating.
Great. On top of my on-going battle with Windows + Firefox + DNS/TLS resolution sometimes stalling for seconds at a time, another few second server-side stall is introduced.
I swear that every day modern computing scenarios get slower and slower instead of snappier and snappier.
Wow - this exact same bug has been happening to me too. I gave up on troubleshooting it after the first few attempts came up with nothing, assumed it was just unique to me.
I searched for this a few months ago and found some mentions of this bug, but yes it affects me too. Can stall up to 20 seconds+ sometimes. Chrome is fine.
I had no idea others hit this, I just assumed it was some wonky setup I have locally. I hope we both figure it out one day haha (or Firefox does)
Exactly this + websites transforming into SPAs, loading lots of JS chunks, displaying spinners and placeholders, 2FAs, login requests, captchas everywhere. Web browsing is now a very frustrating and time-wasting experience!
> On top of my on-going battle with Windows + Firefox + DNS/TLS resolution sometimes stalling for seconds at a time,
Have you tried disabling HTTP/2?
The biggest problem with this is if the target URL doesn't load but also doesn't quickly error out, like e.g. many .gov sites in Europe (seems like they are just dropping traffic from non-US IPs).
Now you can't load the page and can't easily (using only the browser UI) get a link to paste into archive.org or archive.is to read the page.
Many EU gov sites and apps also drop all non-eu traffic. Its terrible. The internet is back where it started, an intranet.
> Sometimes, these redirect URLs take a perceivable amount of time to load, which is very irritating
I do a bunch of work in remote areas with low-ping/low-bandwidth networks. The “hold on a skimmer while we round trip to Google” dark pattern makes the service unusable for me when I’m on-location.
The link you followed when you clicked hasn't a direct link for years, decade afaik (they mangle so they can see what's followed). The page used to show the direct on the search text but now it shows some stand in for it - sometimes. You can see the direct link on the bottom of the screen when you hover - sometimes (and sometimes you see a mangled link). Sometimes the google link contains the original link in the center also[1].
The situation seems to vary from result to result even on the same page of the same search - at least on the test search I just did. You can figure out what happening to an extent but this very inconsistency seems to speak to a dystopian quality to today's information gatekeepers.
[1] Example. https://www.google.com/url?sa=t&source=web&rct=j&opi=8997844...
I've just checked this again using a google account where search result pages are still following the old behavior: It looks like the 'href' attribute is the direct link, and the 'ping' attribute is the /url redirect link you are referring to. So it looks like it is actually sending me to the direct link, it just also requests /url at the same time in order to log the click. This means the user was not waiting for the logging/redirect request to come back.
Which is exactly the game theory that was predicted when some browsers started ignoring <a ping> to "protect privacy". If your browser supports ping you get ping, otherwise the website gets the data anyway but with a worse user experience.
When does that happen? I still get a normal address:
https://www.google.com/search?client=firefox-b-1-m&q=direct%...
Try it in a private browsing window - if you are logged in, Google will link directly to the result, but if you aren't logged in, it appears to be redirecting through their /goto endpoint
Are the bytes the raw url, or encoded?