Kiril Seksenov is the Senior Director of Product Management here at Salesforce. In this episode, Kiril discusses Lightning Web Security (LWS), our next-generation security architecture, which will eventually replace the current Lightning Locker service. Find out what that means for you as developers and how we’re keeping JavaScript secure using standards. 

Kiril previously worked at Microsoft. Wanting to move up the stack and start building on the platform he had been helping develop over the past seven years, Kiril started exploring roles and found an amazing opportunity at Salesforce. Tune in to hear how Salesforce is leveraging web standards to create a faster and more secure web experience.

Show Highlights:

  • The elevator pitch for Lightning Web Security
  • How the Locker service pushed this evolution
  • Challenges in the Lightning component framework
  • Ensuring components are isolated in sandbox
  • The notion of distortions on top of existing APIs
  • Isolating code execution through JavaScript sandboxes
  • Considerations for enabling Lightning Web Security
  • How enabling LWS makes components run faster

Links:

Episode Transcript

Kiril Seksenov:
Was really, really interested in creating games. Like I remember learning Java, being a teenager and using Java Swing and creating like little square football game or something like that. So that was kind of my first encounter.

Josh Birk:
That is Kiril Seksenov, the senior director of product management here at Salesforce. I’m Josh Birk, your host of the Salesforce Developer Podcast, and here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Carol about lightning web security, an update to our old friend the Locker Service. And what that means for you as developers and how we’re keeping JavaScripts secure using standards. But as usual, we are going to start with his early years.

Kiril Seksenov:
Yes. So I was in college and that was heavily on the coding front. I have a computer science degree, lots and lots of programming there. And then it was time to kind look at internships and what I wanted to do professionally outside of school. And I remember looking at the kind of available jobs at different tech companies, and one that stood out to me was from Microsoft, because you could go directly from college and become a product manager. There were three tracks you could go into at that time. It was program or product management, just your standard software development. And then also the testing or software developer and test track. And I knew I loved to code, but I also loved to build products kind of in a broader sense, or rather than just working on individual features. That really fascinated me, and that’s kind of what pushed me to choose that track. And then I was very fortunate and lucky enough to land an internship there at Microsoft. And then the rest kind of just followed. I ended up working there full time after I graduated from college.

Josh Birk:
Nice. Was that the associate product manager program?

Kiril Seksenov:
It’s not an APM program. It’s similar to that, but it’s not as much of a rotational program. I wish they actually had a rotational program at that time. I think that would’ve been really cool. And I’m a little jealous of the APMs that come in today.

Josh Birk:
Okay.

Kiril Seksenov:
But no, you were with one team. Although I changed so many teams in my first kind of year starting out, I felt like I did get an APM experience.

Josh Birk:
Got it. Okay. So tell me a little bit about that time at Microsoft. What kind of products were you managing?

Kiril Seksenov:
Yeah, so I started out working on a team that was under our cloud business, and it was Connected Car. We were working with partners like Ford and other automakers, other OEMs, to figure out the future vision of Connected Car and how cars would be connected to the cloud. All that good stuff. And that was super interesting to me because I’m also a pretty big car fan. So loved working there, but I’ve always had an interest in the web, and I’ve loved web development because it was so… Easy is kind of the wrong word here, but so approachable, right?

Josh Birk:
Yes.

Kiril Seksenov:
Anyone with a browser could flip open a console and you could write some script and see things happen. Right? And that’s kind of what I loved about it. And I wanted to learn more about the web. I honestly didn’t know much at the time, I was kind of just diving in. And it was right around the time when Microsoft started developing the Edge browser. So moving away from Internet Explorer. I saw it as an opportunity of like, oh wow, maybe we can go gain some market share and do some good on the web. So that’s when I started working on the web and had the opportunity to join the Edge team over there.

Josh Birk:
That’s awesome. And how exactly did we steal you away from that show?

Kiril Seksenov:
Yeah, a good question too. So I had been working on the web platform for a number of years. Probably six, seven years at that point, working with the W3C the TC39, all the standards bodies, kind of evolving standards. I’d followed through the Edge journey ever since it was a proprietary kind of Edge HTML engine. Until I think the first kind of Canary build of the Chromium Edge was shipped.

Josh Birk:
Gotcha.

Kiril Seksenov:
So I was involved in that. And then around that time, I really wanted to move up the stack and actually start building on the platform that I had been helping develop over the past, whatever, six or seven years. So I started exploring roles there, and Salesforce was an amazing opportunity. It was in the platform space, which I know and love, but it was actually developing an enterprise grade solution or application, rather than just building platform for the sake of building platform.

