Hi everybody. Welcome to this presentation. What I'm going to speak about today is where do security and safety meet? First, I'll give a little bit of introduction. Assuming that the people who are attending this session have a good solid background in security, given this is the Linux security summit. People have some notions about safety, and I'd like to perhaps dispel some myths and to understand where really they can meet. The focus of this session is going to be on engineering aspects, basically how we can design Linux-based systems and what type of features are maybe relevant for making those systems meet more safe, and where we take some lessons from work that has been done in the past for security. Okay, so this is the agenda, basically what I just said now. We'll give a little bit of a background where they meet, where they don't meet, and then we'll go over some typical foundations from security and to understand if and how they may be relevant to support safety. At the end, we'll discuss some practical considerations, and I'll introduce a project from the Linux Foundation called ELISA, and I guess this is also a call to action if people want to contribute from an engineering point of view to design and to help to support such features. They can contact me after this presentation. I apologize in advance, it's a little, it's the first time I'm giving a presentation where I'm talking to myself and it's pre-recorded, but I really expect this type of interaction, and I hope you'll be able to contact me, sorry about the fast forward. Okay, so very briefly, who am I? My current position is assistant safety architect. I have many years of, and I work in Mobileye, even though this presentation is not a representation of anything on behalf of my employee, it's totally my independent thinking and initiative. What I do on a daily basis is to design as an assistant architect safety features, which are deployed in Mobileye products. Basically where I focus is in the low-level parts of the system close to the hardware, the hardware software interface, system move drivers, Linux infrastructure to understand what can be done to make those areas safer. I'm pretty new to safety and as you can see, I don't deal with anything having to do with qualification standards, certification, things like that. I'm leading that to the other safety experts. My work is totally engineering and design development of these features. Beforehand, I worked for many years as a security architect. I thought it was formally NDS before it was brought up by Cisco. And for a few years, I worked as a security consultant for some major European automotive concerns on behalf of some startups here in Israel. Okay, so I have a lot of experience as a security architect and moving into the automotive domain in Mobileye. Ideal, I still do some security architecture, but more my focus now is in actual engineering features, which are supportive for safety because of the focus on automotive safety, which is very necessary in this market. Okay, so first definition, what is functional safety? If you look it up in Wikipedia, you'll see that basically it's sort of an insurance policy. Basically, it's some kind of guarantee that we are able to give that we can, we won't, and the user of this product won't face unacceptably high risk by using the product. Okay, and the way that is done is by several steps. The first thing is a failure analysis, which is sort of similar to a risk analysis that you see in security, which identifies what type of system failures you may expect to have that may these failures may be due to hardware failures, software failures, or operational failures, design failures, all kinds of possibilities. And based on those failures, this is where in my work I step in to try to understand what type of safety features can we build into the system, something which is, they call here safety functions, sometimes called safety mechanisms, and to the build the system so that we have those engineering building blocks, each of which is designed to mitigate or lower the risk of a specific type of failure, which is a potential failure which was identified. And then we have to make the safety case, which is again done by the safety experts, have to take that and put together some kind of proof, some kind of documentation, which demonstrates to whoever is necessary to that we have done the best we can, best effort to avoid such unacceptable risk. Now, certification, there are loads and loads of standards out there. I gave two examples for all kinds of different systems which are highly dependent on safety. Okay, and it's a very painstaking work to have to deal with those standards. And but the most important thing which I want to take away from it here, in this scope of this discussion, is about the liability. Okay, so what we see here as safety is really is about liability and being able to prove the level of risk or and mitigate potential failures. And I put this table together to sort of summarize some of the key differences between security and focus and the focus and safety. Okay, so if we start, you can see that in the driving force of security is malicious intent. We're always dealing with this potential hacker, somebody outside and want to do the best we can to design our system that we block any attack by that malicious hacker. In safety, we don't suffer from that. Let's call it paranoia. We have potential failures. Things break down, hardware breaks down and can give erratic results. Software can have bugs. There may be gaps in the operational procedures. For example, I don't know if a system is built with the wrong configuration file, other such issues. And we have to be able to we identify failures which are either systematic, which deal mostly with software procedures, operations, things like that, or transient failures, which mostly deal with hardware type of failures. There are others going to more details, which I'm not going to go into. But the point here is that we deal with failures, and we have to be able to ensure freedom from an unacceptable level of risk of those failures. Okay, in the world of security, we look for vulnerabilities, because those are the weaknesses which open the door to the hacker and let them exploit, provide the ability to exploit the system. In the world of, in the domain of safety, we deal with faults, which are some abnormal conditions which may cause failures. The most common tools for security are based on crypto, because they give us the mathematical foundations to be able to say, to prove, let's say for example, integrity, confidentiality, and the different important features which security experts are trying to build into systems. Whereas in the world of safety, we want to bring down the risk to an acceptable level. And acceptable is a statistical thing. If it's one in a million, that's not the same as one in 10 or one in a hundred. And based on the type of system, there are very clear guidelines and standards in the market for different types of systems on what's an acceptable level for failures or meantime between failures. Okay, so the dividends is more statistical for those type of failures. For testing, security, we deal with pentesting, fuzzing, in safety based on the failure analysis and the safety mechanisms which we define, we have to be able to test the system. But it's not a pentesting type of testing, it's more common software type of testing where we have to prove that we have an hypothesis, we have this safety mechanism, we want to be able to demonstrate that that safety mechanism is sufficiently robust, that it reduces the risk to an acceptable level. And that can be done by stress testing or the type of testing or fault injections and investigating the behavior of the system and to see how those safety mechanisms which were identified and defined based on the failure analysis, how they prove an article can be tested in a real system. In the domain of security, we can use many types of tools. They can be either open source tools or proprietary tools provided by different vendors. In the domain of safety, life is a little bit more difficult because safety certification bodies have to be able to trust that those tools actually do what they do. And open source tools are commonly not developed in a rigid formal software development process. And which means that it's much harder to demonstrate that those tools actually provide the results that they claim. So there is an inherent mistrust of open source and part of the reason for this discussion is to expand communication and to demonstrate where we have proven features from open source which have been proven in other domains and to understand how we can adapt them and demonstrate their power and relevance in the safety domain as well. One area where it's not quite clear where the future will lead us are safety standards which are being adapted for security. One of the most prevalent areas nowadays is in the world of automotive safety. There's the ISO 26262 standard which defines safety requirements, safety guidelines for the automotive domain has been pretty much adapted and modified and into terminology which is relevant for cybersecurity. The ISO 21434 is very much based on and derived from the 26262. It's still on draft and it's a real good question where that's going to lead, how that's going to help support cybersecurity really can't help because as I said it's still in draft and it's something which is still being worked on. So much for introduction what I would like to do just to wrap up the introduction. We want to deal with engineering foundations and basically to understand how we can derive safety mechanisms from security engineering. Okay now the security engineering features there's nothing there. What's new in this talk is how these may be adapted or perhaps extended by relevant patches to the kernel or other mechanisms so that these security features can help be useful for supporting safety as well. That's where the novelty here is. Okay so let's take one example. In the safety standards they talk about freedom from interference. Okay so safety standards tend to be very, I don't know what to call it, even more like almost philosophical. Okay they use a lot of terminology which is quasi-engineering. So they define as something very very basic and very critical to in again this is from the domain of automotive safety. Simply I take up the examples from there because that's what I'm familiar with but obviously these can and they have been these ideas have been adapted for other areas as well other domains. Freedom from interference means that we have to make some kind of guarantee that there won't be cascading failures. Cascading failures is something let's say like a domino effect where if you have one let's say for example either software or hardware element of the system which fails which can sort of by this domino effect lead to failures in other areas and as a result something which may be minor in one area can cause a major breach or what in the term in terminology of safety is important a violation of some kind of safety requirement. So if we think of this in terms of software let's say for example if we have a some code which is safety critical which monitors some the temperature of the system or monitors some other aspect of the system was critical to the safety of the hardware and no software of the system and we have a lot of other code which is doing whatever it needs to do to to support the the business requirements or the functional requirements of the product at hand and if some whatever non-safety related code has some kind of bug or failure or some non-safety related hardware has some major failure if that can by lack of freedom from interference by some kind of cascading effect cause a failure in the safety critical hardware or software and some others element that's what we're concerned with here when we deal with freedom from interference. Now if anybody here who is familiar with developing secure systems they should right away ring a lot of very familiar bills. We deal with in again and these are derived from the security domain we define separate processes with each of those processes having its own well-defined access control requirements because it has its own virtual memory space and the data which it can access or cannot access in whatever way it is needed and it's expected to have reduced privileges so that it cannot access or or corrupt let's even say other areas and we deal with containers and perhaps even hypervisors which combine hardware and software features for this type of separation. I left out here capabilities was also Linux capabilities provide each process or whatever it is a software element it's necessary privileges but not capabilities kernel Linux capabilities but no more no less etc we can design the system so with features which from the security domain are meant to set up isolated islands let's even of communication of computation so that even if a hacker gets control of one area of the system maybe an area which is more vulnerable it's blocked that hacker should be blocked or his life should be made much more difficult if he tries to cross over from there into a more critical area of the system and these same type of techniques are relevant and have been found to be relevant for safety as well and this is just as an example to see that when the people who wrote freedom of interference I don't think they were thinking in terms of these Linux elements but in a practical sense this is the most natural way of translating the concept of freedom from interference into code okay and that's what we're really looking for how we take those standards how we take safety requirements how we turn them into actual code and what type of features exist which can help us to do that to build those safety mechanisms so in the talk today and I'll try to keep track of the time okay we deal with memory protection features um in the safety standards there are various areas which deal with how we protect different areas of memory and to make sure that memory for example the the heap the stack let's say for example we prevent um stack overflow stack underflow um stack corruption etc similarly for the heaps a simple similarly kernel versus user space memory all kinds of memory protection features um which are built into Linux that can help us um perhaps to support those safety claims to make our stack um safe or in more formal terminology to make sure that when we define the stack if we put our any um data on that stack which is critical to the safety of the system to be sure that that's that data will be protected for any of those type of failures okay that it can't get corrupted due to um um some faults that somebody um mistakenly overrides our data in the stack when they should not have um access or permissions to do so freedom for interference which we discussed before we'll go into a bit more details um pending round of time we have anything which I don't cover I won't be able to go into great detail again um the slides have my email please please feel free to contact I think that's one of the most important things I want us to take away from this is to invite people to um to to call to answer this call to action and great to join together to expand this work isolation techniques which we briefly discussed timing and execution issues which are fundamental also to safety we have multi-threaded systems any type of concurrency we want to be sure that one element um cannot corrupt another one due to basic um issues such as deadlock live lock race conditions all of these also in the domain of security are known to be um lead to potential vulnerabilities and can be exploited by hackers so the same type of techniques which are used to support and avoid uh to support security and engineering and um avoid such security issues in um in systems in concurrent systems we investigate the potential to use them for um safety as well um um ebpf is already well established as um as um as a quality as a as a context for defining tools um framework let's say for defining tools which are supportive for security and we investigate some areas of interesting areas in which it may be relevant for safety as well and fault handling when i'm talking about faults in the world of security we have failures it could be it's usually we're talking about because of malicious um um actions in the world of of safety we get faults because of system failures hardware or software it doesn't really matter where the faults come from in any case we can have built in mechanism mostly on the level of the drivers to be able to deal with those faults either um on one level by detection on another level by corrections and some of the same features which are relevant for security handling such faults um may be relevant for safety as well and the bottom line is safety and security are not the same but we want to try to find where they meet and where they can join together in actual code in um in engineering design okay so the first area which i'm going to focus on are memory protection features it's something which is so basic to security already and it's it's i found it especially when i started working on safety quite mind boggling that um there was no familiarity with the potential and the power that these um features can provide and about in after this slide i'll go into a few examples but um there are kernel configs very basic common kernel configs which are used they can be enabled or disabled depending on you know the specific setting at hand for um security a lot of those are similarly relevant except that the justification or the the context where they use this may be a little bit um different in safety but the same features are relevant for safety as well now what i did was i started putting together a database and if you see the link here if you get the slides after this talk you can go into the database and and and see the draft on what we have there of of a list of um some um configs kernel configs um we mapped them on into iso 26262 to give them the safety context and again um i'm coming from the automotive domain domain so that's where i focus but a lot of what is written there it's it's pretty similar to to the mindset and the requirements are defined um for safety in other domains as well and similarly they're also mapped into security cwe's to to give that context of vulnerabilities that those um kernel configs are are have the potential to deal with okay it's also divided down into different groups simply for ease of access different memory type c stat kernel memory etc etc and what i provided there is a very basic layman's description which is um um a bit more detailed and a little more more um um easier for a um a layman who's not an expert to understand the if for example compared to the um um kernel driver database um which is the common resource for kernel configs there's some we added some implementation guidelines runtime performance impact issues which can give um which is um the user should be aware of so that they can make judicious use of these um different settings and basically the idea is to identify configs which are potentially relevant for safety you don't make any safety claims i told you i'm not a safety expert i don't make any of of compliance with any standards or anything of that sort but we're just giving ideas i'm lighting up some light bulbs showing people hey you're dealing with a problem you have a safety mechanism which you need to be able to resolve that problem here are some building blocks which may be relevant for you and it's up to you as the integrator of the system to look into this and see how um they when you use these features how they impact your system as i said before most commonly the safety mechanisms are implemented and tested to be able to demonstrate um the level of risk how that's reduced okay but again all of that is i don't deal with it that's part of the work of the safety expert what we do give our to do is to identify configs which are potentially relevant the database deals most completely with memory protection features there are some details also on timing and execution issues which we'll talk about afterwards and this is also an invitation hopefully others can help to expand this database to make it more useful um and more general generally available and and to add results also from practical implementation practical use cases so some examples okay and again anybody who deals with security probably says oh of course all this is basic for security um what's new here as i said before is how these may be also at the same for the same price basically um have um value for supporting um safety cases i wrote down on the bottom the disclaimer which i which i explained before because i i don't make any safety claims or or any claims about how these um comply with any safety standards there are only examples which seem to be relevant and have been used by others in different use cases for this purpose okay but it's up to any user to to make those claims and proofs and their specific system okay so for example um defk mem um is to disable kernel direct kernel memory access which is something which we normally um don't want um to support so again this starts ringing bells of freedom from interference fortified source it's it's allows us to detect buffer overflows and common string and memory functions um again which um reminds us of various requirements which are relevant for um overflow buffer overflows and how these are actually related to different safety requirements um proc k core um is related to kernel debugging features again i'm not going to go into all the details here these are very basic very commonly used security features but again um the database provides some detail on how these may be relevant for safety as well strict kernel rwx defines um what should be basic and and and common sense um access control on kernel data kernel code um and again it should be relevant also for protecting kernel code for safety purposes as well and thread info in task basically moves the thread information off the stack where it's a little bit more vulnerable from security from interview and moves it into the to the task struck some of the thread information maybe especially in in heavy concurrent systems some of that um thread information maybe safety critical and by moving it into the task structure um it it may be a bit easier to prove how we can protect and isolate that safety critical data again that needs to be investigated in a specific context but it has been found by users um to be useful to support their safety claims on that data okay so these are areas these are different types of of kernel configs which are um acceptable for security and seem to be relevant for safety as well on the other hand we've had some surprises when we started this work the first one was dev mem which for anybody who comes like myself from security basically when you disabled um dev mem you disable direct physical memory access and um it sort of doesn't make any sense in the modern system that a user application should be um in given the power to um corrupt or access directly physical memory on the other hand in um in many um safety critical systems um we found that safety mechanisms were actually implemented in this way um bi direct memory access which is which created some problems and code had to be actually refactored we did find however that it was very useful long term by enforcing this setting it created the type of separation which we were looking for which was important for safety as well so we were able to build in more checks and balances by by defining code in a more appropriate and modern way where we define the different levels of hardware versus software and um we have better um APIs between the hardware and the software and we really don't expect a user application to be able to directly um manipulate physical memory um other issues i gave some examples here which deal with traceability in the world in the domain of security we normally would want to disable these settings because of the the the fear of information leakage on the other hand um in the domain of safety there's a critical need for traceability because um if we think for example what happens after a plane crash or a car crash crash a major incident um one of the first things they look for is that black box which um records what happened up to the time of the of the crash or the failure and um so this trace these features are necessary in the domain of safety for providing um that trace to support that traceability and here there's a tricky issue of having to deal very clearly what are the security requirements what is the level of security um which is necessary for the system and what are the safety requirements and how to reconcile between them so that we can support both the security needs as well as the safety requirements for traceability and the last area is something which is very fundamental also for safety is what happens if there is a failure um there's normally a requirement to to transfer to a safe state and a safe state is one in which the system cannot damage itself or damage others anymore and most often in that state is the state when data is collected from memory from the hardware from the scope of whatever and um collected so that uh uh postmortem can be um carried out by the people who analyze those results so again this may um this necessity to um support that switch from one state to another state something which is normally disabled um in security because you don't want a hacker to be able to to control that and the need to design the system to to give the necessary security support but at the same time to enable uh secure transfer to the safe state is something which needs to be taken to account and um again it's a play area where security does not naturally meet safety but by awareness and by clear definition of the security requirements the safety requirements the implication of the different features um then the system can be designed um to meet both safety and security requirements so that's where this understanding um is is necessary and important okay my time is is getting a little bit of tight tight so i'm going to go quickly freedom from interference is defined in the standard is in this way and it's it's uh uh you can look at it afterwards it's just it's like a whole shopping list of every potential area of corruption between different elements of the system focusing on timing and execution memory or exchange of information and it's quite mind boggling how um safety experts expect to support this and again Linux provides many features many of which are derived from security which um are helpful in this area okay the next slide i'm going to to skip over because i mostly had talked about it before but um when we want to be able to to give to define the safety architecture to support the freedom from interference we we deal with um um kernel basically Linux features i mentioned a few more it's a different list than the ones we had before but i mean these are all things which should be familiar namespaces cgroups kernel capabilities and we found that by using um well-defined configurations um such as for example but this this is not a necessity but it's it's useful system the unit files it's easy to to use those as a basis for safety claims because we can demonstrate what has been defined and built into the system and what is not timing and execution the next area there are some kernel configurations which can be enabled which help us to test a system most of these settings have a strong and and unacceptable impact on performance so they're normally not used for production systems which go out to the field but certainly for offline says testing if you want to um make safety claims i want to be able to test um how are how robust our system is how how how um what the level of risk of deadlocks and race conditions on other such issues we use these and these are useful also for security testing as well okay not in the sense of pen testing but in the sense of understanding how well designed our system is and how we can um expect that their system should be free from potential race conditions or whatever it may be um there are also some well-known tools which are useful for this um casey sand t-sand um again i'm not going to go into the details but these are very very useful both for security testing as well as safety testing ebpf and security as well established in safety it's a new domain we are fine that um we are found that many of the ebpf based tools which are useful for security or also useful for the tracing and profiling which is so critical for safety as well we also have been and um this is my personal thing i've been investigating the use of the ebpf verifier which um originated obviously as as a tool for security to ensure that the ebp f code is not malicious um when it's introduced into the system and there's an ongoing investigation of my personal to try to understand um how we can see this as a model for safety runtime monitoring as well and um also the whole domain of xdp which basically allows us to avoid the network stack and all of its complexity and the necessary for necessity for testing and to deal directly below the network stack with um communication and to understand how that helps us in our safety claims because if we're dealing mostly on the hardware level on the on the nick um it's a lot easier to deal with the hardware safety claims which are usually provided by the vendor um because the hardware is well tested before it's deployed and we don't have to deal with any safety issues on the network stack level as well so especially if we're talking about an embedded system um where direct um hardware um communication is relevant and xdp is the most um um performance effective solution perhaps um there are safety implications as well on how that fits into a safety case and how we can make claims and and prove um um the robustness of the system from a safety point to view okay fold handling is basically um how we can extend linux drivers so to support um both detection and correction of errors there are lots of features which are built in and this needs obviously collaboration with hardware vendors so that those safety features are built in and to provide that open source infrastructure so that faults are um detected by the hardware and the potential also for correcting them and there are some vendors who are very supportive in this area who provide um these features in their hardware products um there for example the infrastructure there's a a very complex um framework for advanced error reporting which can be leveraged and is very very useful for this type of fold handling okay there are some practical considerations um for example um we have found that some of these features are less relevant mainly for for practical reasons for complexity non um difficult difficulty to maintain long term um different difficulty to scale up from simple um basic examples that's been my experience um again this is an invitation for people to join to participate to contribute if people have a way of um defining selenix policies or actually seccomp which is something which should be very relevant for um safety in a more practical way it's it's it's an important area of investigation and um one of the areas which I would like to see similarly to the way we have linux security models perhaps to define safety models which will be open source building blocks but that's sort of a dream um but again if we don't dream you never know how far you're going to get okay and the last slide here is just an invitation for people to join um forces and to contribute to Eliza Eliza um I mentioned it before the charter is that um this says that the mission is to define and maintain a common set of elements across a tool that can be incorporated into linux based safety critical systems amenable to safety certifications um there's a lot of ongoing work by safety experts about um you know the the safety requirements and how those how things can be certified I'm not focusing on that what I am proposing here is an invitation to people who come from the more technical community people who actually produce such systems and which to contribute to expand on ideas which I've mentioned here perhaps other ideas and see how we can join forces and give more building blocks to those safety experts and who can help to to to define them in a way that's um they can actually be used in in safety critical applications and to um in actual safety cases okay and also obviously I'm sure we will find gaps and also to to introduce enhancements kernel patches to help um expand existing linux features in this way to support safety cases okay so feel free to contact me if you have any questions if you have anything to contribute anything to ask um if this area interests you sorry I can't be in person but um I'll be very very happy to hear from anybody um via email and um we'll see how we can take it from there and perhaps to get together a work group of technical people within Eliza if there is sufficient interest thank you and have a great day enjoy the conference


