Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UPDATE/SPLIT E.4. into Unintended use and Aversarial use #82

Open
Cedric-Garcia opened this issue Nov 7, 2018 · 0 comments
Open

UPDATE/SPLIT E.4. into Unintended use and Aversarial use #82

Cedric-Garcia opened this issue Nov 7, 2018 · 0 comments

Comments

@Cedric-Garcia
Copy link

Overview

I suggest splitting E.4. into two components. It seems to me that the unintended use element combines two related but distinct concepts. As a result, the users of the checklist may interpret it as one and miss the other, instead of considering both. I tried to define the two below, and give some hypothetical examples to make the distinction clearer, and at the bottom put some suggested changes.

  • Aversarial use: People with nefarious intent tricking the algorithm into malfunctioning.
  • Unintended use: People using the algorithm in a different context, with negative consequences.

The Tay Chatbot example seems to be an example of adversarial use to me, while the Deepfakes example is more of an unintended use according to the above definitions.

Hypothetical Examples

A company (say Tesla) develops an algorithm for a semi-autonomous vehicle, which is designed to be used on the highway, with users maintaining their hands on the wheel.

  • Adverserial use: An individual paints confusing patterns on the road tricking the algorithm into making a bad turn and causing an accident.
  • Unintended use: A user uses the self-driving mode without keeping their hands on the wheel, and gets into an accident.

A company develops a 'resume review' algorithm designed to rank application resumes for programmers wanting to apply to the firm, in order to focus HR resources on top candidates.

  • Adverserial use An applicant gets a copy of the algorithm and identifies a way to trick it by using cleverly placed keywords to ensure his resume is ranked near the top of the pile.
  • Unintended use The HR department in the company finds the algorithm successful, and uses it to screen for other positions than the one it was trained on.

Suggested changes

Here would be the suggested modification (happy to setup a pull request after we have discussion here)

E.4. Unintended Use: Have we taken steps to prevent end-users from using our model in unintended ways and do we have a plan to monitor these once the model is deployed?

E.5. Adverserial use Have we explored which actions third parties could take to cause our algorithm to malfunction, and have we taken steps to limit this possibility and/or the consequences of such actions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant