Welcome to the Jenkins user experience special interest group. It's the 16th of February 2022. Thanks for being here. So topics that I see on the agenda weekly status, an issue that Daniel Beck raised about image removal and existing plugins. Then we've had good sessions with young young and Tim sharing ongoing UI improvements. Uli added prism for source code highlighting and font awesome and code coverage plugin. Yeah, would you be okay if I moved UI improvements to the end so that we've got the most time available there. Okay, and Uli, are you okay if I do it that way. That's fine. Great. Okay. Any other topics that need to go on our agenda today. Okay, then first topic 235 three, the 2.335 weekly status. As far as I understand the build is in progress. I've seen entries written to tags, written to the or not tags artifacts written to Artifactory. I haven't run the release checklist to be sure that all the parts and pieces are done. This is the one that switches the Linux installer to system D from system five in it to system D that's not a you. There's nothing per se, but it is user experience and so I'm using that as the excuse to note it here. I intend to blog about that. Because I think it's a big deal. And I've got to make an update to the changelog. Any questions on 2.335. The next topic then was there was a concern I saw from Daniel Beck in terms of the image removal the removal of icons may break some long existing plugins. I wanted to get, get input from people in the UX is there something we should do about this. How would how would we approach it, etc. Wouldn't be the easiest thing to file a bug report and fix the plug in. So, I don't see a real problem with this, because, you know, I think we need to go forward with the UI, and this means that we will break things. So, if something is not really working yet, we can provide a pull request and these pull requests are quite easy. Maybe just a different URL for the images. I think we can go on. Sorry. And I think one of the things kind of going forward is plugins or want to get their icons anyway. If they want to fit in with the new style of Jenkins icons sell probably update by themselves shouldn't be too much of an issue. It's just down to removing all the images. Just in case team your make is not the expected one, I think. Yeah, we're not hearing. Sorry, I'm not hearing you. I get some hints that you're saying something. Try that. Yes, much better. I'm just having a nightmare with my headphones. Maybe that works now. I'm just saying that he the PR he raised on something only affected like two plugins. Okay. Yeah, I thought it was over the top the comment. Okay. All right. Well, so, so that it sounds like the consensus is then well or Vadaq you had a comment before we go on. Yeah, just about the response there that the pull requests are easy and things like this. I agree completely with that. My concern is mainly for private plugins. There are a lot of user of Jenkins that are implementing their own plugins. And in that case, they do not have the knowledge about what you know, in terms of what is easy, what they have to do and these kind of things. So it could be a bit more painful to do for them, the different update that are required there. So is it possible to have separate plugin with the legacy icon with the good links and these kind of things so that they can keep using their own private plugin with that legacy adapter transformer plugin in a sense. I'm not sure how easy it would work because the plugins, the images that are being removed from core, not from plugins. And they're coming from the core resource path. There is a migration guide published for any of these on how to adapt. It should be self-discovery there normally in a sense that if I imagine I have a private plugin, I'm using some links that are no longer available in the new version of Jenkins. Will I get the information that there is a migration guide somewhere like some 404 page with information. Hey, you can look at that migration path, this kind of thing or it just you have to guess you have to create an issue to look for the things in the website. Just thinking about the developer experience there as well. Yeah, it's just Jenkins.io and there'll be an LTS upgrade guide as well I assume. Yeah, see, and we usually do the LTS upgrade guide to focus towards users so this one might be somewhat of an exception then if we put it in the LTS upgrade guide saying hey look, this, this is part of UI modernization and go help modernize your plug your private plugins. Yeah, so users of private plugins may need to update their image location. Okay, so fine. Forget about what I said. That's good. Go ahead to you could you could possibly add in a hook for like what we had said. If it's one of those removed ones then show a special image or something. But it had to be quite small and probably still return 404 and linked but you wouldn't be able to link it or anything. It just opened the discussion if you had some thought that it was easy to do or things like that if it's not the case not all the effort I would say. I don't think so really. But thanks for raising it. Okay. So, so good insight so I think I'm back to the consensus being, we would prefer to have plugin maintainers repair it, make the changes, and use, use the migration guide as their as their guidance on how to do it. Is there a way that I could search through the Jenkins open source code base and see the plugins that need migration. I assume there is right that we could that that's a searchable thing. Alex already handled most of it. Oh, he did. Okay, all right. So for the main those two PRs was the main one that removed 300 icons or whatever, and Alex updated about 50 plugins or seven got the more released. And then there was the one that you saw that Daniel commented on, which affects like two plugins. Okay, so, so the the open source piece the non private plugins has has already been done and, and yes it was a known known thing it could be done. Thanks. Yeah, and there may be a couple of edge cases I think Alex has done a few follow up since it's released but the big majority of them was handled and before it was released. Okay. All right. I think we're back to the consensus is, let's continue submitting pull requests and documenting and point to the migration guide for plugins with icon issues with old icons and point to the migration guide. Did I, is that a fair enough statement. Yeah. Okay, great. The next topic then was prism for source code highlighting Uli. Do you want me to stop sharing my screen and we'll let you share your screen to show or. Yeah, maybe that's the best thing. It's just a minute or two though but it's easier to see it on screen, I think. Okay, so let me stop sharing. There is the stop share there it is okay got it. And let's So last year, I think I introduced the new plugin that can, yeah, highlight source code and basically, sorry. I'm using it in the warnings plugin to render the source code. So here is one example in in one of my warnings plugin fuse, where you will see the source code of a, yeah, of a warning and you see here the warning highlighted. And what I'm using here in the background is the prism plugin now, which is rendering the source code using JavaScript. What I this was part of the warnings plugin and now I created from this part of the warnings plugin a new plugin where other plugins can use it. So for instance, I would like to use it in the code coverage plugin, and maybe some other plugins can use it as well. So what I created now is I extracted all of these colorings into this plugin so it depends on the language you're using so if you're rendering C code, it will use a C code renderer if you're using Java code you can see the rendering or the highlighting with Java. So this is done automatically. What I decided is kind of system configuration. So we have here the prism syntax highlighting section. And here you can select the theme. So currently, these are all these themes that are supported by prism. Maybe there are some additional ones available but these are the ones I found on the plugin repository of prism. So if you want to plug in and if you choose a different theme, then the rendering will look different. So you can use if you have a dark theme you can use this one. If you have a light theme you can this one that it depends what you prefer. So it is only possible to configure it in the system configuration. What I'm going to add is to make it customizable per user. So a user can say okay I have a dark theme, or a light theme. Yeah, that would be easier if it can be changed per user. It would even be not much easier if we can change it automatically, but I'm not sure how to do this to get an event if the system is using a light theme. So on Mac OS you can switch and toggle. I'm not sure if I can catch these events and handle it in Jenkins. Basically the plugin is not really a special thing, it just provides prism.js for Jenkins plugins. So are there any questions on this plugin or ideas what to do? A couple of things I guess. It would be cool if it was integrated into theme manager in some way so that all the theme configuration was in one place. You probably need a new extension point in theme manager for you to be able to add your own theme settings. Yeah, that would be a good idea. Yeah, we had a bit of a look at adding it for configuration as code, but I think it seemed just a bit heavy because configuration as code tried to avoid dependencies a lot. I think it had a few dependencies like plugin util and a couple others. So we're not sure. We're thinking about it, but I think because part of it is it has a whole bunch for generating on Java code side, whereas in configuration as code we're just enriching a YAML file. The two things we were interested in at four was one, a managed version of prism API so we didn't manage it ourselves and the other one was the theme side of it. But yeah, just not sure if it's the best fit for that plug for the configuration as code plugin, but we were interested in that. Yeah. Yeah, maybe we can split this plug in in one, you know, JS part and the util part or something like that. I'm not sure. Yeah, that would certainly help. So Uli the prism API plug in today is is more than just the JavaScript, the prism JavaScript library. I see. Okay. Actually, it provides this view. So the idea is that if you change. If a lot of plugins are using the same few I don't need to reprogram these views. And if I want to change it I needed to change it only in one place. So the idea is like the bootstrap plug in. We have the Java scripting library and some add ons we can already use in Java. So, yeah. Of course, we can split all of these plugins in a simple JS layer where we only have the Java scripting part and the additional ones which provide some jelly fuse and provide some Java APIs. So currently all of these plugins contain Java code to help the Java developers. Yeah. And if someone just needs the Java scripting libraries it's not possible yet to split them. It's just a matter of work. So I want don't have so much time or so I have one component but yeah it would be possible to use two components for that. Thank you. Okay. Okay. Any other questions on this topic. Maybe then I switch to the next UI plug in which is just a note that I also have a plug in which provides the icons of font awesome. They have now a release six with a lot of new icons and a lot of new designs. I included these new icons now in the corresponding Jenkins plugin. So if someone would like to use icons which are not the tango icons but some looking better ones. Yeah, everybody can use the new ones of the 6.0 version of font awesome. Is it do I go to the plugin documentation on plugins Jenkins.io to learn more about how to use those or is there some other place I need to go to. Yeah, it's all I think it's in the GitHub repository everything. So it's a big read me. I think I wrote a blog post. Yeah, a couple of years. I don't know where I introduced all these Jenkins Java scripting libraries and I wrote a lot of, you know, examples on how to use them. Basically, so, yeah. Plug in this plugin is really simple. It's just provides the icons as an sprite and you can use them in your plugins. So if we have all ionic icons in Jenkins core, maybe this one is not needed anymore. But until then, yeah, maybe it's a good alternative for tango icons. I'm using it for instance here in the spot box plugin here on this or here on this side where you can have some nice icons without, yeah, without any configuration used to simply use the name and you can use it. And this is what I also mentioned on our pull request of yarn. So as a plugin author, I just want to use icons. I don't want to search in the internet for an icon and don't want to upload it in my plug in. I just want to use them. So this is the idea behind this plugin. And, yeah, maybe we have a similar concept in core sometimes then this plug in is not needed anymore. Okay. And the last thing I would like to show you is, you know, it's more to get some feedback what we can do. One of my students is currently working in the code coverage plugin to improve the code coverage views. And we are currently trying to incorporate a column in the main view or in this table where you see the code coverage. And I'm, you know, we are not designers. So I want to have an open question on what would make sense to show in a column of the code coverage. So currently, we are using the percentage here of the code coverage and a color. And the color has a, you know, a shading or how do you say it in English, a gradient where you more it's more green if you have a higher coverage, and it will go sometimes to red. So, but it doesn't really look like a nice with a new table. So I'm not sure if someone has an idea how we can improve such views or such sales here. Try using some labels tags, the thing that are just around with the background around the number. Like you can see on notification pills in general, with the exactly the same kind of color you have there with some red thing. If it's below 20 or things like that, you have the information about the color you have the number, but you are not fully filling the cell completely in terms of background. I mean, you're like the one here in the yeah, it's okay. Okay. A couple of things. I would drop percentage from the label of the column. It goes on two lines and it's pretty obvious because it has a percent. Do you need that not applicable color there? I guess it possibly trying to call out was a problem. But whether it's intended that all the projects have coverage, I would possibly just leave it uncolored. What I've seen is maybe this is a totally different example on the, sorry, let's see. When you look at CodeCuff, there is a tool which showed the coverage. I thought that we can see it here. Okay, it doesn't work now. Okay, sorry. They provide a background which is a kind of 50% of the background is filled and 50% is not filled and this shows a coverage of 50%. Maybe this is an idea which is not so currently the colors are too looking too high with high contrast and I think it doesn't really look nice currently. But maybe that's a good idea to use some patches or something like that. To go further on, Tim's theme, I wonder if the word we're just coverage at the top, let them infer a code. Yes, of course. The label still doesn't, it's okay. I already commented that on the pull request but I'm just wondering how the cells should look like. Because in the static analysis plugins, I have the same thing, so yeah, okay, this is a different thing that our tooltips don't look good. And how, yeah, show how can I show that a project has too much warnings or if the warnings are okay, something like that. We have it in different ways. It's the number of tests, the code coverage, the number of warnings, et cetera. I think we don't show only text. Sometimes it makes sense to show some more information on the screen. So it would be helpful if we have some concept that can be reused somehow. Okay. So this is just an impression. I keep you informed how we are proceeding here. And just to put some positive notes, it's a very nice thing. So moving there, it's very useful to search information. So great job. Thanks. Okay. Are there any additional questions? Okay, then I think I'm finished with my part. All right. So next, I think next topic then was, was Jan and Tim on UI improvements or current status. Jan, do you want to take over? And if you've got something you'd like to share or topics you'd like to discuss? Sure. I'll just share my screen quickly. Nothing major today. Just a quick update on where we are really. So kind of in the last week or two, we've had the forms stuff merged in. So hopefully you can see that. It's basically 90 odd percent of form components cross Jenkins and now using the new stylings. So things are a little bit more consistent now they have the same kind of focus states and colors and whatnot. So this was this is quite a pain getting in so thanks everyone for the help. I appreciate it. And so that's that's now merged. And there's going to be a fair few follow up merge requests to this just to update the odd thing. Such as the draggable cards they'll probably change eventually and stuff like that. Very recently the new icons have been merged in so users can now use the symbols across Jenkins. The settings page everything's using the same kind of simple icon basically it's it's quite flat and so on and looks like so. And then recently I've been working on the rest of the icons across Jenkins. So you'll see in the sidebar using the same style of icons and the RSS icons updated pencil. And also recently with the status and other icons and they look a little bit with a icon or get people excited. They're a little bit different to how the icons look at the moment but this is kind of working progress. So everything's a little bit kind of flat a little bit bolder. And the weather icons have their kind of distinctive colors back. A lot of people who complained about the weather colors get with their icons going to a single color. And so yeah that's that's pretty much it for me really just working on the new icons at the moment. We'll hopefully have some sort of pull request up soon. That's that's all for me really. Did anybody have any questions or anything. So, so is this the large view. Could you. Yeah this is the large view for the icons. Those are the they are are they are they significantly smaller than they were before or is it am I just misremembering is my recollection poor in terms of size of icon compared to text. I don't think so. I could definitely increase them in size if they are too small. As I look at them now I think I think you got it matched I just I had not remembered them being as well suited to the size of the text. Nice. It's probably good to have a selection of jobs with different statuses to show when demoing sort of thing as well. This is a message from Daniel just saying to open up. Sorry. So I like Jenkins.io. Yeah, my browser's just gone berserk. Because we have only a folders on the top level but if you select the job that's building on the left perhaps. They do look a little bit small I think they may have changed size when the table was redesigned. I think it isn't running the new version yet. So probably are a touch more than than this. Yeah. You're more obvious with more jobs. I don't know how many questions or anything.  I really like that new set of icon. But at the same time there were a lot of changes in terms of icon that were done what two years ago something like that in the first kind of rewamp of icons. What could be the the guideline in general when we want to change something like this to prevent someone to reach change back in a sense in one year or things like that to be sure we are coordinating the effort in the good direction all together. Instead of having multiple conflicting direction in a sense. I think that project just got abandoned. It was at the very end of the CloudBase UX improvements. And it was the very last thing that was being worked on basically. I'm not saying it should be a follow completely. It just that I prefer that approach completely. It just what could be done to prevent this kind of situation in a sense. I mean, Jan's published a kind of a design sort of guide on to jinkers.io. I think it has been merged. Jan, do you remember? Don't think so. I think actually I think it was waiting for the weekly today. So it should probably merged after the weekly. But Jan's put up a guide on how to use these anyway as a starting point. Okay, great. Perfect. I was just about to ask what happened to the style guide documentation plugin developer thing that I asked for last year. And this is the first time hearing about this. So I'm really excited. Thank you. Yeah, there's a PR really to go. It was just waiting for the to do version to be filled in got held back because of the security release last week. That was all to me now before. And kind of somewhat on that topic as well. I've recently but very recently just forked the UI samples project and just to try and update that a little bit. Nice. It kind of looks like it's completely very, very rough. But the idea is that we'll have a kind of page for every component. And just developers can kind of pop on here and copy code and so on and get the right of template. Yeah, look in and so on. We talked about this a year or two ago about either just moving this back into core or or automatically installing it somehow in test jinkers or something. Just because it's a lot of people don't even know it exists because it's just some random plug in. And because it's outside of core, it's a lot harder for people to maintain it. So yeah, and could you pick one of those this looks this this gives me real hope. I was amazed at the number of things that surprised me and so this lets me now explore with the UI samples plug in and see source code to get a hint. Yeah, you should get jelly card as well. Yeah. I want to kind of restructure the pages anyway. Maybe you offer examples of both groovy and jelly at the same time rather than having them kind of split. But yeah, so for example, the copy button page shows you the preview of the component. I can also access the source code for it. And yeah, it's kind of a really early days for cover at the moment. So we'll see maybe for the next sake to see where it goes there. And if you could inline that so you don't have to click on the source file. If you could just do some sort of raw thing with a prism prism highlighting on top of it or something. So so and copy button in this case is showing the groovy is there a copy button jelly that's that's the same thing in jelly and that's what you would combine two things into one. Yeah, there isn't a jelly version yet but I can write that quite quickly. And now for as guidance for me, I think most people are preferring to write jelly. Is there a, is there a reason we should be pushing more and more people should should the get plug in for instance switch from the things where it's using groovy now in its UI to use jelly is there is there are their weaknesses and using groovy that I should be aware of. If you're using jelly, it simplified the work of the security team. Okay, just for that it could be a good argument because if you want, when we are looking for things in Jenkins, if you're using a completely different language, it just completely different for us to look for your thing in general. So if I can with a magic one to change all the groovy view to jelly, I will do it in an instant, because for us it just doubling the size in terms of results, rules to write these kind of things. Jelly views are supposed to be more performance so anything that gets called an awful lot is supposed to be in jelly groovy is supposed to have better ID integration and you can debug your views in the ID is an advantage of it but kind of also I've always found the groovy a bit harder to write. Great. Thank you. Okay, so that that lobbies that there are the moving away from groovy is a good thing and showing people like me how to do it with jelly will be a help. Great. Thank you. Okay. I think we're supposed to be more type safe views and a little bit anyway, the better ID support I think is one of the polls but I'll stop train my screen benefits. I've got the theme manager rework. So this is something that yarn started on earlier. Let me just find my screen. I've done this a while back, but kind of just left it because it depended on the form rework. But so you might have seen this before you will have seen that he's changed the built in themes from just a little radio buttons on the side here to actually separate them out into a theme, and then he's got like pulled in the colors from each theme and then it shows you which theme it is. And then if you click on it, it will actually change. So if I click to default, it will live reload and change to nothing. Same with dark and dark system. And then if I go to display dark mode, so I've just changed my display from light to dark mode. And then Solarize, Solarize dark. So just like live clicking around here. So yeah, I believe that is something that people like, but I think it should be quite nice. That's awesome. Okay, so, so my user experience is I can click around and see what the theme will, how the theme will appear to me if I choose that. Very nice job in the animation as well. That wasn't done nothing to do that. It just changes CSS class, not even CSS and data set. So it's based on this value up here, themes in our namespace. So it's a bit of a design change. So instead of only serving one CSS file, it serves all the CSS files on the pages. And then based on this value here, it's which theme it's going to show. And so now does this dramatically increase page size for people or? The CSS files are absolutely tiny. So not really an issue. Refresh the Solarized ones are under a kilobyte. And the dark theme ones are about live and kill by each and they will be cached heavily. Once I fix the dark theme, not caching stuff. As I see that Daniel use stapler. In a better way. Yeah, there's one bug to fix on the Solarized system. You see Solarized system isn't working. And I need to change something in core to integrate with this so that it gets the default color. Instead of the currently selected one. But it's pretty much there. I'll show you just a couple of main changes with the morphers. That's on my fork. So there's a new flag is namespaced. So this will only add all the themes if they're namespaced. So old themes won't automatically get added to this. So it means you won't get any problem with an old. So it's completely compatible. And old themes won't affect this new setup. I've done a bit of a hack in the dark theme. When I load the file, I add this prefers colors theme dark. Rather than how the other mechanism was before. And this is a couple of places and automatic. And so just does a finer place with that as well. Changes to dark systems. I've only got one CSS file. It's a bit hacky. But you see these these data theme equals dark selectors. That's selecting the root elements theme. And you'll also see the theme picker has a data theme element as well on it. So that's how I've got the colors coming in here. So it's just it's just using the SVG. It uses the same variables that are used for that the theme uses. And then this here is a more specific selector which overrides in the context of this window. And so you've got a local fork of the solarized one. Just pretty much the same thing. And I'll also try fix up solarized to work on system as well. And probably update material theme and core. But I think it's pretty much there. It's pretty close to ready. So I updated yarns poor question theme manager. There's one thing that is failing is the injector test fails because it doesn't allow you to do for equals on the label. The yarn switched from attached previous to four equals. But I think Jenkins core also switched from that. Jenkins core doesn't run injected tests. So I think we might just need to make to update through and remove that injected tests probably. You said four equals Tim that has some semantic meaning in JavaScript that. Yeah, so it associates a label to an input using the ID.  Well, it was discouraging to do it because repeatable elements and. And guessable IDs wasn't so easy, but that's all handled for you inside of the jelly fragments inside of radio. If radio or whatever it is, it generates the ID for you and does the association. Whereas before there was a JavaScript function called which attached, which would try and find these and attach them. I assume you aren't changed that for some reason. It didn't work perfectly in some cases, I'm guessing. It's mainly just for accessibility. And then some of the CSS left has kind of got a bit wonky with that method. So kind of went a bit weird, but pretty much that. Yeah, so you need to fix that up because the tests are failing because of that at the moment. But hopefully should have all that tidied up out of this this week or next. It's pretty close to being ready. And for me, I have a question about for plugins. So what I'm using my plugins is a kind of color palette to show the warnings or to show the coverage. And I think that it would be perfectly if we integrate an extension point so plugins can provide a themeable thing. And then I can have different colors if we have, for instance, a black theme and currently the colors are look a little bit weird on the charts if we use the same colors in a dark theme. So we can automatically switch them though that would be a really good thing if it would be extensible. Yeah, I mean, you could certainly get the themes from theme manager already and you could just use the. I'm not sure if you could just map those themes or or just another extension point to integrate within some way. But like you could look up the theme and if you could say it was using dark you could or dark system or something you could just use that. Yeah, but the themes are have no semantics or they have just a name. Yeah, I mean should it would definitely be possible to add an extension point for it that a plugin can extend from the manager. Yeah, I'm not sure maybe it's it would be easier if we have a kind of color palette in a theme, which is independent of the plugins. So because the unit plugin needs something to represent a green thing and a red thing, the warnings plugin needs it the coverage plugin needs it and maybe a different plugin needs it as well. So it makes no sense to have 10 different theme at different color palettes it makes maybe sense to have one system color palette. We do do that now. Yeah. Okay. I'm just linking it to linking it here. I'll just share my screen quickly just a demo. Essentially, say for these icons, the screens dependent on the theme that you use. So if I try and good start quickly, you'll see the green will actually change slightly it'll go brighter. And the sun's disappeared for some reason. If I reload you also see the sun's also a slightly different color as well now. This is all possible to use in your plugins straight out of the box. Is this just two colors or is it because in a when you're using a chart you need more than your three or four colors. We have support between six colors at the moment but I plan to add entirely rainbow and more eventually. I've just been adding the colors that I've been using for the icons and whatnot, but look at a massive palette by the end of it. Okay, that's fine. So, yeah, and to be sure that that the palette definition then is shifting into the theme theming, therefore, Uli will eventually or other other things that are doing graphic rendering will be able to get their color definitions from something that is theme aware. Yeah, yeah. I was just calling the CSS variable and say Tim seems can override that easily so the update kind of magically. Excellent. Thank you, Tim or Jan. Yeah, Jan, anything else. Are you still working on the buttons PR Jan or any of the other, is there any other open ones. I mean, it's just the buttons and breadcrumbs right now. I think the breadcrumbs might just need one more review or something like that. And then the buttons just need the acceptance tests. Would you mind adding me to the to the branch for that just so I can try and fix it or something. I'm not really sure. One setting of the acceptance test is a bit limited, admittedly. Buttons. Yeah, I can add you to that. Yeah, and the unit test should be passing now. They went a bit dodgy due to with merge that I did but they should be fixed. I've added you. Yes. So your breadcrumbs is breadcrumbs. Yes, got three approvals. I'm not sure if Daniel if you were planning to have another look the combining of this separated was backed out. I mean, the combination was fine. I just didn't think it makes sense to add a new type to the hierarchy when it's more about the presentation. I can't really explain the reasons in the in the poll request. I haven't had a chance to take another look. Yeah, I think you definitely can. We just weren't we aren't wasn't sure on how to get it working without that I think the time newly suggested just backing it out for now to ship an interactive again. I think it makes sense. Sorry. Daniel go. Okay, what just wanted to say I'll take another look. Thanks for the pink. I wanted to say, I think we need some time to discuss the sidebar elements currently I think in much. There are many too many things on the sidebar which should not be there. And maybe we can define a new concept what is really shown on the sidebar and whatnot. So we don't have 1000 plugins that can add an action on the left and yeah you don't see the important things anymore. But maybe get maybe getting rid of the sidebar in some places or collapsing out or or sections in the sidebar and hiding things. I mean, to some extent this is a problem with the extensible nature right because if we say, well we only display things by default if they are an important action or something. Then obviously every plugin maintainer will say yes my plugin is definitely going to implement important action because it is very extremely important.  The get plugins quite bad at this I think it's attached last I noticed it attaches lots of build data, which becomes an action on the side. If you have interactive two or three get reefers I think you end up with like three things on the left. I mean there are strategies to to address that. Certainly. But maybe we can give some guidelines what is good and what is not good and this is currently really missing. So when I started my warnings plugins I also added a lot of actions on the sidebar but now I'm thinking maybe it would be better to have just one static analysis, or even if it doesn't need on to be on the sidebar. Maybe we need some totally different screen rendering. Yeah, I was going to look at that. Sorry. And one of the things I was kind of thinking of was kind of having plugins display as cards, kind of on the build page so for the static analysis warning, have a card for that so. So having an action users can see the cards straight away for example. So there's less clicking involved and hopefully showing more on the build page because right now it can be a bit empty at times. So that on the pipeline graph you plug in at some point. Somehow I lost my branch, but like I started adding a bit of that where you'd have like tests and coverage and static analysis would just get added would get like a section on the page or a tab or something. But I don't know what happened. I lost it in a stash or something I don't know. I'm not sure I wrote the card. Something we could look into could be that we show only some of the items. Now, there are a few ways we could do that I just mentioned the prominent or important action. So that would always be displayed and the others are you kind of have to click on an element first before they're visible or something like that. The other option would be that users can configure the stuff they want to see, which obviously means it's still a mess unless a user goes through the work of, you know, customizing their thing, which is probably not a great default. Another might be that we could look into like, can we track the actions actually used by a user in some manner, because we know when you click the, we can probably determine when you click the link to see an action and navigate there. Can we track that in your user profile obviously difficult impossible with the anonymous user and feels a bit like brittle magic. When people don't understand what's happening but just off the top of my head, these might be strategies we could employ without entirely throwing away this part of the UI. I think we presented a couple of months ago one of the bachelor thesis work of one of my students, where we had this pull request monitoring plugin, which showed how we can use some kind of, you know, drag and drop things to configure the screen. Maybe this is an approach as well. So maybe I show you the details. Maybe it's easy. So, this is where the idea was that we have these things where we can put these elements here and we can, I think it was here where can use different portlets and select the portlets. And what we did not manage was to say what is a good default, because everything is important for everybody so it's really hard to find. Yeah, which of these portlets are good or which should not be shown so yeah. This takes a little bit time, I think, until we get this finish. And then you get microservices and then you have 1020 30 projects, you're looking at, and then you don't care about individual, you just want an overall. Are there other topics that we should be discussing here before we conclude. All right, I take the silence as a, it's okay, thanks very, very much to everyone involved today thanks for the presentations, early, Tim, thank you, thank for your work on on 2.335 and on all the ongoing things. This is amazing. Thank you very much a recording will be available this within say the next 24 hours I'll get it uploaded. Thanks all. Thank you.


