start	end	text
0	4160	Hey, everybody, and thanks for coming to this talk. This is The Ballot is Busted Before the
4160	7940	Blockchain, a security analysis of votes, the first internet application used in U.S. federal
7940	12580	elections. My name is Mike Spector, and this is joint work with Jimmy Koppel and Danny Weitzner,
12580	17500	and all three of us are from MIT's Computer Science and Artificial Intelligence Laboratory.
18420	22580	All right, so let's talk a bit about voting. In February, the state of West Virginia abruptly
22580	26920	abandoned plans to adopt an internet voting phone app called Votes, and this research is actually
26920	32140	why. I also think this serves as a great case study for explaining why we should be careful
32140	36420	before advocating for new technologies and civic processes, and it really highlights
36420	42560	the need for transparency and accountability in election systems in particular. So our story
42560	46920	starts in late 2019, when it became clear that West Virginia was going to pass a bill directing
46920	51160	their Secretary of State to allow disabled voters to cast their ballots over the internet.
51380	55520	This is really important in the context of West Virginia, because the state has a higher than
55520	61600	average number of disabled voters. For example, according to the CDC, 22% of adults in West
61600	67520	Virginia have some serious difficulty walking or climbing stairs. Another 7.7% have some
67520	72460	sort of vision impairment. Interestingly, West Virginia had already been using Votes
72460	76420	for overseas military voters, and we expected that they were going to be used for this expansion as
76420	83480	well. So given the potential impact, we really wanted to know how Votes provided what are often
83480	88640	considered to be the essential security requirements of voting. In the crypto literature,
88640	95580	these are defined as correctness, privacy, receipt freeness, and coercion resistance. These bottom
95580	99620	three properties are there to ensure that the voter isn't unduly pressured to vote in any
99620	106520	particular way and can't sell their vote. Really interestingly, Votes advertised heavily on the use
106520	111060	of cryptography and cryptographic tools. In particular, they said they used hardware-backed
111060	116440	storage, mixed nets, and of course, because every app has to do this now, the blockchain.
117200	122920	The question that we had was, you know, is this app meant to be N10 verifiable, right? And N10
122920	128780	verifiability is a guarantee that allows a voter to tell if their ballot was counted correctly in
128780	134200	the final tally. And given the use of the tools that were purported to be used here, the expected
134200	139740	guarantee of the system. What was really interesting about Votes to me is that if you took a look at
139740	145080	them from sort of a large distance, they look really good. For instance, they had this bug bounty
145080	151000	by HackerOne. They had undergone a couple of security odds from people outside of the company.
151120	154740	There's even some documentation of how their system worked. But the more you looked at them,
154740	159720	the more red flags you saw. For instance, let's look a little bit at their documentation.
160520	166420	Their documentation consisted mostly of this FAQ, and here's a link to the version that we saw in
166420	170880	the beginner analysis. Importantly, there was no formal description of how their system actually
170880	175740	worked. And this was a bit odd, given the fact that the use of the crypto would really imply
175740	180520	something novel that might require further explanation. There was a number of security
180520	185420	reviews that were claimed to have occurred, but none were actually made public. And in fact,
185420	189340	there was no public list of fixed vulnerabilities at all, which led us to believe that either the
189340	193740	security reviews were just being kept secret, or the security reviews themselves hadn't found
193740	198180	anything, in which case it's sort of unclear if they were any good. These reviews were done by
198180	203240	the National Cyber Security Center and Shift State Security, two entities I'd never heard of before.
203820	208720	The NCC was sort of interesting to look into as well. Their name originally gave me the impression
208720	211920	that they were somehow associated with the government, and I was really surprised to learn
211920	217160	that they weren't. They also appeared to me more of a trade association, and I couldn't find a
217160	221520	staff cryptographer or security researcher there that I could reach out to and ask further questions.
223740	229300	So, you know, at a first glance, many of the cryptographic guarantees that they tried to
229300	235760	claim in the FAQ were sort of interesting, and they look like they're real hard things
235760	240540	to achieve. But in reality, there's really no formal definition for any of these things.
240540	245780	For example, N10 vote encryption really doesn't mean anything, but if you squint at it, it sort
245780	252260	of looks like N10 verifiability. So we really weren't clear on what to make of this whole thing.
252800	257740	All right, so let's look a little bit at their bug bounty. The FAQ bragged quite a bit about
257740	262280	having a bug bounty, and don't get me wrong, having a bug bounty at all is fantastic, except
262280	265980	when we took a deeper look, we found it to be sort of less than encouraging.
266920	272140	You were required to use this special version of the Votes app, which connected to a bunch of
272140	276980	different servers from the live version, and there was no documentation of the differences between
276980	280500	the bug bounty and production, right? And as a researcher, this is sort of dangerous, because
280500	284580	I really would like to know what the actual version of the app is doing versus what's
284580	290180	happening in the special environment. It also had really limited scope. For instance, we weren't
290180	294940	allowed to look into man-in-the-middle attacks, and there was nothing allowed that required
294940	299400	physical access. But they never really defined what physical access meant. So if I used a jail
299400	304160	break to simulate a root exploit and then found a bunch of things that I could do with a piece of
304160	308860	malware that happened to have root on the system, it was unclear if that actually was in or out of
308860	315060	bounds. And the test infrastructure provided was also sort of wonky. There was no binary source
315060	321000	for the servers or the server infrastructure to set up yourself, so you had to rely on their
321000	329510	systems. And when we first tried the app, it actually wouldn't connect at all. To make things
329510	335930	even worse, both the live and bug bounty version of the apps were obfuscated. For context, with
335930	343750	Android reverse engineering, everything is really an APK. And APKs themselves are made up of a bunch
343750	350330	of Java classes and metadata in the form of XML. And what's really cool about APKs is that they,
350330	355690	for the most part, will decompile to source, with the exception of C compiled libraries or
355690	359890	something like that that are attached in there. But the Java stuff will almost always decompile
359890	364630	to source. So we popped those into a decompiler, and the first thing that we noticed is that
364630	369430	all function names, class names, and variable names had been changed into these random Unicode
369430	375530	strings. This really isn't normal and is the kind of thing that's done as an additional step by some
375530	381050	automated obfuscation tool to make static analysis more difficult. Maybe this was done on accident,
381050	385250	but there was other things that led us to believe that it wasn't, right? So, for instance,
385250	389070	later on in our reverse engineering process, we noticed that there was a bunch of string
389070	396930	obfuscation going on. So, for instance, in normal cryptographic code, in Android, you'll see strings
396930	402950	like ASGCM used. And instead, we would see this weird function call with a series of numbers after
402950	407170	the fact. And if we actually looked into the function, what you'll see is this. And this is a
407170	414750	really common runtime string deobfuscation technique. And I rarely have seen this in the
414750	421150	context of consumer software, except out of things like game kits and DRM kits. I've mostly seen this
421150	426310	in cases of, say, hiding malware command and control. So, this is sort of out of the ordinary
426810	431210	and interesting. And as a reminder, this is the bug bounty version of the app. And this is the
431210	434450	version of the app that they're trying to get us to do analysis on. And there's all these sort of
434450	439930	dodges to make it more difficult. Things also got a little interesting if you look at their safe
439930	445070	harbor provisions. These are the conditions that they put on researchers before the company agrees
445070	452170	not to pursue legal action after you report a bug. The restrictions I'm reporting seem to be
452170	458330	the following. First, you must give votes reasonable time to patch bugs. And the second is that votes
458330	463250	retains the authority to decide what reasonable time means. Taken together, this means that votes
463250	468410	could just hold on to bugs indefinitely. And to me, this sort of misses the point of using a bug
468410	473270	bounty as a transparency tool altogether. If the point is to let us security researchers hold the
473270	478310	company accountable to actually fix the bugs we discover, then there needs to be some sort of
478310	485510	time limit here. To make matters worse, a previous attempt at security analysis appears to have
485510	492430	resulted in a University of Michigan researcher being investigated by the FBI. In fact, votes' CEO
492430	497230	was quoted by CNN taking credit for reporting the researchers to the authorities. And we never
497230	502150	found any indication that the company was bothered that it turned out to be a researcher rather than
502290	509410	a malicious entity. To be fair to votes, though, there was this quote in the bug bounty that
509410	516570	explicitly banned examination of the non-bug bounty version of the app. However, the bug bounty's edit
516570	521110	history tells us that this restriction was added after the University of Michigan researcher was
521110	528030	reported to law enforcement. So I can't believe I have to say this, but the first unwritten rule
528030	533770	of bug bounties is do not send the law after well-meaning security researchers. Flashing a bit
533770	538450	forward in the talk, this combined with the rhetoric afterward really complicated our ability to
538450	543550	disclose the results of our work. All right, so overall we found a bunch of issues, right? There's
543550	548390	no formal documentation of the system, there was these weird security claims, there were no public
548390	553830	security audits, the code itself was really obfuscated, and the bug bounty as a whole seemed
553830	559510	kind of dubious. But really we needed to do this analysis, the impact was too great, so we did it
559510	566030	anyway. All right, so a key challenge here was that we really didn't want to touch anything that could
566030	570810	possibly cause harm to an election, and therefore we had to make a number of assumptions about the
570810	575870	back end. Our solution was to manually reverse engineer the app and iteratively re-implement the
575870	581690	server to better understand the protocol and app functionality. For analysis, we always assume the
581690	586710	best possible situation for the back end, and whenever we deviated from this assumption, we
586710	592550	explicitly discussed why in the paper. All right, so let's take a very quick tour of the app from
592550	599710	the voter's point of view. Initialization is very similar to any other app. You're asked to use the
599710	605010	sort of standard one-time password, you're asked to provide an eight-digit PIN, then you're asked to
605010	612590	log in via fingerprint, and finally you are officially part of the system. At this point, however, you're
612590	618350	still not verified as a real voter, so the way that Votes allows you to become sort of identified in
618350	625470	the system is you provide some sort of physical ID. And how they do this is that they ask you to
625470	631190	take a picture of your ID, and they ask you to take a picture of your face, and then they upload it
631190	637330	somewhere and do some matching, and eventually the user is told that they have successfully been
637330	643010	verified. Now, at this point, the voter can actually participate in elections, which looks something
643010	648550	like this. Here's an actual ballot. Finally, they can review and submit their ballot. They're asked
648550	656430	to verify and log in again using their biometrics, and finally they have voted. From their FAQ and
656430	661390	reports from the pilots, we found out that the users emailed an encrypted receipt of their vote,
661390	666330	which appears to actually contain their real selections. It's really not clear how this receipt
666330	670590	ends up working in practice, but we did find this screen in the app which provided a password
670590	676810	for decryption. From what we could find in the literature, really there's no intent-verifiable
676810	683210	voting system that really works this way. All right, so let's talk about what happens behind
683210	689350	the scenes. In reality, Votes is for the most part just a REST app, which means it's a bunch of
689970	696070	HTTPS GET and PUT requests to a centralized API server. In addition, there's two other entities
696070	701670	that you should be aware of. The first is Imperium, which is a third-party antivirus which Votes uses
701670	707890	to detect all sorts of stuff going on in the system, and a third-party ID verification service
707890	712350	called Jumeo. So if you look at the network itself, it looks something like this.
712390	718330	Solid lines here delineate a connection that we were able to actually observe or find in the
718330	725990	documentation. Dotted lines are things that we sort of suspect exist. All right, so let's talk
726110	732610	a little bit about attacks. Let's consider this scenario where an attacker has gotten control over
732710	737410	a user's device and loaded some malware. The first thing that this malware would have to do is
737410	743790	actually defeat Imperium's malware detection. Imperium is initialized on app creation. So when
743790	748610	the app first loads, it begins scanning, and then after every app resumes, so if you were to leave
748610	752830	the app and go to your web browser and come back, it'll then do another scan. It looks for a bunch
752830	758110	of things like known exploits slash malware, any indicators of jailbreak, debugging, or modding,
758110	763390	and it's a bit of a snitch, right? If you're caught, it will alert both the Votes API server
763390	769070	and its Imperium servers, and if we had to guess, this is probably what caused the University of
769070	773690	Michigan researcher to be caught. The thing about Imperium is that it's really not meant to stand
773690	778410	up against targeted attacks, right? Defeating this is really easy, it turns out, if you have
778410	784090	root on device. In particular, we can inject code into Java runtime and modify it to stop Imperium
784090	789870	from ever really being initialized. This might sound super complicated, but this is almost all
789870	793910	the code that's actually required. This sort of thing is really common and well supported by the
793910	799890	tools in the modding community. And without Imperium, right, the attacker has complete control
799890	805070	over the user's device, and any receipt that you would receive over email is also likely compromised
805070	811870	as well. And there's really not much that can be done to prevent this. Again, Votes does not appear
811870	819390	to be end-to-end verifiable. All right, so maybe you don't buy this attack, maybe you think that
819390	824010	it's a little difficult to get malware on the system a priori. You know, what happens if we only
824010	830850	get access to the device after a vote has been cast? All right, so what's really interesting is that
830850	836150	there's an encrypted database that contains all of the user's vote history and everything that
836150	842270	is needed to authenticate as the user to their server. This database is encrypted using a secret
842270	848770	key, which is derived from the user's PIN and the salt. The salt is a random value that's stored on
848770	854830	disk unencrypted. The PIN, however, is also stored on disk, but it is encrypted using the Android
854830	859030	Keystore, which means the keys are stored in this hardware enclave and never accessible to the app
859030	864130	itself. And it requires a user's fingerprint or biometric to decrypt, and this is actually kind
864130	870770	of okay, right? So it looks great. Except that the PINs themselves are only eight digits and numeral
870770	876570	only. And of course, you know where this is going. 10 to the 8 combinations means that there's roughly
876570	882790	100 million PINs. And if we copy the database from the device onto our laptop and create a very
882790	888830	short Python script to try to brute force it, we found that it takes roughly 0.05 milliseconds per
888830	895390	attempt so that you can try all these PINs in roughly 1.6 hours. Indeed, we were able to get
895390	901850	complete access to the voter's entire vote history and their authentication data, meaning that anyone
901850	907050	with forensic access can brute force the PIN, control the voter, and see how they voted.
908350	910250	All right, let's talk about the server.
912070	916150	Now, on device, you can really just get access to one particular user, of course.
916230	920570	The server has access to far, far more. And what's really interesting is that Votes use this
920570	925190	custom crypto protocol between the device and the server. It looks something like this.
925530	930710	First, the device will establish a standard HTTPS connection to Votes' API server.
931270	936750	Then, on top of HTTPS, it'll perform the following non-standard homeworld crypto algorithm.
937070	943930	First, the device generates 100 ECDSA key pairs. It'll then immediately discard all
943930	949950	but the 57th secret key. Then, the device sends all 100 public keys to Votes' server.
950070	954630	The server will generate its own 100 keys and perform a key agreement with the center's 57th
954630	960150	public key and generate a random value that will later be used as an AES-GCM shared key.
961070	967050	It'll then encrypt this AES-GCM key with the ECDSA shared key, this 57th
967050	971930	key, and sends the client, the server's 100 public keys.
972070	976630	Finally, the phone performs its own key agreement and decrypts the AES-GCM key.
977570	983790	So, from this point forward, all communication is additionally encrypted using AES-GCM.
984630	989930	The thing is that was actually 100% of the crypto in the protocol used between the device and the
989930	996590	server. The app actually never sees anything from any blockchain. And this includes what we would
996590	1001750	expect to exist in an ecosystem like this, which would be a proof of inclusion. The app actually
1001750	1008270	never even verifies the server's public key outside of the standard HTTPS connection. So,
1008270	1012950	active man-in-the-middle attacks are still possible if HTTPS is broken. There's also no
1012950	1018090	non-ephemeral public keys sent from the device, and nothing is ever even signed. And the summary
1018090	1023970	here is that the API server can really do anything that it wants, which sort of begs the question,
1023970	1029770	what's the point of having this blockchain? All right, you know, maybe you think that it's
1029770	1034790	impossible for someone to even get access to votes as servers. We're not worried about nation-states
1034790	1040030	here. Let's talk about the least powered possible adversary, a passive network adversary.
1040810	1045190	Now, that protocol that I mentioned, that I explained before, was non-standard and has
1045190	1050670	unclear security benefits, but it isn't inherently insecure on its own. But it does make this other
1050670	1055570	attack way worse. But first, I have to explain how votes are cast. On the left is what a ballot
1055570	1060610	looks like in-app when the user is selecting their preferred candidate and example election.
1061490	1066050	This is generated from JSON strings sent by the server, which are variable length,
1066050	1071090	depending on the description of the candidate, various URLs, and other metadata. For example,
1071090	1078010	you can see the corresponding JSON sent from the server on the right. When a vote is submitted,
1078010	1082750	you might expect that it just sends some ID numbers, but instead what it does is it sends
1082750	1089110	all metadata for the voter's choice, but only that candidate's metadata. The result is a textbook
1089110	1094670	side-channel attack, which again is made far worse by votes' custom crypto. In normal HTTPS,
1094670	1099290	the plaintext is somewhat obfuscated by gzip compression. In votes' protocol, however,
1099290	1104210	the plaintext is encrypted before gzip even gets a chance. The result is that if you know the
1104210	1108530	lengths of the ballot options, you can very obviously tell which of the options the voter
1108530	1118090	selected because you cannot effectively compress encrypted data. This image graphs the size of
1118090	1121870	packets sent from the device to the server immediately after a submission for the candidate
1121870	1127730	with the short description and the candidate with the long description. Note that you can clearly
1127730	1133090	tell which packet is the vote submission and which run is for the long candidate and or short
1133090	1138470	candidate. The end result is that a passive network adversary like, say, the user's ISP
1138470	1145410	or the insecure coffee shop Wi-Fi that they're voting from can easily determine ballot selections.
1146610	1151170	All right, scenario four. Let's talk a little bit about privacy and informed consent.
1153690	1159750	Jumeo is this third party that actually does a series of things for votes in this ecosystem,
1159750	1165370	including liveness detection, some machine learning to match the selfie and the voter's ID,
1165370	1169830	and performs OCR on the ID. What's really interesting here is that none of this is
1169830	1174930	actually done on device. In fact, Jumeo's servers actually gets both of these images,
1174930	1180830	which include all of the voters' personal information, like their driver's license ID,
1180830	1189030	as well as their location via GPS. And the only place that we could find either in their
1189030	1195670	votes as documentation at the time, or in the app itself, were these very small translucent logos
1196190	1202110	at the bottom of these two particular screens. And I'm not normally a privacy nut, but in this
1202110	1207630	case, you got to remember that this app was being used for soldiers in war zones. So at this point,
1207630	1214710	it's actually somewhat of a national security issue. All right. So in sum, we found five high
1214710	1220150	severity vulnerabilities and a really serious privacy issue. Interestingly, many of the issues
1220150	1226770	we found were really basic implementation failures. This included a mandated use of weak passwords,
1226770	1231430	their anti-tamper slash AB solution was really easily circumventable, the side channel attack
1231430	1237110	that we described earlier, right? And again, like the API server had complete control over
1237110	1243070	all users in the election. It's also really unlikely that any of this is N10 verifiable or,
1243070	1247530	and it's unclear from what we saw that this could possibly be receipt-free or coercion-resistant.
1248150	1252590	Below is a summary of the powers of a given adversary, and I won't dwell too much on this
1253050	1256790	here, but if you read the paper, we go into much further detail.
1257450	1262010	What's really frustrating about all this is that none of the attacks we found were really novel.
1262210	1266450	I really started this research hoping to find some crazy new crypto, and instead I basically
1266450	1274810	found the standard CRUD app. So at this point, we really needed to talk to somebody, and I'm a huge
1274810	1279150	believer in responsible disclosure, and we really didn't want to hurt an ongoing election, but there
1279150	1284790	was a real sense of urgency. And remember, for context, the DNC had just announced that it was
1284790	1290470	going to use a voting app to count ballots for Iowa's primary, and as far as we knew, votes was
1290470	1295530	what they were using. We actually really didn't think that the DNC would be crazy enough to try
1295530	1300790	to launch an app right before an election. So the first thing that we did is we contacted the
1300790	1306990	MIT BU Law Clinic, who were fantastic, and we sort of ran immediately into this very pernicious
1306990	1316110	problem. And again, this is why Rule 0 of bug bounties exists. Both law enforcement and votes
1316110	1322630	seem to have used this rationale for reporting the researcher that it was somehow required due
1322630	1328810	to this designation as critical infrastructure. And, you know, we actually kind of agree that
1328810	1333570	voting infrastructure is critical infrastructure and really should be treated this way. So rather
1333570	1339450	than reporting to votes, we reported to CISA, the part of DHS that is responsible for digital
1339450	1345470	critical infrastructure. CISA here was fantastic, professional, and wonderful. They allowed us to
1345470	1350770	report the vulnerabilities to both the vendor and those affected without putting ourselves at risk.
1350770	1354970	Once we had confirmation that there were no active users of the app, we then released a
1354970	1362150	preview of this paper. The media attention was immediate and effusive. We got a number
1362150	1368390	of responses from both civil society and other researchers that were all very, very positive.
1368390	1374210	Senator Ron Wyden spoke in support of our findings and sent a letter to SHIFT State
1374210	1379070	Security asking for further information about why, for instance, they hadn't found the same
1379070	1383510	bugs that we had. And I think that the reason everyone was immediately so sure of our results
1383510	1388150	actually has a lot more to do with votes' response to us, which, to put it frankly, wasn't very
1388150	1392770	encouraging. They appeared to have two main concerns with our work. First, that we somehow
1392770	1396710	used an older version of the app, which, by the way, wasn't true. I literally have no idea where
1396710	1401630	this 27 version thing came from. We used the most recent version of the app at the time of analysis.
1402130	1408950	And the second was that somehow our methodology was flawed. Interestingly, votes never really
1408950	1413350	denied the vulnerabilities themselves. And attacking the methodology without denying the
1413350	1419590	results is a really classic dodge. For example, Diebold did the exact same thing when Princeton's
1419590	1424190	research on the Acuvo TSX came out. And it's worth noting that third parties were able to
1424190	1432150	independently verify Princeton's findings after the fact. Speaking of which, about a month after
1432150	1436590	we released our report, Trail of Bits, a really well-known security firm, revealed that it had
1436590	1442790	been contracted to do a full source code review of votes. And Trail of Bits' report couldn't have
1442790	1448870	been worse for votes, right? Not only validated our methodology, but also quoted votes as objections
1448870	1455030	to our work and explicitly rejected all of them. It also confirmed all of our bugs and revealed
1455030	1461590	that the company had been alerted to their veracity before they spoke to the press. They
1461590	1465550	also revealed that Zemperium wasn't running during the pilots, also that it was a blacklist.
1465550	1470690	They also found no evidence of a mixed net and confirmed the system was not end-to-end verifiable.
1471490	1477130	They also found roughly 40 other bugs and vulnerabilities. So this is all sort of a
1477130	1481450	mess. It's sort of important to do a little bit of retrospective and figure out how we got here.
1481450	1486050	I think that there's a tension here that can be summarized pretty well in this quote by Bradley
1486050	1490130	Tusk, who was the philanthropist that funded Votes is Use and seems to be really focused
1490130	1495250	on expanding internet voting. He says that it's not that cybersecurity people are bad people,
1495250	1501430	per se. I think that it's that they are solving for one situation and I am solving for another.
1501710	1507890	They want zero technology risk in any way, shape, or form. I am solving for the problem of turnout.
1509130	1512510	And while I really do agree with the overall goal of solving this particular problem,
1512990	1520670	the issue is that introducing new technology tends to introduce new and unexamined risks.
1521230	1526270	And in this case, this is all really compounded by asymmetric information. And here's what I mean
1526270	1531150	by that. Election systems in the US are fractured and purchasing decisions are made locally, right?
1531150	1536690	Each jurisdiction here shouldn't have to be stuck trying to vet the security of the systems they're
1536690	1541510	purchasing. And unfortunately, the vendor is always going to know more about the systems they create
1541510	1548110	than those purchasing them. So what can we do? The first thing that we should do is try to fight
1548110	1552790	efforts to increase information asymmetry. Put another way, we should advocate for transparency
1552790	1556970	in this ecosystem. This can be done through better public analyses of election systems,
1556970	1562610	including reverse engineering like this work. We must also start demanding software independence
1562610	1568570	in our voting systems. We don't really know how to do this very well with electronic-only voting,
1568570	1573450	and anything where the voter gets to physically verify their paper ballot before it's sent in
1573450	1577790	is really a better situation here. For instance, like mail-in ballots, in-person drop-off,
1577790	1583990	and in-person voting are all great. Electronic-only return or other electronic-only systems like DREs
1583990	1588870	are really, really hard to make and verifiable, and really, really hard to make software-independent,
1588870	1592770	and we're still trying to figure out how to do this at the research level.
1593530	1596550	And everything that isn't transparent or software-independent, we should examine
1596550	1603450	and really try to develop some replacements. Finally, it's an election year. Go vote!
1603850	1605950	Thanks for watching, and feel free to reach out.