The next concept that we are going to talk about is the concept of co-normal points. Having learned about the equation of the normal, now we will talk about the concept of co-normal points. Now in order to understand what are co-normal points, let us understand this fact that in general, four normals can be drawn to an ellipse, not more than four, can be drawn to an ellipse from any point. Please remember that all the four normals need not be real. So let's say I assume a point h,k inside the ellipse. Okay, let's say I assume this point h,k. From this h,k, I can draw four normals. I am again repeating it is not necessary that all the four normals should be real. First of all, how do I prove this fact that I can draw only four normals max to max from any point h,k onto the ellipse? How do I prove this fact first? Okay, so in order to understand this, by the way, what are the co-normal points? The points or the feet of these normal a,b,c,d, they will be called the co-normal points. So a,b,c,d are the co-normal points. So co-normal points are nothing but they are the feet of the normal drawn from a point h,k onto the ellipse, right? So is there any question with respect to what are co-normal points? Now sometime I am going to prove that we can actually draw four co-normal. We can actually draw four normals from a point h,k to the ellipse, not more than that. So let us prove that first. Now we all know that the equation of the normal to an ellipse is given as a square x by x1 minus b square y by y1 is equal to a square minus b square. So now what I will do is, I will assume that these points have eccentric angles, alpha, beta, gamma and delta. So the eccentric angle of these points are let us say alpha, beta, gamma and delta. So now what I will do is, in general let us say the eccentric angle is phi. So in general, let us say the eccentric angle of these points of the co-normal points is phi. So when I write it like this over here, I can write it as a square x by, x1 could be written as a cos phi and y1 could be written as b sin phi is equal to a square minus b square. So I can further simplify this to a square x by cos phi minus b square y by sin phi is equal to a square minus b square. So what I am assuming that, I am assuming the opposite way round, I am assuming that from a general eccentric point phi I am drawing a normal. So this will be the equation of that normal. Now this normal is also passing through h comma k. So I can replace my x with h and y with k. I can replace my x with h and y with k. Now guys here I will take the help of complex numbers. I will take a help of the complex numbers. I will say let z be a complex number which is given by cos phi plus i sin phi. That means in the Euler form I am writing it as e to the power i phi. So of course 1 by z will be cos phi minus i sin phi. So it is clear that 1 plus 1 by z is 2 cos phi. That is cos phi is going to be half of, I can write it as z square plus 1 by z. And similarly sin phi would be z minus 1 by z into 1 by 2 i. That means it can be written as z square minus 1 by 2 y z. Now what I will do is, in the equation of the normal, in the equation of the normal which I have written in terms of cos phi and sin phi, I am going to make the replacement with z square plus 1 by 2 z. And I am going to change sin phi by the way this a and a will get cancelled. And here I am going to replace sin phi with z square minus 1 by 2 i z. And this is equal to a square minus b square. So please pay attention now I am going to simplify this. But for the interest of time I am going to directly write down the result of the simplification so that you all don't waste time knowing that what is important is some properties which we are going to discuss with respect to the conormal points. So when you simplify this, you are going to get a bi-quadratic equation in z. This is a bi-quadratic in z. Bi-quadratic in z. Clearly suggesting that there are four values of z1, z2, z3 and z4 which are going to be the roots of this equation. That means there can be four eccentric angles because each one of them is e to the power i phi. So I can say e to the power i alpha, e to the power i beta, e to the power i gamma, e to the power i delta would be basically be the roots of this particular bi-quadratic equation in z. Suggesting that there can be four eccentric points. There can be max to max four eccentric points which are going to be the feet of the normal drawn from h, k on to the ellipse. Hence only four normals can be drawn, not more than that. Only four normals can be drawn. Is that fine guys? Any question with respect to why four normals only can be drawn from a point external to the ellipse on to the ellipse? Okay. So for the purpose of giving you some properties I will rewrite this particular expression once again. You don't have to memorize it because it's very very lengthy procedure to derive these equations. It's just for your conceptual clarity that I'm going to write this. Okay. Now I'm going to ask you few questions. I'm going to ask you few questions. The first question is prove that the sum of the eccentric angles of the conormal points is going to be an odd multiple of pi. Prove that the sum of the eccentric angles of the feet of these conormal points or of these conormal points is going to be an odd multiple of pi. So what I want to say here is that if you add the eccentric angles over here alpha, beta, gamma and delta their addition will be going to be an odd multiple of pi. Can you prove this? If you're able to prove it, please send me the snapshot on my personal ID, personal WhatsApp. Alright. So guys, if you look at this equation here what are the product of the roots? Z1, Z2, Z3, Z4. Okay. Be careful that there is no Z squared term over here. So you can write zero Z squared. So remember, sum of the roots is minus B by A then C by A then minus D by A then E by A. So E by A would be this. E by A would be this. That's going to be minus of one. Right. Now, Z1 is e to the power i alpha. Z2 is e to the power i beta. Z3 is e to the power i gamma. This is e to the power i delta. That's going to be minus one, which means e to the power i alpha plus beta plus gamma plus delta is equal to minus one. Right.  So that can only be possible if your this is equal to minus one and sine of alpha plus beta plus gamma plus delta is equal to zero. So this can only be possible if your sum of the eccentric angles happen to be an odd multiple of pipe. An odd multiple of pipe. So this is how we can prove this. Any questions with respect to this proof, please feel free to type in in the chat box. If it is clear, please type CLR. Alright. So second property is again if alpha, beta, gamma, delta are the eccentric angles are the eccentric angles of the co-normal points eccentric angle of the co-normal points then prove that sine, take any three of them let's say alpha, beta, gamma so alpha sine alpha plus beta plus sine beta plus gamma plus sine gamma plus alpha is equal to zero. This should be very simple for you to prove since you have already taken the previous case while proving this you will be able to realize many more properties as well. Guys, again let me tell you if je has to ask this question they will actually ask this in the je advance part where they will first tell you what is co-normal points. They will not expect you to come prepared with this theory. Je is most interested in locus whether you are clear with locus if at all some extra concepts are to be asked they will always frame up a paragraph based question explain you what is co-normal points and then probably ask you follow up questions on that. So look at this again we will recall back the previous equation so again for the purpose of using it I will recall it for you so this was the equation that we had written in terms of z in terms of z again I have not written it but zero z squared should be here because z squared is not present and that's actually the key point for us this is the key point for us if you realize that z squared term is absent that means product of all the roots product of z1 z2 will actually be zero that means e to the power i alpha e to the power i in fact I will directly write it e to the power i alpha plus beta e to the power i alpha plus gamma e to the power i alpha plus delta e to the power i beta plus gamma e to the power i beta plus delta e to the power i how many have written 5 the 6 one is left e to the power i gamma plus delta it should be zero correct now when you express it as a polar form you would realize that summation cos alpha plus beta plus summation i sin alpha plus beta is actually zero plus zero i right summation means understood right two angles taken at a time which clearly indicates that these two individually are zero zero right so again this is some extra information which I got from the problem however I have to prove only the thing which is given to us so how do I prove this so let me write down these angles once again sin alpha plus beta sin alpha plus gamma sin alpha plus alpha plus delta sin beta plus gamma sin beta plus delta sin sin gamma plus delta equal to zero okay now we all know that alpha plus beta plus gamma plus delta is an odd multiple of pi so let's say pi okay it's an odd multiple of pi so can I say that can I say that alpha plus now look at the terms which are not required if you look at the proof we only require these terms this beta plus gamma and gamma plus alpha gamma plus alpha this we don't require this term this term and this term okay so what I will do is first of all can I write alpha plus gamma term as pi minus beta plus alpha plus delta can be written as this alpha plus delta term as pi minus beta plus gamma correct so sin of alpha plus delta is sin of this term which is actually sin beta plus gamma okay so these two terms these two terms are same this term and this term are same these two are same similarly I can say that beta plus delta that is this term is equal to pi minus alpha plus gamma so sin of beta plus delta is equal to sin of alpha plus gamma so this and this are the same term this and this are the same term and similarly you can say sin of gamma plus delta will be sin of alpha plus beta so the first and the last are the same term that means the same expression can be written as twice of sin alpha plus beta sin alpha plus gamma sin beta plus gamma any three angle you can take okay so dropping a factor of two from both the sides hence proved is that clear guys any question with respect to this


From the SiliconANGLE Media office in Boston, Massachusetts, it's theCUBE. Now, here's your host, Dave Vellante. Hi everybody, welcome to this breaking analysis in this CUBE Insights powered by ETR. I'm Dave Vellante and this episode is about data protection. You might be saying, Dave, why are you going to bore us with the conversation about backup? Well, it's interesting. The market is actually quite hot. You know, over the last 18 to 24 months, there's been well over a billion dollars, probably 1.3, 1.54 billion dollars raised just from companies like Rubrik, Cohesity, Druva, Zerto and a number of other startups like Clumio is a name you might not have heard of and I'm going to mention a couple of others. So you have this situation where these upstarts, particularly Rubrik and Cohesity, are really challenging the install-based players and they're spending a lot of money on marketing and on engineering and sales and they're going to market and they're really shaking things up and I want to talk about that dynamic, share with you some ETR data and talk about some of the other players like Veeam who was a rocket ship because of the virtualization trend, how are they faring in this kind of new market and why is this market gaining so much attention today? And what does this mean for incumbents? What does it mean for customers who can achieve escape velocity and what are some of the likely outcomes that we see? The market's very confused right now. If you look at the Gartner Magic Quadrant and compare that to, for instance, the Forrester Wave, Dell EMC's not even in the Forrester Wave, Gartner Magic Quadrant has Rubrik not as a leader and it's just all over the place and so what I want to do is use some ETR data and some context from theCUBE to share with you our audience what we are seeing in the marketplace and kind of what it all means. So let's get into it. Alex, if you bring up the first slide. I first want to make a statement about the overall storage market. The ETR data set, which is incredible, doesn't drill down into backup although it does have pure play backup vendors in the data set. So I want to start with storage because it's the superset of the data protection market. So what this chart shows is all the sectors and it shows the net scores. Remember net score is, they ask every quarter, are you spending more, are you spending less, are you spending the same? They subtract the less from the more and that gives you net score. So this is the net score for the three periods of October 18th survey, July 19th survey and the October 19th survey. And you can see the red line shows, storage is kind of on the back burner. Yeah, it's upticking a little bit from previous surveys but it's got a net score of 18. That's crappy. I mean, it's not really a hot market I've talked in previous episodes and breaking analysis as to why really two main factors that I cited, cloud guys eating away at the traditional storage array business and flash injected so much capacity and performance into the equation that data center managers are saying, hey, I don't really need any more storage right now. So storage is kind of on the back burner. You can see I blew it up here and you can see sort of how it's playing. You see the hot sectors are analytics, cloud computing, container platforms, data warehousing is making a comeback. I've talked about snowflake on previous breaking analysis, machine learning and AI and new workloads, robotic process automation, even virtualization. These are the hot sectors that are driving spending. But I will tell you, storage ultimately is going to be there. It won't be down forever because people are always going to need storage. These new workloads are going to require new storage and obviously backup. If you go to the next slide, Alex, you can see some of the vendors here. So we've sort of established, okay, storage is right now it's down, it's not one of the hottest sectors, but you can see there's some companies in here that are pretty hot. Rubrik leads the list with a net score of 53%. Now the shared end, might be a little hard for you to read here, but the shared end out of the last survey, 1300 respondents from the ETR survey answered what their spending intentions were. And then the individuals mentioning specific companies, in this case Rubrik, 55. So it's kind of a small shared end. You can see Pure Storage, a company that we've talked about previously, continues to show strength, 48.1%. Down slightly from the previous quarters, but still really the only clear share gainer in the overall primary storage market. Again, Rubrik, you can see Nutanix is up on the list. Veeam is actually quite impressive. I'm going to show you some data in a minute that I think will impress you in terms of Veeam's continued staying power. You see Veeam on there, Cisco's on the list. God knows why Cisco's on the list. Their storage is not perceived as leading, but they do have offerings and Cisco's so big. People just kind of say, yeah, we're buying from Cisco. You see Cohesity there. We'll dip this past survey, but still very strong. Again, I'll show you some other data there, et cetera. So you can see the point is, even though storage is down, there are a couple of shiny stars, like Rubrik, like Nutanix, Pure Storage, Veeam, Cohesity, et cetera. So let's dig into that a little bit. Before I do that, I just want to share with you some trends on this slide with regard to the backup market. I underscore backup because it's no longer just the backup market, it's evolving. So there's pressure on the overall storage market, but data protection is actually really hot right now. It's captured a lot of venture capital. Startups are moving in. I'll mention a few that you might not have heard of. Why? Well, several reasons. One is the data explosion continues. It's growing at an exponential rate and it's kind of non-linear. Digital transformations are all about how you leverage data. And so if you're making your business a data business and a digital business, well, you better have a way to protect it. So things like ransomware are coming into play and people are really concerned, obviously, about ransomware. So data protection evolves and expands, sort of transcends backup into business continuity. Cloud and hybrid cloud are some other trends that I'll talk about in more detail that are driving opportunities for what were traditionally known as backup and really now are evolving into sort of these new areas. Last decade, it was about moving from tape to disk. Tape sucks, that was kind of the data domain mantra. And they were the hot company of last decade. They did an IPO, they reached escape velocity, they sold for 2.5 billion. But today, the data domain platform that EMC bought and now is Dell EMC is kind of old school, right? It's these new guys that are coming after that. So while data domain pioneered data duplication and higher performance backup moving to storage, today it's a whole new conversation. And people have come to the realization that the primary and active storage is only about 20% of the stored data. All the less hot data, I don't want to say inactive stuff. It's not cold storage, but it's files and objects and copies and replicas and backups. That's 80% of the marketplace today in terms of the volume of data. Not necessarily the spend, you know, OLTP stuff, primary storage is expensive, flash arrays expensive, but huge opportunity, especially in terms of data growth. That's where all the data growth is happening, all that unstructured data. So today the conversation is evolving to data protection, data management, data assurance, particularly with containers. So you think about spinning up containers, spinning down containers, you know, dozens, hundreds, thousands of containers. How do you keep track of that stuff? How do you protect that? How do you assure that your data's not leaking, that you're not exposed? And so that's a really hot area that you're seeing a number of startups focus on. So real focus on recovery becomes much more important for a digital business. How fast can I recover? Security, compliance, this notion of data assurance, CDM on this slide, which is stands for copy data management, a practice that was really popularized by Actifio. DevOps, really supporting DevOps through a data management platform, being able to give live copies or near live copies of data so that, you know, tests can be tested on much more fresh data and compressing that cycle time. Analytics becomes more important. I talked about ransomware before. Well, you can look at the backup corpus and do analytics on that to see if there are anomalies and anomalous behavior just in terms of bad actors coming in. So all this stuff joined with cloud and hybrid cloud and is sort of bridging the legacy business and it's bringing out a lot of new challengers to the incumbents. So let's take a look at some of that data from ETR. Alex, if you go to the next slide, this is the ETR data set on backup vendors. So what I've done here is pulled out of storage the pure play data protection folks.  No, we're much more than backup. We're data management. Now data management means a lot of things to a lot of people, but nonetheless they are expanding and transcending pure backup. So credit to them. This is the net score timeline from January 2017 to the latest October survey from enterprise technology research. And you can see here, I've pulled out Rubrik, Cohesity, Veeam, Commvault and Veritas. And Rubrik leads, as I say, with 53% net score followed by Veeam, 44%. So you can see Veeam really hanging tough. The Cohesity just relatively new to the survey jumped up, jumped down a little bit in this quarter. You'll see that. You'll see that in the ETR data. Anyone get too freaked out about it? I think Cohesity still got some tailwinds and momentum does Rubrik, but look at Veeam. Veeam's ascendancy came from really Veeamware. They were the Veeamware specialist and they were all virtualized. And now they do bare metal, they're doing cloud and multi-cloud and they back up Office 365 and so that's the SaaS platform. But look at how well they've held up. Quite impressive there with Veeam. Made a major push into the enterprise, kind of pivoted back to SMB, but still does a lot of business in the enterprise and you can see them showing up here. What's relevant to me is the shared end. In other words, out of the 1,300 in the total survey, how many are responding to these vendors? Rubrik, 55, relatively small. Veeam, 155, much larger. So a bigger install base, Cohesity, 42. Kind of just getting started in the ETA data set. Commvault, 105. So, Commvault's a $700 million company in revenues on a trailing 12 month basis. They get about a $2.2 billion market cap. They just bought HeadVig. They're moving toward a SaaS model. They launched a product called Metallic. They get a very, very large install base. You can see their net scores. Yeah, where they're holding relatively well. They're smaller, obviously, they're lower than those top three. And then you can see Veritas. Veritas is the big whale in the business. They kind of, mostly, they're almost a pure place software company. They do have an appliance, but they really are the leader, a leader here. And have had a big market. They went private. They got bought by Symantec. Symantec didn't know what to do with them. They fumbled around with it. They did a private equity deal. That was going okay, but they had some management turnover, private equity squeezed them a little bit, even though they made some investments in the platform. And so Veritas has some challenges. They have to serve the install base, but at the same time, they got to compete with the new guys. And all the new guys, Cohesity and Rubrik in particular, are attacking the Veritas install base, certainly Commvault, and as well, Dell and EMC. You can't have a discussion, really, around leadership and backup and data protection without talking about Dell EMC. They're so large. So, Alex, if you go to the next slide, you can see the net score for Dell EMC. The N here is 348, much, much larger than some of the other guys that I just mentioned. I'm actually looking at Veritas 97, even though I have a large install base. So Dell EMC, but here's the caveat. This is all of Dell EMC storage. So it's not just the pure play backup. The previous slide, I was showing you pure play data protection vendors. This is all of Dell EMC. So it includes all their primary stuff, all their flash storage, all their storage, not the other parts of their business, not the compute and analytics and other stuff, just storage. So I'm using this as a proxy. Okay, so this is not Dell's data protection business only. And so let me make some comments there and I'll comment on Dell's data protection business. You can see it came out of the downturn, past 2009, big uptick. And Joe Tucci used to say, we're going to come out stronger. We're going to invest through the downturn. We got the cash. We're going to come out stronger. And that's exactly what happened. They came out very strong, but then, you know, cash flow started to get squeezed. They expanded their product portfolio. It was like product du jour, all these mega launches. And it just got too confusing for customers. Salesforce got confused. They got less productive. And then Dell or EMC at the time was really relying on VMware. It's the value in Dell. I'm sorry, I keep saying Dell. Value in EMC at the time was really in VMware. And you can see that kind of steady decline in the net score. And that's what happened. Elliott management came in, they squeezed EMC, kind of forced them, forced their hand and then Dell ended up taking them private. Let me make some comments about the Dell acquisition and specifically Dell EMC's data protection business. Dell EMC took its eye off the ball in storage generally, but specifically in the data protection business. It fell behind. It wasn't investing fast enough. It had some management changes. It put Beth Phalen in charge a couple of years ago now and her task was, okay, she was tasked with shoring up this business. But they had to get some new products out. They had to focus on some of the lower end of the market and then have to refocus on the higher end of the market. So they've really begun to get their act together again in data protection and really refreshing the data domain piece of the portfolio, bringing Avamar and data domain together and becoming much more competitive. Having said that, they lost some ground, okay? So they've got that same challenge as Veritas. They've not only got the new guys coming at them with this modern data platform, they've got to service the existing install base and sort of manage that cash flow. They're now a public company again. So a lot of pressure on those guys. I want to go back to the previous chart, Alex, if you will, and then the one that shows Rubrik, Cohesity, Veeam, Commvault and Veritas, the pure plays. There's some other dynamics that I want to talk about here. HPE exited the software business. It's core software business. It sold off to Micro Focus and as part of that, it sold off Data Protector. When it did that, it opened up a whole new partnership opportunity for these emerging companies, particular Cohesity and Veeam are actually reselling through HPE. HPE's got a massive channel and those two companies are doing very well there. I said you can't talk about Data Protection without talking about Dell EMC. Same thing for IBM. You got to talk about IBM. IBM is a huge install base and IBM bought Tivoli years ago, Frank Moss's company and then they served mainframes and it was this big complicated platform, kind of still is. And so IBM had to make a move. So it was getting killed in the marketplace by Veeam in particular, so it created Spectrum Protect Plus. And IBM has really gone after software defined. It's begun to modernize its platform going after containers, as I mentioned, is a hot area. But it's still got that same problem. It's got to service the install base and so they're sort of doing that balancing act. But they definitely had to refresh the portfolio and it's done a good job there with Spectrum Protect Plus. Couple of the companies that I haven't mentioned, Druva is getting into that whole data management space. So Cohesity and Rubrik kind of redefining back up into data management. Veeam goes back to the basics, really talks about backup and data protection, data management as being the future. So it's kind of trying to deposition Rubrik and Cohesity as much more in the future and not here today. And so they're sort of playing that marketing game and very effectively, as you can see by its net scores. Again, Druva hopping on the data management bandwagon. Xerto, kind of a DR replication expert. Clumio is calling BS and all these guys and saying we're going pure SaaS model.  It's raised about $50 million I think. But here's some other names you might not have heard of. Castinio, Valero, Trilio. These guys are going hard after containers and what I referred to earlier as data assurance. So the big question is who's going to be able to achieve escape velocity for the upstarts? Who's going to be able to hold serve for the incumbents? Let me make a couple of comments on that. I think storage eventually is going to bounce back as I say some of those hot emerging workload areas like AI, they're going to need storage. Analytics is going to be driving the need for these types of things, security, data assurance, data protection, storage will, don't bet against data. So storage will I think eventually bounce back. And unlike compute where Intel makes all the margin, storage is more like networking where you get really good margins. It's a 60 plus percent gross margin business. Pure storage has almost 70 percent gross margins. Cloud is the wild card here. I predict you're going to see the cloud vendors begin to dramatically expand their portfolios. And he's beyond just going to S3 simple object storage. Okay, yeah, we got Elastic, a block store, EBS from Amazon, Microsoft has similar storage as this Google. They are going to double down on storage. They're going to look at storage as a bigger opportunity and that is a wild card. It could continue to pressure the traditional storage guys but look, let's face it, it's a hybrid world, still a ton of stuff going on-prem. So I think that the overall market will bounce back. I think data protection as a subset in data management is going to grow faster. It has some tailwinds. I think it's got an expanding TAM and those tailwinds are digital data, digital business security, data assurance, this new management capability that I talked about, DevOps and container protection, container platforms as I showed you earlier in the ETR data is one of the hottest areas going. And I think you're going to see some consolidation. You saw a Commvault bought a HeadVig. You're going to see some exits. Veeam is now talking about doing an IPO. It just took in a half a billion dollars in investment. So its investors are going to want an exit. So our cohesities and rubrics, which together have raised almost a billion dollars. So you're going to see some M&A, I think specialists like Zerto and Druva are probably going to be targets. I think you're still going to see Dell become much, much more aggressive, kind of getting their act together. The big incumbents, IDM, Veritas, refreshing their portfolio. Again, their challenge is the innovator's dilemma. So I do think you're going to see some, at least one, maybe two, the favorites there would be Cohesity and Rubric is achieve escape velocity. I don't think there's enough room for three to be like blockbuster IPOs that can survive long term. But I think this data management thing has legs and we're going to continue to watch it here. Thanks to you for watching. Thanks to our friends at ETR for sharing this data. This is Dave Vellante for Cube Insights powered by ETR. We'll see you next time.


This is a quick word on me. This is what I am. I have over a decade of experience in the field of cyber security and I'm very passionate about, you know, delaying offensive and defensive practices which include security by design, privacy by design, threat modeling, etc. I'm a very active member in a community called Null, which I'm not sure if you guys know well. And our recent project was jobs.null.community which powers, you know, free recruitment for employers and job seekers both. And you can always find me on LinkedIn and Twitter. My DMs and messages are always open. So if any questions, please feel free to drop a line. So before I get into the presentation, I have some, you know, ground rules. If you have any questions, please feel free to raise them while in the middle of the conversation. If I don't see a raised hand, you know, feel free to leave a message in the chat and I will have a look at it. Everything that I talk here is, you know, purely out of experience and something that is, you know, we've learned or I have learned over practicing, you know, different streams like privacy by design and security by design. So that's, that's pretty much it. So let's quickly jump in right now. What are the key takeaways that I'm expecting that our audience will benefit at the end of this is a we will talk about a lot of unstructured data and what are the privacy implications around it. We will also talk about privacy by design blind spots and I will give you a number of examples how these areas are often, you know, missed when you're coming up with a data governance framework, especially when you know you're talking about privacy by design. Agile practices for implementing privacy controls. I will talk about this as we move through the slides. A lot of stuff I will talk about will also be out of experience and you may not find them on the slide, but I think wherever it is important, I've made my best effort to put them onto the slide, but if not, we can always also have a chat, you know, maybe offline later. So before we begin into the unstructured, you know, data word, this is a very high level definition of what data governance is all about. This is for audience that is largely into governance privacy and compliance and similar practices. So what is data governance? It's essentially, you know, a set of principles and practices that ensure high quality through the complete lifecycle of your data. Now, if your data sits in one particular system or in one particular database or one particular location, it's fairly, fairly easy to come up with a data governance framework, and then you implement rules that make sure that, you know, achieve the purpose of why do you have a data governance framework set up in your organization. But the real problem then starts when you don't know where your data sits, you don't know what is the structure of that data.  Again, this is a very high level data governance framework that, you know, generally is followed if an organization has a data governance function, you answer typical questions like why, who, what, when, etc, etc. The largely to be able to answer a why do you need some data, who's going to have access to that data, when will they access to that data, and what are the means for accessing that data. But let's let's break this, you know, complex diagram into some very, very simple examples. So that takes me to all the blind spots. And again, I think a lot of this that I'm going to talk about is something that we've developed over years of experience, right. When I started the journey into helping different teams within the organization that I work for privacy by design, especially when you know the GDPR was very, very rampant and we operate in European geographies where GDPR seems to be mandatory. It was a fun exercise to start with to see every single system that stores customer data or any information that is deemed as, you know, private. In doing so, like I said, when I started that if the it's very easy to identify data that sits in a, you know, structured manner because then you can implement uniform controls. The real challenge was unstructured data. And I'm going to give you some examples in a bit. The other invent the other blind spot that you know I discovered during this process was inventory of systems that actually store process and transmit data. And once you have a look at these examples, you will realize that, you know, these are systems that we don't even consider when you talk about data governance or data privacy or privacy by design related stuff. I will touch upon some examples on, you know, masking, tokenization, anonymizing or encrypting the data. If I were to summarize, you know, all the blind spots that we've come across through our practice of privacy by design is you cannot protect something that you don't exist. Right. I mean, it's a very, you know, it's common sense that if you are responsible for protecting an organization from external threats, you cannot protect that organization. If you don't know what is the exposure of that organization on the internet. So, I mean, that's just my way of, you know, summarizing the different blind spots that we have. So let's move on, right? Let's move on and talk about what unstructured data is a very simple definition is that if it does not have a predefined data model or a schema for me, it's an unstructured data. And I'm sure that, you know, it's a general definition for any kind of unstructured data. Now, some examples are sensitive data that is exchanged over emails, documents, text files, it could be anything, right? It depends on what is your function in that given organization. For example, if you are somebody who supports a product and you often deal with a lot of customer, you know, questions, then you are extending a lot of data over emails and documents. And, you know, it's very difficult to put a structure around it. Sensitive data stored on public S3 buckets. You can find several, several examples on the internet of how people have managed to find sensitive data about a given organization on, you know, in a public S3 bucket, which does not have any, you know, correct ACS configured analysis is accessible to anyone. Data shared on social media. This is very interesting, right? Now, a lot of my examples in this presentation are relevant to, you know, my organization. The reason I say that is because, for example, you know, let's talk about data shared on social media. Now, these days, we often exchange a lot of information with our suppliers. So for example, you know, if you want to tweet to your electricity provider, then you, you know, go ahead and tweet and in doing so, you might end up giving a lot of information to them, which is something that, you know, in principle, you should avoid. If you're tagging your friends, if you're tagging, you know, images, which may have, you know, location information on them, etc. All of this is basically, you know, data shared on social media. Data shared indirectly with suppliers or partners.  But what about the data that you share indirectly? What that means is that you start with a certain initiative saying, saying that this is what the data that is going to be consumed as a part of my product life cycle. But in doing so, other information as well, which makes your data more and more richer, you know, from a privacy point of view. Now, Facebook is a classic example of this, that it's not just you who give information to Facebook, but it is also all the people who advertise their products on Facebook. Facebook is giving them your information. And as a result, you see a lot of tailored experience in terms of pointed ads, you know, that come up on your Facebook pages. So let's, you know, break this down. Now, if you think that your data is only stored within an rdbms thing twice, right.  In my experience, it often happens that developers are never exposed to the entire life cycle of the product. What that means is that as a developer, if I'm writing code for a certain product, I have no visibility as to how these are exposed to the Internet. What kind of logging is configured for these applications? What are the kind of analytical trackers that are implemented? You know, what kind of other activities are carried out, you know, by my business that works on these kind of products. So as a result, because the developer visibility is minimized and is not, it leads to blind spots in a lot of areas, and we are going to talk about some of them.  There are some very interesting examples that I will give to you in a bit. Data analytics systems, I'm not quite sure of, you know, how many people in the audience are well versed with, you know, full blown data analytics systems that can actually record an entire user session in their browsers and give opportunity to your businesses to be able to replay that entire session and come back and give you a more tailored feedback or an experience. I mean, this area in my experience has been a big, big privacy nightmare, if not implemented correctly. Again, something that the developers are often blindsided is, you know, the kind of logs that get stored within web servers, proxies, load balancers, errors, web application firewalls, et cetera, et cetera. So everything that I'm going to talk from now on is going to be related to this slide and the way I've structured is that I've come up with a case study. And this case study is something that we will keep often referring to throughout the presentation. And please feel free to raise questions if you have any, you know, doubts or, you know, you want to add something in. So this is, this is what my case study looks like, right? It says the business requirement is very simple. I need to design an API as a developer that will return all the attributes that I have about a given user after successful authentication. Now, consider a system like Facebook again, where once you authenticate Facebook, you always have these, you know, websites that power login by Facebook login by Google, et cetera. When you click on login with Facebook, it basically returns a very specific data set and it asks you for your approval before it is shared with, you know, the actual vendor or the actual website that you're using login with Facebook as now. The other requirement that I have is there could be a number of partners that could consume this API and each partner needs access to different attributes within that data set. So for example, if my store, you know, 100 attributes about a given user, when they register on my website, partner one needs access to only five, partner two needs access to six, and so on and so forth, right? So this is, this is what the business requirement is and, you know, let's look at possible solutions of how you could design an API like that, right? So the first one is let's say that I create one API that sends all the user details upon successful authentication, and every partner can choose whatever field they want. Now, what I mean here is that if I have 100 attributes about a given user, and I would successfully login and in my head, because there is an NDA or a non disclosure agreement signed with the vendor, I have no problem giving them all the 100 attributes. But the vendor will in turn end up using only those that are required by them. Now when you're doing something like this, like those important one, you know, being that time to market. If you tell your business that I have an API that you can actually consume and give it to all the people that you work with or all the partners or suppliers or vendors you can quickly work with. My time to market is extremely, you know, less, I have less over it and quicker turnaround. So even if I have to make like the slightest modification, I just make it in one place and it's applicable to everybody. Now, the biggest challenge in doing this is it's not data privacy friendly. Let me give you an example, right? So for example, you have one vendor that only needs five fields from the response of your API. But because you're giving them all under it, there is nothing that stops the vendor from iterating through your database and storing all those 100 attributes about those users. What they do with that is completely, you know, a different discussion, but this is a potential, you know, area of concern if you are somebody who's very privacy, you know, minded organization. The other way to solve this problem is you could create multiple versions of the same API for each partner and send them only what they have signed up for. Now, this is a very good approach, right? Because even if I have 100 attributes and let's say that one partner needs five, I only send them five. If the second partner needs six, I only send them six, which means that I have full control over what I can share with each of these vendors. Now, the biggest problem with this approach is time to market, which means that if your business follows a lot of agile practices and, you know, they onboard new vendors on your platform very frequently. Then this is going to be time consuming because with every new partner that they onboard, you have to create a new version of that API and then map the fields that are required. Of course, this also means it's a bigger override and turn around times and something that your business may not necessarily appreciate. Now, considering the different technologies that are available in the market, the third approach could be that you create one API, but you create multiple views on top of it for each partner. Now, I'm not sure how many people are developers in the audience, but if you know technologies like GraphQL or if you know Facebook's Graph API, this is exactly what they do, right? They create one API and they create multiple views on top of it and then depending on what the partner ID is, you only send them the data that is required. Now, I'm not sure if you guys are well-bursed with the whole Cambridge Analytica and the Facebook scandal where Facebook has this approach to all their APIs. They create, they have one version of the API and they build multiple views on top of it and then they allow Cambridge Analytica to pull a lot of information. About Facebook users, which they would potentially not really give access to other people. What are the pros in this process? It's very efficient process. It's very scalable and it's also very data privacy friendly. Come on, because you're giving only access to the data that is required. The only challenge in this is and that is something that you learn out of the Facebook and the Cambridge Analytica scandal is governance and oversight. What this means is that there is no way for you to not know what data is accessed by a given vendor if you have the right checks and balances in place where you're reviewing the responses that are sent to individual partners on periodic basis. As a result, the cons are governance and oversight. But hey, governance and oversight are fairly easier problems to solve when you know that the underlying platform that you have built is foolproof or you know for sure that it does the job that it was designed for, which is allowing you to create views and only extending that information that is required. So this is a blind spot, which we have often come across that you design APIs, but these APIs are sending information back, which is not intended for sharing or was not a part of your agreement with the vendor or whatever your agreement with the vendor or supplier was. I mean, this is personally my favorite one. Let's talk about this, right? So there are a lot of functionalities in your applications which require you to deep link. Let me give you for example, if you see here, you have a service online in which if you go back and click, I forgot my password. They email you the password link on your email with a token. Now, when you click on that link, sorry, when you click on that link, it takes you to the password reset page.  If this token is valid, then it will allow you to reset the password. This is how typically password reset functionalities are designed. You send an email to your customer, your customer will click on the link, land on the page. If the token is valid, you will be able to allow the user to reset the password. Now, what happens actually at the back, right? And something this is often the areas where developers don't realize, you know, the privacy implications. Now, the browser security model simply states that anything that you send in the query string A will always be visible and B will always be logged by a web server. Right? So let's say for example, you have two parameters that take a username and a password. And if you ever do a get with that request, whatever is the fragment of the URL will eventually get recorded as a part of your web server logs, which means that whoever has access to your web server logs could also potentially have access to the password reset codes. Now, if you look at two important problems with this approach, is that whenever, sorry, when the page loads the entire link along with the code will be submitted to any trackers that are implemented on the page. Now, what does this mean? What this means actually is if your organization or if you're building a product that is having this requirement where you want to track, you know, user experience and you want to see how many users actually use the password reset functionality for whatever reasons, right? Or you build a tracker that is there on the page every time somebody visits, it collects certain information that is available in your DOM and submits it to the tracker. Now, this tracker that you have may not necessarily be designed by you. The most common example and most widely used marketing trackers on the Internet are through Google Analytics or through DoubleClick or to Kretow. There are a lot of ton of, you know, these providers on the Internet. These trackers also have the ability to inject JavaScript into your browser if that's what you've designed them for. And again, an area where you have to be very, very cautious about what they are capable of injecting back into your pages. Now, the other common area that I've seen often, you know, is an oversight is if on this page when you click on the Save button, whatever is in your browser URL actually gets submitted as a referrer to the next page, right? Again, if I were to explain this in detail, you have a link to the left which allows you to reset the password when you click on it, you get to the page on the right. And when you click on the same button, whatever is the page that you go next, this link automatically becomes the referrer. Now, from a privacy point of view, there are a number of things that could potentially go wrong here. Let's say that your password reset functionality was not implemented correctly, right? Which means that once the user clicks on the link, you don't expire the token or the code in this case. The other mistake could be that if your business is very keen in terms of making sure that the users have the best of experience, these codes, they live for longer than 24 hours, which means that I request for a password reset and I will continue to keep the link active for the next 24 hours, right? Even if the user has clicked on the link and that link is having a data that is then submitted to a tracker and anybody who has access to the tracker will potentially have access to your code links as well, right? So as a developer or as an organization, anything that leaves your vicinity or your boundary of systems is out of your control. What happens to that data is something that is very difficult to govern and as a result, it becomes very difficult to implement privacy-related, you know, design controls on such pages. Now, the black spot is that the data that is sent in the query string will always be present in the web server locked or leaked by a reference and submitted to trackers implemented on the page. If the request, of course, is visible in clear text. I am not sure of how many developers are well versed with systems like App Dynamics or Quantum Matrix or Full Story or IBM Tele for example. Now, these are systems that allow you to implement some kind of tracking onto your web page that allows them to record the entire user session. They then convert this session into some sort of an HTTP request and then they post this information to the backend. Now, from a business point of view, they never want to lose an ounce of business just because the user had an unintended or unexpected experience on that page. Let me give you a very simple example, right? It's very common in an airline industry or for that case, even on any e-commerce platform that if a user puts something into the cart and if they go all the way to the paving page and for whatever reason, they are not able to make a payment successful. Your business would definitely want to know this. The reason they want to know this is because they don't want to lose the revenue on that user. Now, somebody on the business side, when they identify these kind of events, they will try and tailor an experience in a way so that next time that user goes back or logs in again to the application, they will continue the journey from where they stopped. And these kind of systems are very, very useful and powerful but at the same time, they are a massive privacy nightmare. Now, I've taken this video, it's about this app called as Full Story that has a similar pattern. So this will just give you some sort of a feedback or just give you a look and feel of what these kind of systems are. So what you see to the left is a simple page in which a tool like Full Story is implemented and you will see that as the user enters information on the left, how they get recorded as an HTTP session to the right. Now, you will see here to the left, there's a lot of information that's available and given or supplied by the user and to the right, you will see that as and when this user actually modifies any information. This app at the back of this API implemented on your website is actually collecting all of this information in real time. I've also given a link in case if anyone wants to go back and have a look at it later on, but these systems from our privacy point of view are a big nightmare if not implemented correctly.  Now, why are we discussing these systems is because of this right now, I will allow you to read these links after the session, but at a very high level. I can tell you what these issues have been and I have, you know, my team back at work we've tested a similar system and we've come across some very interesting observations. So I think both these incidents were very good examples of how unintended data can get captured by the actual vendor or the owner of the website. So in this case, let's say it's either Facebook or Flipkart or Amazon or whoever it is. And then what do they do with this data at the back? Now, while all of these systems, they have one thing in common where they actively talk about a lot of privacy controls that are there in their application. But at the end of the day, you can only trust them for what they say, right? And from my experience, what I've realized is that, yes, it's good to trust and have these kind of implementation done, but it's also very important to verify what the claim has been made here. And verification could be as simple as you set up your app, integrate this tracker and then you do an assessment or a review from both the sites while you're actively submitting the data from the app. You see what's happening on the other side and then you find ways and means of compromising that piece of information or trying to get unauthorized access to that information. And that's how you will be able to tell yourself how foolproof this technology is or how foolproof that solution is. But I would highly encourage you guys to read these articles because they give some very interesting insight on how different organizations have implemented it. I think the first example if I recall well is related to Air Canada where they had a similar feature technology implemented in their app and then a privacy researcher identified gaping holes in the way it was implemented. This wired article talks about how organizations like Google and Apple are working very closely with their developers to ensure that if there are any such technologies implemented within the app, then they have to fully declare and they have to follow some accessibility rules and guidelines to be able to make sure the user is aware of what data is captured from their screens. Moving on, this is one area which is where developers are often blindsided. For example, you know they come up with designs of get posts request or any restful API for that case, but whenever they try sending the data in the query string. They don't know that it is potentially getting logged everywhere where the SSL is intercepted or offloaded. What that means is that you have perimeter technologies. For example, you know, if you talk about F5 or Akamai or any other web application firewall service provider and vendor in the market, you need to offload your SSL onto those devices so that they can carefully examine the requests for any potential anomalies. And if everything seems good, then they forward this request, you know, back to the actual origin server. Now in doing so, if you pass anything that is potentially sensitive, then you will end up showing all of that information, you know, in the log for those kind of devices. And I've listed some more, you know, you know, technologies, like for example, very big organizations which, you know, give access to their employees for Internet implementing proxies, they often SSL intercept your traffic. That way, they know everything that is going in and out of the system. So again, you know, if you're passing anything that is sensitive in nature, you want to think twice because you know that it is going to eventually get logged. Getting logged is one part. The problem is that if any of these implementations have any sort of authentication or authorization issues, then it becomes a big, you know, nightmare because now you can actually take that request, extract that request from your proxy and actually replay it on behalf of the user. Right. Similarly, you have, you know, load seven layer seven or application load balances these days with all, you know, advent of cloud web application firewalls. These are very interesting devices. If your organization and if your product that is consumed by different people on the Internet is under any kind of attack. And if you have of an application firewall, then you will always be able to see what the attacker is actually doing.  So these are the kind of questions that you will always be able to answer with, you know, the application firewall like devices and others is of course, you know, market capturing devices if, if your user or your customer base is compromised through phishing campaigns, they are actually submitting their credentials to, you know, the people, the adversity here in this case. But if you consider an example like, you know, the British anyways hack that happened a couple of months ago, where somebody injected a malicious JavaScript on the page itself and it was only on the payment page. And what that script essentially did was that it logged every single keystroke of the user. So you as a customer you actually go to the website you are entering and trying to book a ticket through the platform. And while you enter the details, this piece of script that is embedded on the page is collecting all this information and sharing it with whoever is, you know, the attacker behind the scene. This kind of attacks were also very popular by the name of the whole crew that was behind this were termed as mage cards. And I think they're compromised a number of e-commerce websites through, you know, a vulnerability is like cross-site and thereby injecting the horse grips that allow you to harvest a lot of information as the user types this data onto these websites. All right. Let's, let's have a quick, you know, deep dive into masking, tokenizing, anonymizing encrypting. Now, I think from a data privacy point of view, I think these are very, very important terms. And I can tell you this sort of experience, right? So let's say that, you know, your organization wants to host a hackathon. And as a part of that hackathon, they want to share some sort of data with, you know, the people who participate in the hackathon. And the goal is for them to be able to come up with a creative app or a creative service or a creative feature on your product that can then be, you know, I would say then they will be able to, you know, either, what's the word, they can generate revenue out of, you know, these kinds of features and, you know, analytics that they capture from the website. And other similar situations could be that you have a data science team that is responsible for using different kind of machine learning algorithms to be able to give insights to your business teams to be able to make educated decisions of, you know, forecasted sales or forecasted inventory or, you know, if they potentially opt for a certain kind of service, what's the cost benefit that they would potentially get. Now these are some very, you know, various use cases. The mistake, the most common mistakes that I've seen in my experience is that they very easily interchange the definition of masking, tokenizing or anonymizing or encrypting the data. So for example, a lot I often talk to a lot of developers and for them encryption often seems to be, you know, the silver bullet that will solve all the problems. But that's not potentially true. Encryption does not solve all the problems, right. And most importantly encryption may not even be the requirement for that particular use case, but you're just trying to over engineer something and as a result make it complicated. Similarly, I've often seen people exchanging definitions of masking and tokenizing. I will give you some examples as we move along in the slides, right. Now, the most common errors that I have witnessed from data masking point of view is first is consistency. Now what consistency means is that let's say that you have a website and you also have a mobile app.  Or let's say let me take a step back. You have one API that is also consumed on the web as well as on the app side.  Like for example, if the website allows you to store credit card information, the website only shows the last four digits of the credit card number.  Right. And these inconsistencies can introduce a lot of problem. The reason I say that is because let's say for example on Amazon. You've seen Amazon allows you to see the last four digits of your credit card number and Apple back in the day used to use the same last four digits to verify a customer. So you can understand that something that is sensitive for Amazon is not necessarily sensitive for Apple. And as a result, this inconsistent masking then creates a lot of other privacy issues maybe outside of a product or even within your product. Patterns. You want to use different character sets. You try to mask them on the client side. So when somebody does a right click and inspect element or a view source, you can actually see what the real text is. Unmask data that is data in log transactions. For example, in PCI, it asks you to log certain kind of financial transactions for audit purposes. And if the data is available in clear text, there's another issue from a privacy point of view. Now I have given some links which are very useful that we've used, you know, back into the place that I work where depending on whatever the technology stack is that will always have options for doing masking or, you know, implement custom field for my for my test or, you know, encrypt the columns that you consider them as sensitive. Tokenization. I would always question that whenever there is a business requirement that asks you to capture some sensitive sensitive information from our analytics point of view, these are genuine requirements for you to capture the data. Your approach should be very simple that when you want to rebuild the data set, you should always tokenize it. And when you only care about the data structure, you anonymize it. So for example, I spoke about the hackathon event. And let's say in the hackathon event, you don't need to tokenize it. You don't need to encrypt that information because it's pointless. But then you can anonymize it, which means that you can replace a passport number with a similar format, format it string, you could replace a pan card number with a similar format string. So that's how, you know, we've adopted these two simple rules, where if you want to rebuild the database, we tokenize it. If you don't care, and if you care about the data structure of the attribute, then you only simply anonymize it. Last but not the least data encryption. We've spoken about this. This is basically data in transit, data at rest. So whatever you do essentially goes inside backups, data stores, data warehouse, data lakes, etc, etc. The most common mistakes that I've often seen, you know, developers do is they're actually trying to encrypt, they're actually encoding some piece of data and calling it encryption. They choose the incorrect cryptography tribe. So instead of using asymmetric, they end up using symmetric. And whenever they're expected to use symmetric, they end up using asymmetric. And these do have privacy implications. I've also seen, you know, with my experience that a lot of times, because all of this knowledge is always known on the internet, developers will end up writing their own encryption routine, which is something that I would never, never encourage any developer to do because encryption algorithms have complex mathematical properties that they meet in terms of trying to protect the integrity of the data as a result they become a standard. So if you ever come up with something that does not meet that same level of standard is not worth, you know, spending your time on it. The other bit from a privacy part of you that I've often seen as a challenge is, you know, you can't have 100% security and have 100% privacy, and I'm absolutely no convenience. So it's always a balanced call between what is right, what is wrong, and which is where you can draw a ground or a middle line saying, you know, this is where you would want to stop and not normalizing it and other, you know, stay with the denormalized part. So this is my last slide. Hopefully, yes. I mean, I want you guys to look at a very high level process that we think works very well for us. So for example, to the left, you are seeing an autonomous team, which is basically having representations from different parts of your organization. All of these people come together and they carry out an activity that we call as data cataloging or data classification, which means you've identified the data that is important from a privacy point of view and then you've also classified that data. And then eventually you feed all of this back into data governance framework. And you will see that the lines are, you know, both ways, arrows are both ways, which means that this is, you know, a bi-directional process. And then you see continuous assurance at the top, which essentially means that while all of this is always going to be a moving target, continuous assurance is just like a feedback loop that you often are doing the right audits or you're trying to raise or identify different blind spots through the life of the data itself. Lessons learned, this is really, really my last slide. Catalog all your data, it's very important. You cannot protect anything that you don't know. Discover privacy related data in your existing systems. This is a very, very important activity and there are a lot of tools available on the internet. Something that I personally use is NASA's to be able to identify systems data. Don't store the data that you don't need. Once you've cataloged all your data and once you've created a framework, define technical controls to protect sensitive data. And the continuous assurance that you saw here is basically summarized in this line, which is build, measure, learn, feedback and loop. And from in a privacy world, it's very, very important that you trust, but at the same time you also verify. And the only way to verify is to have continuous assurance. All right, guys. So that's pretty much it that I had to share with you guys today. So thank you for the opportunity to discuss topics, article on privacy and unstructured data. I think it's a great starting point. And Hasgeet is doing the right thing by actually reaching out to community members like Scribble Data to be able to comment on the article. This requires wider conversation. And I want to bring one dimension which has, which provides the context for the whole topics article. And that is on the economics of the privacy, because the question is, why should the companies care about all of these, right? And I want to first mention two, three points about what is the nature of the problem that we are dealing with and why topics article and approaches that we discussed actually makes sense. So the first point that I want to make here is that the cost of generating data and sticking it in email or S3 and so on is almost zero. The cost of discovering, managing, cleaning, organizing all of this information is very high. So every organization is now dealing with this cost asymmetry in the world and this problem is only going to get worse and worse unless you apply ideas, approaches, principles to deal with the problem. The second thing, the second point about this particular problem space is that it's actually a long tail of problems. Even something as simple as anonymization is very data dependent, very context dependent, use case dependent and skill level dependent. It is not a simple decision to make and that is inherent in the nature of this space, which is that it's a long tail of complicated problems which can absorb any amount of FTE that you can throw at it. Simple techniques are not going to work, right? So you're looking at both investing in tooling, processes, education, applications and so on. The third dimension of economics that I want to highlight here is that the cost of cleaning up any bit of data only increases dramatically with time. It is that is inherent in the nature because you start losing a lot of context and a lot of work needs to just is required to just rebuild the context so that you know what is the appropriate action to take in any given situation. So in general what we are dealing with is very tough economics and today, then as we go through our organizational processes every day, we tend to externalize a lot of this cost. We just explore data and send it over email to somebody without realizing that the organization has to pay the privacy costs one way or other in the form of leak data or in the form of compliance sometime later on. So we have to figure out a way to fundamentally alter this economics, the trajectory on which the privacy economics is so that it becomes manageable in the organization and there are two, three base of doing it. First is by providing the right kind of tooling. For example, if the person is actually exporting data and sending over email. There is a need for a sharing interface somewhere, maybe constructing of cohort and sharing maybe the way to do this is to create a small application which eliminates the need to share. That is the first problem or have a very structured exporting interfaces which makes sure that the data that is going out is actually kosher. Interestingly, feature store was initially meant for machine learning applications. Increasingly what we are finding is that there are privacy applications. Also, as it became clearer, we became more and more privacy conscious. One of the big reasons they want to put a feature store between the raw data and the end users so that the data set that is being consumed is actually kosher from multiple angles from a privacy risk and other angles. The second point that we're that I want to make is that we eventually have to acknowledge and explicitly manage this cost. And here, initially I used to think of SOC to GDPR all of them as a burden, but today what the way I see them is that they're actually a forcing function. They force you to ask tough questions that you have always been postponing and they force you to have an at an individual accountability, right, because ultimately the CEO is signing off ultimately the CISO is signing off on all this. That means that now there is an individual anytime you have a workflow this individual will actually ask questions about why you're doing and whether there are better ways of doing it. There's a way to externalize the order to to surface the hidden costs in your day to day data processes. This is a longer conversation. I think I would love to see expansion of the article by coffee there are several threads that could be developed not just on the technical mechanisms like the tokenization and the API security and so on, but also on the other elements like catalog discovery governance flows and things like that. And I think the big thing that I am, I am looking for is that while in larger organizations that are specific teams to deal with all of these. I'm looking for ideas for how smaller companies can cope with this problem space, which much less resource need through clever thinking through planning ahead of time, having the discipline into and discipline in their tools as well as processes So looking forward to more from topic as well as this particular thread within has cake itself. Thanks for the opportunity to discuss the article.


