Can you explain what the issue with this is? What does this circumvent that cannot be done with pure JS?

> Can you explain what the issue with this is?

The only issue I can think of is mixing code/data with styling information. Otherwise there is no "issue" per se.

> What does this circumvent that cannot be done with pure JS?

Nothing, it is just JS after all, and the idea that you can store data in other things than JS variables is not new (jQuery days we stored data in various attributes in the DOM to keep track of state). You could also store the same data in <title/> tag and get the same results. Not sure what the use case is, except it's a fun little hack.

Maybe this will spawn some new JS framework, nothing would surprise me anymore.

If you're trying to make your code look non-malicious, it's easier if you have somewhere to hide the malicious-looking stuff.

possibly a longer lasting cache 'super cookie' i made a poc comment below. you could do something similar with a dynamically generated js file but i might wonder if a very small css file with headers like a cdn is cached longer

This kind of thing why I browse with javascript and CSS blocked.

It also shows a lack of understanding of how JS and CSS works in the browser. Disabling only JS would prevent anything from happen as CSS doesn't execute any code here, the JS part is responsible for that.

Except for enjoying a web without styles, there is no reason to disable CSS (together with disabling JS). You're not gonna prevent any more JS fudgery by having JS and CSS disabled compared to just JS disabled.

> It also shows a lack of understanding of how JS and CSS works in the browser.

Since you understand how a browser works much better than I do, tell me, can I disable XHR while still running JS?

From the article:

> CSS as an API?

> This makes me think that a CDN-hosted CSS file like this could have other useful stuff, like today’s date for usage in pseudo content, or other special time-sensitive stuff. Maybe the phase of the moon? Sports scores?! Soup of the day?!

> It’s almost like a data API that is tremendously easy to use.

Nope, I can't see any problem with JS being able to receive data from an external API, but then I have a lack of understanding of how JS and CSS work in the browser.

Not OP, but disabling xhr is not possible and disabling it wouldn’t achieve much. The modern browser has many apis with which to make remote calls such as fetch, web sockets, and web rct. They can also fall back to classic methods like jsonp, crafty css skullduggery, and iframes.

The reason why this css thing is not a major problem is that the js could retrieve this data just as easily using one of the other methods I listed. JS retrieving data from an external API is generally not a problem unless its used for tracking purposes or as part of an cross site scripting attack.

At worst, this gives online tracking companies yet another tool in their toolbox. I am sure the boffins down at ublock are already working on detecting and mitigating this behaviour.

I can’t really see it being used for cross site attacks unless some whackadoodle site decided to try and send secreted authenticated data via CSS payloads.

> disabling xhr is not possible

uMatrix can do it, I'm sure there are others

> fetch

fetch is a Javascript API and covered by uMatrix's XHR setting[1].

> web rct

That can be disabled[2] and is also covered by uMatrix's XHR setting.

> iframes

Can be blocked in several ways, including the aformentioned uMatrix.

> At worst, this gives online tracking companies yet another tool in their toolbox

At worst CSS in the browser has had a CVE[3] and OWASP has some attacks[4] that seem old, but you know which of these have been fixed by all the browser vendors you use, right? Perhaps you've read this paper[5] on scriptless attacks and you know that all of these have been mitigated?

> The surprising result is that an attacker can also abuse Cascading Style Sheets (CSS) in combination with other Web techniques like plain HTML, inactive SVG images or font files. Through several case studies, we introduce the so called scriptless attacks and demonstrate that an adversary might not need to execute code to preserve his ability to extract sensitive information from well protected websites. More precisely, we show that an attacker can use seemingly benign features to build side channel attacks that measure and exfiltrate almost arbitrary data displayed on a given website.

Even better, you have the faith that there will never be a repeat of these kind of things and that no attackers will bother to go down this route in future. What part does faith have when deciding upon the risks of running things downloaded from untrusted sources?

Still, the anti-tracking is good enough reason for me.

> I am sure the boffins down at ublock are already working on detecting and mitigating this behaviour.

Let's hope so.

[1] https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the-...

[2] https://www.ivacy.com/internet-privacy/disable-webrtc-leak/

[3] https://cve.circl.lu/cve/CVE-2011-0132

[4] https://owasp.org/www-community/xss-filter-evasion-cheatshee...

[5] https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlich...

> can I disable XHR while still running JS?

Sure, but it's not easy. You'd have to run content-scripts from some browser extension that polyfills the APIs you want to get rid of. But disabling XHR/fetch/others won't stop your browser from being able to make requests. CSS can make requests (like when you provide custom font paths, or images), HTML can also make requests (<img> and <iframe> elements comes to mind). Without those, we don't have a web anymore, we have a document storage without links to other resources.

CSS cannot be used as an external API as much as HTML cannot be used as an API. The trick the author is talking about under "CSS as an API" assumes that JS is activated, otherwise you can't really do anything dynamic with the data. And if you're not doing something dynamic (like you wanna display some text in :content under a :before element), you can just set it in the HTML response instead of in the CSS response.

I'm not saying that disabling JS by default is bad (I do so myself, enabling it only for trusted sites). I'm just pointing out that disabling CSS is not gonna give you any additional benefits. As long as you're in the browser, a HTML page can make requests for you, even if you have CSS disabled.

> Sure, but it's not easy.

I have XHR disabled by default and can enable it with 2 clicks.

> But disabling XHR/fetch/others won't stop your browser from being able to make requests.

> CSS can make requests

Hence it being disabled.

> HTML can also make requests (<img> and <iframe> elements comes to mind).

Which is why I have those disabled by default too.

> CSS cannot be used as an external API as much as HTML cannot be used as an API

But it can be used as an API and because there are people out there, like yourself, who downplay this ability, there are those who will leave it running…

> assumes that JS is activated, otherwise you can't really do anything dynamic with the data

…and hence, may have disabled the usual routes that you listed - XHR, images, frames etc - and leave JS on for some other reason while believing they've mitigated a number of major threats.

It's hard to produce perfect security or anti-tracking behaviour, very hard, but that doesn't mean we should ignore CSS.

Blocking CSS turns most websites into unusable stream of text and oversized SVG images and such. At that point you may as well use something like Lynx or Wget...

I find it actually improves a number of websites (an increasing number), which may be more of a comment on the number of front-end devs who seem to be able to construct a website that degrades properly without javascript.

I also can't make Lynx and Wget into a more graphical form with just a couple of clicks, and there are other reasons reasons to disable CSS[1][2] but each to their own.

[1] https://medium.com/javascript-in-plain-english/tracking-with...

[2] https://www.templarbit.com/blog/2018/03/20/tracking-users-wi...