Okay, ladies and gentlemen, our next talk is coming up, DP5-PRI for Privacy Preserving Presence, a framework that allows you to have better control of your privacy. If you have a space, a free seat next to you, could you please raise your hand so anyone can find seats really quickly, even for the people coming in late now? Now there will be a notice about the translation. Es gibt von diesem englischen Talk eine deutsche Live-Übersetzung. Bitte das Decktelefon nehmen und Kanal 8011 wählen und unsere Live-Übersetzer übersetzen von Englisch nach Deutsch. Okay, so we are ready to start. Here we have Ian and George and let's give them a warm round of applause. Hello here, dear listeners, here is welcome to PIR for Privacy Preserving Presence. And I am Julian and we are sitting next to each other. Hello, we are Ian Goldberg and George Dinesis from University College of London. And the third person couldn't be here today, Nico Borisov. We want to talk about DP5, PIR, private information retrieval, PIR, and then George will talk a little bit more about DP5. First of all, PIR, what is PIR? Imagine an online data bank. It's not that hard to imagine. There are a lot of online data banks and we have a patent data bank. There are a lot of data banks that you can ask for example in the USA for patents. We are all researchers. Everything wants the patent 62667, the patent on the swing of a shovel. This is a real patent. It was pulled back because of stupidity, but it was first issued. Everything wants to find out this patent, but the database doesn't want to know that the data bank knows that shoveling is a totally new research topic. Chalking is a stupid example, but if you translate chalking through one, three D-metals, blah, blah, blah, then you can imagine that it is important that you want to ask data banks without trying to say where to look. Then the database operator could see that someone is interested. Maybe we should take a look at that too, because we have information. There was a time domain front running. You made a tool to see if a domain is available. And this act of the US front running made a few domain registers to make this domain register before you could do it yourself. So if you want to ask a data bank without asking the data bank, you know what you are interested in. That is private information retrieval, private information retrieval. We don't want to hide that Alice is interested in chalking, but we want to hide that chalking is a hot topic. If you want to add some anonymity to it, then you can just use Tor or whatever it is in order, and that's what it's all about. And of course there are business models that are based on this PIR, that you pay for it, that you do it privately and that someone finds out this question. So everything makes this question, this PIR question, and the idea is that the server has no idea what is being asked. The best of you, I think, are probably not, that is of course completely impossible. Well, it is of course a bit impossible, and the magic of cryptography is that things are impossible and that is just transitive. Everything is connected with the server and says, I want a patent and the server says, here are all patents, look at them yourself. Of course, this version would be completely private and the server has no idea what everything is interested in. But of course that's pretty ridiculous. Of course, that sends way too much data. Data banks with a corresponding size won't be able to send all the data in the right time. And of course there are other problems with it. And with the trivial PIR protocol. So what we are looking for in better PIR protocols is that we want to have more privacy with less data. And what we will see in a few minutes is that it is possible that there are some PIR protocols that can do that. There are different categories of PIR protocols and the first is computer PIR, where the security of the PIR system is based on it. I see that it leaves you. The server tries to find out what you are interested in. And that you assume that the computer doesn't have unlimited data and that it can't find out and can't break any crypto. So Alice takes her request and locks it up. And in contrast to a request where Alice sends a request via the TLS, where other parties can't read it, she tries to integrate the query to her own public key. So what can the server do with this PIR protocol? Well, as you can see, you can use certain types of public key encryption for a certain operation called homomorphism. You might have heard in the news about so-called full homomorphism, cryptography. You can use all the weird calculations that you can do with the high costs. But that's not why it's here. That's the so-called partial homomorphism. It's totally simple. What you can do with it is the server can take the request that is open to the public key and they can connect it to it and send an answer that is still open to the public key. And this is sent back to Alice and that's the general structure of computer PIR. These so-called homomorphisms are a bit more expensive. That's why it costs a lot to do this calculation. That's why there's another type of PIR, the so-called information-theoretical PIR, the IT PIR. What you do there is that the server, you're not going to assume that the server has a limited computing capacity. They are now unlimited. They can do anything. In no time. Alice's query is still protected. Alice's request must still be protected even if the computers are unlimited. We use a different approach, one that doesn't rely on cryptography but on information-theoretical PIR. That's why IT PIR, you need multiple servers and Alice asks each server a question and gets an answer. And then they combine these answers to get her answer. The security property we have is the non-treatment approach. That's a certain number of these servers that don't work together to break everything into a private sphere. And this approach is pretty... There's often in private technology, for example, a goal. If your path doesn't work together, then you're ruined, too. If all the servers are colluding against each other, then it's bad for you. Some kind of electronic voting has this kind of... E-voting also has this kind of approach. So it's pretty... There are many that combine these two. And most of them are combined. That means they're a bit of a computer protection and this information-theoretical protection together. And this is the information-theoretical PIR. And the advantage here is that this technology is 70 to 100 times faster than the computer-based PIR. So we have a certain advantage here. On the other hand, you need these multiple servers. That's the trade-off. So let's look at a... Let's look at a simple example of information-theoretical PIR so that you can get it. And I'm going to do a bit of math now. Please, raise your hands. Who's afraid of math? So let's go. It's going to be pretty easy. In some countries, that's maybe a high school level. In other countries, maybe an amateur level. But it doesn't matter. So about this level. Attention, vectors and matrixes. Yeah, all of them are happy. So vectors and matrixes. So this will be... If you're happy with that, if that's the case, then it's going to be easy. If not, then just do as if you understand it. So we're going to say our database is a matrix, right? A matrix is just a kind of a right-wing block of 0 and 1. Each row is one row. So this is one of the next rows. This is the first row, this is the second row, and so on and so forth. So we're going to say, there's R entries in this database. And each entry has 7 S bits. So there's an R times S matrix. And what the queryer wants to do is to get an entry, for example, the third one, and want to get one of the rows. Okay? So in order for the PR system to work, we need to call two facts from me from the first row. One is, if you take the elementary vector, if you take the elementary vector EI, which is all 0's and 1 and 1 and 1 in the octagonal, in E3, if you take EI, length R, and multiply it by this matrix, remember how it works? So trust me, what comes out at the end is the i-th row of this matrix. That means entry E. Okay? So if you could say, well, that's our protocol, it's that simple. You just make this vector with this index, the entry you'd like to have, send it to the server, the server multiplies the two things, and send you the answer. Okay, that works, but it's not private. The server just has to look at the vector. Okay, the 1 is in the third place. Okay, you want the entry number 3, 0 privacy. So the second part of mathematics is the distributive property. Remember, it works with numbers, but it also works with vectors. It works just fine. So the distributive law, if you multiply i times d plus wi, then you get the sum of the vectors times d. Okay, how can you make a PIR protocol out of it? Maybe you can already see it. Okay, here it works. Say, everything wants entry number 3. Everything constructs e3 and doesn't send it to anyone. And then looks for l server and looks for total random vectors under the assumption or under the condition that they sum up exactly to ei. Modulo 2. The easiest way is to choose l minus 1 vectors and then understand which of the last ones must be exactly to sum up ei. Okay, now we have total random vectors. We can send them to the server and each server only gets a random bit. And if you think about it, it has exactly zero information about this number 3. Okay, so each server gets zero information about it. That means, in fact, i, the same coalition of servers, as long as they're not all, has zero information about i. Yeah, what's the protocol?  And thanks to the disputive law, the result is exactly... the answer is exactly the sum of the vectors times d. Yeah, wonderful. Okay. Is this more efficient than the naive just download the trivial one? Okay, so let's think about it. How much data does it send? It sends everything here first. And it's one vector length r. And it's r bits. And how much does it get back? So it gets a vector length s back. That means it gets a r plus s bit sent back and forth. And how many bits are there in the whole thing? Well, this is much more than the reasonable values of r and s. And in fact, we get the best protocol if r and s are about equal. If the data is the same, that means the root of the size of the data bit is set to the root of the data bit. So the root of the data bit is set to the root of the data bit times l, the number of servers, as opposed to n. So you get exactly the length of a vector and not the length of the entire data bit. Okay, so that was one of the very first protocols that you thought about from Jordan and others in 1995, about 20 years ago. But there are a few problems, many of which have been solved in the meantime. First of all, let's take a look at this. The shape of this database is rather simplistic. The shape of this database is pretty simple. That means it's exactly a series of exact entries that have the exact same length. In the meantime, there are many other databases that are different, but they have extended this protocol to be able to function properly in the database. You might think, maybe it doesn't work, because you have to say, how big is the number of entries that you actually had? How does it work? With PrivacyAber, we did that. And further work was thought about what kind of request you can make. In this case, which we just talked about, the request is, I would have liked to have number three. In most cases, you don't know that. We know some characteristics of it. We say we need a more powerful request, for example, Keywords or, for example, SQL requests. And it was proven that you can do this. You can ask SQL requests without the server to share what the SQL request is. That's pretty cool. It's already available. It's available in code. Wonderful. So, this is what was done before. And another problem of this simple protocol is that it's not very robust. What do I mean by that? Look at this. What's happening? I'll go over here. OK, I'll go over here. OK, next slide. OK. Next slide, please. OK, there we go. Laser's working. OK. So, OK. What do we mean by robust? What do we mean by robust? Well, imagine one of the servers is broken and doesn't answer. Or one of these servers wants to attack and gives a bad answer back. Well, if all of this is added, then she just gets garbage. And she doesn't know which server you gave the bad answer to. That means a robust protocol would not allow some of the servers to deliver the correct answer, even if some of the servers are broken or damaged. And at the same time, if you identify which servers are bad or damaged, then you can isolate these servers. So, let's take a look at how this works. So, it works on a basis called Shamir's secret sharing. Who has ever heard of it? Not as many people as Matrizen. Who has ever heard of Polynomes? OK, good. Wonderful. We're going to use Polynomes now. So, Shamir's secret sharing. That means we have a secret, for example, the PAI. In this case, this vector, i.e., that means which number you'd like to have. We have a secret, and we want to share some of the secrets of this secret. There's some threat that there's a limit T. That means if you know right to T what the secret is, they have no idea what it is. They have no idea what the secret is. If it's more than T, then you have the secret. So here's how that's going to work. Here, I'll explain how that works. You have your secret, and you have your limit T. We're going to call it T. What you do is you draw your X Y. That means you plot the graph and draw a green point, 0, your secret. And then you look for a random Polynomes from level T that goes through this point. That means one random Polynomes is the level T that's a secret. So that's what you're doing. That's a secret, that's what you're doing. In one is a line, in the other is a parabolic curve, in the other is a random cubic curve. So what you do next, then you hand out other points on this Polynomes and you draw a green point which you do eventually. So what's about that, right? So let's just look at the simple linear case. If you have one dot, you have no idea what the Y-axis of overgang could be. It could literally be n. Right? Okay. And similarly, if you have two dots on the parabolic curve, you have no idea where the Y-axis of overgang could be. Right? Okay. And similarly, if you have two dots on the parabolic curve, you have no idea where the parabolic curve is. It could be anything. But if you have more than T, let's say you have, for example, two, in the case of the linear case, that means two dots make a line. We are, and immediately you have the secret. So this is Shamir's secret. This is what we use. And we use exactly this technique instead of sharing EI in parts. We share it in this more complicated way that the property has. You don't need the answer of all servers. You only need T plus 1 answers. Well, what if some servers give the wrong answer? In this case, we use a filler code, for example, which, if we have a wrong point, which point is wrong? Here's a quiz. T is three. We need a cubic curve that goes through all three curves. Seven, six points. One is wrong. Which one is wrong? Who says the one at this end is wrong? Who says the second one? Third one? Fourth one? Fifth one? Sixth one? Okay. The answer is, in fact, the first one. The answer is the first one. That's the cubic formula. And this kind of error correction is actually quite commonly. It's in CD's and DVD's, in QR codes. Do you probably know what this QR code is called? Yeah, okay. It was just a joke. But the reason why you use QR codes is that you have to do these things. You can cover a part and it still works. Which is, in fact, the homepage. And the fact is the homepage. Okay. So these error correction codes are used all over the world now. You just want to make sure usually that scratch is on your DVD or your QR code. Don't mess things up. You just want to make sure all of them are in PAI. So all of this is implemented in the PC++. Open, open... Quell Open Bludtik. It's a joke. Okay. It doesn't matter. For those of you who like Git, there's a Git. If you'd like Git, here is a Git that will not like source code. If you like to go to HTTP, then someone will find in the Git-Market. Okay. So now I'm going to turn it over to George. about the use of PAI to make private sphere a protocol. Thank you very much. Good afternoon, good afternoon, everybody. The cool thing with cryptography is that it's mathematics, mathematics is cool. But what's cool is that we can protect our private sphere with cryptography against people that we would otherwise have no power. And PR ensures that we can use private sphere in social interactions. We got social applications in the last 20 years, something like Twitter, Facebook. And we have chat protocols. It doesn't work sometimes and not other times, right? No, it doesn't work. All of these have something in common. They have a feeling that some users are connected with other users. And even with Twitter, where there is no secret who follows who, it's clear that who follows who. And when it comes to chat, because we also want to protect private sphere from people, the chat is present. Present means when there is a point that you see next to the name of a user, when this person is online. We are very used to it. In the past, we just called someone and just hoped that someone would pick up. And most of the time, nobody picked up. And when did you last have this frustration, maybe 10 years ago? Nowadays you can just see who is online, you can call and know that they don't answer the most of the time or don't want to talk to you. We just know that. And to prevent the fact that there is a strange feeling, we have improved this presence protocol. We don't only have green and nothing, but we also have orange, which means we are online or online. We are just gone or red, which means we are busy right now. And we have a little bit more information to connect with. We have a little bit more information in the middle. They say, I'm back in five minutes or something. And our presence ensures that we have exactly this information. So we ask ourselves how we create this presence, in services like large commercial services, as well as small services of good people like Jabba.cd. The way we do this is relatively clear. You have a server and you have a kind of social network. And you have a feeling that people here have friends or want to know who is online. And the server just has to know the complete social graph. And that's how you can create presence. And that's how you see that Bob comes online. And everything goes online. Everything identifies with the server. He says, hi, I'm Alice. The service knows that Alice is Bob's friend. And the server sends Alice a list of who is online and who is not. I'm clicking furiously here. So I'm going to move over here. And presence information is written back. And it's rotated back. And there is a fundamental private phone problem with these services, these social graphs. Now, what is the problem with that? The problem is that if your friends are, means a lot, let's know a lot about who you are. If all of my friends are hackers, it's a great chance that you're a hacker. If all of my friends are journalists, then it's a great chance that you're a journalist. If all of my friends are from Sudan, then it's a great chance that I'm from Sudan. And these lists, let's know a lot about who I am, who I have in my circle of friends. They say a lot about me. If I have a lot of doctors or lawyers in my circle of friends, then they say a lot about me. They ask you, why, where is the problem with that? But as we know from the Snowden Libs, if we have services that have this information, that means that the government that wants to have this information, for example, to a service like LavaBit, just goes to this service and says, can we have this information? And there are special programs that spoil these data banks. Either they force these providers or they just spoil the data directly from the management. We had an interesting... We had a very interesting... We had a very interesting... We had a very interesting... We had a very interesting... Michael Hayden from the NSA just admitted last year that we are people on the basis of their metadata. That means, in the worst case, you can land on the surveillance list depending on who you are friends with or the goal of repression. And we want exactly these data to be hidden and to ensure that we can no longer find out who we are friends with. What do we expect from a private scene? First of all, there are some functional features that we won't be able to lose, which we will continue to have. We want to continue to associate with friends so that we can see that they are online but do not wish to share any more information with them. We want our operations-friendly system to be consistent against some pretty serious adversaries out there because we know that they are in the different ways. We see more adversaries out there and a lot more communications on the network. We want to hide information even from a lot of users out there. We want our operations-friendly system to be consistent against some pretty serious adversaries out there. We want to hide information even from a lot of users that we have. How way that we will, even if we have some things up our sleeve that we can still do. For example, that our computer is safe. Well, if that's not the case in your computer, then talk to the people in the details or anything else. And we will, that we will not, we will not take advantage of this particular infrastructure that we do not work with these enemies just as Ian said before. And with those tools, with these tricks, we would protect the privacy of our network. We want that no third party and in particular, you will associate this integrity and also find an additional property, These most noteworthy things we want to be able to do is, for the first time, the unconnectedness, which means it's not possible to collect information that can be collected over time to be able to use them together. That means, and furthermore, to resist very harshly. So, furthermore, some of you already be thinking, hm, a few of you probably think that there is a very trivial way of doing it, and this to implement is not particularly difficult. We simply have Alice, and she basically also has a anonymity channel, like a channel, for example, Tor, to a hidden service, or a hidden service, or a different channel, and then we have Bob, who also registers. Yeah, he also says, hey, by the way, is Alice the pseudonym online? You may think so, but perhaps you think, ah, that's the problem is solved. Unfortunately, it's not the case, because the server can link the pseudonyms of A and B together. And then she knows about the hidden services, and what happens is that the server can construct an isomorphic social graph to the real graph, which means that we only have pseudonyms connected to the pseudonyms. But the form of this graph is exactly one-to-one mapped to the original graph. Despite the fact that these pseudonyms are, for example, A and B instead of all the information. Well, if the server has any additional information, for example, if friends have online video reviews, then it can be that they can use this information to solve these one-to-one graphs. And we have a certain example that you can do exactly that. Yeah, that's not just this problem, and friends can not only go to this server and get this isomorphic graph, which is almost as real as the real graph is. We don't want to do that. We don't want to give no information, not just a high-level overview of how do we actually use it. And you can recognize a few of the ideas that you might mention. So the thing is, for example, if we have Alice and we have Bob, but we have all these friends who would like to use a service on a specific protocol called DP5, and that stands for the last tool privacy-preserving protocol and the extra piece for extra privacy. So they would like to use a service that runs a DP5 protocol to gain as a presence information, but we want all servers that have a DP5 protocol not to be able to extract any information out of it. Let's see how to do that. First of all, the service should not actually be able to extract any information out of it. So we should have Alice and Bob in a certain secret that they have to extract when they need to have Alice and Bob in a certain key, a crystal key, for example, like public key geography. So first of all, Bob has to send a certain kind of information about his status to the server. And then naively, you may think, well, maybe you can think of yourself naively, but you have to ask, you know, is Bob there, is Charlie there, and through this information. However, this would be insecure, I think, because that would lead to the information price that Alice and Bob are associated with each other. Because they would say that Alice and Bob and Charlie are connected. If at this stage we had some kind of mechanism that we would have at this moment for a particular record so that all the server can ask a certain entry, without the server knowing which entry they would like to have, that we would solve exactly this problem and this private presence. This is exactly the protocol Ian talked about before and the Ian side behind the DP5 protocol. And that's exactly the trick with this protocol, is to use these private, so-called holding requests, to use them so that all these requests can be sent without the infrastructure learning what they would like to have. Okay, so it works on a critical level. We first distribute the time in epochs, they can be shorter or slower. The idea is that at every epoch users register their presence with service and after each epoch users can actually recover who's on-line. Okay, when Alice, when she needs to register, first of all, is here with Bob, and you can use the random function, which you can think of, and use an pseudo-accident function, for example a hash function, and basically applies that to the time epoch I, and gets two things. First of all, she needs an ID. Alice is present at this time period, and she will register in epoch, and the second is a symmetric key. First of all, can use the symmetric key, can access the first status using a protocol, and use a certain method, named AED, authenticated encryption with associated data. That means it's just secure encryption, you can think about it. And then she can make a record of the ID for this period, and the encrypted status, and just store it in the database. Okay, now Bob comes along, the next period, and we'll find out if Alice is on-line. So Bob, of course, shares a key with Alice. Okay, Bob has a key with Alice in general, and uses the same function, with the same key, and uses that on the previous epoch, and extracts, hopefully, the same ID and the same key. And under the use of this ID, and the protocol that Alice is using, Bob tries to get this ID that Alice had left behind, and hopefully gets the ID back, and extracts this ID with the same key. And if Alice is on-line in the previous epoch, and for them all, we can get the status. Okay, now, I hope that everybody is half convinced that this just works. And if, under our assumption, this system would work, and these properties would have, and these functions would continue to be filled. However, there is a problem with all this, which is associated with the fact that the database tends to be very large. That means, for every, every connection in the world, you need a request to the database. We would also like to have additional requests, so that we can hide how many friends have a certain friend. For example, someone has a personal, always 100 friends, no matter how many friends there are. The database can actually be very large. That's a problem. The large database is less efficient. And we would like to work really hard to capture what is possible. We would like to have this epoch as small as possible, so that we can have this registration and this request as short as possible. If it's too long, for example a day, then you can find out at the highest that someone was there yesterday. It's not so useful. So we need to do something to improve our efficiency, so that these queries are very fast. And this registration is very fast. And as I said, the problem in computer science can be solved with another layer of redirection. In fact, the problem in computer science can be solved with an additional layer of abstraction. He invented the subroutine of many other cool things, which is indeed a layer of redirection. He would like to applaud, because he thought, among other things, my subroutine, the subroutine, that would be another level of abstraction. He was, in a way, enough that this normally creates another problem. So what we do basically is we run two versions of the protocol that are the same. We just make two versions of the protocol. At the same time, the one feeds the other. We have two different types of epochs, a long epoch and a short epoch. And basically first of all, we have Alice and Bob. Alice and Bob save one kind of entry into their long databank. And as a status, just a public key. So now Alice is basically in a long epoch that we have built. That means Alice is in a long epoch, for example, a day, and just saves her public key for Bob in the databank. And then in the short epoch, Bob can both really use the public key associated with Alice in the long period and the long databank. And at the same time, use the short epoch. Now, the trick here is to share by all friends of Alice. The trick here is that the public key, where we have all friends of Alice, is shared with Bob in the long term. We go from one record per active user, which is a short period per active user. That means in a small databank, you can use that. And you can save the epoch as short as a minute or a few seconds, depending on how many machines you have. And then Alice can use this public key in the short, living databank to save her status. And Bob can use these holes every minute, for example. And then she can make sure that she is online and has an up-to-date status for her. The status is very important to us. We don't think it's just like, I'm busy or something, but it could support other protocols. So you can make sure that, for example, the status of our content could contain the information. Oh, by the way, here is my pseudonym that I can use. Or here is the address of a Tor hidden service over which you were speaking to me. We would like to share this information. We would like to have this information so that we can use even more secure chat protocols with this protocol. So Cypherpunks write code, I believe. Cypherpunks write code. I think that's how you should do it. I think that's how it's going to go. So all of this has been implemented. We use the Percy plus plus code as a kernel. And the rest of the DP5 protocol, I don't know if you can see plus plus. And we use Cypher plus plus. We have Python bindings with Cherry Python work. And we have Twisted to implement all of the networking. So that we can time it and make sure that it works. So we're still working. But it has to be integrated with any client. So the protocol is there. We have the protocol. But we can't find out who is online if not. With real users. We only listen to our test robots. That's still missing. We'll work on it next year. And the cost of running this is surprisingly low because it's not that high. Certainly the cost per user rises the more users you have. Unfortunately, the cost per user rises depending on how many users you have. If, for example, you have 10,000 users, it costs about a small fraction of a penny. If you have millions of millions of users, it comes from the fact that per user it costs a dollar or more. So what are the messages from this? Metadata in chat protocol. Metadata in chat protocol is a goal for the NSA and everyone else. We absolutely have to make sure that if we are serious about our content. We know how to make content. Metadata is not so good as a general approach. Private information as a general service is pretty cool. We can do things that you might not think it's possible. And you can use this protocol to implement a particular protocol about presence. And based on the heuristics of this protocol you can actually use it realistically. Thank you very much. We would like to answer your questions. Okay. Could you line up at the microphones? Can you put up a question here? One question from the Internet. Our first question is, how can DP5 prevent which they don't want to share with her? We can prevent DP5 from getting information about anything or Bob gets with which they don't want to share with him. At the beginning we all had a Bob. He had to share a key. And he shared a key with each friend. With this key Bob can get information about everything. But all of these are non-friends. They can't get this information. But Eve wouldn't have shared this key. So Eve wouldn't be able to get this information. Okay. Microphone number four, please. Hello. I wanted to ask if this price graph looks pretty terrifying. That's a million dollars a month. Yeah, it's exactly right. Yeah, it's a lot of money. Yeah, it's a lot of money. Yeah, it's a lot of money. But if you think about it, if you have a million users and for a cost of about a dollar per month, it's not completely ridiculous. I'm sure that the price per user goes up. It's just because of the PII. The big data bank is scaling with the number of users. That means every request has to go up on a bigger data bank. That means the user for the cost of the PII is proportional to the data bank. You can think about it well. If the server doesn't know anything about the request data bank, that means every request has to go up on a particular data bank. That means if it doesn't touch a particular data bank, it's clear that you're not interested in this request. That means the server has to touch every request on a particular data bank. That's why the costs are proportional to the data bank. Okay, microphone number one is up there. Hi, thanks for the interesting presentation. I have a question about the non-collision as well. In the scenario where there's a patent server, everything is trusted by the one server, but it's not the information that's been added. It seems like in the instance where you put the data, but at least one server has to trust that it doesn't work together. Why is the first patent not meaningful? But the second one is that if you... Why would you trust the one server? The one trust is not... The patent is a bit strange. I agree with that. For many protocols, you can't achieve them just with your communication part. You can't reach it alone or with your partner that you can do this. The general wisdom is that you have to use some certain information. That means if a person is corrupt or under stress, however, if you have one person more than one person, you have to corrupt them all or work together. So, all the logic that goes into why we trust things like onion or mixed networks or so on and what you trust is more than one. Why do you trust more than one person? Because they're in different countries or because they're under different operators that they're under different things and to hide data. Logistically, it's just difficult to go to so many services at the same time to get this secret information. It is perfectly clear. It is absolutely forward secret. That means you have to... That's a post. It doesn't work. You have to do it simultaneously. It's a social announcement. That means these social announcements are a bit strange. They are based on us. And we give this security. And just like other free software projects, it's not automatic. If people like us don't do these things, then it's very unlikely that others will do it. Okay, microphone number six, Daniel. The base effect of performance. Even the sharding, the performance of the data bank... If you damage it in, for example, K parts, then the performance gets better. But then only users in the same shard can be friends with each other. If your user population naturally falls into these shards, then it's exactly the information you're trying to protect. Exactly the information you want to hide. You don't want someone to know in which shard you are. That would be visible. We try not to do that. Even though the performance gets better, privacy gets worse. And two more from the internet then. Hi, quick question. Doesn't the public key that's used to carry the short epoch database, doesn't that allow a third party to reconstruct, again, a graph which represents the real one? Or is the public key also behind a PIR that doesn't really make it public? I understand the question. Can you understand that? Only Alice's friends can learn this public key. That means you have to go through the first step of the DP5 protocol, and then only your friends have it. Only your friends have this public key. That means the key is public in the sense that Alice has the secret half of it, and your friends have the public key. That means it's not really public. It's not part of the query. No, no, no. No one is going to give it to anyone else. The second round is based on their key on the first one. That means it's not going to be published that way. Question from the internet. There are similar questions. The question is, what do I have to do to use the Jabba? And the second question is, can I distribute the DNS system? Can I use this for X? Well, the first question is more easy. The first question is easier. The second question is for you. What do you need to do to use the Jabba? I understand. You have to take some time to integrate it with Jabba, which we haven't done yet. We've already thought about how to do it, and we believe that you can use a kind of Jabba protocol proxy where your client talks to a certain local proxy, and the local proxy replaces this various information and then reuses it so that you can use the Jabba code. We haven't done this work yet. This is one of the most difficult parts of this work so that it's really usable. We haven't done that yet. The second question is, how can we use that to do DNS? It doesn't fit so well with DNS, because DNS is the whole trick. Everyone has to know the DNS information, right? That means it fits better on a SMS system. For example, Alice wants to tell Bob what to say a certain information, which would be the auxiliary, the extra information. For example, DP5 or an X protocol can be used for some kind of more messaging, so for a SMS system where all these specific messages to one person or a small group of people, for example, your friend in this part. With DNS, all the messages don't fit so well with it. Okay, two minutes left, two questions. Microphone number one. Two minutes left, two questions. Microphone number one. In the protocol, Alice saves everything, her connected communication with her IDX and then Bob asks this data bank after this IDX. What's behind the server then for me to find that out? Yeah, the clue is exactly the approach with PER with privacy, on a kind of way so that the server doesn't know what this ID is. That's the model, right? Yeah, exactly, we use this model, exactly. Microphone number one again. Microphone number one. What happens if the data banks are not synchronized? If they run out of sync in a time period and have a little bit of concurring information about the same user? Yeah, that would be bad. But it's not so bad. Because, as I said in the first part, at the end, these PER protocols are robust. That means certain servers are not synchronized as long as there aren't too many. No problem, because the robustness properties of these PER protocols will be solved by thinking, ah, that means that as long as the other servers are not synchronized, the answer to the biggest part of the server will be the answer. It's no value in between. It's the most agreeing number. It's not the middle value, but the main technical value. Okay. So unfortunately, you have to close the Q&A now. We have to use the Q&A session now. Thank you very much. Thank you very much. Thank you. That's the end of the session of DP5 PR.