In the last video on classification trees, I mentioned the predictive behavior of a model, by which I basically just meant my model's accuracy. So today I'll explore this a little bit more. Now, just like last time, I'll use the iris dataset. I'll feed it into a classification tree to develop a model, and then I can send both my data and this model to predictions, to see how well it performs. Now, the predictions widget displays the predictions and corresponding probabilities of my classification tree, along with the error rate. Now, in the case of trees, these probabilities are based on the class distribution in the leaf nodes. So, I'll go ahead and open the widget, make the first column a little bit wider, and sort the table by prediction error. A classification tree predicts the probabilities of each class, then chooses the most likely one. So, at the top of this table, we see it predicted the iris was a versicolor with a 98% probability. But in reality, the flower was a virginica. Now, there are also a couple more errors of this kind. In the second row, a versicolor was misclassified as a virginica, and in the third row, a virginica was misclassified as a versicolor. But other than that, the classifications were fine. In a dataset of 150 irises, there were three misclassifications. So now, we can work out the overall classification accuracy of this model. We want to divide the number of correct classification with the total number of instances. So 150 minus 3 divided by 150. This works out to be exactly 98%. The same number as the classification accuracy shown at the bottom of the widget. Pretty good. So, now we can go to the flower shop, and we'll only have a 2% chance of guessing our irises wrong. So moving on, let's try plotting our results to get a better overview. First, I want to see the output predictions in the distributions widget. I'll choose to display the predicted class and split the columns by the true class. Now, this graph also shows that the tree mostly made the right choice, and that it correctly predicted every single sitosa. When predicting versicolors, it made two mistakes, and then another mistake when predicting virginicas. Okay, great. These results all indicate that the tree did pretty well. But now it's time to experiment a little bit. So, I'll completely mess up the data just to see what happens. And by mess up the data, I of course mean I'll shuffle the class column. This will emulate a clueless botanist like myself. Because I could measure the petal and sepal leaves, so I'll leave those intact, but I have no clue about the species, so I'll just randomly assign one to each of the irises. In orange, I can do this by feeding my data to the randomize widget. Now remember, the original data was clustered nicely on a petal length petal width scatterplot. But take a look at what happens when I randomize the class. Now to do this, I feed my scatterplot the data from the randomize widget, and I'll turn on replicable shuffling just so that everyone can get the same results. Now I see that the data points are still in the same place, but the colors tell me the classes are all over the place. Okay, so now I can build a classification tree from this data and send it over to the predictions widget. Of course, I expect the tree to perform miserably. Nobody can build a solid prediction model on random data. Now I'll quickly get rid of the scatterplot, as I don't need that anymore, and rewire the signals to use the randomize data instead. Now I can open up distributions again to see what I get. Wow, the tree got a surprising amount of flowers right. How is that even possible? Most of the predicted cytosas really are cytosas, and the same goes for diversicolors and virginicas. It almost seems like magic. Even when the input was completely randomized, it found a way to make mostly accurate predictions. Or did it? Maybe I did something wrong. I probably did. Bad data in, great model out, I don't think so. So I'll have to sort this out in my next video.


