WEBVTT 00:00.000 --> 00:14.680 Thanks everyone. Just in case people are curious, we do have like a democratic voting process 00:14.680 --> 00:21.560 for how we pick the talks that get accepted to the devrim, they get anonymized. So all 00:21.560 --> 00:26.360 of the names and organizations get removed from the proposals. So me being selected to 00:26.360 --> 00:30.640 talk was completely not to do with anything being a maintainer or anything. It's all 00:30.640 --> 00:35.960 we do a lot of stuff to make sure that we're not biasing who we pick to speak in the room. 00:35.960 --> 00:41.200 That being said, thank you for coming along to listen to me talk about attestations. Something 00:41.200 --> 00:47.840 which I'm sure other people in the room know way better than I do or at the very least 00:47.840 --> 00:52.720 can define better than I do and hopefully I will do justice on the definitions that I will 00:52.720 --> 00:58.960 bring. I want to particularly at the top of my talk, thank the Open Home Foundation, 00:58.960 --> 01:04.000 which I recently joined the team, the Design and Product team. They make home assistant 01:04.000 --> 01:10.080 and other smart home opens a smart home technology. And I look after the product design 01:10.080 --> 01:14.640 of something called Music Assistant in ESP home among other things. And I want to thank them 01:14.640 --> 01:19.640 for supporting me to be here actually to talk to you all about a previous project that I did 01:19.640 --> 01:28.160 at a previous organization. So this attestations work was part of my previous work at a design 01:28.160 --> 01:32.360 num profit called Super Bloom. You can find out more about that organization that I 01:32.360 --> 01:37.240 no longer work at Super Bloom.design. What we're going to talk about, we're going to talk 01:37.240 --> 01:41.400 about essentially the structure of this project. How did this project come to be? What happened 01:41.400 --> 01:47.960 during a typical kind of short term design project? I'll go over the timelines later. And 01:47.960 --> 01:54.760 also just some of the aspects of what we learned, how we approached UI and UX for this, what 01:54.760 --> 02:01.560 were the goals of the project and also some of the foundational aspects of open source transparency 02:01.560 --> 02:08.520 around doing a design project with the team. And I'll talk a little bit more about the team 02:08.520 --> 02:14.760 that we did this project with later. But we're going to talk a little bit about package registry 02:14.840 --> 02:21.560 pages as well. And what we learned about those more broadly when we were thinking and asking developers 02:22.120 --> 02:27.080 and people that look at open source packages on registry pages will learn a little bit more 02:27.080 --> 02:31.400 not just about the security of that supply chain. Those supply chains of open source packages. 02:31.400 --> 02:37.480 But also how they think and regard package registry pages more generally in this work. 02:38.120 --> 02:48.440 So what is actually I'd love to get an idea of the room, who has heard of the term attestation 02:48.440 --> 02:59.160 as far as like a cool. Okay. Cool. Who absolutely no idea ready to learn, ready to be 02:59.160 --> 03:04.600 interested, ready to nerd out about it, no idea. Okay, cool. So good, good amount. Awesome. 03:05.000 --> 03:11.000 Um, I may ask some of the people that raised our hands first if you would like to add anything 03:11.000 --> 03:16.360 or change anything about my definitions of attestations because you may have additional details or 03:16.360 --> 03:23.480 information that you want to offer. But an attestation, I took this definition from this year 03:23.480 --> 03:29.880 I'll hear from the docs at Docker. Um, so an attestation is a sign statement provides verify, 03:29.880 --> 03:36.680 verifiable information about an image around Docker or a package or some some kind of art of 03:36.680 --> 03:43.640 that. Um, as to how it was built, what's inside and what security checks is passed. 03:43.640 --> 03:49.000 So attestations are typically signed using six store tooling, such as co-sign or other things 03:49.000 --> 03:54.600 making them tamper, evident in cryptographic verifiable. Now I realized this is from one source. 03:54.600 --> 04:01.480 So I went to another source. Um, so again software attestations, they're a trust mechanism. 04:01.480 --> 04:06.840 Um, they allow a verifier a person that wants to consume the package to independently validate 04:06.840 --> 04:15.480 the integrity of those packages or something that's asserted by an authority. Um, which could be 04:15.560 --> 04:24.360 the vendor, so it could be the package registry, um, like brand or identity. Um, so these are 04:26.360 --> 04:34.120 also often automatically machine readable and what we wanted to explore in this attestations work 04:34.120 --> 04:39.640 that we were doing is when people, when we want people to better understand their stations, 04:39.640 --> 04:44.760 when they come to interrogate the information, not just rely on like the machine readable aspects of 04:45.640 --> 04:52.600 attestation information that kind of gets processed and sent back to them like how, how do humans, 04:52.600 --> 05:01.640 which developers are, how do humans understand the process of verifying an attestation, 05:01.640 --> 05:06.360 do they go through a process of verifying an attestation? What kind of steps did they go through 05:06.360 --> 05:11.880 to understand that and what makes sense to them? Um, so this is what we were at one of the 05:11.960 --> 05:18.040 challenges that we were trying to understand better in this project. Um, would anybody 05:18.920 --> 05:24.600 that racer hand about attestations like to add any essential, you think is essential information 05:24.600 --> 05:29.880 about attestations that you think is missed? Okay, but if people, um, might do you want it? 05:30.200 --> 05:33.000 More complicated than this thing. 05:33.800 --> 05:42.040 Might for the recording, might said it's more complicated than you think. Um, and if I can 05:42.040 --> 05:49.160 expand on that and attestation is not always just about verifying the supply chain security, 05:49.160 --> 05:54.680 it can be an attestation about any aspect of the package, is essentially a statement of verifier 05:54.760 --> 06:01.800 bonus. Um, so, I mean, the tricky thing here is we're trying to improve the UI UX, the 06:01.800 --> 06:08.920 usability of something that is an emergent understanding and emergent term and emergent topic, 06:08.920 --> 06:14.760 which is challenging in of itself, but also a fantastic time to be doing usability work. 06:15.480 --> 06:26.920 Um, so a little bit about why checking open source software package, um, package security matters. 06:27.960 --> 06:33.800 Something that I learned a lot about while I was working with the team, um, at Open SSF, the 06:33.800 --> 06:39.000 securing software repositories working group. Um, I learned about typoscotting, which is when a 06:39.000 --> 06:44.520 URL is very similar to a package URL, but it looks so similar to the, you can accidentally 06:44.840 --> 06:51.000 go ahead and, and use something, um, and that the build supply chain of dependencies, they could 06:51.000 --> 06:57.560 have a link that's also malicious or affected in some way. Um, you want to avoid, um, so understanding 06:57.560 --> 07:02.760 attestation, these are the things that why it matters to understand attestations as a person that's 07:02.760 --> 07:08.520 consuming open source packages. You want to avoid critical dependencies being compromised and ensure 07:08.600 --> 07:14.600 that pre-built packages are built using secure practices as well. Um, uh, I hope you like some 07:14.600 --> 07:18.680 of my illustrations actually all open source so you can use some of these illustrations afterwards. 07:18.680 --> 07:23.720 So, should you, should you want to, this is Inspector Package for those that watched the 07:23.720 --> 07:32.360 cartoon of Inspector Guy. Um, so without an attestation developers and users of open source 07:32.360 --> 07:35.560 software packages, because they're not always developers, you're not, it's not always developers 07:35.640 --> 07:40.040 that are consuming open source software packages. Sometimes it's researchers, somebody that might 07:40.040 --> 07:45.320 identify, say, a researcher in an institution, documentary, and any number of people that are 07:45.320 --> 07:51.720 working in open source can be consumers of open source software packages. Um, but they're forced, 07:51.720 --> 07:58.280 without attestations, they're forced to implicitly trust information that they can find around that 07:59.160 --> 08:07.080 package. Um, so without that, it's very, without an attestation, it's very difficult to validate, 08:07.720 --> 08:12.120 unless you know the process of validation and that's part of your role or part of what you do, 08:13.320 --> 08:19.720 in your day-to-day development work or your day-to-day work, to really be sure that this is safe. 08:19.720 --> 08:25.800 So, unless you're a person that's really like knows how to go in and double check the cryptographic 08:25.800 --> 08:31.560 signing of things, knowing that it kind of matches certain user names, or you have certain 08:31.560 --> 08:37.320 processes around that, you have to go on other information around packages to trust whether it 08:37.320 --> 08:48.200 is legitimate. So, this work was done with the securing software repositories working group, 08:48.200 --> 08:54.280 at the open SSF. This was paid for by the working group, which is actually all transparent and 08:54.360 --> 09:00.920 valuable on the various issues and the project board. So, you can see, you can see the person 09:00.920 --> 09:06.040 submitted the fund request, how much they submitted it for, and what they wanted to do around a UI 09:06.040 --> 09:15.720 UX and usability around these attestation issues. Um, but the things that the Open SSF 09:15.720 --> 09:21.240 securing software repositories working group wanted to look at is they, they wanted human 09:21.240 --> 09:27.640 consumers of attestations. Um, they, they knew that they contained a lot of information, 09:27.640 --> 09:33.160 which users were largely unfamiliar with, depending on your context, and they want to understand 09:33.160 --> 09:38.040 how useful our attestations, as well as how essential they are. So, there's an understanding that 09:38.040 --> 09:43.160 attestations are essential for this kind of verifyability, but how useful up really are they in a 09:43.160 --> 09:54.040 day-to-day life of somebody consuming Open SSF packages. Um, so what is the second one is 09:54.040 --> 10:00.920 what information is being shown to users, and what is the maybe minimum viable information to 10:00.920 --> 10:08.680 show to users to better meaningful, meaningfully communicate attestations, and why they're useful, 10:08.680 --> 10:14.280 and why they can be trusted, and why you can rely on them, and trustworthy. Um, and how can we 10:14.280 --> 10:18.760 start to build, and this was a large aspect of the work across the different package registry pages, 10:18.760 --> 10:25.720 and package registries, is how can we make UI and UX consistent across different package registry pages, 10:25.720 --> 10:34.120 different ecosystems of packages, because attestations and security information need to be identified 10:35.080 --> 10:40.440 kind of familiar across these ecosystems, so they can be trusted. So, if there's very different 10:40.440 --> 10:50.440 looking, seeming information, about security, and safety, on say, um, NPM versus say PIPI, 10:52.440 --> 10:57.480 how is any developer that might be working, or any person that's what consuming packages across 10:57.480 --> 11:02.360 these ecosystems? How are they using knowledge that they know from one ecosystem around like, 11:02.360 --> 11:06.440 okay, I'm looking for this information, I trust this information, oh, it suddenly looks really 11:06.440 --> 11:11.240 different over here for this other package registry page, is that the same, and there's spending 11:11.240 --> 11:17.880 extra time trying to understand whether the same information is as relevant, or even looking for the 11:17.880 --> 11:22.520 same information in different places, so how can we, I don't want to use the word standard eyes, 11:22.520 --> 11:29.320 but how can we make it easier to find that information, and commonly, and commonly, looked for 11:29.320 --> 11:34.840 places across, um, people that might be across the ecosystems. Um, if you want to find out more about 11:34.840 --> 11:39.320 the working group, there is the link to the, um, securing software, repository's working group, 11:39.320 --> 11:43.480 lovely folks, um, I hang out with them past this project, as well on the, on the, on the 11:43.480 --> 11:52.920 team course, lots of fun. Um, I want to talk a little bit about the user research approach, 11:52.920 --> 11:58.920 so we had a few designers on the team, and we started with the user research and usability 11:59.480 --> 12:06.280 testing and user testing. Um, to better understand what adaptations were in the context of open 12:06.280 --> 12:12.760 software, um, we actually also spent a good amount of time as designers trying to really understand 12:12.760 --> 12:18.600 what adaptations really were. We were like, okay, we need to make this, this, um, concept more 12:18.600 --> 12:24.200 understandable, really we need to understand it ourselves and the very least basic terms at first. 12:24.360 --> 12:31.960 Actually, this is, this is why one of the illustrations here is around apples. Um, um, like the 12:31.960 --> 12:39.880 concept of an attestation could be granny from granny's farm makes granny's apples, and then 12:39.880 --> 12:45.560 our package and send and then to a consumer often we think about attestations are the label of 12:45.560 --> 12:51.880 granny's apples. You know that it's come from granny's apples because it has a, an attested to label 12:51.960 --> 12:59.880 that this is granny's apples. Um, anyway. Um, so the user research, uh, so we, we formed some 12:59.880 --> 13:05.480 user personas, uh, of just to give us an understanding of who we wanted to talk to, give us a broad 13:05.480 --> 13:10.120 kind of idea of, okay, these are the kinds of people that we think might be consuming outfits or 13:10.120 --> 13:15.560 sat, uh, software packages, how can we segment them so that we can find enough of each kind of 13:15.640 --> 13:21.560 person to talk to about how they use the, the packages. Um, we then, after forming personas, 13:21.560 --> 13:27.560 we then, uh, conducted, uh, semi-structured, uh, interviews together and, and understanding of how 13:28.360 --> 13:37.160 really how security and safety and the liberty of a package was understood by people consuming them. 13:37.960 --> 13:44.680 Um, after the interview of insights, we then developed some visuals and first kind of concepts 13:44.680 --> 13:50.760 of how do we communicate attestations better on these package registry pages. We then tested those, 13:50.760 --> 13:56.440 again, with the same people and some new people, like, how does this improve how you understand these, 13:56.440 --> 14:03.800 these concepts in terms of attestations? Um, there was, uh, a lot of development, a developed, 14:04.440 --> 14:08.920 we developed a lot of support documentation because we found out throughout the process that, 14:09.000 --> 14:15.400 hey, documentation is really important and understandable, human understandable documentation is 14:15.400 --> 14:21.160 really important alongside anything that's like visually representative as well. And often a lot 14:21.160 --> 14:26.120 of what we were doing with the UI and UX was making sure that there were really clear links to 14:26.120 --> 14:33.480 relevant documentation next to key terms that might be new or might be evolving terms as well. 14:33.560 --> 14:38.920 And then we, um, built and published a style guide, a UI style guide of this is how we suggest 14:38.920 --> 14:45.480 this get implemented on specific package registry pages, but that could be extended, 14:45.480 --> 14:51.960 worked on, contributed to change and also rolled out to other, um, package registry 14:51.960 --> 14:57.480 ecosystem, too. How am I doing for time, gang, that is, ideally? 14:57.560 --> 15:11.000 Okay, I'm going to go faster. Um, so we focused on NPM, uh, PIPI and uh, Ruby Gems for this work, um, 15:12.040 --> 15:17.480 there's a variety of information on hair effects, um, just boiled down my longer list of what 15:17.480 --> 15:23.640 I would talk about. Um, the typically users when we did the user research here, they typically, 15:24.600 --> 15:31.080 spend more time, uh, trusting information like who are the maintainers, who are the maintainers 15:31.080 --> 15:39.640 affiliated with? Are those recognisable, um, avatars icons, um, and names? Also, how many times 15:39.640 --> 15:45.560 there's a package been downloaded and used? And it was a lot of this like, uh, web of trust information, 15:45.560 --> 15:49.880 or this, uh, like social proof information that a lot of people that were consuming packet, 15:49.880 --> 15:54.440 and consuming open source packages that were relying on. But there is a lot of information in here 15:54.440 --> 16:00.120 in these package registry pages, um, and actually a lot of people, uh, that we did the user testing 16:00.120 --> 16:05.880 with, we'll go straight to the repository and actually don't spend a lot of time interrogating 16:05.880 --> 16:11.880 the information on this page, uh, and it's validity. So here's just a bit more detail about how 16:11.880 --> 16:18.520 some of the, um, more detailed, uh, information about provenance, uh, provenance is quite 16:18.600 --> 16:22.120 closely linked at its stations, but if you ask me to define the difference between the two, 16:22.120 --> 16:25.800 I will not be able to do that for you, um, but somebody else will be able to do that. 16:26.840 --> 16:29.720 Um, the three personas that we had, and I'm not going to go into detail here, 16:29.720 --> 16:34.120 please take a picture if you're interested. We had a security architect. This is somebody that is 16:34.120 --> 16:40.920 really deep in the world of security at our stations and espons, read all the salsa, documentations, 16:40.920 --> 16:45.480 deep in it. For whatever reasons that may be, maybe they have a really complex ecosystem, 16:45.560 --> 16:49.320 maybe they're working on hardware that they actually can't get to, so they actually have to be 16:49.320 --> 16:53.560 really robust. So if it breaks, they actually can't physically get to that hardware, like stuff like 16:53.560 --> 16:58.840 them that might be in space, or in a very, like, in the desert, um, so it has to be really important. 16:58.840 --> 17:03.240 Um, and also people that are working on anything finance related, so some people that we talk 17:03.240 --> 17:08.920 to about Web3 crypto and working on wallet, they really had to be really careful about, um, the 17:08.920 --> 17:14.760 security of their packages. The pragmatic developer, um, there's more of these than there are 17:14.840 --> 17:20.200 security, our architects, but they, and they've heard of these terms, but they really struggle to 17:20.200 --> 17:24.360 define why it's important, it's actually not terribly important in their role unless they dedicate 17:24.360 --> 17:29.240 time to understanding attestations and espons and things like that. And then we've got an incidental 17:29.240 --> 17:35.160 consumer, there's lots more of these, um, and people, these are the people that go straight to the 17:35.160 --> 17:38.840 download when they see like a million downloads. They're like, great, a million downloads, this is 17:38.840 --> 17:42.760 safe, I'm going to download it, great. Um, they might not even be familiar with things like type of 17:42.760 --> 17:46.200 squatting, they're definitely not keeping up to date with all the things that are coming and, 17:46.200 --> 17:51.560 uh, emerging about security of open source software packages. These are some of the things we learned 17:51.560 --> 17:55.080 about user research, I'm going to pick them out so that it can go through the visuals a little bit more 17:55.080 --> 18:01.240 detail. Um, so yeah, all the personas factored in social proof, even the security architects 18:01.240 --> 18:06.760 were interested in social proof, but they also had detailed steps that they would go to to verify 18:06.760 --> 18:13.960 things like the char, um, cryptographic keys, the hashes, all of those things. Um, the thing that 18:13.960 --> 18:20.360 I found the most interesting and maybe the team also found the most interesting was the all of the 18:20.360 --> 18:26.120 people that we interviewed were fine with critical information about security being repeated multiple 18:26.120 --> 18:32.040 times. So there were a couple of designs that we tested that had, um, like hashes and shars, 18:32.120 --> 18:37.080 repeated numerous times. And that wasn't a deterrent. Like in design, we often think we don't 18:37.080 --> 18:41.480 want to ever repeat information because it becomes less, um, trustworthy if there's repeated 18:41.480 --> 18:46.920 information, like, oh, is this a error above? But with security information and these users, 18:46.920 --> 18:52.120 they said, oh, if something's repeated in multiple places, they definitely want me to see it, 18:52.120 --> 18:56.600 and they definitely want this to be important. So repeating information actually wasn't like 18:56.680 --> 19:01.800 didn't decrease trust, it increased, oh, I'm going to see this more readily. That's actually, 19:01.800 --> 19:06.440 it went against a lot of my background training as a designer to repeat information across different 19:06.440 --> 19:12.280 sections, um, but yeah, they, they, they, they wanted that. And yeah, there was a lot of emphasis 19:12.280 --> 19:19.640 as I'll go through on the visuals about, um, badges, symbols and icons, um, and then the key thing 19:19.640 --> 19:25.080 which I'll show in the visuals is a dedicated security page was really needed across package registry 19:25.320 --> 19:33.080 pages, um, for detailed information, um, about all these concepts, but also the quick reference 19:33.080 --> 19:38.360 in side bars. Um, so here's some of the first visual explorations where we were trying to 19:39.000 --> 19:45.080 boil down the concepts of a concept of an attestation to an icon. We came up with, uh, or like a symbol 19:45.080 --> 19:51.000 of some description, um, we were trying to combine, build with the bricks, package with the box 19:51.000 --> 19:56.840 and signing, um, as like a, as imagery and we kind, we got to the bottom one here as, as actually 19:56.840 --> 20:02.440 an icon for attestations that we ended up using in some of the final designs. Yeah, done. 20:04.440 --> 20:10.120 Okay, I'm going to go through some of these designs really quickly and then, uh, go for questions. 20:10.120 --> 20:15.720 Uh, here's some of the, um, different orientations of information and badges that we ended up 20:15.720 --> 20:21.080 going with for the visuals, uh, and some of the essential information that was tested, but needed to be 20:21.080 --> 20:25.880 in these UI UX improvements on the package registry pages. You can see things like swore syrup build 20:25.880 --> 20:31.880 conference and then the attestations. Um, the style guide is all open. You can find it out there, 20:33.160 --> 20:39.080 on the repository, uh, in PDF form, um, but we suggested three different approaches. We had a 20:39.080 --> 20:44.840 light medium and heavy. Heavy was the dedicated security page. Medium was some slightly bigger 20:45.000 --> 20:50.600 modules with more information and light was very small, um, box sections of the central 20:50.600 --> 20:56.920 information, um, which you can kind of see here is the heavy version where we have sidebar information 20:56.920 --> 21:03.160 and then a full security page, uh, uh, the example here being the MPM adding a security page in there. 21:05.000 --> 21:13.160 Um, one of the last things I'll say, the words confirmed and verified be so careful using 21:13.320 --> 21:19.160 this across your documentation. As soon as a user sees the words verified confirms, they're like 21:19.160 --> 21:25.080 great. This is safe, fantastic. I don't have to further interrogate it. Um, so we were, we had to be 21:25.080 --> 21:30.920 so careful with the language we were using in small UI modules around this because some words 21:30.920 --> 21:38.120 instantly made users go and download something. Uh, we, I also did a bit of work on inclusion and 21:38.120 --> 21:43.800 localization because things are different, different places like orientation of, uh, words and 21:43.800 --> 21:50.920 longer words and we need to consider those. Um, and the last thing I'll say is, we, this is essentially 21:50.920 --> 21:56.120 I can ball this down to one statement. We need to invite more designers into these complex open 21:56.120 --> 22:01.480 source software, like, uh, practices, security practices, because there's so much that we can do 22:01.480 --> 22:07.320 as designers to improve the usability, understandability and the UI UX of these kinds of things, 22:07.320 --> 22:13.240 like package registry pages. So I urge designers to really think, oh, S-bombs, do I really 22:13.240 --> 22:19.880 want to go there? Yes, you do, because S-bombs need your help, security of open source needs your 22:19.880 --> 22:26.120 help. So, and with that, I'll say, done. 22:27.000 --> 22:32.440 Thank you, Ariel. I think there will be a time for one of these questions. 22:34.440 --> 22:39.720 Do you have fun? Uh, yes. Thanks for helping out as of these, I mean, it's really important. 22:40.680 --> 22:47.080 The question is, did you think about the things that have not been attached to, 22:47.960 --> 22:52.680 because it's not that there's multiple things that have not been attached to, yeah. 22:53.640 --> 22:57.720 It's like, you know, it came too, and the most important thing for you is missing, 22:58.280 --> 23:03.800 whether you need a liking for that as well. So the question was around, is there a design template 23:03.800 --> 23:08.040 and have we considered when there is no attestation for something? So what's the design? 23:08.040 --> 23:12.840 We did designs for when there is an attestation, but what should, um, what should pages, 23:12.840 --> 23:18.200 what should information look like when there is, uh, absent of attestations? So the projects 23:18.760 --> 23:24.280 wasn't scoped to include that, though the conversation did move to that shortly after the project 23:24.280 --> 23:29.720 wrapped up, actually, or was wrapping up the design phase. And yeah, I actually think that what I'd 23:29.720 --> 23:35.480 love design contributors to do with this work, um, now that it's kind of out of the paid, um, 23:35.480 --> 23:41.320 paid project side of things, is okay. So what do we need to show when there is no attestation? 23:41.320 --> 23:45.560 Do we need to show no attestation? What does that mean when a user sees, oh, there's no 23:45.560 --> 23:50.920 attestation for this, but also what does that mean for the community building, the understanding 23:50.920 --> 23:59.720 around attestations? Um, because does that lower or affect the trust in attestations, or the 23:59.720 --> 24:04.360 trust in the pages? So I think the balance there needs to not just be, oh, this is what the UI 24:04.360 --> 24:09.080 would look like if there's an empty stay. It doesn't, I think it, empty state would be bad. 24:09.080 --> 24:14.760 We need to really consider what's showing information around security and the absence of that 24:14.760 --> 24:17.960 security detail, does to users understanding.