Maintaining a list of the preference keys that might contain more and
less sensitive information is more than I'm willing to do, I'm afraid.
Status quo sounds best.
Unless you think I should remove the names of the collections.
Robby
On Tue, Sep 27, 2011 at 10:31 PM, Neil Van Dyke <neil at neilvandyke.org> wrote:
> Right now, there are two big text fields: "Description", and "Steps to
> Reproduce".
>> How about changing it to be 2-3 big text fields, but one of them defaults to
> having all this synthesized info in it in plain-text form, and then the user
> is free to edit it, or even expected to?
>> This removes more GUI than it adds.
>> Perhaps 3 fields, with the new one being "Additional Information", and
> something like the format below.
>> If someone wants to do this, I will write the procedure to sort out the
> preferences and generate this text.
>> INTERACTION HISTORY:
> (display "Hello, world!")
> (+ 1 2 3)
>> POSSIBLY MORE-SENSITIVE PREFERENCES:
> ...
>> COLLECTIONS:
> ...
>> LINKS:
> ...
>> OTHER PREFERENCES:
> ...
>> HUMAN LANGUAGE: english
>> VERSION: 5.1.3.10--2011-09-24(09b0a46/a)
>> ENVIRONMENT: unix "Linux matthias 2.999-686 #1 SMP Fri Sep 2 20:66:05 UTC
> 2025 i686 GNU/Linux" (i386-linux/3m) (get-display-depth) = 32
>> MEMORY USE: 94206368
>>> Neil Van Dyke wrote at 09/27/2011 11:09 PM:
>>>> The prefs seem potentially more sensitive than the info traditionally
>> hidden behind "Show Synthesized Info".
>>>> I'd like to see the "Show Synthesized Info" button go away, if you're
>> going to include sensitive prefs in the info. Either the information should
>> be exposed while user is writing bug description, or there should be a
>> confirmation step after submitting, that pops up a window that presents this
>> info that will be added to the bug report and gives them a chance to edit or
>> opt-out of it. An advantage of exposing during writing bug description is
>> that the user then knows what info is provided automatically, so they don't
>> waste time on it. Implementing the confirmation dialog seems easiest right
>> now, because you can mostly just take the code for "Show Synthesized Info",
>> and you don't have a UI design&implementation problem for how to expose the
>> info while writing description.
>>>> I'm not only being a privacy hippie here. I know of Racket projects in
>> which the collects info alone (which Dr* has long included in bug reports)
>> could threaten business opportunities of the owner of the code, would raise
>> concerns about security that people would then be obligated to examine, and
>> could also constitute the bug submitter violating an NDA or other
>> restrictions on how they handle certain info.
>>>> Robby Findler wrote at 09/27/2011 10:37 PM:
>>>>>> Would you think it unwise if it was another field behind the
>>> "synthesized info" button? (Perhaps with some other name, but in
>>> roughly the same manner.)
>>> --
>http://www.neilvandyke.org/>