Allow me to introduce my speech with a quote. Open the world we live in today needs the values of religion, which holds the virtues we must arm ourselves with to be in the good graces of our Creator, God Almighty, who which strengthen in us the propensity for tolerance, love and cooperation marked by the seal of human charity and piety.  This fundamentalism does not feed only on disenchantment with the world as much as it feeds on the failure of happy modernity and rather than an opposition to globalization. The religious fact was transformed throughout the 20th century and its manipulation, not to say its instrumentalization for hegemonic purposes, has diverted the very nature of its vocation to be an actor of peace and reconciliation, peace, reconciliation and dialogue. The international scene is undergoing profound upheavals today. Identity conflicts are linked to the rise of social injustices. At the same time, the perception of inequalities is on the increase. In this context of insecurity, religion can have a positive role if it becomes able to reclaim the nature of its own message, a message that has been diverted, a message that has been violated, a message that has been trapped by war-mongering of the fundamentalists. Although it is true that there are many misunderstandings on religious fundamentalism, religion has without any doubt been used as a means for political ends or for personal interests that are inherently contradictory to religion. Hence, it is necessary to notice the imperative need for dialogue in order to meet or respond to contemporary conflicts beyond the religious nature or not of these conflicts. Dialogue is not a negotiation. It is not a controversy either.  It is about a characteristic of the human being through which the relational quality of the human person is constituted. To understand what is happening in our world today, we need to think about the role of religion in humanity. What some call the return of the religious or the God's return in a world that is secular world but witness a reactivation of an essential dimension of humanity which even if it is connected to identity is not. However, identity seeking rather as much as it is metaphysical and spiritual. In this sense, the function of religion may appear obvious, but they are nonetheless crucial for human existence and human coexistence. Religion is connected to human concerns and helps us develop answers to essential, existential questions related to life and its meaning, truth and eternity. Religion is connected to the identity of peoples and civilizations. This is why the religious traditions of others should not only be known, acknowledged, but also appreciated. This knowledge is a prerequisite, a necessary prerequisite for any kind of dialogue. Religion has participated to the achievement of great cultural and civilizational adventures. Religion is a factor, an essential factor of the peace process. As written by St. Paul, God is not a God of disorder, but a God of peace. This is what the Holy and Grand Council of the Orthodox Church in June 2016 reminded us the importance of interfaith dialogue. The frank interfaith dialogue contributes to the development of mutual trust in the promotion of peace and reconciliation. The Church strives to make peace more tangible. The true peace is not obtained by force, the force of arms, but only by love that has, that does not seek its interest. This is type six. The balm of faith must serve to heal and cure injuries, but not to rekindle new hatred. Ladies and gentlemen, dear friends, Morocco has always been a country that was precursor in terms of interfaith dialogue. It was at the vanguard of the fight against fundamentalism. As you will know, the Mediterranean Basin has known for many past centuries the Pacific cohabitation between Jews, Christians and Muslims. This experience shows if we needed to bring proof again that the believers in different religious traditions can live together around a common project that of the unity, humanity's unity and peace. That's the unity of humanity and the unity of peace. Among the big religious institutions, the ecumenical patriarchal of Constantinople occupies because of its history a unique position along the upheavals, traumatic upheavals that it has been faced with, two millenniums. Our patriarchal institution has always remained active. A testimony of this is that it is possible to survive and to pass on a testimony of civilization throughout the ages because of its existence. The Orthodox Church contributes to give meaning and hope in a world dominated by anguish, a world which is looking for its path. The legitimacy of religion today depends on their clear attitude towards the protection of the liberties and human dignity, human liberty and dignity, as founding principles in the establishment of peace, which is also at the center of interfaith dialogue. No challenge, whether it be personal or international, can find a solution in solitude and isolation. We all need each other. We need to rely on each other because we are relational beings. We are people of communion who, as we move on, become true actors for peace. We cannot, of course we cannot but be delighted by the this meeting which is held the 10th edition of this World Policy Conference which is being held in Morocco. By inviting me to give this speech at the opening session, the organizers whom I would like to thank, I would like to thank in particular Mr. Dumon Brial for his friendship and I would also like to highlight the fundamental importance that religion has in the thinking about the affairs of the world or to say differently talking about the international stakes. The Ecumenical Patriarchal, which we have the honor of representing here today, thanks the organizers and wishes them full success in this endeavor. Thank you for your attention.


