
RecapJS: Browser session record/replay without leaking user data - illiala
https://recapjs.com/
======
briefrrapp
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...](https://www.nccgroup.trust/us/about-us/newsroom-
and-events/blog/2011/august/javascript-cryptography-considered-harmful/)

~~~
sha2nk
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.

~~~
briefrrapp
Ah, ok. That makes sense. Thanks for the clarification.

------
sha2nk
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!

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

Is the blurring not reversible though? Even if lossy?

~~~
sha2nk
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.

~~~
cptnntsoobv
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.

~~~
sha2nk
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.

~~~
cptnntsoobv
Fair point about the length leak.

Good luck with this.

------
googleminus
Neat! Are you storing the data in localstorage?

~~~
sha2nk
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.

~~~
googleminus
How much data is stored on the user's disk per session?

~~~
sha2nk
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.

