Crooked Style Sheeding – Webpage tracking using only CSS • Hacker News Board

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#71

Post by tqkxzugoaupvwqr » Tue, Jan 16, 2018, 3:42 PM UTC

Raphmedia wrote: post #57

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 would have the same styling – the one chosen by the user. This HTML alternative could provide an API that makes it possible to have dynamic websites but still prevents scripting and fingerprinting.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#72

Post by ppeetteerr » Tue, Jan 16, 2018, 3:42 PM UTC

AntonyGarand wrote: post #31

asadlionpk wrote: post #15

Interesting trick. But I think adBlockers block requests to entire tracking domains. So even css calls would be blocked?

Not if you're hosting your own tracking information, on your own domain

Most trackers are built by third parties. This is true for analytics tracking and for ad tracking. Few companies ought to track their own impressions for many, many reasons.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#73

Post by MamboJ » Tue, Jan 16, 2018, 3:45 PM UTC

ekianjo wrote: post #48

dahart wrote: post #42

Earlier quoted context omitted.

> it just relies on well structured accessible content. Honest question: how much of this is left? What popular sites are still accessible this way? HN might be the only site I visit frequently where browsing with no js/css has any hope of working.

Check surfraw (by Assange), you can actually access a surprising amount of resources using sr and lynx from a terminal. Text only, but still makes internet pretty useful.

Are you aware of any piece, writeup review or anything on Assange’s programming skills?

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#74

Post by ppeetteerr » Tue, Jan 16, 2018, 3:45 PM UTC

Raphmedia wrote: post #57

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

I know this is a joke but you will still have tracking in the rss reader or in the images loaded along side the articles. The only solution is paying for software that does not track.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#75

Post by flooq » Tue, Jan 16, 2018, 3:45 PM UTC

Tepix wrote: post #43

Do browsers really need to allow fetching URLs in the "after" event of a link?

It's not after event, the "after" is for inserting a pseudo-element. That then sits inside the original link element and hits the tracking URL by trying to load a resource from it when the link is active.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#76

Post by MamboJ » Tue, Jan 16, 2018, 3:49 PM UTC

kodablah wrote: post #13

If you're concerned as a user of a malicious site: * Link click tracking - So what, the site could route you through a server side proxy anyways * Hover tracking - Can track movements of course, but doesn't really help fingerprinting. This is still annoying though and not an easy fix * Media query - So what, user agent gives this away mostly anyways * Font checking - Can help fingerprinting...browsers need to start r…

Wouldn't the Tor browser solve most of these issues?

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#77

Post by tqkxzugoaupvwqr » Tue, Jan 16, 2018, 3:50 PM UTC

Trufa wrote: post #2

Very interesting, it's always intriguing to see how much of a cat and mouse game this privacy stuff is. I'm always thinking that this needs an overhaul and slightly different approach altogether, sadly I can't produce any viable solutions. With this huge and complex kind of issues I don't think we have to find one solution but rather point in the right direction, but I'm not even sure we're doing that.

In my opinion the new approach should be: Let websites deliver content and let the user’s website reader interpret the markup / content description and style the page according to the user’s preferences. Websites shouldn’t be able to style and script themselves any longer.

The website should load more content when the user scrolled to the bottom? Let the website reader retrieve the content itself. The website wants to know the dimensions of the viewport to load the appropriately sized image or change the layout? Tough luck, this is none of the website’s business! Let the user’s website reader handle this.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#78

Post by talmand » Tue, Jan 16, 2018, 3:50 PM UTC

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.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#79

Post by beckler » Tue, Jan 16, 2018, 3:51 PM UTC

AntonyGarand wrote: post #31

asadlionpk wrote: post #15

Interesting trick. But I think adBlockers block requests to entire tracking domains. So even css calls would be blocked?

Not if you're hosting your own tracking information, on your own domain

honestly, I don't care if you use your own tracking solution on your own domain, as long as it's not passing the data to a third-party.

I get that some of that data is genuinely useful in determining what parts of an app are popular and what is not. Even though I don't like being tracked for dumb shit like ads, it does have valid uses.

Re: Crooked Style Sheeding – Webpage tracking using only CSS

#80

Post by bastawhiz » Tue, Jan 16, 2018, 3:52 PM UTC

Daycrawler wrote: post #60

kodablah wrote: post #13

If you're concerned as a user of a malicious site: * Link click tracking - So what, the site could route you through a server side proxy anyways * Hover tracking - Can track movements of course, but doesn't really help fingerprinting. This is still annoying though and not an easy fix * Media query - So what, user agent gives this away mostly anyways * Font checking - Can help fingerprinting...browsers need to start r…

> So what, the site could route you through a server side proxy anyways There's little interest in proxying through a token system (this would require a DB read at each click, and a DB write at each page generation), which means the actual link is available client-side and the whole thing can be bypassed.

Most implementations that I've seen, including Google's, just put the linked URL in the query params of the redirect endpoint URL.

'/redirect?url=...'