Thank you very much. So one of the for those who don't know me so well, I'm working on plasma Okay, so I work on plasma project and So getting community started working on plasmo project in 2015. It was introduced as a community project in 2015 academy The goal was the project is to full control over information of the mobile devices and communication and It should be inclusive to third party software and not like some closed-down systems like iOS and Also, same list cross-device experience or convergence as you call it and Also, we were we wanted to use the open standard switch So Today's my talk is about plasma mobile on the open devices. It doesn't actually focus much on the software side but actually more on the hardware and basically It doesn't even actually focus on the plasma mobile itself, but the the layers be below the plasma And so as a background I took liberty of copying two slides from my last year's presentation so last year's presentation I basically provided updates about my updates about work done in one year and at that time I listed out some External factors that affect the plasma by project and some of the challenges we were facing at that point so the External factors listed were physically the devices which are currently in the market have a really old Colonel wasn't it's not reasonable to support them For example, lots of people here will have a Nexus 5 which supports a 3.4 Colonel. So, yeah, that's a ancient Colonel and We also have a lack of open devices the devices where we don't have some kind of device schematics and Where you don't really know what's happening behind the scenes So that makes it really hard to put something totally different than than what manufacturer wanted to put on that device and Also, like those devices requires a closed-source binary blobs and PSP's to function and so this is a this was a External factors and Also, I listed out some of the open devices or the programs which were Which were known at that point The one is open devices program by Sony where they are basically trying to open source as much as they can other program is the It's a community effort to support as much as men line Do I as much as devices we can support in the main line Linux Colonel and There is also fair phone which provides open device schematics and and Basically, you can replace the parts of it yourself and Also, of course, it was a question mark at that point because it was merely a rumor that Purism will be building a Linux phone. But of course, it's not no longer a question mark. So that question mark should not be there So back to present So back to in this one year we had to work with the several projects and several community members and several corporations as well to To get To make it easier for open software to be present on the mobile devices It's entirely basically not structured effort like it. So basically different contributors working on totally different issues and trying to solve it so When it comes to the off the self devices, which are currently in the market Those comes with the old kernel version, but the Linux kernel have a But in theory it can be put it can be supported by the current main line kernel version just you need to do some work to add Socy system supporting the for example, Colonel if it's that you need to you need to add to hardware supports and so basically One of some of the Factors are DRM and GPU drivers. For example, there is a There is a free trainer project to which is reverse engineer driver for the adrino welcome devices There are Wi-Fi and Bluetooth drivers, which needs to be open sourced into mainline kernel And of course, that is the phone part, which is the modern and telephony So for that there is a project called Ophono, which we use in plus mobile. So more and more Drivers should be added into Ophono and Also, there is a Well every hardware in the mobile for example camera sensors and everything So well, I'm at that point it was the next in the past year we Had supported many Qualcomm devices with the mainline kernel You might have read my blog post in planet.qt.org so the Qualcomm devices basically The idea came to my mind when well, basically I was starting to work on plasma mobile That was a blog post by John Which is so that Nexus 7 2013 model was running 2013 model was running a mainline kernel and the Android So I thought like if it's a mainline kernel we will have an open drivers and in theory plasma mobile could work online and Of course, I had no access to Nexus 7 2013 model or that it was it was not easily available to It was not easily available in market anyway but I had an access fire device which was a reference device for plasma mobile at one point and And So I Got excited about this and like started reading up on various things and so I learned that Nexus 5 have a MSM8974 board and it was already supported to some level in into mainline kernel for So I try started by Like how can I add support for Nexus 5 into mainline kernel? Of course, that that that was a bigger technical challenge than I Did that was a really bigger technical challenge and then like it was a bigger bite than I could chew So well, I added some support Well, some support is basically you get a kernel log over the headphone jack and You can place the volume buttons, but that's of course not usable for plasma mobile So Well, due to lack of time and lack of proper knowledge. I basically serve that project but In this in past year one of the other community members managed to actually extend the work I have done and they actually managed to run a Fully mainline kernel and so with the graphics and Wi-Fi wireless and the support on the plus mobile and Then with the help of the community members we We started building a tabian based system which can run along with this mainline kernel work done by the by the community members So it was essentially thanks to people who are working on it and the communities like post market OS and Tabian community which was possible Thanks to them and those developers have now managed to port More and more two voices. So which is Sony Xperia Z2 and there is also Serious for which I'm not exactly sure of the model number and There is actually there is a so basically now we have a experimental Experimental branch experimental root file system, which can be done on such devices which we have which are already mainline It uses a fully open source mass abstract instead of the hacked up live hybrids and Hacked up live hybrids So it's a great to have such a open devices in the market and Also like you might have you might know this already so a caddy community partner with the tourism to build a build a live room five and agreed upon to and We part the tourism computers rain a Campaign which was successful and The caddy community agreed to support plus mobile on Libram five So it's expected to see pin January 2019 and it it also uses a fully mainline Kernel and fully open source drivers and in addition to that it also supports a Kills which is concept which is essential to privacy and security Goal V as a caddy community have set up So I Talked about devices and here are some of the pictures So it's a Sony Xperia's head voice I talked about it's running a Mainline Kernel version and Plasma mobile on it Then there is a neck. There is another Sony device running a post market OS and Plasma mobile and Here is another device running Plasma mobile and nexus file. Sorry not nexus file So and of course, there is a prisms development board, which is already which is also running a Plasma mobile so When we started Plasma mobile project essentially we were using lip hybrid and we were we we didn't actually explore the Opportunities to at that point we didn't actually explore the ability Possibilities to have a open devices, but now we are we are now Due to community members and the corporations. We are actually in the both position to Build upon the open devices and have a plasma while running on the search devices One of the interesting fact about such devices is it makes a development so much easier because Who is tech is so who is tech is familiar? You have a same mess our stacks. You have a same drivers. You have a same wireless drivers and you don't have to deal with the Deal with the system which which basically Where you run a Android inside the Where you run minimal Android inside the container and talk to it through various IPC and you try to convert to Cis called to Cis calls to the to the Android by my neck base system and This will also make it so much easier to have Multiple distributions to support mobile devices Currently we just have a whole for example kidney neon based root file system on the Plasma mobile but If we are we are going to follow such open standards, which are already getting used on desktop devices It will make it very easier for other distributions like tabian or our Linux or open suzay to build upon and Of course, we need a help So free you can ask you can talk to us in metrics channel plus mobile metrics dot org and Mail English. There is a platform where we're taking on We need a help on various topics. For example, mainlining such a new devices and we also need a so far we have success in running mainland control on the only Qualcomm devices, but There is effort to have a Mali based reverse engineer graphics driver Lima So we need help with such devices as well There are a lot that are there is also a community which so which can help you get started on mainlining your devices and Also, we have a post marketer's project Who have a very very good card on how to mainline your device? And Yes, before I go to the questions This is the one of the very small Thanks or if you just, you know, physically trying to restrict the work that you're doing, and I think it's okay to get your company ready if you are committed to a lot of such kind of talking, like if you don't like the search, you can't do much more than what you can as well, and you can't proceed with your own work, or you can't as well proceed with your third party. Yeah, so, we don't have any questions. We have a question for you. If I recall correctly, the login image Google does actually has a space on a contract, so it can't be done without an option of an intro card, which don't have to be opened. Which don't force to use Google's search results. Yes, I would like to, but still, if you know that the system is equalized with the system directly from the Google itself, and the entire folks and folks of folks will be rewardless, and there's no question about the actual end processes, but the main ones meet each other at the same, if they want to. So, I think it's important to get an introduction. I'm a little bit confused about the main Plasma mobile, and maybe what's a lot I've seen today is, it sounds very low level in its stuff, not much about actual Plasma. What do you do with focus sizes also while working with Plasma? Well, as a Plasma worker, I was kind of hoping to see, you know, how does Plasma work on mobile devices currently. So, for the Plasma mobile, it's a basically a system, and set up a very nice way to do that, which basically allows us to, basically allows us to store the mobile, for example, off Google, and then there's the server, the server and the user interface server, which servers most of the 90% of all the Plasma that is a shared protocol, and then we also have a Kiribati, which is sort of, which is sort of, you know, for any part of your applications, which can be used even on the end of your iOS, or even on the desktop. So, for Plasma mobile, it's basically a Plasma OS, so you know how to use your own desktop and it doesn't actually change very much. It's just a question, you know, and you can use this time of the month. Yeah, right. All right, do we have any more questions? I'm wondering if two things, actually, maybe you meant the Sony Xperia X device, which with the unknown set, because for that one, the hardware is pretty open. Sony documented a lot of stuff, and I'm also wondering, do you think about joining efforts with the Sadelfish people? About joining efforts with the Selfish West people, I think in the past, I mean, like it's a thing of past year, we started a collaborative effort with the Selfish West and Nemo Mobile and Ubuntu Touch people, which is called Halium. It's a separate to Plasma Mobile. So, it works on a solution to use... So, it works on a solution to use Plasma Mobile on basically this old hardware, where the only Android can be used. So, yes, we are basically collaborating with the Selfish West, but as far as I am aware, they are not putting any effort in the mainlining devices, basically. So, my current presentation was about the mainlining device. So, basically, you get to use very recent, kind of like 4.18 or 4.19, and not the vendor provided 4.4 or 4.9. Are we on time or...? So, there's a reason why he talks a lot about Linux low-level stuff and why he's in charge of that and why there's this sort of weird separation of where does the Plasma stop and where does the Mobile end, right? So, I hack on Plasma. The way Plasma is architected is that we have a single executable called Plasma Shell, which loads the rest of the UI from a package, which means if you have a system that has Plasma Shell installed on it, as a third-party, you can install an entire different UI into that system, right? So, this is then why we call Plasma Desktop and Plasma Mobile, not because we like lots of keystrokes, but because in our minds, those are kind of separate. Plasma is the runtime that enables you to write UI targeting a specific form factor, and Desktop, for example, is a project that implements a desktop UI for that, and Plasma Mobile is two things. It's also a project to implement a device-specific user interface, and also our effort to bring the Plasma runtime to mobile devices and all of the steps that go into that, like device image creation and so on, which he is the expert for, which is kind of why he focuses on that. Now, under your eyes, side of things, some of the things we've done in the last year are we had an optimization sprint where we worked very hard on making this runtime more performant on low-powered ARM hardware. For example, the target device we started with at the start of that sprint, which was for a week, from pressing the Power button to getting the UI at the time, we took 34 seconds. At the end of the sprint, it was down to 12 or something like that, and we cut memory usage by, I think, 150 megabytes and stuff like that. So on the runtime side of things, we've worked very hard to target a lower-power envelope. Then a lot of the work that we're doing right now are in Kirigami. Kirigami is a KDE framework. It's a user interface toolkit that extends Qt and Qt Quick. What Kirigami provides is stuff to make your applications convergent, which means that with one code base you can target both a desktop and a mobile form factor. And we've been working, for example, on porting KDE's system settings application to Kirigami and all the modules in there to make them available on Plasma Mobile. We also see more and more of our KDE applications port to Kirigami or add Kirigami-based interfaces. So as time goes on, more and more applications pop up on the Plasma Mobile device image and become more usable on the mobile form factor. As for the shell specifically, there has been some polish. It needs much more work, for sure. So the way it works is that Plasma is very, very plug-in oriented. Everything that you see on screen is in fact a plug-in. Even the notion that you have a desktop, for example, on the desktop or that you have a panel is provided by a plug-in. The plug-ins are made aware of their constraints and they can adapt to them. This gives you the ability to do something like use one code base to provide desktop icons but also have a file pop-up on your panel, right? So what we do is we reuse some of the existing UI bits we have on the desktop in the mobile shell, like, for example, the network manager UI to pick your Wi-Fi or pick your connection is reused in the mobile shell to the form factor a bit. What this has given us is a usable basic system that shares a lot of code. It needs a lot more work to be polished specifically at form factor, which the framework allows for. You can, on a file basis and on a sort of per UI screen basis, you can swap in form factor-specific URL files. And that's work that is ongoing as well. So that's like a short overview of what's going on on the UI side. And I think we're very excited to see more and more apps work on the mobile form factor. And as they pick up Kirigami to do that, Kirigami also gets better, which then creates this fortuitous cycle where it becomes more and more appealing to port your application to Kirigami. Okay, thank you very much. It was very interesting in my mind. We have a plasmobile buff on the Monday. So if you want, you can stop by. It's at room 122 at 10.30.