and letting people get here. So thanks for being on time. I'm sure some more people will arrive soon. But we've just had a good talk this morning which has told us that we're in a war and that we have to make sure that all our information stays out there and stays free. I guess once you have all that free information, it wants to form its own social networks. We need ways of sorting it out, letting it join groups with other like-minded information. I think Paul's going to give us a way of trying to classify that information and sort it and store it and things like that. So I'd like to ask you all to welcome Paul Harvey. Hello. Yes, well, this talk is a little bit of exaggeration. It's just to get you here. Accidental wealth is really what I'm talking about accidental wealth. It's really trying to create workflows that are useful in everyday work. And we accidentally or at least without any extra effort by the user, they've come up with a workflow in a system that allows them to collate and store their information in reusable ways. So where I work at the Center for Plant Biodiversity Research, research is often geneticist, taxonomist, natural life science people. And although the young ones these days do have very good computing skills, there's been a long tradition of really overusing Microsoft Excel. I just have to say it that there are way too many Excel spreadsheets out there, a lot of copy paste madness, and a lot of time wasted trying to merge data, check data. So we've been trying to leverage FOSWIKI. Has anybody heard of FOSWIKI before? Before this talk? Oh, good, that's excellent. How about T-WIKI? Yep, a few more. Well, FOSWIKI is written in Perl, although Olo disagrees with that. It says it's written in JavaScript, but we check in a lot of jQuery libraries and things like that. It also said it's worth nearly $51 million, but that's a very interesting claim. At two years and three months old, we've come quite a long way. We've had over 10,000 check-ins, nearly 400 a month. There's anywhere between 10 and 22 contributors every month. And I managed to abuse Olo to make a very flattering graph here, where FOSWIKI's coming out on top of Drupal and Semitic MIDIWiki. Of course, that's a bit of a lie. That's just the core. So if we count contributions, yeah, FOSWIKI's down the bottom there. So it's not a huge project, but it is still significant, in my opinion. Drupal completely dwarfs everything, as you can see. So why didn't we go with Drupal? And in actual fact, I should mention that some of the work I'm about to describe today, there's been many, many attempts over the last decades to try and rationalize biodiversity systems. So biodiversity is a mess when it comes to computer science. Not that I'm doing anything really tricky here. That could be really called computer science. But just trying to structure and collect information in a rational manner, that is useful to scientists without getting in their way too much. So FOSWIKI has a very open community. It was important for us that we chose a platform that we could contribute to and keep our plug-ins alive. Like, is our project ends? Because most of these things are project-based. They have fixed lifetimes. And people are very terrified of putting their data into a system that's going to fail or end. So we don't want to create any data jails. So investing in an open-source platform helps us do that. FOSWIKI has many plug-ins. We have the old TV project. And FOSWIKI, of course, one of the common complaints is that it's hard to search for things. And we've funded somebody, or at least convinced them to open-source a plug-in that they had written, which was a solar integration. Anybody heard of solar? Yep, loosing, natural language searching, fuzzy matching, that sort of stuff. The interesting thing about solar is that the integration for FOSWIKI also does attachments and Word documents and Excel files of all things. So if you are plonking them and using the FOSWIKI as a glorified file system, then you'll still be able to find those things. FOSWIKI also has a superbly modular architecture. Now, I wouldn't say that the code is brilliant, but the APIs are generally pretty flexible. They've been well thought ahead. And being Perl in such an old Perl project, there's some ugly code, but there's some pretty good code in there, too. This is contrasting to TikiWiki, which is another platform that we considered, among other things. So apart from Drupal and TikiWiki and TWIKI and FOSWIKI, we also considered Google Wave. I actually wrote a couple of robots for Google Wave. That was a very interesting experiment that I couldn't get anyone to use. There was also XWIKI, which is a giant Java project. And as no one in my team is really strong in Java, we didn't go very far with that. So we kept coming back to FOSWIKI because it's very easy to hack being Perl. It's designed for hackers by hackers. That does show up a little bit in user interface, or I should say a lot, actually. But with proper training, and there are some plug-ins that make the default FOSWIKI a lot easier to use. One of them being that EditContrib plug-in, which allows users to interact or set preferences on their topics a lot more easily. And we do have WozzyWig. So actually, I personally use WozzyWig quite a bit, not when I'm writing FOSWIKI code, like macro expressions and building reports. But it's very useful to paste from rich text sources. It can filter a bit preserved formatting to a certain extent, so you can keep tables and then things from Word documents. And FOSWIKI has a tremendous, weird aptitude, which I haven't quite found in other platforms. So when I say, whip it up to Tude, I can put something together really, really quickly. Once you know the patterns, so just as an example, I'll show you something that a user asked me, I need to make a resource directory. They had a resource directory. It was in Excel. They emailed it about to each other all the time. They don't know what's changed. People accidentally paste over other people's cells. What sort of junk? I could have said, use Google Docs. But that wouldn't be using the Wiki, would it? No, actually, there is a great sense of wanting to preserve ownership of your information. So owning your data is a big deal in science and in other enterprises for a second. And this is just a very simple data forms app. And when we say data forms app in FOSWIKI, this is a sort of a data form as a schema in a sense. Well, a data form is actually, technically speaking, a special type of topic. And it just holds a Wiki markup table. And all it does is describes a set of fields in terms of a key value type schema. So I like to think of the pages on the Wiki. We call them topics in FOSWIKI, by the way, as objects. And if you attach a schema to an object, it suddenly has these fields that you can populate. So these are actually all pages. So we can filter these. I'm going to search for now, so I can filter these down. So instead of a whole bunch of articles, like on Wikipedia, you could make, or sorry, media Wiki. You could make a whole bunch of these articles, an article per row. That's what we're usually working to, is every row in a table that comes in, we turn that into a topic. But as they're all each individual pages, they have their own history. They can be separately tagged. We can add multimedia to them. And we can represent each topic in a view in different ways. So if I edit this now, the schema that's defined for these pages have types. So you can define the possible values. This is a multi-value field. And you can just keep adding to them and then save. I won't do that because it'll make people upset. But admittedly, it's kind of hard for users to take advantage of data forms. It requires a lot of reading the manual, as they say. So this is what we talk about when we mention structured data. So if I was to ask you, why do you think people find Excel hard to let go of? Can you involve? Sorry? Yep. Commonality familiarity. And they think they know how it works. Yeah. It is definitely ownership. Ownership is what we found was the number one thing. Because we have many database systems developed over the years where we're trying to take people away from using Excel. They need a collaborative environment. So we're trying to make them collaborate. We're trying to make the information that they create reusable so that it's not a throwaway thing. And it's frustrating watching people spend so much time fiddling and merging data and keeping things up to date by hand. It should be something that computers can do for them if only they would use the database that we give them. But the problem is they want to present the data in their own way. They want their columns, their headings. They want to create their own reports. They don't want to have to go through a database administrator. And if you don't have the resources to have the appropriate quantity of people or people with sufficient time and patience to sit down with users and work with them every day, they feel that they lose control of their data. If they keep it in their spreadsheet, yes, it wastes a lot of time. But at least it's their time. And it's up to them, really. So what are the risks? If we give them the perfect system, well, sometimes new systems are created. And they are technically better. But as with any project-based activity, people come and go. Money comes and goes. The systems can be left neglected for years and years before the next round of funding comes through or it breaks completely. So people have experience with this where they've used a system for a while and it becomes just another jail for their data and they find it very difficult to mobilize their data in and out. The other problem is it can be quite expensive to add flexibility and richness to the, and when I say richness, I typically mean multimedia. So things we take for granted on a wiki, like a commenting system or image galleries and that type of thing. And incidentally, we also have a web-dav interface, which makes that quite easy to work with. It can be that the new way doesn't actually meet their needs. So has anybody heard of Google data wiki? No, it was a Google lab thing. It fascinates me because I read the project description and it was basically describing FOSWIKI. Of course, they're describing their own product that they're making. But they actually do a better job of describing FOSWIKI than FOSWIKI does itself. Possibly because FOSWIKI is a thing that really has evolved. It never started off with all of these features and goals in mind. But as all the Pearlhackers slowly formulated this thing, this pattern has emerged where we can really make some really powerful stuff. So as I said, it's a key value-based schema. Unfortunately, there's only one schema at a time on a topic, although there are workarounds to that, but they're very geeky. Model view control separation, absolutely not. That would make things difficult for a user anyway. So there is a bit of tie in there with some of the peculiar ways that we mix up the view logic and the data storage. Plugins may extend the topic object with additional matter. And I've used this quite effectively at work. Some of the interesting things we're doing is we have these web services. So people are often copy-pasting fields from external data sources. And I really just want to link to them and really just pull in that information and cache it onto the page and make it so that they don't have to maintain that stuff that they've been copy-pasting. So we can build links in. So I've got some plugins that register some new metadata types that augment their pages with external information. So we can search, sort, and report on metadata on topics. There is a little bit of normalization possible. And I do this a little bit. But if you really go overboard and make third normal form structures, it becomes not only really, really slow, but because FOSPIC is really designed as more of a key value type query language, it has its own query language. It lends itself more to the denormalized sort of way of thinking. And so this is really a no SQL approach before it was called no SQL. So this has been, before that fad, sort of took off, you know, FOSPIC has been working with this kind of data model. And in doing so, it actually has a store API, which allows us to drop in. So at the moment, it's actually flat text files. There's no database. Even though we're trying to use FOSPIC Wiki as a database, FOSPIC itself out of the box does not use a database. It uses text files and grep. And that sounds terrifying and hopelessly unscalable. But if you do actually keep all your data in RAM, it works surprisingly well. We've found that on virtual machines, the limit is about, well, now virtual machines anyway. Once you get to over 4,000 topics in a web, it starts to get slow. And if you have lots of concurrent users using application in a web of that size, so when I say web, I mean like a namespace in other things, like workspaces in Confluence. So I don't know if you can see that. But so the anatomy of a topic is really what I wanted to show. When I say key value pairs and not necessarily key value as such, it's more of a, we have sort of root element metadata types. And each root element can have a collection of key value pairs, which probably makes no sense this time. But you just have to remember that we have different types of metadata. So we have user-defined metadata. We have plugin-defined metadata. And some metadata types, such as the authoring information, are native to FOSPIC Wiki itself. So they're always there out of the box. And this little diagram over here is talking about an instance of a topic that uses a data form. You can implement a view using a view template. And all of these things are pages. And that's really a fascinating thing about FOSPIC is that developing these applications and dashboards, you're just editing Wiki topics. You've got your version control. You can see who's done what on the application code as well. So I very rarely have to write much Perl when I'm augmenting the Wiki. And just it really is great, because I'm the only system administrator. Well, I share some responsibilities with some of my colleagues. But it's really liberating for me, as well as them, that they can actually write their own dashboards and reports without me having to be involved. So this is one report for a project we're working with, which I'll talk about a bit later. And I didn't have any hand in this at all. I did a little bit of debugging. So this is showing a report of some topics that we're calling terms. There's a hierarchy there. And these are all just built using standard macros, standard query expressions. It's certainly taken them probably after a year of usage. You can do this sort of stuff. But if it's something that they're using every day, their reporting aspect is quite powerful for them. And it means I don't have to do much. Well, I have to do less anyway. So the weaknesses are your typical data entry person or person authoring content doesn't really even know what a schema is or what a key value thing is. So they think in terms of headings and bullets, things that they've put into a Word document, obviously they're more advanced users, well, when I say more advanced. So I'm talking about we often have students contributing to data entry efforts as well as researchers. And volunteers, in fact. So we have community people coming in and trying to give us data about natural science stuff. So data forms are simple, but you still have to read the manual. A lot of reading manual, if you want to do fancy queries in macros, we can do more. So now you're just going to talk about where I work a little bit. That's the team. Sadly, most of these people have day jobs. So three of us work full time for hubris until very recent. We've got two extra. So we are the bioinformatics team within TRIN, something called the Taxonomic Research Information Network. And the goal of TRIN is to accelerate the capture and delivery of biodiversity data. And when it comes to taxonomists, they're sort of becoming less and less of them.  So one of the things that we're trying to do with TRIN. So apart from FOSWIKI, we do use other platforms. We use Ruby on Rails project called MX. We use some proprietary software that makes building identification keys a lot easier. We could have done all these things in FOSWIKI, but really it's all about the right tool for the job. So it's not that we're obsessed with FOSWIKI. It is difficult to find another open source WIKI type system that has all this type of WIKI pattern stuff to it. The other thing we do at hubris is we're trying to build a sort of information best practice guide for marking up a particular type of data set. And this is taxon profiles. So these are like species pages, fact sheets. The type of information you might see in a field guide. If you don't know what a field guide is, that's something you take into the field with you too. So if you see a critter, you can look it up and see what it is. So the thing about standards are that there's just so many of them. And when it comes to biodiversity informatics, it's no exception. So it's very daunting for your average database administrator, for someone who's not even using a WIKI, so maybe they are using a corporate database at a museum or a specimen collection. If they want to expose the data and make it reusable, even to start with, they have to know how to export the data in a standards compliant way. Because there are so many standards, it's difficult to know the best way to do that. So part of our project is to come up with some guidelines for that. So we're trying to avoid creating any new vocabularies, too many new terms or any new schemers. It's been necessary in a few spots, but we've done a pretty good job of mashing some stuff up. I'll show you that in a second. So we have this problem where we're trying to integrate many, many systems. And because there's only been three of us for a while now, we've sort of tried to consolidate on just FOSWIKI as a sort of portal for doing that. There are, of course, lots of legacy systems. We have electronic lab book things. We have obscure specimen tracking systems. And we have tax on profiles. So we're trying to only build missing bits and otherwise work on links between systems. So rather than reinvent the world, even if we could do it in FOSWIKI, we're just trying to link stuff together. So this was what I was talking before about copy-paste madness. We have these people building species lists, checklists. And they're going to a database. They know the species name, but then they want all the other information associated with that name. It's classification, the authority who determined it, maybe some identification characters that comes with it. And they're sort of decorating that information with more information of their own. So that might be genetic sequences, GATC letters, that sort of stuff. And we don't want them to waste time having to keep that in sync. And it is a big problem because taxonomy changes. Sometimes, in this case here, I've got one highlighted right here. At the beginning of the year, they're looking at this species here, rhizophora, goniculator, and several months later, it was shifted entirely to a different order. And that's cool if you know about it. But when you've got a list of 1,000 species, you then, at the end of a data collection effort, have to go through one by one for each one of the 1,000 species and look up, is it still a current name? Is it still the current classification? Is the authority that I've used correct or even spelt correctly? So luckily for us, this isn't true of all disciplines, but luckily for us for plants and now for animals as well to a certain extent, plants are pretty robust. We have these web services that we can look up the name of the tax on and get all of that metadata about it, including its classification. Now, I'm using this word tax on profiles a lot, and it's occurred to me I haven't really explained what that is. So here's an example of one. Here's another example. So this is really just whenever you've got a species and any information about it. Some people have a more strict definition, but we've had to look at so many. It's sort of become all very blurry. So distribution maps, that sort of thing. There's one on the wiki. So we've come up with all these terms and there's really quite a lot of them. So you've got this sort of tag cloud soup of words. And people mean different things by the same word. People mean the same thing by different words. And it's really, really difficult when you've got these different tax on profile data sets and you want to present a unified view. So say you've got a collection of species that came from a project from somebody who was documenting the plants in northern Queensland and somebody is doing a mangrove's project over on the east coast of some island somewhere. They're talking about critters and species that are common between both sites, but they're talking about them with different terminology. They're using profiles that are structured slightly differently. And it's hard to present a unified view of this data. And to make it, it would be very, very valuable to present this data in a way that can be reused. So this is the problem. So this is just two different profiles. And as you can see, the mappings are not clear. There's no one-to-one mapping. The mappings are fuzzy where there are mappings. So our solution is to use something that we've called Wallace Core. This is named after, well, inspired by the Darwin Core standard. I don't suppose anybody here has heard of Darwin Core. Yep, one person. That's one more than I thought. So Wallace Core isn't necessarily inventing a whole bunch of new terminology or an ontology. We're using an evidence-based methodical procedure. So we've collected over 1,200 terms from about 60, I think, taxon profiles. And we've come up with a method where we're documenting the meaning and mapping of all of the elements in a taxon profile, trying to use an evidence-based approach to build a reasonably standard. There's no such thing as a standard, but we're just trying to aim for 80% to 90% coverage for the terms that you would expect to be able to find in a profile. And we're calling that Wallace Core. So this is what we're calling a term. This is all pretty boring stuff, but the term has a label and author. We have a basis term. So we try to never create a term out of thin air. It has to come from at least a profile that we've seen or an existing data standard that we've looked at. So we're really trying hard not to invent too much stuff from thin air. So the benefits of this approach is that, as I was saying, we can repurpose data a lot more easily. And I'll just show you in a second an example of that. It makes curating the data easily a lot more easier. So when we have tax on profiles encoded in the wiki using the Wallace Core format, we're hoping that we avoid the data jail problem to a certain extent, because if you can export the profile information that we've built up in the wiki and take that somewhere else, that's really been the whole goal of our project. So we've actually had users creating their own terms. We have a tax on profile builder toolkit, which I've worked very hard to try to have ready for release for this conference, but didn't quite get there. So hopefully in the next week or two, that'll be available on foswiki.org slash extensions. And this is a thing that allows users to create their own heading. So the thing is that they don't want to be told exactly the terminology that they have to use, because if we do that, they won't use it. This is going to be just like every other system that was inflexible that they had to use before, and they'd rather go back to Word. But in order to make that workable, when they create their own term for their own profiles, we have to be able to map it back to Wallace Core. So the idea is that we have all these mappings back to Wallace Core. So in Wallace Core, we have this thing called distribution. And in this profile over here, they've called it geographical range and dispersal. In this one here, they've called it distribution. And in Plinium Core, I believe that is, they've called it endemicity. I'm just a programmer. I'm not sure if I said that right. And in Weeds, they call it distribution. So this is an example of a Wallace Core term that has mappings to various other profiles. So this system basically forces the user to not only create a heading, but we like to present them as headings because that's just the easiest thing that they can cling on to. The easiest metaphor. But in actual fact, they are their own topic. So the heading in their namespace is their own topic. And the workflow forces them to set up a meaning. It's a semantic definition that allows our knowledge experts, or should I say Wallace Core mappers, our mapping team, to be able to go to a user heading that somebody has created without any intervention from the wiki team to go back and sort of tidy up after them and sort of determine what they mean when they say this heading here. Because the workflow forces them to define what they mean by that content holder. And here's an example of a term being entered. That's a very boring one. We have this thing called happiness index as well. Happiness index is how happy we are, basically, with the definition. There's also a happiness index for terms. So I can sort our terms here by happiness index. Let's see how happy we are in general. So there's a few 7s there. It's on a scale of 1 to 9. So our first 20 results out of 1,142 are all above 5. But it drops off after that, I can tell you. So we're still working through those. So have I convinced anyone that a wiki could be a database? Yeah? Maybe? Yes. And we're actually working on a... We're trying to adapt this system for a laboratory workflow that is doing Acacia DNA. So it's not been entirely smooth. We're funding a MongoDB backend to make that data more scalable. So we're still making the primary data the text file because we trust text files, and that's actually one of the selling points of PhosWiki is that if it doesn't matter how hard it crashes, you've still got the text files to resort back to. Whereas even a good SQL database can crash nastily. And when it comes to MongoDB, well, there was a talk the other day about how hard that can crash. I don't know if you saw that one. So it's really just a case. But it allows us to really index the data and the great thing about PhosWiki is with these store implementations, it's transparent to the user. So the user doesn't see any change. So if we swap out the regex search with the MongoDB one, nothing changes for them, it just becomes faster. And with the modularity of PhosWiki, it's sort of hard to describe. Like in other platforms, you don't have such a... If you're going to do hardcore queries, it just exposes you to the underlying SQL database. In PhosWiki, because there is no SQL database, it has its own query language. And a recent feature that was implemented was actually the ability to query all versions of all topics. So we can now search for finding all versions of a topic that ever had a field that contained this, or that ever had a state set to something or other, or ever had this list of contributors to a topic. So we're trying to improve the dashboards that we have so that a manager can look at the laboratory workflow and look at the things that a certain staff member has worked on in the last week, for example. And you would do that with a versions query. So the latest version might not have their authorship on it, but it will have at some point in the past. And the interesting thing about that feature was that I intended to implement it, but I made the proposal and somebody else did it for me. So that's the beauty of open source. I have to do less. Somebody else can fix the bugs sometimes. So are there any questions? MongoDB just released a new version like yesterday or something. That's supposed to make it a little bit more resilient if it crashes. They've implemented a write-ahead log. I don't know, just thought you might want to know. Oh, okay. I didn't follow that. Just yesterday. Cool. Sorry, just another question. One of the problems we've come into with trying to do data sharing issues in science is that people sort of get very, I don't want to share it with them. I'd like to see your data, but I don't really want to go the other way. Do you have a lot of problems with this or do you don't have that problem at all? Well, I have to admit that the projects I'm working with are funded across institutions. So there isn't such a secret obsession, although we do have some other stuff that is quite private. We also can implement hierarchical access controls. So you can pick and choose how you want to expose your data to a quite fine detail. A quick question on a slightly long question. With the data attributes, is there some form of the Wiki markup that lets you put them into each page so the page becomes a template for the metadata? So you want to pre-populate some of the metadata? No, no. I mean, just when you look at the Wiki page, rather than looking at it as a form, is it possible to have it as a HTML markup where there's particular Wiki tags that you use to display the specific fields? So it looks more like some kind of web page rather than form. So pre-formatted. Yes. So are you familiar with semantic media Wiki? Not really, no. Not really? So it sounds to me you're describing semantic media Wiki has these things called semantic links. So you can arbitrarily put any ad hoc information into the page that can create metadata in a way that's unstructured or is not bound to a schema. So is this sort of what you're talking about? No, what I'm asking is, you know when you clicked on a particular page's... So this is a row and a table here. Come on, Silstra. When you were showing a page's field value, as a form that you selected that one, some of the multi-select, some of the text fields, can you, like, yeah, in that, but then can you say you want to put, I don't know, say the acronym field inside the text, on the text tab? Is it a markup to say put the text, the acronym field here? Put the biome field here? Yes, well, yes. Do you want to make it editable as well? No, no, just displayed. Just displayed. There's a few different ways, sadly. There's always. This is the cool new way. So you just sort of do that. There's another one that's form field, and I can just... No, we're deprecating that one, yeah. Queer is the way to do it. The thing about the form types is that they can be rich fields, so not just holding text, but they can be interactive elements. So it might be a Google Maps field or a genome browser thing. So you can do... So a guy called Michael Dorn made FlexForm plugin, so I can do render for display, and I forget the exact parameter, but it's something like field equals... acronym, something like that. And if it's a special field type, how do the JavaScript and everything necessary to make that interactive element come up? Could you show us an example of how you could construct a slightly complex query, like maybe on a couple of fields? And I also wanted to ask about the licensing for it, because I see it's kind of copyright-respective contributors, which is not super useful, you know, wiki, but probably you have restrictions because of where the data's coming from, I'm guessing. Yes. So you're talking about the content of the actual page rather than the licensing of the wiki itself? Yeah, Trinwiki's copyright. Yes. A lot of it's user-created data and they haven't decided what license. So we're trying to push them to use Creative Commons, but they want to share it, but they don't ask them about a license. It's really too hard. I've got this guy who's made this Latin glossary. It's the most comprehensive botanical Latin glossary you could have and we're almost at the point where we can release it to the public. It's better than the Google Latin translator, by the way. I don't know if you've actually tried to use it for scientific Latin, but it's not very good. And the glossary isn't by any means as interactive as the Google Latin thing, but it's a very comprehensive list of 25,000 glossary terms. It covers some Greek as well. And the problem is he wants to share the data, but he doesn't, and he wants to have credit, but he doesn't want to be credited when somebody just changed it. And I haven't really found a CC license that sort of covers that scenario. If you can help me, I'd be glad to hear it. But I've nearly convinced him. So let's see if I can do a live demo. So FOSWIKI macros are interesting. In other platforms, you sort of have this outside-in expansion order. In FOSWIKI, it's inside-out, so you can actually build compositions of macros. So like you can build it in a macro that expands first, then an outer macro that takes the output of that one, and you can feed macros into other ones and build these monstrosities. So I go search, type, so I'm going to say, I want to get all my term forms. This is a query search. Running an experimental version of Mongo, so I don't, whoops, missing operator. That's because there's no operator. Now, this is running in debug mode on my laptop, so this might take a while. I think this is 1400. If you go to Web Search Advanced, when you hit return, get your results down the bottom, it even tells you what you'd put into the topic if you wanted to make a topic with that. So it's kind of a semi-useful prototyping tool that most people don't know about. I knew about it, but I haven't used it. You've changed your tech. Have you thought about the kinds of things that HTML5 will allow you to do with this sort of system? Hopefully, if we do HTML5, we'll be able to become WCAG compliant as well. Sorry, that's on the top of my list. HTML5, yes. At the moment, FOSWIC is not very AJAX-y, so every sort of screen is its own request. It's nice to have a sort of page that you don't leave, but it's going to reload those divs and do all those AJAX kind of things. And we've sponsored a REST plug-in, because the native REST API is a bit lacking. But the new REST plug-in allows us to send objects in JSON to and from the server over HTTP REST with content negotiations. That's the first step to really enabling AJAX-y type stuff. But in terms of specific HTML5 technologies, I haven't really thought that far ahead. Getting close to the end, so I'll just take one more question. I like the idea of sort of bottom-up. You can design a form out of nothing that your users can when they need to. Can you add how simple is it to add constraints validation? This one's got to be a number or anything like that. When that was your starting point, somebody just said, he's a box. Yes, validation is something that can be done but isn't part of the native data forms experience. Yeah, it's an intended feature yet to come. So really, it's hard to enforce constraints and things, because fundamentally, a topic is just a collection of metadata. So there's nothing that I know of. You could make a plug-in that prevents somebody saving illegal values into a metadata field if you so wish to do it that way, but you sort of then short-circuit a lot of the arbitrary Excel-like nature of this information. Yeah. Okay, well, I think Paul's going to be around for a few more minutes after the talk, but we have to get ready for the next one. So it's been good to hear how trying to deal with the unreasonable demands of all those users out there leads to this interesting bit of software. So would you all join with me in thanking Paul?


