Last year I got on a hotel elevator in Toronto, with three men, a staff member of the hotel and two others. I hesitated before getting on, but I thought better of it. There was a staff member, it was a nice hotel. But I did something that should have clued me in. When I got on the elevator, I pushed the button for the wrong floor. The staff member got off on the fifth floor. I had 14 more to go. The doors closed, and I felt the large man behind me grab my backpack.  I froze. I made myself small. I tried to ignore him. Eight more floors. He persisted. What's in there? My heart raced much faster than the floors were ticking by. Eight, nine, ten. I realized that if they wanted, those two men could drag me off the elevator and into their room. And I would be more or less helpless. The doors finally opened, and the man to the right, who was much less drunk than the man behind me, dragged him off. The doors shut. I was alone. But I felt anything but safe. I felt vulnerable, exposed, fragile, scared. I went up in the elevator to the wrong floor, found the stairwell, walked down. It was eerily quiet. Found my door, fumbled with the key, got inside, locked the door. I called my mom, and I sobbed. I got lucky. That story could have taken a much darker direction. I travel alone a lot from my job to conferences. And that experience fundamentally changed what I act like on the road, the precautions I take. After that experience, I became extremely interested in the instinct of fear. Because the clues were there for me. I hesitated before getting on the elevator. I had a bad feeling. I pushed the button for the wrong floor. Why? What did my gut see? And what was it trying to tell me? Why didn't I listen? So I did what every developer does. I went to Google. I discovered Gavin DeBekker's book, The Gift of Fear. The book delves into dozens of stories about violence and the precursors to violence. With the hopes that we can begin to recognize the warning signs and avoid harm. DeBekker opens his book with an incredibly gripping story. A woman named Kelly had gone grocery shopping. She arrived to the front door of her building. It was unlocked. She was frustrated at the neighbors who consistently left the door to the building unlocked. But also a little relieved that it would be easier to get in with those groceries. As she headed up the stairs to the fourth floor, one of the bags broke. And her groceries tumbled down the stairs. As this was happening she heard a voice from the floor below. Got it.  DeBekker goes on to say that from that moment Kelly didn't like that voice. She knew instinctually something was wrong. The man who walked up the stairs had a very friendly face. He handed her the item and went to take her bag. But niceness isn't kindness. Kelly didn't let go of the bag. And for this moment they both held on to the handle. It was a moment of tension and decision. The man had pushed himself into Kelly's space and she had to choose in that moment whether she would trust him or ask him to let go. Kelly went against that internal guiding voice she let go. The man took the bag up to her apartment, stopped at the door, turned to her and said, or she turned to him and said, thank you, I've got it from here. It was the second time she had asserted herself. She made herself clear. And a kind person would have walked away. But this man wasn't kind. He insisted. He'd help her take it inside. Everything in Kelly said no. But then she convinced herself he was nice. He was just trying to help. It was probably fine. She let him in. He held her at gunpoint and he raped her. After he got up, got dressed, shut the window in her bedroom, said he was going to the kitchen to get a drink of water and that she should stay right where she was. She didn't. She knew in her gut he intended to kill her. And this time she listened. She got up off the bed and walked as his shadow down the hall right behind him. When DeBecca tells this story he says that the man could have felt her breath if she'd been breathing. She went out her front door across the hall, opened the unlocked door of her neighbor, walked inside, locked the door and told them to be quiet. We know now that that one incredibly brave decision saved her life.  We think about it on a weekly if not daily basis. But it's not just women who have intuition. In 2006, Army Reserve Staff Sergeant Martin K. Richburg was in Iraq and he was talking to his wife on the phone outside an internet cafe. A man approached with a blue bag and Richburg had a bad feeling. Something didn't seem quite right. His suspicion led him to watch the man closely. The man set the bag on the cafe's air conditioner and quickly walked away. Richburg alerted to the danger chased after the man and found out that an IED was located in that bag. The building was evacuated before the bomb detonated and his quick action saved the lives of 12 soldiers and five Iraqi civilians. Military field reports cite a sixth sense or what they like to call a spidey sense so frequently that the office of naval research has put nearly four million dollars toward research on intuition. That's the military, a group of people who aren't exactly known for being in touch with their feelings. The Department of Defense calls this sense making and defines it as a motivated continuous effort to understand connections which can be among people, places and events in order to anticipate their trajectories and act effectively. Which is military speak for listening to your guts. Not a lot of writers end up at West Point apparently. Fear is not a gut feeling. Fear is your brain delivering critical information delivered from countless cues that have added up to one conclusion. Stop, get out, run. But sometimes fear isn't life or death. Most of us, thank God, don't experience threats to our safety in our everyday lives. Instead we experience a more subtle, less threatening form of fear. Sometimes our gut feelings are as simple as code smell or that shiver of hesitation before a deploy. I'm Emily Freeman. I'm a developer advocate for Kickbox.  I'm thrilled to be here with you all at RailsConf. It's my first RailsConf, so very excited. Great conference. This talk is going to explore fear, instinct and denial. We'll focus on our two brains, what Daniel Kahneman calls system one and system two. And we'll look at how we can start to view our feelings as pre-incident indicators. There are endless dark alleys in our code bases. I think we all have that one feature that really shouldn't work the way that it's built, but it does. And you don't want to touch it. And you're pretty sure that it's going to explode everything at some point, but you're just kind of hoping that you won't work where you do when it happens. I'm lucky enough to have never experienced anything like Kelly and I've never served in our military. But I think most of us drive, right? So imagine you're in your car driving down the highway. There's light traffic, but you're moving along at a pretty good clip.   Now, you've got no real cognitive reason to take your foot off the gas. They haven't signaled or swerved, but then they do what your gut said they would do. They move over into your lane. If anyone here rides motorcycles, you know it's even more intense. You develop the sixth sense for other drivers. So what's happening here? Well, I have some bad news. You're not actually clairvoyant. That would be cool. I don't recommend you quit your probably lucrative day job. Change your name to Ms. Cleo and open the stand up at the mall.  Take a thousand inputs and distill it into one conclusion within seconds.  Maybe the driver checked the mirror. Maybe the car moved ever so slightly over in the lane. The signals are much less important than the result and your discernment of the basic instinct of fear. Because fear is one of the reasons humans have survived as a species. Fear has kept us alive and it's an incredibly useful and powerful gift, a skill honed by thousands of years of evolution. This feature of fear comes out of the box for us. We have it, all of us built in and we don't need special training to experience its effects. But you can become an expert in your own intuition by purposefully training yourself to recognize the warning signs and precursors to danger, even the risks lurking in our code bases. Now I want to take a minute to distinguish anxiety and worry from true fear. I suffer from anxiety and I'm sure many of us in this room deal with some kind of anxiety or depression. Even those of us who don't experience occasional worry. The difference between fear and anxiety is rather subtle, sometimes indistinguishable. Both feelings elicit the same physiological response.  Your body begins to preserve fluids and controls the release of saliva, tears, and gastric acid. It creates cortisol, which actually assists your blood in clotting, and noradrenaline is released to strengthen your skeletal muscles. Your body literally prepares to experience harm.  The difference is time. Fear is a response to an immediate threat. Anxiety is rooted in anticipation. And that's the key to discerning fear from anxiety, time. Fear will hit you like a ton of bricks. Worry brews and ruminates. Psychologist Daniel Kahneman was awarded the Nobel Prize in Economics in 2002 and the Presidential Medal of Freedom in 2013. He was a man who intimately knew fear. Kahneman's parents were Lithuanian Jews who had immigrated to France in the 20s. His father, believing that Jews were safe in France, chose not to flee to Tel Aviv, then in Palestine. Kahneman prayed daily to live just one more day as his family hid in the woods during this time. His father died of untreated diabetes just six weeks before D-Day. His research partner was Amos Tversky. Nearly everyone who interacted with Tversky talks about him as the smartest person they had ever met. And he had an incredibly sharp humor. While leading a group in the Israeli Army, he dealt with men who didn't want to wear their helmets. They felt that if a bullet had their name on it, it was God's will. He remarked, what about all the bullets that say to whom it may concern? In thinking fast and slow, Daniel Kahneman describes the work he and Tversky conducted over their careers, researching judgment and decision making. It's brilliant. I highly recommend it, though at times it's a little bit dry. So if your brain's like mine, I mean the audio version will help you work through the particularly thick statistical bits. Kahneman and Tversky became extremely interested in the cognitive biases and heuristics that humans use to make decisions. Heuristics are shortcuts that your brain uses to make complex problems much more simple.  It's a speed accuracy tradeoff. Cognitive biases are assumptions our mind makes based on existing patterns. For example, the availability heuristic makes all of us more likely to believe that we may die in a plane because we're sucked out of the window because the engine blew, especially if we're flying southwest this week. Then in a car on the way to the airport. But we know statistically that air travel is the absolute safest way to get from one place to another. Over their decades of research, Kahneman and Tversky theorized the human brain has two styles of thinking, what they call system one and system two. System one is quick, instinctual, and driven by emotions. I like to think of this as our mean girl brain. The 13-year-old hormonal monster that lives inside all of us. On the other hand, system two is highly logical and quite deliberate. I'll refer to this as our nerd brain. Now, most of us in this room are engineers and if you're not, you probably work fairly closely with us, so you know the type. We, I think, like to think we're always running on our nerd brain, right? Because we measure ourselves on intelligence. We're smart, rational, data-driven. We're not. Bad news. We are driven by emotions. We make snap judgments all day long. Humans, all of us, default to system one, your mean girl brain. I know. It's pretty hard to hear. I'll give you a minute to mourn. Listen, system two is expensive. So it's most efficient to run on system one most of the time. It's unconscious and processes information quickly. All right, this is audience participation time. The Ruby community is fantastic, so just shout out the answers. Don't be shy. Which line is longer? Light blue, dark blue. Good job. Two plus two is? I see what you did there. And complete the phrase war and good job. Congratulations. You've accessed your system one. It's pretty easy. So if we run on our mean girl brain most of the time, what's the nerd's job? Well, system two is conscious and effortful. So let's really exercise our brains. What's 24 times 19? Significantly harder than two plus two, right? Funny story when I was giving this to my boss as practice. He had done it on the calculator and he just blurted it out and like, I know what you did.  It's actually 660,000, that's apparently. Which chemical element has the shortest name? No, tin. Not as easy, huh? We're just like a white word away from a full on technical interview there.  It takes much more energy to think with system two than it does with system one because it's rather lazy. But what if you could use both to its advantage? Remember Staff Sergeant Richberg? System one alerted him that something was wrong and that curiosity that innate suspicion triggered his system two. Your lazy emotional system one is an alerting system. This cat would probably not be a very good watch cat. And the buttoned up rational system two is the investigator. Now, you're never going to be able to fully trust your system one. It is rife with bias. System one runs purely on existing patterns. Snakes are bad. Homeless people are dangerous. Hackers live in their mother's basements.  I mean, a few will and RailsConf wants to make it very clear that we do not endorse you picking a brand of snakes. Most homeless people are absolutely harmless and less than 50% of hackers live in their mother's basements. Probably. While you can't trust the conclusions your system one makes, you can trust its ability to trigger your system two. And system two is what delves into the details. Forms hypotheses and creates algorithms. Michael Lewis, the author of Money Ball, became interested in the Oakland E's impressive performance against teams with triple, sometimes quadruple their budget. You think that the team with the highest player salaries would get the best players and be the most successful in the league, right? That would be an efficient market. And economists, like developers, love efficiency. Only it didn't work out like that. The major league baseball at that time, it wasn't efficient at all. The Oakland E's held their own against teams, even the most wealthy teams in the league, like the Yankees. His interest peaked Louis Duggan, or you could say his system two Duggan. Like most sports ball, baseball players are picked by scouts. And scouts, like all humans, run on their mean girl brain. They fall victim to the biases we all do. For example, a handsome player with an athletic build will most likely be overvalued because he just looks the part. Due to their budget limitations, Oakland realized they had to find players that were undervalued. So they turned everything upside down. They approached player selection with an entirely new perspective. These scouts for the Oakland E's looked at statistics no one else did. Other scouts leaned heavily on stolen bases and batting average. Oakland looked at on base percentage and slugging percentage to gauge offensive success. They even went so far as to seek out unattractive players, often with some kind of physical oddity. The players on average were a bit fat, actually. Louis likes to say that if you lined them up on the wall, they'd look more like accountants than professional athletes. One player had two club feet. I'm not kidding. They employed a catcher with a busted elbow and a pitcher with this very odd submarine style pitch that's like long and lanky. The scouts used their system one to make those snap decisions. For example, that shortstop runs with a limp. Maybe he belongs in our team of misfits, where then they defaulted to their nerd brain to test those assumptions. They measured every player against the statistical algorithm they produced. Engineering isn't baseball. It's not dangerous. Thank God, if your job is dangerous, like on a daily basis, we should probably talk. How do we make this instinct of fear intelligent? And how do we apply it to our everyday, not-so-dangerous engineering jobs? First, pay attention. When your gut sends you a message, listen. Think of it as a precognitive fire alarm. If you find yourself thinking, it's probably fine. No, it's probably not. And if you find yourself thinking, what are the chances? Hi, the odds are high. Stop equivocating.  So take action. But don't freak, not yet. Action does not mean panic. It doesn't mean alert your CEO.  It simply means acknowledge your curiosity and allow it to transition into suspicion. Now, suspicion has a bad connotation in our society, but it's derived from the Latin suspicier, which simply means to watch. So observe. Look more closely. Finally, trigger your system two. Ask questions. The more detailed and difficult questions, like 24 times 19, will actually trigger your brain to alert system two. And it'll jump into action. Investigate. Get to the root of it. Sometimes your gut feeling is nothing. It's a false alarm. Sometimes it's misdirected. Maybe you went home because you thought your oven was left on, only to discover your phone was left on the kitchen counter. And sometimes you're about to delete dozens of servers and bring down S3 and US East 1 for hours, effectively faulty on the internet. Articulate your feelings to someone else. Talk to a real person, in person, or on video if you happen to be remote. Communicate your concern and ask their opinion. Now, this can be tough to do, right? Our industry isn't known for respecting feelings. We measure each other on our intelligence and our technical precision. But remember, you are an expert. We have technical intuition as engineers. It's a thing that enables senior engineers to debug something and half the time it would take someone with less experience. It's code smell. It's the squint test.  Our brains are fantastic observers. They collect and process unfathomable amounts of data. Your intuition is not a feeling. It's a powerful mechanism derived from thousands of years of evolution and enhanced by your years of experience as an engineer and as a human. We would be wise to trust ourselves and to respect the gut feelings of those around us. Thank you. My name's Emily.