The Junior Reserve Officers Training Corps at Bemidji High School celebrated a successful year with a ball over the weekend. Our own Cherelle Moore tells us how the program is creating leaders for this week's Golden Apple. The students are part of the Junior Reserve Officer Training Corps at Bemidji High School have a lot of reasons to be proud of themselves and a few of those reasons were spotlighted at their 14th annual military ball. Really the whole military ball is almost like putting on a wedding and these are high school students that are kind of organizing and planning an entire wedding by themselves. I guide my subordinates to work on projects such as getting donors for it. Really it's a wide variety. The students have been planning this event since December covering every detail from the glassware and the food to the venue and programming. Really an honor to be able to work with all these people and to be able to be up at the head table and claim some of this really hard work for my own. The work shown at the ball is only a fraction of what the JROTC members do. The JROTC program is student led so they teach a lot of the courses to their peers. The program also focuses on community service and leadership. When I came in here I was kind of shy, just kind of hoping for an easy A which wasn't the case. I've worked really hard for my ranks. One of the most misunderstood aspects of JROTC that it's kind of a path for the military while there's very little military that we actually teach it's just a structure where we can really put the kids into dynamic situations in order to teach leadership. It's applicable anywhere I go from working at McDonald's to college life even to working moving on into a career. It's also been a great tool for enhancing myself physically becoming stronger. For all the training to be better than they were the day before, the students naturally get close to each other, making this celebration all the more special. It really is a second family.  You can get so far in this class and so far as a person in the community which is what this program is about it's about getting out in the community and being a great person. Reporting in Bemidji with this week's Golden Apple, Shraamor, Lakeland News. If you enjoyed this segment of Lakeland News please consider making a tax deductible contribution to Lakeland PBS.


