HN user

jackbeck

124 karma
Posts8
Comments46
View on HN

I have strongly negative connotations with rock tumblers. When I was about 8 I saw one in a store and thought it would turn regular rocks into precious stones. One of the biggest disappointments of my childhood.

Thanks! This sort of "deno"-fies Node, but in my opinion it's a bit smarter. With Deno, it's an all or nothing approach where 3rd party libraries still have the same access as the main application.

Hagana is still not at the stage where it's fully ready to block all attacks, there's still work to be done, but I do want to be transparent about the approach taken so that the open source community can create issues that show sandbox breakouts (as someone already has).

Eventually it'll get to the point where the security will be tight enough that having it open source won't make a difference.

Additionally, even having this rudimentary protection is still more effective at blocking generic supply chain attacks than not having any protection at all.

Thank you!

I've given this exact question some thought. I think that the only real way to make sure this doesn't happen is by not allowing any 3rd party packages into the codebase. That means any package I want to install will have to be manually copied over. Granted, that this isn't the state now in the repo since I wanted to get to a POC phase as quickly as possible, but it's something I'm going to do.

Yup, I agree with you about this. It’d be interesting to do a deep dive into a library like FingerprintJS and see what has the most weight in terms of uniqueness. Maybe getImageData is worthwhile blocking, but perhaps other APIs will increase the amount of entropy.

The problem with a lot of these attempts at fingerprinting prevention is that they cause additional data which can be used to more accurately fingerprint users.

getImageData() is blocked - datapoint

Any detectable difference from what a “regular” browser would return is another point of entropy.

There are sects (like the ultra orthodox) who don't use Sabbath mode specifically for this reason. They say that the added weight causes the elevator's motor to work harder thereby desecrating the Sabbath.

Thanks for your in depth explanation. The current structure for me is I have the main app which is responsible for previewing and making the edits to videos. This project does not include FFmpeg. I have a separate project which is the renderer. The renderer is loaded in a separate iframe which loads ffmpeg.wasm. Would this be separate enough that upon request I would only have to open source the project which includes ffmpeg.wasm?

I agree with your reasoning, the issue is that it requires a fair amount of work to restructure the authentication flow. Additionally, I would have to preserve the project and migrate it to the newly created account. At the moment I have higher priority usability issues that I'm working through, but I will get to it at some point.

I'm not a lawyer, so understanding the exact implications of licensing is beyond me. My thought process behind this is that there are other (even commercial) services offering web-based video editors that use ffmpeg and are closed source. In any case I completely isolated the renderer into an iframe so in theory I could allow people to upload their own version ffmpeg.wasm if they were so inclined to.

The wasm port of ffmpeg that I'm using isn't modified so there's nothing for me to open source. Once I finalize my modifications of the library, I'll be open sourcing it.

When I was looking around to see if my idea of a client-side video editor was even possible, I found Clipchamp. Since they were able to do it, I knew it was possible and I got started immediately afterwards.

The final render is performed in the browser. I’m very much a fan of offloading computationally expensive take to the client so that I can provide this service for free.