Hi and welcome to the session. I am Asha and I am going to help you with the following question which says is it true that for any six A and B power set of A union power set of B is equal to power set of A union B justify your answer. First let us learn what is the power set. This is take a set A where power set of A will be collection of all subsets of A and it is denoted by this sign. So with this idea we will solve the above problem. So this is our key idea. And with the solution we will show that power set of A union power set of B is not equal to power set of A union B. And to show this let us take one contrary example where A is a set having elements 1 and 2 and B is a set having elements 2 and 4. And power set of A which is the collection of all the subsets of A will have elements 1 set having element 2 set having elements 1, 2 and an empty set. This is power set of A. Now let us write down what is power set of A union power set of B. So this will have all those elements which are either in power set of A or power set of B or in both. These elements are set having elements 1, other set having elements 2 and 4, set having elements 1, 2, set having elements 2 and 4 and 5. Now let us find out what is A union B. Then we will find the power set of A union B. Now A union B will have elements which are either in A or in B or in both. So these elements are 1, 2 and 4. And now let us write down power set of A union B which will be having the elements as follows. Element 2, 4 like this. Now let us compare power set of A union B and power set of A union power set of B. On comparing these two we find that set having elements 1, 2 and 4 is in power set of A union B but not in the power set of A union power set of B. Element 1, 2 and 4 does not belong to power set of A union power set of B but set having elements 1, 2 and 4 belongs to power set of A union B and thus we say that power set of A union power set of B is not equal to power set of A union B. Hence justify it. So this completes the solution. Hope you enjoyed it. Take care and bye for now.


