Hacker News Reader

Comment by thedg | Hacker News Reader

Great concern!

We do two things to address that:

The first is nothing gets recorded and saved (or even sent to our backend) until the user actively chooses to log a bug. So it’s like actively choosing to save a HAR file when there’s a bug.

The second is we scrub all network requests on the client side for anything that resembles PII or sensitive data. We just don’t want it on our servers.

Is there anything else you think we should do?

Definitely building on the Chrome platform there’s always API risk of something changing but I hope Chrome and other browsers will keep it possible to provide a better debugging experience through extensions like ours for people who want it.

View on HN

Some kind of end-to-end team encryption would be great, I could generate a local passphrase using 1Password or something and put it in the team vault. Then you wouldn't have access to the request metadata (maybe outside of hostnames?) on your servers. Alternatively, an option to simply download local replays and then a desktop/electron viewing client instead of having to upload them to a server would be great too

I like that idea a lot, we should do that

I see in the Security page [0] that you filter out headers that you think are PII or tokens. And I see that you're willing to receive feedback via email. I don't think this approach is scalable, for the main reason that sometimes we use custom headers to pass tokens.

My suggestion is to have a setting that lists default headers you think should be obfuscated, and the user/team can remove and add to them as they like.

0. https://jam.dev/docs/product-features/dev-tools/security

[disclosure: I work at Jam]

Yes! I think that's a great idea.

+1 great idea!

Maybe scrub cookies and authorization headers by default, but make them an opt-in for bugs where they're relevant?

Edit: it looks like this is already the case!

> but make them an opt-in for bugs where they're relevant?

The tool seems to be built for people who don't know what to include in a proper bug report (As they are maybe not technical enough), so not sure how helpful that choice would be for them.

This might be a feature fit for the pro tiers. I would really like it for our QA testers who'd want to include that information but still aren't that technical to know all the places to look for that information.

Reply on news.ycombinator.com