 I feel a bit strange welcoming you to somebody else's office, but welcome to an event that we've called the Extensible Web Summit Boston. My name is Dan Applequist. I am co-chair of a group called, along with Tim here, of a group called the TAG Technical Architecture Group, which is part of the W3C, the main standards body that produces things like HTML5, which you may have heard of, and the work that we do tends to be focused around the technical steering of work within W3C, within web standards, that kind of thing. We've just been meeting this week. We tend to have one meeting a quarter in different places in the world. For some reason, we tend to meet a lot in Cambridge, Massachusetts at MIT, I wonder why. And whenever we do a meeting, we tend to try and do these days, anyway, we try and do some developer outreach and do some work to connect the work of standards and the work not just of W3C but of merging web technologies with the work of web developers, the work of people that are actually working with the platform, both as a way to kind of demystify what goes on in standards. We've had a lot of feedback over the years that people don't really understand how standards work, and they sort of see standards as a very opaque kind of topic that they don't know how to engage in, so that's part of the thing here. But also, it's about getting input and specifically input into our work so that we can work that input into the next phase of our work or our ongoing work program of work, basically, both in the TAG and in web standards community in general. So what we've been doing is sometimes we do evening events, sometimes we do larger things. One day events, our last one that we did was out in Tokyo and we did a kind of evening event, which was very similar in format to this, where we had breakouts, so we're kind of playing around with the format, we appreciate feedback, but part of the point of this is to hear from us and to hear from your colleagues, but also is to kind of work together and I'll be explaining the format in a second. Just to talk a little bit about the work of the TAG, I said we've been working here over the past three days, so what does the TAG do? The TAG does reviews other people's work, so it reviews the work of other working groups that are working on other emerging standards, so we reviewed, what did we review? First of all, who from the TAG is here today? We can kind of put their hands up, okay, so we have Tim, Andrew, we have Alex Russell, we have Hadley Beeman, David Barron from Mozilla, Eva Fawn from W3C, I think that's it that we have in the room right now, and you'll get a chance to meet and talk to everybody who's in the TAG in a second, but one of the things that we worked on this week, for instance, is we developed a document which actually Andrew Betts wrote or edited, which is a document about polyfills, and it's really considerations about polyfills, where they fit into the platform, trying to draw a definition of polyfill that goes beyond kind of the agreed kind of community definition of what a web polyfill is, and we think that's important because it helps to set a stake in the ground about what polyfills are, why they're important, how people should build them, what people shouldn't do, so some best practices as well. And I think Andrew agreed that he would like to lead one of our breakout sessions on that topic. Another historical finding that we made two years ago was, and the work of the TAG is kind of, we do reviews of other people's work, and we also do, we publish documents which we usually call findings. So a finding that we published two years ago was something called Securing the Web, and it's one of the documents which helped, I think, to, well, which joined a chorus of voices around the world really, around pushing the web to implement HTTPS, and pushing websites to try and implement HTTPS, but also trying to push that the web itself becomes more secure and more encrypted at its root, that the idea being that in the future, going to an unencrypted web page will be out of the ordinary rather than the ordinary thing. And I think just recently, by some stats that were published, we've seen that over 50% of web traffic is now encrypted. We've seen major websites, web properties moving to HTTPS, such as New York Times, most notably recently, and other major news sources around the world moving to HTTPS. So we're really glad to see that that happened, and of course, that was kicked off by the whole Snowden revelations, and which then led into a workshop, which then led into some work that we did, which then led into a whole bunch of other things that happened in other groups that we had some influence over, but we were just part of the story, but I think we played an important part. Anyway, so, and if you're interested in more reading more of the stuff that the tag is produced, you can visit our page at tag.w3.org, which is kind of our working page, which has all of the published findings as well as who's in the tag and, you know, work mode. It's all of our work happens in GitHub these days. So if you're interested in getting involved in our work, raising an issue, asking us a question, all that kind of stuff is in the clear and in public in GitHub, and it's all linked from tag.w3.org. So before I hand over to the Boku people to organize to intro kind of the lightning speakers that we have, I just want to explain the format of today. And this is kind of a format, again, that we've worked out over the course of a couple of years now. It's kind of a hybrid, unconference slash meetup format where we start off with a series of lightning talks. And the idea of the lightning talks is to set the stage, introduce some interesting topics, get people thinking about new stuff, maybe things that they haven't thought of before. So we're going to have that first. And then once we have, once we end the lightning talks, we're going to do agenda setting. And that happens in unconference kind of open spaces format, which I kind of always assume that people have done. But if anybody hasn't done an unconference, the idea is you go up to the board and we have a nine box grid up there for our three session slots, our long slots, three to four, four to five, and five to six, and three spaces, one, two, three spaces here. So this will be space one up here, space two in the middle, and space three at the back. And the idea is that you produce the topics. Now, I know that there are some people who want, who have some specific ideas about topics, so they're going to jump up and add a topic, but you're welcome to jump up and add a topic as well. And it's kind of a bit sometimes called the mad scramble, right? Then, but if you if you suggest a topic, then please be prepared to lead that session, lead that discussion. Don't just suggest a topic and say, yeah, but I'm not you know, I'm not interested. I can't lead it, right? So be prepared to lead that session. And that means leading the discussion in a productive way. Don't suggest a topic like my cool product, and then expect to have an hour long pitch for your product either. That's not how this works. All right. And be prepared to lead a discussion in a productive way, where you where you get people's input, and, you know, hopefully come to some consensus ideas. You'll be, I'm also well, I want to say that it's required, but it would be great if you could take notes. And we have a and that means designating a scribe for each session. And we have a etherpad set up at pad.w3ctag.org, a slash p slash, and then something. And I have a I have a start page for that set up at p dot or sorry pad.w3ctag.org slash p slash EWS underscore Boston. And from there, people can add additional pages and link those to that page. And then then we end up with a kind of record of what was said at the event. You don't have to take exhaustive minutes. The idea isn't that that and, you know, if you don't people, the minutes need to be, you know, should be more indicative of what was talked about during the session. But that the reason for that is because then we can refer back to that actually in the tag. And we often have done that. We said, Well, what was discussed at that breakout session on WebRTC? Oh, yeah, okay, let's go back to our notes about that. Oh, yeah, that this really interesting topic came up. We should think about that. We should work that into our into our ongoing work. So that's part of the idea here. And also it helps you you can refer back to those notes you can, you know, you can et cetera. So that's basically it. And then we're going to break and we're going to pizza. And that's going to be the nice part. Okay. So other than that, I don't think I have other things to address. So I think I'm just going to hand it over to Boku. My name is Joy Berson. I'm the CEO of Boku. It's my sincere pleasure to welcome everybody here. I want to introduce a couple members of our team. In case you need anything while you're here throughout the day, Laura Powell is our operations person and Matt Serravino director of Web applications. So if at any point you need something ask one of three of us who will be more than delighted to help you find it housekeeping wise, the bathrooms are down the hall. Please feel free to go anytime. I'll tell you just briefly about Boku. We're an open source technology consulting company. We work with companies to modernize Web applications and work in an open and collaborative fashion. So obviously standards is a big part of that. So we're thrilled to host today. And on that note, I'm going to introduce our first lightning speaker. My friend David, I'm sorry, Brian Cardell from the W3C is a co-author of the extensible web manifesto. And going to tell us about chapters. Do we have a screen here or no? Everybody put this screen here. We'll wing it. Can you hear me back there? Yeah, good. Okay, so I'm going to talk to you about chapters, which is something that I'm really dreaming of and is being kind of championed by the JS Foundation. And people in W3C have been warmly receptive to it. So here's what it's about. Imagine that you're just a regular web developer, and you experience a problem. Like, you know how to use the technology, but when you use it, it's wonky. Like, it's too hard to use. There's weird gaps. And you think, well, maybe it's just me. Like, so you talk to your friends about it, and they say, I know exactly what you mean. Yeah, I have the exact same problem. And they talk to their friends, and they talk to their friends, and everybody you talk to has the same problem. So what do you do about it? So the good news is anyone can be involved in web standards, at least in theory, but most people don't know that. Like, a lot of web developers don't know that. So if you wanted to, in the past, what you would do is you would join a mailing list. Probably many of them. And oh my God, so many things. You don't realize how many people are competing for how much attention about how many things and how deep some of those conversations go. And it's intimidating to throw yourself into that arena. A lot of people don't. So a lot of people don't even get that far. Then next, if you stick with it long enough, and you establish that, you know, you have some bona fides here, then you can maybe level up and be an invited expert. And then you can participate in all the meetings and go to face to face meetings and everything. But the costs are on you. And it's not always cheap. You'll give up vacation, sleep, things like that. And it's a long term commitment. A quick standard is five years. A lot of standards are 10 years before we get them everywhere. And at some point, a lot of developers think, Hey, why am I doing this again? Because like, didn't I get involved because I have a problem. And here I am six years later, and I still have the problem. Like, I could have saved myself if I had this solution, I could save myself, you know, three days on every project. But I'm 30 days worth of thing here and six months worth of involvement on standards. So in 2011, Adios Monty wrote this on the jQuery blog. He said, The reality is that whilst most of us would like to see change, due to time restrictions, like the formal processes, we're unable to actually participate in standards. This makes it difficult for web developers to have a voice. So what he was announcing there was the formation of the jQuery foundation standards group. It's now the JS Foundation. And the goal there is to give developers a voice that you couldn't otherwise have by taking the voices that we hear and carrying them into web standards, and taking the web standards that we hear developing and carry them back to developers. So the problem with being involved personally, what Adios saying is that the economics are broken, like it sounds good in theory that we could just get like jump in and everybody could get involved. But that doesn't it's not practical. And I would posit that adding thousands or millions of people and voices into this model would be a mess anyway. Like if you think there's a lot of people talking a lot of people competing for limited attention. Now, it would be much worse if we put 5 million people on a mailing list. This is another model for standards. It's a dictionary. If you can't see that this is Miriam Webster words we're watching. So this is not in the dictionary yet, but they're thinking about putting in a dictionary. It's one of the things that they're watching that they see that's out there. It would be ideal if we had some of this for making web standards, right? If there were some way to take the pulse and watch, if only there was some way to get developers to talk about web standards and find the words to watch for and and have this kind of channeling. Dude, they're totally is right. This is meetup.com. It's not the only way people organize. They have 5.6 million web developers that participate in 11 and a half thousand web meetups around the world. So what if we could plug into that and use that as a conduit back and forth between developers? So that's the idea. Chapters is taking existing web meetups and pairing them with standards people, giving them a goal of creating this channel where they can work together and then championing all of those voices back into web standards with real data. So that's it in a nutshell. I don't know. It seems good to me. It seems pretty simple. It's not intimidating. It's effectively free by comparison with the other model. Competition for attention and priorities a lot better because here you'll see we won't talk about everything in CSS and everything in HTML and everything and we'll pick some things that the people in this room want to talk about and we'll talk about them in a really deep way. And then just like Dan said, we'll take the stuff that the tiny bit of feedback that needs to go back can go back and can make us have the thoughts we need to have. So the noise is localized and valuable information is carried. So instead of calling and getting put on hold, you call and you say, perhaps I can be of some assistance, right? And we can frequently give those people actual things, polyfills, transpilers, preprocessors that roughly approximate what they're trying to do. And instead of saying, why have I been doing this for five years, they know why they've been doing it because they get value out of it. So we help each other. So that's what chapters is. And that's what I would like you to do join the rebellion. So talk about chapters if you find it interesting, because that's how word spreads. If you're interested in starting one, you can file an issue here, and we'll try to pair you up with a local meetup and a standards person. And if all else fails, if maybe there's just like my crazy dream, and you're never going to get one, it's just possible. The Pittsburgh chapters loves you and you're more than welcome to join us remotely, because we do this already. So you're welcome to participate as much as you can from here. That's all I have. Thank you very much, Brian. Our next speaker is going to be Matt Markey. He is the chair of the Responsive Images Community Group at the W3C. He's also a partner. Also, he built the lectern. He's very proud of it. Recent author of JavaScript for web designers, Matt. Any circumstances lead with the lectern thing, I keep saying and nobody ever listens. I don't know who that was, but you get a bonus RICG sticker from the back of the room. What are the odds this will work first try? Yeah, it's a little squished, but use your imagination. So I am, I am an employee of Boku, first and foremost. And that will be relevant toward the end of this, I promise. From a web standards perspective, and this is not rehearsed or scripted or anything, so bear with me. I am the illustrious chair of the Responsive Issues Community Group. I don't know because I haven't checked in a while, but we were toward the beginning of the effort. The we were the largest of the community groups. We were one of the first. We sort of paved the way for groups to come for better or worse. And that when it first kicked off was a group of concerned developers in an ether path, just kind of hashing out ideas for a syntax that would mean a more responsible way of delivering image assets to users of varying contexts, various screen sizes, viewport sizes, resolutions, which is becoming more and more relevant a few years ago. Now we've sort of plateaued where every screen is monstrous and super high resolution. But we were presented with a venue for, for us, the nebulous us to provide feedback to the nebulous them. There was web standards, and there was we the developers. At the outside, it was not, it wasn't explicit, but it was still implied to be something outside of our control. This is where you send an email into the ether and hope for the best. And the powers that be will hopefully dane should they find your reasoning sound to solve this problem, which I as a long term troublemaker immediately took issue with, but this is the venue. This is the system. Okay, we'll work with it as best we can. We showed up, you know, bright eyed and full of web standards hope for the future. And you know, we're excited. We're full time developers. We were super excited to get into this problem. And it was a very responsive web design oriented thing. And when this kicked off, that was a very new field that was during the Boston Globe project that I worked on with Ethan Mark, not bragging or anything. But yeah, we were like, look, we're, we're sort of like the first to the line on this. We know exactly what this problem is. We're excited to help solve this together. And we got constant pushback almost exclusively in the form of theory. Just use JavaScript, just use CSS, just use the server venues exist for you to do this, completely divorced from the reality of day to day web development. This was absent any further thought of CMS integration or environments where we as developers can't control the server of situations where we can't control how this stuff is going to be used of how images uploaded to the cloud somewhere will ultimately be rendered on the page. We got solutions in the form of ideal conditions and what worked on paper. And when we pushed back with, but that doesn't match reality, we think it needs to be messier. The default was no, no, we don't want it to be messier. This looks really nice. This is very terse and very clean. People who we contacted who worked almost exclusively in full time web standards, browser reps, etc. wanted to shape these features in terms of what would be considered theoretical purity to anyone who worked on developing websites full time. Not to them. To them, it seemed like user facing concerns, developer facing concerns, keep this terse, keep this simple, keep this very clean. But to us, this was all academic. This didn't match the reality of how people would actually work with these tools. This was not tenable. And it was leading toward unworkable impractical solutions that we eventually had to stonewall. We had to say, no, this will not work. Please stop this. This will not work on this feature. At this time, I don't mind saying, and this is where I coronally work in the title of the talk, we went full pirate radio. We started creating our own documents. We started with a use cases doc because that was basically the process we'd seen laid out by the people creating the spec that we didn't like that wouldn't work for us. We eventually drafted our own spec, which we absolutely as a community group had no right to do. We were nobody's, we were developers in a GitHub repo. Wow. It turns out sort of. But most importantly, our role was to make a lot of noise, to make ourselves the rallying point for anybody interested in taking on this topic. And based on our tech, it was developers, it was 100% developers saying, yeah, no, we have the same problem. This solution doesn't work for us either. And they all rallied under the RICG umbrella. We eventually that there we go. We eventually built picture fill, which is sort of following the spirit of the extensible web manifesto before it existed. This was a prolly fill using divs and data attributes that sort of outlined how the markup pattern we were after might work, just so we could start hashing out the spec thing based on something we could see something we could point at something with a resizable browser window to see how this stuff behaves. This eventually once these things were implemented in browsers, sorry, spoilers, became the de facto polyfill for these as well. So that's a that's an extensible web manifesto success story before that document was even written. Ultimately, because we were operating in a vacuum, because we were just developers in a silo, you know, shouting into the void saying, please, browser reps, please build this the way we've asked, we ended up raising $15,000 from a crowdfunding campaign to hire a developer full time to implement this in Blink and Webkit. Ultimately, in the end, we publish a spec and it got merged. This this became part of the HTML specification, just a document we put up using bike shed in in GitHub somewhere. These features now see nobody's keeping score, but more usage than things like input type email. This is pretty common now. This has since landed in some form in every major CMS. I don't mind saying WordPress and Drupal 8. I know for certain have it built in as part of the core WordPress alone. That's 25% of the web has seamless responsive images. No tinkering on the part of developers and the user based on the way we've set this out and I'm happy to like lecture at length on on how the spec played out. Users see nothing. Users see absolutely no difference in the images that they see on the web on at least 25% of the web. But it saves them a tremendous amount of bandwidth by design. We were very careful with the spec to say everything must always look the same. You just save a lot of bandwidth. There's no cons. There's no downsides to that. This is something the average developer doesn't even need to think about now. It would be very easy to think of this history lesson as a success story. A group of like minded developers got together and developed a new feature for the web and shipped it and it was massively successful and has done no harm to any users or devs and done tremendous benefit in terms of bandwidth usage. This is in no way reproducible. No group to follow us can do this. This was incredible straight up dumb luck. Browsers which were not interested in implementing things the way we wanted them implemented were the bottleneck. No matter how much noise we made, nobody stood up and took notice until it felt like a marketing point until it was, hey, they raised $15,000 at which point, no offense to any Googlers, Google swooped in and said, we're going to give you $1,000 toward this, which I appreciate. I hope they didn't struggle with rent that month. But like, we've been railing about this for years. No one paid attention until there was a huge dollar sign attached to it. That's not tenable. No other group of, you know, scrappy web standards rebels led by a handsome and charismatic leader could pull that off. Nothing that usually, at least a chuckle would be good. So we've since changed the name of the responsive images community group to something broader. This was right at the tail end of the responsive images thing. We decided we were the responsive issues community group because we did this once. We could do this again. We know there are things that developers want that aren't being actively worked on because they're not as flashy. They're not as practical. They're not as on the ground. These aren't things that people need for their eight hours a day making websites job because some of the people involved in designing them are, let's ship this cool VR thing. They're full-time developer browser developers. So this talk and it's brief and I'm almost done. Originally I set out to just give like a history lesson to say we were the RICG. We did some stuff. We've been real quiet since the WICG exists now. They were coming up toward the end of the RICG. It was like, all right, this isn't cool that this group has just hauled off and done this. We have to create some avenues for developers to have more feedback and a lot of that work is underway but it's been years since the conclusion of the responsive images mess. And so I come here not with a history lesson but with a warning. We originally started talking about container queries which is a method for like media queries rather than resizing and re-styling elements based on the size of the overarching viewport. It'll do it based on a parent container. We've talked to browser reps. We've gathered initial feedback. We've gathered use cases for use cases document that again we don't super have the right to publish but we will 100%. Polyfills are underway. People want this. People have wanted this since toward the tail end of responsive images when we said, all right, now we have a little bandwidth. Now this thing's on rails. What do we do next? People want this very badly. My warning is that I will 100% try to do this again. There are still tons of us in the RICG. There are still tons of engaged developers who want to have active feedback on web standards and the directions it's headed in who want this feature specifically. We broke the system. We made a path where there was none in order to get responsive images done. My warning is that unless something is done to the system to make this more tenable to give us a venue to make these things happen, we're just going to do it anyway. That's it. Thank you. He wants to turn us into a hard wood software company is this cool. So our next lightning speaker is Wendy Seltzer. Wendy leads strategy and is counseled to the W3C. She's going to be speaking about burning issues and very timely issues in web security and privacy. Does anyone, I have mini DPA, mini display port rather, NVGA. Sorry about that. Okay, well, that's going to be close enough because that was going to be close enough. All right, resource unavailable. Never seen that before. The most difficult part of the technical presentation is always getting the presentation to show up on the screen. So, I have no idea what's happening here, but I will give the Wi-Fi seems to have gone off. So, imagine that you are seeing a picture of an old file cabinet on the one hand and a server box on the other hand along with the story of the email break-in that was in the news all of last September through November. We know since that the Democratic National Commission servers were email services were hacked in part because of phishing emails sent to John Podesta, an aide to whom he forwarded the message said, this is legitimate. Go change your password. He followed the fake link in that email thinking he was changing an email password on for Gmail. Instead gave the password to the attackers who got into his systems and from there into all sorts of other systems to which he high ranking Democrat had access and web security became a matter of the cybers, the cybers everywhere. So, what can we do to solve the cybers? Well, we could try to make phishing passwords stronger. We could try to demand that everybody use not just, you know, ten characters with three special characters and two numbers in some uppercase and some lowercase. So, that makes passwords harder to brute force. You can't run a dictionary attack against them. Still doesn't solve against the phishing problem that caught them. If you can convince somebody to enter that complex password into your fake website rather than into the real site you're trying to log in as a man in the middle or as someone setting up a spoof site, you can capture that and replay it to capture the login. So, how do we make the web un-fishable? Well, we're working on the web authentication standard brought in from the Fido Alliance to the end of that phishing message, the AIDS message, despite not correctly identifying the fish, did say, and not only should he change his password, he should immediately enable two-factor authentication. Two-factor authentication brings something else to the authentication so that it's not just you remembering a password that somebody else can borrow, but you having a second factor, a chip, a USB key, a TPM in your device that is that required in order to attack your connection and isn't so easily taken by the fishers. So the web authentication standard we're working on brings this to the web as a native function that the browser will be able to help you as user agent to accomplish. You'll bring an authenticator, whether it's the USB key or a chip or a retinal scanner or fingerprint reader, something that is capable of performing cryptographic operations in exchange with the server and will authenticate you in a way that's bound to the channel of the server. So the credentials that work on your Gmail account, if an attacker gets them, won't be able to be sent over to that fishing site that tried to convince you that it was Gmail asking for a password reset. You send credentials there because they're bound to the channel. It'll get a different credential and that credential will be useless when it tries to pass it along to the Gmail server. So instead of just trying to make the password stronger, web authentication is looking at a fundamentally different way to do login transactions or authentication transactions and to make that easy to deploy everywhere you have web browsers across the web. Wanted to share some of the other things that we're doing at W3C and web security, we are essentially offering a forum for collaboration on the problems of security on the web. We don't all share the same problems, but we all have issues where we want to ensure that our communications are secure between our client and the server we're talking to. And so we have in our web application security working group various efforts to support HTTPS everywhere, to make it easier for application developers to demand a secure channel, secure contacts for their application, and then to assure that that context is enforced through content security policy so that scripts can't be injected to mess with the web application and cross-site scripting attacks can't grab information out of that connection. And so content security policy level two is a W3C recommendation. Development is already underway on CSP level three, the next generation. And we try to be responsive. We try to hear from the community of web developers. What are the features that you're trying to use? What are the ways that existing features of the policy aren't working for you? What else do you need to make these usable as web developers? Because if it's not working for developers, it's not working for the users who depend on web applications to offer them secure services. Other work, mixed content standard, helps to make it easier for applications to enforce their security by blocking mixed content that could compromise the app security. And then on the other side, we have specs like secure contexts which suggest to the developers of new features that they think hard about whether their feature should be exposed only in the context of a secure authenticated channel. As the web becomes more powerful, users should be able to expect that not just any random drive-by attacker will be able to get access to their location information or their video and audio. And if you're not using a secure HTTPS channel, you don't know that you're sending that information only to the authenticated site you meant to be visiting. So the suite of specs in Web App Sack is helping developers and browsers to cooperate in providing that security to the user. We have other work. We just brought web crypto to recommendation and providing standard JavaScript access to cryptographic functions in the browser. So you shouldn't be rolling your own hash functions and encryption and decryption. Now, cross browser, you don't need to. And I have and we'll share with you in the etherpad afterwards a set of links to some of the places that this activity is going on because while I love the pirate radio notion that Matt gave, we really do want to hear from you and we want to be tuning into all of those channels at W3C so that the web can serve all of its users and web developers are really a key means of getting that implementation and use out to serve the public. So, you know, as users our security and our privacy depends on application developers and implementers to offer us these features and to use them effectively. And so at W3C we very much want to hear and incorporate feedback. Thank you and thank you for bearing with me with the audio video problems. Awesome. So, I'm pleased to introduce Cade Crockford as our second to last speaker. Cade is the Director of the Technology for Liberty Program at the ACLU of Massachusetts. So, I feel like we should put and maybe in the live stream like a donate now, the ACLU. Really important work going on there right now. She's going to speak to us. She also blogs at Privacy Matters and she's going to speak to us about technology and social engagement. Cade? Thanks. Hey everybody. This is just for the web, huh? Or is it in this room too? Okay, great. Hi everyone, also somewhere else in cyberspace. My name is Cade Crockford. First of all, I'm grateful for the invitation. So, thank you. I'm going to talk not so much about technology actually a little bit, but also largely about politics. So first of all, I want to endorse everything that Wendy said. Please consider privacy and security, obviously, as paramount when you're developing technology. I will speak a little bit more about technology, which is to say that former CIA director Michael Hayden said infamously after the Snowden leaks, we kill people based on metadata. And that's true. The US government kills people based on metadata alone. Sometimes just using MC numbers and location tracking of those MC numbers through drone strikes. We kill people based on metadata in terms of phone records that are left behind, the digital trail that people leave behind, oftentimes unknowingly, every time we touch technology. So when you're thinking about security and privacy in terms of the applications that you're developing and standards, I would just submit to you to think about hiding metadata whenever possible, either not collecting it in the first place unless it's totally necessary, or getting rid of it as soon as possible. Because you likely know that any information you, as a corporation or an individual developer, collect about your users, is retrievable by the government. And unfortunately, law reform doesn't work as efficiently as developing code. So we have not yet reformed the law so that it protects people from warrantless demands on their information from corporations. So basically what I'm asking of you is to really only collect information you absolutely need about your users and to get rid of it as soon as you don't need it anymore because it can endanger people. So having said that, thank you for suggesting that people donate to the ACLU. People in the tech community often ask, what can we do? And I think really the most important thing you can do is give us money. I'm serious, I'm not joking. The ACLU has about 300 lawyers nationwide. The Department of Justice alone has 11,000. So you've seen probably that the ACLU raised $24 million over the weekend after the weekend when Trump signed his Muslim ban executive order. That's great. That's gonna help us hire lawyers at the National Office and in some affiliates nationwide. But that's not going to help us staff up to the levels that we need to be staffed in order to fight back against the existing and coming wave of civil liberties and civil rights violations from this administration and from every other. And I just wanna be very clear about one thing. You probably know that the ACLU is the nation's oldest civil rights and civil liberties organization. We've been around for almost a hundred years. I actually started here in Boston just like the Fourth Amendment, which was also born in Boston. I can bore you with that story later if you'd like to hear about it. But we fight in every single state across the country in legislatures as well as in Congress and in every single court system across the United States. And we do so in a way that is truly nonpartisan. Some people on the right have attacked us over the past couple of weeks because we've been hitting Trump hard and suing him all across the country including here in federal court. But the reality is that we sued the Obama administration a lot. And we don't care who you are, what flag you wave, red or blue, if you violate the Constitution, if you violate people's civil rights and civil liberties, we're gonna come after you, which is what we've done for almost a hundred years. So no matter what political party you ascribe to, you should be certain that if you work in collaboration with the ACLU, if you donate to us, we are going to fight for principles, not politics. We don't really care about politics. We care about principles. And we do that here in Massachusetts as well as at the federal level. So another way that folks can get involved is that I'm hoping that some of you will want to join a budding, nascent, not quite existing, but soon to exist, technology advisory committee to work with us at the ACLU of Massachusetts. And a lot of tech people have gotten in touch with us since the election asking, what can I do? Well, there are maybe some discrete projects that you can work on. I probably can't manage those projects because I have a full-time job fighting for freedom. But we would love, for example, for developers to create an alternative to Google Docs, like a really secure and encrypted document sharing program. That would be fantastic. That's probably the number one question I get from activists all over the country is, is there a secure alternative to Google Docs? And the answer is basically no. There are some products like Sandstorm, I believe it's called, is one, but it doesn't really work very well. It's not super easy to use. Unless you're a techie, you basically can't use it. So that's my number one ask. If you know how to develop things and you want to work on a big, expansive project that will change the way that activists and organizers across the country can share information securely, that's it. That's what I'm asking for. That's not just me. That's thousands of other people all across the country who tweet me that question all the time, email me that question all the time, and I don't have a good answer for them, unfortunately. So if you want to help, please do. And usability, I think, is really key, right? We know that because of Signal. The use of Signal has exploded over the past couple of months. Millions and millions of people all across the country and the world are now using this free, easy to use, encrypted communications technology. And the reason they're doing that is because it's free and easy to use. It's not complicated. You don't have to teach someone how to install PGP. You can't really fuck it up. It's difficult to use it in a way that compromises your security because you don't know what you're doing. So again, please think about usability when you're thinking about secure communications tools or any kind of security tools, really. The last thing I'll say is that increasingly, we are gonna need tech folks on our side in political battles. So one of the things that if you join the Technology Advisory Committee, you will be asked to do is to lobby. To lobby your state legislators, to lobby federal representatives in Congress, to lobby the governor, maybe even to lobby your local officials in city councils here in Massachusetts. Because essentially over the next four years, what's gonna happen is the ACLU and like-minded organizations and advocates are gonna obstruct at the federal level. We're gonna try to obstruct whatever we can through lawsuits in Congress, through mobilizations, mass mobilizations like we saw in the airports a couple of weeks ago, there's gonna be obstruction. But at the state and local level, we actually have a broad progressive agenda. And by progressive, I don't mean that in a political sense. I mean that in the sense that we hope to actually improve things here in Massachusetts, not just to play defense, but also to make the law better. So one of those ways is by passing something called the Electronic Privacy Act, which is a sort of state-level version of an update to the Federal Electronic Communications Privacy Act, which hasn't been updated since 1986. When I was three years old, probably some people in this room weren't even alive at that time. It's alarming because in 1986, one gigabyte of storage cost $75,000, which led to the creation of a law that said that any information stored on a server for longer than 180 days can be obtained by government agents without a warrant. So that's the current state of federal law in the United States. Hasn't been updated at the federal level. Last session, it nearly was reformed, but Jim Comey slipped in a poison pill at the very end of the session and killed it. The FBI director, who many people also blame for Trump's election. So we here in Massachusetts aim to reform the law on the state level. Another thing that that state-level reform would do is require a warrant for the use of stingrays. You guys know what stingrays are? Great. So there are little devices that allow the police to directly wiretap and track cell phones, skirting the requirement to go to phone companies. So anyway, we have a very robust legislative agenda here in Massachusetts. We're trying to push also ordinances at the local level in Cambridge and Somerville at the moment to require that police departments go through a public process before obtaining new surveillance technologies like license plate readers, stingrays, surveillance cameras and things like that. So if you are interested in using your technological skills, your background, and frankly your power as someone in the tech community to lobby at the local level and at the state level, please let me know. And thank you very much for your time. All right, our last lightning speaker today is Leo Balter. Leo is a developer here at Voku and also works on standards with the TC39 Committee and JS Foundation. Leo's gonna talk about testing and the standards work that he does. Thank you. Thank you. Thank you. Thank you. Sorry, I'm new to computers. Computers are new to me as well. Okay. Okay. Hello. Leo. I work here at Voku. I also represent the JS Foundation on TC39. And I'm glad to be here. I'm talking to Leo. And I like testing. And I'm here to talk about testing and standards. And I can also say like about testing standards. Here at Voku, we love testing. We are actively working with Test262, which holds the test for ECMO script and also the web platform tests. And like there's a short what, how and why. First part, what are we exactly testing? I have a small example here from the ECMO script. Specs, which is the math ABS. It's a bit short, but like we, this is a small API spec. And like we try to identify all the observable parts of the API and syntax as well. In this case, like we try to identify parts that we can test, like testing the arguments and conversions that are applied to this argument and like trying to get results from it. Like it returns, the result has the same magnitude as X but has a positive sign. And like it's absolute value of X is not a number. The result is not a number and et cetera. We try, we write tests for all of these parts. And like even finding a lot of observable parts of it. And it's great and it's easy to test it because we just use like open web technologies. Like for, on the example on test 262, we use pure JavaScript to write tests for JavaScript. And that's great. Same thing for the web platform tests. We use the open web and why we do this. There is a nice introduction on the web platform tests. And like it's a long text, but you can find like keywords that like really encouraged me to have this test that we have there. Like it provides confidence and compatibility and like this compatibility is extensible for other implementations as well. And this is like all present in there. And it helps us to have confidence so we can rely on the web platform. And with on the promise, like we are gonna work across browsers and devices. This is really nice. With that, we get like, it helps us having like proper specs with the confidence. We have like, we improve consistency, working across all of the browsers. We have like the best checks for web reality. Sometimes like we can just like have standards and then like we find out it doesn't reflect what we want, like if it works for the web. And also there's a lot of great community feedback. And this is nice, like on test 262, for example, we have like community members, web partitioners as I am, coming by and not only like, telling us we have a bug or anything, like people are coming in to improve the test, to write new test or to fix test that we have. And that also like, this is like a quality that is applied directly to the runtime implementations to it. And this is what we have for TC39 for ECMAS script. Like we have acceptance tests as a required criteria for standards. Proposal since ES2015 or mostly known as ES6, TC39 has this new staging process that we have also include tests, acceptance tests which are test 262 as a criteria for to have a proposal to become a standard. And this is great. And here's my small idea like we can, that can be then a proposal as well. We could ship test as a criteria in every standards process that we have for the open web. Like to be honest, I love tests. So I find this like amazing. And that's it. I wanted to make this short. And thank you very much. I'm here available to talk more about this. It's like the topic that I really love. Thank you. Okay. Well, we're running a tiny little bit late. That's okay. I've changed the timings on the board so that our official start times for each session is going to be half past the hour. So 330 to 430, 435 30s, 530 to 630. So what happens now is people come up to the board right in their session. We have discussion. I think we have a small enough group so that we don't have to have like a formal thing where people announce what sessions are going to do. But we just kind of work through for the next like 15 minutes or so what sessions we're gonna run. And then, and who's gonna again, who's gonna lead the session, who's gonna scribe the session. And then we're gonna move to having these breakout sessions. And during the sessions, we can use the wall as a kind of scratch pad space. And we can also use the ether pad that I've set up. Also, if people want to use a hashtag for today's event, they can use EWS Boston. That's what I've been tweeting on if people are so inclined. So anyway, yeah, let's go up to the board now and just decide what we're gonna talk about for the rest of the day. Sorry? We're gonna close the live stream. We're gonna close the live stream. Thank you. Everybody who's been watching and I hope you... Bye everyone. Thanks a lot. We'll put the recording up later.