2015/Privacy by Design
From SIPB Cluedumps
(Difference between revisions)
(Created page with "{{Cluedump |title=Privacy by Design, or, How Not to Screw Over Your Users |date=2015-12-8 24:00 |presenters=Lenny Foner |location=5-134 |abstract=Research, startup, or just exper...") |
|||
| Line 4: | Line 4: | ||
|presenters=Lenny Foner | |presenters=Lenny Foner | ||
|location=5-134 | |location=5-134 | ||
| + | |notes=[http://bella.media.mit.edu/people/foner/Cluedump/ Slides from the talk] | ||
|abstract=Research, startup, or just experimenting---if you're building systems that people use, you're setting them up for being victimized by all kinds of bad actors unless you take steps to prevent it, and your users' misfortunes can quickly become your own. Protecting them often makes your own job as a developer easier, but many projects start with the wrong mindset and never recover. What questions should you be asking yourself? How do you even frame the problem? How do you do the right things without having to become an expert? And how do you convince others on your team to do likewise? | |abstract=Research, startup, or just experimenting---if you're building systems that people use, you're setting them up for being victimized by all kinds of bad actors unless you take steps to prevent it, and your users' misfortunes can quickly become your own. Protecting them often makes your own job as a developer easier, but many projects start with the wrong mindset and never recover. What questions should you be asking yourself? How do you even frame the problem? How do you do the right things without having to become an expert? And how do you convince others on your team to do likewise? | ||
}} | }} | ||
Latest revision as of 16:00, 24 March 2016
[edit] Privacy by Design, or, How Not to Screw Over Your Users
| Date: December 8, 2015, at 7:00 PM |
| Presenters: Lenny Foner |
| Location: 5-134 |
| Notes: Slides from the talk |
| Abstract: Research, startup, or just experimenting---if you're building systems that people use, you're setting them up for being victimized by all kinds of bad actors unless you take steps to prevent it, and your users' misfortunes can quickly become your own. Protecting them often makes your own job as a developer easier, but many projects start with the wrong mindset and never recover. What questions should you be asking yourself? How do you even frame the problem? How do you do the right things without having to become an expert? And how do you convince others on your team to do likewise? |