Josh Birk:
Got it. I just have to ask this because the story overlaps so much, did any of your time overlap with Greg Whitworth?

Kiril Seksenov:
Yes.

Josh Birk:
Okay.

Kiril Seksenov:
Yes. Greg and I, a lot of it actually. So Greg and I worked on different, what I would call sister teams over there at Microsoft.

Josh Birk:
Got it.

Kiril Seksenov:
Very differently. Yeah, we’ve worked together for a while.

Josh Birk:
Okay. And I ask this of all product manager speakers. I love the variance of the answers I get. How would you describe your current job?

Kiril Seksenov:
That’s another really good question. I have an interesting current job, I guess.

Josh Birk:
Nice.

Kiril Seksenov:
The one thing that has stuck with me is, talking about what do product managers do? And it’s almost like herding cats. And I think we were talking about your cat before this started. So I’ll use that analogy.

Josh Birk:
Nice.

Kiril Seksenov:
And there’s so much variance in my role today. I run teams from the security aspect, to data, to enablement. So it’s very interesting. It’s never the same. And there are always different, unique problems that need to be solved or addressed. And a lot of the time you, as a PM, aren’t always going to be the subject matter expert. Especially as you grow and take on more and more teams, or more and more projects. So it’s almost like herding cats. It’s getting the right people in the room who may be smarter than you to make the call on how to solve particular challenges. That’s how I’d describe my job, I think.

Josh Birk:
Nice. Nice. Okay. Well, let’s get to that product that we have on the title of the episode. What’s the high level elevator pitch for Lightning Web Security.

Kiril Seksenov:
Yeah. If I were to use just two words to describe it, I would say usable security.

Josh Birk:
Oh.

Kiril Seksenov:
And the elevator pitch for Lightning Web Security is it provides you that strong security posture while not getting in your way and prohibiting you from accessing functionality and features that you need to build out your scenarios. And that’s where we really began with the vision of Lightning Web Security. So Lightning Web Security is our next generation security architecture. We used to have Lightning Locker prior, and it offered a very similar level of protection in terms of client side attacks. However, it also prevented a lot of developer functionality that you’d expect to work on the web. So things like cross namespace communication did not work. A lot of third party libraries were just broken because we used this notion of secure wrappers with Lightning Locker.

Kiril Seksenov:
With Lightning Web Security, we went back to the drawing board and we revisited the standards that were available in the web today, right? The web is always evolving. So we decided to build Lightning Web Standards, or Lightning Web Security for them, sorry, in accordance with standards. So we took a look at what was available and at times what was kind of in the inception phase, even from a standards perspective. Like today, we’re still influencing the shadow realm standard, pushing that with browser vendors to create even stronger and more secure sandboxes in the future. And in the meantime, we’re leveraging other standards within the TC39 to create this Lightning Web Security product in this new usable security architecture that gives developers the same level of security as Lightning Walker, while also enabling all this functionality that was prohibited in the past. And I think that’s the superpower or elevator pitch of Lightning Web Security.

Josh Birk:
Nice. Okay. So digging into a few things there, first of all, your quote unquote slip is somewhat accurate though, right? We’ve been involved in crafting these standards and watching their evolution as well. Right? Salesforce is sort of in the same room as Microsoft and [Zillow 00:09:14], all these players as the stuff is moving forward, is that right?

Kiril Seksenov:
Totally. Yeah. And it’s funny, I’m a little glad I had that slip and mentioned standards in there, because yeah, we’re not doing anything proprietary here.

Josh Birk:
Yeah.

Kiril Seksenov:
This isn’t kind of almost what Salesforce has done in the past. This is looking forward and partnering with folks like Google, Microsoft, and Apple. And then other third party vendors, like Igalia who go and help with these standards and help implement them in different browser engines. So yeah, we’ve been participating in the TC39 meetings and the W3C forums. And I think all of those browser vendors have been hearing our challenges. They’ve also have been letting us speak, because coming from that background, a lot of the time you don’t get a lot of customer input, you know?

Josh Birk:
Right.

Kiril Seksenov:
And in order to shape the web, you need to know what customers are building and what they want to build in the future as well.

Josh Birk:
Right. And so, you can actually use Locker Service as like an example of a shim to a company that could try to put that into a browser as a beta, and then get rid of the shim and get the advantages that you were just talking to. So, is it a true statement to say locker service, helped push this evolution forward?

Kiril Seksenov:
Yeah. Yeah. That’s a completely accurate statement, and it was novel at its time when it was created. Because something like it didn’t really exist or it might have existed, but it had the similar challenges and drawbacks. But it’s really difficult to predict what those drawbacks and challenges are going to be before you develop the product. Right?

Josh Birk:
Right.

Kiril Seksenov:
And that’s what really helped us influence how we want to build this new product, Lightning Web Security, and also discover what kind of evolution we would need from the standards themselves and what we would need in browsers in order to build this technology and build this product.

Josh Birk:
Right. And maybe we should take things up a level. And I’m trying to remember the episode that this has come up in the past, but can you kind of walk me through why Salesforce is kind of, I mean, it’s not a unique challenge, but what are the challenges that are lighting [inaudible 00:11:36] framework in our style of UI bring to trying to make a very secure environment that’s also very developer friendly.

Kiril Seksenov:
Let me just make sure I understand the question that you’re kind of prompting for. So some of the challenges that we have are the unique ecosystem that.

Josh Birk:
Yeah.

Kiril Seksenov:
Or the ecosystem that we have and need to solve challenges for.

Josh Birk:
Yeah. We aren’t just delivering a single page off of a single, Salesforce has this interface, this is what you get. We are giving you this highly componentized, highly customizable library of things that you can put into a UI.

Kiril Seksenov:
Totally.

Josh Birk:
And some of those things might want to talk to each other. And some of those things might not want anything to talk them.

Kiril Seksenov:
Exactly. Yeah. Yeah. So we have a pretty heterogeneous mixture of components that all sit in one page, right? And that’s kind of our unique challenge. It’s also very positive, because we offer this highly customizable platform that any customer can take and kind of mold to whatever they want.

Josh Birk:
Yeah.

Kiril Seksenov:
But that also presents the challenge that you were describing. Like we have these pages and the lightning experiences and the lightning experience that have components from many different authors. We have the Salesforce authored standard components that are on the Lightning namespace. We allow customers either through low-code customization or pro-code, go and create components that they can then install in their org that run in the CNAME space. And then we also have this amazing third party thriving community with AppExchange, where our customer can go either download and install a free component or purchase a component. And then many of our customers, some of our large customers work with other third party ISVs, right, that produce custom components just for them.

Kiril Seksenov:
So we have this mixture of namespaces all coexisting on the same page. And we also house very, very critical and sensitive customer data. A lot of the time, for example, a customer doesn’t want a credit card entry or component of one of their users or one of their customers to share that data with another map component that’s sitting on the page, let’s say. Right? Or some other third party component that was installed from AppExchange with a not so verified partner. So that’s where Lightning Web Security comes in. And that’s kind of the challenge we need to solve for. We need to ensure that our components are isolated IN sandbox so that a non-malicious component can’t inadvertently reach in and pull out customer sensitive data, or even worse, a malicious component or malicious player comes in and tries to actively do this. And we need to prevent those scenarios and uphold their number one value, which is trust.

Josh Birk:
Right. Well, let’s talk a little bit about how Locker tried to solve those problems. When you say that it used the concept of a wrapper, does that mean it was taking something in a namespace and obscuring it from the other namespaces? What was its particular trick, [it’s a show 00:14:39]?

Kiril Seksenov:
Yeah, so it did these wrappers or shims around the document element in Window Global Objects.

Josh Birk:
Got it.

Kiril Seksenov:
And then it would do this thing called namespace keying, where it would look at the DOM and key these objects based on namespace, and then only offer access within one namespace. Now, the problem there was, as with any wrapper or shim, it was like playing a game whackamole, because as the web evolved, we had to recreate our own metadata system. It’s almost like we had our own DOM mapping and metadata of objects on what we would expose to different namespaces. And it’s just impossible to keep up with, right?

Josh Birk:
Right.

Kiril Seksenov:
The web is changing at all times and we would get reports of new libraries being broken because some new web functionality came out and we just forgot to add the metadata for it.

Josh Birk:
Yeah.

Kiril Seksenov:
But it was just really hard for us to know. Yeah. And that’s kind of where that architecture felt flat with the secure wrappers.

Josh Birk:
Yeah, because as any JavaScript developer knows, objects like window and document are very simple, don’t change very often, and people very infrequently use them.

Kiril Seksenov:
Correct.

Josh Birk:
Or not.

Kiril Seksenov:
Correct. Right? No one ever uses that.

Josh Birk:
I mean, I’m trying to think of an example where I didn’t at least use document dot something.

Kiril Seksenov:
Right. Right.

Josh Birk:
That’s almost the whole point of modern JavaScript is to go tell the document what to do.

Kiril Seksenov:
Exactly. Exactly. And then even if you think you’re not using it, some library that you’ve included on the page, or some framework that you’re using is indirectly using it. Some two abstraction layers below. So there’s not much that you can do, you’re absolutely right, without accessing the document [inaudible 00:16:35].

Josh Birk:
So then is the solution by moving it to standards meaning it solves that problem, because it gets you out of the business, because the browser’s always going to know what the document’s doing. So the documented window are just behaving as they should be normally now.

Kiril Seksenov:
Yeah, exactly. So what we do now is we actually give you access to your own global Window document and element objects. Right? And everything in that prototype chain. However, we proxy and restrict some things based on namespace. And that’s where a new notion that we’re introducing called distortions comes in.

Josh Birk:
Okay.

Kiril Seksenov:
And these distortions are basically implementations on top of existing APIs and they distort those or that API’s behavior. So just to use a concrete example, because I think it would be easier.

Josh Birk:
Yeah.

Kiril Seksenov:
Let’s say the cookie, getting access to the cookie object. Right?

Josh Birk:
Right.

Kiril Seksenov:
And using things on-

Josh Birk:
Another object that’s very simple and infrequently used.

Kiril Seksenov:
Very simple. No one uses it.

Josh Birk:
Yeah. Yeah.

Kiril Seksenov:
We give you full access to the cookie object. However, we distort it.

Josh Birk:
Okay.

Kiril Seksenov:
So, to your namespace, it looks like it’s the global cookie object. You can write cookies to it. You can access cookies to from it, but they’re only cookies that your namespace has written, or that are accessible to your namespace. You can’t access the global cookies or cookies written by another namespace. So that’s one good example of how our distortions work on those APIs.

Josh Birk:
Gotcha. I’ve just kind of seen the term thrown around, how do JavaScript sandboxes play into that?

Kiril Seksenov:
Yeah. So JavaScript sandboxes are another method of isolating kind of code execution.

Josh Birk:
Okay.

Kiril Seksenov:
And the full on standard, if anyone wants to go follow it through the TC39, it’s called shadow realms. It’s actually actively being worked on within web kit and chromium as well, but creating one of these shadow realms, which is almost very similar to what we’re doing today, except we’re using what’s available in the platform currently, which are kind of detached eye frames. It just gives you a JavaScript’s execution context. And we do this per name space. So once again, if you’re executing code, you get your own access to global Window document element objects, but they’re within your namespace.

Josh Birk:
Got it.

Kiril Seksenov:
So if you modify any of the behavior, if you create anything new, that’s only within your namespace, it’s not shared across name spaces. However, the key thing here is that because we’re using these secure code execution context for each namespace, you can now import modules across namespaces, which is another huge win for Lightning Web Security.

Josh Birk:
Yeah.

Kiril Seksenov:
In the past for LWC, you couldn’t do this.

Josh Birk:
Yeah.

Kiril Seksenov:
You couldn’t. I think the term kind of coined on the idea exchange was cross namespace communication. And a lot of our customers want to do this. They want to share code across namespaces because a lot of the time they own the multiple different name spaces and they weren’t able to do that with LWC in the past. However, with Lightning Web Security, they can import modules across namespaces, and it’s all secure imports. You hit a proxy of the module, you can play around with it. You can make changes to it, however you’d like, and that doesn’t negatively or adversely impact the namespace you imported that module from.

Josh Birk:
Got it. Nice. I also just have to say, I want to know who gave it the name shadow realms, because that’s a really cool name, and I think I’ve played that role playing game before. So, but serious, is shadow realms named that because it’s like related to the shadow DOM, like it’s that concept, but placed into the namespace theory?

Kiril Seksenov:
Yeah. Yeah. We’re kind of like the JavaScript context theory. So it’s funny you ask. That name kind of evolved. The original name when the standard was in draft form was realms. However, that was a bit too generic, and then folks wanted to also connect it to shadow DOM itself, right?

Josh Birk:
There you go.

Kiril Seksenov:
With web components and different namespaces for components. So shadow realms came into play, which is also a name from a role playing game that you’re calling out to. So it’s a win-win.

