
Rethinking front-end error reporting - jastr
https://blog.logrocket.com/rethinking-front-end-error-reporting-659db3950db3
======
bryanrasmussen
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?

~~~
pkriete
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.

~~~
gnud
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.

~~~
x0x0
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.

~~~
bryanrasmussen
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.

~~~
x0x0
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.

~~~
bryanrasmussen
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.

~~~
x0x0
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.

~~~
bryanrasmussen
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.

~~~
x0x0
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.

~~~
bryanrasmussen
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...](https://ec.europa.eu/commission/sites/beta-
political/files/access-essential-services_en.pdf) 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](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)

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

~~~
benthehenten
(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!

------
ro-laren
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!

------
salt-licker
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?

~~~
anarchy8
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.

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

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

------
simplify
How does this compare to fullstory.com?

~~~
arbesfeld
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)

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

~~~
benthehenten
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)

~~~
txmjs
Absolutely, keep up the good work!

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

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

------
seattle_spring
Does LogRocket easily hook up to PagerDuty?

~~~
pkriete
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!