All right. Good morning. Welcome to this talk. I'm going to be talking about some work that I did over the summer on API client libraries. I want to be talking about, from a developer's perspective, how you're able to make a good one, how if you're a developer working on them, how to make a good one, and if you've already made a good one, you'll learn a bit about how to make it better. So, before I begin, I just want to establish that these are all basically the same things. So, I'm going to call it a client library. Around Wikipedia, you'll also hear a lot about library, but what it is, you know, software that makes it easier for developers to write. So, San Francisco just got muted. You're good. Okay. So what do people use these for? They're used for writing and running the box on the keys. So, automating tasks like welcoming new users or cleaning up vandalism or identifying vandalism or other tasks that are, you know, I mean, for a while, everyone's keeping the interrelated links, the inter-language links going. Aside from, so there's bot running, there's also using it to create data sets for doing research. So you can figure out that you want all the edits by people, by this specific set of users in this time, in this namespace, and get only the information that you want in an up-to-date manner. You can also use them to write scripts to do various quick maintenance tasks, and you can also use them as the data source for a number of people have for these neat projects that are somewhere like data visualizations and stuff like that. And everyone's a couple, you can follow up, but I'll put the slides up later. So, common features of these things. Basically, the idea is that you want to, I mean, computers are for doing the stuff that's obnoxious to do by hand. And API client libraries are no exception to that. So, if you have a library that will handle your HTTP requests, it'll handle cookies for you, it'll keep track of your session data. It can specifically make the medium of the API smooth and to use. It's not always the most intuitive, it's not always the most intuitive thing to use, and there are also things which are features, but which are just a little bit, can take a little bit of doing to handle yourself like query continuations and Seusser tokens. They can also have convenience methods for common API requests just so you don't have to type out all of the parameters for the requests like logging in or specific search or getting categories. And they don't always, but they can add a layer of abstraction on top of the API. The MediaWiki API in a lot of ways reflects the MediaWiki database structure, and that can be, especially if you're a developer who's new to the MediaWiki API, that can be a little bit challenging to deal with when you're getting started. So, if you don't want to think in terms of getting a revision or getting a text extract, you can just say, okay, get me the page contents and some client libraries will let you sort of think more on that. So, how are you going to get one? Well, you can go to the list of all of the, I think, most of the client libraries that are out there. But there's a lot of them, and there's not necessarily, for a lot of languages, there's not a whole lot of specific information on the particular library. So, that's a starting point in the sort of like, how do I find them? But when you're thinking about going to choose them, you want to think about those same things that are like, what makes any token? Well, it makes it easier or impossible for you to do what you need to do. So, yeah, you figure out what you need when you compare it to what's available, and that's really simple, right? It takes a little bit of research, and it means that you need to figure out what you need, and it means that you need to have some way to figure out what you might be able to expect. And that's where standards come in as a useful tool. When you have something that you can compare, you can sort of go down the list. Does it have these features that one might use? Okay, do I actually care about these things? Maybe not, but it's a tool to help you sort of figure out what you need and what you can, what you might want to think about if you're writing one of these. For most of the rest of the talking, we're going to take the perspective of talking about someone who's writing a client library, maybe a client library, but if you're looking for one to use in a project of your own, then you can just, not everything that I say is going to be applicable to you, of course, but you can take it as a certain point for things that you might want to be looking for. So as part of my working for this summer, I wrote this gold standard for what sort of, as media-wiki developers, we want to see from a media-wiki API client library. The general outline of this, and I'm going to go through each of these in some more detail and talk about the reasoning behind the points on the standard, is that it should be easy to install. You shouldn't have to share too many gags to get going with it. It should be easy to understand. It should be easy to look at the project page and say, okay, what can I even expect to get out of this? Is this sort of impacting framework? Is this something that just handles the HTTP and cookies and stuff for me? How heavy-weight is it? What am I going to get out of this? It should also be easy to use. So once you sit down and start writing codes, you don't want to have to go, oh, this feature turned out wasn't included even though I thought it was, or oh, I need to change these defaults so that I'm complying with the policies for the media-wiki API. And if there's sample code, then it's so much better. It should be easy to tell what's wrong, and as a part of this sort of shared ecosystem of open-source libraries and based on the open-source media-wiki, it should be easy to improve and to contribute and to get back if you find something that you can make it work better, and so you do. Alright, so I'll start with easy terms though. I'm sure there is someone in the world who really enjoys setting up developers environments, but I'm guessing that's not most of us. So as a library developer, and I should say, most of these things are small projects.  That's not the point of this, but the point is that if you want the library that you've written and you've shared to be something that other people can use and use easily, these are things that you might think about when you're trying to make it at least. So as far as setup goes, your goal is to make getting started as smooth as humanly possible so that developers don't have to put in a bunch of time and effort to figure out if the library is even going to work for them. So starting with what you can take is just right up what you've done to get it working on your own system. And for various languages, there's a lot of existing tools that can make it easier, package managers and such. So another thing that I found is that you want to make sure the installation instructions not only exist but are correct and easy to find. It sounds obvious, but it's an easy thing to overlook, it seems. So you can also package the library for installation through package managers. So if people are already using those tools, they'll be able to just get their library through that. And you can consider making it available through various Linux package managers. That's kind of if you want to, it can be nice. But the language app level package managers are a really good starting place here. Okay, so your developer can get started with this and can install it. So the next question is can I sit down and look at this and figure out if it's outwardable and how to use it to make the project work. So what's it capable of? What are its limitations? How does it work? And what sort of stuff is it designed for? Is it designed for pulling down data to get your data sets together? What research is it designed for? Which box is it? What's the purpose? And here you can approach this from a couple of angles. So first thing, follow general principles of good API design and I'll say more about that in a little bit. When you're writing a client library, you're writing an API on top of the API. So those principles are going to apply. If someone's looking at your code, they should be able to understand it. It should be readable, it should come into those applicable, and most importantly, it should be documented. Source code is not documentation, right? It can be a place to look, but ideally you have comprehensive and accurate and up-to-date and also easy to find documentation. For me, when I'm reading documentation, I find it easier to understand if I can get a snapshot of how to use the function in a larger scope and as well as visually. So sometimes it gets lost as to how something fits in context. So if you can get an overview first of how it fits in wider context and then you can tell them that's a lot more helpful than just being like, here's the stuff and here's the parameters. Oh, yes, definitely. So yeah, when you would want to do something, not just how to use it. Yeah, definitely. And then the easy to find. If you don't already know to look for it, finding GitHub Wiki is not the UI there is not the most intuitive. So if that's where you have your docs, put a link in the read me or something like that just so that people actually know. You don't have to define the tab on the site and click that. So talking about those API design principles, the biggest one is that you want to be very deliberate about what layer of abstraction you're working on. So if you're writing functions to handle the API call in general so it's parsed the response that comes back. You want to separate those as much as possible so that people, so that developers who are using your library know where to look and have the appropriate signposts for what to use how. You also want to avoid redundancy. If you have a couple of methods that are doing the same, basically the same thing but are something different, make sure that you need all of them and highlight those differences. Don't make the developer who's using this guess. Naming is considered one of the biggest problems in computer science and that's for reasons. So for the API, names should be descriptive and they should relate to the level of abstraction that they're working on so that the developer can look at the list and make a good guess at where they want to start. And again, use your languages, idioms and conventions and all of this boils down to don't surprise your users. So that's the sort of making it easy to wrap your head around and get started. When you're writing code you want it easy to use and this sort of leads into easy to understand because you need one to do the other. But you want to make it easier to use your library than not to use it. So the benefits need to outweigh the frustrations. So that means that you want to make it clear what features your library offers. You want to, you know, clearly if it's a client library, you want it to offer access to one or more of the APIs. So media-wiki, but also if it can handle wiki data, that's somewhat different at the eye, but it's also useful. It should again offer documentation that's not source coded. It should offer the sample code. And on sample code, if you offer it, it's going to be used because programmers like to take the resources that are offered and not do more work than they have to. And when we're talking about good here, what I mean is efficient and courteous and secure. So if you can make your underlying library code efficient in terms of API calls, that's work fits. That's going to allow your developers to do that. If you have your library defaults lined up with what's expected for media-wiki API clients, then that changes that your developers don't have to make. And if you're using HTTPS for your requests, by default then that's again a choice that developers who are writing the API clients don't have to make. So here are just some of our luck with the easy to understand, but these are things that you want to consider if you're writing or maintaining one of these libraries. Okay, and everyone's favorites in debugging. Programs and native code, code has bugs, more code, more bugs. And this is just one of those facts of life. So given this, how can we reduce developer frustration in finding these things and make it as easy as possible to track down the difference between what you expect and what you find? So first, you can make the expected behavior clear. If there's a... If you have a function that has a side effect, make that clear. Don't make that a surprise. Make the bugs of the library easy to find and make it easy for developers to find what they're actually expecting from the underlying media API. So to do that, a couple of things you can do. You can include unit tests for at least the longest and most frequently modified functions in the library. So that means that if you're changing up your library code then you can tell if you've broken something or if this is just something that your users are doing themselves. How do you test that? Do you directly run it against the media API or do you have more code? I think it depends on what we're trying to test exactly. I've seen both approaches. So are you aware of the library that uses the mark? I'm trying to... The one that I spent the most time looking at the test site was Java, which is that framework. And if I'm remembering correctly, there were so much that some of it was just a test if you can get to the API and then the rest of the tests. Okay, cool. And if you're getting really clever then it's polite to just comment and say, okay, I know this is hacky, but this is the corner case I'm addressing or sort of just if you're doing something unexpected then they can edit that. And you can also just to make it easier to make it easier for developers to sort out the letters. You can link to the relevant section of the API docs for methods when that's applicable. Okay, so you have this library. We're using it. People are maybe sending in some feedback. You want to make it easy to improve. So what are things that make it hard to improve? When contributions are... All right, go ahead. Like someone sends in a full request and it just sits there for months. When projects look dead, so either... So there's no note. It looks like it might be updated sometimes, but there hasn't been anything for the last... for the last number of breaking changes to the API and it's sort of unclear what the status is. If someone's looking to contribute but there's no really obvious starting points, that can be a sort of like, well, maybe I could do this and maybe I could do something else. And there's... I haven't run into this on any of these libraries, which is awesome, you know, this is the end of the facility in this respect. There are also areas to people wanting to engage. So we lost audio for San Francisco again. Sorry. All right, this is... It's good now. Okay. So you can respond to contributions and see that even if it's... You can respond to contributions and feedback, even if it's just to like, hey, thank you. Thank you for the web reporter. Sorry, this isn't currently maintained, but I'm glad that it's been useful for you or something like that. If there's someone who's new to the project and you need to write in API clients, you can have a sort of like, welcome your developer section in your doc somewhere. One of the most important things I've found for encouraging new contributors is to document your development practices, not just your code. And if you're doing that, you can also sort of... If you have bugs or issues that you think, okay, yeah, this wouldn't be that big a deal, but I don't have... I'm not going to deal with it anytime soon. You can mark that as maybe something that a new contributor might want to take on. So I think the biggest thing here is to set accurate expectations. I mean, people are busy. Library maintainers are busy. Developers are busy. So if your library is unmaintained, say so. If it's accepting requests and keeping up with breaking changes, but there's no new development, say so. If it's underactive development, that's cool. Say so. Beyond being good as yourself, you can also set expectations for respectful behavior in project-related spaces. If you're maintaining it, you can, like I said, respond. One other thing is that you can note compatibility with media and key versions. So it's not that you write one of these and you're obligated to keep it up to date, but it is helpful for people who might want to use it to say, okay, this works up to version 19 and that's it. So just giving people the information that they need to decide to make the decisions about what tools they want to use is the most important thing here. You want to respect your own time and you also want to respect other people's time. And just for the sort of legalities, if you actually release it under a free license, no one has to worry about there not actually being a license to say what they can and can't do with it. So in general, there's code-related ways for usability and there's ways that aren't strictly code-related. So to keep up to date with API design, keeping those levels of abstraction in mind, testing appropriate to what you want to be doing. Use tools that are available for you. So to keep up to date, you can use automatic tools that pull the documentation out of the comments. You can use package managers, et cetera. And you can have good defaults and good examples in the code that you wrote. Things that are not code as such is make your intentions clear, communicate clearly, make those examples clear and usable, and have documentation and have it accessible and readable and with context, what you're using, how you would use it, the rest of that. And pretty much all of this comes down to respect and empathy.   These are mostly for people who want to follow up with the slides. There's the client code page. There's evaluations for about 12... so far there's evaluations for about 12 libraries compared to that gold standard. If you want to improve, if you want to add to those, then please do. Larger library projects might have a list or IRC, there might be presentations or how to use them, developerexperience.org has a lot of good links on thinking about developer experience because developers are people too, just like software users are. You can also look up documentation tools for your language. General API resources, really great place to help get your head around how it works and what the options are. Various documentation. Dev.wikimedia.org is in progress, but when it's up, it'll be a starting point for you to engage with development using the API and similar, and there's the mailing list. So, yeah, just a couple of quick ways to get involved. If you do use one of these API client libraries, you can help evaluate these especially the PHP ones. After I finished the work I was doing this summer, I had a couple of inquiries about whether I was planning to do any for the many available in PHP and unfortunately that's not something that I'm working on, but if it's something that you are, that's good. Offer feedback and you can contribute to more documentation. I do want to acknowledge a handful of people. I was doing this work as part of my internships through the free open source software outreach program. My mentors for Simona, Harry, Karisra, and Salah Fahin and Redrush and Roland and Dean were giving me a lot of helpful advice as I was working on the project and Kijil helped run the project and make sure that everything went smoothly. So thank you very much, and if you have any questions I will ask them. Is there anything for me? If you're going to hang out, you can ask any questions you have directly. Max, if you have anything, can you go ahead? As an API developer, I can just add a couple of words. We are doing a lot of deprecations in the API, so we recommend you to use libraries that use the JSON format and if you're developing a library that relies on something else we recommend you to think about migrating to JSON and another thing libraries should set the user agent clearly sorry so that if something goes wrong, people will be able to see from your user agent that it's a bot and ideally whose bot this is. And if you can include a method to generate a user agent given the contact information and similar that's even better. Ideal client library sets its own user agent header and allows you to add the client information to it. That's it from my point of view. Anything else? So I was just looking through that API client code page on Meta and I didn't see a summary of the ratings that you gave. Is there a table with a row per client library that we can reference? The information right now is just in the individual evaluations page but that's a good idea to have something that people can look at at a glance and figure out if it meets the basic things they need. As an API client developer I really love to get a quick overview and updates on what's being deprecated and what sort of standard practices are. Right now I know that there's sort of a transition about query continuation but I have no idea if that already happened, when it's going to happen. How should I best keep up on this? You should subscribe to the MediaWiki API mailing list. I'm on that mailing list but there's just too many. There's often discussions about what really affects me as an API client code developer. Subscribe to the MediaWiki API mailing list. Okay, there's a separate one. Cool, thanks. Alright, I think that's it. Thanks so much for coming. Sue, I'm going to add some links on IRC. Thank you all so much. Thank you.