Josh Birk:
Nice, nice. Okay, So with Locker, there was like a lot of stuff that we kind had to know, just sort of uphand, hey, we’re trading off security for functionality, but at least it’s more secure. But just know that these things might happen. What should developers know with Lightning Web Security? I know there’s a checkbox to be like, boom, we’ve turned this on. What are other things I need to think about when I’m either writing out my components or talking to other components?

Kiril Seksenov:
Yeah, that’s a really good question. So in terms of enabling Lightning Web Security, and this is strictly speaking for Lightning Web components, we’re also working on enabling Aura components in the future, but we don’t have an exact timeframe for that yet. However, Lightning Web Security is going GA for LWC in our spring ’22 release. And if you want to enable it there, if your LWC components were running with Lightning Locker, the enablement should be pretty seamless. We don’t expect for you to see any issues. However, it’s still a new product, please don’t enable it directly in production. Enable Lightning Works Security in a pre-prod environment.

Josh Birk:
Yeah, sure.

Kiril Seksenov:
And then verify that it’s not impacting your org in a negative way.

Josh Birk:
Right.

Kiril Seksenov:
And the biggest reason I state that there is, because a lot of orgs have a mixture of Aura and LWC components. So what’ll happen is when you enable Lightning Web Security in those orgs, it’ll enable Lightning Web Security for all LWC components, but Aura components will remain on lightning locker.

Josh Birk:
Got it.

Kiril Seksenov:
And we don’t know if, in a mixed mode namespace, in a namespace that has Aura and LWC components, if that’ll create certain challenges. It very well may not. That might be the 90% case, but we don’t to break things in production, obviously.

Josh Birk:
Right.

Kiril Seksenov:
We’ve actually identified a set of orgs in the number of thousands that will be auto enabling. And that’s going through an enablement program. There’s outreach going on there, letting customers know. But throughout the spring ’22 release, we’ll be gradually turning on lending web security for those LWC only orgs.

Josh Birk:
Got it.

Kiril Seksenov:
In terms of enabling and in your own org, there’s two resources that’ll be very valuable that we’re putting out. One of them is the lending web security console. And this’ll let you execute any JavaScript code with Lightning Web Security enabled. It’s not a exact replica of an org environment. So once again, please test in [pre-prod orgs 00:23:59] before installing this component. But it’s fairly close, right?

Josh Birk:
Right.

Kiril Seksenov:
So, it should give you a pretty good sense of whether my code runs with Lightning Web Security or not.

Josh Birk:
Got it.

Kiril Seksenov:
So that’s one good tool.

Kiril Seksenov:
And then another one is a set of linting rules. Now we know that linting rules aren’t going to be a hundred percent perfect, and the JavaScript language is very dynamic. But it’s a great starting point. So you can go use these linting rules and run them on your code and see if there are any potential issues that are flagged. The linting rules themselves are covering all of our distortions. So those distortions that modify the behavior of web APIs to make them secure are covered in the linting rules. And they’ll let you know if there are any warnings or if you’re using those APIs that we’re distorting. If you do see warnings, that doesn’t mean that your scenario is broken. It very well may work. However, once again, you should test to see that it truly functions.

Josh Birk:
You know the magical hand of the shadow realms on that particular function.

Kiril Seksenov:
Yes.

Josh Birk:
Well, and to keep the theme of the jokes going on, it’s JavaScript, what could go wrong, said no developer ever.

Kiril Seksenov:
Right. Right.

Josh Birk:
Obviously mileage might vary.

Kiril Seksenov:
Said no one ever working on the [wes 00:25:25].

Josh Birk:
Right. Anybody’s been inflicted by that. And then, so sort of that same angle, but with third party libraries. Is it now sort of just like, don’t worry, but test. So now are we sort of out of having to maintain a list of like D3.JS is going to work, but this other thing isn’t going to work.

Kiril Seksenov:
Yeah, exactly. The space we want to get out of as well.

Josh Birk:
Okay.

Kiril Seksenov:
Inherently, most libraries should work. These distortions aren’t prohibiting like secure wrappers were. And we are giving you access to the global objects of document window and element. So library should function much, much better than they did with lightning locker. However, we’re still a web components based framework and we employ shadow DOM, and we have closed shadow routes. So if the library itself, and there’s still some analytics libraries out there, if you try to use that to get insights on the whole page itself, you’ll get the insights for your namespace. However, you won’t have access to the entire DOM. Right?

