| Re: [cross-project-issues-dev] Error reporter and third-party code |
> I assume that you and everyone else understands why classnames from non-eclipse/non-apache bundles are replaced by HIDDEN.HIDDEN by default. I can imagine cases, such as pre-release products and internal solutions, where stack frames contain sensitive information, but that isn’t the general case. Stack frames should not be considered sensitive just because they are from a non-OSS code base. Users post stack traces with commercial code references in forums all the time. Companies that worry about this sort of thing scramble their bytecode. User should not be expected to know how to change preferences to turn off filtering as none of them will bother to do so, especially as the error reporting system gives them the impression that the error reports are actionable with information omitted. My proposal: When a we detect a non-OSS stack frame, we actively ask the user to make a choice that’s then persisted for that instance of Eclipse. If they make a choice indicating that non-OSS references are sensitive, we don’t even bother sending an error report. I have yet to see an error report with hidden frames that was actionable. This active choice should be viewed as equivalent to user making a choice to grab a stack from the log and post it on the forum. > I strongly conclude that if someone would have cared at that time, they would have had the chance to participate from the very first moment. I brought up the issue of better handling third-party plugins several times from the very beginning and was brushed off. Thanks, - Konstantin From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Marcel Bruch Konstantin, let me send this at the beginning: this discussion is greatly appreciated - although my personal answer might not be satisfying yet… Library projects like Sapphire or Nebula are somewhat special because they are (more or less) exclusively used by third-party plugins. Hence they do not benefit that much from the privacy defaults.
Although your questions may give a different impression, I assume that you and everyone else understands why classnames from non-eclipse/non-apache bundles are replaced by HIDDEN.HIDDEN by default. No matter if one does or not, one may ask the following questions (again) and judge differently now (after ten thousands of users reported ~170K errors in the last 30 days): (i) whether a class name in a stacktrace should be considered as "potentially private information“, and (ii) whether it should be anonymized by default. When we (Eclipse Foundation staff and me) discussed the legal implications of the error reporting we came to the conclusion that a class name may reveal sensitive information and thus should be anonymized by default.
The discussion about what to anonymize and how took place on August 2014. First with the Eclipse Foundation Staff in a couple of conference calls and then published and summarized in several mails to cross-projects-issues-dev@xxxxxxxxxxx. I strongly conclude that if someone would have cared at that time, they would have had the chance to participate from the very first moment. Let me know if you need me to pull up all emails and slides I sent to cross-projects regarding the error reporting at that time. I’m pretty sure the whole process was quite transparent at any time and visible to everyone starting from M1 to RC4 :-)
IMHO this is more a legal question then a technical one. It all depends how lawyers (and users) judge on the two questions above. I can imagine that - if member companies agree to collect their error reports at eclipse.org OR to opt-in to disable anonymization for their bundles and namespaces - we can reduce the number of HIDDEN in your error reports. But as I said, this would need the support of the Eclipse foundation and like of the member companies. Konstantin, I assume you understand that user may find stacktraces to contain potentially sensitive data (if not - let’s assume it hypothetically), which options would you propose? Regards, Marcel |