Hi all! Discord Employee here that was involved in the remediation of this exploit! I just wanted to clarify with a timeline, and explanation as to why we had context isolation disabled!
9:21 PM on July 16, 2020 we received a very detailed report from Masato outlining this exploit.
9:34 PM: Ticket acknowledged - and we began a deploy that would disable sketchfab embeds within the app, to remediate this known attack vector.
10:00 PM: Update pushed to stable to disable all existing sketchfab embeds.
Thanks to the detailed report, we were able to go from a report to a fix deployed to stable in ~40 minutes!
Following that, the next day we deployed a better update as we understood more about the issue (which was the sandbox attribute on the iframe.) In addition, we also paid out $5,000 for this bounty, even though the main fault that lead to RCE was due to a bug in Electron (CVE-2020-15174) which allowed for a bypass of our CSP, by allowing the main window to be navigated to a different domain.
----
As for context isolation, a lot of the code that had been written was not compatible with contextIsolation - and required significant work to refactor. For example, due to the way that objects needed to be cloned to pass through the bridge, the internal APIs that existed needed to be entirely reworked, as they were not really compatible with this model. We began this work in April shortly after we worked out all the quirks required to upgrade to Electron 7 which is when contextBridge would be available for us to turn on contextIsolation. It was not as simple as flipping a boolean from false -> true, and required a re-work of our native modules and their internal APIs, and also doing so in a way that would be backwards & forwards compatible with the various app versions that we had shipped in the wild - in addition to dealing with some performance regressions that needed work-arounds in the new context isolated world.
In August, we shipped context isolation to our Stable release channel and gave Masato the green light for disclosure - which leads us to today!
It's cool you guy fixed it so fast and deserve some good PR here for that but I'm surprised you paid out $5k for an RCE. That's unspeakably cheap for something that could have fucked over many of your users.
I work at a very small company, so small that a security researcher would never accidentally stumble on our products to test them and if my boss asked me what would be an appropriate pay out for this, I'd say easily $25k, but more likely 30-35k if we can afford it.
What you guys have accomplished here is set a precedence that you pay so little that researchers should either a) not bother with discord or b) should sell on the darknet.
As a discord app user, I'm very concerned about both of those cases.
The issue is that the bug was technically in a 3rd-party dependency:
> even though the main fault that lead to RCE was due to a bug in Electron (CVE-2020-15174)
This may seem like an irrelevant detail if you’ve never operated a bug bounty program before, but you have to consider the incentives.
Paying researchers for bugs in 3rd-party open source software creates misaligned incentives. If you’re a security researcher and you discover a security bug in Electron, you have two choices:
1) Follow proper protocol to create a CVE, coordinate a fix, and properly disclose the issue through appropriate channels.
2) Keep the vulnerability secret and unfixed while you shop it around bug bounty programs looking for kind companies who will pay out for 3rd-party issues. To maximize profits, it’s important that you keep the security issue unfixed and secret as long as possible while you work your way across bug bounty programs.
The second option is a little publicized negative externality of bug bounty programs that don’t draw the line at 3rd-party dependencies. I’ve even had bug bounty participants beg us to not fix upstream code yet because they were still trying to collect bounties from other companies.
This is also why it’s important to have your security team read every CVE immediately and check against your software. It’s also why bug bounty programs don’t pay out as much, or even at all, for security issues that come from popular 3rd-party dependencies used across the industry.
I appreciate your insight into the 3rd party aspect of BB programs but I fear you're also setting a dangerous precedant of _outsourcing liability_ from major companies to small open source devs.
If I get hacked and find out Discord was the vector, I'm not going to let them off the hook when they shrug and say "3rd party code man, it happens". In the end, I'm a discord user, I don't want RCE exploits in software I use.
If the bug was instead reported to Electron and given a CVE, Discord could have still implemented the fix. Either a workaround in their app or an upstream patch.
Given that discord chose electron as a dependency it's at least partially their responsibility. They are putting their users at risk for choosing that dependency.
Thanks for the insight, I can imagine it was quite an impressive refactoring effort!
> In addition, we also paid out $5,000 for this bounty, even though the main fault that lead to RCE was due to a bug in Electron
You seem to imply that because the bug was in a library that you use as opposed to code your own developers wrote, that it's gracious of you to even pay out $5000 for this bounty. Surely that's not actually what you're saying and I'm merely misunderstanding you? Regardless of who wrote the bug, Discord ships the binary and the impact of the vulnerability remains the same.
I'm sensing a trend in the replies here, which is that this was too low a pay out, perhaps we should have a discussion about what is a worthy payout, because we based this off of what we saw other companies paying out.
Our bug bounty page on H1 (invite only currently) lists critical vulnerabilities at $3,000 for a bounty, we decided to up the pay-out to $5,000 for the thorough report on the exploit - even though the vulnerability was not in our code, we paid extra (from our perspective...) because the vulnerability did after all ship in our software.
I compared this to similar payouts for RCE's, for example, slack paid out $1750 for a similar RCE earlier this year, due to lack of context isolation (https://hackerone.com/reports/783877) - although this did get published after we paid bounty - so it did not influence our decision.
Clearly there is some discussion to be had about what is fair. For context (which might be missing), this was not a 0-click drive-by RCE, and to exploit involved 4-clicks you had to be sent the embed, (1) click the "play" button to launch the iframe [we never load iframes with 0click], (2) click play within sketch-fab to load the 3d model, (3) click a small "1", and then (4) click a "+" in the tooltip that pops up in order to trigger the exploit. I'm curious if anyone has prior art or opinions on what would be a more appropriate bounty?
The reason I'd personally say it's unfair is because Discord should do their own fair calculations, not just copy what another low-paying company pay may have given before.
Discord is valued at several billion dollars, and their last funding round was over a hundred million. They are a key component in the lives of at least a hundred million people. Given this, $5,000 is, in my opinion, negligible, and the proper payout would have been at least double.
Given that Discord permanently stores so many chat logs, personal information, analytics, etc, there should be no higher priority than maximizing security and user trust, and $5K would make me, as a potential user, think it's a second priority.
The questions you need to ask are what is the cost of the alternative?
What is the cost in the exploit being used in the wild?
What is the cost of the PR shitstorm that would come your way?
How much business could you lose? Customer confidence?
Is this an exploit that could be devastating to your continued operations? Would it lead to legal action? What are your duties to inform customers/users/legal bodies? Will there be any fines involved? You may need to retain an expert PR firm to handle the communication to the world to put a good spin on the story, another cost. Did you breach GDPR? Does the data that could have been leaked reveal business practices you'd rather keep secret? Is there any kind of internal risk of leakage? How far does the exploit go? Can it be combined with other exploits that could be used to gain access to internal systems?
The industry has collectively decided that exploits have a value and I'm not sure these factors are taken into account. You should look at examples of companies that have suffered an attack and look the damaged caused (for example, Experian, Blackbaud come to mind) to understand the impact it can have.
How much does it cost to have a CEO tweet the stock price is "too high imo" and causes a dip? That may cost him potential investors to think again.
Of course, you can't know that person who was just about to give you $50,000 worth of business decided not to because of how you handled the situation but it's always a possibility.
I know I've made (small) decisions like this because I didn't like how it was handled or didn't agree with some of the details, and I no longer consider myself a possible customer as a result.
Thanks for the explanation. Would you say security issues are the main reasons you update? I open Discord once or twice a week and I feel like there's always an update or 3 waiting.
My main takeaway from this article is the question why conextIsolation was introduced defaulting to false.
This is one huge lever to help with the maxime “XSS is RCE in electron” and yet they default to not helping.
I know this is about backwards compatibility, but they could easily have decided to throw if the property is unset. Security-minded people would have set it to true and dealt with the fallout, whereas others could have set it to false and shipped their update still.
But by defaulting to false, this security tool is hidden from both existing and new users. Old code will not even have the chance to get fixed and new code will be written in an insecure state.
I’m sure the release notes talked about this feature, but who reads release notes? Especially not past release notes (when starting fresh today).
The backwards compatibility cost of throwing and in the message even suggesting setting to false as an emergency out would have been minimal compared to the fallout this is causing.
I can write secure apps even with this option disabled, thank you. Really it's no harder than preventing SQL injection. All I do is that I don't use APIs that can lead to interpreting data as code.
So I assign to textContent liberally, don't manipulate URLs as text, but via browser APIs, and avoid everything that allows code execution. It's really stupid simple to follow safe practices for absolute majority of apps.
And this makes writing a electron app with direct access to local PostgreSQL database trivial, fun, and makes writing useful apps without a separate HTTP backend a breeze.
I don't have a need to split privileged code out to separate process, and go back to acting like there's trusted/untrusted split, just like with regular website. Having to do that would kill all the allure of Electron, for me. I use electron precisely because I don't have to do this, and can depend on the HTML/JS code to be trusted.
Thing is: even if you are careful, you only need to make a single mistake to lose everything.
Just like there’s is benefit in memory-safe languages, there is benefit in environments where a single .innerHTML instead of a .innerText doesn’t mean an RCE.
But that wasn’t really the point of my initial comment. Just as I can accept C programmers thinking they don’t make mistakes, I can accept you believing never making any mistakes either and thus I can even accept electron having a footgun mode.
What I took issue with wasn’t the general availability of such a mode but the fact that this mode is a silently chosen default.
Have people explicitly opt in or out of this safety feature. Don’t assume they want to shoot themselves in the foot by default.
That was my concern and this is the pet I hope we can all agree about.
That I personally also think that turning off context isolation should be impossible is another matter and not really part of this discussion and I’m even willing to accept that people could change my mind about that one.
But having an unsafe default is craziness in my book.
Yes, it doesn't need to be default. But comparing C and JS doesn't make much sense here. It's easy to avoid using innerHTML and similar. You can just turn those functions off, if you don't trust yourself to not type them out from time to time in your editor, or if you don't trust your dependencies to not use them.
There's nothing unsafe about having context isolation off, per se. Yes, you can do stupid stuff like run code directly from the internet, but context isolation doesn't prevent that. It still allows RCE. It just limits the fallout to just stealing your data, like with any other XSS on regular websites.
And if programmers can't be trusted to not execute untrusted input as code in more secure context, adding an extra hop via some IPC will not save them, if they make the same mistakes in less secure context.
How common are 'local only' electron apps anymore? I can't think of any program that I've run recently (even a large number of my non-vim terminal applications) which don't make some kind of remote calls.
Loading a remote page and executing it in Electron is not the only, or even recommended, way to build Desktop apps using Electron. Electron was designed for creating Desktop apps, where the content is shipped in the app itself - in that case, contextIsolation is much less necessary because every way you could break out of the sandbox isn't interesting, it's just an obscure way to hack yourself. It's also a huge compromise to the developer experience, and is a big roadblock to anyone other than Electron experts.
Unfortunately, the world disagrees - they really want to wrap websites using Electron, so now we need to default to options that make Electron apps far less compelling as a platform
that's only true for applications that strictly only ever work on and display content that the user has created themselves.
This is an increasingly rare type of application in the age of the internet and social media to the point where I would argue that most applications these days interact with data created by other users (think opening an image file, displaying a chat message, displaying an email, etc).
With Electron you're setting yourself up in a way where a single case of a forgotten input escaping automatically means a remote code execution attack.
On websites, XSS certainly are a bad thing, but they are still somewhat limited in scope and generic mitigations exists in many browsers.
In Electron apps, an XSS means an RCE unless you make use of features like `conextIsolation`.
Reading your comment makes it obvious to me that this isn't already a well-known issue. People generally aren't aware or believe their type of application to be immune and thus it would, and that's the point of my initial comment, make sense to either default to secure or at least default to asking the user to specifically make the decision to be insecure.
Defaulting to turning every XSS attack into an RCE seems to me like a very bad decision.
The fact that there is an app that downloads privileged code as a normal course of action is already a Remote Code Execution issue to me. Furthermore, the fact that it's only https protected means that any https proxy in between me and the server (say a corporate firewall) can execute random code on my computer. No thanks! And they are just a single hack of their static js hosting away from having all of their active user's computers hacked.
I would assume the danger is not your own content breaking out of the sandbox, but displaying unsanitized content from a remote database, which sadly still happens a lot more than you would expect. Definitely not something that only happens when wrapping a website using Electron.
I am well aware of the compatibility issues and the associated difficulties. I wasn't saying the option of turning it off shouldn't be given. I'm saying that the setting should have been mandatory.
People wanting to do it the "easy" way (using scare quotes because turning any XSS into an RCE feels like hard mode to me) set contextIsolation to false and they are done.
Also consider newly created applications: when the limitations exist from the start, it's much easier to build this correctly (the same way it's easier to get to 100% test coverage if you start with TDD than if you have to refactor years of static methods and global state and implicit dependencies).
By having a default setting and having it default to insecure, even newly created applications will be unsafe and will require refactoring in the future.
I hate to be the "RTFM guy," but contextIsolation is pretty well-covered in their docs[1] (and it will be enabled by default beginning with Electron 12).
This might be true, and in certain contexts I’d agree that defaulting to the secure option -while potentially breaking- could be the safer one.
But I have to disagree with your point about reading release notes, this should be the expected behavior from developers working on the product, maybe not every single dependency but at least the main ones. Being an Electron app mainly, discord devs should’ve known and understood what they’re working with. Of course mistakes happen, but the main issue here is developers missed reading the docs properly, not whatever the default value is.
These types of exploits are exactly why I just prefer to use the browser version of everything. The browser is superior (both mobile and desktop). It’s safer, typically faster and less resource intensive, and it has reliable and consistent controls. For example, “going back” means something different to every app, but in safari it’s always just a click away.
And most importantly in the browser I can have full ad blocking/tracking protections enabled.
In case of Discord, there are three key causes for preferring the desktop version - and I don't see any easy workaround to them without adding explicit support to web standards:
1) custom audio codecs & filters; Discord is primarily a gaming VC app and the codecs available on the desktop version are superior for purpose of cancelling echo, noise etc. at low latency,
2) ability to capture any keyboard & mouse shortcuts for VC activation
3) ability to use voice & keyboard shortcut while the browser window is not focused (in particular while in game)
Incidentally adding general support for those to general browsers would lead to subtle security bugs & gotchas.
After a web search it sounds like a common perception is that discord does some audio processing to make speech sound clearer than just plain recording. So this probably has little to do with the codec that's used for data compression. This speech clarity effect could be done in audio worklets too.
>2) ability to capture any keyboard & mouse shortcuts for VC activation
This is extremely important because otherwise I don't think I'd be able to play a game in VM like Hyper-V and still talk to friends via Discord.
The only problem is that I have to run as admin the discord.exe that's hidden in its folder instead of that default Discord icon (updater.exe I guess?)
Yeah I noticed recently that I actually prefer browser apps from a UX point of view - creating tabs of content and jumping between them is something I do a lot, and it's baked in very nicely to the browser. (As is sending a link to share the exact screen i'm on, back button as u mention etc etc)
If the browser is your OS, it makes a lot of sense.
In contrast, I often organize my browser tabs onto multiple separate windows (even when I don't have that many open), because opening programs in windows and jumping between them is something I do a lot, and it's baked in very nicely to my window manager :)
To avoid misinterpretation since text is horrible this way: I am NOT disparaging or even really disagreeing with the parent comment. They're just two different workflows, and while I appreciate the advantages of the browser, apps work better in mine.
I guess they mean launching webapps with --app=, which launces the page in a chromeless window.
Firefox recently learned --ssb (after you enable that in about:config), but it's use is much more limited, geared towards kiosks. Things like right mouse button and extensions are disabled, and you cannot open external links.
Chrome has something called Desktop PWA that allows a PWA (that meets some additional requirements) to be installed as a native app. On macos it has its own .app bundle that can be launched by user and participates in the app switching as a separate app, but underneath shares process tree as the user's chrome instance.
So it's like having an Electron app with stricter sandboxing, less memory usage, and an easier installation / upgrade process.
This is why I prefer the cli/tui version of everything... but discord specifically fights against that. I think discord is one of the worst things to happen to chat in a long time, and it makes me sad so many people jumped ship to it so fast without realizing all the issues, and now after having plenty of time to know those issues, staying there. I watched whole active communities dissolve because of this.
Needless self-promotion; this is why I came up with this template, to build secure electron apps. It is obvious that current industry has not caught up with secure practices for Electron apps, and I hope this template can help people in their endeavors.
Discord is a remote control backdoor. It just isn't an exploit because that's how Discord is designed.
They send a tracking request for every single thing you do in their client. Clicked on someone's profile, clicked on a channel, clicked on a server, etc. The URL was named /track before but they renamed it to "/events" and then recently "/science" (but it's still a POST with no response).
Also their desktop client is literally a remote administration toolkit, it has full access to FS (electron app) and it loads every script from their servers. On launch the desktop client opens websocket server for command and control listening.
They can just add something like require('fs').readFileSync(process.env.HOME + '/.ssh/id_rsa').toString() and send this to their servers, and you won't even notice that (since it doesn't require an update on client because the client is just a browser with full permissions that loads obfuscated code from their servers every time you launch it).
How is this at all surprising? Any non-open source program can do everything you just listen and more. Discord may have been dumb for naming their analytics request point "/track" but that doesn't make them worse than anyone else. I wouldn't be surprised if Word sent every button press to Microsoft. And besides, all the chat data is stored on their servers anyways, so it's not like they get a whole bunch of new data through this.
Well, you have to read past my first sentence. It's a list of things not a thesis statement. Together they make Discord notably bad compared to even other proprietary software. Especially since unlike MS Word where people pay money for the product Discord's product is the user.
But in particular the problem is that it's web crap and it pulls down it's code every time you run it. And now with the websocket backdoor it doesn't even have to do that. This is very different from a compiled program.
It's not surprising but it is also not acceptable. I chose not to use it and encourage others to avoid it.
> Especially since unlike MS Word where people pay money for the product Discord's product is the user
I wish people would stop touting this. Just because you pay for it doesn't mean you aren't being tracked. I would say MS Word is considerably worse because you have to pay for it and it still tracks you.
I think this is less an issue with discord and more an issue with desktop computing in general, and why I personally do my personal business on an iPad whenever I can.
Every application that you run can do everything that you can do. You aren't just trusting Discord not to suck up your keys, you are trusting every application on your system, and maybe even the OS itself.
I prioritized moving to iOS the same day I realized that every application would be restricted to a sandbox. It'd be nice if every application on windows had to beg for permission to read outside of its own sandbox as well, but I doubt we will ever get there due to the sheer amount of legacy stuff hanging around.
This is both a pitiful amount of money for finding flaws in three different pieces of software but at the same time the biggest thing Discord did wrong was not practicing defense in depth through disabling contextIsolation.
Although it makes sense, I'm almost surprised Discord paid out given that biggest reason the RCE exists was due to the Electron top-level navigation bug allowing XSS despite Discord's existing mitigations in the first place.
This seems to be a bit of a concerning attitude, and it's also in that top Discord guys post. No, it's not a bug in some third-party library that you are excused from - you use it, it's your bug now!
And who other than Discord would be poised to take charge and fix it? They need a desktop client almost like no other Electron user. Time to grow up and take some responsibility for the stuff you ship. Instead we have
Yeah the moment you take on a dependency and put it into your code, you vouch for it. That's why so many open source (or even proprietary) licenses have the NO LIABILITY clause.
Alternately take responsibility for fixing it, sending changes upstream, applying pressure that the get accepted, and building defenses against the specific bug in your surrounding code just in case.
Enabling contextIsolation was a lot of work, and required a re-working our native modules (around voice and video) while still maintaining performance.
Getting everything to work in a context isolated world was a many month effort, which had begun long before this bug was reported to our team.
(The majority of this code was written before context isolation even existed :P)
It'd be super interesting to hear more about the performance implications of contextIsolation; as an attacker, an intuition for _why_ developers select less-hardened options is quite useful in prioritizing targets.
Once rearchitected there was negligible performance hit. But context bridge etc... basically requires cloning all objects that need to be passed to the renderer/browser window from another context (the native module). If your message passing is frequent and objects are large this can have an adverse impact to performance.
Our video rendering implementation needed to copy frame buffers to the renderer. Doing this over context bridge would have been quite expensive.
A more ideal approach which the team is working on keeps the buffers on the GPU - which should solve all the performance woes and more.
why is XSS inevitable? I've made plenty of Electron apps that don't connect to the net and or don't display any user data. I still chose electron because it was easy to use and let me be cross platform with effectively zero effort
How would this play out? Bug bounties take the charity business model, you disclose everything you know, they get to fixing it and when they're done they may inform you that they'll write you a check.
Disclosure at this point is moot, you'd only look like an ass and probably wouldn't get the check.
What you're describing is more like a darknet marketplace when you describe the vulnerability in the fewest words possible and never giving up code until the Bitcoin deposit is confirmed. I seriously doubt most companies would deal with an individual like this, it's closer to blackmail than it is a bug bounty.
Electron is going to get a lot of shit for this, but this is really Discord's screw-up for allowing third-party (e.g. not vetted) iframe embeds.. why would that ever be a good idea? CVE-2020-15174 is an interesting exploit (the only part I find pretty damning).
In the web context, iframes are reasonably safe (if you discount ad privacy issues).
One of the touted advantages of Electron is that you can use web technologies and thus have engineers familiar with web technologies working on your application.
It’s very easy to see a web developer do what is perfectly fine on the web.
Heck, this feature might even have been added for their web client and then brought over to the electron version, possibly unbeknownst to the original author of the feature.
No. I wouldn’t call this a bug screwup. Just another effect of the footgun that is electron
> In the web context, iframes are reasonably safe (if you discount ad privacy issues).
This is a dubious claim; not sure how long you've been developing for the web, but iframes have had many many exploits fixed over the years. That's neither here nor there though, as Discord purports to be a native application and therefore should be extra careful.
You can say that about any major piece of tech being used on the internet, right down to the microcode running on your processor having issues. I mean, shit windows had ANOTHER ping of of death style exploit this month. Should we just stop using windows? What about all the linux exploits that exist?
If embedding grants the site owner the ability to execute privileged code on my system, it is unreasonable. I wouldn't expect or want YouTube to gain full access to my system (or my user account at least) when I run a chat program.
If being on the whitelist doesn't grant any special privilege, why have a whitelist? I got the impression that it's for security, but I want my machine to be secure from YouTube as well.
Some orgs (edus and non-profits) only have 10k to 20k per year for their entire bug bounty program. So when setting the price of RCE, we should keep that in mind. Not all of us have tons of cash. Recognition and resume building is a huge value as well.
But on one hand we have an app made by a company valued at 2 billion $, with hundred of millions of $ in funding, made with a tech stack that is sold as the best thing since sliced bread, and on the other we have a one-person-show coding an app in C++/Qt in their free time, which is also compatible with Slack, much faster than the official Discord client, and which does not seem to have any CVEs reported against it (yet, of course, but still :-)).
At some point the supposed amazing development efficiency of the web stack ought to be put in that perspective.
Even if Ripcord is "safe" it is not safe to use. Discord will ban Ripcord, and Ripcord users, if it ever gets popular. They've already said that Ripcord is a violation of the terms of service. They've banned third party before and will again.
They make their money by selling their users and they can't do that if they allow other clients. So they have their policy of not allowing it and banning all third party. Of course they only act when it begins to effect their money. So for now ripcord is usable.
Just using "sandbox" attribute would fix it. Most of the time this is a reasonable situation and I try to remember to use it on 100% of iframing (until it breaks) - I hope you will too.
It's probably telling that I'm a) older and b) paranoid that my internal translation of RCE was "Resume Creating Event"; e.g. a screw-up so bad that a new resume was needed to be produced to begin a new job search.
9:21 PM on July 16, 2020 we received a very detailed report from Masato outlining this exploit.
9:34 PM: Ticket acknowledged - and we began a deploy that would disable sketchfab embeds within the app, to remediate this known attack vector.
10:00 PM: Update pushed to stable to disable all existing sketchfab embeds.
Thanks to the detailed report, we were able to go from a report to a fix deployed to stable in ~40 minutes!
Following that, the next day we deployed a better update as we understood more about the issue (which was the sandbox attribute on the iframe.) In addition, we also paid out $5,000 for this bounty, even though the main fault that lead to RCE was due to a bug in Electron (CVE-2020-15174) which allowed for a bypass of our CSP, by allowing the main window to be navigated to a different domain.
----
As for context isolation, a lot of the code that had been written was not compatible with contextIsolation - and required significant work to refactor. For example, due to the way that objects needed to be cloned to pass through the bridge, the internal APIs that existed needed to be entirely reworked, as they were not really compatible with this model. We began this work in April shortly after we worked out all the quirks required to upgrade to Electron 7 which is when contextBridge would be available for us to turn on contextIsolation. It was not as simple as flipping a boolean from false -> true, and required a re-work of our native modules and their internal APIs, and also doing so in a way that would be backwards & forwards compatible with the various app versions that we had shipped in the wild - in addition to dealing with some performance regressions that needed work-arounds in the new context isolated world.
In August, we shipped context isolation to our Stable release channel and gave Masato the green light for disclosure - which leads us to today!