Css-only-chat: A truly monstrous async web chat using no JS on the front end (opens in new tab)

> Some people, when confronted with a problem, think "I know, I'll use AWS Lambda." Now they have thousands of concurrent problems.

You made my day.

Following the link in your readme to davywtf's twitter post, I saw this comment by dade:

>I remember last year, and probably the year before that, and probably the year before that still, people continually rediscover CSS keylogging. Glad to see something more interesting this time. Good work.

Following up on this, I found an article[0] claiming that it isn't really an issue since a pure CSS keylogger can only catch one character. It seems to me like your method of pseudo-refreshing the page by making old elements hidden and delivering new elements to replace them might be able to overcome this impediment, which would make your on-screen keyboard unnecessary; if I understand correctly, you could just keep capturing whatever the user types in a field, and deliver a new field that already has whatever they've typed already as the default value with autofocus on. Do I understand correctly? Is there something I'm missing, like autofocus not playing well with continuous chunks of data being delivered? I'm not saying you should put in the additional effort to do this for your beautiful-horrible-clusterfuck of a project, I'm just curious about the feasibility and thought you might already know the answer.

[0]: https://www.bram.us/2018/02/21/css-keylogger-and-why-you-sho...

When I saw this had 400+ upvotes, I kind of rolled my eyes and thought, Wow, HN will upvote the absolute worst idea if it’s an implausible-enough hack. But having actually read your explanation and FAQ, I have to admit every upvote is well earned, including mine. That is really concise and entertaining prose, and the feat is well done. Bravo.

Love this idea and your excellent explanation on git--then there was this gem (added the first ? and :):

"Why's your code suck?: Why do you suck?"

>A url-shortener using AWS lambda - JUST lambda

I expected a lambda, which compresses/decompresses the url. This would also work without storing anything.

Good god I need to buy you a beer, those were incredible. Let me know if you ever get to Toronto!

Just looked at your other projects. You're a terrorist. XD

A maybe more horrible idea, but also more fun, would be to deliver not an HTML that infinitely loads, but an mjpeg like webcam monitoring software does. Server-side rendering taken to the extreme.

Thank you for elegantly solving the “don’t click order twice!!!” problem:

Thankfully, our method of receiving data fixes that for us. Here's what happens:

We show an "a" button whose background image is like "img/a". When you press it, the server receives the image request for "a" The server then pushes an update to the client to hide the current button and replace it with one whose background images is "image/aa".

I love the crazy idea, but I’m upvoting for the FAQ alone, it’s hilarious and made me spit some coffee.

Enjoyed the hack and the FAQ.

We used to do that to track emails. Gmail's fix was to cache the emails' images on their own server, so it's only hit once. They also don't listen to selector:hover{} so you can't have hover effects.

This is pure evil. Maybe we should just go back to manually typing into SSL connections...

I've done this exact same thing to track when people printed vouchers we offered. Have a background image only on the print css.

The fix is to make the Tor browser preload all images.

Unfortunately, as always, using Tor will make things slower.

This is just a different spin on the (now fixed in most browsers?) trick of using ':visited' with a background image to uncover which sites the user has visited.

It's things like this that drove me to start browsing the web with CSS disabled by default. It's yet another vector for tracking.

Sounds like privacy oriented browsers need a patch :hover Selector to always prefetch background-image

Indeed. Demoed in the Tor browser as a mouse tracker.

> tl;dr css hover selectors that change the background image don't actually cause the browser to GET the specified background image until you hover over it

This specific page uses :active, not :hover, so it is really no different from a web form, that performs web request each time you press a submit button. It just does not reload a page.

That could potentially be bandwith heavy, but even then it's not a solution since you could just add more CSS at runtime as the Github repo shows.

You seem to be confused about meaning of "CSS tracking". Detecting that user clicks on the link, that you have shown him, is harmless — as demonstrated by Google, a website can always track it's own outgoing requests by replacing all it's outgoing links with redirects. This is inherent part of hypertext.

The infamous "a:visited" tracking didn't simply track your visits from Google — it tracked all your visits across entire Internet. Browser vendors are bunch of lazy hacks, who can't even implement per-site link history (just like they failed to implement per-site cookies). All "a:visited" states are source from single SQLite database, that stores your full web history. THAT is the "CSS Tracking", because it can tell a page about visits from completely different domains. Instead of separating your web history per-domain those <censored> have crippled :visited selector in several undocumented ways.

This would cause serious negative consequences for users (in rather a lot of the world) on slow or bandwidth-limited internet connections.

It does seem odd that browsers don’t preload images for hover effects. I guess in practice most hover effects just use colors? Otherwise there’d be a noticeable lag the first time you hover or something.

Interesting. If I understand correctly, this one doesn't receive data from the client. Maybe it can be combined with the css idea?

Exploits rely on interactions between parts of a system, not on crunching numbers. A pure Turing machine is perfectly un-exploitable since <s>its only i/o is supposed to be to the keyboard and the screen</s> (edit: it has no i/o whatsoever). CSS would have more holes than JS if it offered more APIs (which it might do unknowingly by mistakes in programming).

I believe I saw something that said CSS is Turing Complete*

* Only with user interaction to step things along, similar to powerpoint: https://www.youtube.com/watch?v=uNjxe8ShM-8

There was a discussion about this on the front page of HN literally a few hours ago:

https://news.ycombinator.com/item?id=19847939

This is what it reminded me of too! I wonder if this would break too as that one does of you press escape key.

I hacked up an existing (shitty) webchat client I had around to do this: https://github.com/Qu4Z/chattr-nojs

It still uses CSS so as not to be ugly, colour-code messages by user, and to position the "Enter message" box below the chat history, but I hope it gets the basic idea across. It should continue to work if you disable styling.

Skeptical because there needs to be some dynamic component to it which is what the CSS pseudo-selectors are achieving. Would love to see a working demo.

mm, couldn't it just be a button that sends a form?

Create a demo then.

No, you.

If you could block *.css files using a HOSTS file, that would be a hack worthy of the front page in its own right.

What exactly do you want to block here? The user clicked a form control, the form control sent a request to server. It is no different from clicking a link.

You know, that HTTP allows websites to "track" you each time you visit them, right? The horror!

It doesn't look like it's going to be easily fixable.