See[1] the Referrer-Policy header, <meta name="referrer">, <a referrerpolicy> and <a rel="noreferrer">.
But generally, webmasters have found it useful to know who caused their server to fall over^W^W^W^W^W^W is linking to their pages. This was even used as a predecessor to pingbacks once upon a time, but turned out to be too spammable (yes, even more so than pingbacks).
After the HN operators started adding rel=noreferrer to links to the Asahi Linux website, Marcan responded[2] by excluding anyone who has the HN submit form in their browser history, which feels like a legitimate attack on the browser’s security model—I don’t know how it’d be possible to do that. (Cross-origin isolation is supposed to prevent cross-site tracking of this exact kind, and concerns about such privacy violations are why SRI has not been turned into a caching mechanism along the lines of Want-Content-Digest, and so on and so forth.) ETA: This is no longer in place, it seems.
Visited links have always looked different from unvisited ones, and the moment you could customize how links looked via CSS, browsers also had to implement styling for visited links specifically.
Modern browsers put a lot of care into making the changes to those styles observable to the user, but not to Javascript.
This is an extremely hard problem, and browsers have had a lot of security issues related to this behavior. Nowadays, you can only apply a very limited subset of CSS properties to those styles, to avoid side-channel timing attacks and such.
This means you can display a banner to anybody who has a certain URL in their browser history, but you can't observe whether that banner actually shows up with JS or transmit that information to your server.
> This means you can display a banner to anybody who has a certain URL in their browser history, but you can't observe whether that banner actually shows up with JS or transmit that information to your server.
How do they stop you from using Canvas to see the output and send it back?
Canvas can't "see the output", it only sees what is drawn in it (which is not a set of HTML tags, it's JS commands).
The screen recording/screen sharing API can be used for this but security is the reason you have to give explicit permission to the site before it can do this.
IIRC, Firefox had a bug where this exact scenario was possible, I think you needed to embed the link in html embedded inside an SVG, which was displayed in the canvas, and then access the bitmap. You could e.g. make the link black if visited and white otherwise, and then the number of white versus black pixels in the bitmap would tell you whether the link was visited or not.
There was also that asteroids game / captcha where links were white/black squares and your goal was to click all the black ones. Of course, clicking a square revealed that you knew the square was black, which meant the URL under it was in your history.
If you go back far enough there weren't even protections against this sort of thing at all! E.g. you could just say a visited link style was 1px taller then measure that. The protections had to be added in after the fact (often with special case logic for what's allowed to be styled or read on :visited) once security became a major concern!
But generally, webmasters have found it useful to know who caused their server to fall over^W^W^W^W^W^W is linking to their pages. This was even used as a predecessor to pingbacks once upon a time, but turned out to be too spammable (yes, even more so than pingbacks).
After the HN operators started adding rel=noreferrer to links to the Asahi Linux website, Marcan responded[2] by excluding anyone who has the HN submit form in their browser history, which feels like a legitimate attack on the browser’s security model—I don’t know how it’d be possible to do that. (Cross-origin isolation is supposed to prevent cross-site tracking of this exact kind, and concerns about such privacy violations are why SRI has not been turned into a caching mechanism along the lines of Want-Content-Digest, and so on and so forth.) ETA: This is no longer in place, it seems.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
[2] https://social.treehouse.systems/@marcan/110503331622393719