Hello, welcome to this week's Legislative Update. I'm Jim Baumgart, your host and Nanette Willebusch to my left is the co-host. Thank you, Jim. To this wonderful program we have today because it's wonderful because we have Jowyn County's outstanding treasure with Laura Henning Lorenz and she's the only treasure we have. That is correct. Welcome to the program. Thank you for having me. We have, of course, what our founding fathers thought was important and it was is to have local people elected to offices and we have sheriffs and we have Regis Burdeed, treasurer, court, all of those individuals and they have oversight by the county because they have county government and they have oversight by the people. It keeps our government honest and it really improves the quality of service to the people because we're all accountable and so we wanna stress that and this program and the next four or five programs we have coming up which we're gonna invite local elected officials be they Republican or Democrat to explain what they're doing to make Jowyn County better. Right. I think Nanette wants to ask you a bunch of background. Yeah, thank you Laura. Thank you so much for coming in to visit us today. Thank you for inviting me. You're welcome. So why don't we start out? Tell us a little bit about yourself, how you came into this profession and maybe a little bit about how you became elected to treasurer. Okay. Well, first of all, my husband and I are lifelong residents of Sheboygan County. I graduated from Lakeland University. Go muskies. Yes, go muskies. And I have a bachelor's degree but I majored in accounting and business administration and then I minored in economics. I think that background led me to loving the world of accounting. So, and many other aspects that are in our office right now but the accounting piece. And then when Sandy Fisher, former county treasurer retired, that was when I decided to run for election in 2002. And then after winning that election then I took my oath of office in January of 2003. And have been accountable to the people ever since. Yes. Yes. Very much so. And they keep watching us, don't they? They do. Yes. That's a good thing. Anyway, so tell us what does a treasurer do? I'm thinking of those green guts in Harry Potter where they're sitting in this tall tower counting money. I'm guessing you're a little bit different from that. A little bit. Certainly we are the fiduciary for the county. You know, it's our responsibility to safeguard the people's money. And I think most people realize that we collect taxes. We collect all of the delinquent and we collect second installment taxes. But other things that people aren't maybe as aware of that we do in our office is we also do real property listing. We work with the assessors and we do assessing. We work to gather the assessment data from the assessors. Not only the local assessors, but also the state assessors. And we also oversee the lottery and gaming credits annual certification. We work with all levels of government, all the different entities, so. Town cities, villages. Town cities, villages. We work locally at the county level as well. We work with all of the different departments. We work with the county board. I report to the finance committee. And of course, then also the county administrator. And I just want to clarify, your office does not set the property tax rates. Those are the individual municipalities, correct? That is correct.  We collect the data from the various municipalities. We have what's called a mill rate form that's filled out every year by each of our 28 municipalities. And they provide us with that information so that we can do the calculations and then ultimately print out the tax bills. So yeah, we also work with the state legislators and also once in a while, not often, but once in a while, we even need to work with our federal government as well. The kind of thing that takes place is important because the things we do in Siobhan County can be affected by what happens in Marinette counties and other counties. And so you have an association that tries to coordinate the best policies that works for the most counties possible, don't you? Yes. Actually, I belong to three different associations. The association that I'm most active in would be the Wisconsin County Treasures Association. They hold quite a bit of education. The association works with the University of Wisconsin to keep us well informed and up to date and continually educated. On the cutting edge. Yes. And really, what a lot of the viewers may not realize, your staff and the staff of many County Treasures Office are updating their staff so that when there are changes, there are computers saying they can save money or save time for the taxpayers. You try to get the legislature or the county to make those changes so that they benefit the people the best possible. Right, right. So we often, so a good example of some of the technology that we've recently implemented. We just went live in September, so last month with a new land record enterprise system that was a two year undertaking before going live. And then we also went live last week with our web portal. So all good and exciting things, new technology that we implemented. I wanted to ask, I know there's a push at the state level and in some municipalities to make this an appointed position. For as long as I know, the Treasurer's always been elected and I'm guessing you would say you would like to keep it that way. But why, why is that important to do that? Well, yes, the County Treasurer's position in Sheboygan County and throughout the state is an elected position. It's a four year term. I think that it's important that I stay elected, that the position remain an elected position as well as several other county positions. Some of the reasons for that would be, certainly we are accountable, as Jim mentioned at the earlier in the program, we're accountable to the people. I think that's a very important mechanism in our, every day that I walk into the office, every day I know that I am serving the public. I'm not always thinking that I'm the county treasurer but I'm thinking I serve the public and that's what I am here to do today. I'm to work as hard as I possibly can and to serve the public. Could you imagine having Laura walk into an office and she's at the treasurer's office and she is at the beckoning of a county administrator who can hire or fire her. She may not be willing to raise a question because her job is on the line. Now it's still on the line if you're elected a treasurer but you have the ability and the pulpit to be able to say we shouldn't be going in this direction. We should be doing this because it doesn't benefit this industry, it benefits the people and taxpayers of Wisconsin or Sheboyton County and you can appoint people and it looks smooth but at the end our forefathers said that's not good because we're gonna have problems down the line and I think our elected officials and some of them that we have I didn't vote for but I think we have quality people running and I think they do a very good job and it should be the people's right to decide if they shouldn't be there rather than some administrator who may wanna fire them because they're not jumping to hither or two. Yes and you know to add on to that the Wisconsin Constitution leaves a wide variety of checks and balances in place for both the elected officials and appointed positions and then at the county level ultimately we all report to the county board ultimately the county board reports and is accountable to the public. So the checks and balances in place are important. They work well, they're very efficient and very effective currently in our society. Well we had a financial person in one of our townships appointed position that they didn't catch doing something wrong for a couple of years and in the kinds of checks and balances we have on the county level that's unlikely to ever possibly happen. I mean anything's possible but just our forefathers were very wise in making sure that we didn't destroy ourselves because we were thinking we're being so much smarter than they were. You answer to us not to a bureaucrat. Not to some of us. So what are some of the things that you at the duty that you'd like to stress? Well going back to the associations that we belong to several members in our office belong to the Wisconsin Real Property Listers Association. So there's folks that are very active with that association and then they also belong to the Wisconsin Land Information Association. All good associations that provide continuing education. So those are all very important things. Excuse me, is there a misconception? Is it something, here's your chance to clear up. What do you think? Is there something that people don't understand about the treasurer's job that you wish they did? In the next minute. In the next minute. Just real quickly, sometimes people think we collect the current or first installment taxes. That we always want to let people know and it is stated inside the tax bill that that one they need to pay at their town, village or city. That's the big one. And of course, we have many local banks that assist us all during the year to collect first installment and or second installment. So we encourage folks to utilize that option if it's convenient for them. We do want to thank Laura and Lorenz. Our present county treasurer who has been around for any number of years. 2002, correct? 2003, January of 2003. Is that right? And we want to thank you for coming and sharing with the viewers the duties and responsibilities of the treasurer's office and the importance of its elected position. Till next week, this has been Legislative Update.


