Live data from Hacker News

Crooked Style Sheeding – Webpage tracking using only CSS

github.com

101–110 of 180 posts

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#101
post #78

This is an interesting concept, but I'm not seeing anything that couldn't already be done with a properly set up website and server logging. Things like "@supports (-webkit-appearance:none)" doesn't give you chrome detection. It gives you webkit detection, which is a rather large subset of the whole. Plus some of the other browsers started supporting webkit prefixes.

> doesn't give you chrome detection

Checking every possible prefix should distinguish most versions of most rendering engines -- still not bad.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#102
This doesn’t mention my personally favorite css tracking trick, timing attacks that can be used to detect what sites you have loaded. This can be done by interweaving requests to a remote URL (say background-image) with requests to your server script, which times these differences.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#103

Alright lads, let's all go back to RSS feeds and scrap that whole "browser" experiment.

I seriously think we need an alternative to HTML that axes styling and scripting and concentrates solely on the markup / content description. Websites would use a certain set of elements/descriptors to describe the content they contain. The user’s website reader would parse the markup / content description and display a page how it thinks it should be displayed (according to the user’s preferences). All websites woul…

A nice start would be browser support for Content-Type: text/markdown.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#104

This doesn’t mention my personally favorite css tracking trick, timing attacks that can be used to detect what sites you have loaded. This can be done by interweaving requests to a remote URL (say background-image) with requests to your server script, which times these differences.

The fanciest tracking trick is the HSTS supercookie.

You use a bunch of subdomains -- a.example.com, b.example.com, etc. -- each configured so that a particular URL (call it the 'set' URL) sends an HSTS header. A different URL (the 'get' URL) doesn't.

You generate an ID for the user, and encode it as a bit pattern using the subdomains to indicate positions of '1' digits. Say your ID is 101001 -- you serve a page which includes images loaded from the 'set' URLs for subdomains a, c, and f. On later page loads, you serve a page including images loaded from the 'get' URLs of every subdomain, and you pay attention to which ones are requested via HTTPS. Since the 'set' URL sent an HSTS header, subdomains a, c, and f get requested over HTTPS, and now you reconstruct the ID from that: 101001.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#105

Earlier quoted context omitted.

> why should any website know all that? As a developer: Without user agent: How would I easily detect which browser breaks a certain feature on my project? If I deploy a new feature and see through logging that a browser X is not able to do Y then I can install X on my machine and test and fix it. If I don't have a user agent then I can just detect that after deploy there are more cases where Y fails but I don't know…

As a developer: If we actually pushed browsers to fix things, you wouldn't need to worry about that. Why should the job fall to you to work around their shitty implimentation of the spec?

Because when management asks you why their site that they paid hundreds of thousands of dollars for doesn't work on , your answer can't be "the browser's implementation of the spec is shitty, blame them." Your answer is going to be, "Yeah, sure, let me fix that."

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#106
Call me naive but, as a dev, I don't see why this would be any better than using JS. The group of people that block JS is likely to do the same for this and, as mentioned by others, common sources of such mucking are blocked by a good ad blocker.

Then, there is the whole, "how could it be integrated into an existing site with minimal fuss" issue. With JS you can specify targets and the like for actions and observations, the only comparable thing would be to offer sass / less integration so that it works with clients that disable or block JS, which is arguably much more difficult.

While it is definitely clever, I just don't see a practical use for it. It would really only benefit those willing to put the work into using it and only work so long as their logging URL is available and not blocked. I just don't see the real value.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#107

Alright lads, let's all go back to RSS feeds and scrap that whole "browser" experiment.

I seriously think we need an alternative to HTML that axes styling and scripting and concentrates solely on the markup / content description. Websites would use a certain set of elements/descriptors to describe the content they contain. The user’s website reader would parse the markup / content description and display a page how it thinks it should be displayed (according to the user’s preferences). All websites woul…

Sounds like HTML, and a browser. (Sad.)

Perhaps Firefox's Reader View would be suitable, when activated.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#108
post #47

Earlier quoted context omitted.

> * Media query - So what, user agent gives this away mostly anyways It doesn't; without media queries you can't detect thing like browser window size or screen pixel density. > * Font checking - Can help fingerprinting...browsers need to start restricting this list better IMO (not familiar w/ current tech, but would hope we could get it down to OS-specific at the most) There's a lot of trade-offs here. Plenty of peo…

If somebody has fonts installed for specific reasons then presumably they don't want web pages changing them. Web pages shouldn't need any more control than selecting from "serif", "sans-serif", or "monospace". The most legible font is the font you're most familiar with. I don't want web pages to use different fonts just because some marketing drone thought it was good for branding. It's disappointing that we allowed…

Have you heard a term 'design'? + sometimes you can't adjust the website to work well with all (or even the popular ones) sans-serif fonts

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#109

I don't see what's problematic about this. The tracking is not really done in CSS, so much as on the server. You could accomplish the same thing with 1x1 images, or loading any remote resource. Effectively the only difference is you're loading the URL conditionally via CSS, as opposed to within a ` ` or ` ` tag. Furthermore, this can be blocked in the same way as any tracking URL. I concede this is a novel way of fin…

The difference is that CSS can trigger remote resource loads in response to post-pageload user behavior, which intuitively seems like a JS-only thing. For example, tracking where the mouse has moved, as mentioned in the readme.

I wouldn't say it's some sudden, alarming capability, but it is distinctly more capable than tags.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#110
This could easily be stopped by a change in browser behavior. If web browsers downloaded contacted every address specified with `url()` automatically on page load, without considering the conditions, this type of conditional requests would be impossible.

Conceivably, you could solve it through a simple browser extension that looks through all of the page’s stylesheets and calls all URLs present in the CSS before the page is rendered.

In an ideal implementation, though, URLs dependant on “static”, non-identifiable conditions, such as an image with `display: none`, would be left alone.

Post reply on HN