I'm Aaron Grealius. I'm a security researcher with Grimm. I'm a cyberphysical systems team. We work on improving the security of embedded devices everywhere. I've also got a background along background and embedded software development on critical systems. The telecom aerospace medical and a bunch of different fields. My name is Tim Brun. I run the cyberphysical systems team here at Grimm. I've been at Grimm for about five years now, hacking all sorts of different types of embedded systems from aerospace to automotive, heavy trucking, medical. We're here today to talk about some of where cybersecurity meets aviation regulations. I'm going to start by talking about the current status of cybersecurity regulation and more how the software development happens in aerospace. The current process that we have descends from the historically how airlines have approached the topic of safety. Airlines have approached the topic of safety usually historically from a purely mechanical standpoint. This part will last for about this long in airplanes. It has to be replaced every so often. There's maintenance procedures and awareness directors that talk about how often these parts need to be replaced based on how it takes them to fail. There's things that they test. Like anywhere you have stresses on a metal joint, you'll have testing done, both visual inspection and other types of testing depending on circumstances to see if it's starting to fail. It's starting to get cracks forming in those areas. But it's really designed around this concept that once you make a part, it behaves in some sort of defined way that doesn't change. Once you design it, do all your fairly rigorous testing that they do in the airline, the aerospace industry and install it. It will change in ways they're defined essentially by the physics of the situation. Stresses on metal, opening and closing of latches and stuff like that. They have a defined physical characteristic and you can define maintenance procedures that will detect all of these potential issues on the airplane. These maintenance procedures are defined to replace things that need to be replaced periodically. These maintenance procedures are, you can follow between the commercial aerospace world will be followed. They rely on that happening that does happen. And they do it in places like this. They have drawers that have labels, places for every bit, every socket, every tool. It's access controlled.  So you don't wind up leaving a socket in an airplane. They have this fairly strictly defined procedures that you follow in order to make sure that all these minutes is done correctly and done completely. So that's the kind of history of where we came from. As far as the current regulations that drive the software development process for our modern aviation software, that's regulated, at least in this country and many other ones, by something called DO-178C. We're not going to go into this too deeply, but knowing how things work right now and how levels of safety are defined will help us think about cybersecurity and where, how to go forward with that. This is developed by RTCA. It stands for Radio Technical Commissions for Aeronautics, which I never actually know until I look that up. It's not super important.  And again, these are adopted by FAA in the United States, Transport Canada, and European Aviation Safety Agency, EASA. So what is DO-178C? I like to summarize it this way. You basically tell the FAA, well, a DER, designated representative that stands in for the FAAs, tell them how you plan on designing, creating, and testing your software. And then you go and follow your plan and do those things, and then you have to prove that you followed your plan. That's it in a nutshell. Now, there's a lot more paperwork involved. There's a lot of checklists you do have to go through and make sure that your plan actually does identify all of the areas of concern that DO-178C points out. And if the DER thinks that anything is lacking in your plan, they will tell you and help you make sure that it gets revised appropriately. That's the way things go forward right now. And as you can see, it's kind of a very water folly-based model where you do all of your design upfront. You create a design, you create a spec, you know, that actual product that implements the design that you do testing on it in order to make sure that your, the product you designed actually meets the requirements that the product was supposed to fulfill. That is a good point. The way this does work in practice, it is extremely waterfall. There have been attempts to try and figure out how to fit agile methods into this, but it is very much planned to prove just pretty much in those steps. And this again comes from that historical background of making mostly mechanical components where that is how you design them. You don't do iterative development on, you know, a way usually. I mean, if there's issues you'll go back and fix on the course, but like you don't really do, you know, there is no fail fast on making a lot of these mechanical components. So it's trying to shoehorn software development into how they make mechanical components for these aircraft. Right. And has anybody who's been in software development for a while knows that waterfall has been around for a long time. The Q178C categorizes different levels of software according to the potential consequences of a failure of that software. So levels A through E and basically A means that something catastrophic would happen if it fails. Level E means that nothing is going to happen safety wise. You know, maybe your passengers can't watch movies, right? That would be a level E software. The level A is also the highest cost. It's probably unsurprising. The last numbers I can find show that it's estimated to be about $100 per line of code for level A software. They're not all software on an airplane is level A. There's usually just a small percentage as possible because of the cost. But Boeing 787, for example, is estimated to happen between 6 and 7 million lines of code. So even if it's a small percentage, just the level of certification alone of the software drives a great deal of cost. Basically, these go from different levels. So level A catastrophic software, usually software that is level A rated will have autonomous control, which means that there's no way to intervene if something fails, hence why it's so expensive and so time consuming to develop. Then they go on both their level B would be something where something hazardous could happen, but also level B will typically allow for pilot intervention. So it might be something that increases the significantly increases the workload or the challenge of flying the aircraft, but it would be something that can be addressed by the pilot train. Level A and B is usually lost in life. Like a level A failure was likely to lead a loss of life. Level B failure is not likely to lead to loss of life or severe injury. Injury sustained at a level B failure should be minimal. And then it goes on down from there. C and D are major or minor impacts to the flight of the aircraft. Also, so entertainment systems are going to be level E. It means that there's lower, less regulations and less checklists, essentially.  And D-178c. Code is expensive. So stuff, especially if it's a level B or level A, is very unlikely to have unused code in it or unnecessary code in it, like a shell onto a system. It's, you know, actually D-178 level A, you're not allowed to have dead code in your design on the system. So there's a, because it's so expensive to develop the code, there's usually a minimal amount of code on these systems. There is extensive testing done for the higher certification levels. It's at least a significant quantity of testing done. Pilot training, taught how to use the software is, and the other systems are designed for redundancy and safety. So if you do have a failure, there should be a redundant system to back up that failure, unless you have a 737 MAX, but we won't talk about that right now. There's a little very, very limited interfaces on these flight-critical systems. They use the differences like R and 429. R and 429 is a UR style bus. You're limited to sending the 32 bits of data at a time, as well as not really room for buffer overflow here. You don't really have longer messages on top of R and 429. These interfaces are very strictly defined and fairly limited, provide very limited functionality beyond just sending the necessary critical data back and forth on the bus. Yeah, there's a great deal of emphasis on determinism and reliability. So there's some bad things related to the current way software is defined and designed in aerospace. This is kind of, so as I said, as we said, both Tim and I worked in aerospace kind of on the development side of things and also on the cybersecurity testing side of things. The things that I found many things frustrating when I was doing on the development side of things, this is kind of a piece of that list right here. Data validation is guarding against accidental data modification. The design of how software is made to be robust in aviation systems is guarding against like cosmic ray bit flips, single event upsets. So simple methods like CRCs and checksums are sufficient. And also the software that runs it is typically slower and older, more reliable, and therefore modern data validation methods are going to be very time consuming for those, for the hardware involved. There's very little code to guard against unexpected scenarios. If you don't, if it's, if every single line of code costs $100 approximately, probably more nowadays than it was when I found that statistic, then you're not going to have a bunch of code for guarding against things that the system designers say won't happen. In fact, as Tim says, dead code, code that is never expected to be executed, is not allowed in DO170AC. There's a lot of complacency. Because of the level of tests involved, because of the amount of work that goes into designing the software, there's a lot of point of view in the industry that the way we do things, the redundancies that we design in the system protect us from bad things. And it protects against single event upsets. It doesn't protect against determined and directed attacks. One thing, one piece of software I was working on a while ago, I had a just a straight up buffer overflow attack against it. And I had to fight fairly hard to actually get it fixed because the incoming data that hit that function with the buffer overflow could only come from a trusted source that would never send more than such amount of data. And if there was some sort of, like Erin says, a single event upsets, a random bit flip that caused the length field to be long and was supposed to be, there's a CRC check that would have failed and they wouldn't have even processed the data at all. So they felt that they were completely protected against this scenario because they just don't have this concept of an adversarial attacker with knowledge of the system being able to get data into this function. They believe that the only way for data to get this function is from a source that they trust to not send data that's going to cause a buffer overflow. So Tim's kind of jumping ahead there. The last bullet point on this one is software's only tested against expected flight configurations. So you will only say, here's, you know, this is what we're going to do for this flight. And that's what we're testing because testing is expensive. There's a lot of tests that are performed as part of this software certification process. You don't want to run more than necessary. What that means though, is that software aviation software and model robust in flight configurations can be extremely brittle when it is put into conditions that are not expected to happen. Some other things here, ground maintenance devices, so things that actually program the different flight devices, those are not DL17C rated because they're not flying, right? They're just staying on the ground while the airplane flies. They're covered under some different guidelines about tool development, but they don't have to go if they're not even levelly certified. It's something different. Maintenance software. So on each box, there's typically a component that will help reprogram that device. That's considered to be deactivated because when the airplane is in flight, you have a signal that says, are the wheels on the ground or not? Sometimes it's called weight-on wheels. Sometimes it's called weight-off wheels. Make sure you read your documentation very carefully. And whatever signal that indicates, if that signal is then used in the startup process to make sure that the reprogramming software component doesn't run, so this is considered to be deactivated. There's also frequently a physical switch on the piece of hardware that you have to switch into some sort of boot mode, maintenance mode, programming mode. So you have to not only have the weight-on wheels signal get there, I also have to have this switch set in the activated position to boot the piece of hardware into the maintenance mode. And then the plane won't fly if that piece of solid hardware is in the maintenance mode or programming mode. You have to switch it back to flight mode before the plane will take off. Right. And it'll be like programming. Sometimes it'll be built into the wiring harnesses themselves. So when you plug in the harness for reprogramming a box, that thing has a wire jumper. And if that forces this type of mode. So there are some current cybersecurity documents out there, DO326, which outlines the activities that should take place at a system and airframe levels. These are the type of security activities that you should do if you're developing either a system for an airplane or developing the entire airplane. These are the various testing activities and testing documents that you should create and how to create them. DO356 goes a little bit more into the nuts and bolts of what testing should look like. Something I'd like about DO356, the DO356 does make provisions for the more ad hoc pen test style testing that hackers tend to do, the adversarial feeling around trying to see, scan different systems, trying to find some way and some chink in the armor that you can then exploit and get out of the system. This is a test in this much. Most testing that you see, such as the DO170C type testing, is extremely formalized. Every test procedure is written down. You do this set of procedures. This is your test. There's conditions for the test to pass. There's conditions for the thing. If they don't meet the passing conditions, the test failed. DO356 does provide those provisions for the more ad hoc style testing that can be much more useful for security testing, provisions for things like fuzzing, which doesn't really have an analog in the DO170C that you can't really formalize a fuzzing procedure. So that's where we are right now. We've got some concerns with current set of, with current way aviation software is currently defined. What do we do? So what do we do about that? Well, Tim and I have a plan. First, you know, as with anything, we've got to figure out what our actual goals are for how to, what needs to be secured, what devices need to be secured, and come up with some examples, come up with some measures that we can use to reach those goals. It's all very well and good to say, secure the system. But if you don't actually tell people how to go about doing that, you're going to end up with a large number of ways to do that, some of which may not be very effective. So the problem is up front here. Everything is hackable, right? Give some, give enough access, motivation, time and money. You can get into any type of device. You give us a piece of hardware, and we can get into it. There's a lot of measures you can use to make it more difficult, but depend with a large enough playground, you can get into anything you want. So for goals here, we, so for goals here, we need to assume that attacker has all the necessary information and resources to do what they want to. If we're going to design an aircraft to be secure, we need to start from the assumption that the adversary knows what they need to know to get into it. We need to make sure that we have some way to prove beyond the most up-to-date way to prove that the software on a particular component is 100% correct. If you cannot prove that, then it's going to be impossible to figure out how to get to secure an aircraft. We need to prevent accidental transmission of something malicious. If you know that everything is secure at some point in time, you need to protect it from going forward and then put multiple barriers in place also all these different components. We know that given enough time and money and so on, anybody can get into a device if they want to. But it is possible to figure out how to prevent, make an attack practically impossible if you limit some of those things. So if you know when an airplane is on the ground that it has all the correct software and configurations in all the different parts that are on the aircraft, then an attacker would have a limited time frame of the actual flight itself to perform an attack. So that's what we're aiming for. And also aiming to get the idea into aviation that a software component can go from good to bad very quickly. Just one exploit and all of a sudden this device that was working completely fine is now no longer working completely fine. And it's not based on some statistical degradation over time. Now that it can just go to be good and then be bad. So to define what is important to secure, here's my list. We have things that are important for flying aircraft. And then we have things that are not important for flying aircraft. These are two device categories. The level D178C defines five different levels to of how critical software is and the consequences of failures here. For us, there's really only two categories, important or not. Because if you leave something that has partial measures in place on the aircraft, then that is a potential point that an attacker could use to pivot to other parts of the aircraft. Flight devices are any component that's used to operate the aircraft. Any or any device that communicates with those components. We've seen instances where you may have a level E hardware device that communicates in some way with even a level A hardware device. And this is allowed because that communication has been strictly defined and tested on the piece of a little A software to make sure that it should reject any bad inputs. So oftentimes that very robust checking and all of these bad inputs actually are. But from a security context, anywhere that you can touch something important from also needs to be secured. Because if you can have a lower functional device, a lower classificate lower D178C DAL classification device that can can maybe in some way disrupt a higher level of no more critical device. And this is something that you have to think about from the security perspective as an attacker using this as a potential pivot to get on to a more critical system. Also any device or software that interacts with these components, whether in the flight or on the ground, all of your ground maintenance software is now used to be considered essentially from a security level, the same as a flight device, because these are things that are designed to be able to modify the behavior of these pieces of hardware that are responsible for directly controlling the flight of the aircraft. And I think that's an important point of what we're defining here. Things that we consider like devices includes the things on the ground that program the device. Because those are very critical to making sure that the correct and only the correct components are soft our program. You know, one thing also we talked about the different components, a different level of components talking together on the same bus. One very common level, a software item on recent aircraft is an operating system running on a particular device. There is a standard called Aaron 653, which defines ways for a partitioned operating system. It's effectively like a virtual machine can have multiple different severity levels running on the same component. So as we all know in security though, virtual machine escapes are definitely a thing. So if there was an attacker who was able to get into a lower level component, you know that they would be able to from their pivot into the operating system itself, or more critical component actually. So that's our devices. How do we go about doing this? Well, we've got a couple different things here. So there's adversarial testing. I choose the word adversarial testing. I don't want to say pen testing, because pen testing means different things to different people. This is the idea of attacking this, you know, testing the system as an as an attacker, what you know, you're not no longer just strictly checking against a specification. You're actually looking at it from a, if I'm an attacker, how could I leverage this system to do something? How could I use this protocol to do something? All the things that, you know, security professionals that we do in our jobs. How do we, you know, do in these things to now an airplane? Another method is a sort of pre flight software and configuration authentication. If before every flight, there was a way to go and check that the system is actually running the software that you think is going to be running actually has a graphically secure method of validating that the software that's running is the software that's supposed to be running that your configuration is correct. Other methods could include like a physically incompatible interfaces on flight systems to make sure that of no flight system, you can't just plug your iPad into a critical flight system, that there's the interface on these flight systems just a little speak these commodity protocols like USB or Bluetooth or Wi-Fi. We'll talk about this a little bit later. We also need to talk about air gaps. You know, anybody in ICS is definitely laughing a little bit right now, but on an airplane with a strictly controlled configuration, you know, air gaps could certainly be a part of the solution for making sure that you can't jump from, you know, the non-flight critical portion of the aircraft, the flight critical portion of the aircraft, at least as a passenger sitting in the plane. The adversarial testing review and test all interfaces for vulnerabilities, you know, you have to, you can't trust, just blindly trust the external inputs into the system, even if they should only be coming from a system that's also been tested at the same level and should only be producing correct outputs for you to consume, you still can't trust this because you can't always trust that the system hasn't been compromised in some way. I like to give an example from Automotive for that. If you have one component that tells you the brake is pressed and you make sure that the thing that actually generates the signal, saying the brake is pressed is very, it works perfectly, can't be cracked. The thing that interprets that signal works perfectly, can't be cracked. It's all well and good, but if you then have an entertainment system on the same bus and that sends a message saying the brake is pressed, well, now you can't trust your inputs, can you? Yeah, and testing your protocol stacks and mills does your vulnerability. I mean, we've gotten a little bit better, but there's been, you know, lots of vulnerabilities found in TCP IP stacks and other network stacks over the years. Our review into software and compile code for vulnerabilities and making sure you're doing like static analysis on the code, not a perfect solution, but does catch some things. Secure Boot is, I think, a fairly critical part of making sure that we can actually trust the software running on the systems, having a good secure boot platform set up. Good to go a very long way to preventing at least an attacker from modifying the operating system. That should then be modifying the software that runs on this platform because it should be detected. And, of course, having multiple layers of protection. Defense in depth has always been one of the strongest things that you can do for the security posture of basically anything. The topic of secure boots, one that could be talked about for a long time, and different people have different definitions of what secure boot means. At a simple level right now, I think what we mean is just that there's a way that the hardware has the ability to use cryptographically secure methods to ensure that only authorized software and components are installed and operating on that device. And a way to store the keys that should be both, that should be immutable. Right, and also should not, if once somebody gets in and pulls apart the hardware that they're not able to go in and break out, break the secure boot for all of the devices. Right, something that is, uses perhaps asymmetric cryptography methods and secure hashing to be used for device. So pre-flight software authentication, talked about this a little bit earlier. We want to make sure that the before takeoff that everything on the aircraft is 100% correct and secure and authentic. So this would be some centralized way to query every single device and find out what software and configuration are running on them. This is already somewhat in existing, before an aircraft flies, this is already somewhat what happens, right? We need to make sure that only the correct software is on each component. So people who fly aircraft will already have a list of different software versions that should be running on each component of the aircraft. So this isn't, this isn't as outlandish as it sounds. You can use cryptographically secure algorithms, no CRCs, no checksums, you should be using something like SHA-2, SHA-3, something better. And there should be also the protocol, the way the centralized device queries every single component. There should be a challenge response protocol here. The protocol should also be tested adversarily to make sure there is something that cannot be spoofed. We need to make sure we can prevent replay attacks. So if there is some malicious software, malicious component on a box, it should be incapable of falsifying the authenticity of that software. You also validate the entire range of memory and flash on each device. You want to make sure that you can't like set the length to zero. You want to make sure that you don't have the correct software and the correct configuration in both the mystery component in the middle and that that gap just isn't checked because it wasn't thought to be important, right? You need to make sure that the entire range is validated. Yeah, physically incompatible interfaces. We're seeing the flight crews, they have the iPad devices that will be there, their flight book that has the flight information. One of the ways to make sure to, in order to help prevent malicious software from being loaded onto these flight critical systems is to make sure that there are physically incompatible interfaces between the non-flight systems and the flight capable systems. So your flight capable systems shouldn't have USB, they shouldn't have Bluetooth, they shouldn't have Wi-Fi, they shouldn't have these standardized protocols that everything speaks in specialized hard wired connections like the connections we have a picture of here, very common in aerospace. Just make it a lot harder for the flight crew to just plug their iPad into a flight critical system. And if you can see on these connectors, some of the important parts of them is that they've actually got different keys.  But then you, there's a lot of different varieties of keys, some have five slots, some have four different widths, different positions. And the whole idea is that you want to make sure that you cannot connect a component wrong. This is already what's done on an aircraft for connecting all the different flight components. And this is something that we say is necessary when connecting anything to a flight system. So air gaps, as Tim said, everybody who is in ICS is probably laughing when we have that out there before. But the whole point is that an aircraft doesn't change. If it changes, it changes because the design of the aircraft changes, it changes because there was an actual document and, you know, tested reason for giving it so. So designing the system, you should make sure that the flight systems and the non-flight systems cannot talk at all. They should be physically separate. We, as I said, virtual machine escapes are definitely a thing. You should not be running on the same box. They should not be able to even talk on the same bus. So anything that needs, if somebody, you don't want to have to test everything on an aircraft, right? You want to make sure you can, you want to try and trim what you need to test because testing is expensive. So something like an entertainment system, maybe somebody doesn't want to go about testing that. Well, that's okay if you can make sure that that entertainment system can never ever talk to its flight system, which means no common buses. It means that the only thing on the aircraft connected to that entertainment system from the flight components is power. If you need somebody to, if a crew needs to, like, disconnect a component, they would need to be able to, you know, toggle the power to that device instead of actually sending it a message to shut down. So some examples of what we've got here. We're going to go through some different category areas, three different types of systems, and talk about how we would apply these things to ensure that they're secure. Maintenance, and these cover, this is pretty much the, you know, all the different types of devices that you would have them on your aircraft, right? Passenger-accessible systems are things that passengers can get access to, so on. So maintenance devices, these are the things that program the different components when the aircraft is on the ground. They usually, a fancy laptop, maybe a robust laptop with some sort of waterproof case and special cables and extra interfaces to talk to the aircraft parts. These need to be adversarial attested. This should be unsurprising to hear by now. Communications with the different flight devices should require full authentication, and these devices should also have a plan and method to periodically validate that the device itself has not been compromised. As I said, they're typically a regular laptop or some sort of a PC type device. So any of the standard ways to secure a PC, you know, a laptop should be used on these devices to make auditing. They should have an auditing on. They should have all the different security protections in place. Programming other devices as well is typically, it can happen through, there is an airing standard for this as well, although it's optional, not every device implements it. It's called Airing 615 for data loading, and that can happen over multiple types of device buses, such as Airing 429. These devices will then usually talk over that. It's kind of a double-edged sword. On one hand, it means that you've got a standard way of doing things. On the other hand, it means that if somebody implements Airing 429, you potentially be able to go up in program with an unauthenticated device, which is why communication with the flight device should require full, you know, back and forth challenge response authentication on both ends. The device should make sure that the programming, the device programming is who it says it is and vice versa. Full mutual authentication. That's the term. So passenger-accessible systems should either be incapable of connecting to aircraft systems, not physically connected in any way, not physically sharing any, you know, any piece of hardware, ideally not even speaking the same sort of protocols, so they couldn't even accidentally be connected together, and you can't just plug USB into Airing 429 and have it work. Or they need to be saying, as everything else, adversarial attested and not have external connectivity that a normal passenger would be able to just plug into and use. If you have like a USB for charging, it should only be for charging. Only the data lines should be connected. It should have the need of the, it should be capable of passing data back and forth. The only case where there's an exception then is if this is a system, if the entertainment system is incapable of being connected to critical flight systems, or to flight systems, then you could have a USB audio interface on it. But that's the only case where that would be allowed. You would need to make sure that this device cannot talk to anything else. And the whole goal here is to make sure that something can't be done, something cannot accidentally or through, you know, through somebody dropping a bad cable somewhere near the airport, have somebody connect something that shouldn't be connected to the flight systems. That's the whole goal here. If somebody is going to try and attack an aircraft during that small, that limited window of the flight itself, we want to make sure that it is incredibly obvious that they're doing something that they shouldn't be doing. So just plugging a USB in is very benign. But if they're starting to rip up panels and trying to find the Air and Fortune 9 bus somewhere down there, well, that should hopefully be obvious to some of the other passengers or the crew and corrective measures could take place. But that's the whole goal here. We want to make sure that can't be done accidentally or on purpose without it being obvious. The flight systems, the flight systems themselves, we've talked about these quite a bit already. These need to be adversely tested, of course, we need to make sure that there's multiple levels of, there's multiple layers of protection in the way for anybody who is trying to attack a system that they would need to get through. No consumer interfaces. So all those flight systems, you need to make sure that you do not have the, you don't have the, you know, there's no USB in there. There's no Wi-Fi in there. So iPads, there's a flight bay or thing now. And obviously, there's an appeal in terms of how easy it is to update. We don't have to carry around stacks and stacks of paper. There's, it's an easy way to store a lot of things. But that means you've now got a device, which is in the cockpit, which is considered a flight critical system, which is a consumer device. And that gives me some concerns. So I think there needs to be some thought on how to secure that type of system. Maybe it just needs to be not an iPad. Maybe it can be a special purpose device. There's plenty of things out there with an LCD. They can store maps and have a program in them. No consumer interfaces. Yes. So no USB. You wouldn't be able to connect this. You don't want to have somebody accidentally plug in a USB. It's not supposed to, right? So just as a quick summary here, again, our goals are going to make these are the things that we want to achieve. And I think we have for the, what we've put in place, making sure we still have to assume again, up front, our attacker has everything, knows everything. We've talked about providing a way to make sure that the systems can be validated and be correct. That the software and configurations on the different components are correct when the aircraft, before the aircraft takes off. We want to limit that potential attack window. We've talked about the ways we can prevent accidental transmission of something malicious to the physical air gaps, physical disconnects, physical incompatible interfaces. And then again, if this is all the goal is make multiple barriers there, multiple barriers or an attacker wouldn't need to get through. Yeah. And then two device categories, there's stuff that can affect flight and stuff that can't affect flight. And what that flight does in this case mean physical full physical isolation from anything flight critical. Methods, we've talked about these at length, adversarial testing, I believe is a big key part of this. One thing that I guess we didn't really talk about is kind of design standards. It's something that could be addressed as well. Making sure that the software as it's developed complies with the different best practice recommendation of how to develop secure software in terms of program functions that are allowed and such. That's another potential method. This is, we are more looking at the fitting things on top of what was there already. But we still do have a few problems that we need to solve. So we're not going to try and pretend that we solve everything here. We'd like to think that we solved a significant part of aviation cybersecurity just in this talk. But there's a few things that we need to think about going forward. Supply chain security is still a concern. Obviously, as I said, anything can be hacked. If some, as the devices are sitting in storage, an attacker could go in and modify them. They've got plenty of time to go in and modify them, figure out how they work, either modify the software or just physically, physical modifications to the hardware. And how to make sure that that doesn't happen or can't happen is a challenge. RF communications is also another area where that we can really address. The airplane has a fair bit of RF communication that has radio and ESP, weather, et cetera. This is also something that wasn't addressed by this, what we presented here in this talk. Yeah, I mean, the flight crew, the pilots training is a significant part of that. If there's issues with communications between the aircraft and the ground, that's something where training can kick in and deal with the situation. It would improve matters if there was a way to secure the communications. Things that we might also want to think about in the future, how often, how much change would require something to be retested, more adversarial testing? What level of change, what type of change? Do you want to send me a C to find that for software where different amounts of change are considered to be minor fixes and they don't have to require a complete redesign of the system, but some level of change does require a complete redesign and retesting of the system. So that's something that would need to be looked at in the future. And then there's also the maintenance devices themselves. We talked about how maintenance devices are used to program all the different components on an aircraft. This means they would be used to program both flight systems and these air-gapped non-flight systems. So maybe those need to have a slightly different category. You could argue, you can put together a committee meeting and argue about lots of this stuff for a while if you want to. But I think that the, what we've given here is a fairly complete approach to address cybersecurity. Any questions? We'll be in the discord for any questions.