Cool, thank you. So quick thank you to the organisers for having me speak and everyone for coming out on a Saturday. It's quite late where I am, but I imagine it's quite early for some of you as well, so without further ado. I'm going to be talking about the Gromovluss and Rosenberg conjecture on positive scalar curvature. So scalar curvature, if we have a manifold m with a Romanian metric g, the scalar curvature essentially is kind of a local property, which is going to compare the volume of balls in this manifold to the volume of balls in Euclidean n-space. So precisely we're going to take the trace of the Ricci tensor, but if you don't know what this is, just kind of think of this idea of we're looking at how curved the space is. So it's measuring at every single point the curvature basically. So two easy examples, the Euclidean space has curvature equal to zero and the sphere of radius r, the n-sphere of radius r has curvature equal to n-1 over r squared. So we can normalise this so that we can just say the sphere has constant scalar curvature equal to one. And notice here that the scalar curvature is constant. In general this won't be true to be a given value at a specific point, but we can kind of ask is it always greater than zero or always less than zero or always equal to zero. So for instance the Euclidean space there has it always equal to zero. And this kind of gives a very natural question, which is when does a manifold admit a metric of positive scalar curvature? And we're going to denote the curvature by kappa. And we're going to think of this as kind of like an integral over the manifold and it's the sum of all the curvature. Okay, so in dimension two this is actually completely solved. So if we go all the way back to gaspone, the gaspone theorem, if m is a compact surface then the scalar curvature is equal to 4 pi times the Euler characteristic. And this is possibly quite surprising because the Euler characteristic is a topological feature of a space rather than a geometric feature because scalar curvature is definitely something out of differential geometry. And yet here the obstruction to it lies very deeply rooted in topology. I mean the Euler characteristic is a alternating count of cells. So this is quite a surprising fact. And so here you can see immediately if it's a hyperbolic surface, so one of genus at least two, then this value is negative because the Euler characteristic is negative. And if you have a torus then this value is zero so again you can't have positive scalar curvature. As we saw this fear does admit a metric of constant positive scalar curvature and here that invariant becomes positive. So maybe we can try and generalize this idea of finding topological obstruction through a geometric problem and you might ask what about higher dimensions. So before we can do that we kind of have to go take a trip through functional analysis very quickly. Don't worry too much about the details but essentially we're going to define a couple of things. We're going to get some machinery out and then the machinery is going to get increasingly complicated but the goal is still the same to find a topological obstruction. So if M is a closed spin manifold and X is a spinal bundle we want to consider the space of L2 sections from M to X. So this is the space of functions from M to X which are a section to the bundle and they're square integrable. Don't worry too much about what the subject is but it's some kind of space which functional analysis like and it's quite easy to get a handle on. We're going to let D be the Dirac operator on this space, this alpha 2 space. Again if you don't know what this is don't worry too much but a very important fact is that the square of it is equal to the Laplacian plus kappa over 4 where this is our curvature. Now if the Laplacian is always greater than or equal to 0. So essentially we found some object, we've taken some object and we've got some operator which is kind of picking up curvature. At the moment this is still very much in the realm of geometry and we're not really looking at this topology but we're going to get to how they connect. So if kappa is greater than 0 this D squared is now invertible so D is invertible. So we can define an index which is going to be the dimension of the kernel of D minus the dimension of the kernel and of course if D is invertible then this is 0 because the dimension of the kernel and the dimension of the kernel are 0. So the corollary of this originally due to Lick-Narrow-It is that if the index is non-zero then M cannot admit a metric with a positive scalar curvature. But we're still in the realm of functional analysis here, we're not in the realm of topology yet. So quite a famous result due to Atea and Singer is the Atea-Singer index theorem which states that if M is a closed spin 4k manifold then the index is equal to this A hat genus of the manifold. Now this is some quite high-powered topological gadget which you get out of the characteristic classes in the corollary of M. But the point is is it's something you can compute. If you're given like a CW structure on a manifold you can just sit there and you can in principle you can work out what this thing is. You can just sit down and compute it and then you know whether you're going to get a positive scalar curvature or not. Admittedly it's a lot harder to compute than the other characteristic but it is computable. So that's kind of what we want. We want something which is very canonical to the topology of the space and not to the geometry. Okay so how do we get more general? Because we know that this was only in dimensions 4k. So Rosenberg introduced something called the Alfven variant and this one's a bit more a bit more tricky to digest. But essentially we're going to take a closed spin M manifold and G a discrete group. We're going to take any map from the manifold to BG the classifying space and then if M admits a metric or positive scalar curvature the class which somehow ends up in this real k group of the group C star algebra is going to vanish. Now this class begins life in the spin borders and group and it factors through a bunch of different maps. But the key point is there is some class which has to vanish. So to break this down a bit more nicely we have a class which lives in some homologically invariant of a group and it vanishes whenever there's a metric or positive scalar curvature. So it is an obstruction and in fact it coincides with the index of that direct operator we had before. Okay so this is great. When is this enough? Oh and actually one more thing to properly get back into the realm of topology because the k north k of a real C star algebra is still kind of an analytical thing. Bonk runs identifies this with this interesting looking thing which is essentially a kind of the finite subgroup version of EG. And we're going to take the aquavariant k theory and this is something which you can't compute. It's just the difficulty becomes more because the invariance more complicated but it's something which again you can sit down you can work this out for a given group. You can work out what the aquavariant k o of e e under bar e fin G is. This has a simpler statement though of G is torsion free. Here it just says that the real k theory of BG is isomorphic with a natural map to the real k theory of the reduced group C star algebra. Now again this is kind of there's a lot going on here but essentially we have something which lives in a topological invariant a class and we just want to know whether that class is zero or not. So it's it's something we can work out. Just the difficulty increases. The bonk runs conjecture is known to hold for a lot of groups. So this is kind of any group which you might consider the set in for positive scalar curvature. It's probably known that the bonk runs conjecture is satisfied. So for example hyperbolic groups relative to hyperbolic groups cat zero cubicle groups finite groups. These are all known to satisfy this. So most kind of natural groups you would consider. Okay so how can we turn this into something which is more general? The idea is that we take a closed spin and manifold again and we're going to only consider maps which induce an identity on the fundamental group of the manifold. And then the conjecture is that you only need to consider these maps. So if the class vanishes now then G has a metric or positive scalar curvature and if the class doesn't vanish then it's not. So it's kind of like the necessary and sufficient condition. So hopefully the idea is that this is the only topological obstruction we need to consider. So when has this conjecture been verified? Well it's known for all simply connected. It's known when the fundamental group of M is finite with periodic cohomology. So this is kind of things like cyclic groups, generalized quaternion groups, SL2P, so quite usually finite groups but not a huge amount. And also it's known when G is torsion free and the dimension of G is at least is less than nine. And then finally the only infinite groups which have torsion where it seems to be known for are fuchting groups. And there is also a counter example due to Thomas Schick with Pi-1 equal to z to the four direct sums z3. So it's not it's not satisfied by everything. You can you can find manifolds where this isn't it doesn't characterize positive scalar curvature. It is just an obstruction. So if I had more time I would talk about Thomas Schick's example because it's really nice but unfortunately I don't. So my little add-on to this is if G is either PSL2Z1 over P for P congruent to 11, 112 or a lattice in PSL2C with all finite subgroup cyclic then G also satisfies this conjecture. So if you take a manifold with one of these fundamental groups dimension at least five then you can just look at this K real K group and you can look at the image of this class through a bunch of maps which you can work out quite explicitly. And then if this class vanishes then you know that these groups admit a metric of positive scalar curvature. So for a really simple example if you take any manifold with dimension congruent to three or five mod eight then the manifold will admit metric positive scalar curvature if it's fundamental group is PSL2Z1 over P. So that's kind of a quick application of this theorem. So I mean my immediate question is why only P mod 12? Why is P only congruent to 11 mod 12? So I'll say a few words about that and then we'll wrap up. So a group G has property M if every finite subgroup is contained in a unique maximal finite subgroup and NM if every maximal finite subgroup is self-normalizing. So these are kind of group theoretic properties and they turn out to be quite important in the proof. So PSL2Z1 over P only satisfies M and NM when P is congruent to 11 mod 12. Essentially this comes from the way these groups can be realized as fundamental groups of graphs and groups. If you're not familiar with that then just kind of black box this along with everything else I've said. But the idea then is that when G satisfies these two properties M and NM there's a spectral sequence due to Davis and Luke which is quite useful. You can compute stuff very explicitly with it and it kind of collapses quite nicely. So the proof then we get a diagram which gets quite complicated and this diagram is directly follows from having those properties N and NM. But we're not going to worry too much about where this comes from because you could spend a long time discussing this diagram. But I mentioned a couple of things. So the map P is the connective cover. If you know about connective cover as a spectra and the sum is over finite congenital classes. But again this is kind of technical so I don't want to dwell on this too much. Oh and X is the this classifying space for proper actions which we saw earlier but we're going to quotient out by the G action. So in the case of PSR2Z1 over P this actually turns out to be a wedge of spheres which is I mean it's a very nice space it's quite easy to see that P is going to be a niceomorphism once you know about connective covers. Okay so this kind of hints at a more general theorem which is if G satisfies M and the bomb cones conjecture and all finite subgroups of the cyclic. If X is this space E thin G over G then P and this connective map is a isomorphism this connective cover sorry for all n greater than equals to five then G satisfies the GLR conjecture. So this gives a lot of examples of groups with torsion which now satisfy this and it's perhaps worth interested to note that if we go all the way back to Thomas Schick's example with z to the four plus that direct sum z mod three the whole group normalizes z mod three so it doesn't satisfy M yeah and I'm sorry it doesn't satisfy NM. Now whether this is actually the obstruction to this I don't want to say but clearly the example where it's not known this is a it doesn't satisfy NM so maybe that's interesting I'm not sure. Okay so my open question is does PSR2 z 1 over P satisfy the conjecture for other primes and I have no idea whether it does or not but I would love to know the answer so thank you for listening. Oh sorry I forgot to say that part I just started clapping. Any questions for Sam? I have a quick question. So you need like a like a passing comment about something about fundamental groups of graphs of groups could you just say a sentence or two more about that? Yeah sure so PSR2 z 1 over P is an amalgamated free product of PSR2 z over a principal congruent subgroup so apart from for P equals two and three these are just three groups so then it's a push out of like graphs so that's how you get the wedge of spheres basically for E and RG. So could you say something more about like if I if I gave you a group that I knew was a fundamental group of a graph of groups could it like fit into this narrative in some way? So you'd want to be amalgamated if it has torsion you definitely don't want to be amalgamating over a subgroup with torsion so all of your edge groups would have to be torsion free and then it's really a case of whether the groups the space is involved already satisfy this covering thing so if they're all kind of low-dimensional groups then they probably do so so um you kind of get like most three manifold groups and three or before groups from this nice. Great thanks.


