I immediately thought this is a great way to ship malicious payloads to an unexpected party. A good WAF would block it as sus, but a few tricks could probably get around that as well
The difference is that if GitHub is found distributing malware on GitHub pages, you can notify them, they verify it, take it down, and open a process to eventually ban the offender.
They expend enough effort in this as to ensure the vast majority of content on GitHub pages is not malware, and avoid getting blankedly flagged as such.
It's not clear if smolsite.zip can successfully set up a similar process, given that they'll serve just any zip that's in the URL, and they won't have the manpower to verify takedown requests.
In this exact context it's likely not a problem, but essentially this is a ready to go XSS attack. As far as I can tell there is no CORS or domain level protections, so an "attacker" here could easily do anything else with any client-side data being used by any other "site" on the domain.
Let's say I make a little chat app that stores some history or some other data in local browser storage or cookies. Any other site can just as easily access all of that information. An "attacker" could link you to a modified version of the chat site that relays all of your messages to their server while still making it otherwise look like it's just the normal chat. It would also retain any client side information you had previously entered like your nick name or chat history, since it's stored in local storage.
Most of the time sanitizing input, like ensuring users don't have HTML in their names or comments, combined with domain-level separation and CORS policies ensures that one site can't do things that "leak" into another. It's the reason most of the time no matter how bad people mess things up Facebook getting hacked in your browser doesn't compromise your Google account.
Intrepid web developers reading this comment, please note that CORS is not, in fact, a protection mechanism. It's a way to relax the Same Origin Policy which is actually the protection relevant here. You don't need a CORS policy to protect a site from cross-site attacks, you need no CORS policy. Go ahead and make your little chat app, you're not at risk of having your messages stolen because of a lack of CORS headers.
I did say it wrong, but my point was that the site doesn't segment off each "site" into a different subdomain or any other ruleset that would allow the same origin policy to restrict access.
As it is with this site, the messages can get "stolen" by any other site on the same domain, which can be anything since anyone can upload one and direct a victim to them.
Your citation says Chrome supports 32779 and Safari >64k. I think it’s fair to say that, as a user (disregarding potential search engine aspects), 8000-character URLs are 100% fine these days.
Wouldn't infinitely spawning web workers do the same thing as a zip bomb?
```
<script>
const workerBlob = new Blob(['
while (true) { console.log("this is a worker that will never stop") }
'], { type: 'application/javascript' })
const workerBlobURL = URL.createObjectURL(workerBlob)
while (true) { new Worker(workerBlobURL) }
"Compression bombs that use the zip format must cope with the fact that DEFLATE, the compression algorithm most commonly supported by zip parsers, cannot achieve a compression ratio greater than 1032. For this reason, zip bombs typically rely on recursive decompression, nesting zip files within zip files to get an extra factor of 1032 with each layer. But the trick only works on implementations that unzip recursively, and most do not."
The iframe's sandbox attribute is doing a lot of work. I tried to change the parent window location to remove the footer, but the sandbox thwarted me since it didn't include "allow-same-origin".
It's collected after 15min, give or take. The hash isn't random, it's the SHA-1 hash of the base64-encoded data, so it's predictable -- if something keeps accessing the base-64 encoded URL, the /s/... URL won't vanish.
I tried making it more strict (by checking the Sec-Fetch-Site and Sec-Fetch-Dest headers), but not all browsers send that.
Yeah, I had exactly that, but in my opinion better, with fullscreen mode on https://flems.io. Right up until hackers found it was a great place to host their phishing sites...
I created a website years ago that let anyone come and just "post" something online anonymously, quick notes or whatever, but have since had to add a registration process and record ip addresses, as the website was overrun by what looked like russian hackers and the dark web in general looking for a place for uh... post links to child... well anyways, took me almost a month to track down all my own website links, as everything was encrypted and growing faster than i could delete it. def sucks to know that even though i took down the means for a place for them to 'conduct business', they will continue to find other websites.
Auth is handled in the playground.
We offer "Sign in with GitHub, Google, Microsoft, Facebook, and Apple". Anyone can see the code with /? but only the owner(s) can (re-)deploy it.
---
There is also service worker support which deploys as a Cloudflare Worker!
Base122 or whatever the other option is (and I'm sure there are others), which tries to take advantage of the whole UTF-8 space, and probably wouldn't even work on URLs, is only something like 15% denser. Obviously, you're limited to printable characters, here.
Cool little project! I did a similar thing recently, I wrote a pastebin that puts the file contents in the URL with brotli. [0]
It works quite well, but I'll need to update the syntax highlighting soon as at least Gleam is out of date (boy that language moves fast), and sometimes brotli-wasm throws a memory allocation error for some reason. I guess that's one cool thing that WASM brought to the table, memory handling issues.
It doesn't seem like the client actually verifies that the content it got back matches the SHA256 it requested, so in theory if you really wanted to meet them you could start sending an update website with details to get in contact with you. Though, that'd ruin the magic of it I'd bet :)
https://news.ycombinator.com/item?id=37410630 is fun but it's too much of a follow-up* to the current thread. If you get in touch with us at hn@ycombinator.com after some time (say a month or two, to flush the hivemind caches), we'll send you a repost invite.
Ok, cool. I'm not sure I understand the issue though, this thread reminded me of that page, so I thought other people might be interested in it too, and there wasn't much conversation here and felt like this was somewhat offtopic on this page anyway.
You didn't do anything wrong! It's just that if you consider two principles: (1) frontpage space is by far the scarcest resource HN has; and (2) repetition isn't good for curiosity, it follows that we need to try to keep a fair amount of time and space between similar-ish topics.
It's also in the interest of the follow-up post because then community interest in that-type-of-thing can focus on it specifically instead of getting split between semantically-overlapping threads.
The comment in the first link about Yahoo embedding a giant b64-encoded JSON object in the URL reminds me of something horrible I did in a previous job.
To get around paying our website vendor (think locked-down hosted CMS) for an overpriced event calendar module, I coded a public page that would build a calendar using a base64-encoded basic JSON "events" schema embedded in a "data-events" attribute. Staff would use a non-public page that would pull the existing events data from the public page to prepopulate the calendar builder, which they could then use to edit the calendar and spit out a new code snippet to put on the public page. And so on.
It basically worked! But I think they eventually did just fork over the money for the calendar add-on.
Mostly just the DIV with a giant string of base64-encoded JSON in a data attribute that looked pretty ugly. Website visitors were of course basically none the wiser if it all worked.
I had an idea once to implement Borges's Library of Babel just like this: all the text is in the URL. With more sophisticated encoding, you can optimize English words. Then hook it up to a "search system" so you can search for your own name, clips of text, etc.
Eventually you'd hit the URL size limit, of course, but maybe we add a layer on top for curators to bundle sets of URLs together to produce larger texts. Maybe add some LLM magic to generate the bundles.
You'd end up with a library that has, not just every book ever written, but every book that could ever be written.
[Just kidding, of course: I know this is like saying that Notepad already has every book in existence--you just have to type them in.]
(Un)fortunately web browsers [1] and URL shorteners block opening and redirecting to data URLs so they are useful mostly as bookmarks in the web browser.
Also having fun on this subject https://goog.space/, trying to add webRTC and yjs, also archive.is for storing a link (and minification). Fun to see so many people are trying things out with URLs, client side web apps, encoding/decoding data
I love this type of stuff too, but be aware ycombinator is a start up incubator - people showing off there wares is presumably encouraged, up to a point.
I don't think it qualifies as advertising. People come to Hacker News to see what hackers are working on. It's certainly a major reason why I come here.
Every Show HN post I've seen was interesting. Motivated me to start my own projects and polish them so I can show them here. It's a really good feeling when someone else submits your work and you get to talk about it.
Some images are base64 in URLs in Google image search results for their thumbnails. Does anyone have any idea why?
Search "Pepsi can" and some when you right click > copy image address will result in "data:image/jpeg;base64,/.../" instead of the website's image. Presumably to limit server cost / make the browser render? It's not for all sites, so perhaps more common sites (Walmart for example) it gives the correct image URL.
Specifically for a gallery page of search results, I'd guess that it's to provide a more-consistent experience.
When you load that results page, you'd be reaching out to ~100+ different domains that will respond and render the images at different rates (and some will fail to load at all). Base64-encoding lets you shove binary content into caches like Redis, retrieval and embedding of which would be preferable to hotlinking to a slow site. Then most of the page gets rendered at the same time client-side.
195 comments
[ 2.9 ms ] story [ 321 ms ] thread2. Modify the parameters to hijack any relevant content
3. Reshare the smol site with your changes under the guise it’s the original link
The only reason that would be a threat is if you implicitly trusted smolsite.zip, which would be an odd thing to do.
They expend enough effort in this as to ensure the vast majority of content on GitHub pages is not malware, and avoid getting blankedly flagged as such.
It's not clear if smolsite.zip can successfully set up a similar process, given that they'll serve just any zip that's in the URL, and they won't have the manpower to verify takedown requests.
Also, cookies.
Let's say I make a little chat app that stores some history or some other data in local browser storage or cookies. Any other site can just as easily access all of that information. An "attacker" could link you to a modified version of the chat site that relays all of your messages to their server while still making it otherwise look like it's just the normal chat. It would also retain any client side information you had previously entered like your nick name or chat history, since it's stored in local storage.
Most of the time sanitizing input, like ensuring users don't have HTML in their names or comments, combined with domain-level separation and CORS policies ensures that one site can't do things that "leak" into another. It's the reason most of the time no matter how bad people mess things up Facebook getting hacked in your browser doesn't compromise your Google account.
As it is with this site, the messages can get "stolen" by any other site on the same domain, which can be anything since anyone can upload one and direct a victim to them.
That doesn't look like a new attack vector, this is called phishing, isn't it?
XSS means you can inject and persist code in a webpage maintaining the same URL accessed by other users.
If you create a bigbank-fake.com and copy a manipulated version of bigbank.com's HTML, this is not XSS.
[0] https://stackoverflow.com/questions/417142/what-is-the-maxim...
```
<script>
</script>```
https://www.bamsoftware.com/hacks/zipbomb/
https://github.com/topaz/paste
https://smolsite.zip/UEsDBBQAAgAIAPtxJlepozjzcAAAAIgAAAAKAAA...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
Of course, you can just link directly to the URL the iframe points to. In the case of your video, you can simply visit https://smolsite.zip/s/57fe209faf4e6c0316ad32d7eeb792dfb571e... to have it autoplay while getting rid of the footer. I'm not sure how long the /s/ URL stays around before getting garbage collected by the server, but I bet you could regenerate it by sending a GET request to https://smolsite.zip/UEsDBBQAAgAIAPtxJlepozjzcAAAAIgAAAAKAAA... again.
I tried making it more strict (by checking the Sec-Fetch-Site and Sec-Fetch-Dest headers), but not all browsers send that.
- <https://RTEdge.net/> output
- <https://RTEdge.net/?> playground
For more information: https://efn.kr
---
There is also service worker support which deploys as a Cloudflare Worker!
See <https://sw.rt.ht/?> -> https://sw.rt.ht
It works quite well, but I'll need to update the syntax highlighting soon as at least Gleam is out of date (boy that language moves fast), and sometimes brotli-wasm throws a memory allocation error for some reason. I guess that's one cool thing that WASM brought to the table, memory handling issues.
[0] https://nicd.gitlab.io/t/
Myself and two other people have literally kept this page alive for many years - the github repo says 2017.
* https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
It's also in the interest of the follow-up post because then community interest in that-type-of-thing can focus on it specifically instead of getting split between semantically-overlapping threads.
I hope that makes sense!
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
https://news.ycombinator.com/item?id=34312546
https://news.ycombinator.com/item?id=2464213
To get around paying our website vendor (think locked-down hosted CMS) for an overpriced event calendar module, I coded a public page that would build a calendar using a base64-encoded basic JSON "events" schema embedded in a "data-events" attribute. Staff would use a non-public page that would pull the existing events data from the public page to prepopulate the calendar builder, which they could then use to edit the calendar and spit out a new code snippet to put on the public page. And so on.
It basically worked! But I think they eventually did just fork over the money for the calendar add-on.
https://sonnet.io/projects#:~:text=Laconic!%20(a%20Twitter%2...
Eventually you'd hit the URL size limit, of course, but maybe we add a layer on top for curators to bundle sets of URLs together to produce larger texts. Maybe add some LLM magic to generate the bundles.
You'd end up with a library that has, not just every book ever written, but every book that could ever be written.
[Just kidding, of course: I know this is like saying that Notepad already has every book in existence--you just have to type them in.]
As usual, no idea is unique--it's all about who executes first!
https://mkaandorp.github.io/hdd-of-babel/
data:text/html,<h1>My%20small%20website</h1><p>Look,%20it's%20real!</p>
You can use a data uri generator to base64-encode it, if you want.
Advantages of smolsite:
- Zip might let you fit a bit more than a data uri
- Some JS APIs would work on a smolsite url, but wouldn't work in a data uri
In before someone writes a smolsite to install a service worker on the domain that sends analytics for all other smolsites to their own server
> data:text/html,<html contenteditable><body style="margin: 10vh auto; max-width: 720px; font-family: system-ui"><h1>New Note
I added some basic styles so I can screenshare :D
Also in most browsers, CTRL + B, I and U work in contenteditable divs.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_...
After one commenter showed off this technique, someone else found a minimal prime giraffe: 7.
[0] https://www.reddit.com/r/math/comments/7qpfls/does_there_exi...
[1] https://news.ycombinator.com/show
Every Show HN post I've seen was interesting. Motivated me to start my own projects and polish them so I can show them here. It's a really good feeling when someone else submits your work and you get to talk about it.
You may only "Show HN" something you've made yourself.
https://news.ycombinator.com/showhn.html
Search "Pepsi can" and some when you right click > copy image address will result in "data:image/jpeg;base64,/.../" instead of the website's image. Presumably to limit server cost / make the browser render? It's not for all sites, so perhaps more common sites (Walmart for example) it gives the correct image URL.
Pepsi can image from:
[1] https://crescentmarket.shop/ data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2...//9k=
[2] But when you click through: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQwXbLG...
[3] Paperpunchplus.com shows the correct image URL https://www.paperpunchplus.com/https://cdn3.evostore.io/prod...
When you load that results page, you'd be reaching out to ~100+ different domains that will respond and render the images at different rates (and some will fail to load at all). Base64-encoding lets you shove binary content into caches like Redis, retrieval and embedding of which would be preferable to hotlinking to a slow site. Then most of the page gets rendered at the same time client-side.
In which case it would be also your hosting provider.