Greetings everyone. Every May we recognize the many contributions and strong heritage of Asian Americans and Pacific Islanders of various nationalities and ancestry that have sacrificed and served in our Navy. As of December, the Asian American and Pacific Islander community makes up more than 70,000 members of the Department of the Navy's total force. We celebrate the hard work and achievements of Asians and Pacific Islanders who have defended and continue to defend America's freedom through service in our Navy and Marine Corps team. This year's theme of advancing leaders through opportunity reflects our deliberate endeavors to ensure all sailors, Marines and civilians can advance, grow and lead without barriers or discrimination. As we continue to build a culture of warfighting excellence, I am committed to the conscious and intentional effort we must put forth to afford leadership and advancement opportunities for all individuals, including Asian Americans and Pacific Islanders. This effort includes recognizing that our nearly 250 years of Navy and Marine Corps history is not perfect, taking the initiative to learn from the past and ensuring that we invest in a force that reflects the nation that we have today. The deep history with the support dates back as far as the Civil War and transcends through both World Wars and many major conflicts. During last year's AEPI month, I had the pleasure of naming a future guide missile destroyer after farm in second class at El Toro de la Cruz Trinidad, the only Filipino in the U.S. Navy to be awarded the Medal of Honor. This past January, we celebrated the future U.S.S. Del Toro Trinidad at the Capitol with retired and active duty service members, senior executives, civilian employees and government leaders to celebrate the growing accomplishments from the Filipino-American community and to honor the heroic actions of farm in second class Trinidad. One of the many proud members of the Filipino descent in attendance was retired rear admiral Eleanor Concepcion Mariano, the first Filipino-American in U.S. Navy history to become a rear admiral and the first woman in the military to serve as White House physician. I announced that Dr. Connie Mariano would continue her connection with the United States Navy and serve as the future ship's co-sponsor, in addition to Trinidad's great-granddaughter Christine. Our military draws strength from the grit and determination of our people, who come from all races, background and cultures. I thank each and every one of you for sharing your rich heritage that has positively impacted our nation and our department, and I thank you for your commitment to our Navy and Marine Corps team.


