4 ms·

Reply to Grandparent and this: Very cool and definitely useful to record and replay the session and modify breakpoint conditions for replay. I wonder if session

Reply to Grandparent and this: Very cool and definitely useful to record and replay the session and modify breakpoint conditions for replay. I wonder if session recording like this could be safely brought to backend systems. You'd almost have to stub every remote call to allow for replayability in isolation of external services, and the potential for data leakage from a downloaded session is also a concern. I'm glad someone else is working on problems and tools like this. I should note I'm not disparaging the use of debuggers in my comments, but lamenting the nature of the process of debugging the types of systems we deploy today, and the largely non-interactive nature tradeoffs we've made for scalability, reliability, availability, and operability. Sometimes I long for the simplicity of a fully self-contained local system, but I know we just don't live in that world anymore, and haven't for a long time now.

acemarke 4y ago
Yeah, data leakage is a concern in the sense that _everything_ about the process gets recorded. (At Replay, all the recordings are encrypted and access-controlled: https://www.replay.io/security-and-privacy https://www.replay.io/security-and-privacy ) The way Replay specifically works is that we fork and modify the Firefox and Chrome browser and Node runtime to add the necessary support for capturing and stubbing all OS-level syscalls, as well as making other changes to ensure near-deterministic playback. So, when the recording gets replayed, the process gets all the same external inputs it did the first time: - https://docs.replay.io/contribute/how-replay-works https://docs.replay.io/contribute/how-replay-works One of our long-term goals is to bring down recording perf overhead enough that we can do "always-on" recording into a buffer, so that the browser or Node just _always_ runs in recording mode, and if something fails the last minute or so of the buffer gets uploaded for analysis.

acemarke 4y ago

Yeah, data leakage is a concern in the sense that _everything_ about the process gets recorded. (At Replay, all the recordings are encrypted and access-controlled: https://www.replay.io/security-and-privacy https://www.replay.io/security-and-privacy ) The way Replay specifically works is that we fork and modify the Firefox and Chrome browser and Node runtime to add the necessary support for capturing and stubbing all OS-level syscalls, as well as making other changes to ensure near-deterministic playback. So, when the recording gets replayed, the process gets all the same external inputs it did the first time: - https://docs.replay.io/contribute/how-replay-works https://docs.replay.io/contribute/how-replay-works One of our long-term goals is to bring down recording perf overhead enough that we can do "always-on" recording into a buffer, so that the browser or Node just _always_ runs in recording mode, and if something fails the last minute or so of the buffer gets uploaded for analysis.