How
about something very simple instead… Don’t filter anything.
See an error in the log, pop a dialog showing the full
content of the stack that will be sent and asking for
permission. If the text box is editable, the user can redact
as appropriate for their needs. Then, “yes”, “no” or “no and
don’t bother me for [select interval]”.
The
approval of the two councils, as Wayne has outlined, seems
to me like an unnecessary step. It’s not required for other
projects, so why should it be required here? We need legal
review, which should be able to commence now. We need EMO
decision on infrastructure. We need approvals from various
package maintainers.
In
terms of tracking to show effectiveness of the service, it
would be very helpful if the reporting portal had “open a
bug” link that embedded a keyword in the bug. This would
make it easy to query bugzilla six months or a year from now
to determine if the service is useful and the backend should
continue to be maintained.
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.