[SOUND] In this segment, which is optional, I want to continue our discussion of the benefits of not being able to mutate, mutate data by showing you an example in Java. So, as I said at the end of the previous segment, in ML, we can create aliases and not worry about one of those aliases causing an update, being used for an update that then effects other aliases. But in languages like Java, we really have to be careful about where we create aliases versus where we make copies. So, the example that I have here I've simplified so it fits on the slide, but this is the exact idea behind bugs that until they were fixed, caused real security violations in real Java libraries, including things in the standard Java library related to class loaders and other things. So, let me walk through what I'm trying to capture, the, the basic idea here. So, I have some resource, which I'll put in the field the resource, and I don't want everyone to access this. I really want this to be private. So, I've used this private field, it should be hidden, I'm not going to let anyone use it, just anyone. But I want some people to be able to access it, and so I'll have something reminiscent of say, passwords. So, the allowed users will just be in this array of strings. So, if someone is in that list, then they can use the resource and if not, if they try to use the resource, I'm going to raise an exception. Now, I'm happy to let everyone know who is allowed to use the resource. That's not secret, just the contents of the resource are. So, I have this method, get allowed users, that will return the string array. So, you can see who the users are, you can even see if you're in the list so you're allowed to use it. Could even find out the current user. So, maybe when the code is executing, there's some notion of a current user. So, that allows the, the main method here, if you will use the resource to do the right thing. So, what it's going to do is for every element of the allowed user's array, it's going to see if the current user is the same string as in the i-th position of allowed users. And so, if you find the current user in that array, then go ahead allow access use the resource in whatever way your supposed to. Otherwise, if this for loop actually finishes without returning here in this if statement, then throw an exception, okay? So, it turns out, this code probably makes sense to you. I encourage you to figure out how it's in fact insecure and it would let any user who's just a little bit clever to actually use the resource whether they're supposed to or not. So I'm going to tell you the answer in a few seconds. Click pause if you want. And don't be too tough on yourself if you can't find the bug since a lot of other people, including the people who have written code like this, have made the same mistake. Okay? Ready? Here we go. The get allowed users method returns an alias to the array, right? So, all a malicious user has to do is call get aloud users to get an alias to the array and then update one of the elements of the array, say position zero, to be the current user. Then, if you call use the resource, I guarantee that name will be in the array. So, clicking back here to the previous slide, the error's in fact not in use the resource. That's doing exactly the right thing. It's in get allowed users for leaking an alias to the allowed users array. It's sort of is like, I assume that clients were only going to read this result. And in a language that didn't allow you to mutate array elements, that would be a fine assumption. But java is not such a language. And so, clients can do something like this. And then, they'd be able to access the resource whether they were supposed to or not. And so the fix which Java programmers have to remember to do, they get no help from the language or the type system unless they use final in the right place or try to use libraries that encapsulate this idea, is to change that get allowed users method to return a copy of allowed users. You have to copy the array so that what's given back to clients can no way update the internal representation of our private resource object which then causes use the resource to do the wrong thing. So, if that's tough to reason about, I agree with you. I find the simplest way to avoid reasoning about that, to get rid of mutation for most of the data in my program. But if you prefer to have mutation, then you get to be in the business of writing your program such that you have copies in all the right places.