Re: [tor-bugs] #7075 [EFF-HTTPS Everywhere]: Automated reporting of buggy rulesets?

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#7075: Automated reporting of buggy rulesets?
-------------------------------------------------------+--------------------
 Reporter:  cypherpunks                                |          Owner:  pde             
     Type:  enhancement                                |         Status:  new             
 Priority:  major                                      |      Milestone:  HTTPS-E 4 stable
Component:  EFF-HTTPS Everywhere                       |        Version:                  
 Keywords:  Suggestion, feedback, comment, Bug Report  |         Parent:                  
   Points:                                             |   Actualpoints:                  
-------------------------------------------------------+--------------------

Comment(by zyan):

 I've started working on this at https://github.com/diracdeltas/https-
 everywhere/tree/autoreport, and so far I have a window that pops up with
 the XML file for the disabled ruleset when the user disables the ruleset
 and has enabled report_disabled_rules_specific (see below) in the
 preferences. Eventually this gets replaced by a window asking whether they
 would like to report the ruleset as buggy. My thoughts on the design going
 forward from here are:

 '''Reporting options: '''

  1. report_disabled_rules_always: Always report when the user disables a
 ruleset.
  1. report_disabled_rules_never: Never report when the user disables a
 ruleset.
  1. report_disabled_rules_specific: Check on a ruleset-by-ruleset basis
 whether the user wants to report it.

 where 3 is the default.

 '''Reporting method:Â'''

 I'd like to get thoughts on this. Based on what Peter wrote, I think we
 could use the anonymisation procedure from SSL Observatory and safely
 write the following to a database table when the user chooses to report a
 buggy ruleset:

  1. xml name of the buggy ruleset
  1. version of HTTPS-E in use
  1. browser version
  1. [optional] a problem description written by the user (include a prompt
 with a text box when they disable a ruleset and have auto-reporting
 enabled)

 And then we could have scripts that aggregate and process the data from
 the table before converting it into Trac tickets. The pipeline might look
 something like:

  1. download data from table in csv form
  1. run script to aggregate reports based on ruleset and assign
 severity/priority based on number of reports for a given ruleset
  1. a carbon-based life form reviews the processed reports, throws out
 ones that aren't actual bugs, modifies fields if needed
  1. run
 http://trac.edgewall.org/attachment/wiki/TracSynchronize/csv2trac.2.py to
 create trac tickets from the modified csv
  1. batch upload the newly-created tickets to trac

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7075#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs