13 comments

[ 2.3 ms ] story [ 26.7 ms ] thread
Thanks for sharing this. We had posted this as a “Show HN” a couple of weeks ago but it didn’t get a lot of traction there. Happy to answer any questions!
Since you seem to be using webcrypto, here is the obligatory mention of "browser crypto considered harmful": https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
Thanks for pointing it out. We are indeed using wevcrypto to encrypt the data generated during the recording. This usecase, however, we’d argue is quite well suite for webcrypto.

The typical critique (including the one you linked to) referring to the presence of scripts from multiple untrusted soutces doesn’t quite apply in this case because the encryption used isn’t really meant to protect against such scripts. Any script active on the page already has access to all the information RecapJS is gathering (and eventually encrypting) so there is no need for RecapJS to worry about them.

The only time RecapJs handles sensitive data that needs to br protected from third party access is during replay/playback. In this case the threat is mitigated by either hosting the player (which is a static web application) in a closed off network in the case of offline replay or by loading an audited piece of js in case of remote full session storage.

Ah, ok. That makes sense. Thanks for the clarification.
Neat! Are you storing the data in localstorage?
In the case of offline recording the data is stored in indexedDB. Localstorage limits are typically too small to store a reasonably sized session recording.
How much data is stored on the user's disk per session?
The actual amount in bytes will vary with the complexity of the app, the amount of activity in the session and the length of history the recorder is configured to store.

Typically this will be a few MBs for the default 10 minutes of history.

I can see this being useful in places where compliance is important (medical, finance etc.).

Is the blurring not reversible though? Even if lossy?

The pixelation is just a visual effect. When redaction is on, the text content/images etc are not captured at all. During replay/playback the place where the original content was is filled with randomly generated data whixh is then pixelated.
I see, pretty cool!

I noticed that when typing in the email box nothing happens in the recording. I assume that this is to hide the email address but it would be nice to have some sort of visual cue (may be asterisks, like passwords?), otherwise it looks broken.

Thanks for the feedback! Yes, the intent is to automatically prevent capture of personally identifiable information. The problem with asterisk though is that it still leaks the lengtg of the email address.

We are exploring other options with the right balance between minimizing information leak and usability.

Fair point about the length leak.

Good luck with this.