Okay, well, I think we'll get started. Thanks everyone for joining today. This is the second in a series of webinars directed at publishers. I'm Heather Staines. I'm the Director of Partnerships for Hypothesis, and I'd like to introduce my colleague, Nate Angel, who's our Marketing Director. Greetings, everyone. Working on a lot of the, talking over a lot of slides today with me. Just a couple of housekeeping items before we get started. We have had all the attendees join in mute mode, and that's just to keep the noise down, you know, during the presentation. But when we take questions at the end, just give us an indicator in the chat box that you have a question and we will unmute you, and you have the opportunity then to ask your question. We will be recording this webinar for later viewing if you have colleagues who are not able to attend today. So we'll be sharing that out, and it will be available via our publisher website. I'll be putting some links into the chat as we go along to help guide people toward things that we mentioned. Great. So first I want to talk a little bit about what we're going to be covering today. We can go to the agenda. First we'll go into a little bit of information about how Hypothesis works. Then we'll talk about how easy it is to integrate Hypothesis into your platform. We'll talk about options that are available if you elect to have Hypothesis assist you with that implementation, and then we should have time for questions at the end. So as many of you know, you're joining here today a little bit about Hypothesis. We're a kind of unique position. We are a non-profit tech company. And we can do things a little bit differently because of that. We're beholden to partners who share our vision rather than investors who share our company. We won't be bought by the competition. We work with targeted small groups to build up our audience strategically. We build up quite a considerable number of users that way. We create open source software so we can involve the community in the roadmap and development of Hypothesis, and we depend on open standards for that same reason. In February of this year, the W3C, the standards body for the web, did approve annotation as a web standard. So what that means is in future, browsers will come with annotation capability built natively. So just like you choose your default search engine, you'll be able to select which annotation client you prefer to use. Very excited about that development. So first a little bit about how Hypothesis works. And Heather's going to pass the baton over to me to talk for a few minutes. And we're working with the assumption that most people on the call are already familiar with annotation, of course, and then Hypothesis in particular. So there's a couple of things we're just going to spend some time reminding you about the basics about annotation and Hypothesis to make sure that we're all on the same page. But the key of this kind of conversation that we want to have is to help you understand how easy it is to get Hypothesis integrated into your own website or publishing platform. And so we're going to start out by talking just for a second about what the kind of basic capabilities of what Hypothesis is trying to do consist of. And so the first one is the idea that Hypothesis enables users to annotate in layers over the top of documents that are in their canonical locations. And so this is a little bit different than some other annotation platforms that ask documents to be moved to a different location in order to be annotated. And so this is really key to publishing, right? Because the idea is to keep your publications in their canonical locations and add annotation on top as an extra capability that can enrich the experience on top of that publication. So that's one of the key elements of the difference that Hypothesis brings to the table. And then this is just a really simplified schematic diagram to remind people that there's two major pieces of technology at play in Hypothesis. And it's what you might call a common client server architecture, right? So the client is the tool that we as users interact with on top of documents in order to do the actual annotation work. That client speaks to a server where we authenticate as users and it stores our annotations and the references to the documents that they belong to over time so that they can persist so we can log out, log in, come back and search and browse our annotations in other areas. And so understanding this, the difference between the client and the server is one of the kind of fundamental things to bring to this conversation. And so what we're going to talk about in this next part is about ways in which users are able to access the annotation client, right? So Hypothesis is hosting a kind of default server environment that's a reference implementation of an annotation server. And the easiest way to be able to take advantage of that kind of service that we are offering to the world is to equip yourself as a user with the client so that you can go out and start annotating. And those annotations would be stored in Hypothesis default server environment. So there's a couple of different ways that folks can get those, that client, that Hypothesis client to start annotating. There's ways for people to just share links to annotations that they've made that then even if the people that they're sharing with don't have access or know about Hypothesis or annotation, they can click on that link and it will bring up the document that's been annotated, the annotation and the client to start using it. They may not have an account yet, but they can at least start to browse. So that's like the sort of easiest way that people end up getting acquainted with the client.  There are some robots who beat her up but just barely so. She equips herself by having a browser plugin and so she carries the client with her to every website she goes to. Well, what we want to talk today, though, is about from the publisher perspective how you can embed the client in your publishing property in your website or platform so that every user that comes to your site has the annotation capability already waiting for them there rather than having to know about it in advance, have a link or have the client embedded in their browser. So embedding the client in the website is the easiest way for a publisher to deploy annotation on their website and take the next steps to kind of enable annotation for all their users. And so it's really easy. I'm a non-technical person. I have a little bit of technical background, but it's the kind of thing that I can do. In fact, I've integrated hypothesis on my personal blog and it was really easy to do and just walk through the steps of how that happens. So in a basic implementation, which there's no cost to do, there's a simple step for the integration piece, which we're just about to talk about. And that brings all the kind of basic primary annotation capabilities to all the users who show up in your publishing website or platform. So let's just take a look at what the integration looks like. And so to embed the client in a website or platform, there's really only one single step that needs to happen. And that's a single line of code that we just showing you the example here on the screen that reaches out and grabs the default standard hypothesis annotation client and brings it into your platform so that every user has it available to them as they're browsing your publications. And so there's a couple of different ways that you can get this line of code into your into your platform, and we'll talk about those in just a second. But the point is, is that, you know, it's much like adding Google Analytics or some of the other tools that are out there that are offered to the to the web. It's just a matter of embedding the single line of code into your platform. And as we go along, if there are questions, feel free to feel free to use the chat or the question feature in zoom to to queue them up and we'll we'll answer them when we get to questions and answers. So now obviously, if you want to embed the client in your in your website or publication, you know, the technical folks who steward that for you, whether it's you or someone else can probably just manually add that line of code in. But there are several different platforms that already have a kind of native module or plugin that adds the hypothesis client to to their platform. And you can just see the list here. It's not every platform that publishers might use, but a couple of key ones that are more commonly used that the open source community or hypothesis have collaborated to make these plugins so that they can be easily embedded into these systems. So you think things like Drupal and WordPress and OJS and Omega. The other way that some publishers are now integrating hypothesis is by working with their platform hosts. So with folks like out upon high wire and gender and silver chair are looking to enable annotation for any of their publishers who are who are using their platforms. And so if you are a publisher who uses one of these, these sort of, you know, more universal publishing platform providers, talk to us and we can we can help guide you to the way that it's easiest to work with that publishing platform to get hypothesis integrated into your into your system. So that's, you know, just to recap, there's a couple of different ways. But this is how easy it is. There's a line of code that needs to appear in your website. And that will make the client appear for all users. And then there's a couple of easier ways to help that line of code appear in your platform if you're using one of these particular systems. Now there are configuration options, and we're not going to go into a bunch of detail about all the different sort of nuances that you can add to to the client once you get it in there. But just as an example, some folks want to make sure that the annotations don't kind of interrupt the initial viewing experience of their publication. So they want the highlights that are anchored to the annotations to be hidden by default, and enable the user to just turn on highlighting if they open the client from from its controls and start to actually read the annotations. And so with just one simple configuration line, you can you can make sure that the highlighting is hidden by default. And there are other configuration options as well. We'll be distributing these slides to all the participants as we go along, so that you can have all the links to this to this work. And so just to remind folks, so you if you've taken this step right of embedding the client into your, your, your publication platform, what does it bring you right? So it brings all your users a universal client client that allows them to do all the kind of standard capabilities of an of highlighting an annotation that that hypothesis offers. They would in order to actually start annotating, they would need to create an annotating account so that their annotations could be stored in the server environment. And in this kind of default basic implementation, they would be creating a hypothesis account, an account managed in the hypothesis namespace for our default server environment. And we can talk about other options. But in this kind of free basic service, you can get all the capabilities for all your users. And they, they would walk in the door with all the capabilities of the client. Behind that client, right, each user and group that they might annotate in also has a very robust annotation dashboard that kind of brings all their annotations together into a collection that they can browse and search. Using various parameters, they can view annotations and collections of tags or through time. And they can see both their public annotations, their private annotations, they can share their annotations from there and they can jump back to the context of the pages where they made the annotations. So there's a very kind of rich dashboard environment for people to look at their full collection of annotations. And then a couple of other points to make about that, what this basic service brings to your, to your, you know, your publications if you embed it. So we're just about to announce work on the completion of annotation capability in EPUB, which adds the third major publishing format to the capability set. So regardless now of whether you publish your documents primarily in HTML, PDF or EPUB or all three, you can now enable annotation for your users in those formats. And here's the interesting thing. Not only can you enable annotation, but if you publish the same document in a variety of formats, there's a kind of architecture of document equivalents behind that that enables folks to annotate in a PDF version and have those annotations also appear in a canonical HTML version, for example. Users who make annotations in a PDF that they've downloaded to their computer that has the same fingerprint as the canonical PDF on your website, those annotations will also find each other because they're hooked together behind the scenes using a PDF fingerprinting technique that allows PDFs to know or it allows hypothesis to know that the same PDF is being annotated multiple places. So there's kind of a rich array of different ways that that documents can be annotated in different locations and in different formats. The other thing that's sort of included in this easy step of getting annotation up and running on your on your platform is behind hypothesis, there's a full blown API. So even without doing any more technical work on your side, other than that, you know, making sure that there's that one line of code in your system. There's an API that, you know, if you have technical resources and you want to do things that go beyond that embedding, you can orchestrate different kinds of calls to that API and do a variety of different things to annotations programmatically behind the scenes. So if you wanted to take steps beyond what the basic service delivers, the API is sitting there waiting for you to use as well. And so that's, you know, that that is the kind of quick overview of the rich array of basic annotation capabilities that are delivered to you. If you just add that single line of code to your property. So I'm going to hand the baton back to Heather, and she's going to talk about taking integration a step further and some of the more customized things that you can do. I think you might be muted, Heather. Thanks, Nate. Yeah, so as Nate mentioned, because we are open source and permissively licensed, you can go ahead and, you know, take significant action on your own part. But if you want something a little bit more custom, or if you are not entirely comfortable taking, you know, those steps on your own, we're happy to help you. Can you go to the next slide, Nate? Sure. So with the customize and supported implementation, you get everything that Nate already explained as a part of the basic implementation, but will help you do the integration on your platform. We have a very simple pricing model that's based on the number of documents that you publish in a year. And there is a volume discount. So the more pages you deploy the client across the cheaper that it gets. If you're, if you wish, we can also hook up to your account system so that your users do not have to create a separate account. And you know, the single sign on is handled and annotation happens seamlessly. A lot of publishers have asked us to create for them those layers that Nate mentioned, a publisher branded and moderated layer. So it's clear which is the authoritative layer for the publication. There's a number of UI customizations that we can make. And we have a program to ensure successful training and rollout. We also offer support and open source maintenance. Let's go a little bit deeper. So the publisher groups, as I mentioned, they are customized to meet your brand. You can decide as a publisher who will be creating annotations and who will be able to see them. So for example, if you want to use annotation to create additional content, whether that's on by your authors, whether that's passing along reviewer comments, or invited experts, you could limit the annotations to that group, but it would be visible to the public. Or if you're really more interested in a post publication conversation layer, you can set up one that anyone can enjoy can join and create annotations of moderation capabilities, certainly possible. And you can choose how the client will be visible on your screen. For example, if you would if you want a button to appear that lets folks know that annotation capabilities are possible, and they click the button and that opens the client, that's one possibility, or the client can be open with the annotations visible by defaults. All of that is completely in your hands. We offer a number of UI customizations so that you can fit the sidebar best to your platform. That includes options and colors and borders, typefaces, how wide you want the sidebar to open to in case it's not covering up your content, for example. Nate mentioned the visibility of highlights. We also have a number of options for calls to action, so how you would let your users know, again, that annotation is possible on the page. Next slide. I think the most important thing to note is we don't expect you to do this entirely on your own. If you do deploy hypothesis yourselves, we're also happy to help you with a roll out and ongoing collaboration. And certainly, we want you to be successful and achieve the goals that you set out from the beginning, so we always talk with our publishers about what they're trying to achieve. We can put together trainings for your internal staff. For example, if the journal editors are not clear on why annotation might be of interest to users, then certainly that cannot be communicated to authors and other external stakeholders. So we can do some internal trainings and record those for you, as well as end user oriented trainings, again, materials that can be available via your site as well as ours to help people get started. We can work with you to talk about how best to engage the folks who will be the key annotators on your content. We can tell you success stories that have happened with other platforms, techniques like getting authors to annotate their own work, invited experts to seed the conversation, for example. And we're happy to work with you on a coordinated program, both on the roll out and subsequent launch materials blog posts. We'd love to talk to you about the possibility of presenting together at upcoming industry events. And as annotation exists on your platform for a little bit longer, we'd love to explore with you unique case studies and maybe put together some white papers that we can in turn share with other communities. Nate, would you like to take this one? You're muted, Nate. So one of the one of the sort of background activities that hypothesis does with our collaboration partners when we're working together closely is we basically become like your support provider the way that you would with a typical commercial vendor and provide all that kind of functional and technical support, not only for your team, whether they're technical or editorial, but also for your end users. So it becomes a kind of help desk service then for you so that you don't have to have your support team train up in all the nuances of annotation. Behind the scenes hypothesis is always maintaining this open source code base. And there's a link here that that will share out to a deeper technical dive for those of you who are, you know, more technical and want to understand a little bit more about the architecture behind it. But so as an entity, we're stewarding the open source licensing, so all the contributions for that, making sure that the open source contributions that are made by various developers are properly attributed and licensed on maintaining that code base for security issues. And, you know, as technology advances, it needs a kind of care and feeding and then advancing development on it. So when we roll out new capabilities, they are added to that code base and become available to a wider array of folks. And so for instance, this publisher group capability that Heather was talking about is a relatively new capability that is now part of the open source code base. And it does need some extra work in order to be enabled for folks. It doesn't it's not part of the default package, but it is there as something that that can be used by everyone. We're also part of the the group that works in general on standards and operability for annotation. So, you know, part of our nonprofit mission is not just to serve the hypothesis annotation community, but also to move forward work on annotation in general for for everyone. And so we were we were definitely part of that group that worked collaboratively to establish the W3C standards on annotation and we continue to work in those fields to advance annotation across the board with with other folks. And we do that really in the context of a wider community. So many of you may already be aware of or even members of the annotating all knowledge coalition, which is a kind of community group that we pulled together of now I think it's over 60 right Heather over 70 over 70 organizations that have come together. And I can show you some of those are if you're more if you're interested in more detail around advancing they come together around advancing annotation as a as a general practice and technology. And once a year we hold an I annotate conference, usually in the spring in the May time frame, where we bring together people not only from publishing but from other fields like education, journalism and research science and scholarship, who are all working on annotation in various ways to kind of have a have a deeper community experience in a live live environment. Just a small plug. Heather will be in Berlin at the force 2017 conference on that's coming up. What are the dates for that, Heather? So the the force conference is the 25th through 27th. We're holding a face to face meeting for the annotating on knowledge coalition on the 24th of October. So if you want more information on that, we can we can provide that as well. We'd love to see you, especially if you've got a use case that you want to present. Great. And so there are other things that we do across the community. There's really vibrant things going on now in a sort of news credibility arena. And there's a variety of different organizations that have sparked up around that pesky problem that we're involved in as well. And so there are other examples. But the annotating on knowledge coalition is really the kind of community group that that we work with in order to kind of develop the publishing and scholarly annotation agenda, if you will. So we'd love to see any of you who are going to be at 417 to also be a part of that annotating on knowledge meeting. And that's really going to be an interesting conversation focused on the fair principles for annotation and data in scholarly publishing. So that's that's the end of our presentation. And so we wanted to move to questions and answers. I've got one question queued up here in the queue that someone's asked that will address. But if you in the course of this presentation have come up with another question and you just like to ask it via text, you can do that either in the chat or the question and answer tool and zoom and we'll address it. If you would like to have a little bit deeper conversation. So for example, you've got a particular publishing platform or scenario that you'd like to talk about in more detail. We can actually promote you to status where you have audio capabilities and can can be part of a conversation. So we're getting a couple questions queued up now and I'll address them and then I invite Heather to speak to them if that's if that's the right thing to do, which often will be. So one of the first questions that we had was about we mentioned that there are bots or robots or machines annotating in hypothesis platform. And so could we explain that more and maybe give an example. Did you want to take that one Heather? Sure, probably the largest example and there are numerous incidents out there is one of our staff members, Mary and Marton, is a neuroscientist and about I think about 125 of the neuroscience journals use things called RRIDs, research reference IDs. And these are particularly important for folks who need to reproduce experiments. They may need to know a specific stem cell line for say a mouse that they're using or where a particular reagent was purchased. So these RRIDs are typed into the papers and there's an external database that you can go and look them up. What the folks at UCSD have developed together with Mary Ann is an annotation robot called Cybot, which when they load up the papers and the browser it automatically looks for these RRIDs and then it actually pops the resolution from the database up in the form of an annotation card on the side. It's got all the information on that RRID. It's also got a tag so you can explore which other papers have referenced that same RRID. So in this instance the annotation capability is almost incidental. It's the way that the information is being retrieved and displayed. We've also had conversations with other publishers who have entities embedded in their publications and these may well be linked to an external database but wouldn't it be great to have the opportunity to have the information from that external database appear on your page so your users could see it without navigating away from the content and we'd love to explore other use cases along those lines. Another really interesting case similar to Cybot came up recently in conversation with one of the publishers who's deploying Hypothesis. So there's a kind of collaboration in non-profit organization called Refigure that is focused on identifying when figures or diagrams or pictures are used in scientific literature in more than one place. So it's a little bit like the Cybot RRID question is you know is this resource in this case a picture a figure or a diagram being used in multiple scholarly works and so we're now in a kind of preliminary conversation about the idea of having the ability for an annotation layer to let you know if any figures or pictures in the scholarly work that you're reading are also used in other scholarly works and what those are. So it's another way to use the annotation layer to sew together scholarly works kind of across the whole work. So there's a couple of other questions coming up. Folks have asked if we're going to share the slides and yes we will when you registered for the webinar you submitted your email and so we'll email you a link to the slides so that you can share them as well as to a recording for the webinar as a whole. So we will definitely do that and you'll get that in your email. It will also be posted on our website in a blog format similar to the blog page that you probably visited when you registered. There's a question too about from Beata about can different formats of content be related by DOI so that annotations made on the HTML version would be displayed on the PDF and vice versa and yes I glossed over this a little bit. Did you want to go into more detail about that Heather or? Sure I mean this so this is already happening you know in many publisher websites when I when I go to do demos an annotation will that's made on the HTML will appear on the PDF and one of the ways that we relate documents is via citation DOI tag. Another way Nate had in the slide is the is there is the rel canonical rel tag to show that one URL is equivalent is equivalent documented another URL and there's a couple of other ways you know that we can relate documents as well. If for some reason your particular website the annotations made on the HTML do not appear on the PDF usually we can look you know really quickly at the metadata and kind of make a determination as to why that's not happening usually it will happen without any additional work to be done on the publisher side but sometimes you need to nose around a little bit but certainly yeah we're excited about that capability. Hey is this an opportunity to mention the crossref collaboration as well. I'm sure we're in conversations with crossref to determine what particular types of do is for example of what types of annotations might be useful to assign a DOI to in a related conversation we're also speaking with the folks at at orchid to see if folks might be able to indicate that they want particular annotations to connect with their orchid profile so DOIs is one way that that that can happen all of the annotations that are made in hypothesis that are in the public layer so visible to anyone are being included in the crossrefs event data project so those annotations will be indexed by google and surfaceable and discoverable so it's a great additional way for users to find your content if annotations have been made on that. Right okay um another question um we got actually a couple of them now so um keep them coming this is a great conversation um so uh and i'll take this one heather um a user had asked if i'm sorry an attendee had asked that the users are annotating on a publisher's website could they download the pdf with the annotations and so um here's one of the uh sort of interesting conceptual things that that took me a while to get through my own my own had um before i could really understand it the annotations are not embedded in the document they're served uh to the document because the annotations are related to that document's unique identifier whether that be a url a doi a pdf fingerprint or whatever it is and so it's not as if the annotations are embedded in the document and need to be downloaded with a pdf version it's rather that if you download a pdf that has been annotated that has a specific fingerprint um that uh and you open that pdf in a browser environment connected to the web then a hypothesis can uh look through its database of annotations and find any that are related to that pdf in its unique fingerprint so um it's not it's the the annotations don't travel with the document they are hooked to the document by some kind of unique identifier and that's what allows um a pdf that's being worked on in one user's environment to have uh contact with annotations that might be being made on that same pdf even though it's in use on another user's computer uh in a different environment as long as that pdf has the same unique identifier in it yeah one um you know sort of additional thing to add to that we have had publishers who have um said that it might be useful uh to offer um readers the opportunity to download a pdf that um has annotations included um so with our api if that's something that was important to you depending upon how you serve up your pds on your site that it may well be possible for you to do that with just a little bit of of work for example we have peer review integrations um underway um one of them is with ejournal press and in in addition to making peer reviewer comments available to authors um via the annotations on top of the document they have enabled the annotations to be uh presented together you know with pdf so there's a lot of options and we'd be happy to talk with you about how that might be possible if you think that that's a use case that would be well received by your readers yeah just to point out um heather's email there is on the screen and so she's certainly uh the best first point of contact for any kind of conversation that will go beyond this webinar uh so another question that's come up is if we could talk a little bit more about the different kinds of groups and the permissions that are associated with them do you want to take a stab at that heather yeah so um you know first when we talk to publishers we we try to figure out what uh you know they want to achieve with groups i mentioned uh briefly that some publishers see annotations as additional content and they want to limit the creation of annotations to um you know folks who are you know credentialed with the document authors for example or um only the the publisher staff so we do have um you know permissions that we can provide um that will you know fulfill those purposes as well as um different levels of uh accessibility in terms of who can create an annotation whether it's it's read whether they can only read them or whether they can reply whether they need to log into your website to reply you know mechanisms for joining a group um in the peer reviewer context for example um there are multiple roles that need to be represented um whether someone is uh is the editor uh reviewer one reviewer two um if it's a if it's a blind interview you know and the author and so different um roles can be assigned to meet that uh flow um so you know it's it's a there for each of the private groups for example that you can make on hypothesis now the person who creates the group serves as the admin for the group can moderate the group for the publisher group um publishers designate moderator to take care of um you know any problematic you know annotations that that come up so it is um it is very granular and you know we can work out something that will meet your needs yeah and i think the uh the the sort of general takeaway from that is the idea that um you know each group basically has its own annotation layer if we go back to that metaphor of annotations living on layers on top of documents and so the configuration of those groups is very flexible as uh how there was pointing out about who can write to that layer and who can read that layer or see that layer and what kind of roles they have so the idea is not so much to have um you know only these set kinds of groups but to be able to enable various kinds of configurations of groups that have different kinds of permissions depending on the need that a publisher might have uh so um i will take this one uh so have um implementers normally embedded hypothesis with their entire portfolio or have some made it available on just a portion and do we support trials so um so technically this is uh anything is possible technically right because if we go back to the simple integration it's about whether or not that single line of code appears on a particular web page for example um to have the client enabled and so if one wanted to make annotation available and only a single um say publication on your site it would be easy enough to do as long as you could insert that code only on that single page some of the plugins have the capability to um deliver the client granularly in that way like i know for instance the wordpress plugin has some controls that allow you to decide um where on your on your platform you want that delivered so it's certainly possible to deploy the client in only specific environments um you know you might just choose a single article a single journal um depending on a single book depending on what it is that you're doing so it's entirely possible and it really comes down to um you know what the details of actually getting the client code into your platform would look like um so uh so and in the sense of supporting trials well the basic implementation implementation that we're talking about right is um is completely free uh and you can go you can walk away from this webinar and implement it yourself uh later today if you want um if you have that that kind of access to your platform to do that um so uh you know there's a way to start a trial if you will of of the basic service without doing anything more than than just walking away with the documentation that you'll receive an email from this from this webinar um the the concept you know doing a trial of the more kind of robust customized and supported um sort of model that that hypothesis is offering is is a different question and i'll see what Heather has to say about that yeah um talk talk to me uh you know send me a message about that you know um effectively as Nate mentioned because you can deploy hypothesis over just a small portion of your content and because our prices are based on um you know the number of documents is employed deployed across um you know it's a really affordable way uh to to get started um and we have got some some offers out there with some of the platform hosts you know some of you may have heard where you can try you know for a certain number of months and and decide whether they want to keep it or not so i'd say reach out to me and let's talk about a specific circumstance and maybe that's a good way to segue here because someone had asked in what our general pricing model is for that um uh customized and supported uh model uh so if you want to speak about that generally and then how people uh can kind of talk with you more directly about um specific pricing for their publications yeah i saw that there was a question in the in the chat about if you had a thousand publications um annually you know approximate what it would cost i did look this up for someone um earlier in the week who asked about the the thousand uh document mark um and as my recollection was it was about 3700 um you know i'd have to double check that so uh you know don't hold me to it off the top of my head but um you know it's designed so that smaller publishers can participate um larger publishers who just want to try things out and and either different types of publications or or certain journals where there may be a desire express free annotation you know can do that so um we're happy to work with you and find something that meets your budget yeah and the costs are relatively low anyway and those costs are annual uh right it's an annual support and subscription agreement great so we have uh just kind of um happy to take more questions but we have just kind of one uh group of questions here left that are related um so have we ever thought about giving pub lawns to annotators the score point system to reward reward reviewers so that's something you've uh you've heard about heather yeah i mean we've we've talked with publishers um particularly in in the area of how to determine success with annotations one way to determine success might be for example number of annotations made similarly we've talked with alt metric about including annotations out as an alt metric you know what does the number of annotations on a piece of content uh you know show about it so um you know it is something that you know we'd be interested in exploring further we're also working with some some groups to actually try to look into the content of annotations a document may have a lot of annotations to say that are responding negatively to the to the content um so can you make a kind of sentiment analysis of annotations um so i think um you know we'd like to try out uh anything that um that makes sense and and kind of see where it goes that's the one of the advantages of being a startup and you know being open source and community driven so we're we're out of questions in the queue certainly um we're happy to stick around and talk more um i noticed a couple of people have dropped off um but if anyone else has a question we've got one more uh uh is hypothesis financially sustainable and can we share something about our finances so hypothesis is grant funded it's been around for about six years so far um some of our funders are the Mellon Foundation, Omidyar Network, Shuttleworth, Sloan, Helmsley um so we're we're well uh you know well taken care of in that regard we did make a decision last year to transition to um be revenue supported um so that's something that our early publisher partners and education partners which will be the topic of another webinar um you know are working with us um and so yeah we're going to be around for a long time yeah and the other thing to say there so right so we just talked about pricing right so that our financial sustainability model is built on the idea of um you know offering real value to partners uh in exchange for uh financial contributions that keep the non-profit open source project um uh kind of sustainable and but the other point about this is that unlike some sort of commercial startup operation that um you know could kind of lose its financial stability and go away um if we think about the exit strategy that hypothesis offers by uh our entire uh code base and all of the documentation that are related to it are completely open source so let's say even in the worst-case scenario where the organization of hypothesis itself went away um all the resources and assets that hypothesis had worked to develop would still exist and be publicly available for continuation in a variety of different ways right a commercial entity could take them up and move them forward uh a publisher could could you know bring all this work in-house uh and and do it themselves so the um the possibility the open sourceness of it just to be clear oh yeah no it's not possible to make it not open source but because it is open source um hypothesis as an ongoing entity doesn't need to persist in order for the technology to persist yeah but i should say um you know some folks have asked us about the business model given that you can deploy hypothesis yourself and not even tell us um and so we usually say take wordpress as an example 20% of the content on the web um is deployed on on wordpress and it's free to use but a very small percentage um of entities would like a more customer enterprise version of wordpress and that small percentage of the larger pie supports a company with more than 700 employees so that's the model that we're working towards yeah and the point is is um you know our primary mission is to advance annotation so the sustainability of the organization it only needs to happen to the degree that it can enable us to advance annotation uh technology and practices overall and so we're not we're not in a position where we need to look for the kind of profit that a for-profit uh entity would need in order to um be appealing to investors so that that enables us to have um a lower threshold for sustainability um so a couple of other questions just on the open source points though has anyone forked the code in the way that we're talking about and I think the answer to that is it's a clear yes there are organizations out there that have um that are using the code and they may have forked it and are using it in ways that uh it's because it's permissively licensed they don't have to report back uh their forks unless they want to um so they can kind of take the code and run so to speak and uh go you know work in their own sort of cul-de-sac of code and continue to absorb new innovations that come through the open source channel um they're not required to share back what they do because of the permissive licensing um so there are organizations that have done that I don't have a ready example at mind maybe Heather does um I don't have one right at hand but I know that it has happened when when folks do you approach us and ask about forking the code we always try to discourage that because of course subsequent developments they need to go back and you know pursue those separately and you know they wouldn't be supported by our main code base so in order to take advantage of the continual development and the community development the code we we discourage it but certainly um it happens um I see there's another question are there open source contributors outside our paid staff too many to count if you want there's there's some slack channels um you know that you can join and that's where a lot of the developers um you know bring their their contributions and their questions and it's just a really vibrant community uh and and maybe Nate when you um include the slides we can put information on how they could join those those public discussion channels so they can really see what's going on in the wider sense yeah and I was just going to mention um one of the greatest examples I think uh recently of that kind of um you know multiple um multiple folks participating in the open source development is the partnership that's recently uh kind of come to fruition around bringing annotation into EPUBs uh so that actually involved um partners including a scholarly press a university uh a software company that's been devoting its itself to EPUB technologies and a foundation um the nonprofit foundation that's also focused on EPUB technologies and so there's a constellation of folks oh and an additional open source project as well that makes it an open source EPUB reader um EPUB JS and so there was like you know you know five different participants um several of them contributing developers to a common effort um and so I'm just going to throw into the chat here a link to our the developers page on our website which kind of gives you access to all the code base the different community technical communities and Slack channel that Heather was talking about and things like that so and just one caveat about the developer Slack channel um we are just about to transition that to a new Slack environment that has unlimited uh space for users and channels so that's just about to get a little bit more robust the other thing that I would invite people to do um is uh we had spoken about um the annotating all knowledge uh coalition and so if you're a publisher and you're not already a part of annotating all knowledge um I'm going to share the link for it here in the chat as well and we'll make sure that will be a publisher so if you're not a publisher I'm sorry joining you may join as well oops sorry I I just shared the same link again that wasn't really helpful was it it's free to join um we just ask a couple questions about you know your your kind of commitment to to annotation we have we ask you to collaborate with others um and and preferably do that annotation in open source um interoperable um standards based way um so that others can benefit but we do have um uh commercial entities in the group that are not open source so those um joining requirements are you know flexible and I'll just point out that the annotating all knowledge coalition a k as we call it also has its own kind of slack community environment which is also free to join and that's a great place for a lot of this collaboration but technical and non-technical happens uh so I just put a link into uh where you can join that slack if you kind of want to continue the conversation um in the broader annotation community uh so we've run out of questions again and we're actually getting close to the top of the hour so we don't want to keep anyone if you want to get on with your day again if anyone has an additional question uh Matt uh saying that um slack is full um so that other slack channel will be the place to participate yeah Matt if you've you've hit exactly on the problem of why we're creating this additional slack environment so um uh and that's um it's it's coming out soon right yeah and part of the reason is we had uh we had uh it tied to a slack environment where each user you know has an annual fee and there are too many people to sustain that so we're moving it to a slack environment where there's no fees per user uh we'll send out the information on the new slack channel when we send the webinar slides and recording so exactly should be ready probably Monday at the latest well thanks everybody for joining this is the second in our series and we look forward to perhaps seeing you at in future webinars and maybe meeting you in person at an upcoming event