| Great work yz-yu. Hope you've learned a lot- I've personally found the session replay space to be incredibly rewarding. However, as a session replay industry competitor and a former security researcher for most industry players, I caution anyone thinking of using a side-project like this on production applications to proceed slowly with care. Security and Privacy are extremely hard to get right here. The tricky thing about session replay analytics is that attackers have a huge attack vector, and compromise means gaining a treasure trove of all user data. The nature of replay is in a way a form of XSS. Modern security features help (like CSPs, iframe Sandbox attribute) but browser changes can cause issues. Some of the challenges:
- CSPs can often be bypassed using Google API libraries, <Object/>, <SVG>
- Blacklisting <SCRIPT/> tags can often be bypassed with an XML namespace
- CSS based data or password exfiltration.
- Clickjacking, "data:" urls etc.
- Could you imagine a web request proxy server deploying Service Workers?
- postMsg() from further nested frames Substantial work goes into sandboxing replay environments and limiting PII. Defense in depth is particularly important here. Enterprise level research, auditing, monitoring and care should be taken seriously. |
Quote from my introduction blog post:
===
Today we already have some commercial session replay products like Logrocket, Fullstory, etc.
If you are just looking for a ready-to-use tool and would like to pay for its service, I would recommend you to use the above products, because they have well-tested backend services that can store the data for you and perform some higher order features.
===
So I don't think rrweb is a competitor of these commercial products.
Actually, I would like to see rrweb grows into a base of many commercial products in the future, which means it handles most of the privacy and security issues, so the other developers can build many fancy projects base on it without spending time on the hard part again and again.