All right, sounds like we're live. Well, fantastic. So I guess good afternoon, everyone. My name is Brittany Isennis and my partner over here. Michael Grouch, hi everyone. So, and today we're gonna be talking a little bit about open source with the security mindset. We want to kind of share our experiences as well as our partnership on what we do in the realm of open source and security. So before we get started into that, we're gonna do a little bit about talking about ourselves. So kind of my path to getting to open source. So as I mentioned, my name is Brittany Isennis. I'm a program manager within the program source open, the open source program office at Comcast. And my main focus is basically on delivery of open source software as well as community building. My journey to open source is relatively a pretty interesting one. I did not initially start off thinking that this was my path. I thought my path was going to be education. And so a fun fact about me is that I'm a lifetime certified K through sixth grade elementary teacher as well as a N through 12th grade special educator. I graduated from Temple University in 2011 and I taught fourth and fifth grade in like kind of the deeper part of the city of Philadelphia. So it was really, it was a really interesting experience and really powerful for me and my students. And together we moved mountains, little kids and I moved mountains. It was really, really, really cool. But when I was working in the charter school and realizing there was such a need for technology for these children to become successful. I wanted them to be ahead of the curve. I wanted them to experience everything as well as just get just really well versed in everything because that's kind of your way out and really where the future is going. So I became the lead technology trainer at the school and then realized that there's other doors that can be opened up in technology and education. So I moved into educational technology and I worked with superintendents and teachers all across the country helping them utilize this online reading program, which was absolutely fantastic. And we saw lots of great results in children who were reading at or above their grade level and you could tell within one year, it was fantastic. And so being completely honest, that was a beautiful, wonderful experience but it was really far away from the city. So I'm currently living in Philadelphia and traffic is not great. It's not fun at all. And commuting an hour and a half every day just wasn't doing it for me. I was like, I can't, I can't do this anymore. So I applied at Comcast and lo and behold, working at Comcast led me to the team that I'm with now which is really, really fantastic. And now I'm an open source program manager. And so with that, I will pass that over to Mike and he can share a little bit more about himself. Sure, thanks, Brittany. So my name is Mike LaCroche. So I'm a security automation engineer for Comcast. So my path here is a little different than Brittany's is I'm sure. I got my master's in computer science. I actually was in a starter company for about eight or nine years. And we worked on hosted voice for IP. So being a startup, I wore many hats. So it was implementation, it was support, it was programming, it was automation, that sort of thing. I did that for about eight years, went to Comcast actually as a contractor, as a voice for IP, IMS tester went back to the startup to come manager and kind of create processes around everything, do some more automation, that sort of thing as an implementation engineer manager. And now I'm in Comcast. I've been here for about four years. I had a lot of different roles. I was a documentation specialist, then migrated to a network engineer. And then with that, I did some more automation engineering and now I work with the security team, mostly focused on security pentesting and also anything related to automation tasks and network tasks. So the open source team, the Bernie takes care of, she needs someone's security and being that I fit that role in the fact that there's a lot of need for coding, a lot of need for networking. And I've been through that, lower cycle process, I kind of fit in really well there. So yeah, that's it for me. So something that Jeff's excellent, thank you. So something that we're going to chat about next is open source keeps developers happy. It just, it really does. It's paramount to work together with internal and external technologists for quality, well-rounded projects. We know open source practice and methodologies bring people together. We were speaking with Angela Brown a little bit before this session started. And she mentioned that there are 4,000 people at this conference from over 100 countries. And that is so amazing. Where else would we have that sort of opportunity to connect with people from all over the world on such a different varying experienced level than without open source? And that's just something that's been exciting. Meeting people from all over the world working on our projects. How fun was it to mail out swag to someone in Singapore when they were working on some initiative for us for Hacktoberfest? And that was really cool. And then we've talked to so many companies that really want to bring open source into their space just because they know that technologists are happy generally when they work with it. And then it really does attract young talent. And then open source as well, if I'm a technologist and I'm working on an initiative that I know already exists, why is my company making me reinvent the wheel and having me just redevelop something that already happens that costs so much time. It's so expensive and it causes burnout. And so it's just, it's really, really, really important to keep that mindset and keep that focus that we open source keeps people happy at least for myself, I can say that it does. So something else that's pretty cool is for those of you that don't know, Comcast, we have a pretty strong open source initiative. We're getting there. Well, I think I'm so proud of where we're going and I'm so excited that we're there. We have roughly 200 projects in our public repo which is Comcast.github.io. Some of these projects that you may be familiar with would be a Trickster. We have Vinyl DNS, a brand new project that we just came out with that's built completely on the Rust language is Capsule, Guber Healthy. I highly recommend checking them out on Comcast.github.io. And a little history about our office is Comcast started consuming open source in 2006. And then they heavily as a company started contributing very, very, started consuming it in 2006 contributing back heavily in 2010. And then come 2011, we launched our first projects with RDK and CDN. And then throughout 2013 to 16, Apache Traffic Control has been formed and now that's incubated in the Apache Software Foundation. And it brings us to 2017 when the team really came together. The team is comprised of our leader, Nithya Ruff whom many of you know as the chairwoman of the board at the Linux Foundation. Sheila Sabi, she's a big community advocate and community manager on our team who also spoke at OSNA yesterday on our ambassador program. And I really hope that you were all able to check that out. We have Pristakare and Ananya Malaku are fearless leaders when it comes to compliance because we all know that is tough stuff. We need to have their sharp, they're helpful, they're fantastic. And it's really taught me a lot as well on the side of compliance. And then Carl Ivey, he just leads our development team. And so that, and then myself came onto the team in 2019. So I've been there for a year now. It's a pretty rock and roll group. I really, I really am proud of the work that we do. So please check out Comcast.github.io. And, you know, since we have this solid focus group, we've been working really, really hard that we open source quality projects. We wanna work with people from all over the world. We wanna develop and contribute back to as many open source projects as we see today. And we wanna make sure that we can support our team. So a little bit more for those not familiar. So we support the roughly 7,000 technologists. It's pretty cool that our current Ospo, we support about 7,000 technologists, which is fantastic. Our offices, we have offices in Austin, we have offices in Philadelphia, Sunnyvale, Denver. We also have a really large, wonderful office in Chennai, India. It's fantastic. And we support technologists. You know, I've talked to technologists all over the world, Italy, London, South America. And so we support people from all down there. So kind of getting back to what we were talking about is how the Ospo and security partners together. And so this is something that, you know, Mike and I have worked together on I don't know how many companies do have this type of partnership within the security team and their open source program office. I'm gonna share a little bit about what we do here. So as I mentioned, the partnership's very strong. We have a level of transparency, which is so fantastic because we wanna make sure that we, our developers have clear guidelines in which they should be following for successful projects. And Mike will definitely be talking about these later. You know, we have governance where we've established the best practices of developers can consistently remain protected. Mike and I, with the communication, it's always been clear throughout the entire open source request approval process. Not only do we talk to each other throughout, but we also keep all the developers on the same page, which then enables the trust within the partnership and then it makes and aids into that low barrier for entry that technologists and developers can get into when they want to start doing open source within the company. And expectations, going back to keeping developers happy, Mike and I just within ourselves, just through working together, have clear processes in which we select time frames throughout the entire approval process. And these honestly were just established by Mike and I, you know, talking to one another about how we both work and what are some of the best practices that would make us both successful and not stressed out because who wants to be stressed out? I don't, I don't want that. So going into some more of the things that we do within open source at Comcast, is we have this group called the Open Source Advisory Council and this group was formed back in 2013 because once, you know, the company realized, hey, we're consuming and contributing, we gotta just kind of see what we can do to make sure that we have a process to this so that way we can keep track of everything. And so this group is a very focused group that determines which projects go to open source as well as which contributions, bug fixes and so on. And as of right now, we have a really strong approval rating. I think we're at 95 to 98% every year. Anyone that wants to contribute back to open source can be approved. We ensure that the developers and technologists are successful and they make the contributions by we provide the guardrails where necessary. And we'll definitely talk about that later. We're gonna feel free to add any questions. We're gonna get deep into a question time. I have a feeling. So please feel free to add any questions into the chat. And then once the presentation is over, Mike and I will get to them and make sure that everyone gets an answer. So we have the oaths. So we lovingly call them the OSAC, the Open Source Advisory Council. They're comprised of members of the security team, legal team, we have our high level engineers that focus on all of the technical side of things. And then also the open source program office. So a little bit more about it. So on average, we have roughly 150 to 180 open source contribution requests from our internal technologists going out into the public. And so they flow through this council annually. And so kind of a high level of what I do and what Mike does is I love being the developer advocate. I wanna align best practices and then also have things, making sure that the technologists are following into the compliance space because we want to protect them. But I also triage out all next steps. If I look at contribution, I'm like, okay, well we should talk to this group of folks together. Let's see what we can do. So, and then we work together for the council success. That's kind of what we do. And then on the security side, which Michael be talking about later on in the presentation, he does scans and he also provides advice to the maintainers for best practices. So we know the word council is, it's very intimidating. It sounds, you know, because we're coming at it from a larger corporation perspective. You think council, you're like, oh, I don't know. This seems like if I do something here, it's gonna be very formal. I don't know if I should even try. It's not. We communicate that through the develop the technologists. We want them to know that it's not hard. Please reach out to us. Please, we want to break down the barriers for you. We want to promote your projects. We want to walk you through the process. Don't be scared of a word. You know, it's technology. We'll get you there. And then also another level of balancing, which is fun in its own way, is how we keep the company happy.  So with that being said, I think that's a wonderful caveat to open up to have Mike come on board and talk a little bit about what he does on the open source advisory console. So my role, like I said, ACOMPGAS is an automation engineer and security pentester. So my initial goal with the open source team is to really go through all the code that they put up there, talk to the contributors, you know, kind of see what the purpose is, just kind of talk out how they got to the different ways you got to it, and I'll kind of include to this later on and take it from two different angles, which I will also talk about later. You know, support the developers of the best practices that we need to put stuff in repos that are safe, and also the best advice to get them for making things secure and also supporting the company, you know, make sure that we at ACOMPGAS aren't giving ourselves away with a different security vulnerabilities in public GitHub, for example, and kind of give advice to the open source team as to how to not do that. So I'll give to Brittany. Honestly, you know, why does any of this matter? You know, we've been talking a lot about why it's important to have partnership and security, but why does this matter? We always think that, yeah, it's common sense. We know what we should do, but in all reality, obviously, you know, we live in a world where chaos exists, it does, and open source code, it can really, really, really invite dangers that you just wouldn't even think about can happen. And so Mike's gonna go back and he's gonna share a little bit about what sorts of things he's seen and what sorts of things you can do about it. Great, thank you, Brittany. So we kind of see it through two different lenses. You know, we see through the eyes of the open source community and through the eyes of our employer. This is ACOMPGAS. So, you know, there's kind of a level of trust with the open source community that, you know, we are gonna contribute code that's not going to leak information or have viruses or, you know, leave the person open for any attacks. So we obviously want to be a good place to go for, for a good, useful, secure code. And, you know, we, ACOMPGAS obviously benefit from open source and want to do our best to give our projects to open source to people to, you know, develop and, you know, use for whatever they want and kind of increase the life cycle that way. And then the other side is to protect our IP, our intellectual property, you know. We want to scrub the code of anything that's going to expose our company to hackers. You know, nothing's worse than having your name on the front street of the Wall Street Journal, you know, like a lot of companies have in the last five, six years. I'm sure everyone has seen. So, the first thing I want to talk about is the trust factor. So we want to be a place for developers and go to get open source contact. Like I alluded to before, you know, we want to get back to the community and have people improving the code, the life cycle of the projects. And obviously any breach of trust looks bad for your company. It doesn't really matter what the source is, you know. If any issues come or are tied back to bad code, it's going to come back to us. And we don't want to be, you know, in that position where we say, hey, we put this bad code on the internet for you guys to use. And it came back that, you know, something malicious happened to it. I put down there as an example, the malicious Python library. So for those of you unfamiliar, Python has built-in libraries that you use, you know, for third party applications, you can use a port or people upload that you can use. There's been a couple of times where people had imported and got through the cracks, some third party applications that you can use and that end up being malicious. So one example, there was this date time util, most times you can just use this to set the time or whatever.  So obviously, you know, the reason I bring this up is that if we didn't catch this, you know, this is something that we use in our code, you know, the blame would be on us because we're the ones who published it. So we obviously want to make sure that those are clear of those kind of issues. And hackers be hacking. So GitHub has extremely powerful search capabilities. You can search by regular expressions across all different repositories. You can search by passwords, you can search by SSH keys, you know, there's really no end there. So, you know, anything that we can do to do the same kind of searching that hackers do that it will obviously save us. And also there is a well crafted automation code that you can use to scour through GitHub, looking for examples. You know, GitHub has API access, so it's really easy to look for certain things in GitHub that, and you can do it in a matter of minutes, essentially, so. And exposures can be hiding anywhere, which will bring me to my next slide, different hacking attack points. Very simple secrets, using passwords. You surprise how many people have used any passwords, just statically set it into their code. These are kind of low hanging fruits. Open, code, and back doors, these are mostly for network or web server projects. These are things that, hey, if you are, if we're developing a web server, we're developing multi-media across platforms, what ports are they going across? Is there any way that anyone can infiltrate that in some sense? Prior to having information, very simple and stuff about the company, whether it be IP addresses, whether it be backend servers, that sort of thing. OS calls, you know, a lot of times, well, it's a lot easier to do a bash call and just find a shell strip and just put that in an OS call, but those can be exploited in a lot of ways. So we try to take that into consideration and make sure that any OS call is safe or they're not used at all. SQL injections, you know, we want to make sure that, you know, database input is being sanitized, that people can't inject SQL queries and any kind of database queries to get either put malicious information or get a malicious information. Compile code, there's a lot of times where developers will either use third party or compile their own code. You don't really know what's in there because you just call it in their function. We try to decompile it to make sure that there's nothing in there because there's a lot of very third party, you know, free to use compiler apps out there that can easily do that. And hopefully there's no kind of information that'll keep us accountable to any issues. Comments or comments or comments. There are, you know, obviously, depending on language, there's many ways to make comments and then make sure that, you know, a lot of times our programmers or contributors use useful things in comments to help people who are reading the code but they also use things that can be, for example, used for social engineering. You know, talk to this person about this, you know, using any kind of information, we want to kind of keep that away. And Git history, you know, Git has, obviously, we want to scour through the history of all your Git commits.  So we make sure that that is not existing. So what can we do about it? You know, are we victims of room faith? Should we just hope for the best or are we just holding on to your life for this sad person in this thick, which is actually me. This is something that me and Brittany kind of joked about but this is me climbing Kilimanjaro and there's actually a ledger, so don't worry, I didn't actually fall or hold on to your life. So code review is kind of an art in my opinion. You know, there's a lot of ways you can do it. You know, you can scour the code but that would be a full-time job. Obviously for a thousand line commit, you know, that's not a big deal but you know, for a, you know, something that has multiple contributors and it has multiple folder structures, you're gonna need some kind of tool or something else to help you out. And you know, we want to assess intelligibly and not haphazardly. Knowing folder structures, knowing frameworks will help you look for issues in a much easier process. And knowing your audience, knowing your language.  And also, you know, if you're working with containers, working with macro windows, so forth and so on. Tools can be your best friends, you know, they, there's a lot of third-party and free tools that you can use to help you look at your GitHub code or look at anything that's being contributed and find a lot of the low-hanging fruits and any other issues there. It could also be your enemy because you're gonna have a lot of false positives too so you gotta make sure that everything's kind of skewed out in that way. But in most cases, it's your friend. So next is skill sets, code, what to really know.  You know, for example, you know, anything that's during your network project, you wanna check server settings, you wanna check firewall, you wanna check open ports, IP addresses, et cetera. And different frameworks, you know, know where secrets are held for each framework because each, you know, obviously each language, each framework have different places to put, you know, the database access wouldn't any kind of a stitch keys, that sort of thing. Get ignore in the likes. You know, obviously in getting more pages you put in there all the folders and all the files you wanna be used.  We wanna make sure that those are being safe on our end that people can't access those through the code itself and second of all languages. Knowing multiple languages, you know, each one has a runway point. We wanna make sure that there is, and there's places of issue high for all of them. And knowing your audience, you know, who's ingesting this, you know, knowing they use it for in what scenario will open up ideas how it could be used maliciously. Next is what tools we use. So, you know, there are dozens of tools on the market, you know, I, there's no one size fits all and, you know, I implore you do your own researches on this because, you know, one tool for one person is not gonna be the same for others because everyone has code uses in different ways. But for the lazy, this is what we use. You know, for pattern recognition, we use Truffle Hawk was a very low maintenance kind of thing that's based on regular expressions that we could put, you know, it will find Azure keys, AWS keys, you know, passwords all in your GitHub repo is all in the history. So anything you're gonna make public wanna make sure that those are obviously scripted out. Decompiler is obviously that is language dependent. You know, we use on compile for Python, we use JDGY for Java, et cetera. All those are pretty open source and you can find those pretty quickly. Code injection and kind of a catch all, we use check marks and there's a couple others that are out there on the market. And what this does, it actually kind of takes your repo and it will take inputs for different ways and go through the functions, how they get to the other end. So it would say, hey, this could be, this object isn't serialized, this is open to people, you know, in any way maliciously you can use any inputs. So a really good tool. So next is communications, how to put it all together. So it starts before they write their first piece of code. You know, we at Comcast kind of hammer home the importance of security. We have a lot of security in place, you know, a lot of different processes along the way. So, you know, obviously it's the big initiative for IR and as you can, I'm sure you know, you know, security is the big initiative for a lot of the major companies based on a lot of things that's happened and, you know, we're making sure that we wanna be secure as a company. So we hammer that home and it kind of helps the coder to be able to write with a security mindset and like also putting yourself in the mind of the contributor, you know, find out why they did what they did. So if they're, if they're making something, you know, why they coded it this way, you know, one of the biggest things obviously that I mentioned was OS calls, you know, is that the best way to write this? You know, is there a better way to do it? Have the coder kind of explained it and kind of figure out whether they, if that's the way they did it because they were lazy or they're, you know, when they went through all the options it was the fastest, it was the best way to do it, that sort of thing. And then last is communication, process and remediation, you know, with the open source advisory council, it's been great that we had like kind of a solid process involved. You know, we have a website with steps involved. So there's constant communication with the group of you, constant communication with OSAP team so that we can work with them to resolve any issues, you know, quickly as possible. And I'm gonna hand it off to Brenda now. All right. Well, thank you so much, Mike. That was very well said. Yeah, I really liked that a lot, very good information. So, you know, like I mentioned multiple times, we want to get best practices for maintainers. So to really have that home, a lot of these do sound like common sense, but common sense only works when you practice, you know, you need to practice, you need to practice what you preach, you need to make sure that you're like, oh, yes, I always check in on my project regularly.  You know, always research and resolve vulnerabilities. That's one of the things that I have to work on is vulnerabilities come flying in and I'm, you know, have to not contact all the maintainers and well, it would be good if, you know, always having a maintainer being like, yes, we're on it, we're on it, we're gonna resolve it. You know, another thing that's great as a maintainer is be transparent. You know, everyone wants to be able to understand exactly why you're working on what you're doing and why you're doing the way that you communicate. So always, always be transparent and then also create a little barrier for entry. You know, for somebody like myself, I'm very new to open source. I'm very new to developing and technology as a whole. And so it's something I would like to get more so into. Even if it's documentation changes within a README, you know, I want to have something that's a low barrier for entry that doesn't intimidate me. And then something else that's so important and this is something I've been hammering home so much lately is just a very clear contributing guide, a very clear README that's so important for just the low barrier for entry and it's inviting. Oh, okay, so let me read this contributing guide. Oh, this makes sense for me. Okay, well, what is this contributing guide saying potentially about vulnerabilities, what to do, what not to do, that's fantastic. And then contact info. I have tried to reach out to so many technologists over the past year of my life and I can't find them because there is no contact information and going down the deep dives, Twitter, GitHub, LinkedIn, who knows where I find some of these team members. It would just be always have contact info in your projects. And then also most importantly, I feel is just be kind. You know, you want people to be excited to contribute to their project or somebody, you know, like myself, it would be a very new to open source. I, if you're kind to them, that's pretty awesome because they're like, oh, this project was great. I'm gonna go tell all my friends. I'm in this particular community. I want to be more involved with this. So I think that that's just one of my, that's one of my favorite, that's like my motto in life. So be nice, that's not that hard. It really isn't. And then of course, we all are experiencing this right now. This is fine. Everything's fine. No, it's not. We understand that it's not, but we have to avoid burnout, you know, in the technological space, we have to avoid burnout. And we find that many maintainers create a project to set it to forget it or they are burnt out and they don't want to work on it anymore. And what I've talked to many technologists about is that they are feeling very stressed and very tired at the moment. And so ways to mitigate that is to reach out to your community, find a trusted committer, find a team member that can be your partner in, you know, poll requests, reviews, things like that, somebody that's really excited, like let's say you were very kind to someone and they were grateful and appreciative and then you trust them, you have rapport, ask them to be your trusted committer. And we all know if a person's completely exhausted and burnt out, that it's super easy for mistakes to occur. Like right now I'm in the process of moving across states, so apologies if I'm a little out of sorts and leaving in two days. So, you know, if you're exhausted, it's easy for mistakes to occur. So, and then another big thing too is if you no longer care about the project, find a new maintainer, reach out to your community and see if anybody in your trusted sphere wants to take the helm. And then also the best practice is to archive it and make it read only and then once again, leave your contact info. It makes the world so much better. So please, if you have credit index out there and you don't have your contact information on it, please do me a favor, can you do that for us? And then that's, I mean, essentially team, that's our presentation. We're at the question and answer part of it. You know, we have one question that's in which is fantastic. Someone wrote in, how does one of our technologists become part of the current like Comcast open source advisory council? And well, essentially you would talk to me and then we have, you know, Mike and I talk about a partnership. We worked together at the beginning of the year. I think that was the beginning of the year or last year. I don't remember, my time has no relevance. I don't remember. Yeah, exactly. That's it. It was like mid year last year, yeah. Mid year last year. So Mike and I worked together and be like, okay, well, Mike, for example, is like the only one on the security side that's doing all of this work. Well, I didn't want Mike to get burnt out and say like, this is fine. So I was like, well, Mike, let's put a set of, what would you call them like checklists or requirement pieces? Like if somebody wants to get involved from your team, we would just bring them on, chat with them, see their experience against Mike's experience and see what Mike says would be great. And that's kind of how it is. Essentially, like I mentioned, word council is not meant to be intimidating. It's just asked. I'm a very approachable person. Mike's a very approachable person. So you could just ask us, it's fine. And then best way to get ahold of us, I would say for after this presentation, you could follow me on Twitter. I put it shamelessly at the bottom, just every single one of my slides. Apologies there. But please, please, please shoot us an email. At least I mentioned, I'm gonna be in and out of this lack throughout the rest of this event, which is unfortunate, because I really wanna get to know so many of you. But please just shoot me an email because my life is a little bonkers right now. And I think Mike, probably. Yep. I think we have one more question there for me. Yeah. Oh, do you have any tips for the folks who don't like leaving their contact info because of security concerns? Well, I mean, what do you think? Just make another Gmail address and just check it every once in a while. That's something you could do, Mike. I don't know, that's what I would think. Yeah, I'm sorry. Yeah. Wait, sorry, I'm sorry. Oh, I'm down. Yeah, I mean, yeah, sorry. Yeah, we missed one above there. But anyway, just wish you don't leave their contact info because of security. I mean, distribution groups kinda help too. A lot of times we, for at least as I'm concerning, we make distribution groups for all of our projects, even if I'm the single person so that we can kind of flow people in and out of it so we can leave the email address there and it will go to certain people and that will kind of be a line of barrier between your contact information and also putting stuff online essentially. And then there's one regarding, yeah, how can you make the upstream open source projects most secure? I'm guessing that's meaning that anything that's already been published, is that kind of what that is? You know, we actually do open scans on all of our things. You know, we were basically, as security team, trying to hack before the hackers hack, you know? So, you know, everything that I said here is something you can do on your open source, you know, our public open source GitHub, if that's so. And when it comes to getting back, you know, we, because of, you know, Bernie said, with that contact information, you know, if we find anything, we gotta alert them right away to make those changes. And then, yeah, yes, we contribute back to security fixes when we do season. And we try to erase the GitHub history, you know, a lot of the reasons you could say, oh, I found this fix, commit the new one. Well, it's still in history, it's still there. So there's different tools actually, kind of, get rid of a lot of that information so that your Git history does not include any of the malicious information that we have on there, or any like IP information. Then we have another question. I've experienced a time, and Mike, this is definitely something that I would, I kind of want to lean on you. Have you experienced a time where an open source project didn't meet security standards? If so, did you remove it and how did you deal with it? Yeah, so most of the times when we started out with a repo, it's private, and we're allowed in there. So there's that level of security, which is good, that, you know, if anyone does make mistakes, you know, it's only within our realm. There's rarely a time where you can, you know, have someone just take down an entire repo, but there are a lot of times where there are issues. A lot of things, you know, the things we see the most are like SSH keys, and passwords, you know, those are the two-hand inputs, or, you know, there might be IP addresses that are statically set in there. And a lot of them that go back to the distributor, just say, like, hey, we found this. These are the steps you need to remove it or replace them, and that sort of thing. So, you know, the most important thing, you know, Bernie will, you know, sure agree with, is that, you know, don't make things public unless you're actually sure that you don't have this information on there. Yeah, I think that's really about it. So unless there's another question wants to come in, I think, I just, I personally like, I just want to thank everyone for attending. This was fantastic. This was the first talk I've ever given an external event. So it's really, it's really cool. And that was, that was my cat that just jumped behind me. She's somewhere back there. But she's, yeah, she's all over the place. But, so I just, yeah, I want to thank everybody for attending, and then especially a big thank you to you, Mike, for wanting to be on this wacky conference journey in time of COVID. Right, yeah, that's great, thank you. Yeah, thank you all so very much. And to everyone that hung out, great. Judith's an email, loved to chat, tell jokes, whatever. It's all good. All right, I think that's about it. Great. Thanks, Jeff, high fives. Yeah, thanks Jeff.   Yeah, I don't know. I don't know.


