Thanks,
- Konstantin
Let’s trim the messages after 140 chars. There can’t be much source code in it, right?
I guess Wayne’s concern are message like "your password to my.secret.server is wrong". It’s impossible to capture them all. But I think it’s also un-reasonable that this concern should prevent any progress.
Or if you still have concerns: let’s skip the message completely. the stacktrace is what we need anyways to fix issues.
Keep in mind that org.eclipse code might be called from 3rd party code.
IMHO it’s fine if we apply the following filters (note, I’m assuming you hook into ILog (ILogListener) and analyze the full IStatus):
- the originating plug-in id starts with org.eclipse
- every source info in the stack frame starts with org.eclipse
- there is no other trace of 3rd party information (in this and any nested IStatus children, etc.)
- stopword list (blacklist) of message content (to be maintained on the server as static list and updated once in a while)
You could then compute a hash and submit this for a server-side duplication check (this should increase a hit-count on the server so that we at least know about dups). If the dup check is negative, I think you can submit it.
But before anything is actually submitted, you have to bring up a dialog which allows users to review the information to be submitted and recorded and to pick from yes/no/never/always (opt-in model).
If all that is met, the efforts to protect privacy and sensitive information sounds reasonable to me.
Oh, you might want to include a detection for message patterns rather soon than later. Quite a few messages are a result of formatting with different argument. Would be great if group those together (for dup detection and/or anonymize argument). Especially if one of the argument is a local temp folder path.
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