Hello, my name is Tori and I am a Libraries Fellow at NC State University Libraries and I am co-presenting today with my colleague Kevin Beswick, who I will let introduce himself. Hey, I'm Kevin Beswick, I'm the Associate Head of the Digital Library Initiatives Department here at NC State University Libraries. And today we're going to be speaking to you about a new program from NC State University Libraries called the Library Technology Career Jumpstart Program. And here is a preview of what we're going to be covering in this presentation. So we're going to start with a brief overview of the background of the program and how it came to be. And we actually also gave a project briefing on the Jumpstart Program last year at CNI after we just wrapped up the first run of the program. So we're not going to be going quite as in-depth as we did in that presentation last year. That is available on the CNI YouTube channel if you would like a deeper dive on some of that. But from there we're going to talk about our assessment efforts, having not completed two runs of the program and having analyzed the data from the program. And then we're going to wrap up by discussing some of our initial thoughts on the future directions of the program. So to begin, what is the Jumpstart Program? The Jumpstart Program is a free, immersive, week-long experience that helps to position first-year library school students for career and library technology upon graduation. It includes technical skills workshops on topics like version control with Git and GitHub, coding in Python, and web development. And it also includes a variety of other professional development opportunities as well. And we began this program in recognition of the fact that recruiting for technical positions in libraries is often difficult. This is something that we've seen at our own institution and something that we've heard from colleagues at other institutions. So this difficulty stems in part from the fact that LAS students just have differential opportunities to build their technical skills. And we wanted to help fill that gap a little bit. So one of the first things that we did as a planning committee was clarify the overall goals and objectives of the program. So we wanted to increase awareness of technology careers in libraries. We wanted to increase diversity in this area of the profession. We wanted to impart some strategies for learning technical skills, as well as provide concrete steps forward towards a career pathway in library technology. And we wanted to create a welcoming and inclusive space for a diverse cohort to learn from each other, while also fostering a community of professional and interpersonal support. So one of the goals in this list that we spent a lot of time on is considering how to recruit a diverse cohort of students each year. This is something that's important to us because we acknowledge that librarianship as a profession is made up of mostly white women. And tech positions also tend to be occupied by mostly white people, whilst being more male. Intentionally cultivating a plurality of perspectives and technical talent is only going to make our institutions and our technology stronger and will help us better meet the needs of the diverse communities that we reach on a daily basis. So given this, we wanted to make sure that our application process and the program itself is welcoming not only on the basis of gender and race, but also in terms of other demographics, such as ability, academic background and geography. Our goal has been to make the application more barrier. The application package consists of just the online application form and a resume. But specifically, don't ask for professional records because you know that that can be an unnecessary burden for folks, especially for a program like this. And we limit our choice of questions to just four, keeping those limited to 150 to each. So on the slide here, you see the wording for some of our recruiting materials and application questions as it appeared on our 2021 application. In general, what we were looking for in submissions is a demonstrated interest in pursuing career and library technology, a commitment and a willingness to learn technical skills and a persistent and creative approach to solving problems. And having now recruited and worked with two cohorts of students, we can say that we were indeed able to build a really awesome community of learners that has comprised of future library professionals from a breadth of backgrounds and experiences as well as career interests. So all of our participants so far have held at least one identity underrepresented in technology or librarianship. And they have joined us from a wide range of schools with express career interests in everything from web accessibility to user experience to human computer interaction and digital asset management. But that's a very broad overview of the conception of the program and how we put our cohorts. And now I'm going to turn it over to Kevin to give us a glimpse of some of the program content. So in addition to the technical workshops that you might expect from a program like this, we thought that it was important for people to hear from current library technology professionals about what it was like to work in the field. The range of work that we do as library technologists, as well as hear stories about how people got to where they are today. We designed panels to touch on these topics and to include perspectives from a diverse set of staff, including early career, all the way to administration and touching on a range of departments and roles across the libraries. Our goals for these panels was to draw connections between the skills that we were introducing the participants to and the work that actually happens in the library and to inspire participants by showing them that you don't need a computer science degree to get into library technology and that many people begin their library technology journeys in library school coming from a variety of different backgrounds. The topics of these panels were the same as last year, but we had an entirely new set of speakers for each for this year. The other major type of session that we planned was looking at our bigger picture of library tech. So we offered an HR session that included our associate director for organizational design, equity and talent, where participants learned about the application and interview process for library tech jobs. We also had a question and answer session with our senior vice provost and director of libraries and our associate director for digital and organizational strategy, where they touched on topics like organizational structure, the future of library technology, offering a higher level perspective of each. And then the jumpstart program also included a mentorship component. So each participant was paired up with the library technology professional. We made these connections based on what we learned during the application and interview process and tried to match with someone that had a common interest background or career trajectory. We asked each mentor to schedule at least two meetings with their mentee, one during the program week and one post program with each pair being able to decide if they wanted to continue the relationship beyond that. This year we were more intentional in preparing the mentors and mentees ahead of time and setting expectations. And if you saw our presentation from last year, you'll remember that we had a more packed and ambitious program planned for each day. But with the program being shifted to offer online, we had to make some tough decisions about what content was most important to offer. But rather than cut entirely, we organized a bundle of asynchronous content and offered participants this content in a variety of mediums with the help of over 20 of our colleagues in the libraries. So in their information packets, participants had access to the content that you can see on this slide. Our hope is that the participants can refer to this content at a later time when it's most directly relevant to their lives. So like when they're considering applying for jobs or they're just starting out in the profession. And all of this content wouldn't have been possible without the help of our colleagues around our library. So over two dozen in total participated as presenters, panelists and workshop leaders and asynchronous content producers. So I'll pass it back to Tori to talk about our process for evaluation and assessment of the program and what our participants thought about it. So in terms of assessment, we wanted to measure what sort of short and long-term impacts participation in the Jumpstart program might have on participants' perceptions of and their intentions to pursue careers in library technology. And to measure this, we sent out a pre-programmed knowledge and attitude survey, a post-programmed knowledge and attitude survey as well as a general satisfaction survey. And we also conducted some six-month post-program interviews with the first cohort, which we're also planning to do with the second cohort as well. And so our completion rates were actually really stellar overall for the surveys, as you can see here. And given that, we feel pretty confident about the conclusions that we were able to draw from the responses that we received. So the open text field on the general feedback survey was able to pull for us some really great positive as well as constructive feedback. In terms of constructive feedback, really appreciated folks' honest and thoughtful responses here is what allows us to make iterative improvements to the program each year and make it the best it can be. So our 2020 cohort, for example, brought up some important points about accessibility and expressed things like a desire to have more opportunities for cohort building and more pre-work and contextualization before arriving, as well as a more streamlined troubleshooting process. And so these are all things that we were able to do our best to accommodate in the 2021 cohort. And then in terms of some positive feedback that we received, here are some high-level themes that emerged from that. So overall participants reported that hearing from library technologists really helped demystify careers in library technology that they were able to see how the text fields that they were learning could be applied on the job and that they also really appreciated the structure of the program given its online delivery, including, for example, all the asynchronous content that Kevin just talked to you about. And so one participant stated that this is a much needed program that they would definitely recommend to other LAS students which confirmed one of our most exciting data points, which is that all students from both cohorts who completed the survey strongly agreed with this statement that they would be likely to recommend the Jumpstart program to other LAS students. So that was really great for us to see. And then here are some examples of some of the pre-to-post knowledge and attitude survey items. So what we were trying to get at with these was students' self-perceived confidence levels in pursuing library technology careers, said both before and after the program. We asked them things like, or we presented them with statements such as, I know what technical skills I need to learn to be successful as a librarian. I'm confident in my ability to learn those skills. I'm aware of my career options in library technology. I'm likely to pursue a career in library technology. I know someone working in Lib Tech I could reach out to. I'm not sure how to best present myself in a resume cover letter or interview. And so students answered all of these statements on a five-point Likert scale, ranging from strongly disagree to strongly agree. And overall for both cohorts, we saw at least one degree of improvement for most participants across most items. We did see some interesting regressions. So for example, one participant moved from strongly agree down to just agree for I am confident in my ability to learn the technical skills that I need to know. But that same participant also moved from neither agree or disagree to strongly agree on I am likely to pursue a career in library technology. And they answered that almost all of the content was new for them. So that was similar across some other participants as well. And we really still consider this to be a success because we figured there might just be some done in career effect going on there in which participants came in rather unaware of everything that they needed to know to become a library technologist. And so then once they became aware of all of that, it might have been a little bit overwhelming, which could explain a minor way in self-confidence. But given that by the end, all participants either agree or strongly agree with the statement that they would be likely to pursue a career in library technology. It seems that we were still able to accomplish our goal of raising the profile of such careers in the minds of students that we worked with. And hopefully they now have a much more realistic pathway for how to continue working towards these careers. And then in terms of our six month followup interviews, our hope there is that they would reveal any potential long-term shifts in thinking for students on their career planning. And this is just the data that we have so far from our 2020 cohort, three of eight participants completed those interviews. And from those participants, we heard overall that the Jumpstart program really did introduce them to career opportunities in library technology that they had not yet considered. And that it did have some impacts on the types of courses and internships that they pursued and the confidence with which they pursued them. One participant summed it up really nicely when they said, I don't think it's like a boot camp. It's more like a space to introduce students to this world so that they make better choices about what they want to learn and how they want to spend their time in grad school. And this was really great to hear because very much in line with exactly what we were trying to do with the program. And then in terms of assessment, I'll just leave you with this second really great quote from our 2021 cohort. The Jumpstart program exceeded my expectations. I expected to learn something about GitHub, Python, HTML, et cetera, but I also gained a lot of confidence through this program from the hands-on learning and working through problems with troubleshooters. Hearing from professionals in the field about how they got to where they are today gave me insight into how I can gain experience and learn the skills I need to start a career in this line of librarianship. So again, that was another really affirming thing for us to hear. And with that, I'm going to pass it over to Kevin to take off the conversation about what might be next on the horizon for Jumpstart. So offering the Jumpstart program each year is a fairly big undertaking, requiring a lot of time and effort from the planning committee, panelists and workshop facilitators and participants and then asynchronous content creators and especially from Tori who acted as project manager, lead logistical coordinator, people wrangler, communicator, workshop leader, panelist and countless other roles. So we've offered the program twice internally and we've validated that it is valuable to students and the profession, but we've also learned that offering the Jumpstart program ourselves each year is not scalable or sustainable in the long term. So after the offering of the second iteration this past August, we've started to think about the future of the program and those questions of scalability and sustainability of the program and an effort to bring more people into the area of library technology. So what's next for the Jumpstart program? We know that we'd like to continue being a part of offering the program in our local context. We have four library schools within a 100 mile radius of our area and many university libraries with a need for library technology talent in the area. So one potential direction we could take is to broaden the scope of the program to include more than just our library. So we could partner with other libraries to share some of the logistical effort of organizing the program and expand on the perspectives represented within the program. We could consider expanding even further than our local context here in NC and partner with other interested libraries or organizations from across the country as well. We're looking into the possibility of applying for grant funding to explore these questions further and to help keep the program running while we figure out how to proceed with it into the future. We've also put some work in scaling the offering of the program. So one of the things that we believe is valuable about the program is the intimate nature of it. So by limiting the number of participants we're able to offer meaningful cohort-based experiences one-on-one mentorship and the opportunity for each participant to engage with panelists and workshop leaders throughout the week. We don't want the program to feel like a webinar. So this creates some challenges around scalability and now Tori is gonna talk about how we're approaching that. So in addition to those strategies just mentioned by Kevin something else we are interested in and helping kick off is essentially a network of similar programs at institutions across the country. So after getting several inquiries from other organizations wondering how they could do something like Jumpstart we decided to create a comprehensive how-to guide that chronicled our process from the bottom up and that is available at the link on the slide. That guide includes helpful information about everything from getting institutional buy-in to building your planning committee to soliciting program content to the technical aspects program delivery and a lot more. We've heard from a few groups that they already have their own version of the Jumpstart program in the works based on this guide and conversations that they have had with us. And that's definitely something that we want to continue to encourage and we would love to chat with others about that if that's something that you're interested in. And so to close this out if you have any further ideas again about how this program can continue to expand please reach out to Kevin or I. We welcome thoughts, feedback and questions. We've also listed on the slide a couple of important links so that you can learn more and we look forward to hearing from you.


