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.
sha2nk|7 years ago
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|7 years ago