This data as json
| day | description | everyone | facilitators | facilitators_twitter | id | length | notepad | room | time | timeblock | title | transcription |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Friday | So, your code broke the internet, but nobody's noticed yet. Not long ago the NPRViz team got a report from one of their users about a pretty serious security flaw in Pym.js, and so suddenly found themselves with the challenge of figuring out how to notify Pym users they needed to upgrade immediately without just blasting out to the world that it was possible to steal their users session data & cookies. I (and others) ended up helping them walk through the security disclosure process, helped draft messages intended to encourage users to upgrade, and poked people in the community. There are individual things that folks who produce software for others can do to make this process easier for themselves & users, but also there are things that we should be doing as users to make sure we're prepared to upgrade when flaws are announced, and also, how to lend a hand when things are going wrong. Lets talk about what _more_ we can and should be doing. | Ted Han, Mike Tigas | knowtheory, mtigas | security-prep | 75 minutes | y | Thomas Swain | 10-11:15am | friday-am-1 | Preparing for security vulnerabilities if you're an open source maintainer *or* user | y |