Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Kage – Shadow any website to a single binary for offline viewing

github.com

Post reply on HN
Print view View original

141–150 of 152 posts

Re: Show HN: Kage – Shadow any website to a single binary for offline viewing

#141

Post by d3Xt3r »

Bad_CRC wrote: post #123
d3Xt3r wrote: post #113

Earlier quoted context omitted.

I'd like to request something between what GP suggested and what your program is doing currently - basically I still want a single binary, but instead of embedding a full browser in it, I would like the binary to be just a self-extracting archive that calls the user's default browser, maybe in a new window/frame. Basically I'm looking for something like the old-school .chm files on Windows, where you could pack a bun…

I instantly searched for chm on the comments and yours was the only one :o

I really miss the old .chm files, they used to be quite thorough, like the ones that came with MSDN / VS 6.0. In modern times, AutoHotkey continued that tradition, absolutely love their comprehensive .chm. But in the Linux/modern world, outside of the man pages, you need to go to the web everytime to lookup stuff and I hate that.

Re: Show HN: Kage – Shadow any website to a single binary for offline viewing

#142

Post by danielheath »

recursive wrote: post #99
danielheath wrote: post #59

Earlier quoted context omitted.

Js modules don’t work on file urls (classic js does).

They can be made to work with blob urls. I have done this.

Okay that’s super interesting and I would love to see an example or writeup - I have a project which would benefit from being able to do that.

Re: Show HN: Kage – Shadow any website to a single binary for offline viewing

#143

Post by nikisweeting »

dimiprasakis wrote: post #121
nikisweeting wrote: post #92

Earlier quoted context omitted.

Docker is designed to be undetectable by default, the best way I have found is to set env IN_DOCKER=True manually in your Dockerfile + check that there is no $DISPLAY configured + that you're on linux. Usually if all/most of those are true you can safely add --no-sandbox --disable-setuid-sandbox --disable-dev-shm-usage etc. all the docker-specific flags. Thats what we do in https://github.com/ArchiveBox/ArchiveBox/bl…

Cool approach. But, a compromise still lands on host's kernel, Docker doesn't provide kernel isolation (well it does on a macOS because it runs in Docker machine but thats a side effect). I wonder if a better solution would be to play with seccomp or Linux capabilities so that Chrome is sandboxed even in Docker. Not sure how this would work tbh. Answering here to get ideas, I saw your fix on Git and request for feedb…

I have never seen anyone pull off seccomp nested sandboxing of Chrome in Docker before, if you manage to figure it out please let me know!

Re: Show HN: Kage – Shadow any website to a single binary for offline viewing

#144

Post by timerol »

praveer13 wrote: post #138
xlii wrote: post #115

> No tracking, no network calls, no surprises. Won't comment on a project (though idea seems interesting) but this in README is a tell for me ;)

Somehow 'Kage' is the first name claude suggests to me for any new project as well

The Japanese word for shadow?

Re: Show HN: Kage – Shadow any website to a single binary for offline viewing

#145

Post by recursive »

danielheath wrote: post #142
recursive wrote: post #99

Earlier quoted context omitted.

They can be made to work with blob urls. I have done this.

Okay that’s super interesting and I would love to see an example or writeup - I have a project which would benefit from being able to do that.

It's a technique I created (someone else must have done it first??) for a sandbox demonstrating a web UI framework I made. https://mutraction.dev/sandbox

To see it work, click "Download self contained .html" from the menu.

Here's the source file that handles this part: https://github.com/tomtheisen/mutraction/blob/master/mutract...

The idea is to use ... to define modules. That's something I just made up. For each such script, provision a blob URL. The main blocker is usually the same origin policy. Crucially, these blob URLs count as the same origin. So then you need to rewrite the imports from the named modules to the blob URLs. I used some regex rather than a proper parser, but it was more than good enough for me.

It seems quite doable to make some proper bundling tools around this concept.

Re: Show HN: Kage – Shadow any website to a single binary for offline viewing

#146

Post by embedding-shape »

rzzzt wrote: post #139
embedding-shape wrote: post #85

Earlier quoted context omitted.

Yeah, but that's fine, the document is .html, and it can load ./app.js or ./style.css just fine even if loaded by file:// (as long as it isn't initiated by JS itself, then Origin starts to matter a lot more), otherwise basically every single local HTML file would suddenly be broken, I don't think anyone would have accepted that even with the origin changes.

I tried this on a small example and it works indeed. In my head this would have been something like a restrictive CSP script-source directive, even if not exposed in response headers or anything.

> I tried this on a small example and it works indeed.

I was thinking "of course it works, how else would people get started creating websites otherwise?" then I remember what's the most common approaches in the frontend ecosystem nowadays.

Back in the days of yore, every tutorial/book started with "First we create a index.html file which you open in your browser ...", even a JavaScript resource would start with this of course :)

Re: Show HN: Kage – Shadow any website to a single binary for offline viewing

#149

Post by rzzzt »

embedding-shape wrote: post #146
rzzzt wrote: post #139

Earlier quoted context omitted.

I tried this on a small example and it works indeed. In my head this would have been something like a restrictive CSP script-source directive, even if not exposed in response headers or anything.

> I tried this on a small example and it works indeed. I was thinking "of course it works, how else would people get started creating websites otherwise?" then I remember what's the most common approaches in the frontend ecosystem nowadays. Back in the days of yore, every tutorial/book started with "First we create a index.html file which you open in your browser ...", even a JavaScript resource would start with this…

Weeellll those tutorials span a ~30 year time range now :) AMPP stacks and Python's built-in HTTP server was available most of the time if you needed to get away from the file:// protocol.

The protection mechanism was introduced so that malicious saved pages can't just grab things from your Downloads folder and send stuff it to an attacker's server. But the method turned out to be a bit more refined than I have imagined: you can display an image but can't grab the pixels, run a script but not inspect its source code, fetch() will be unavailable, etc.

Post reply on HN