You know when you're outdoors gaming, it's cold, you've got some hot tea, and you need power. Well, I've got the test rack for you.  Now, the Vita 550 is a portable power solution from GrowWatts, and I wanna give them a big shout out for sponsoring this video, and also sending us the Vita 550 to fully check out. I really like this device, and it's not just because this is a sponsored video. It's the fact that the portability and the functionality built into the Vita 550 takes it to the very next level. Now, there are a ton of power solutions out there that you can buy, but what I like from GrowWatts is that they've brought in all their experience about 11 years in, of course, the power solution game, and they've put into a device that is portable, easy to move around, and also brings a lot of great things. So, let's go back to me outdoors gaming, right? I'm sitting out there, and I've got the Vita 550 set next to my Xbox Series S, which I have, of course, a portable screen. I can power that on. I can also go ahead and charge my devices with the wireless charging solution on the very top. I can also move it around anywhere I want to because of how light and easy it is. Tossing it up in the air is not a problem, but please do not do that, but it's easy to take around with you. Now, as we come back into the house here, I want to show you what you can actually do with this device. Connect to my PlayStation, my Xbox, my TV, to these three AC ports. There's also a car charging port as well, and then you do have a couple more ports, USB ports in general, giving you 11 ports in total. Now, the fact that it has 11 ports is nice, but the fact that you can isolate and control those ports is even more impressive. There are physical buttons to turn them on and off. You do have an LED screen that gives you a lot of information there, and of course, that wireless charging at the very top. Now, the Vita 550 is not just a power solution. It's one that charges really, really fast. So say, for instance, you want to go camping or you've got some work to do outdoors and you need portable power and you don't have it charged up. You can, of course, charge it through three ways. You can charge it either solar, direct via AC. Of course, you can use a car charging port as well, which is all on the left-hand side of the device. Now, the charging speeds are really impressive. We've got 1.6 hours of fast charging here, meaning you fully charge this device in 1.6 hours at 500 watts, and I timed it from about 42%, and you can see the results yourself. It was really impressive. Other portable charging solutions do not charge this fast. They may take about five or six hours. This slow charging on the Vita 550 is 3.5 hours while charging with a solar panel, a 240 watt solar panel, will give you about 2.5 hours of charging time. So again, doesn't matter what solution you use, it charges really fast, and that's pretty cool. Now, the other thing I do like about this device is that it's got an app, and you're going, okay, why should I care about an app? So I go into the app, here I can connect to my Vita 550, I can connect via Bluetooth and Wi-Fi. Wi-Fi, you ask, well, because I could have it as a power solution for a specific device at home, and remotely I could turn it on and off, and I can also see what's going on. The other thing too, it gives you more information on what the Vita 550 is doing. So you've got, of course, input, showing you how much power that's coming in, and then you've got output. Of course, I've got a ton of things plugged in, you can see the wattage output, you can see the temperature it's running at, you can see how much battery life you have, how long that will last as well. You can also isolate those various ports, so you've got the three AC ports, you can turn off remotely, as well as also the USB power ports which you can turn off remotely as well. You can turn on the built-in lights into this device. So this thing is multifunctional, and this is a smart portable power charging solution. It doesn't have to be, but I like the fact that they made it that way. And the best thing of all is that it can still power all my devices that I wanted. In this case, as a gamer, I'm testing it out, of course, with the Xbox, the PlayStation, to see how that performs, and it does a great job. For anyone else, whatever you wanna do, power-wise, whether it's outdoors, whether it's just in your backyard, you can do with the Vito 550, and it does a fantastic job. So with a price point of 529, you think, well, this is a pretty good offering. Well, Grow What is giving you a special offer at 429. Plus, I do have a discount code that gives you $30 off to bring that price even lower, making it one of the most affordable and honestly the best portable solutions in its category. So if you're someone who loves to hike, camp, and you just want power on the go, the Grow What 550 is a really good solution, especially with 528 watt-hours of capacity, this will do the job for you. Or like me, you can just game outside with it. So this is Thunder E. Sane, thank you. Definitely check out the link down below to pick up yours, and always enjoy your entertainment.