Welcome to this presentation. This is about Hades, which is a generalization of substitution permutation networks. And this is joint work together with Lorenzo, Reinhardt, Christian and Dragosh. And my name is Markus. So let me first give you a very short overview where we currently are at. So we have many general purpose ciphers and they are used for many use cases. For instance, for pure encryption, AES, we like to use AES and this is perfectly fine. However, recently there appeared many new use cases. For instance, MPC or Starks or FHE. And these use cases benefit from certain properties. For instance, the multiplication count may be important, but also the multiplication depth. And also, this is another difference, they tend to work directly over large prime fields. And if I say large, then I mean prime numbers in a range of 2 to the 128, for example. So this leads us to the fact that existing primitives, like the AES for instance, are not very well suited for many of these new use cases. And the idea is there to design something which is good in these scenarios. However, let me say that this idea is in general not extremely new. So for instance, there is this low MC cipher from 2015 and this construction is actually already designed to minimize the number of multiplications. However, the multiplications in F2, which is a lot smaller than the large prime fields I've talked about before. And another problem of low MC and of PSPN ciphers in general, I will then talk about PSPN and what this actually is. So another problem of these networks is that they are not very easy to analyze from a security point of view. And hence the question remains, can we build something which is much easier to analyze, at least against sum attacks, and which is also so what we can also use to optimize the number of multiplications or also other metrics, for example. Okay, so what is a partial SPN? And I will now begin with the classical substitution permutation network, which is shown on the left side. So for example, shark from 1996 is a classical substitution permutation network. And what this means is that in the nonlinear layer, the S boxes are applied to the whole state. And then there's the fine layer, and then there is again a nonlinear layer and so on. And this is done for a couple of rounds. But the main property here or the main difference to the other constructions then is that the S boxes are applied to the whole state. And if we go one step further, we can see this partial substitution permutation network, for example, Zorro from 2013 or this Loeumsee from 2015. And the main difference here is that the S boxes are only applied to part of the state in the nonlinear layer. And the rest of the state remains unchanged. So this is an identity function for the rest of the state. But of course, the fine layers are still applied to the whole state. And if we go another step further, we have a mix between these two. And this is the Hader strategy, which I will talk about in this presentation. And basically, the idea is to mix the classical SPN with the partial SPN. So we have full nonlinear layers, so to say, at the beginning and at the end of the construction. But in the middle, we have these partial rounds where basically only a single S box is applied in each round. So this is the idea of Haders. But why are we actually doing this? So we already talked about that partial SPNs, like Loeumsee, for instance, are more difficult to analyze from a statistical point of view. And if we don't have the tools, this may also be true for FISC networks. So what we would like to do instead is to use very well-known techniques. And one such possibility is to use the white trail strategy. This was originally used for the AES. And the idea of this approach is to basically use a certain construction and together with a certain matrix in order to guarantee security against differential and linear attacks, which are two kinds of statistically attacks. And we use exactly this strategy to protect Haders against some statistically differential linear attacks. However, the problem is that due to this approach, we need full nonlinear layers. So we need S boxes being applied to the full state. And this is rather expensive in our setting. We'll talk about this also later. So what? The expensive part. Okay, so let me now, after this short introduction, talk about the Haders design strategy. And I will first talk about these full rounds, so where the S boxes are applied to the whole state in the nonlinear layer. And we'll then talk about the partial rounds where only one S box or limited number of S boxes is applied in the nonlinear layer. And finally, we then combine these two things and show the resulting construction. Okay, so first about the full nonlinear layer. This is used against some statistically attacks, so namely against differential and linear attacks, however, we also we also conjecture security against other, other statistically attacks. And in order to do it, we need a specific matrix. And this now brings me to this expensive part in our setting. And then we also talk about this later. So in our setting is NPC setting, we try to minimize the number of nonconstant multiplications because they are quite expensive. However, multiplications with fixed constants tend to be way cheaper in our setting. And so we have, we can basically choose an expensive matrix, so to say. And what we do is, we indeed choose the best matrix from a statistical point of view. And this is the MDS matrix. This has also a very large branch number. So we can basically minimize the number of full rounds we need in order to get security against these classes of statistically attacks. And this is exactly what we use the full rounds for. Of course, also for the algebraic attacks, but this is their main reason, so to say, especially when compared to partial SPNs where we use no full rounds. Okay, so this was about the full rounds, the full nonlinear layer. What about the partial nonlinear layer? So differential linear attacks are solved by these full rounds. And we also conjecture security against other statistical attacks. However, algebraic attacks still remain an issue here. And the bad thing about these new use cases, such as the NPC use case, is that they tend to benefit from a very simple algebraic structure. And this makes algebraic or may make algebraic attacks much more powerful. So we have to focus on that during our analysis. And what we can observe here is that the degree is very likely to increase in the same way during the full rounds and also during the partial rounds. So what we do is we mainly use the partial rounds to get security against algebraic attacks. Of course, high degree is not the only thing we need. We also need the polynomial to be dense, but this is done in more analysis in the paper. But the partial rounds basically can be added many, many times because they only contain one S-box. So that's not so expensive in our setting. However, we still may need many, many partial rounds. However, there are optimizations if this is the case. Okay, so now we have talked about the full rounds and about the partial rounds. Now we combine these two things and we arrive at the construction, which is shown at the right side here. We have a symmetric construction. So we have the same number of full rounds at the beginning and at the end. And in the middle, we have these RP rounds, which are the partial rounds. So given then some state size, for instance, we can also modify or change the number of full rounds and the number of partial rounds in order to optimize the construction for different metrics. And in the following presentation, we will denote the S-box size by this small n in bits, which will be 128 in most cases. And the number of S-boxes in the full rounds or the number of cells, if we are talking about the substitution implementation network, is denoted by t. And if we have many partial rounds, which may be the case, and if I say many, there may be, for instance, 80 partial rounds for certain instantiations, then we can make use of recent optimizations. And if we do that, this is actually much cheaper than using just the plain construction. And more details can be found in this paper from 2019. So the problem is here, the nice thing, but also the problem is that we can change many things about the design. So for instance, we can change the S-box size and we can also change the number of cells almost freely. So this is good, but it means that cryptanalysis gets harder. So we have to focus on some instantiations. And what we did is that we focused on prime fields only. And this is also important for a later part of the presentation. So we only define this construction or paper over prime fields. Okay, so now let me talk about this concrete instantiation of our construction and also about very briefly about cryptanalysis. So what is this concrete instantiation? We use a prime field where prime number is approximately to the 128, so 128 bits large. We use one single S-box in the partial rounds and the S-box is f of x equals to x cubed. So basically the cube S-box. And for the matrix and the linear rounds, we use a Cauchy matrix with a very specific starting sequence. And more details are found in the paper. And I will also talk about this towards the end of the presentation because this also may make a difference regarding the final security. So if you see the S-box, the cube S-box, then you probably immediately see that the inverse is quite expensive, especially if we increase P. But for our setting, we only need the encryption direction. So for this NPC setting, so this is actually not a problem here. Okay, cryptanalysis, very briefly, we have two security levels we focused on. We have the state size security, which means that basically for a 1000-bit state, we want to have 1000 bits of security. And we have the S-box size security, which means that if we use a 128-bit S-box, we want to have a security of approximately 128 bits. So we focus only on this security level, which should be equal to the S-box size. And in our setting and in our instantiations later, the key size is approximately 128 bits always. So we want to have a security of 128 bits and not a full state security here. Okay, so very shortly about statistical attacks, we use the white trail strategy and an MDS matrix for security against differential linear attacks. And you also, based on these results, you also estimate the complexity of other statistical attacks. But what about algebraic attacks? So there are many different kinds. There's, for instance, interpolation attacks or group databases attacks, and various strategies. So we also estimate the security of the construction against these types of attacks. And, yeah, and more details are then also found in the paper, of course, much more details. Okay, but let me now come to the use case, the actual use case of haters or of this construction haters mimsy, which is the NPC use case. Now let me first talk about the use case itself before I talk about the construction we use. So this is a very large application area. And the security, the setting is a secret sharing based NPC system. So data is shared as elements of this very large prime field. And we transfer the data by evaluating block cipher calls on this data. So traditional algorithms like the AS are not very efficient. So we use this new constructions instead. And we want to avoid having many cipher text for stored shares. So we do basically a single block cipher evaluation for multiple shares. And that's also the reason for which we have, for instance, an S box size of S box size of 128 bits, and then multiple S boxes. So we increase the number of cells basically, and these are the the different shares then. And if we arrive, or if we come to such a construction, we then, of course, we also want to compare it with similar constructions, such as the older mimsy or the very recent rescue or so. Okay, so first about the cost metric, I've also hinted, I've already hinted about before. So linear defined functions are almost free. So for instance, additions, however, nonlinear functions, so multiplications with non constant multiplications, they are very expensive. So and yeah, about these multiplications, they're actually required. They require communication between the parties in this NPC setting. So the total number of multiplications of the resulting construction of haters is a good estimate for the final complexity. And this is what we use then, to basically determine the right number of RF rounds and RP rounds. The additions are free in this setting, but they can still influence the cost. So for instance, if there are many, many additions, they have an impact on the computational cost, of course. Okay, so what we want to have as a conclusion is we want to have a small number of multiplications, this is very crucial to reduce the overhead. The depth may also be important, but it's about the number of multiplications here. And we can have different tradeoffs and different round numbers. And about these round numbers, let me just give you a few examples. So for instance, if we have a text or state size of 512 bits, and the S-box size security, so 128 bits, then you can see here we use six full rounds basically and 71 partial rounds. If we increase the security or the state size, sorry, to approximately 4000 bits, then in the S-box size security level, we have, for instance, six full rounds and 71 partial rounds. And now you maybe know why I've talked about these optimizations for the partial rounds because 71 is quite significant. And here it becomes very important to use these optimizations. Also, of course, for these numbers here. So after having shown you maybe some instances, we can have a look at some benchmarks of Haters-Mimsi and other site for the constructions in this MPC setting. And let me first say that all tests are done over a local area network for various cell numbers here 2432. More examples can then be found and the larger table can be found in the paper, of course. The total size or state size is 128 times T. And we use this Mimsi construction in a counter mode. And let me also say here or emphasize that the security of rescue is actually larger because it's a state size security level, not an S-box size security level. Okay, but if we have a look here, for instance, for T equals to two, we can see that Haters-Mimsi is quite good when it comes to throughput and also to communication per element. We can see that this also holds for T equals to four and for T equals to 32. It's not the best in the latency section. So Mimsi is better here and rescue is better here. However, here for 32, so for very for a high number of cells, it's also better in the latency. But again, the performance of rescue may be better actually, especially regarding the throughput here. If we consider an S-box size security level, but we couldn't find the numbers for these. So we use the state size security level. Okay, let me briefly also talk about open problems and future work. So there are of course, more use cases which can benefit from this Haters strategy. This for instance, two, there's the Stark use case and there are two constructions of permutation Starkat Pi and Poseidon Pi. And they're used for the hash functions Starkat and Poseidon, which are shown in this paper from 2019. And they also use this Haters strategy with full rounds at the beginning at the end, and partial rounds in the middle. Of course, for future work, more cryptanalysis would be better, specifically, maybe to improve the understanding of higher already French attacks over FP, then to improve the understanding also of the difference of the cryptanalytic difference cryptanalytic difference, sorry, between the full rounds and the partial rounds. So this may be very important also. And if we have a better understanding, maybe even better tradeoffs are possible. And another thing which has to be considered here is the properties basically of the linear layer. And I will now shortly talk about these because there have been some results since the submission of this paper. So as properties of the linear layer, let us recall first that the linear layer of this Haters construction, we use the multiplication with an MDS matrix. And for this MDS matrix, we use a very specific generation sequence, namely it's a Cauchy matrix with a very specific starting sequence. And if we do this over F2 to the end, so our binary fields, then there are some problems. So for instance, if T, so the number of cells is a power of two, then the square of the matrix use is a multiple of the identity matrix. And what this means is that there exists some subspace here that is invariant for the partial rounds, which means that no as using this fact, no S boxes are active in the partial rounds over an arbitrary number of partial rounds actually. So this is a major problem, but it works for binary fields and it does not work for prime fields here. So Haters Mimsi or construction is actually not affected by this. So at least we don't know a way here. More details about this are given in these two very recent papers. And one possible solution is for instance, to change the generation sequence of the Cauchy matrix. But we emphasize again that this works over prime prime fields here, not over binary fields. Sorry, it works over binary fields, not over prime fields. However, there are new results also for arbitrary matrices. So not only for Cauchy matrices, and they also they also hold for prime fields, but still we don't know a way to to exploit these results to attack Haters Mimsi. And yeah, these new results can be found in in this paper here. So thank you very much.


Hi, Dr. Jared and today's Friday flop is this tooth number 19 patient came in for conference of evaluation and pain and With deep carousal lesion on 19 we diagnosed it with reversible pulpitus And it turned out that the patient didn't come back for a year later and I'm sure it's happened at your office, but The flop is the patient not coming back, but luckily for me. I went ahead and placed a temporary restoration Restoration we have a self cure HV is what I like to place and here you can see a year later Just placing the temporary got the patient out of pain That's why they've been come back and also the pulp responded. Well, we're able to go ahead and restore this with the direct restoration here at my office and we do this all the time with kids waiting to go to sedation and We do this all the time with silver diamond fluoride and river aqua and the smart technique and it works really well to stabilize your patient So hope this is helpful and I hope you have a great weekend


Welcome, my name is Shannon Kemp and I am the Executive Editor of DataVersity. We would like to thank you for joining today's DataVersity webinar, Hot Topics and Graph Databases. Due to a large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A section in the bottom right-hand corner of your screen. Or if you would like to tweet, we encourage you to share highlights or questions by Twitter using hashtag DataVersity. Next, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Today is an elite panel of specializing in Graph Databases, Leon Guzendas, founder of Objectivity and Infinite Graph, Emile Efrem, CEO of Neo Technology and Neo4j, and Andrea Lopez, Senior Director of Spatial and Graph Technologies from Oracle. This is a theme panel as DataVersity's partner in the NoSQL Now conference in Expo, Dan McCrary. Dan is an enterprise data architect and author specializing in emerging database technologies. He has worked at BABS with Steve Jobs at Nex Computers, as well as founding his own consulting firm for over 75 people. His background includes topics such as high-performance computing, programming languages, databases, and XML standards. He has published articles on the Semantic Web, metadata registries, U.S. federal XML standards, X-Forms, X-Query, and XRX. He is the author of the book Making Sense of NoSQL by Manning Publications. With that, I will give the floor to Dan to start the discussion and introduce our panelists. Well, and welcome. Thank you very much. I'm really excited to be here today. I think we have a great panel and a great topic here. There's something about graph databases that are inherently appealing to me and a lot of the problems that I deal with in information management. And I'd really like to have our speakers start out with a quick introduction of yourself, the company that you're with, and maybe a quick background of what got you into graph databases. Linda, can you give us a start here? Sure. Thanks very much, Dan. Well, I've been in databases practically since the beginning of the technology and was for a very long time a program manager on large projects around the world. I'm first going to go back into the 1970s, dealing with data for NATO and for the Joint Intelligence Headquarters in London working with us. When we found projectivity, we set out to solve problems where there was very high interconnectivity in the data. And that's really been our focus for the last 25 years. We produced the infinite graph about three years ago because the technology was becoming more visible to the community if you like. And that's really the kind of customer base that we've had rather than just being over in the telecom and process control equipment and the intelligence community isn't going right across the board. And I think that's a very encouraging sign. Thank you very much. Any thoughts about yourself? Thank you, Dan. And thank you to DataVersion for hosting this use call it esteemed panel. It's a pleasure to be here. My focus, graph databases, it's been the focus of my professional life. I do not have as long of a professional life as my friend and colleague in the industry, Leon. But I've been at DataVersion for around 13 years. Back in 2000, I worked at a small enterprise content management start-up here in Sweden. I'm in Sweden right now, normally based in the Bay Area. And we ran into a bunch of problems. We had built our stack on the sort of traditional, at the time, stacks. We had a middle layer which was like EES or J2EES. It was called and a web front end and whatnot. And then of course, in the data layer, we had relational databases. And we worked with the usual culprits. We worked with Informix and DB2 and work and whatnot. And I had 20 engineers. I was the CTO of this small start-up. And half of my guys spent the majority of their time just fighting with the relational database. And I, for the world, couldn't figure out why. So I didn't think that we did anything too complex on the data side. It turned out that when I started double-clicking on that, that we actually did. It turns out that we had a lot of connect data, big file system trees, as well as lots of big user hierarchies and security models and things like that. And that turned out to be really, really hairy to model in a relational database. Once you got through that point, when you were able to model it, it performed really, really poorly. And so we Googled a lot of things. We added this around or Yahoo'd around. It was early 2000s, right? For a database that could natively speak, connect the data or graphs as we later on learned. And it couldn't find anything. And this is at a point in life when I was young enough and naive enough that when I got a good technical idea, I said, screw it, let's build it.  All things being equal, you don't want to build your own database. But we didn't know that at the time. And we really needed something like this. So we came out and we built it. And on a flight to Bombay in 2000, I sketched out the initial model. Actually on a napkin, stereotypically enough. The model that is now called the property graph model. We implemented that and wrote a couple of prototypes and what we then put in production in 2003 is what is today called Neo4j. Which is a graph database that implements the property graph model. And we formed a company around it in, I believe, 07. Which is the commercial sponsor. But the software in office completely opens doors. Neo4j.org. So that's me in a nutshell. Thank you very much, Emil. Right here. Tell us about yourself. What drove you into this wonderful world of graph technologies? Well, everybody, I've been with Oracle for about 15 years. And so that whole time I've been involved in spatial technologies, dealing with more with mapping digital and geospatial stuff. So I've been focusing on managing geospatial data in the database. But one type of geospatial is graphs or networks. So they're commonly referred to as a net space. And so managing networks for roads, electrical networks. And then not only just managing these large networks, but it might represent, say, all the roads of Western Europe and North America, managing them scalably. But also doing performing analysis, path analysis on that. And so we introduced the first graph database for that kind of networks in the Oracle database years ago on that. And then after the semantic web technologies came up and social media started to emerge. And so we did the same thing for that. Essentially managed triples of the, essentially, the W3C's RDS graph model, which is in the form of triples. So essentially extended the Oracle database to manage RDS triples and then be able to perform inferencing in the database. So basically addressing the problem or the problem was basically extending standard relational technology to have graphs more natively on that. But more recently, I've been involved in essentially doing the same thing for providing graphs capability to Oracle's NoSQL database or have that NoSQL database in addition to relational databases. And so our task, or at least our team's task, is not only to make sure that spatial content and co-processing is native to our database families, but also to for graphs as well. So that's where I come from, really straddled both sides on the spatial one graph. Great, that's a good overview. I forgot to mention at the beginning that we usually go about 40, 45 minutes with a discussion. Then we open it up to questions from everybody. So I just want to remind everybody that you can use the WebEx software and there's a special panel for questions. So feel free to, as we're discussing these things, add your questions to that. And if we cover them in the discussion we're starting here, we'll try to get back to them towards the end. I have a couple of questions I'd like each of you guys to answer. I'm just incredibly surprised at the continuing growing interest in graph databases. When we first started this conference, we thought that graphs were going to be kind of a side thing and it wasn't going to be front and center. But in this conference we seem to have more graphs of vendors and more interest in graphs than a lot of the other types of NoSQL data stores. So, Leigh-Anne, when you start this out, tell us why you think graphs are becoming so popular now. They've also been popular in the background, but it's been a quiet movement if you like. And I think over in the social networking world there's really a lot of things to look for. And I give credit here to me and the open community for coming in on this problem as well and starting to do more and more work in this area. So, the theory course has been around for 300 years, but more and more people aren't getting interested in it. And the general movement in general has helped that as well. So, the blinkers come off and people aren't looking for a single solution anymore. They're prepared to look at different kind of database for different parts of the problem. Yes, I totally agree. I think that technical movement has almost given people our permission to look outside just the narrow field of relational and analytical databases. So, that really makes sense from what we're seeing. Do you have any thoughts on this topic of why we're seeing so much interest in the last couple of years? Well, I think you mentioned a couple of things. There's the broad industry trend of looking beyond the relational database. People have called it NoSQL, not only SQL, or they've probably polyglot persistence and lots of different names. None of the names really is a great name, but particularly the concept, of course, is that we're part of the point where you can just block and take your dataset and just assume that it will always work great as a relational database, which has been actually true for the amount of, at least, you know, part of the time that I've observed the industry. You know, back in the 90s, when I grew up as a professional programmer, the choice was not really what type of database are you using or what data model does your database have. The choice was a vendor choice, right? Should I go with, you know, Microsoft SQL Server later on, right, but initially Oracle or database or, you know, DB2, it was a vendor choice, it was a vendor choice of the type of database. And the nature of information has changed since then, right?  So that's one aspect. But also the fact that data is becoming increasingly connected, or at least that people are seeing more and more places where they can unlock a lot of value by looking at how data is connected. And that's just a really, really poor fit with the relational model because it inevitably leads to a bunch of joins. And that's just not performing well and doesn't have a very convenient program model. So these three things really connect, I think is the main reason why that is happening right now. Yeah, I agree. That's a very interesting insight that the more data we have, the more connected we potentially have and having a tool that we can connect heterogeneous databases that weren't designed to work with each other, that technology has become more important. David, do you have any perspectives that you'd like to add on this? The point is critical within enterprises, and that's why our customers move toward the graph feature is essentially to treat, typically create an enterprise standard, standards-based meta-graph model. It has to be a graph form. I'm referring to the RDF graph model. It has a standard for the model, the definition of the model. It has a standard for the query. But most importantly, it's flowing from the get-go by a W3C to essentially program this linked layer to manage the integration of relational databases, the system-relational databases, content management stores, big data stores, streaming data and so forth. And that's the challenge of today, is essentially how do you integrate all of these different data types as some folks refer to it as big data. But then the integration problem is huge. It was a big challenge when you just had really big databases integrating the scheme as you had all these semantic issues and doing that. But RDF, a graph model in particular, is ideally suited for this integration capability. So that integration problem has grown as different data types coming in, but also because different application developers don't want to be coding to the underlying data models. So they'd rather be coding to a semantic layer that more evenly reflects their dynamic of the vocabularies. And so this graph model provides that semantic layer that makes that possible. Okay. Let me change the order up a little bit. I'm going to all reverse it here and ask Xavier the first to respond to this next question here. What kind of vertical industries are you seeing that are the earliest adopters of graph databases? We obviously know the social networking space is using graph databases quite a bit. Are there other vertical industries that you're seeing or are picking this up before others? Before we get into that, I think it's important, and we may not have the time to get into it in this call, but unfortunately, there are different graph data models. And they're essentially designed, or they have sweet spots to address certain different problems, whether it's a debugging problem or an analytical problem. And so that's important to understand is that the different graph models are there. And which model is best suited to the form of an application to address that area. So for example, in the telecommunication space and transportation space, there's a network graph model. And it's essentially a node model. You can apply constraints to the links of the nodes and influence the path calculations. So if you use Google Maps, Google Earth, or Google Maps to do driving directions, name your favorite routing application, it's a built-in graph model. And it's essentially designed for very fast path calculations, one to many, traveling salesmen, all these different types of network calculations that have been around as Leon says for a few years. So those algorithms now exist on these models. There's the W3C already a graph model, which is essentially designed for integration to integrate different schemas and layers. And this is used a lot by businesses that are trying to integrate different, either distributed or federated resources to create these outputs known as logical data warehouse where you have the representations in the form of schema and resources on that. And then the third category, as Leon was referring to, is this property graph model as well to support other ranges of applications. So each of these three, and there's more than that, have a sweet spot that they address, and I think it's important to understand what they're best suited for and then which implementation of them would make the most sense. That makes sense. Next, do you have any comments on vertical industries that are using Neo4j today? I actually have some comments on Saviour's comments as well, but let me quickly read in with the answer to your question first, Dan. So we have a lot of people who are actually horizontally across the field in terms of verticals. There's a bunch of verticals where people are experimenting with graph databases, with expanding connected data, let's say. But primary ones where we've seen early adopter traction, where they really have recently moved from experimenting to actually deploying it in production in mission-critical situations is telecom, as was mentioned before. Finance, we have a lot of up-taking finance. We have a lot of interest from healthcare, which surprised me actually because it tends to be usually longer adoption cycles in healthcare. But that has been a very recent, just this year for us. We probably have tens, if not 20, of reduction deployments in healthcare from like three or four second half of last year. So there's a lot of traction in healthcare. And then gaming, gaming is picking up steam really, really rapidly with us. So those, I'd say, would be top ones. But we have a bunch of deployments as well outside of that. I mean, one of the most critical logistics deployments in the world was done in Europe, packaged for routing for a major country in Europe and it was all based on Neo4j. And so we see that kind of action as well outside of the core. But if I could mention a few, those three are the ones. All right. How are you doing? Do you have any specific virtual interviews that you're following and are getting a lot more uptake? Yes. We have a steady background in the intelligence community, telecom networks, cyber security and finance. Over the years it's been very strong. Great news in North America, for instance, to consolidate all the data from their client base overnight and send it back to them. But recently you've seen an upswing in healthcare, logistics, agriculture and retail, tracking seed to consume kind of stuff. And if you look at the trend, have you tried to lump it all together? I guess people are exploring metadata in more powerful ways. That's the trend. They're pulling some data out of existing databases and using our technology to explore the metadata. Interesting. Okay. That's great. I'll just throw it out to any order here if anybody wants to jump in. One of the things I really love about our NoSQL conferences is that people come to the conference with real-world stories of times that they've tried to use in a relational database or maybe the wrong database. And then we assembled the right database and the job just became orders and orders of magnitude easier. And I wanted to invite any of you three to share any recent stories you guys have about case studies of people that were struggling trying to do it with one type of used-to-graph database and made their problems easier. Anybody want to jump in? Thank you, dear. Pharmaceutical company, Lily, may have worked most of the time as a pharmacist in this grass area, but in particular they had this classic data integration problem of new research with the drug discovery research. And they needed to be able to access a variety of internal data types from different systems, but also external systems as well from the government sites, PubMed, content repositories as well. So they had a pretty massive integration challenge and one approach had been in the past to just trying to bring it into one environment, one relational environment, sort of taking a classic warehouse approach. Well, I found that it just wasn't that it couldn't scale. It was just the time they incorporated the data they needed to, the people they were trying to ask were different and that warehouse was designed for certain kinds of queries, but the queries needed to change over time. Secondly, the amount of data that is growing, so the whole space of the industry is growing, so they had to incorporate their knowledge and that very rigid warehouse approach wasn't appropriate for that solution. So they took a heavy metadata approach to it, essentially a graph metadata approach, they already have a graph metadata approach, to align the semantics of the underlying data types to the semantics. You know, they used snowmobiles as an ontologies and industry ontologists used, and then there's other ontologies as well. So they basically aligned the underlying terms of the real-life environment, but also their external resources to this internal enterprise vocabulary. And with that, that's how it got connected, both with the external systems. The model was the model through which new applications could query. So the new applications didn't have to worry about, you know, how is the data model in these underlying systems that are either internal or external, they just code to that metadata layer. So for ease of development and maintenance there, it didn't disrupt their legacy applications on that. So this is pretty much the successful model there. We find most of the life science industry. In addition to the other industries that you mentioned going forward with this metadata approach. Just to summarize, it sounds like the problem was complicated enough, I think of medical and healthcare vocabularies as being, snow med being very complicated. If I had to, you know, come up with dimensions in Kimball data warehouses for that, it would be a huge problem. It would take a long, long time to model those things. So what you're saying is that by not having to construct by an old app cube kind of modeling process, you're still able to get the search and retrieval and discovery features out, but they could be much more agile in our ability to add to it. Is that a good summary? Yes, they would. New data sources would attach to that model, essentially through the mechanism, and that new application is just a query of that model as opposed to the underlying database. We're designed by DVAs, you know, years ago, and the other terms that are used for the columns and so forth may not be very intuitive to the web application developer who's trying to develop a clinical model, for example. Leon, do you want to interject with any case studies that you've come across lately? Go ahead. Do you have a meal? Do you have one? If not, I have a... I have one, but go ahead. Go ahead. Okay, in a brief brief. I mentioned the questions in North America. That actually was a switch from DBT to using our product some years ago. Most recently, as you've announced, they're working on a big program with external funding. They are looking to integrate data from as many places as they can into a very large knowledge base. We're all familiar with the Internet of Things, but this thing will end up with quadrillions of nodes and edges in it. It's going to be a huge project, and they're working with a lot of the national labs and private companies and so on to build that. We started out looking at the problem of the semantic one, and we were federating information across all of these domains into an RDF kind of environment. And then finally, the ontologies were really, really complex, and they needed the graph database just to model the ontologies before the light came on, and they designed themselves a layered model that's going to use infinite graph as the underlying model. Very interesting. Another one, Ian, also? There's a bunch to choose from, and it's a little bit like picking your kid, right? So it's difficult to pick out one in particular, but a recent one that comes to mind is the one that I actually alluded to before, which is a big logistics deployment. This one is actually by one of the top logistics providers in the world, like imagine the UPSS and DHLs, etc., of the world, where they are doing all of the package routing for a core country in Europe. And they realized two years ago that they would not be able to deliver packages in December of 2012, so eight, nine months ago. And as you can imagine, package routing is a very seasonal thing. Around, say, the 23rd of December is the absolute maximum peak in that business, and their software platform would not be able to deliver Christmas presents. And if any of you have, we mentioned kids before, if any of you have kids, that's the definition of mission critical. They're not going to get Christmas presents, right? And the problem was that they used a relational database, so they were unable to create a lateral connection saying that, hey, there's a bunch of packages coming into the city, sending them out to the central hub and then down out to a destination. It turns out that it's faster to just go directly to the destination from this particular package routing station. They could not do that, because their database wouldn't allow them to create that connection. So they, you know, Accenture did the project. That's public. I can't even talk about customer risk, but Accenture did the project. It was one of Accenture's most important projects last year. And Neo4j is at the core for that. And the application is really cool.  And then they deploy it once per day. They deploy the smartest routes. And then as, you know, physically as the packages are thrown down a chute, as they fall, they have a couple of milliseconds, you know, as gravity pulls them down in this chute. They scan the barcode package at the top of the chute, and by the time they get to the end of it, it has gone through Neo4j, calculated the smartest route, and they actually then choose, you know, by the end of the chute, they're going to choose how to actually route it, and which station to deliver it, right? So it's a very mission-critical, you know, sub-millisecond type of application all based on Neo4j, which we think is pretty cool. There's actually a video about it online. They spoke at GraphConnect last year. I hope I'm not blocking any articles here by mentioning another conference. You should all go to NoSQL now. By the way, but they also spoke at GraphConnect, which is a conference completely dedicated to graphs, graph databases, last year, and it was a pretty amazing presentation when during the course of the presentation, he concluded the ExCenture architect concluded by saying, yeah, by the way, during the presentation, Neo4j has routed, you know, 100,000 packages in this country, in Europe. I can post the link later in the chat log. It's well worth watching. That would be fantastic. If people have any links to case studies that you guys feel are relevant, feel free to copy and paste them into our chat log, and we'll try to collect them at the end here. So it sounds like we're getting a lot of interesting stories. I think what I'm surprised at is the diversity of the industries. It seems like there's a common thread to do graph to RISL, but no one industry that's really adopting it a lot. We do have a question just come across here that's really related to the industries, and Ken Smith asked, are you seeing a higher uptake in graph databases where people have high security requirements? You know, when I think of a graph database, I often think of graphs running in a central program, and I don't think of the elaborate role-based access control that you might have on some systems. Ken's question was specifically about the need to get this something called ATO accreditation and authority to operate. Lee and I have some feedback on this because you're very involved in some federal projects. And please feel free to be real close and speak up. Well, one thing I've learned over the years is that you never mess with the security people. If there's no sense of humor, they're right and they're happy. So we actually ship a product with security in it, and that's very deliberate. What we do is that no matter what we put in the way of security, people wanted something else. We wound it up, and we let people use their existing security infrastructure with replaceable modules, we call them, in our own products. And that's everywhere. And in a federated database like ours, that works particularly well across organizations. So, you know, one organization has its own set of rules. They're not necessarily the same as another part of the government even. Even in the government, there's no single standard. And so each organization can impose its own rules on the data which it owns and open itself up to their community as needed. So we're very much in favor of helping it open, letting people plug in what they'd like, and then putting hooks for them to supplement mechanisms such as encrypted objects. And so we have people who build their security infrastructure for all the roles and user structures and so on, organizational structures using the ground databases. Emile and Xavier, do you have any comments on some of the high security requirements that you guys are seeing? Security is one of the reasons people actually have a database, at least in the enterprise. That's one of the expectations is that their data will be secure, and the access of data will be secure. And so being able to have role access is critical for all of our enterprise customers, and so for the role of the data, so for the graph data. And so that's one of the reasons, or the rest of this technology was to make sure that we could apply the same level of label security not only to a person's role, but also the data that they're looking at. So you could have a graph model, but it's a person that's on their Plastic Youth Act that's only considered that those triples are that portion of the graph that's there. And so it's critical for finance, for fraud detection, for oil and gas, for the military intelligence. It's fundamental. And so you can apply label or security at the application level, but talk to the security guys in the IT guys, first thing they'll point out is, well, you can go around the application level into data. So that's fundamental. And it's important to have security, in this case, down to the triple level, or at least node level in the database to ensure as much as possible of the access to the data. Okay, so a little bit of contrasting views there. Leanne likes to have a module of things where people customize by looking at having properties within the triples themselves that manage access is also another approach. Well, yes, just to clarify, of course, we're very, very happy that Oracle takes on that role. If Oracle has a corporate license, cross-site license, they can naturally use that security infrastructure. And of course, we just leverage that so they can hook the data in our database into their security infrastructure. So we're more than happy to let them do that job. Thank you, Emil. Any comments on the security world there? Sure, I have several comments on many things. But I think the angle that I'd like to take here, actually, is a little bit different than Leon and Xavier. We've seen a lot of uptake in people actually modeling permissions with Neo4j. What we call access control and permission resolution. That seems to be really, really popular. It's also related to identity management and entitlements in the financial space. I posted a link to one example of that. It's from a company called Telenoor. If you're a Canadian, you know them. But you might not know them. It's a top 10 telco in the world, the biggest in Scandinavia. The problem they had is that they had really big customers, which generally is not a problem, except that for the really big customers, they wanted to offer them the ability to manage their plans. Let's say that you're in a, let's take a Scandinavian example again, you're IKEA, right? And you have hundreds and thousands of employees and you are a Telenoor customer. I have no idea if this is true, but let's assume this, right?  You want to do that in a central place, right? Telenoor built that application for all of their big, highly valuable customers. They built it based on, of course, not on your employers' employees, but based on the database. In this particular case, they chose PsiBase, which is one of the reasons why it didn't work, because it turns out that this database is actually very graphy. You can imagine that you have people belonging to multiple groups, several devices are connected to one or more plans. They move from one group to another and you want to centrally manage all that. And as you can see in the deck, I posted a link to a slideshow presentation that those guys did. They had response time in the minutes, but when they switched in the FDA, they got response time in milliseconds. So that, I think, is a great example of, maybe actually not what the question was referred to, but a great example of a security application that benefits from a graphy view. Good. So we're at about 20 minutes before the end of our discussion here. And so I wanted to, first of all, throw it out to the very general thing. Do you guys have any questions you'd like to ask each other about different approaches or any other questions that you think are relevant for the discussion here? Well, I do think that and some of you have been on a panel with me before. I try really hard. One of the most boring things I think is panelists that agree with each other. And I think we've seen a lot of that here. So I always try to make an effort to disagree with my fellow panelists. And there are some disagreements here around data model. And we've all alluded to that before. If I understand it correctly, Oracle special and graph is RDF. So for J is property graph oriented. And I think it's correct if I'm wrong, but infinite graph is also property graph oriented. And I think that would be a great discussion topic because I, just to put out my view on that, I think RDF is a fantastic invention. It's very smart. I'm getting an echo here. If you could mute, I get an echo from you. It's very smart. It's built by very smart people. Its final goal is to create the semantic web. And for that, it may be useful. The problem, however, is that it's typically really, really difficult for developers to comprehend. And I've been very deep in semantic web stuff. And I've taught the semantic web stack to a lot of developers, had a week-long course where I tried to teach them to model pretty simple applications. And by the end of that week, typically sometimes they eventually got something up and running. And then I've done the same applications several years later based on the priority graph model where you see the lights turn on in half an hour. There are three simple concepts, nodes, relationships between them and key properties on both nodes and relationships. That's it. And they deliver the same kind of application in half a day instead. So that's my view on why I think the property graph model is going to be the dominant graph database model. And if you look at adoption today, I'd say probably 95% of the graph database use cases out there are property graph models for that reason. So that's my view. And I'm trying to be a little bit contrarian here. And I think your Xavier won't agree with me that I would love to hear your view and as well as Leon's view. Yeah, I would disagree. So the point is that it's a very simplistic model. The property graph model is useful. Its simplicity is useful and valuable. There are other use cases where you're going to model the road of network efficiently of weather in Europe and use it for random. There are better graph models for doing that and they've been doing that for years. The other thing that you keep in mind is that there's tooling, there's third-party tooling that works on those kinds of network models. So you're not going to reinvent the visualization and algorithms or say logistics on a new model. You're basically building up the application from the ground up. Our take is there's existing type of application applications that are out there and that network model for running and transportation is not going to be replaced by either the RDF model or the property graph model. The RDF model also has the capabilities. It's a little bit more complex, but it is designed more for a knowledge basis. So it has other features that a property graph would not have. For example, you're not conferencing. You're not being able to reason. But that's a very key reason why customers adopt that model. It's that reasoning capability that you can have in a very scalable way that you can't do with a straight forward property graph model. So that's where I was referring to earlier. I don't think there's any one graph model that's going to approach. We each have their sweet spot including the property graph one and it's important for customers to realize that they're there. But not just that. There's other fundamental infrastructure issues that security came up. It doesn't matter how good your graph model or your application is going to be. If it's managed securely in an environment, the other guys and the security guys are just going to throw it right out. The next thing is manageability. Do you have manageability tools like recovery? Do you have third-party tools? Are there standards for querying this graph model or do you build up your applications from scratch?  Essentially, you can have your system in it to do it and they love these kinds of models because they're not standardized. They can build the whole thing up and then they can send their kids to school and college just by maintaining that. So I think it's actually to align with standards and try and move forward with standards. I think the proper graph model is still a little immature. It's growing. It's a meaningful one, but I do think there needs to be a little bit more organization in front so there can be an evolution of third-party tooling and maturing of that model. And I'm interested in the maturing of the property graph model because there is value to complement the other types of graph model that exists. Okay. Very insightful feedback for both of you guys. Any feedback on property graphs versus other graph models? Yes, of course. I agree and disagree with my fellow panelists here. But I'm not as worried about the model. The reason being we have a very strong store in which we can deal with linking things in multiple ways. And so we have people using RDF. We have people adopting something like a property graph model. And we have people who stick with pure schema to get extreme performance in very specific algorithms. So I've seen much more bothered, as Emil knows, about getting a standard graph query language for the industry. I think it's holding us back. I don't mind that we've been at small as a start, but it's not great. We all know this issue is great with RDF. It's not good for hypergraphs. Maybe we should listen to the community and look at cipher and start from there and extend it. But I'm much more worried about the query language than I am about the model, because I think we should be flexible in that respect. Just take that comment before we're just going to have a couple more questions open it up. I think the question about standards is very critical. I think Xavier pointed out that if there are standards, there are tools, and there's ecosystems, and there's training and books about things like that. If every one of our graph databases had a separate query language, that would really inhibit the adoption of a lot of people and also prevent third-party developers from moving towards graph databases. They have the fear if they tie themselves to one engine and that engine isn't popular in the open source or in the product, but they've got a dead end there. So they also want to talk about the potential for standards beyond Sparkle. I think everybody knows that Sparkle is the standard for RDF. What about standards for property-based graphs? Xavier, I think that's an important question. And I wouldn't approach it by trying to apply the Sparkle standard to, say, a property graph. I think that the use cases for property graphs are different. I think there's some older ones, but their sweet spot is different. And there are APIs that can work against that property graph model. And they can work for some cases, but they're just not expressive enough. You know, which is the database is the expressivity of the language, which is the fundamental differentiator. But as you say, the mainstream, it's very likely to hit mainstream without a standards-based active model. So I think there's some opportunity there for an organization, either the W3C or others, to explore that or an industry, you know, a community of industry groups to come together and say, look, for the good, we can lift all boats here through a common-access layer. As Leon is saying, you know, from the database level, it doesn't really matter, you know, what the structure is in the database, what we need to give us the language that needs to be standardized in a little minute, but it's not that big. It just needs to have a standard way of doing it. And companies like Oracle are a little bit low to adopt or create a new language that will be viewed as proprietary. We'd rather have the industry come together and advance a real language that can be used for all. And several vendors can invest in that, including our company. Well, I know that your tools have been used by a very large number of Java developers. Do you think some of the techniques in your query language could be standardized across other databases also? It definitely could. You know, Cypher is our query language and it isn't tied to Neo4j. It's tied to the property graph model. And it definitely has been. The immediate potential, I should say, consequence of that would be the ultimate demise or at least the realization of graph databases. The problem is that we're way too early to standardize. And the industry, we don't know what we're doing yet. We're very candid about it. Like, you know, even though I've been working with graph databases for 13 years, you know, I've learned so much just in the past 12 to 18 months, right? I mean, I think three years ago we probably had 10 production deployments of Neo4j. Today there are thousands, if not tens of thousands, and hundreds of paying customers. And we're learning so much still on how to actually use graph databases. And I think premature standardization is not all evil, but a lot of evil. And the goal is to slow down innovation in the graph space then to standardize. But that's my goal. I want to get graphs in the hands of thousands of developers. And standards is not a goal in and of itself. What you really want is to avoid vendor lock-in. Vendor lock-in is horrible. You need that at a normal cost, but at a normal cost, right? There are a number of ways to do that that are not standards and that's a really sound architecture. Minus the amount of, let's say, the percentage of your application that has to change if you change database. And that's just sound architecture. And that's the real way, I think, to get around vendor lock-in. I think standards today would kill us, but we don't have any standards five years from now. I think that's also really bad. Sometimes we now in five years from now need to see standardization in the graph database space, but today it's way too early. At Neo4j, we see probably a hundred times or a thousand times more graph database installations than what's out there. And so we have a lot of data on how people use graph databases. But we still don't know everything. Nowhere close. And trying to build this as a standard, it's a great way to slow it down. I agree. I agree. I agree, but I think maybe part of the problem here is maybe Amir is thinking of standards the way that we used to think about developing SQL 2 then SQL 3. I can't remember whether SQL 4 ever happened. It was eons between these things crawling along with hundreds and thousands of people involved. Now, I'm talking about the community being dynamic about this and saying, look, there's change of direction. And let's say down a couple of grand rules. It could be as simple as saying, we want something that certain tool vendors or certain communities would like to use. And then some of those people and evolve this thing to meet those requirements. And if other people join in, great. I've watched things like the Object Management Group. I don't want to really implement anything the Object Management Group does anymore. We don't want that. I completely agree with Amir on that. I also agree with him that probably three or four years I'd go in the era of three or four years. The reasoning for that, in my mind, is that I've gone over and over and over in different forms of databases, network databases, et cetera, et cetera. And if we don't get it soon, people turn off. If we don't pull them turn off and the Object Database world way back because the EMG couldn't find people with the tools that we've got to pull in. If we don't do it, they'll do it. And that's not the best way for it to happen, in my mind. No rigid rules, I think, but there's a set of common requirements. And if that applies, I'll come in and say, okay, we'll become part of the Cypher community and bring the entities of these very high-end users that we have. And we're happy to do that. Very good. This is a very good discussion. There are a couple of questions that are coming in. And actually, they're also about standards. And maybe I'll throw one of those questions out that has come up from a couple of people. What about the Tinker, Pop, and Graham ads existing standards? Anybody want to comment on those? Well, let's have you address them to sort of point toward me on that. So those can be considered ad hoc as opposed to de jure standards to sort of... And so I think they're useful, but they're not... I think what we're talking about here is a query language as opposed to an API access to API. So those are useful. There's one... Those are somewhat accessible. But I think what we're... I think those are just here. And the need for it is a query language on that. Otherwise, you're going to end up with these end-to-end vendor lock-ins. And as a result, I'll throw up a proprietary approach on that. And that's essentially what we're trying to... I think what we foresee, if we want to make greater databases prevalent and widespread as reliable databases are now, and they'll each address their specific problems, you need a standard query language. The industry tooling community is not going to be investing tooling on a single vendor, a small single vendor to address that need if they see that that database vendors will be supporting that, whether they're large database vendors or small database vendors. It means that the risk... It won't reduce the risk for the customers if they have choices of different databases that are aligning with that standard and different tools that are aligning with that standard. That creates the ecosystem there. Yeah, I think we will likely have some form of standard within the next three to five years, but that's a process. It needs to start at some point, and these things don't happen overnight. In order for someone to put a specification on the table and they can work from there, but it's a community process, and moving the process forward. But I think, as Amil was alluding to in his first take up of it, and we're seeing it in ours, we need to take this to the next level. I think that opportunity is now, and the opportunity to actually take this mainstream through the common access method. Okay, so we're running up about five minutes from the end of our session, and I just wanted to thank everybody that participated, but before we exit, I'd like to ask each of you guys one of the most critical features that you guys are working on right now for your next release. What's the new hot thing that you guys are going to be releasing that you can talk about? Leanne, you want to start us out?  We've been very strong on having our customers use new features, and then when we're all happy with them, then we announce a release. But the next release is coming very soon. There are always performance and scalability improvements in our product, and we've got some interesting new features on the way which will miss more competitive with some of the newer products that are right there. Okay. Anything new coming that you want to talk about or just general trends? Two questions. New things or general trends? All right. Let me address both. So, I mean, we do develop in the open, right, the open source project. So, our code is available on Github, so you can see, you know, in real time as we build out the new features. And so, the 2.0 release is coming up this fall. And Neo4j 2.0, which is going to be a significant release. The most important part of it is going to be support for what we can build in indexing. And that means that you're going to be able to take a node and you're going to be able to label it as, say, a person node or a code and whatnot.  The reason this is really important is that then it's going to be a first-class citizen. Indexing will be a first-class citizen in Cypher, which is not true today for Neo4j 1.9.  And we think that's huge. So, that's one big thing. The other big thing is that we're doing a refresh of our web UI to write it to be completely Cypher-oriented. It's going to be, I hope, a great at least starting for a developer environment around writing Cypher. So, that's going to be awesome. And then we have, maybe it's a super exciting thing, but what's important is that we're doing a window where we're doing a Windows installer. And that sounds kind of trivial, but it turns out that we have a lot of uptake in Windows. A lot of people downloading us in Windows and our Windows experience right now is honestly, it's very manual. You need to install Java if it's not installed and things like that. So, it exposes a little bit of our underwear, which we've never liked. And we're going to improve it with an actual real install experience, which I think is going to actually just make working with Neo4j on Windows a lot smoother and easier. In terms of trans, let me just address that much, much rougher. The big trend for us is that we're going to blow away all the barriers we have in Neo4j to adding lots and lots of data. So, we're working on supporting petabytes and trillions of nodes and relationships in the 2x release. So, that's going to be super exciting for us. That's one of the most important trends for us right now. Very good. Savi, what's in store for you that you can tell us about that is? Yeah, I mentioned a couple of things that evolved in the last three months. So, first of all, our graph implementation on our relational database. We developed the Sparkle 1.1 standard specifically for these RDF views on relational data. And this is important for a lot of our enterprise customers that are trying to create these metadata stores, because what it does is you run this operation and it basically creates a view on a relational database. So, what that does is you can keep your relational databases as they are, but we've just created a view that basically represents it as a graph. So, you can basically query it as a graph, and it sits there. So, you can see the graphs that are essentially behind the covers of relational data. Very powerful for a lot of modeling. So, you're taking existing relational data and modeling it as a graph without having to transform it into a graph form. Very, very tremendous interest to our enterprise customers. The second one was the reduction of graph data model in the Oracle NoSQL. So, now you can use the Oracle NoSQL key value store as a RDF graph repository, and then use an enhanced Jenna layout and a framework to access that and utilities for loading and querying and optimization. So, those are two I'd like to highlight. Very good. Well, we're right at the top of the hour. I just wanted to thank our expert panelist. This has been a really great discussion. I think we've learned a lot. You guys all have different insights and a lot of good stories.  Yes, I am. I just wanted to mention to everybody that you'll be seeing a lot of these people at the NoSQL Now conference in San Jose starting on August 20th. Just to reiterate, and your words, Dan, thank you, everyone, for this great discussion to Leanne O'Neill and Xavier. That was just phenomenal, Dan, for moderating. And just to remind everyone, we will be posting the recorded webinar to Dativersity.net within two business days. And I will send out a follow-up email to let you know the links to the recording and all of the great links that everyone posted in the chat section there. And a big thanks again to our panel for this discussion and to Dan for moderating. And you can learn more about all these great graph databases at the NoSQL Now 2013 conference in Expo in San Jose, California, August 20th through 22nd. Thanks again for joining today's webinar. We hope everyone has a great day. Thanks, everybody. Thanks, everybody. Bye-bye. Thanks, guys. Bye-bye.