We'll see you back with the breakfast and plus TV Africa. Now, we'll move away from politics and all of the politicking and elections and talk about, you know, the environment. This morning, we'll have a guest joining us, Folake Sawa. Joining us this morning, she's of Green Recovery Niger, a coordinator to speak about wetland as it's been celebrated today, the second of February 2023. Folake, it's good to have you join us this morning. Can you please bring us up to speed with what today is about? I mean, what's the importance of this day and how does that really affect us as humans, especially in Nigeria? Okay, thank you for having me. I work with the Nigerian Conservation Foundation, NCF is the premier NGO in Nigeria at the forefront of promoting environmental and conservation education in the country. So basically today is International Wetland Day and the commemoration is usually done on the second of every February of every year. It started in 1997, one of the outcomes of the ERAMSA International Convention on Wetlands. So it's to raise awareness on the importance of wetlands to humanity and the reason why we should protect the wetlands. And that's the reason why we commemorate today. I don't know, basically in the last 50 years, over 35% of the global wetlands has been lost due to human activities.  And in line with this year's theme, which is wetland restoration, it's all about now we've done a lot of harm in terms of degrading the wetlands. We need to now start promoting the restoration to get the wetlands back to the forms where they will continue to provide the ecosystem services that they provide. For those who are wondering, when we talk about wetlands, what do we mean? Okay, so basically wetlands, it's a distinct ecosystem that's flooded or you know, saturated by water either seasonally or permanently. So what comes easily to mind when you want to give example to people are forest swamps or mangrove forests, like we have along the most coastal areas in the country. And within Lagos, the most prominent would be like the one around the National Theater. There is a wetland, if you notice around the National Theater in Urilegumu, there is this particular expanse of, excuse me, expanse of land, rich in trees and biodiversity surrounding it. It's a typical example of what a wetland is. And why do we need to restore the wetlands? Before you even get there, what is the important role wetlands play in our world, in our society? Okay, so I mentioned that they provide what we call ecosystem services and then the most prominent one would be like they provide the flood and flood control. It's like a place, it's just like a storage where water otherwise that would be a nuisance to people is stored and supports fauna and flora, that's aquatic life. And also wetlands also they perform water purification function. So you know, when Nigerian, I mean I know it's a global event, but let's talk about us. Where can we, you know, spot out, you've just mentioned one in Lagos, the other paths in Nigeria where we can find these wetlands and what are the challenges that, you know, these areas are faced with? Okay, so Nigeria is one of the internationally designated wetland countries. And then wetlands in Nigeria you can easily find prominently in the Niger Delta area along the Benua and Chad basin, as well as the whole length of Nigerian coastal areas, including Lagos state. So we have what we called 11 international designated wetlands in Nigeria. Those are the ones that internationally will recognize. And this includes, it includes the what we call the Adegiang Guru wetlands. It also includes trying to remember some of them. Basically, most of them you can find in the in the Niger Delta area. Okay, really, but let's talk about, you know, the challenges and the human activities that are affecting these wetlands in Niger. Okay, so it all depends on the parts of like, for instance, the Adegiang Guru wetland is situated between Jigawa and Yobi state. And the main human activity impacting it is overgrazing, as well as deforestation. So this impacts the wetland. And once you lay bare, it's unable to provide the water retention, the water purification, the flood control that it does. And then in other areas, for instance, like Lagos, you have persistence, some feeling of wetlands for urban development. So these are the kind of activities that impact wetlands and reduce the amount of wetlands that we have. And also, definitely, and then one of the most important functions of the wetlands I forgot to mention, is all called carbon sequestration. It acts as just like forest, it acts as a carbon sink and helps to provide hair. And this also provides an important role in climate change control. So when we sand few wetlands, when we cut down the trees and wetlands, when we encroach on wetlands, it impacts the ability of the wetlands to provide the ecosystem services that are previously listed to us as humans. But you know that in the course of survival, for instance, there are areas where they are big on the production of rice. And we know that rice and wetlands work hand in hand. So swamp, if this were talking about these swampy areas, for instance, you have them in different parts of the country. And of course, in the state, we have swampy areas where people plant rice or grow rice. So how do we now separate human survival and the protection of these wetlands, because you have to survive? Okay, so as an organization in NCF, our vision is to promote Nigeria where people prosper while living in harmony with nature. There's such concept as sustainable agricultural practices. It doesn't mean that you're able to do your agricultural practices but what we're saying is do it in a sustainable manner. Do it in organic manner. Don't overuse chemicals that impact the wetlands. And whatever you're taking from the environment, make sure you replenish it. When you cut down trees in the parts for you to do your farming, make sure you do another planting of trees in other parts to compensate for the damage you're causing in that particular. So there's such things as sustainable agriculture that also minimizes the quantity of land you need and also improves the yield of the farmers as well. Whilst going through the conversations and some of our programs ahead of during the flooding, recent flooding around the country, we forget so quickly mercy. We moved on from flooding. Now it's Naira, it's petroscacity, it's election. I think we're grappling with it. But we need to remember that people died, people lost their home, property, livelihood. And we've not, we've government has just moved on, left everybody. But when the conversation on floods was on, had to go dig up the legal state development plans, the one that Fashella did, the one that Ambody did, recently someone came up with his, because Ambody is not needed to be upgraded and it's going to be experiment soon. One of the things I saw, I think in the Fashella legal state development plan, what's called master plan, which Singapore has been campaigning with, is they said they were going to try to prevent flooding in legal state. Legal state is under threat of floods. Some communities are just by the water and that they were going to set up a legal state wetlands agency of some sort or think tank or body. I want to talk about how has government, what can government do to make sure that this wetlands, because I haven't heard of this agency. It's important that they move to set up this commission or agency about for wetlands restoration and protection to prevent flooding and then what can government do to make sure that we do not have legal state flooded over in the next few years. Okay, so basically the agency you mentioned has not come on board, definitely. But if he comes on board, it's going to like give priority to wetland conservation, which presently is undue at national level by the Federal Ministry of Environment and also at subnational levels by the state ministries or departments of environment as the case may be. So having such agency will definitely help. But the main way to do this is to promote protection of wetlands. All designated wetlands should be, they are already giving protected status, but the enforcement of the protection of these areas should not be breached. For instance, like I mentioned the National Theater in the last couple of years, we've had to do photo exhibition, do a lot of awareness creation because of the renovation that is ongoing and which is already impacting the wetlands. So now we have to call those in charge of the restoration and get the guarantee from them that you're going to protect this wetland. But normally, statutorily, we shouldn't be conversing for that. It should be part of the building regulations that these designated wetlands don't sandfill, don't build on them, and when you encroach on them, these are the penalties. So what about the other developments? So look at that now around the Lagos where you have sandfilling going on, even public infrastructure projects. This is impacting negatively? Not all the time because... We see around the Oyanoro for instance, I'm sure you know of that part. Yes, so that's part of it. If you look at the statistics of the rate of loss of the wetlands, it's as a result of incidents just like that. I was telling me a lot of people that, as early as 2010-11, people used to paddle boat from Ifako to that Oyanoro. Now everything is sandfilled and those are the wetlands that we're providing ecosystem services to that particular area. Now where will the water overflow from the lagoon? Where does it go? It goes straight to people's houses. Whereas before the construction, that particular expanse of land serves as a storage to take excess water during the rainy season from the lagoon. So it's just a way that we need to enforce the environmental impact assessment, which ensures that building and construction projects do not have adverse environmental impact on the general environment and specifically to very sensitive ecosystems like the wetlands. So not to chew on that and I hope the authorities will take your advice and do something with it. Looking forward to seeing if the legacy government will do what he had said, it will do which itself, this agency, you said. But I would like to encourage you and Nigerian Conservation Foundation to keep up doing the good work and thank you very much for your time. Thank you very much for your time. Well that was a size of our conversation this morning and we definitely let it go at this point in time. We're speaking with an expert if you'd like to see, Folake Salawa. Folake Salawa has been with us this morning and follow us on Facebook, Twitter and Instagram to be part of the conversation. That's if you missed out on any part of it and do subscribe to our YouTube channel at Plus TV Africa and Plus TV Africa Lifestyle. I am Messi Boko. Have a great morning. Kofi Bartels here. We're back tomorrow. Good morning.


