Guest User

Untitled

a guest
Oct 17th, 2017
104
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 12.36 KB | None | 0 0
  1. These notes may have errors and omissions. I couldn't get the names of a lot of the speakers and there are some places where I was thinking or distracted.
  2. I make no claims as to the completeness of this information
  3.  
  4. * Algorithmic transparency legislation hearing 10/16/17
  5. James Vaca, Chair of NYCC committee on technology
  6. ** 16-96 2017 Measures of transparency when NYC uses algorithms to impose penalties, police persons
  7. - Requires publication of source code and querying systems with sample data
  8. **
  9. - If left unchecked, algorithms can have negative repercussions
  10. - Algorithms are a way of encoding assumptions
  11. - the very data behind them can be biased
  12. - Despite importance to governamce and their problems, they tend to be hidden from public view
  13. - Unclear what assumptions they are based upon and what
  14. - Hence, a lack of transparency
  15. - What is considered to be most efficient?
  16. - More dificult for members of the city council to advocate for their citizens if variables are tied up in algorithms
  17. - When there appears to be inequities or shortages in services, we should find out why
  18. - Vaca seems to be worked up that his district does not have as much police manpower as other districts
  19. - The ability to make government accountable is obscured by algorithms and democracy is undermined
  20. - To ensure that city agencies, when utilizing cutting-edge tools, are accountable
  21. - First city, first legislative body to undertake the issue in the US
  22. ** Sunderland -- City enterprise software IT, joined by Craig Kamble mayor's office of data & anaytics
  23. - City services heavily rely on computer programs
  24. - Notify NYC app: in-source team
  25. - Several positions that the city may not hire on their own
  26. - Not making policy, making apps.
  27. - 16-96 presents significant operational concerns
  28. *** security concerns and problems
  29. - Roadmap for bad actors to exploit and abuse
  30. - meaningful risk to divulge software
  31. - Scope is all-encompassing, intentionally targets all programs
  32. - Releasing proprietary code, releasing old source code
  33. - Testing is not possible (?)
  34. - IT departments would have to create a new body of software
  35. *** Unintended consequences
  36. - Deliver a deluge of information, most of it unrelated to most interesting city services
  37. - Users could fabricate data to get the responses they want
  38. - Code is a small part of decision-making
  39. - Algorithms supplement, rather than supersede decision making progress
  40. *** Mayor's office
  41. - Open data includes 3 recent projects. Reviewing a backlog
  42. - Motivation to create project library closely aligned with legislation
  43. - Mayor's office vision aligns somewhat
  44. - Much legislation about transparency, but decisions are cloaked in opaque algorithms
  45. - MODA works on specific focus areas: agency projects on priority of the mayor, or legislative mandate
  46. - MODA's goal is to not own any analytics projects long-term, but for specific projects
  47. *** Questions
  48. - RAND formula: always opaque, always used, public does not have a right to know
  49. - Don't know if it's update in 20 years
  50. - No comprehensive list of data analytics teams in NYC
  51. - Why doesn't the mayor know about who's using data and analytics
  52. - Is there no oversight over which agencies employ advanced data analytics
  53. - At what level is there an understanding of other agencies' use of data and analytics
  54. - Never been approached with an agency seeking to implement more transparency
  55. - Open source: thoroughly vetted
  56. - Most city systems would divulge system architechture details
  57. - We don't believe in transparency because we're not doing anything
  58. - It was a new topic for the Enterprise IT (transparency)
  59. - HRA employs algorithms to detect benefits fraud, no level of human review
  60. - Human rights commission: studying decision-making (not algorithms)
  61. - EIT personally does not know about information rendered without human input
  62. - How does someone get an apartment in public housing? Strictly by computer, with one appeal
  63. - What are the bases of those decisions?
  64. - Feedback loops:
  65. - Officers stationed in places which have lots of nuisnace calls/arrests which generate nuisance arrests
  66. - Agencies are not watching their own algorithms
  67. - Open to creation of commission-based body to oversee the use of algorithms?
  68. *** My own notes
  69. - EIT architect seems to be work-shy or worried about mass-reimplimentation of software, renegotiation of contracts
  70. - Mayor's office analyst seems young & that his boss probably told him what to say, idk
  71. - If NYC funds are paying for NYC software, well, why isn't that open source/transparent?
  72. ** Witnesses in testimony
  73. *** (name unknown)
  74. - legislation reinforces the core of a responsible, equitable government
  75. - worried about tech companies entering the public spheres
  76. - we are outsourcing our government to the unknown
  77. *** Sheena richardson NYCLU
  78. - CLU stuff. Much in favor, full testimony submitted
  79. - (had to answer a couple texts, incomplete notes)
  80. *** Research fellow at Cornell tech
  81. - multi-year NSF funding in decision making in algorithmic systems
  82. - bold proposal, exciting
  83. - does not reach critical threshold in research
  84. - privacy implications
  85. - no guarantees of accuracy or fitness of use
  86. - any proprietary claims no matter how broad, will fall short of the law
  87. - black box: administratively burdensome, testing usually takes thousands of queries
  88. *** Rachel -- Brennan center for justice
  89. - restoring proper flow of information from government to people
  90. - filed FOIA to NYPD over predictive policing technologies
  91. - NYPD expected to spend 45 million on predictive policing software over 5 years
  92. - 0 records returnd from FOIA, followed suit
  93. - no disclosure of source code
  94. - had a hearing in August, and now is before a judge
  95. - lawsuit filed in July, suit in December, hearing in January
  96. - striking, the number of exemptions that were brought
  97. - the NYPD strategy was to wait for a lawsuit to force documents
  98. *** Alex Kroff
  99. - no certifications required to create algorithms for city government, but cosmetology licenses required. Seems backwards.
  100. *** Bronx defenders
  101. - want to bring to attention of the public a specific algorithm and to make sure that hey are just and fair:
  102. - NYC developing with private contractor to predict defendent's likelihood in appearing in court
  103. - would be deployed in bail hearing
  104. - would increase pre-trial detention in NYC
  105. - can't predict, but attempts to do so would run aground of bail reform
  106. - concerned about racial justice aspects of algorithms, exacerbate existing racial disparities
  107. - one reccommendations: transparency & accountability are good first steps
  108. - before city algorithms are applied (in courts) the city would be required to perform equity assessments
  109. *** Brooklyn defenders
  110. - bail reform & algorithmic transparency, ore algorithms, more policing, more CRJ
  111. - multinational surety companies have popped up to take advantage of overpolicing
  112. - RAI's: discriminatory masures like priors, homelessness, education, etc.
  113. - investigation found accuracy only slightly more accurate than a coin flip
  114. - RAI's bypass an individual's right to due process
  115. - underlying data is not transparent, even though engineers say that they are
  116. *** Security concerns
  117. - constitutional protections vs security risks: const. protections must take precedence
  118. - "post-equifax world"
  119. - people are not consenting to their data being used for overpolicing
  120. *** Robert Wallace - Research scientist - div of epidemiology
  121. - algorithms for model systems
  122. - Rand models that nobody can see & damage data
  123. - response time is a good index for ambulance
  124. - for a fire you 'have to build a hospital around apatient'
  125. - empirical damage measures must be used to determine fire policy
  126. - you will target tenements for reduction of fire services in high fire neighborhoods
  127. - models of rand's quality, you wouldn't use for fish! But they are for humans
  128. - rand hasn't changed since 1970's
  129. - cuts to city services based on models with questionable validity
  130. - e.g. city island
  131. - with global warming, more hurricanes, still using ancient models
  132. *** Selene - Policy director for Tech NYC
  133. - nonprofit trade group, increased engagement from tech companies in politics (??)
  134. - we believe in transparency, treating residents fairly
  135. - imposing protocols to publish sensitive source code is bad
  136. - chilling effect on companies publishing code online
  137. - protecting confidential data
  138. - (basically against legislation -- so why are you "for transparency" again?)
  139. *** Josh - Staff attorney for Decarceration, legal aid society
  140. - brunt of new algorithms have been shoulderd by constituents in
  141. - may result in wrongful convictions
  142. - hidden from public view
  143. - 6 areas where algorithms are used in criminal justice
  144. - bail, predicitve policing, DNA, family court, parole proceedings, sex offender registration
  145. - 2 algorithms in bail
  146. - 17 million dollar prgram with 3000 spots, determined by algorithm
  147. *** Julie - DNA unit of egal aid society
  148. - dna evidence & challenges dna certification software in the courtroom
  149. - fst: probabilitic gene interpreting algorithm
  150. - no idea how fst calculations are formed, no way to verify soundness of conclusions
  151. - people went to prison, lost their child from fst
  152. - fst's source code contained an error
  153. - hope is that the entire source code
  154. - strmix - 2 verified errors
  155. - different algorithms will get different answers in the same case
  156. - only way to verify that questionable forensic software is not used is to go open source
  157. *** Center for information technology policy
  158. - NSF funded research institute
  159. - bill requires significant changes
  160. - algo transparency cannot be achieved without data transparency
  161. - results must be interpretable
  162. - making source code available is a good 1st step, but must be readable and complete
  163. - The same algorithm may exhibit two different results with two different training sets
  164. - Scoring methods for schools and students are different
  165. - propose following interpretation of transparency:
  166. - agents must make available details of data collection, summaries of statistical collections of the data
  167. - privacy-preserving synthetic data
  168. - 1st mention of EU legislation
  169. *** Charlie Moffett - NYU graduate student
  170. - conducted research on behalf of data officers in SF, but also countrywide
  171. - most research echo what has already been said here today
  172. - extra recommendations to that committee:
  173. - regarding publishing source code, often most folks won't understand it
  174. - understanding outcomes, not just the process
  175. - algorithms must be clear about confidence and data quality
  176. - addressing explainability
  177. - question the use of an algorithm at all, if they can't be explained to the public
  178. - burden should fall on the vendor
  179. - reactive auditing: not good
  180. - leveraging this position when contracting with vendors
  181. - plan in place for when algorithms go wrong or if mistakes go wrong, what is the redress?
  182. - transparency must be understandable, and should be inclusive
  183. *** William Banfield - Tech Worker
  184. - value of open source
  185. - 2013 company had incorrect implementation of RAFT protocol. Users downloaded, provided fixes, publicly
  186. - private company's software could have resulted in data loss
  187. - regarding security: not a practical way to enforce it
  188. - openSSL is a public project, is the standard of TLS, government
  189. - keeping things a secret to improve security is silly.
  190. *** Sumana - Tech Worker / Recurse Alum
  191. - Speaking as consultant programmer, citizen
  192. - 1: tech NYC does not speak for me
  193. - open source and transparency are the way to better security
  194. - if there are businesses that make money from citizens data, we need to hold them accountable
  195. - phrasings of analytics, data, etc require more scrutiny in the context in the law
  196. - trade secrets, proprietary code: must fix procurement process.
  197. - code you write with taxpayer money should be made public
  198. - food report cards: easily understandable
  199. - if they want to understand deeper, resources are available
  200. *** Bert - Google, speaking as a citizen
  201. - objections raised are about existing programs
  202. - not as many concerns about security models or engineers rehashing old code
  203. - new development can be held to a high standard of transparency by default
  204. - centralizing of information and review
  205. - people of new york should be able to obtain a list of all programs that police persons, penalize, etc
  206. *** Alex Rich - Data scientist at NYU
  207. - on bail decisions:
  208. - open source can be quite understandable
  209. - new systems can allow people to understand how decisions are made for people
  210. *** Other thoughts
  211. - appeal is based on pleading, but you don't have that kind of information
  212. - people need to know what government decisions are made and on what basis
  213. - introducing the need for transparency ends up exposing tons of problems, inefficiencies and problems, as a side-efect
Add Comment
Please, Sign In to add comment