Words at War presents To All Hands starring its author, Lieutenant John Mason Brown. We were two days out from the United States when I was summoned to the bridge of our flagship by rare Admiral Allen G. Kirk. Mr. Brown, I want to talk to you about your battle station. Yes, sir. You may have seen that you're listed as bridge announcer. This means that I want you to be up here on the bridge during the action and report it play by play to the men below. You know, only one man out of ten on a modern ship in combat can see what's going on. I want you to do their seeing for them. There's a democratic war, and I believe that men who are willing to give their lives for democracy have the right to know what's going on. Informing them will be one of your duties. Suppose you start this afternoon by broadcasting to the ship on the formation of the convoy. That was the beginning of these talks to the men of the spell gun, Admiral Kirk's flagship. Of course, Spellvin was not her name, as every playgoer knows. George Spellvin is a name always to be found on theatre programs when a performer does not wish to have his identity revealed. Security demands that our ship have this same passion for anonymity. But at any rate, this is the record of a void she made long ago and the part she played in the invasion of Sicily, the record as I kept it in the daily talks from Admiral Kirk's Bridge, talks that our public address system carried to all parts of the ship, to all hands. Words at War. The national broadcasting company in cooperation with the Council on Books and Wartime presents another in its series of radio adaptations of the outstanding books of this war. Tonight we bring you an unusual story. A day-to-day record reported to the hundreds of men below deck on a certain flagship that participated in the invasion of Sicily, reported by the well-known dramatic critic, author and lecturer, John Mason Brown, now Lieutenant John Mason Brown, United States Naval Reserve. Tonight you share the experience of the men below deck on the Spellvin, for you will hear, just as they did, John Mason Brown himself in excerpts from his new book, To All Hands, which he subtitles an amphibious adventure. So now, imagine yourself a seaman below deck on the Spellvin. Yeah, below, where you don't know if it's raining or if the sun's shining. Where you are, where you're going, whether you're alone or in a convoy. If you get into action, you don't know what's going on. Almost drives you nuts wondering. We were wondering about a lot of things on the Spellvin. The day we heard the voice come over the PA. To all hands. To all hands. Hands. This is Lieutenant Brown speaking from the navigation bridge. I'm here to see for those of you who cannot see what is going on. Take, for example, the present moment. In convoy formation, we are zigzagging our way for protection across the Atlantic and ocean at war. We are making several hundred sea miles a day. The ships we convoy are divided into columns, which we lead. And the rest of which, on the port and starboard sides, are cruisers. These columns are several ships deep. Trailing them is another cruiser. And screening this convoy are destroyers, lots of them. Some far ahead, serving as pickets. Others protecting the flanks. Still others the rear. With us, we have oilers. Amphibious supply ships. One sea going tugged. And over a dozen troopships. We have excellent air coverage. We are on our way. Destroyers, cruisers, troopships. Hey, this is something big. Yeah, where are we going? A dozen troopships, he said. That's a lot of troops. Yeah, but where are we taking them? We've got plenty of air protection, he said. This thing's big, I tell you. Where are we going? That's what I want to know. To all hands, you must want to know where you are going. Hey, that thing is psychic. This much I know about where we are going. This much I have permission to divulge. We are not. I repeat, we are not. Headed for either of the Dakotas or for the Indian or Pacific oceans. May I give you a hint? Before too many days or weeks, we should see friendly planes sent out from the Old World to protect us. Even as today, those of you who have been topside, have been seeing airplanes dispatched from the New World for the same reason. But where in the Old World are we headed? The Old World is almost as large as its past is long, and its coastline is almost as irregular. Where indeed, for the present at least, this must remain a secret. So let us be patient in our suspense. In our suspense because we shall know in the war's good time. It helped. It helped a lot down below to hear the voice coming over the loudspeaker, telling us what it looked like outside and what the news was, how Pantleria had surrendered, how the RAF was bombing Sicily and the Italian mainland, telling us all kinds of little things, making fun about things on the ship. He even joked about submarines. But one night he was serious and no wonder. To all hands, this is Lieutenant Brown speaking from the navigation bridge. I urge you to listen attentively. Tonight, on the Spelvin's bulletin boards, a message from Admiral Kirk will make our mission crystal clear. Admiral Kirk's message is addressed to all hands. It reads, We are sailing to Sicily. We are going to land a division of army troops on the southern coast of the island on beaches near a small town called Scaliite. We, in our division, are only a part of the forces involved in this attack, but we have a place of honor. To the west of us will be other American forces, and to our east will be the British. We are at the hinge. Ahead of us into the west, there will be parachute troops. Covering the operation at sea will be a strong British battle force. We shall be opposed. The army troops have a tough assignment and a very important one in the overall plan. Our job is to make it less tough for them by doing our part well. We must put them where they want to go, on time in full force. We must support them by gunfire, unload their supplies and equipment, care for any of their wounded. To do this, we must also take care of ourselves. We shall be busy. Good luck. A.G. Kirk. Yesterday was our last Sunday before battle. Few of us will ever forget it. All three services were crowded. Men and officers gathered bare-headed around improvised altars, under no compulsion but inner need. Do you remember all the times you have sung onward Christian soldiers? Not reverentially? Not really bothering about its implications? Nearly pleased to release what is triumphant almost gay in its assurance. The assurance was there yesterday, but the gaiety was gone. If the music was more moving than the sermons, it is because music leaves unsaid what we are afraid to say or are awkward in the saying. It leaves those things unsaid, but blessedly not unsung. Now the period of let's pretend is over. The reality is upon us. This drama so slow in starting is now galloping to its climax. The day, the battle day, is near. And the days which follow it are days which offer no choice. They must succeed. And down below, every day down below on the Spelvin, we listen for the voice over the loudspeakers as we went about our jobs. Listen for to all hands. Each hour, the hour of hours, the battle hour is almost here. It's now 11.30 p.m. and the attack is scheduled to begin at 2.25 a.m. We are nearing Sicily now, still moving toward it in the darkness. It will not be long before we reach our anchorage off Scolite on Sicily's southern shore. We have seen something of a miracle tonight. Things have looked bad for us. Very bad these past eight hours or so. By some ugly mischance, the first storm we have had in the Atlantic or the Mediterranean overtook us this afternoon. The gale increased until as darkness came on, the waves swelled into more and more sizable mountains. The prospect of trying to send landing craft into the beaches against such odds was disturbing to put it mildly. Then suddenly, a little while ago, the miracle of which I spoke occurred. The wind died down almost as a broccoli as it had starved. The sea is still choppy, but compared to what it was only a short time ago, it is as quiet as if God had put his hand upon it. This ought to be the best of Omen's. Perhaps you can hear it, that distant gunfire. Fires are boning on the beaches ahead. These fires mean that our planes have been busy. Scolite, our objective, must be about five miles away from us in the darkness now. If our first sight of Sicily has consisted of fires boning in the night on a land we cannot see, there is a reason for this. According to plans, the Northwest African Air Force was scheduled to conduct an air offensive throughout the whole Mediterranean area prior to our coming. That crunchy bumpy noise you may have heard was our anchor on the way down. It's blacker than coal up here on the bridge. Our ships are slipping into position. They're gathering like conspirators. We cannot see them, but we can feel them. The way in a dark room you know someone has entered. He's creeping past you or is standing next to you. It's 1.30 a.m. now. A great wave of planes. Our planes has just swept over us. These were our transports coming out. They mean that our paratroopers have landed on Sicily and are all ready at work. Small boats should be in the water now. From transport after transport, these small craft are being lowered. They must be filled with anxious men, the small boatmen, a point and glory of this... Down below we waited for every word. We kept looking at our watches. I got 240. HR is just five minutes off. It'll be long now. To all hands. Hey, wait a minute. Listen. Those deep, throated, distant guns you may hear don't belong to us. They are British and come from the east coast. From the sound of them, the show must be on there and on in a big way. It's 3.15 a.m. The sky has become fairly active. Some red and white tracers have been chasing one another inland, following a high arched course. Three enemy parishion flares drop from a plane or planes coming in from west of Skylity have been hung off our starboard bow. The stage is set. The curtain is scheduled to go up in a few minutes now. Down below on the spelvin we waited. They couldn't see anything, but they were letting us in on what was happening. For July was never like this.  Our guns have really been speaking up, and it looks like they're much more than just big talkers. The sky is as bright as a summer parasol, with the sunlight streaming through it. The darkness is losing a battle soon. Light is everywhere, never for long, always changing, always in the swiftest motion. Then the night seeks back, only to be driven away again. Overhead, it's all dots and dashes which you can see. Livering as they race to rise and fall, dots and dashes and streamers of heat and rockets overtaking rockets. Light and noise. The noises are as different as the lights. There's a frog-like glump, a flak, as it thubs through the water after a brief splash. There's a sign in a whistle coming from something I don't know what. There are big guns, little guns, medium-sized guns, all of them fluent, all of them demanding to be heard from. The big guns bellow in a full, damp, dull tone. They sound the way a goldfish bowl might sound. If water and all, it exploded right inside you. Under this flaming cover, the small landing boats have been pushing into shore. Right as the sky is, the water is still so dark that I've been able to see the Viking outlines of only a few of our little boats. But once in a while, in the dim, the spot of their motors has been heard. It's 4.45 a.m. now. Low on the spellvin, we waited to hear the word. We wanted to hear the most. We didn't just wait, of course. There was plenty for us to do. And it helped to be in on the know, even though we couldn't see what was happening. And finally, a little after five in the morning, we heard what we were waiting to hear. To all hands, it's 5.15 a.m. and I have good news. Word has just been received that initial landings have been accomplished on all of our beaches. This means that the little boats from each of our transports have pushed in wave by wave to their designated landing places and that our troops have established themselves on shore. For the details, we shall have to wait. What matters is that the Sicilian invasion is by now a fact. The sky is still noon bright up here in splotches. There have been more flares, more enemy planes, too. One of these has falconed down towards the spellvin. It's motor's angry as if to dive bombers. It was a rumble, a roar, a rumble again and a bad moment. As a matter of fact, being anchored here in the light waiting has given us a lot of bad moments, though thank God so far only to think about. It's dawnish up here now on the bridge. Sicily's coastline has just begun to take shape. It's still indistinct, still part of the vanishing night. Far inland to starboard, the kind of mountain Mount Etna might be if only it were within seeing range is slowly working its way down into the dawn. The pink-blue daylight is creeping down to the beaches. Expect to hear birds. Instead, the sky rattles with anti-aircraft fire and the hurried booming of the big guns on the cruisers and the destroyers. The shoreline also rumbles every now and then with battle-nots' noises like a kettle drum. You must have heard that explosion directly ahead of us. A great blob of light has just bleached and reddened the sky, tearing the night into shreds. It was followed by that blast, more sullen and deafening than any we have so far heard, and then scattered across the sky with a ship from the task force to the west of us. Now the German planes which got that ship are flocking towards us. There are not many, but enough. Say six, flying low, leaving a trail of big splashes behind them in the water where their bombs have fallen. One of them slanted down across our bow, barely missing the cruiser off our port side. No more damage. They're going now. One man in ten. That's the percentage. One man in ten aboard a big warship actually sees the battle. The rest are at their posts below. Well, for us below on the Spelvin, it was a long night, a hard night, but not half as bad as it might have been if we had to just wonder about one without ever really knowing. Of course, we wondered about a lot of things anyway. We still couldn't help wondering how it looked up there. It's now 6.30 a.m. You can see Scaliete, our objective to port. It's a group of drab white houses clustered around a church tower. The beaches on either side could be beaches seen in the freshness of any early morning, if it were not for the little boats nudging into them and the swarming docks visible through binoculars on the sands. The fields and the slight hills backing these beaches could be any peaceful hills and fields if it were not for the smoke rising here and there from fires burning on them even so. They look almost as tranquil as if they were the contour maps increased in scale and come to life. The sea and the sky are different.  The ships in our task force are all around us. They look refreshing by the morning sun and are unhurt. Our gunners continue to pivot covering whatever passes in the sky. It's 7.15 a.m. now. We're weighing anchor to move in closer to shore. Everyone tops out has been nibbling on or at K-Rations and feels the better for coffee with its illusion of breakfast. Most of the shore batteries have been silenced due to the spectacular accuracy of naval gunnery. One by one they have been snuffed out like candles. Some jeeps have been lowered into the landing boats panting alongside of us and the LCTs are now going in rolling quite a bit and crowded with boys in khaki only a few of whom look seasick and are holding their heads. These LCTs have been escorted and given fire cover by our destroyers. The army is leaving us in large numbers. As it does so, one of our big cruisers is thundering away at an inland target and a huge fire is burning on the beach to port. Some more coffee, Slim? No, I got enough for a while. It's quite a night, huh? It's quite a night, yeah. But we did okay, huh? What, it's set over the speaker? Sure we did okay. To all hands. I am, for the moment, all's quiet. We have just dropped anchor again and after shaking hands with Admiral Kirk General Middleton of the 45th Division has gone ashore. A message from the shore says considerable artillery and prisoners taken. That's good news to sleep on and the Chief of Staff urges that you do sleep today, your duty is permitting and sleep as long as possible. It should be a happy night. It should be a happy sleep. Brother, it will be. That was just one night. There were others off Sicily before our job was done. More nights when the big guns shook the ship and we listened for the voice to tell us how we were doing. We were doing all right and then suddenly our job was done. We were leaving Sicily and it came over the loudspeaker that the reason we were pulling out from Sicily and landing our cargo ships were unloaded there was no point to us sticking around as targets for enemy planes. And then it was official about how we did our jobs to all hands. Gentlemen, grab hold of your chests and prepare to expand them as for your shoulders throw them back. A dispatch from Admiral Hewitt Commander in Chief U.S. Naval Forces North African waters has reached the spell then the ships and units in the Western Task Force. It reads due to careful planning, excellent seamanship, gunfire and engineering and a high standard of proficiency and devotion to duty by all hands the most difficult and complicated task of landing our troops on hostile shores has been successfully accomplished. I consider that all from the Task Force commanders to the lowest weightings have performed splendidly and are deserting the highest praise. Well done. It is now our duty to support, maintain and build up the forces which have landed. Carry on. After a battle the first thing a guy wants to do is talk about it right home about it. We were on our way back from Sicily and the word went out that we could write letters to be mailed from Africa. They even told us what we could say on the letters. You cannot say that you have been in Sicily, in the Mediterranean, in Africa or in the Atlantic. You cannot say you were in action. You cannot say that you took Sicily single-handed or even in good company. You cannot mention the weather. You cannot say where you were, where you were going, what you have been doing or what you are expected to do. In other words, you cannot To all hands gentlemen, this is a moment of farewell. Many of the flag are leaving the spell bin. We have been transferred to another ship. There is an old saying that fish and guests stink after three days. We have been with you a little more than two months. But though we may be parting company we cannot part with our joint memories. After all, we have served together in the amphibious forces under Admiral Kirk. We have eaten K-Rations together and they are enough to cement any friendship. We have dodged submarine packs in each other's company, taken inoculations together, zigzagged in unison across the Atlantic, drunk the same bad wines in Africa, spoken the same bad French, seen the same shorelines, heard the same flak, been lit by the same German flares and scanned the same tracer bullets. No matter where we go in the future a part of us will always be spliced to the spell bin. This is our St. Crispian's Day. It was the day on which the armies of an English king Henry V faced and vanquished the forces of Charles VI of France. It was Henry V spoken for by Shakespeare who speaks for the pride which each of us will know in the coming years because of our being here in this company now changed the names in the drumbeat of Shakespeare's singing station verse and you will I think see what I mean and feel what I feel. Here is Shakespeare's King Henry speaking on the eve of an ancient English holiday vanishing despair and igniting a proper pride in tested men. If we are marked to die we are enough to do our country loss and if to live the fewer men there of honor oh do not wish for more rather proclaim it Westmoreland through my host that he which hath no stomach to this fight let him depart his passport shall be made and crowns for convoy put into his purse.  This day is called the feast of christian. He who lives this day and comes safe home will stand a tiptoe in this day's name and rouse him at the name of christian. He that shall live this day and see old age will yell on the vigil feast his neighbors and say tomorrow is saint christian then will he strip his sleeve and show his scars and say these wounds I had on christian's day. He will teach his son and christian, christian shall near go by from this day to the ending of the world but we in it shall be remembered we few, we happy few we band of brothers for he today that sheds his blood with me shall be my brother be he near so vile this day shall gentle his condition and gentleman in england think themselves at coast they were not here and hold their manhoods cheap while any speak but fought with us upon saint christian's day and so men of the spell then top side and below we who have had our christian day together we of the flag say farewell, farewell and scolite these have been words at war another in the series of radio adaptations of important books of this war tonight john mason brown distinguished dramatic critic author and lecturer and now lieutenant john mason brown usnr acted as narrator in portions of his own book to wall hands just published words at war is presented each tuesday evening at this time by the national broadcasting company and the independent radio stations associated with the nbc network in cooperation with the council on books in wartime this program came to you from new york this is the national broadcasting company


