[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Error reporter and third-party code
|
> 'instance of Eclipse' is ambiguous.
I mean the Eclipse installation. The reason I think this scope is the correct one is as that's where the plugins reside that the user is asked to make a choice regarding. For instance, I might have one installation with pre-release code that's private and another installation with all released code that's ok to report.
> If the choice is persisted in the workspace that seems too dangerous,
> one accidental answer and Eclipse becomes leaky.
Accidental answers can happen regardless of which approach we use. Obviously, we would need a preference system for changing the preference after the initial prompt.
> Persisting only until the next Eclipse restart seems like a good idea.
That seems highly unworkable. I don't know of any user who would tolerate constant prompting like that.
Thanks,
- Konstantin
-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: Wednesday, July 22, 2015 9:28 PM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Error reporter and third-party code
Hi
IMHO, the 20% who explicitly enabled message anonymization will also enable method anonymization because they are avoiding the problem of needing corporate approval of any release of data. A method name such as
SHA4096 may reveal what algorithm is being exploited/developed. Too risky if you are not sure.
> 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.
'instance of Eclipse' is ambiguous.
If the choice is persisted in the workspace that seems too dangerous, one accidental answer and Eclipse becomes leaky.
Persisting only until the next Eclipse restart seems like a good idea.
Regards
Ed Willink
On 22/07/2015 22:39, Marcel Bruch wrote:
>> My proposal:…
>
> Sounds okay to me. I wonder if the short cut „not to enable 3rd party class names in stack traces by default“ would be acceptable as well since it’s right on the configure dialog and easy to grasp (IMHO).
>
> Wayne,
> any thoughts on this? I can change the defaults (for SR1) if the EF would agree.
>
> FWIW, during the milestone build (until June 20th) 20% of the users explicitly enabled „message anonymization“ because they feared that the message may contains sensitive data. I’d expect that users are less concerned about method names. I’d need to validate this number with the current reporter base to give a more reliable statement, though.
>
>>
>>> 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.
>
> I did a quick search for earlier discussions on this topic and found [1] from August 2014. I don’t have the impression you were brushed off in that discussion - but nevertheless: If I did (there or somewhere else) I apologize for that.
>
> Best,
> Marcel
>
> [1] https://dev.eclipse.org/mhonarc/lists/epp-dev/msg03193.html
>
>>
>> Thanks,
>>
>> - Konstantin
>>
>>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6081 / Virus Database: 4392/10286 - Release Date:
> 07/22/15
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
