Rethinking front-end error reporting

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.

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.

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.

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)