Dialogical interactions challenge students to think in novel and flexible ways about various topics and issues. The language teachers use to communicate with students is critically important in helping students to understand what they are learning and how they can be effective learners. In Dialogical Teaching, teachers ask questions that probe for more detailed responses so students learn to provide answers that elaborate on information and ideas and are well reasoned and justified. Feedback is informative as well as encouraging in an environment that invites open discussion. Such an environment can be seen in small, co-operating group situations where teachers often use language that is more friendly and personal and more dialogic as they encourage students to elaborate on their ideas, build on what others have to say and provide reasons and justifications for positions taken. Teachers are encouraged to use two types of discourse in classroom interactions. A third of discourse is used to direct students learning to key points. This type of talk is often used when teachers engage in direct or explicit teaching where they want to ensure students develop specific understandings about a topic. In Dialogical Discourse, teachers discuss topics of interest together with students. Students and teachers present ideas, consider alternative solutions, clarify concerns and work to promote understandings. In so doing, they tend to engage in sustained interactions as they build on each other's ideas to develop lines of inquiry and thinking. Dialogical Discourse often occurs in small, co-operating groups where students are working on a problem-solving task together. In this type of situation, students need to harness the potential of all group members and this means listening to what others have to say, contributing ideas, challenging others' perspectives and synthesizing key points to arrive at an agreed solution or outcome. The teacher's role is to act as a facilitator, challenging and scaffolding students' ideas to help them develop a clear understanding of the topic. Now let's have a look at how Wendy Mercer uses both authoritative and dialogical talk in her classroom. As you watch, jot down each time Wendy shifts from one kind of talk to the other.