Josh Birk:
Oh God.

Kiril Seksenov:
So, that’s where we’ll still see some discrepancies.

Josh Birk:
Got it. You’re literally drawing on an empty canvas.

Kiril Seksenov:
Exactly.

Josh Birk:
Okay.

Kiril Seksenov:
Exactly. And we have to do that in order to uphold security. And this goes back to we have this heterogeneous mixture of components from multiple different authors, and we don’t want one name space to have access to the whole DOM and to be pulling data.

Josh Birk:
Right.

Kiril Seksenov:
And doing DOM scraping across the whole page. Right? That’s kind of…

Josh Birk:
Sort of complete antithetical to what you’re trying to get done. Yeah.

Kiril Seksenov:
Exactly.

Josh Birk:
Got it.

Kiril Seksenov:
Exactly.

Josh Birk:
Got it.

Kiril Seksenov:
Our product security teams within Salesforce would not be happy with us.

Josh Birk:
Now I think I know the answer to this, but I kind of just want to get it on tape. I read somewhere, I think on one of the slides you shared with me that enabling this actually makes components run faster. How exactly is that magic working?

Kiril Seksenov:
Yeah. So that’s another great question. So Lightning Web Security is actually built into the LWC compiler itself, or as part of the LWC compiler. So we’re already, pre-compiling the components with Lightning Web Security.

Josh Birk:
Got it.

Kiril Seksenov:
And there’s nothing happening at run time when you’re passing objects back and forth. One of the biggest issues that we had with Lightning Walker, and it was due to these secure wrappers that we had, was iterating over larger arrays, or JSON objects, because we have to pass through the secure wrapper boundary at every operation. And it was an exponential increase and impact to performance. The bigger the array got, the worse the performance got, the bigger the JSON object got, the bigger the performance hit was. And at times, it would just slow down to a halt where you couldn’t iterate over, I don’t know, a JSON object with thousands of objects in it, and I’m making those numbers up on the spot, but that’s…

Josh Birk:
Sure.

Kiril Seksenov:
Yeah, that’s kind of how it worked. However, with Lightning Web Security, that’s no longer the case.

Josh Birk:
Got it.

Kiril Seksenov:
You’re directly iterating over the object itself. So you’re getting the native performance that you would get in the web, right? And that’s a huge win. We had that reported by many customers in the past. So from a performance perspective, that’s where you’re going to see some of the biggest benefits. We’re not passing these operations over secure wrapper boundaries anymore.

Josh Birk:
All right. So enabling Lighting Web Security, easier to use third party libraries. Is there anything in my code itself, like not just the JavaScript, but within the component XML that I need to think about?

Kiril Seksenov:
No.

Josh Birk:
Okay.

Kiril Seksenov:
Not the component XML. And we tried to stay away from that to keep it less confusing for our developers and our customers.

Josh Birk:
Okay.

Kiril Seksenov:
It’s just a switch inside of your organization.

Josh Birk:
Got it.

Kiril Seksenov:
The switch that’s within the org, it’s within session settings and the security settings in there. That’s where you can enable Lightning Web Security to try it out.

Josh Birk:
Got it.

Kiril Seksenov:
It’s all kind of outlined and highlighted in our Lightning Web Security dev guide as well. If you want to go look there, but that’s what we’ll be using to toggle it on and off for orgs as well. We’ll be doing it programmatically, gradually over the spring ’22 release. But it’s the same thing that our customers have access to.

Josh Birk:
Got it.

Kiril Seksenov:
Now, the other thing to note there is that once you enable it, you have the option to disable it. So if anything were to fail or if you were to see some sort of breakage, you can go back and revert to Lightning Locker, which is also pretty good for our customers. You have the power in your hands to kind of turn it on and then turn it off if you need to.

Josh Birk:
And that’s our show. Now, before we go, I did ask after Carol’s favorite non-technical hobby, and well, it’s a little seasonal.

Kiril Seksenov:
My favorite non-technical hobby. We’re in the winter months right now, and I’m really enjoying the snow. So I’d say skiing.

Josh Birk:
Nice.

Kiril Seksenov:
But that changes depending on which time of year you ask.

Josh Birk:
Got it. What’s your favorite summer one?

Kiril Seksenov:
Summer one. Being out on the water, whether it’s paddle boarding, boating, or anything of that sort.

Josh Birk:
I thank Carol for the great conversation and information, and as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcasters. Thanks again, everybody. I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.