So, my name is Jacob Hoffman Andrews, I'm a staff technologist at the Electronic Frontier Foundation. If you're at the EFF panel, parkour is saying, you know, we like to solve problems by suing. We also like to solve problems by writing code and writing blog posts, and that's what I do as a technologist. So specifically, my biggest project these days is Let's Encrypt, which is part of EFF's ongoing project to encrypt the web. Pardon me, it's going to be a little awkward because I couldn't get my speaker notes on the screen and the slides up there, so I'll check back to see what page I'm on occasionally. So to start off with, I'd like to explain a little bit about the project to encrypt the web and why we care so much. So you're probably familiar with HTTP versus HTTPS. HTTPS is the more secure version of HTTP. It protects your data in transit and ensures that you're talking to the website you think you're talking to. So the first and most obvious reason why we care about encrypting the web is our friends at the NSA who are hoovering up everything, and especially they love plain text, which is HTTP, is plain text, and it's easy to look at, interrogate, find selectors in, find data in. We also know that they actually care about SSL, which is the protocol underlying HTTPS because they try to find ways around it. This famous slide from the Snowden leaks shows a little smiley face with SSL added and removed here. So when they find encryption, when they find SSL, HTTPS, they try to bypass it by going to the inter-data center links. But we've actually started to see a bunch more kind of commercial level attacks recently. So for instance, about a year and a half ago, EFF kind of sounded the alarm about Verizon's new tracking program using this UIDH header. And the way they were doing this tracking was actually really novel. They would take HTTP traffic passing through their network, they would modify it, and they would inject a unique header for every user. So if you were a website that had visitors from Verizon, every one of those visitors would have a unique cookie tagging them that doesn't respond to their browser's privacy controls or deleting cookies, or if you have a privacy badge or installed, that wouldn't help. The only thing that helps with this type of injection and traffic modification is HTTPS. We've also seen Comcast using HTTP vulnerabilities, like the fact that HTTP is so trivially man-in-the-middle-able to insert ads into their webpages.  The other really important thing with HTTPS is HTTPS2. HTTPS2 was standardized, I believe, last year, but has already seen a lot of deployment, and it's got a lot of performance improvements over HTTP. But what the authors of the spec found is that in practical deployment, these middle boxes, you know, caching layers and caching proxies and, of course, blue coat boxes, munch the HTTP so badly that if you tried to change any protocol aspect of HTTP without adding encryption, you would have a bad time. Some middle box somewhere would munch it and would break the protocol. So in practice, if you want HTTP2, you need HTTPS to support it. This was one of the really fascinating attacks of the last year or so, was the Great Cannon. This was due to some great research by Citizen Lab. Basically what happened here was GitHub was being used to host some content for greatfire.org, and China didn't like that content. So they wanted GitHub to take it down. GitHub wasn't taking it down, so they started DDoS in GitHub. And this was one of the biggest DDoSes seen on the Internet, I think. I'm not sure if the full numbers have been released, but it was a really remarkably large DDoS and remarkably hard to counter. And the reason was this unique way it worked. So China has kind of made in the middle position on a huge amount of Internet traffic, not just users inside China, but users outside China. So Baidu is, of course, a huge Internet company, and they offer a lot of services, including Baidu Analytics. Baidu Analytics is like Google Analytics, but by Baidu. And so that's included by millions of websites around the world, not even just Chinese websites. And visitors from all over the world would visit those websites. And normally their browser makes a request for BaiduAnalytics.js. That request goes to Baidu servers in China, comes back with regular JS. During the attack, when China turned on this tool that Citizen Lab deemed the great cannon, those bytes for the BaiduAnalytics JavaScript would instead come back with an attack payload, which would basically say, fetch this URL on GitHub over and over and over again. And at the scale, the huge number of people that load webpages that have BaiduAnalytics, that added up to a tremendous amount of traffic. And it was very hard to block and filter because it didn't come from any one place. It was essentially an instant botnet made out of browsers. And the thing that made this possible was HTTP rather than HTTPS. So if we had an all HTTPS internet, this type of attack would no longer be possible. I mentioned in the slide title PKI, I realized it's a jargonny acronym. And feel free to raise your hand if I say a jargonny acronym and I forget to define it. PKI is public key infrastructure. It's how you know which key goes where. So for instance, with PGP, you manually verify each other's keys on the web. We have some help from the web PKI, which is composed of CAs or certificate authorities. So there's a problem with CAs, which is there's too many of them and they're too big. They're too decentralized and they're too centralized. So this is a graph from the Berkeley ICSI's scan and evaluation of the CA ecosystem. There's literally hundreds of CAs or certificate authorities. And each one of them is trusted to vouch for any website on the internet. So if you run a website and you use HTTPS, there's hundreds of entities who could sign a valid certificate for you. Now they're supposed to follow correct procedures to ensure that they only sign certificates for the right entities, but those can fail. There have been a number of examples of CA failures over the last few years. And that brings us to the other problem, which is if you see some of the largest circles here, Rapid SSL, GeoTrust, I don't see semantic on there, but they're definitely somewhere in that graph and they're big. If one of those biggest CAs fails and they miss issue a cert, you might say, well, forget them, I don't want to trust them anymore. But you can't, because say for semantics, some 30% of the websites on the internet are signed by their certs. So if you turn them off, you would break the internet for yourself. More importantly, the browsers can't turn them off either, because they would break a huge portion of the internet for their users. And this is sort of an open, unsolved problem. There are a few alternatives people have worked on, especially in the hacker community, Dain, which is DNSSEC, something named entities. I forget, DNSSEC authentication for named entities, I believe. This is a protocol based on DNSSEC that allows DNSSEC to deliver the trusted keys for a given website through the DNS system. And it's hierarchically rooted in the trust you have in the root zone. But that's not actually seeing any deployment in browsers yet today, so it's not yet a practical alternative. Sovereign keys was a proposal by my colleague at EFF, Peter Eckersley, along with some others, to put identities in an immutable public log that could be used not only for vouching for identities, but also for censorship resistance. But again, we're not seeing practical deployment of this in browsers. Convergence was a proposal by Moxie Marlin Spike to use a concept of notaries. So you would have multiple vantage points across the internet that could reach out to the site you're trying to visit, tell you what key it should have. Not available in browsers today. TAC was a proposal to use the certificate authority ecosystem to bootstrap trust in your site. And then from there, you would essentially use self-signing. You kind of take care of your own key. This is similar to what is available now, which is called key pinning. So this is a bit of a way to say, I want to trust the CA system minimally, but not available on browsers. And DNS chain is a blockchain, Bitcoin-based approach to naming and delivering keys. And again, it hasn't seen any practical deployment. Or I should say it hasn't seen large-scale browser-based deployment. So what are we left with? If we want HTTPS for the whole internet, we're going to make another CA. They say you don't go to war with the army you want.  You don't encrypt the internet with the CA, with the PKI you want.  So this was a big project. EFF came together with Mozilla and the University of Michigan and sponsors Cisco and Akamai to create the Internet Security Research Group. So ISRG is an independent nonprofit from each of these entities and runs, lets, encrypt and owns its roots and keys. And ISRG has a small staff. It also gets through volunteer labor from EFF employees and Mozilla employees like myself and some of my colleagues. So the big question when you want to start a CA is how do you get trusted? How do you become one of those hundreds of CA's I showed you in the previous slide? So the decision of which CA's are trusted is to some extent up to the browsers and to some extent up to the operating systems. It's a question of what's called trust stores. So a trust store is a list of CA's where you say these are the CA's that are allowed to sign in my world. So you have essentially three options. You can buy a route from somebody else who's already in one of the trust stores and this happens all the time in industry. And there's pluses and minuses to it. You could say trust isn't necessarily transitive across purchases, although there is an auditing layer to prevent terrible malfeasance in theory. Another alternative is you can pursue something called a cross signature which is where another CA in that graph of CA's signs your route or signs your intermediate certificate and essentially delegates that power and says this entity ISRG is trusted to issue certs. And thirdly, you can actually just start from scratch. You can roll your own key, make sure you store it in an HSM, apply to the browser and OS route programs. And six months to a year later, the very newest browsers will trust your cert. But we wanted to be trusted by a really wide variety of browsers and other programs right out the door so that people could start encrypting right away. So we wound up going with this approach. We're cross signed by another CA called a dent trust who's also one of our sponsors. So I said, well, we've got this kind of broken ecosystem and we're participating in it anyhow because we think the win is bigger than the loss. But we are doing some things within that ecosystem to try and improve it. The first is CAA, Certificate Authority Authorization. This is a DNS specification. So it's a newish DNS record type in the last few years where you can request a CAA, Certificate Authority Authorization record for a given domain and that says, this is the list of CAAs that I want to allow to issue for my domain. So maybe you don't trust some CAA you can say, okay, only these three are, say, only Let's Encrypt or none at all. I don't want any TLS certificates. Go away. Let's Encrypt is actually the first to implement the CAA spec versions. Oh, no. OK, correct. We have a correction. Ah, all right. Sorry about that. Yes. Is that Rob in front? Yeah, hey. So we have Rob Stradling from Komodo in front, and he corrected my fail. Oh, sorry, fail. So Komodo actually invented CAA. And is Komodo enforcing CAA for issuances? Oh, that's operations. OK, that's operations. So anyways, we consider CAA implementation one of our important security fixes. We also implement Certificate Transparency. Certificate Transparency is an attempt to improve the trust of the CAE ecosystem by ensuring that every certificate issued is logged publicly and can be analyzed by the public and by browsers. And so when there's a mistake, when there's a mis issuance, we can catch it right away and take the appropriate measures. So Let's Encrypt from day one has been logging voluntarily every certificate we issued to CT. And we plan to take further steps to ensure that the CT proofs are included with either OCSP responses or in the certificates we issue. So sometime in the future, the goal of the CT project is to enforce that every certificate trusted by a browser is present in a CT log. Serial number entropy. So the CAE ecosystem recently went through a transition from the SHA-1 hash to the SHA-2 hash. And the reason for that is, SHA-1 is no longer considered strong enough. It's too easy to produce collisions on SHA-1. And if you can produce a collision in the hash used by a certificate, you get to mint your own certificates. And we saw this before with the MD-5 hash. We migrated from MD-5 to SHA-1 many years ago. And while MD-5 was on its last legs, a group of researchers actually produced a live collision and minted their own fake CAE certs using this collision. So as a response to that, the CAE sort of self-regulating organization called the CAE Browser Forum added language saying serial numbers should include 20 bits of entropy, which was a great step and I think most CAEs in practice do that now. But there's still this bug in that this critical security feature, entropy in the serial number, isn't required. So one of the nice things about being a CAE, we get to participate in the CAE Browser Forum. So we recently helped push through a requirement for serial number entropy at a 64-bit level. So now that's a must rather than a should. One of the longstanding problems with certificates in general is, you know, they say revocation doesn't work. Revocation doesn't work because the method we use to deliver revocation information, OCSP, is not inherently reliable. It fails some percentage of the time that's unacceptable to end users. So if you're visiting a website and the website is up, but the OCSP responder is down, you generally don't want that to stop you from visiting the website. So what that means in practice is that if a browser fails to get revocation information via OCSP, if it gets a timeout or it's blocked in some way, it'll fail open. It'll say, you know what, it's probably not revoked, I'm not gonna worry about it. But you can imagine if you revoked your cert because somebody stole your key that the attacker using that stolen key with a network position on their victim would just block the OCSP response. So OCSP in practice as deployed by browsers is this tool that sort of fails when you need it most. So there's a recently standardized spec called OCSP must staple. That's actually called TLS feature, but before that it was most commonly known as must staple, which basically says, you know, when I make a handshake with a web server, if it has this extension in the certificate, I should always expect to see a stapled response attached. And if I don't, when I say stapled, that means that the server has gone to the OCSP server, OCSP responder itself, fetched assigned response that's up to date and has a timestamp and attached that to the handshake. So this actually makes revocation work if you turn it on and let's encrypts deployed it pretty early on. I think, again, Komodo actually beat us to the punch on that. But this is, you know, we're trying to make revocation actually work on the web. So takedowns, you know, one of the things that doesn't get talked about a lot is the power of your CA to take down your website through revocation. You know, I said, you know, OCSP is a tool that fails just when you need it most, but it also works when you don't want it to work.  Now, you know, I haven't seen this actually happen in practice, but because not all certs are logged to CT yet, it's actually not possible to do the comprehensive research necessary to find out how often revocations are happening. So when we develop let's encrypt policies, we try to take a very content-neutral approach and say, you know, we don't want to revoke certificates based on the content of the site. We revoke them if the key is compromised or, you know, a certain number of other requirements that we have. Now, we've had to make some compromises there based on the requirements placed on us by root programs in the CAB forum. So we do some amount of phishing check at issuance time when you talk to the Google Safe Browsing API. But we try to keep those as minimal as possible to avoid the temptation to do content-based takedowns of sites, which I think is going to become a bigger issue as HTTPS deploys further. And we have some community forums that, you know, started out as a support tool for let's encrypt itself and for our many clients, but I think these are quickly becoming one of the best places to get advice on TLS configuration on the web today. I work pretty hard to keep them a friendly place and always welcome more people, come check them out and either contribute advice or ask questions. So one of the other really cool things about let's encrypt is this new protocol ACME, which is the Automated Certificate Management Environment, which is clearly a background. I'd like to say it's named after the ACME bread company in San Francisco because certificates should be like bread and that, you know, everybody should have all that they need, but it's actually named after the ACME company in the Roadrunner cartoons that, you know, produces boulders and anvils and that's where the name of our server software comes from, it's Boulder. It's an ACME Boulder. Here's the URL for the IETF process. It's an IETF standards track document. Would love to get more feedback, more analysis. So right now, let's encrypt is the only CA implementing ACME, but Startcom, who runs StartSSL, has recently committed to implement ACME. They rolled out their own kind of ACME-like protocol with a custom client in a service called Start Encrypt. Some researchers found that there were vulnerabilities in how that does validation. So they've since decided, you know, let's use the standard ACME. SSLmate is not technically a CA, but is a kind of front end to a number of CA's that has a really convenient tool for setup. Andrew Run's SSLmate is also considering implementing ACME. One of the valuable things about ACME relative to previous protocols that try to do the same thing is that it covers both validation and issuance. So ACME includes not only instructions on how to ask a CA for a cert, but how to prove to that CA that you own the domain for the cert, that you own the domain that's listed in the cert that you're asking for. And I said, we have bold or implemented. We also have probably dozens of clients for Let's Encrypt that speak the ACME protocol. And the idea here is that once we have broader deployment in the ecosystem, you can have one client that could potentially interoperate with a number of CA's. Hopefully that will reduce the too big to fail problem by lowering switching costs and making it easier for people to choose a CA that meets their policy goals and meets their cost goals. Perfect. So this is our server software, Boulder. It's written in Go. You can visit our code on GitHub, take a look. Do a security audit if you want. We have paid for professional security audit and we're about to go through our second one and we've also gotten a volunteer one from the community. We're always interested in making this more secure. CA's are a core part of internet security and we do our best to make sure we live up to that very high standard. So CERT-POT is the first ACME client developed. It was developed at EFF. And CERT-POT's goal is not only to solve the issuance problem but to solve what we saw as perhaps the even bigger kind of skills gap, which is that if you wanted to buy a certificate, the cost is one thing, it was $15. It's not that bad if you're based in the U.S. It's pretty bad if you have a bad exchange rate on the dollar. But even beyond the monetary cost is the time and skills cost. Most people just don't know how to start getting a certificate. You have to create a CSR certificate signing request. You have to upload it to the CA. You have to follow their instructions to prove you on the domain. You have to download the certificate and you have to install it. You have to remember to install the certificate chain, which is a common mistake, and you say it won't work properly without it. There's a number of mistakes you can make. Even professional sysadmins sometimes take hours to set up a cert or renew it. So we wanted a tool that could handle all that for you. It does the proof, it gets the cert, it installs it, and suddenly you have HTTPS. And CERT-POT does this. It has auto-configuration for Apache. We're working right now on adding nginx support. So if you use nginx, it can do that automatic install thing. Also one of the common misconceptions about CERT-POT is that it requires root. Certainly kind of the smoothest flow is if you have root and it can write keys with only root privileges, reconfigure your Apache, write logs with only root privileges. But with a little bit of config, it works just fine as a non-root user. I mentioned we have a broad client ecosystem. This is just a small sampling of the ones we have. Lego is a client and go. It's pretty small and straightforward. Catty is a really unique web server. It acts either as a file-based web server or as a reverse proxy. And it just handles the let's encrypt certificate assurance for you. So you can stand up a catty server, tell it what your host name is, and you have HTTPS. You don't even need a separate client. Acme Tiny is designed as a small Python client that doesn't have many dependencies. And Acme Sharp is your option for Windows. I haven't tried Acme Sharp out, but try it out, let me know what you think. And if you don't like the idea of installing any extra software on your web server, if you're familiar with the existing certificate assurance process and you just wanna do that again, you can visit gethttpsforfree.com. This is a third-party piece of software that uses the Acme API and allows you to submit a CSR certificate signing request and gives you instructions to put a certain file on your website and do that whole thing without any software install. So it takes more time, but it's just kind of zero touch in terms of installing any software on your servers. So let's encrypt has limited resources. We try to make them stretch as far as possible and make sure that everybody gets the certificates they need. And I think it's a common place of running a service on the internet that if you give somebody something for free, they'll use all of it. So we have some basic rate limits in place to ensure fair distribution of certificates to everyone who needs them. We do it based on the registered domain, which is say you have example.com, it would be www.example.com, the example.com part is the registered domain and that takes into account other TLDs like .code.uk. So within one registered domain, you can issue up to 20 certificates per week. The certificate is kind of the basic unit of what consumes resources for us. But each one of those certificates can contain up to 100 subject alternative names. So you can have 100 names on that cert. They don't all have to be for the same registered domain, but if you're trying to get as many subdomains as you want on a single cert, you can do 100 of the subdomains in 20 a week. So each week you can do 2000 new subdomains inserts. The other thing we really care about is renewal.  So we have an exception in place. If you issue a certificate before and then you go to issue a certificate with the same set of names, you get a free pass on this particular rate limit. And so what that means in practice, it means two things. It means you have a defense against hitting a rate limit while you're trying to renew. But it also means in practice you can continually grow the set of names for it. You can issue for your domain. So in week one, you issue 20 certs. In week two, you issue 20 new certs and potentially renew your previous ones, although you actually have many days before you have to renew. So 90 day certificates. This has definitely been one of the most controversial decisions that Syncrypt has made. But so far I think it's working out fairly well. There's kind of two main reasons we decided to go for 90 days, even though more traditional CAs tend to go for a year. One is key lifetime. We saw with the Heartbleed attacks of 2014 that it's possible to have roughly internet wide potential key compromise. Any server running OpenSSL in 2014 might have had its private key compromised and there wasn't really a good way to be sure. And it was a year before all of those keys were rotated off, not necessarily even all of them. With 90 day certificates, if people are issuing their certificate each time with a new key, the time of exposure to that type of attack is smaller. But I think the even more important effect here is that it's allowed us to build expertise much faster with automated issuance and especially automated renewal. Let's Syncrypt's goal is not just to reproduce the existing CA structure but make it free. We're actually trying to do something new and special which is make this stuff easier, make it more automated. So if we went with a one year schedule, it would have been a year from our first launch before we saw any experience with renewal at all. And we would only get a chance to improve our systems and for clients to improve their code once a year. So this way we've actually, we get about six opportunities through the year to, you know, for each client to renew and make sure that renewal is working. And the goal here is if everybody can do automated renewal or a large majority of sites can do automated renewal, we can get rid of the, this certificate has expired message which is kind of a counterintuitive thing. You'd think longer lifetimes would help more with that but we think this is actually contributing to a stronger auto renewal ecosystem. And it's also encouraging hosting providers to build in core integration rather than relying on their users to go to sites like get HTTPS for free and paste in the certificate. So how are we doing by the numbers? This to me is one of the most interesting ones. My colleague, JC Jones did some analysis and this is again based on the certificate transparency project I talked about. So there's some large fraction of certificates that are available on the web that are now in the CT logs and beyond its benefits for transparency and auditability of CAs, certificate transparency is a godsend for researchers because you have a large set of certificates you can analyze. So what JC found based on CT data and also based on data from census.io, that's C-E-N-S-Y-S dot I-O which is a scanning project from the University of Michigan. He found that of all the certificates issued by Let's Encrypt, if you look at the host names in those certificates, 94% of them had never been used in a certificate before that had been seen by census or certificate transparency. And this is really the number we're trying to affect, as much as we want people to be able to save money on their certificates, we're really trying to get new sites onto HTTPS. And so far it seems like we're doing that fairly well. This is an up and to the right graph, number of currently unexpired certificates. We're currently at four and a half million. You can see in the graph here, there's a pretty sharp spike upwards. I believe that's when WordPress.com turned on automatic integration of Let's Encrypt certs and they shoot for a million host names all over the course of a week or so. And that's an example of the great power of hosting provider integrations is, you can turn on HTTPS for people who wouldn't even necessarily know what HTTPS was or why they should turn it on. They don't have to think about it. That's the level of easy encryption we really want to get to. This graph, I don't know how well you can read it from back there. This is not quite as reassuring. This is the percent of page loads. Yeah, it's very small text up there, but a percentage of page loads over SSL, aka HTTPS. And this comes from Firefox telemetry. So Firefox has code in it that will collect various data that helps Mozilla improve the browser and report it upstream to Mozilla if you let them. The great thing about Firefox telemetry is that they actually make it public. It's anonymized, so you can't find data about a particular user. And it will tell us the number of page loads over SSL versus the number of non-SSL page loads. And you can see this is also up and to the right, but not quite so up and not quite so to the right. We were at approximately 37% in September of 2015, and we're now hovering right around 45%. So we've come 7% over the course of about a year. If you extrapolate that linearly, which it's almost certainly not gonna be linear, but we'll get there in seven to eight years getting into 100% HTTPS. Personally, I think that's not nearly fast enough and we need to kind of step up this rate a little. So we're gonna be looking for more ways to increase the rate of adoption. And you can see there's a little bit of a kink in the graph when let's encrypt launches, but we'll see on this next graph. This is the percentage of validations using let's encrypt certificates. So this is also from Firefox Telemetry. And what you can see here is, we start out small, we get big fast. This is kind of proportional to our number of issued certificates graph, but on the right is the percentage and it's 0.15% of validations. So let's encrypt is issuing a lot of certs, but they're mostly to what we'd call the long tail or relatively small sites without a huge amount of traffic. And honestly, that's fine. That's the goal here is not just to get the Googles and the Facebooks of the world encrypted, which partly through EFI activism, they decided to go HTTPS some years ago, but we also wanna get the smaller sites for which people would say, it's just not worth my time to encrypt the site. It's not worth three hours. It might be about five minutes, it might be worth five minutes. Zero minutes, and my hosting provider did it for me? Sure, it's totally worth zero minutes. So obviously, like any project, we wanna see our fraction of validations go up. And so this is a number we'll work on. So the big question posed in the title is, how many certificates are we gonna issue? I kind of gave away the punchline there, which is by some estimates, there are about a billion websites. So if you look at the number of certs, let's encrypt this issue today, right about four and a half million, there's some tens of millions of other certs from other CAs existing in the logs. But that's about two orders of magnitude smaller than where we need to be. So we really need to accelerate and amplify the rate of certificate issuance and the rate of getting sites to start using HTTPS. This, by the way, is from internetlifestats.com. So what do we need to get there? So first off, read the code.  Like I said, we pay for professional scans, but we are very welcoming to community contributions. If you see a minor non-critical bug, file a GitHub issue, if you see a security flaw, visit let's encrypt.org, and we have our security contact on there, and we have a PGP key so you can email us details. We also definitely love more contributions to the code. We've gotten some great participation on both the Boulder and Certbot repo from volunteer developers that have really made the product better. We always want more clients. I said, do we have dozens of clients? There's always room for more. Our attitude is let 1,000 flowers bloom and let people find the clients that are right for them. I think we're definitely still in the early days of experimenting with how automated certificate issuance can make things better. Especially documentation improvements. I led a workshop yesterday morning and led some of you through the process of getting a certificate from Let's Encrypt, and definitely there's places where our docs are lacking or could be more user focused or more to the point. We would love pull requests on our docs to any problem you've had, if you don't find the answer in the docs or you think it's in the wrong place, send us a pull request or a ticket. So a lot of the work on both Let's Encrypt and ISRG comes from staff like myself funded by EFF memberships. We have a booth downstairs. We've been working the booth some of the time and it's been great to see how enthusiastic everyone is here. Could I see a show of hands? How many people are here EFF members already? Nice, that's a lot of you. So by the way, I have some special Let's Encrypt stickers that we haven't had at the booth till this morning because I forgot them in my luggage. But if you wanna go down to the booth after this talk, you can get a Let's Encrypt sticker. So membership funds EFF and funds not only Let's Encrypt but our broader activism for the future of technology. And especially if you become a member that adds to the numbers that we can put to paper when we write our legislators and say, EFF is a membership-based organization with 25,000 plus members. ISRG is also an independent nonprofit and also has staff of its own, both operational and developers. And so you can give to ISRG on the website, let'sencrypt.org. The other thing ISRG can really use is sponsors. A lot of our money comes from large hosting companies and providers who look at their current bill for CA services and say, well, we could spend a fraction of that on a sponsorship for Let's Encrypt and use their certificates. So if you belong to an organization that has some money and you'd like to see them sponsor Let's Encrypt, definitely get in touch about that. And especially hosting provider integrations. I showed on that earlier graph where we saw a big spike from just one hosting provider integration. We've seen a number of others also and all of those have been extremely good for users in that sites are just easily available over HTTPS. So if you know someone at a hosting provider, if you work at a hosting provider, see if you can integrate Let's Encrypt for automatic free encryption for your end users. And it's a little off the bottom of the slide here, but CT implementations. So I've mentioned a few times just how key certificate transparency is to the health of the CA ecosystem. But CT itself is in its early days and it needs a bunch of things. So in particular, we have about one CT implementation, implementation of the log server. And we need at least one more to really feel confident that it's in the spec and get it standardized. And we also need more people deploying CT logs, which is a fairly big task. You need a pretty solid institution to back it up, run multiple data centers, make sure that it's gonna be reliable. What we've seen over the last few months is that some of the initial logs that were in CT have been disqualified at least from Google Chrome's program because they didn't meet the reliability requirements. So that leaves us in this awkward position where the only CT logs we have are run by Google. And we really want a lot more organizational diversity in this system that keeps tabs on the internet security. So if you feel like you can write a CT log or deploy a CT log instance, please do so. The world needs you. And so now I'd like to open it up for questions. The mic is up front. Please come up and speak into the mic. How you doing? Thank you for your work. I think we all appreciate it. Thank you. I'm wondering if you're anybody that could speak to the history of the CA system. And if you confirm a memory for my old days, that when Verisign and Thought were the only game in town, I feel like I have these memories of like you had to be listed in standards and pours just to get a certificate and... So yeah, so I wasn't there in the early days, but I've read up a little on the history. And certainly when the CA ecosystem was just getting started, validation standards were higher and based on real identities. And I think over time, competition has driven down the level of real world validation required for identities. But we've also seen an expansion in the use cases we want to... Type of sites we want to encrypt on the web. And so I think we do see a lot of division between people who feel like HTTPS certificates should reflect real identity and trustworthiness. Like this is a company and they're at this address and they aren't scammers. Versus people who see HTTPS as kind of a trusted introducer of domain names. So in other words, a certificate just says for this domain name, this is the key. And that's all it says. It doesn't vouch for the identity or trustworthiness of the person behind that site. So I'm in the latter camp and I think generally speaking, let's encrypt is in the latter camp, which is that CA certificates are for this trusted cryptographic binding as opposed to a trustworthiness measure. And do you think that the flaws in the current system are kind of rooted in its connection to old worlds institutions or I feel like the original assumption was the only use case was financial transactions? Right, I think the flaws are inherent in the structure of the system. PKI is really hard. We just have essentially three trust models. Tofu, trust on first use, which SSH uses. Web of trust, which PGP nominally uses, but most people just verify the keys of the people that are talking to. And kind of a hierarchical CA based system, which HTTPS uses. And each of them has major flaws. I don't think anybody has synthesized them all into something really good that has all the properties you want. But fundamentally, this type of hierarchical system has these types of problems, although we can patch some of them. Thank you. Thanks. Are you supporting wildcard certificates? We don't currently support wildcards. We might in the future. We're still working out on the ACME spec, what types of validations would have to be done. We actually recently landed a significant change to how the order of ACME validations to better accommodate both page CA's and wildcard assurances. Okay, thanks. How about TCP ink? Are you following that at all? Sorry, say it again. TCP ink, increased TCP security. So the idea these people have is every time you start up a TCP connection, you do an ephemeral Diffie-Hellman unauthenticated so that you get to encrypt you're vulnerable to a man in the middle attack, but the idea is that they want to drop this deep into the stack so the encryptor's happening automatically. Yeah, I definitely, I love the idea in principle. I think HTTPS is kind of becoming this huge, that probably one of the biggest crypto systems deployed on the planet, but that does mean we're neglecting other systems like SMTP still has horrible vulnerabilities and very often isn't encrypted. In terms of ephemeral non-authenticated encryption, I'm not sure it'll get us where we need to be. We've had similar discussions in the HTTPS realm with HTTB2 and we've had a lot of discussion about whether we can kind of automatically get everybody onto HTTPS if we accept unauthenticated self-signed certs. And personally, my feeling on the matter is that when the enemy is the ISP as we see with Verizon and Comcast, any protocol that's man in the middle bowl is gonna get man in the middle potentially all the time. We have like middle boxes and optimizers who want to cache stuff or who want to track you or sell ads and I think we will see that happen consistently to the point where it's just normal. So I think we definitely need authentication in our crypto. I was surprised to see StartCom on the list to people that's using Acme. As I remember they had their Start and Crypt project about a month ago with all of its fundamental architectural issues and then replacing versions without changing version numbers. Was it hard to convince them to use Acme or did public outcry change it? So this is the cool thing about public standards. As far as I know, nobody from Let's Encrypt actually talked to them or tried to sell them on Acme. There was some discussion on the public lists where other people were like, why didn't you just use Acme? And so they just announced it it was as much of a surprise to us as anyone else. But yeah, you mentioned their launch and they had some bugs with their validation. How do you proceed with all the stuff that doesn't like Let's Encrypt certificates? Like this phone or the proxy in the place where I work, stuff like that. So the question is how do you handle devices that don't trust Let's Encrypt? So I mentioned earlier, we did our best to be trusted as broadly as possible by getting a cross signature from the identity and trust route. But actually the landscape of who trusts what is really fragmented and complicated and different devices have different trust stores. And so you rarely see a CA that, in fact you probably will never find a CA that can offer 100% validation across all devices. Usually it's in the 99 plus range. Depending on your device, you may or may not have options. So for instance, older Android devices before, I think 2.2 don't trust Let's Encrypt. And I believe, I'd have to check my docs, but I believe that's actually because of the SHA1 to SHA2 transition. All right, so I might have time for one more question when I finish this one up if anyone has one. But essentially, you need to be able to update your software I think with Android in particular. This is this problem that cell carriers don't always offer OTA updates and manufacturers don't offer OTA updates. So we have a lot of old and secure phones and that plays into a lot of security elements besides just trusting Let's Encrypt. A lot of systems that, one of the big categories that we're lacking trust in is JavaScript, we're lacking trust, who are not trusted by is Java. And actually the root that Let's Encrypt is cross-signed by DST, DSTRootX3, which is a dentress root, was recently included in the most recent Java release. So I'm afraid I don't have any easy answers there except upgrade and if you can configure root stories, you can add DSTRoot and ISRGRootX1 to those root stores. Thank you all very much for coming. I appreciate your support. And come by the EFF booth on the vendor level.