"That's a bad idea because other scripts that run in the context of the website domain can access the HTML code at any time—and thus the injected Kaspersky ID. This means in plain language that any website can simply read the Kaspersky ID of the user and misuse it for tracking," the researcher says.

https://thehackernews.com/2019/08/kaspersky-antivirus-online-tracking.html

Quote:

"That's a bad idea because other scripts that run in the context of the website domain can access the HTML code at any time—and thus the injected Kaspersky ID. This means in plain language that any website can simply read the Kaspersky ID of the user and misuse it for tracking," the researcher says.

Using JS all scripts from all sites linked on the page can read the HTML code and report back to multiple places.

Using an img tag will direct the browser to contact a single site.

And if CSS can be used to do the same thing then CSS also needs to be blocked or neutered or something. I haven't looked into it, but you make it sound dangerous. Do you have some links about its abilities?

It certainly isn't right that websites can have so much power over the user's browsers regardless of whether it is JS or CSS or whatever. Especially since code coming from webpages can't be audited, and every visitor can receive a different version. Some high-profile reviewer that people trust to tell them what is safe could receive perfectly neutral code, while everyone else gets weaponised code to steal their banking details. And there is the problem. It shouldn't be that we need to trust the remote site to be safe. That is wrong headed. We shouldn't have to care.

Especially since code coming from webpages can't be audited, and every visitor can receive a different version. Some high-profile reviewer that people trust to tell them what is safe could receive perfectly neutral code, while everyone else gets weaponised code to steal their banking details.

You come back to blaming websites while ignoring non-web-applications that have much higher privileges.

is like you went to library, you intended to borrow some books, but you don't want anyone including library to know, but then how library could confirm it was indeed you who returned those books and you were returning them in exact quantity?

The idea is that you can use :visited pseudo-class to detect if the URL of the link has been accessed recently. And then there’s plenty of ways in CSS to attach an image to particular elements (say, background-image property). That’s quite enough.

This can be seen in the following two images, the left one showing the testcase published in the WebKit code repository as part of the bugfix and the right showing the part of the in-the-wild exploit code that triggered the bug.

The bug causes an out-of-bounds write to the JSC heap with controlled data.

But website visitor should already trust the website owner, so the victim trusts the attacker.

DimonSoft wrote:

But website visitor should already trust the website owner, so the victim trusts the attacker.

I don't agree with that. I can't trust any website. I don't know who controls the website, even this website. It could be a hacker that controls a website, not the person that owns the domain, or the person that own the equipment, or the person that has the admin password. Those other people might think they are in control, but some hacker might have exploited something (which is the case with the article above). So, no, there are no websites that can be trusted. The trust model is just not there. We are all strangers.

Trust or stop using all the tech stuff.

Web browser produces its output by processing data retrieved from a website. It’s you who directs browser to that particular website. So you implicitly have to trust the website owner not to trick your browser into doing strange stuff. Just like you have to trust DOC file not to trick your MS Word into doing strange stuff.