Hi, I'm Julianne Racine, the NDSU Extension Agent, Agriculture and Natural Resources in Lamor County. I'd like to talk to you about planters. It's springtime and we all want to get outside, enjoy this beautiful weather, and go to town in our gardens. So what I'd like to suggest everybody think about this year is cleaning out their planters and sterilizing them before reusing them. And the reason that is is in the event last year there was a pest in the dirt or your plant headed disease, then you don't have to worry about that carrying over to whatever you put in there this year. So all I do is I have my gloves, I have my bucket of bleach water, and I've already taken the plant out of this, and I'm just going to set it in the water and clean it out and let it dry. And then tomorrow I will put fresh dirt and I can put my new plant in there. And I have planters that are too big obviously for this bucket. So what I do is I just take a rag or I take paper towels and I'll get it wet with some bleach water and then I'll just wipe out the inside and that should be fine. Another thing that you can use is disinfectant wipes that will also work. If you're going to use bleach water, this is five parts water and one part bleach. So I'm just like I said I'm just dipping it in here, wiping it out, good to go. So tomorrow like I said I'll put fresh dirt and it will be ready for whatever I decide to plant in here. Hope that helps for your spring planting season and that you have a great time outside. And remember if you have any questions feel free to call your NDSU Extension Head Offices and we'll be happy to help you. Have a great day!