All right, I think we're going to get started. My name is Dustin Kirkland. I'm the CTO of a startup company at Austin called Gazang. I'll talk a little bit about what we do toward the end of the presentation, but we'll set that up by talking about the meat of this presentation. Really about encryption everywhere, everything, inside of OpenStack or Cloud in general. I've got some suggestions here, some ideas of way that we could do things better in the OpenStack community, but also some best practices that perhaps you can do as practitioners of infrastructure as a service, clouds, or as users of clouds for your infrastructure. Let's talk about what's changed, right? In particular, with respect to security, I've sat in this room for all the sessions today, and we've had some great content. So I think a bit of this is repeated. I believe we're starting to center on what has changed in terms of security with respect to the cloud. The big thing is that security is getting outsourced, along with your compute and your storage and all the other things that you're outsourcing to the cloud. You're also outsourcing your security, and that's something that happens in some cases without you even realizing it. Not only is it being outsourced, but it's also being distributed. In particular, if you spread your workloads across multiple clouds, or you're managing multiple clouds within your organization, the security that used to be in one place inside of your data center where you had established over the course of the 90s and the 2000s the log book that you had to sign in and the multiple forms of identification, all that's out of the door once you start dealing with cloud computing. And this sounds a little at odds with one another, but not only is it distributed, but in some cases it's consolidated, right? So you've managed to get everything now into a single cloud provider, but they have a breach, but they have some endemic issues that totally jeopardize the security. You've now centralized it. So it's kind of that weird combination of outsourcing, distributing, and consolidating in some cases. Ultimately, you've given up some of your usual barriers, so your physical barriers to your infrastructure. Automation and orchestration are absolutely essential to cloud computing, and that's really at the heart of it. We talk about configuration management and orchestration. It's beautiful. It's wonderful. It's absolutely the only way to deal with the number of systems that we're talking about, virtual machines, physical systems. You've got to automate and consolidate things. But with automation and orchestration comes a handful of new challenges, new issues around security. The fact that you no longer can enter a password every time you need one system to authenticate with another system to do some process, maybe a backup or federate some exchange of information. That has to happen without passwords. It has to be non-interactive. It has to be automated. And then simply the numbers game, the numbers of systems we're talking about. That's completely changed. If you were managing a data center 15, 10, 15 years ago, even five years ago, you probably weren't dealing with the number of logical system units, the logical deployments of operating systems that you deal with now that we're in a cloud heavy world where you just spend up a new VM and every new VM comes with its own security challenges and handling that is an important new consideration, something that has changed. And finally, I guess we could go on and on and I guess that's why we have an entire track dedicated to this today. But the last one that I'm gonna talk about today is randomness and I've actually got a second presentation just after this one on entropy. Some ideas of how we can actually improve the entropy pool inside of OpenStack. But I'll just leave the leader here in our plan of seed here. Some cloud computing practices render virtual machines completely predictable and that's just the nature of the beast. I'm not gonna go into that in this presentation if you're interested in that. Come back in about an hour from now. Back to that numbers game. So we've exploded the number of systems that we now have under our management that we talk about. With that comes a proliferation of the sensitive data and every machine has sensitive data. Inside of Gazang, we tend to call that machine DNA. It's the little pieces of that machine that make it unique, distinct, different from every other machine that either you've launched or your tenant next to you has launched. The obvious ones, the big ones, the important ones are your private keys. The SSH, SSL, if you're using Kerberos or some cloud equivalent to Kerberos, GPG. Any of these, they have some bit of private key material that's stored or generated on that box. The generation, that's back to the entropy problem, but the storage is really at the heart of this presentation how to protect that storage. If not private keys, which every machine at least has a private host SSH key, but if not that, configuration files, the stuff that's in Etsy. How much of that you consider for a second, how much of that would be harmful to your business if your configuration of a given system leaked. There may not be anything in there that immediately gives access to the system, but it certainly would allow a sophisticated attacker to build, construct and attack against the system knowing how it's set up. Log files are just treasure troves of information, some private information, some sensitive information, more information about how the system is configured, what's going on within it. And these are just a few examples, but VAR lib, you know, most applications tend to put their varying state information in VAR lib or VAR temp or VAR cache. That's machine exhaust. I think some of the config management or some of the monitoring guys would call that machine exhaust. It's just information that's being created by your application. In many cases it's important, and in some cases it's bits of information that's in that, but consider that for a second, just in terms of what's sensitive that your application's processing. User data seemingly obvious, you know, maybe you've got information in home, maybe not, but that's kind of the equivalent from a human perspective to the application data. It's the stuff that makes that user use, or what that user needs to use that machine. The application data is what the application needs to do its work. Password hash is various. I mean, the list goes on. This is just a, you know, an example to kind of get your, start thinking about what's important on my hosts and on my guests. And unfortunately, disks do disappear. This is some statistics I ran across the U.S. Department of Health and Human Services publishes a wall of shame. It's actually pretty entertaining. You can download a CSV file of all breaches that have been reported to the Health and Human Services department, which by law you're required to report any loss that involves 500 people or more has to be reported by law to the Health and Human Services. And anyone can download a CSV file of the breaches, not of the data that was leaked obviously, but of the report itself. So I loaded that up into a spreadsheet, ran some stats on it, and, you know, we used this a bit for our marking material within Gazang, but this is absolutely accurate. So I went through the 480 reported breaches and there's this free form field to the far right of the database that for each incident there's an explanation given for what happened. And I classified those into one, two, three, four, five, five different categories. Theft of device or physical media accounted for 55% of the 480 breaches. Another 12% from lost devices, so not theft. Theft was clearly something that was malicious. Lost is just, you know, whoops, we don't know where we put it. Another 5%, which actually a lot of these had improper disposal as the label and that was to me different than lost or theft. But in all three of those cases, we're talking about media that walked out of a data center. And that's a little bit frightening to me, especially as a CTO of a company that does work with cloud providers. We put our company information into that cloud. We hope their security practices are good. We hope they dispose of the disks in a meaningful or in a secure manner. We've got SLAs, we've got contracts, but I mean, at the end of the day, do you really know? My point with these statistics is that 72% of these 21 million healthcare records that have been exposed could have been trivially solved by encrypting the data at rest and storing the key somewhere else. That's really the take-home from this presentation. If you're doing work as a guest in a cloud, if you're running a cloud, I think we've got a really awesome mix of people at this OpenStack Summit of practitioners who are deploying cloud services themselves and people who are trying to leverage that as guests of those clouds. The point of this presentation is both of you need to be doing encryption, doing your part encrypting that data and ensuring that the levels of protection are in place. And that's the answer to this question. So what do we do? So as a host, as a cloud provider, you really have the responsibility to protect your customers' data. Your customers are entrusting you with this, if not explicitly. It's certainly implicit that they're implying that they're trusting you with this data. As a guest, well, you need to do what you can do to protect your own data at rest and use encryption within your guest. And then on the wire, using appropriate security measures, encryption on the fly as well. So we can dive into each of these. So comprehensive encryption means protecting all layers of the cloud stack. And I listed three here. We could have broken this down into a lot more, many more different layers. But just at the highest level, the network layer, I think SSH seems to be pretty well understood. I mean, no one's using Telnet anymore, right? No one's used Telnet, and I hope not anyway. I think we understand that one pretty well. But TLS and SSL, I guess, more commonly in practice. But SSL, it's used correctly in some places, but certainly not everywhere. At the file system layer, there's a handful of technologies that will look at eCrypt FS, TrueCrypt, Z Encrypt is a product that my company makes based on eCrypt FS. And then below that, at the block storage layer, DMCrypt encrypting the block storage. And in some places, one is more appropriate than another. But in all cases, both the guest and the host need to be doing this work. So SSH, well understood, there are actually some helper utilities that are quite useful when managing SSH. SSH copy ID is a cool utility that allows you to push your public key to another site. I think we're pretty good in OpenStack through Keystone, allowing users to upload their keys. But I remember when I first started using Amazon, Amazon forced me to generate my public-private key pair on their site. So clearly they had my private key at that point. That just didn't seem right. I'm glad we've taken a different route in OpenStack with Keystone. But being able to generate your key local, a key that you protect, use reasonable measures on, and then push it out. Copy ID is a great way of pushing keys. Import ID, SSH import ID is an interesting way to pull someone's key. So we do a lot of shared access, shared terminals, at least in the development environments I've been in. SSH import ID and then give someone's username or URL where you can fetch that public key from. It'll securely pull down that public key installed in the local user's authorized keys file and set up that authentication. That should say DNS host records are not DHS, not Department of Homeland Security. No, this is DNS. So DNS host key records, SSH, SSHFP, SSH fingerprint is actually a DNS record that can be used to propagate the public fingerprint, the key fingerprint of the host that you're SSHing to. So we've got some scripts that handle that with Dine DNS for us, a little-known feature of DNS. Does anyone else use SSHFP? It's really cool. You know the question you get when you SSH to a system and says, you know, this is a new fingerprint, I don't know, do you trust this host? You can actually have SSH go to DNS and look up the fingerprint if you set it up that way. And skip that question securely. The SSH will verify that for you. It takes a bit of infrastructure to get that tied to your dynamic DNS provider, your bind, if you're running your own DNS bind itself. But once you've got that set up and automated, it's a really neat feature and really can give you as a sysadmin confidence that you're actually SSHing to the system that you think you are.  If we're really paranoid, we'll go to the console, grab the SSH fingerprint, and we'll check all 32 bytes match. But, you know, that's a little bit clumsy, especially in a world where we try to automate everything. From an SSL perspective, many if not most, I'd say most applications support SSL, but it's rarely enabled by default. And I attended some of the Keystone talks earlier today. It seems that, you know, a lot of OpenStack even has support for SSL communications basically everywhere, but we don't always enable it. We certainly don't enable it by default in OpenStack.  Part of it is that the PKI piece isn't fully well-baked. It sounds like for the next release, for the Grizzly release, there's going to be some work around PKI and OpenStack. Really, you need, you know, good sign certificates from one of the real certificate authorities. And SSL needs to be enabled.  The encryption is, especially with some of the cryptographic accelerators like AS and I, that part is almost free nowadays. Key management's really the hard part. I'll talk about key management a little bit toward the end of the presentation. But with respect to SSL, that can and should be enabled everywhere, everywhere that you've got the opportunity to. And then in a production environment, you really need, you know, real root sign search for those applications and those systems. At the block storage layer, which is the lowest layer of the storage stack, DM Crypt is a well-understood technology within Linux. It's been the Linux block driver encryption since the early 2.6 Linux kernel days. It's extremely fast. It's very efficient. It's a bit of a blunt tool. It's an all-or-nothing sort of solution. You either encrypt the entire block device or you don't. You have to make that decision upfront. You can't take a system that's been running for a while and say, yeah, I want to go ahead and encrypt that disk. There's no way to do that live or on the fly. But, you know, the entire melt point can be encrypted. And that ensures that a key is loaded at mount time. And all the data written to the disk is handled by the Linux kernel driver for DM Crypt itself. It's encrypted before landing as blocks on the disk and decrypted as it's presented to the application layer. The beauty of that is no application needs to know that it's running on a DM Crypt encrypted device. The trick, though, is getting that key loaded at mount time. So it's a little bit hard to do the root device using DM Crypt unless there's an administrator who's present who can type the password or passphrase or if you've got some device or dongle that can provide that. Or you've got a network-based key manager like an HSM or, you know, a software-based equivalent to an HSM. But as difficult as it might be to do that on the root device, doing it on the auxiliary storage is actually quite easy. You can do that on your slash server data or mount or wherever your auxiliary storage is happening, your secondary disk. And this is, I would recommend, a really good way of protecting the disk that's having your local instant storage. The thing that, you know, when you clone a VM from or an image, you pull an image out of glance. And with an open stack, we pull it out of glance and we initiate the new instance. Having that in an encrypted volume, I think, is the next logical step in the way that we protect the customer or the user that instance's data before it's written to this local physical disk. With AS&I, AS&I is a new set of cryptographic accelerator instructions on modern Intel and AMD chips. It's awesome. I mean, really awesome. It takes the computational complexity of encryption and puts it to, you know, less than 1% of impact on the workload. In some cases, zero. I mean, I really don't even see the encryption happening on my heaviest workloads when my chip has AS&I and I'm using DMCrypt. And then the one other somewhat of a downside or potentially downside is that a single key is used for the entire mount point. In some cases, that makes sense. In other cases, that doesn't suit the problem very well. But it's really easy to set up, really fast, really efficient, and there's no reason why we shouldn't be doing DMCrypt by default on the auxiliary storage, on the extra disks that are attached to a given system. Built on top of DMCrypt is a package that I co-authored with Scott Moser. Scott's still in here. He was in here a few minutes ago from Ubuntu. We're both Ubuntu core developers. Overlay root is a combination of DMCrypt and overlay FS. And it provides a union mount. So a union mount has two directories. And one is the read-only directory. One's the read-write, and they're sort of merged together. And you get this one sort of presentation of what the file system looks like. Ubuntu has been doing this, Ubuntu, Nopix. All the live CDs have been doing this for years. You get a CD-ROM and ISO that's read-only. But you've got this other bit of storage, maybe it's in memory, maybe it's on an extra disk or a USB stick that is read-write. And then the two emerge together so that it looks like you've got a disk that you can read and write data from. Most of it's coming from the read-only storage. Your changes go to the read-write storage. Overlay root is that exact concept inside of a virtual machine instance. And this is already in the Ubuntu 12.10 release that actually released today. Overlay root is one of the features in the new cloud images from Ubuntu. It's one single line you need to configure and it's the overlayroot.conf. Basically, you can tell it there's a handful of flags. This is how you set up encryption. You say crypt, that's a flag. colon separates the different parameters as a handful of parameters. You need to give it a dev, a device. Dev equals dev xvdb. This is the secondary disk that's associated with this instance that I did this one in Amazon. Just as easily dev could be some other disk or even tempfs. You could do this entirely in memory. So overlayfs provides a union mount of all of the root file system where most of it's coming from the lower read-only directory. That's the pristine stock Ubuntu image. That's the AMI that everyone's running. If you're running 12.10, you're all, everyone's running that same image. But there's a second directory that's mounted. It's called the upper directory. It's mounted read-write. And it's mounted on top of a dev mapper secure. It's a dmcrypt, basically. So we have the primary disk is mounted read-only, xvda. The secondary disk dev xvdb is dmcrypt encrypted and that creates a dmcrypt device at dev mapper secure. And then that's mounted on top of media root read-write overlay. And this one's mounted on top of media root read-only. And then the combination of those two provides a place where when reading, you get the combination of the two. When writing, all the changes go to the upper directory, the read-write directory. And so you start with this pristine image just like you would do with a live ISO, a disk. But all of your changes, all your var log, all your edC, all your var lib, everything that happens on the system after boot is written to the other disk and is encrypted before it lands on the disk. So this is available today. You can do this inside of OpenStack, inside of Amazon, inside of Rackspace, inside of anywhere that has Ubuntu 12.10 images loaded and the overlay root package installed, which is installed by default now. This can be done pretty trivially. At the file system layer, eCrypt FS is sort of the other way of doing file system encryption inside of Linux. So there's dmCrypt, which does full block encryption. And then there's eCrypt FS. eCrypt FS does perfile encryption. And full disclosure, I'm one of the authors and maintainers of eCrypt FS. I'm trying to do this as objectively as possible, but it's hard to omit that small fact. It's file system encryption, but it's on a perfile basis. With eCrypt FS, you mount one directory on top of another directory. And the upper directory to applications and user space looks like clear text data. It looks like files and directories and just like any other directory, recursively down below that. But that's only a virtual view of those files. It's only a virtual presentation of that data, that information. If you've got the keys loaded into the kernel key ring, you can see that data. You read and write it as if it's just normal files and directories. None of those files actually exist there in that clear text. It's only a virtual representation of those files. What actually happens, the kernel does a translation between that upper directory and the lower directory. And before it lands on disk in the lower directory, they're actually encrypted or decrypted depending on the direction you're going there. Each individual file can be encrypted with a different key. Each individual file can have its own policies, its own policies for those keys and such. And some files can be encrypted while others are not encrypted. I think this would be a really interesting way of doing encryption inside of OpenStack at the host level where we'd use eCrypt FS and encrypt different images, different backing disks with different user keys. A user could load their keys or have their own unique or distinct keys, have them managed by Keystone or another key store. And before that data is read or written to or from disk, you know, the appropriate keys are loaded by that process. Yeah, question. So performance hit on eCrypt FS, it's really hard to benchmark, but we tend to quote a 3% to 5% performance hit. It really depends on the workload, how much reading and writing you're doing. It's a fairly memory intensive operation. There's one other part, the AES and I support isn't yet working right with eCrypt FS. It's coming. We've got patches on the kernel mailing list. We should see that in the next couple of months. It can be much worse than that. It can be 10 or 20% depending on how intense the reading and writing happens. In general, the profiling that we've done around disk encryption, be it file or block device encryption, if your disks are anything less than extremely fast SSDs, the seek time to find the next block often fits within the CPU time for encrypting and decrypting that block. So in some cases you don't even notice the difference. Good question. I think it's worth benchmarking. Sorry, it's good feedback. Robert? No, it's seekable. So eCrypt FS is block encrypted. There's 4K pages, so it's very seekable. The other advantage of eCrypt FS is incremental backups are possible on a per file basis. With the encrypt, if you want to backup the encrypted data, you got to send the whole volume wherever you're going to go, the whole block device where you're going to go. With eCrypt FS, you can back up and R-sync or incrementally back up on a per file basis. Now, if the one file is 20 gigs and you've changed that, unless you've got R-sync configured in such a way that it can send bits of a file. But from an eCrypt FS perspective, each block is encrypted separately. Another question. This was introduced in Sandy Bridge, I believe. Excuse me? Nahalem. Excuse me? Westmere? Okay. I'm not an Intel engineer. When AES appears in PROC CPU Info, your CPU has the magic bits necessary to... or the silicon necessary to do AES and I encryption. You need to mod probe AES under bar Intel or AES under bar AMD depending on which you need. And then the kernel takes it from there. If it's DMCrypt, you'll see a big performance increase. With eCrypt FS, you won't yet, but we're getting close. We've got the work. We just need to get, you know, it merged into the VFS layer. Another question? So file... That's a great question. So I'll repeat the question. I forgot to do this for the others, but I'll repeat the question. In eCrypt FS, do the files look just like the decrypted files? Do the encrypted files look just like the decrypted files from a metadata and attributes perspective? eCrypt FS, yes, DMCrypt, no, it's just encrypted block data. And sometimes that's what you want. With eCrypt FS, the owners, the file system or the file permissions, the ownerships, the timestamps, the rough size, you know, encryption does pad the data. It takes up a bit more space. All of that's visible to an attacker, maybe who sees the encrypted data. They can't see the data. File name encryption is an option. You can turn it on or off. There is a bit of a performance hit for encrypting file names because every seek or LS in a directory, every LS in a directory or search or a find, you know, you got to do a whole lot more decryption than you normally do. You can encrypt the file names. There's also a limit because the encryption necessarily involves padding. The normal Linux 255 character file name limits is down to like 180 or 200 character long file names. The Linux path max is 4096. You can hit that a little bit faster if you've got a lot of directories with encrypted file names. So you can encrypt file names to that part of your question. The file system attribute or the file attributes are not encrypted. And so it may reveal that it looks like you've got a file with permissions of this and ownerships of that. Sometimes you want that, sometimes you don't. It makes it really nice for doing backups. It's easy to back up the encrypted data and know that the contents of those files are encrypted. But if you're trying to protect the structure, if you have a, you know, foo.jpg, you can see that's name is foo.jpg. EcryptFS can be used on both the host and the guest layer. I think, you know, I think it's worth benchmarking and seeing how this works in a big production environment. DMCrypt might be the better way to go for protecting the backing disks. Inside of the guest itself, I use EcryptFS all over the place to protect data that may be in just an ephemeral image, a launch and instance. And this instance is only going to last so long, but I want to make sure the data is protected before being written by the hypervisor to the underlying storage. And this is an easy way to do that. I can load the key in the kernel memory and discard it. The key never lands on the disk. So just briefly to introduce ZnCrypt. ZnCrypt is our commercially supported version of EcryptFS. Essentially, we'll have support for DMCrypt available later this year. It's a wrapper for EcryptFS. The open source EcryptFS is the core of our product. We've certified it with several enterprise workloads, including CDH, Elastic MapReduce, MongoDB, Cassandra. We've tested and benchmarked it on tons of other workloads, namely OpenStack, GlusterFS, React, MySQL, Postgres. Our customers come to us. They need a commercially supported version of an encrypted file system, something that's backed by a vendor. We've got easy installation devs, RPMs. We've got young repositories after repositories for that. And we've bundled support for remote key management. Key management is really the hardest part of all of this. Encrypting stuff's easy. It's where do you put the keys? How do you put the keys in such a way that you can reboot your system? It fetches the key and can mount that data. Oh, and by the way, do it in a way that your attackers can't just do the same thing to simulate that. That's really the hard part here. And in some cases, protecting it from your cloud provider, your cloud provider, or maybe that was a Freudian slip when I said DHS earlier. Maybe you're protecting your keys from Homeland Security or some other government body elsewhere. Unfortunately, right now, there's no, you know, for this space, for OpenStack space, there's no complete comprehensive open source solution to the global key management. Keystone doesn't really fit this. It's similar. It's easy to get confused on it. Keystone really, really handles identities, but not just the generic opaque cryptographic objects. The traditional way of solving this problem are hardware security modules. But hardware security modules don't map particularly well to cloud environments. When a tenant needs the equivalent of an HSM, but they only need it for a few days or weeks or months. Hardware security modules are literally that welded shut, one-U rack-mountable systems that you buy. And if you've got physical infrastructure, they're great, and they've been around for ages and they're an excellent way of doing things. But as we move to cloud, HSMs don't map particularly well to that. Our solution is something called Z-Trustee. It is a comprehensive key management solution. There's a server, there are clients that put and get their keys from that over a secure channel. You actually have the opportunity to assign trustees to those keys. And trustees are basically another multi-factor authentication. They authenticate with the system and allow or deny the release of those keys. So, in conclusion, encrypt everything everywhere. On the hosts, encrypting the network layer, ensuring that OpenStack or your cloud system is set up in a way that takes advantage of TLS or SSL across the board. When you're doing testing, sure, self-sign certs are great. Once you go into production, it really means having real SSL certificates or setting up a PKI, public key infrastructure, and federating those ahead of time. It's a little bit harder to do it that way, but depending on the size of your infrastructure, it might be a lot cheaper than buying, you know, 20,000 certs or wildcard certs from Verisign or someone. Encrypting the backing disk images, you know, in some cases, the disk images themselves are sensitive and others, it's once the instance launches and the instance data needs to be encrypted. We've got opportunities to encrypt lots of things in OpenStack and I really hope to see us move that direction in the near future. Compute, Swift, Glant, Sender, Sef, each of these have a layer that writes sensitive data, sometimes sensitive data that's outside of its control to disk and each of those should go through a DMCrypt or a new CryptFS layer. Within the guest, taking control of your data and ensuring that your data is protected, you know, the network layer, that's just federating your applications together. You've got that same responsibility. It's not at the OpenStack layer. It's whatever your apps are that are talking to one another, maybe over a REST or REST-based API or web service. But, you know, the locally generated data before it's written to disk, if you don't know what your cloud provider is doing or maybe you don't trust that cloud provider necessarily using a DMCrypt or any CryptFS to push that data to the lower storage encrypt, it's important. Then across the environment, we're managing the keys centrally and securely using a key management solution. If, you know, some people bake their own or roll their own, maybe we'll see one in OpenStack at some point. And then just briefly, the advertisement, where Gazang had quartered in Austin, Texas. Start-up, we do encryption key management for big data and cloud. Most of our customers are trying to protect their data for HIPAA regulations. That's healthcare, FERPA, student records, PHI, PCI, PII. This is all the personally identifiable information. Our customers have that requirement and they come to us to help them ensure that their data is encrypted, sometimes in their public cloud solutions, sometimes on their local site. That's that. I'll take any other questions now. Yes, sir. Yep, eCryptFS is a Linux kernel module. It's a Linux-only offering. TrueCrypt would probably be the closest equivalent to eCryptFS. That's multi-platform. Our focus, Gazang's focus is Linux exclusively. I understand some people have, you know, other OS requirements. TrueCrypt would probably be the best bet where multi-platforms is a necessity. DMCrypt is also Linux-only, but it's been supported for a long time. This isn't new. eCryptFS landed in the kernel in 2006. DMCrypt a year or two before that. So they've both been around for six, seven, eight years. They're in all the major distros. REL supports it. Ubuntu supports it. Yeah. Yes, sir? Sir, you said NIST test. Right, so FIPS 140-2 is the cryptographic standard from NIST, right? So no, we haven't. We use AES under the cover. So neither eCryptFS nor DMCrypt, neither of these do the encryption themselves. They offload that to the Linux kernel's cryptographic layer. So the crypto APIs in the kernel provide AES among other triple-des, AES, Blowfish, all of these. We use AES 256, excuse me, AES 128 by default. Gazang uses AES 256 by default. It's the, we've written no crypto in eCryptFS. That's offloaded to the Linux kernel. So the question is, has the Linux kernel been through these certifications? My guess is probably, but I don't know that one definitively. Any other questions? Yes, sir? TPM support is, yeah, if you want to use it, you certainly can. We don't have any bundled support for TPM. TPM would store your root of trust, right? That's left as an exercise for the user. I mean, our consultation services, we've helped users leverage their TPMs. There's also no virtual TPM, and most of our customers are running in a cloud, in a virtual machine. So there's no virtual TPM. You would need to do that. This would only be supported on real hardware. And then you would use the trousers interface to get, pull those keys, retrieve those keys from the TPM. It's important to understand what that protects. When you use the TPM, you're basically binding that disk to that chassis, right? And if you move the disk from the chassis, well, now the disk's key is over in that chassis, and you can't get to that. But if you move the disk with the chassis, someone steals the entire physical machine, then you don't really have that protection. So it's just important to understand what the TPM does and doesn't protect. Maybe that's what you want. Maybe you're just worried about someone literally pulling a disk, because it's a lot easier to stick a disk in your pocket than a 4U rack mountable server. So the answer to that question is, when hardware is present, and you've got the trousers library, sure, you can put and get your keys from the TPM on the local system. It takes a wrapper script, a small shell script to do that. Anything else? Good. Well, thank you very much. Appreciate it.