A ruby dsl that’s indistinguishable from JavaScript. http://kevinkuchta.com/_site/2017/07/disguising-ruby-as-java...
^ and in talk form: http://confreaks.tv/videos/rubyconf2018-ruby-is-the-best-jav...
A url-shortener using AWS lambda - JUST lambda. No data store. http://kevinkuchta.com/_site/2018/03/lambda-only-url-shorten...
You made my day.
Wise and funny, at the same time.
>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...
That reminds me of:
• Stealing Data With CSS: Attack and Defense https://www.mike-gualtieri.com/posts/stealing-data-with-css-...
• CSS Exfil Vulnerability Tester https://www.mike-gualtieri.com/css-exfil-vulnerability-teste...
• CSS Exfil Protection (Firefox) https://addons.mozilla.org/en-US/firefox/addon/css-exfil-pro...
• CSS Exfil Protection (Chrome) https://chrome.google.com/webstore/detail/css-exfil-protecti...
Never really got much coverage. It's not mitigated by uBlock or uMatrix (unless you deny all CSS).
"Why's your code suck?: Why do you suck?"
I expected a lambda, which compresses/decompresses the url. This would also work without storing anything.
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 am happy to add “the hack FAQ” to my snack pack.
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, thus creating a way to send data from a web page with no javascript.
That doesn't solve the problem; email trackers could just use a unique URL per email.
Why are you contributing to the surveillance age of the internet?
That little background image feature in CSS has given up quite a bit of data in similar situations (people used to use it to check browsing history of :visited links before browser started blocking that).
Unfortunately, as always, using Tor will make things slower.
It will make this kind of example really slow, but if the intention is to break this kind of spying, then that's okay.
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.
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.
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.
But who asked them to? As far as I know, the spec says nothing about per-site histories, and I find it much more useful to know if I already visited a site, regardless of the origin - for example, if I'm researching a topic, two or more sites might link to the same place, and I don't want to open it multiple times.
Plus, the idea that one can look at a modern browser, which are some of the most complex software packages being developed, and think "clearly these people don't know how to add an 'origin' column to a SQLite database", well, it boggles the mind.
To be fair there has been an ugly solution to this recently, the `__Host-` cookie prefix:
If you want to prevent this kind of spying, the solution is to load these kind of interactive background images either always or never, but not on the interaction they're supposed to track.
https://rawgit.com/elitheeli/stupid-machines/master/rule110-...
https://news.ycombinator.com/item?id=19847939
Now I don't know if there's any causal relationship between the two (or the three) or if it's just a big coincidence, since it says on the README that the inspiration for it came from a Tweet posted a few days ago.
Are browsers that allow CSS as vulnerable to being exploited as those that allow Javascript?
* Only with user interaction to step things along, similar to powerpoint: https://www.youtube.com/watch?v=uNjxe8ShM-8
HN Discussion: https://news.ycombinator.com/item?id=16319248
Basically the same idea, but it does refresh when you submit. The CSS buttons are quite a clever workaround to not refresh the page.
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.
<meta http-equiv="refresh" content="10; URL='http://new-website.com'" />
So the page would simply refresh itself every 10 seconds.
You know, that HTTP allows websites to "track" you each time you visit them, right? The horror!
but you shouldn't
CSS is always CSS. It's CSS on the repo too, but got edited back to "Css" here on the HN title for some reason.