Rethinking front-end error reporting | Hacker News Reader

Rethinking front-end error reporting

blog.logrocket.com

69 pointsjastr28 comments

So, we've logged everything the user has done into logrocket, and given logrocket some way of uniquely identifying the user.

So anyone should ask, what is the GDPR impact here?

Note: I work at LogRocket (and also a European)

I believe we fall into the same categories as any other analytics tools (or any data controller/data processor in GDPR speak). Which is to say, there are compliance boxes that need to be checked (right to object, right to be forgotten, etc), but it's possible to be compliant and we plan to be when the law takes effect in May.

It's also worth noting that pretty much all frontend error reporting tools nowadays send a URL along with the exception and allow you to assign user data to the event.

Not only the right to be forgotten - but also requiring real, informed consent, up front, that can be denied.

Seems simpler to try really hard to keep the data anonymous.

I'd call it a legitimate interest (site development and debugging tools) and skip the consent. Simply say you must allow cookies and our debugging tool or don't use the site. Particularly with SPA or js framework heavy sites where more bugs occur only in the browser, this is simply a development tool. Now, if you were primarily a rails site that uses very little javascript, this would be a much more questionable call.

There's no possible way to keep an app that can reconstruct screen state anonymous. The app, by necessity, records all info the user enters.

I'd be more concerned about PCI.

This would probably run into legal problems, you're essentially saying you must allow us to track everything or don't use the site, but GDPR is about granular permissions - if you assert that users must give blanket permissions I would argue that breaks GDPR right away. The legitimate interest is maybe arguable, but then people can argue hey you can develop and debug your site without these pervasive tracking tools. I think allowing this as a legitimate interest would be a big attack on the law.

No one is discussing blanket permissions, ie using these cookies or information for advertising.

You cannot have a site with a login without a cookie. It's gdpr compliant to inform users you will use cookies for that purpose and not pretend there's some magic way to have a login gated site without a cookie or something functionally equivalent. A site development tool is very similar. Understanding if code is working and where it's breaking is a fundamental technical requirement to build and operate a production website.

Stoking paranoia by calling bug reporters "pervasive tracking tools" is misguided; this tool only sees information that the user was handing to the site. ie any personal data is obviously already disclosed to the site.

I wasn't talking about the cookie.

As far as blanket permissions goes you said 'Simply say you must allow cookies and our debugging tool or don't use the site', saying if you use the site we gather all this data sort of implies a blanket permission is given by using the site. This is generally what one does with the cookie warnings - the ones that say if you continue to use the site you agree to us setting cookies. I suppose you meant that you would have a message like - in order that we can keep our site performing optimally and fix any errors that might arise in day to day operations we need to track your actions on this site. (only a better message than that) - maybe that works but - well I think it might run into problems.

Blanket permissions do not only mean we allow you to advertise to us.

The bug reporter, as I understand in this case, tracks everything the user does on the site and associates it with the user account. I suppose that something that tracks everything you do on a site can be considered pervasive.

You can argue you have a fundamental technical requirement to gather some particular data, but going from the technical requirement is to understand if code is working and where it's breaking to therefore we will need to gather every action users do on the site seems shortsightedly heading for a significant fine.

This is what I meant in my other comment that if data is saved for a reasonable amount of time - 3 weeks maybe - and especially if the customer gives permission to analyze the data when they make a bug report then you would free from any problems.

The simple fact is the tracking tool knows nothing that the site doesn't already know. Because the user performed it on the site. If the user wasn't comfortable with the site knowing information X, and associating that information with that account, then the user shouldn't have done it on the site.

The sole additional information this tracking tool gathers is things like internal state of the application. There is zero additional personal information disclosure.

This seems to be a personal or philosophical stance of yours, I'm talking specifically about legal requirements of GDPR. Those are different than the legal requirements of the cookie law.

As far as the tracking tool knowing nothing that the site doesn't already know, in real time that is true, but the GDPR addresses your site's 'memory' and in that case it is obviously false - which is actually sort of the whole purpose of the logging tool isn't it?

So, as an easy to understand example, in my current work at a telecom we have a map where the user can add in address information and find if there is any outage happening in their area.

We were logging the addresses entered. For GDPR reasons we removed these addresses from the log. We have set up temporary logging of the addresses that raise certain kinds of errors so that we can examine those addresses later - this is a reasonable usage and we inform the user 'We may save the addresses you enter here for a short time for the purposes of improving the performance of the application' (not exact message).

The tracking tool would retain the data we have decided not to retain, admittedly in a more difficult to extract format, but the GDPR does not make allowances for that and really it would be silly if they did.

Furthermore, for our site and service (and for any services that could be argued that people need to use) I believe stating if you're not okay with us keeping your data don't use the site would run into non-GDPR legal problems but would also be contrary to GDPR requirements and is as such a no-go for anyone wanting to remain in business - and anyway it would probably piss off customers.

I could give other examples, but as I said your argument seems based on philosophical grounds that I believe if they were accepted by a European court would render the GDPR effectively useless, and as such I doubt it would be accepted.

Three points, and I've done a detailed review of the gdpr as it applies to our business:

1 - I'm unaware of non-gdpr legal problems -- I only have to pay attention to UK and DACH. The GDPR is (imo) mostly aimed at intent: see the distinction between processing and profiling. If you log user actions to profile, it's pretty clear you would have to allow them to disclose and allow opt out. But internal application logging is not profiling as defined by the gdpr. The restrictions I'm aware of for processing are 'adequate, relevant and limited to what is necessary'. I'm pretty confident -- as are our attorneys -- that the courts will be ok with internal debugging tools. Particularly because these tools do not make decisions.

2 - It's definitely my opinion the customers liable to throw a fit about you recording transient application state are customers you don't want.

3 - The gdpr does not require sites to allow ad-hoc opt-out of processing for the same purpose; in our case, operating the site. See recitals 32,42.

3a -- Your address example isn't (imo) relevant. Your purpose -- instantaneous lookup -- has expired. Operating a site or diagnosing bugs has no time limit except (possibly) the time limit to reasonably have a bug reported, diagnosed, and fixed.

1. I don't think it's necessarily a problem, or at least right now - but the EU is working on the concept of essential social services https://ec.europa.eu/commission/sites/beta-political/files/a... which telecom is covered by. And then I believe the scandinavian countries might also be amenable to an essential services argument if a telecom says stop using our site to find out if there are service outages in your area if you don't like us recording everything you do - I haven't checked on this, but am somewhat paranoid about stuff though.

I agree that the GDPR is mainly aimed at intent, but it is also aware that you may intend to get something for purpose X and repurpose it some years later for purpose Y. Therefore you should also be ready to demonstrate that the processing is 'adequate, relevant and limited to what is necessary'. I think people could argue that tracking everything a user does is not limited to the purpose of identifying bugs. But by limiting the time of data retention it would be limited for that purpose. But I guess we disagree on this matter.

2. People might not want to be tracked. And if you don't do it they might be willing to give you lots of money for your service. We get paid lots of money by some of our customers, and I don't think we want to piss them off. I guess we have disagreed on this matter also.

3. True, but you have to tell people what you're recording. And I don't think the purpose here is definable as operating the site.

3a. that's my point about the diagnosing bugs having an intrinsic time limit. I would say 3 weeks to report a bug. The purpose of the recording is not operating a site, it is diagnosing bugs (although it could be used in a hotjar way also to run through how people use the site for UX analysis, and considering that when using Hotjar you should probably take steps to make sure you are in GDPR compliance https://www.hotjar.com/gdpr I suppose the same sort of minimum steps should apply here [and IIRC hotjar doesn't associate the data it retains with a particular user])

I suppose other than that they need to allow for deleting all video of sessions related to a particular customer if requested (as part of a larger request to delete data you have collected regarding that particular customer)

actually I think about the legitimate interest defense.

If saving of data was time limited (less than a month), customer contacts says they had a bug and they get back an email allowing the retention of the data for fixing the bug.

Especially if you could limit recording to new features/worked on parts of the application.

These would be totally defensible.

I feel weird... like I've never heard of this before and it seems fully built out... what am I missing?

(disclosure - I wrote this article and work at LogRocket)

The product is built-out in the sense that we have many customers who use LogRocket daily to fix bugs and support their users.

Of course we've only just started toward our long term goal and have lots more work to do!

We built a similar system internally that accomplished some of these functions. Essentially data is ingested to an ELK cluster with some custom views on top. This definitely looks more polished though!

I've used TrackJS in the past - they have context on the user session surrounding front-end exceptions, e.g. what the user clicked on beforehand. Is a video replay really that much more useful?

In my opinion yes -- being able to actually see the user going through the app before they clicked on the thing that made an error can make a huge difference. Sentry's breadcrumbs are similar, but they don't provide enough context. An actual session recording provide all the context.

Very cool! Do you know if this product is currently HIPAA compliant or if there are plans to make it so in the future?

Thanks! Yep, LogRocket is HIPAA compliant though we usually suggest that clients scrub all PII before it leaves the client.

How does this compare to fullstory.com?

Good question- customers that have switched from FullStory generally say the logging is the reason they choose LogRocket. Network, console, and Redux logs gives support and developers crucial context for fixing bugs and understanding user issues.

At larger scale (10M+ sessions), LogRocket dynamically samples sessions to help surface the most important sessions and issues from your application. Hope that's helpful.

(disclosure: I work on LogRocket)

Are you still planning on releasing an open source version of LogRocket, much like Sentry offers one?

In the long term, it's definitely something we plan to do. For now, we are prioritizing building new features and improving the core product.

Doing open source well requires significant resources for community management, PR review, and support. When we do release an open source version of LogRocket, we want to be sure that we can dedicate enough time to supporting our users and engaging the community.

(I work at LogRocket)

Absolutely, keep up the good work!

I see this will log Redux actions/state leading up to a crash- can it also log data from MobX?

Yep! LogRocket also supports Vuex, @ngrx/store, and mobx-state-tree (both actions + state logging)

Does LogRocket easily hook up to PagerDuty?

It doesn't yet, but we did build it with reporting/monitoring tools in mind (a Slack integration is part of the beta).

We think to do alerting correctly you really have to be sure that you're primarily flagging issues that actually impact the user. Nobody wants to get called in the middle of the night for a random browser quirk that didn't affect usability.

Definitely get in touch if you have something specific you need alerting on!

Reply on news.ycombinator.com