Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Code Recommenders » [automated error reporting] Anonymization function(Problem with a CoreException with the message: "File not found: 'X'".)
[automated error reporting] Anonymization function [message #1603916] Fri, 06 February 2015 13:55 Go to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1252
Registered: October 2011
Senior Member
From the documentation:
Quote:
Anonymize package, class and method names:

When enabled, this will clear potentially sensitive package, class and method names occurring in a log's stacktrace by the literal 'HIDDEN'.

For example, a name com.mycompany.Class.secret(..) would be replaced by HIDDEN.HIDDEN. Classes originating from org.eclipse.* , org.apache.* , java.* , javax.*, sun.*, as well as selected 3rd party libraries shipped with the Eclipse IDE, are not anonymized. This option is enabled by default, but committers would appreciate if you'd send stacktraces unannonymized. This gives us the opportunity to quickly spot troubling 3rd party libraries and may also allow us to let these projects know that their users are struggling with.


This is a really important feature in order for the user to have trust in the system.

We have a case where the JDT throws a CoreException with the message File not found: 'X'.

My problem is in the content of this X. Our tooling in the IDE (Scout SDK) is working with the java source code in the workspace and tries to get a file.

For the error report in question: the name and the path of the missing Java file in the workspace are public. This provides the package name and some insides of the project the developer is working on.

I can't evaluate the sensibility of this information, but the code in the workspace is not open-source and I guess that our customer will not really be happy if he finds this bug report.

What do you think from this case?

Is it possible for you to anonymize the message of an Exception?
How can we prevent cases like that in the future?

In my opinion one possible action could also be manual: when the Error Report is transformed into a Bugzilla entry. Sensible information should be removed. Is this possible?

Maybe the case we speak about was generated before the HTML-Backend for Error Reports was introduced.

I have decided to discuss this publically because I think that this problem is important and can raise concerns in the community. If people loose trust in the IDE, they will disable the "automated error reporting" feature.


Re: [automated error reporting] Anonymization function [message #1603941 is a reply to message #1603916] Fri, 06 February 2015 14:18 Go to previous messageGo to next message
Marcel Bruch is currently offline Marcel BruchFriend
Messages: 289
Registered: July 2009
Senior Member

Hi Jeremie,

1. every user can enable "anonymize messages" in the initial configuration dialog before sending any error report.

2. every error report is send via https to eclipse.org. Only the reporter and eclipse committers can access sent error reports. Committer and reporter access is https secured. Nothing is send over the wire unprotected.

3. error reports are stored in an internal system and not published to bugzilla directly (anymore). A committer may decide to send an error to bugzilla from the error reporter's web UI. But before he does so, he can edit the bug summary and bug description. Thus, it's always possible to remove potentially sensitive information before anything goes into a public bugzilla.

4. Bugzilla offers the ability to secure bugs so that only selected groups of committers can access them. If necessary, you can request that protection for your product and we can configure our bugzilla connector to create bugs only with this security flag set.

4a. All error reports sent before M5 were directly sent to bugzilla but protected by the Bugzilla's "security advisor" flag (that means it was always only visible to committers and never visible to the public). To become visible a committer would have to remove that security advisor flag explicitly. However, even if removed it can be set at any time to enable protection again.

5. We have logic in place to filter log messages that contain java source code (JDT sometimes logs that data). We may extend this to replace file paths in a send error report. If this is what you need please raise a feature request at [1] with a short explanation why. I'll then take this to the Legal team.


If I did not answer one of your questions, or missed out an option you had in mind, please let me know.

Thanks,
Marcel



[1] https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=short_desc%2Cvotes&component=Stacktraces&f1=status_whiteboard&list_id=11050321&o1=allwordssubstr&product=Recommenders.Incubator&query_based_on=Stacktraces%20Feature%20Requests&query_format=advanced&v1=votes

[Updated on: Fri, 06 February 2015 14:43]

Report message to a moderator

Re: [automated error reporting] Anonymization function [message #1608170 is a reply to message #1603941] Mon, 09 February 2015 10:20 Go to previous message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1252
Registered: October 2011
Senior Member
Thank your for the clarification of the process. I think we need to learn how to deal with this new tool.

I will check with our team and other developers using the IDE. If additional concerns are raised, I will let you know.

Marcel Bruch wrote on Fri, 06 February 2015 15:18
1. every user can enable "anonymize messages" in the initial configuration dialog before sending any error report.


See also: Bug 459328
Previous Topic:Does CodeRecommender have an impact on CTRL+1 proposals.
Next Topic:Error when using code recommender
Goto Forum:
  


Current Time: Thu Apr 25 23:11:03 GMT 2024

Powered by FUDForum. Page generated in 0.02464 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top