So at this time when museums and the archives are reaching capacity and heritage sector in the UK and also throughout Europe are looking at way of prioritising funds from archaeological excavation for retention and disposal, I think that it's important to consider those projects which are making the most out of the archive to produce new methods of analysis and also to enhance our understanding of the past. And as the Archaeological Science Manager, HES, I have a particular interest in those projects that are making use of science, that have a science focus and utilise the material that is often the first to be considered for disposal, that I quite liked what you were talking about earlier. So before giving a couple of examples of projects, I wanted to start off by getting the background of some of the strategies, procedures and legislation which guides how archaeological assemblages in Scotland are reported and how they're allocated to museums and then how they're used in research. I feel that if we're to reflect on the future and what we do, we really need to fully understand the current challenges in each of the countries. There's a lot of similarities, so that makes it a lot easier, but hopefully I'll help it, we can be more collaborative in the overcoming these. So the first is Scotland's Archaeology Strategy. It should be noted that this is a strategy for the whole of the archaeology sector in Scotland, it's not, it doesn't belong to Historic Environment Scotland. Museums and archives form a big part of this and it's developed and we actually looked to the overarching Museum Together Scotland Research Strategies and as well as other government ones. The vision, so what we want from the strategy is a Scotland where archaeology is for everyone, that Scotland is a place where the study of the past offers opportunities for us now and in the future to discover, care for, protect and enjoy our rich and diverse heritage. What it does is it focuses on five key aims, so the first one is Delivery and Archaeology which aims to broaden and deepen the impact and public benefit of archaeology within and beyond Scotland, so it's putting Scotland into an international context. Aim two is Enhancing Understanding which aims to increase knowledge and understanding interpretation of the past and that's where our research framework sits. Aim three, which is an important one here and I'm going to come back to it, this aims to ensure that the management of material evidence for the human past is cared for by society and managed sustainably for present and future generations. This is how and this is in this area where we are engaging with museums the most. Aim four, Encouraging Graser Engagement, aims to enable and encourage engagement with our past through creative and collaborative working, active involvement, learning for all ages and enhanced archaeological presentation. And aim five, which I'm also going to come back to very very briefly, aims to ensure that people, so everybody has the opportunities to acquire and use archaeological skills that they need or desire and those skills provide the underpinning for innovation and the understanding, interrogation and learning and also funding of archaeology. Now, if you want any more have a look at the strategy, there's lots of examples of projects, some of which are utilizing archives and things like that. Okay, so just to come back very briefly to aim three, as I mentioned the museums sector are quite key within this and one of the main points made within the delivery plan and I'll put it all up there but you can get it online, is to increase access to collections to allow for learning, research, creativity and also participation. This one's been a bit slow to start but we just recently had a workshop which was led by the National Museums of Scotland in association with Museum Gallery Scotland, so they go for arching bodies. We're really identified a number of challenges in the future of museums including capacity, so that's storage staff, we have an increasing number of archaeology collections that are looked after by non-archaeology curators. That in itself isn't an issue but what is an issue is if they don't have access to the right information to be able to make the most of their collections. Another thing retention disposal came up and also our traditional process which I'll explain in a minute and you'll see that we're slightly behind England from the first one and so we're just going to let England make all the huge mistakes that cost them lots of money and then we won't meet them. I think we've got very different systems as you'll see so we just have to do what we're doing individually and we're actually learning huge amounts from all the work that's going on. So innovation and skills, this one touches upon archives with a particular focus on science, so science and innovation in science is one of the things that we're concentrating on for the next 10 years and what this aim does is it focuses on collaboration between different parts of the sector in order to share information and form creative projects and what it does is it emphasizes the utilization of archives for educational workshops and we've been running a lot of science workshops and we will continue to do that and also prioritizing unpublished assemblies when we're talking to students. So we have five science PhD students that we're currently funding and several of them have access to older excavations and older archives where this struggle is where that information has been thrown out because somebody hasn't quite understood so a lot of what was said earlier really does work true for me as well. So Treasure Trove Scotland, this is a system in which excavated assemblages and transfines are reported to and allocated to museums and we don't have the Treasure Act in 1996 in Scotland. Instead we have the Scots law really and all finds in Scotland actually become property of crime. This law extends to all types of object so not just precious metals and it can be anything like stone and pottery as long as it's not modern. I didn't want to change the side while you've taken a photo sorry. So is the role of Treasure Trove to ensure that all these objects are protected for national benefit and it's the Treasure Trove unit who's responsible for the daily running of the system. Now our Treasure Trove unit is two people in the cup of the whole of Scotland so you can see why we're flagging up looking at and looking at how we do that. So after the artifacts are reported to Treasure Trove it's the Scottish finds allocation panel who meet. It comprises archaeologists and artifact specialists and museum specialists and they decide to which museum the assemblage will be allocated. Now museums are told in advance, accredited museums are told in advance and they can fit into the material. However these are my big fog bears. There are several caskeries of material which are not included and human remains. So in England there's a revered policy. We don't have one in Scotland so human remains are not routinely revered after excavation because human remains can't be owned by anybody and it means that they can't be put through Treasure Trove process. Usually what happens is the finds any finds associated to a human remains will go through the Treasure Trove process and then the human remains will go with the finds when the finds are allocated. That causes us problems when we have human remains found in isolation. So we have a bigger road in coastlines in Scotland and if we have big up a dead person and they've got no finds then technically that person has no home so we're having to deal with that. What we do have is the treatment of human remains policy which is used as the guideline for them and my bug there that anybody knows me has to sit and listen to me rant about this is environmental human remains. Also not covered by Treasure Trove. There's a massive increase in the last 10 years of the amounts of samples because people are a bit scared and they just kind of sampled everything and so we have a huge number of unprocessed soil samples that are finding their way into museum archives and unfortunately that tends to be the first thing that people tend to throw away. They're just like why have I got a tonne of soil in my store and they get thrown away and that's actually one of the issues for one of the PhDs that I supervise. She doesn't have access to that material anymore because it's been thrown away. There's no national best practice guidance for these at the moment. I'm starting that process of writing those so if anybody's got any ideas I would be all ears. So just to give you a couple of examples before I finish up. Die to the Dark Ages PhD by the fantastic Ursula Cesare at the University of Aberdeen. I don't know if anybody heard her talk yesterday but she's fab. What she's doing is using human remains from archives and museums throughout Scotland to reconstruct diet in individuals from the late Iron Age through to the medieval period. Her main questions are looking at the differences between diet in urban and rural settlement during a time of significant urbanization so big changes going on in Scotland. To ensure that her study is truly representative she's needed to access huge numbers of individuals all throughout Scotland and as well as more recent excavations. If we had a reburial policy she wouldn't have that material there. So that's something I always worry that we're just going to throw out all the soil samples and just reburial the humans. What I'm trying to show is that it's not as easy as that. What she is doing is using methodologies that were not available and not even that refined even 10 or 15 years ago and so access to that collection is key in order to make her study useful representative and also fairly innovative. And I've been a bit naughty because this is my project. I worked on this project before I worked for HGS but it is another HGS funded project. What it's doing is it's bringing into publication 1950s excavation of an Iron Age wheelhouse in the Western Isles when they were building a rocket range in the area. The site was excavated as part of one of the largest rescue excavations that went on in Scotland and about six weeks they surveyed and excavated over 30 sites to throw out the US. Very little surviving archive. This is probably it. We have this here and that's when we realised we had more than one wheelhouse which we didn't know we had but what you can see as well is it was very complex. We had quite a lot of stratigraphy in there as well. And it was in this project that the survival of the soil samples from 1952 and the fauna remains so that your unworked animal bone that was key in unlocking the stratigraphy of the site for us. What we did was we knew when the finds were dug up because they were very meticulous in writing this and we also knew how they dug in the grid squares so what we did was we created a Harris matrix of the finds and then dated through those as much as we can in order to create a stratigraphy. Because we knew when things were dated we assumed that it must either be at the same level or the level above in our matrix and we fed those into a Bayesian model and it worked surprisingly we didn't expect it to. And what it showed us was the starting end of occupation but also multiple phases and what appears to now be quite a large Iron Age village which is stuck under the Mecula airport. So why that's significant is that these types of structures are often published on the road in isolation. I have a single wheelhouse and what we're now starting to do is to look at community which is part of new kind of theoretical ways of interpreting and we actually don't have that many wheelhouses dated in Scotland either. There's really few. Kate McDonald did a PhD a few years ago and had to give up with wheelhouses because we just don't have it. So even though it was in 1952 and there wasn't a lot of information we're getting a huge amount out of it now. We're working with the local people in Benbecula in order to link pre-start community with current community which is working really well and if we didn't have those remains they'd be thrown out because we date to 1952 we wouldn't do that. So just to opportunities and challenges I think there's quite a lot of opportunities. We're continually developing new methodologies for the way that we interpret results, how we analyze material. We also have new techniques hacking all the time. I was in the sedimentary DNA session and they were getting sedimentary DNA out of 10 year old samples that have been stored at room temperature so every day so yeah we need to see things up every day we're getting new things happening. Interpretation within new theoretical frameworks that have been published in 1952 we wouldn't have had that community aspect we wouldn't have been discussing that with the local communities now and so again we need that in consideration and we really are getting a much more enhanced understanding of our past. For the challenges I think our biggest challenge is how we loop how we prevent the loss of information it's not simple there's no one size will fit all for any of this and I'm sure we will make mistakes as we go on that journey. So what we need to do is to think about the projects that already exist and what they're doing and where new innovation is coming around especially in archaeological science because I think that's really important. I mentioned best practice guidelines but we're quite good in Scotland at being quite connected and trying to do the same thing we have a single national strategy and we have a single region a single framework for for research and when we're doing individual ones to the region so I'm definitely going to do something to work on and promoting access if people don't know they're there how are they going to go and look at the staff so you mentioned earlier Duncan about having a time limit well it won't work if nobody knows the staff's there so we really need to think about promoting access at HHS we're really lucky because we actually have a national archive and for paper digital that doesn't tend to go with the funds so and you can get it online can more if you want to have a look it's spectacular and the good thing about that is I can help with that because it's part of the same organization so you can be quite connected in that um just to let you know that I'm not just here stopping we put our money where our math is so this is our archaeology program where we look at and where we fund archaeological projects and everything that I've mentioned is everything that we're taken into consideration when we look at projects especially archive projects especially looking at finds the spoils and retention and the how we deal with the archive of itself every I like you mentioned um seeing archival is the end of the of the project and for us that wasn't always the way that we thought the publication was said to be the end and now we've got um archives floating around that we're now having to track down and get them out we're not paid for one where somebody had the excavator died years and years ago and so I think that that is another key thing is making sure the end of the process is the archiving we can't see it as any other um we also need to look beyond the shiny golden treasure um and I would go and look at like soil samples but filling anybody else's so and I think we need to take into consideration the eco effects when we have these conversations about retention and disposal so thank you very much for putting out with my voice