Hi everyone, Joe for jazzy's case breaks. This is actually not our last filler. Sorry. I forgot to scribble that out Break 8 will be the last for this is break 7 and with 10 extra Chronicles pack spots being given away right there. Let's gather all those names and So we're only sold 22 spots outright top 10 after three We'll get extra spots one two and three All right, so Tristan Michael Tristan Berry Jason Michael Nicole Christopher Monty and Nicole extra spots going your way now, I apologize ladies and gentlemen because This actually sold out last night and I was not aware of that because I Forgot or I didn't know that 10 extra spots have been given away I'm surprised no one yelled at me. It's like Joe. What's that happening? but better late than never and Thanks everybody We had one more filler to do anyway, but we're very close on that valiant break We got one more filler. I think one full spot and we could pop that open That's kind of a longer break just because there's a couple hundred autographs in there So let's make that happen sooner rather than later. All right, so three and a four seven times for the pack break names and teams seven times each one two three four Seven Monty down to Nestor and then three and a four seven times for the teams two NBA playoffs hockey playoffs happening So an exciting time of the year a young baseball season You know just trying to see teams figure out who they're gonna be the remainder of the season It's an exciting time of year Big thanks to this group right here Once again, there's the first half of list second half the list right there. No trade windows Let's just print and rip. Thanks everybody list hot off the presses pop this pack open and Let's see it's 20 21 right yeah 20 21 chronic This guy got a big payday today. I'm trade Lance rookie card And a Trevor Lawrence rookie card nice another t-law another trade Lance I don't know as Kyle Traskin get an opportunity They got Baker Mayfield in Tampa Bay We'll see Michael locia with that one Trey Lance will go to Jason and the Trevor Lawrence will go to Josh With the t-laws trade Lance All right now let's see who's gonna win those spots in a valiant so let's flip back to the list over here Let's gather all the names again Third and final dice roll And it's gonna be the top four We'll get into that valiant break top four after two snake eyes easy Good luck one and two There's gonna be a lot of sad faces here because it's only the top four saddest faces spot five Nicole apologies very close, but Just not quite. We'll get him next time top four happy time through you. You're in that valiant break Tristan is happy Monty is happy. So is Nicole. You got it Nicole and Tristan again So congrats to the top four right there those extra spots coming in handy for you Tristan Congrats, I'll see you in that valiant break. Hopefully a little bit later tonight. Jaspy's case breaks.com