WEBVTT
00:00:22.678 --> 00:00:31.769
Welcome to Making Data Better, a podcast about data quality and the impact it has on how we protect, manage and use the digital data critical to our lives.
00:00:31.769 --> 00:00:37.792
I'm George Peabody, partner at Lockstep, and joining me is, of course, steve Wilson, founder of Lockstep.
00:00:38.240 --> 00:00:38.984
Great to see you, Steve.
00:00:38.984 --> 00:00:45.149
Good to see you too, George, over the channel, over the signal processing, making podcasts better.
00:00:45.729 --> 00:00:48.006
There we go, we're making audio data better.
00:00:48.780 --> 00:00:49.040
All right.
00:00:49.040 --> 00:01:21.174
So, look, this is going to be one of those podcast discussions between Steve and George, so we won't inflict it on you for very long, but we wanted to talk about I guess the topic really is around the distinction between technology and the context that technology has to operate in and that has everything to do with the business incentives and the perceived benefits of a technology adoption and the competition of adopting something.
00:01:21.174 --> 00:01:34.483
And, of course, we're talking about security here or security-related topics, the tension between implementing those kinds of things versus adding yet another function to the software that you're selling, for example.
00:01:34.483 --> 00:01:49.742
Right and Steve and I are all about the sharing of metadata, the story of the data of sort of around an identifier like a phone number or a driver's license.
00:01:49.742 --> 00:01:51.204
We want to know.
00:01:51.204 --> 00:01:53.129
How long has that been in existence?
00:01:53.129 --> 00:01:54.712
Where did it come from?
00:01:54.712 --> 00:02:01.787
There are great examples out there in the world of metadata being shared.
00:02:02.028 --> 00:02:04.451
Using existing tools works.
00:02:04.451 --> 00:02:30.985
We like PKI, digital certificates and cryptography at the edge, so we've got things like chip cards great example of a combination of hardware and software getting rid of plain text presentation We've got now well, it's been a year or so since passkeys have been introduced and here's a hardware and software-based combination to kill passwords.
00:02:30.985 --> 00:02:38.128
Very exciting.
00:02:38.128 --> 00:02:47.675
Which phone numbers can be spoofed by a robocaller to make me think I'm getting a call from my next-door neighbor.
00:02:47.675 --> 00:02:53.258
Indeed, the telecom industry has got one called Stir, stroke, shaken.
00:02:53.258 --> 00:03:02.930
Of course, stir and Shaken for those of you who may remember James Bond, ian Fleming's spy character.
00:03:02.949 --> 00:03:03.854
He took his martini shaken, not stirred.
00:03:03.854 --> 00:03:04.276
It's terrible.
00:03:04.276 --> 00:03:05.441
It dissolves the ice.
00:03:05.441 --> 00:03:08.949
It's one thing James Bond got wrong, I think.
00:03:08.990 --> 00:03:14.448
Here is an industry that's trying to go after robocalling In the United States.
00:03:14.448 --> 00:03:52.930
It's getting some significant pressure from the Federal Communications Commission and yet the fact that the business case for deploying it clearly isn't high enough for what, after a few years, is a flat adoption rate of that technology in the 35% range, I think, which means the impact on robocalls is essentially negligible, which really gets to that preamble I gave around where you've got to have a business reason and you've got to have ubiquity if you're going to be able to put up a barrier to bad actors.
00:03:55.181 --> 00:04:00.092
There's so many demands on product developers, software engineers.
00:04:00.092 --> 00:04:01.282
These days.
00:04:01.282 --> 00:04:11.531
The product development lifecycle is so tight, the competitive pressures are so high for overt features that basic hygiene, I think, always suffers, which is sad.
00:04:11.531 --> 00:04:17.951
You know, we've had this capability with the mobile protocols to do much better confirmation of origin.
00:04:17.951 --> 00:04:19.821
That metadata is available.
00:04:19.821 --> 00:04:25.694
If developers had time to know about it, implement it, talk to their colleagues.
00:04:25.694 --> 00:04:27.927
I mean, a lot of this has got to do with co-op petition, doesn't it?
00:04:27.927 --> 00:04:36.170
You do need to be coordinating across competing telco providers and even handset providers to really leverage some of this technology.
00:04:36.170 --> 00:04:47.182
So I think in a busy day-to-day life of the developer there's so many demands on their work that it becomes difficult to get what we call a non-functional requirement up on the table.
00:04:47.182 --> 00:04:48.966
I reflect sometimes.
00:04:49.567 --> 00:04:52.903
We've been talking about verifiable credentials, george, for months now.
00:04:52.903 --> 00:04:55.267
Well, years in the industry, but months on our pod.
00:04:55.267 --> 00:05:00.228
I always say that one of the original verifiable credentials is actually the SIM card itself.
00:05:00.228 --> 00:05:06.130
And if you think about it, there's a chip in everybody's handset that protects their mobile phone number.
00:05:06.130 --> 00:05:13.127
It actually protects their so-called IMSI, the International Mobile Subscriber Identifier, which maps onto your cell phone number.
00:05:13.127 --> 00:05:18.891
But the irony of all of this is that the world's first verifiable credential is sitting in everybody's handsets.
00:05:18.891 --> 00:05:33.565
It's a cryptographically signed copy of your definitive IMSI and the handset could make that verifiable credential available to the firmware in the phone so that every single phone call could actually be checked against the EMSI.
00:05:33.565 --> 00:05:36.136
And the network, of course, does this.
00:05:36.136 --> 00:05:39.988
The network checks the EMSI because that's how it generates bills.
00:05:39.988 --> 00:05:48.648
Global roaming depends on the SIM card signing the EMSI and sending it into the network so that a handset identifies itself at the start of a call.
00:05:48.648 --> 00:06:04.505
So that a handset identifies itself at the start of a call, you know, it kind of frustrates me that that signal is not also available, I guess, at the firmware or the software level in the phone, so that the handset could also identify whether the claimed caller ID actually matches the EMSI or not.
00:06:07.521 --> 00:06:14.110
Which I knew more about, the stir-shaken protocol, but it doesn't seem to be going to the hardware at that level.
00:06:14.110 --> 00:06:17.730
It looks to me like it's a software-only approach.
00:06:18.920 --> 00:06:31.149
Yeah, and you mentioned before, George, as we were preparing for this, that there is this sort of cross-protocol problem too, that telephony these days is mostly about IP telephony and not just using the network infrastructure.
00:06:31.149 --> 00:06:43.641
So we think that what happens is that even if you're using this protocol as a call, as the call data moves between an IP network and a mobile broadband network, a lot of that metadata gets lost.
00:06:43.641 --> 00:06:49.069
It's just too hard to keep the metadata across those different boundaries, so it disappears.
00:06:49.069 --> 00:07:04.067
Priority is given to the actual call data and maybe the data, the IP payload and all of that metadata that shows us where it's come from and what it's supposed to be used for and how does the data originate.
00:07:04.067 --> 00:07:05.446
All of that metadata gets lost.
00:07:05.446 --> 00:07:07.146
It's dropped on the floor.
00:07:07.519 --> 00:07:09.302
It's an important resource, but we just can't maintain it.
00:07:10.283 --> 00:07:12.264
So, steve, what have you seen with respect to solving this?
00:07:12.264 --> 00:07:13.586
It's such an important resource, but we just can't maintain it.
00:07:13.586 --> 00:07:16.228
So, steve, what have you seen with respect to solving this ubiquity problem?
00:07:16.228 --> 00:07:19.310
And I'm going to take up some more airspace here.
00:07:20.232 --> 00:07:35.944
In the payments world where I come from, apple Pay been around for almost a decade, had a very long time to reach hockey stick level adoption because it required handsets.
00:07:35.944 --> 00:07:41.033
It required the comfort level to be attained by people to load their phones with payment credentials.
00:07:41.033 --> 00:07:41.853
That was a new thing.
00:07:41.853 --> 00:07:45.550
Of course, it took a contactless footprint all around.
00:07:45.550 --> 00:07:50.451
The convenience factor is way up there, so it's getting used more and more.
00:07:50.451 --> 00:07:54.100
It's still not ubiquitous Even in that case.
00:07:54.100 --> 00:08:03.971
The specification on which Apple Pay is based and Google Pay and Samsung Pay all follow it the EMV tokenization specification, framework specification.
00:08:03.971 --> 00:08:08.096
It specs a lot of data, specifies a lot of metadata types.
00:08:08.096 --> 00:08:17.569
It's really handy for risk management and the challenge here is that a lot of entities that might use that metadata don't.
00:08:17.569 --> 00:08:22.411
They don't adjust it and use it for risk management capabilities.
00:08:22.411 --> 00:08:31.632
Back to my question is how do we get security to be a priority against the functional stuff?
00:08:32.679 --> 00:08:34.768
It's our old friend regulation, isn't it?
00:08:34.768 --> 00:08:36.405
I was wondering where you'd go.
00:08:38.284 --> 00:08:42.320
Look, it's hardly our lone voice calling for regulation.
00:08:42.320 --> 00:08:54.388
I mean none other than Bruce Schneier, for example probably the world's most preeminent security commentator and security engineer has said for a long time of things like IoT, the Internet of Things, IoT.
00:08:54.388 --> 00:08:56.932
Security is such an important thing.
00:08:56.932 --> 00:09:03.094
It doesn't get a voice at the table in the competitive product engineering landscape.
00:09:03.094 --> 00:09:10.673
So Bruce Schneier calls for regulation to mandate minimum security on IoT devices, and I think he's right.
00:09:11.600 --> 00:09:13.889
I think you get a market failure with safety.
00:09:13.889 --> 00:09:17.389
I mean, Lord, let's go back to automotive safety.
00:09:17.389 --> 00:09:33.643
With the best will in the world, competitive businesses don't prioritise safety, especially when it's not a competitive differentiator, and we don't want safety to be thus differentiator and we don't want safety to be thus so.
00:09:33.643 --> 00:09:37.152
The brutal truth is that capitalism fails to deliver safety when safety is not a competitive differentiator.
00:09:37.152 --> 00:09:39.043
That's almost like a law of nature.
00:09:39.043 --> 00:09:46.010
So we do look to regulators, and perhaps that's why these things move so slowly, because regulators are notoriously slow.
00:09:46.010 --> 00:09:54.184
But I think that the parallels between car safety and internet safety and cyber safety are very strong and very obvious.
00:09:55.368 --> 00:10:01.215
Sure, we've seen it with automobiles and, of course, we've seen it in airlines and aircraft.
00:10:01.736 --> 00:10:09.543
Faa is very strong, your favorite example, the importance of airline safety and the advances in airline safety are down to regulations.
00:10:09.543 --> 00:10:11.469
I think everybody would have to agree on that.
00:10:11.469 --> 00:10:11.850
That's right.
00:10:12.600 --> 00:10:19.288
Very rigorous certification requirements for every type of aircraft and every modification to that aircraft.
00:10:19.821 --> 00:10:31.134
So we're actually asking politicians, I guess, to regulate things that lead to robocalls, and maybe the political competitive imperative to regulate robocalls is not there.
00:10:31.134 --> 00:10:33.527
I mean, where do most of our robocalls come from?
00:10:33.527 --> 00:10:34.509
Politicians?
00:10:35.081 --> 00:10:38.100
Do we just stop and weep at this point in frustration?
00:10:38.100 --> 00:11:07.251
You know, I do think that and we've talked about this a lot amongst ourselves is that how do you build in economic incentives to improve security, incentive to build to improve security and you know, you and I have talked a lot about in our own thinking about a solution is that there are economic models that could actually, in terms of sharing verifiable credentials, there are ways that a party that's consuming those credentials, that has to make a risk decision based on it, has an economic incentive for paying for it.
00:11:07.700 --> 00:11:08.663
Paying for better data.
00:11:08.663 --> 00:11:10.628
You're saying Pay for the quality signals.
00:11:10.628 --> 00:11:12.292
Maybe they're optional quality signals.
00:11:13.645 --> 00:11:27.278
We've got a ton of relying parties who subscribe to services like LexisNexis Risk Solutions and and other data providers because they need to spend money to manage their risks.
00:11:27.278 --> 00:11:42.375
There's a way you know alternatives that require less storage of data, stronger proofs of data provenance, just to say that there's not an economic engine that's available.
00:11:42.375 --> 00:11:44.399
That's not the case?
00:11:45.784 --> 00:11:46.889
No, it's plainly not the case.
00:11:46.889 --> 00:11:52.291
We have a free market that has led to a marketplace of data signals.
00:11:52.291 --> 00:11:58.469
Businesses do pay, and they pay a lot for better data, and in a sense, it's a good thing.
00:11:58.469 --> 00:12:02.688
I don't think the way that that data is distributed at the moment makes a lot of sense.
00:12:02.688 --> 00:12:09.149
I think that the market is corrupted by a number of misaligned interests, shall we say, to be politically correct.
00:12:09.149 --> 00:12:12.566
But clearly, in a sense, information wants to be free.
00:12:12.566 --> 00:12:19.428
There's so much free information out there and yet businesses do pay a premium to get those risk management signals.
00:12:20.070 --> 00:12:23.738
Information wants to be free is just some hippie nostrum call.
00:12:23.738 --> 00:12:27.793
We have always paid for quality information.
00:12:27.793 --> 00:12:30.006
We've paid for books for centuries.
00:12:30.006 --> 00:12:31.971
That's quality information.
00:12:31.971 --> 00:12:39.557
Just because I don't have to go to a library or a store to buy a book online, there's no reason why it should be free.
00:12:39.557 --> 00:13:01.008
I think, as an industry looking at systemic economic incentives and getting those aligned around the sharing of data using more broad mechanisms rather than the I have to contract with company A, company B, company C to get the data that I'm looking for and hoping that it's accurate we can do a lot better.
00:13:01.008 --> 00:13:04.629
All right, we leave it there, steve.
00:13:06.666 --> 00:13:20.779
Yeah, it's one of those little conversations that raise more questions than answers, so we always hope that our listeners and our audiences have come here for ways of thinking about problems and unpacking the dimensions of this wicked problem.
00:13:20.779 --> 00:13:25.076
There's no easy solutions, but I think the principles are becoming clearer.
00:13:25.076 --> 00:13:37.897
How do you make data quality, signals, metadata, how do you make it available and how do you have a flatter playing field, I guess, on how to access that data and how to pay reasonable?
00:13:38.238 --> 00:13:38.739
fees for it.
00:13:38.739 --> 00:13:39.466
Well, that's it.
00:13:39.466 --> 00:13:44.457
I think it's this combination of sure regulation when it's feasible, possible.
00:13:44.457 --> 00:13:49.114
Living in the US regulation is a challenging piece.
00:13:49.975 --> 00:13:51.018
How very polite of you.
00:13:58.653 --> 00:14:12.096
Politics drives our regulation hugely, of course, and tempt businesses to deploy with a regulatory kick in the back, because I do agree that a regulatory push, it really moves markets.
00:14:12.096 --> 00:14:26.450
You know, one of the reasons I'm excited to have this conversation with you, steve, is what appears to be happening in Australia is that there's a lot of strong, focused thinking on this topic and what's the role of regulators, what's the role of the market?
00:14:26.450 --> 00:14:32.719
It's top of mind, so at least I hope our conversation is useful in your neck of the woods.
00:14:40.225 --> 00:14:40.706
Definitely so.
00:14:40.706 --> 00:14:43.715
We could flag another podcast from National Australia Bank, which had me as a guest, on their Digital Next podcast.
00:14:43.715 --> 00:15:03.750
That's going to be posted next week sometime, and we've got a couple of blogs lined up that you'll also see at the Lockstep website, discussing what we think is shaping up to be Wall's best practice in terms of regulating digital ID and a vision for how this might be extended to regulating all sorts of other data as well.
00:15:03.750 --> 00:15:08.458
So it is a really interesting time here in Australia.
00:15:08.458 --> 00:15:09.539
It's been a long time coming.
00:15:09.539 --> 00:15:16.054
We've got probably the third iteration of what used to be called digital identity legislation third iteration in 15 years.
00:15:16.054 --> 00:15:19.254
But no, we're absolutely getting there.
00:15:19.254 --> 00:15:20.470
It's good to see some progress.
00:15:21.232 --> 00:15:21.432
Good.
00:15:21.432 --> 00:15:24.350
Well, on that optimistic note, I'll see you next time.
00:15:24.350 --> 00:15:26.214
Got to be optimistic, dave.
00:15:26.214 --> 00:15:26.995
Absolutely.
00:15:26.995 --> 00:15:28.477
Thanks, my friend.
00:15:28.477 --> 00:15:32.345
Talk to you later, cheers, thank you.
00:00:22.678 --> 00:00:31.769
Welcome to Making Data Better, a podcast about data quality and the impact it has on how we protect, manage and use the digital data critical to our lives.
00:00:31.769 --> 00:00:37.792
I'm George Peabody, partner at Lockstep, and joining me is, of course, steve Wilson, founder of Lockstep.
00:00:38.240 --> 00:00:38.984
Great to see you, Steve.
00:00:38.984 --> 00:00:45.149
Good to see you too, George, over the channel, over the signal processing, making podcasts better.
00:00:45.729 --> 00:00:48.006
There we go, we're making audio data better.
00:00:48.780 --> 00:00:49.040
All right.
00:00:49.040 --> 00:01:21.174
So, look, this is going to be one of those podcast discussions between Steve and George, so we won't inflict it on you for very long, but we wanted to talk about I guess the topic really is around the distinction between technology and the context that technology has to operate in and that has everything to do with the business incentives and the perceived benefits of a technology adoption and the competition of adopting something.
00:01:21.174 --> 00:01:34.483
And, of course, we're talking about security here or security-related topics, the tension between implementing those kinds of things versus adding yet another function to the software that you're selling, for example.
00:01:34.483 --> 00:01:49.742
Right and Steve and I are all about the sharing of metadata, the story of the data of sort of around an identifier like a phone number or a driver's license.
00:01:49.742 --> 00:01:51.204
We want to know.
00:01:51.204 --> 00:01:53.129
How long has that been in existence?
00:01:53.129 --> 00:01:54.712
Where did it come from?
00:01:54.712 --> 00:02:01.787
There are great examples out there in the world of metadata being shared.
00:02:02.028 --> 00:02:04.451
Using existing tools works.
00:02:04.451 --> 00:02:30.985
We like PKI, digital certificates and cryptography at the edge, so we've got things like chip cards great example of a combination of hardware and software getting rid of plain text presentation We've got now well, it's been a year or so since passkeys have been introduced and here's a hardware and software-based combination to kill passwords.
00:02:30.985 --> 00:02:38.128
Very exciting.
00:02:38.128 --> 00:02:47.675
Which phone numbers can be spoofed by a robocaller to make me think I'm getting a call from my next-door neighbor.
00:02:47.675 --> 00:02:53.258
Indeed, the telecom industry has got one called Stir, stroke, shaken.
00:02:53.258 --> 00:03:02.930
Of course, stir and Shaken for those of you who may remember James Bond, ian Fleming's spy character.
00:03:02.949 --> 00:03:03.854
He took his martini shaken, not stirred.
00:03:03.854 --> 00:03:04.276
It's terrible.
00:03:04.276 --> 00:03:05.441
It dissolves the ice.
00:03:05.441 --> 00:03:08.949
It's one thing James Bond got wrong, I think.
00:03:08.990 --> 00:03:14.448
Here is an industry that's trying to go after robocalling In the United States.
00:03:14.448 --> 00:03:52.930
It's getting some significant pressure from the Federal Communications Commission and yet the fact that the business case for deploying it clearly isn't high enough for what, after a few years, is a flat adoption rate of that technology in the 35% range, I think, which means the impact on robocalls is essentially negligible, which really gets to that preamble I gave around where you've got to have a business reason and you've got to have ubiquity if you're going to be able to put up a barrier to bad actors.
00:03:55.181 --> 00:04:00.092
There's so many demands on product developers, software engineers.
00:04:00.092 --> 00:04:01.282
These days.
00:04:01.282 --> 00:04:11.531
The product development lifecycle is so tight, the competitive pressures are so high for overt features that basic hygiene, I think, always suffers, which is sad.
00:04:11.531 --> 00:04:17.951
You know, we've had this capability with the mobile protocols to do much better confirmation of origin.
00:04:17.951 --> 00:04:19.821
That metadata is available.
00:04:19.821 --> 00:04:25.694
If developers had time to know about it, implement it, talk to their colleagues.
00:04:25.694 --> 00:04:27.927
I mean, a lot of this has got to do with co-op petition, doesn't it?
00:04:27.927 --> 00:04:36.170
You do need to be coordinating across competing telco providers and even handset providers to really leverage some of this technology.
00:04:36.170 --> 00:04:47.182
So I think in a busy day-to-day life of the developer there's so many demands on their work that it becomes difficult to get what we call a non-functional requirement up on the table.
00:04:47.182 --> 00:04:48.966
I reflect sometimes.
00:04:49.567 --> 00:04:52.903
We've been talking about verifiable credentials, george, for months now.
00:04:52.903 --> 00:04:55.267
Well, years in the industry, but months on our pod.
00:04:55.267 --> 00:05:00.228
I always say that one of the original verifiable credentials is actually the SIM card itself.
00:05:00.228 --> 00:05:06.130
And if you think about it, there's a chip in everybody's handset that protects their mobile phone number.
00:05:06.130 --> 00:05:13.127
It actually protects their so-called IMSI, the International Mobile Subscriber Identifier, which maps onto your cell phone number.
00:05:13.127 --> 00:05:18.891
But the irony of all of this is that the world's first verifiable credential is sitting in everybody's handsets.
00:05:18.891 --> 00:05:33.565
It's a cryptographically signed copy of your definitive IMSI and the handset could make that verifiable credential available to the firmware in the phone so that every single phone call could actually be checked against the EMSI.
00:05:33.565 --> 00:05:36.136
And the network, of course, does this.
00:05:36.136 --> 00:05:39.988
The network checks the EMSI because that's how it generates bills.
00:05:39.988 --> 00:05:48.648
Global roaming depends on the SIM card signing the EMSI and sending it into the network so that a handset identifies itself at the start of a call.
00:05:48.648 --> 00:06:04.505
So that a handset identifies itself at the start of a call, you know, it kind of frustrates me that that signal is not also available, I guess, at the firmware or the software level in the phone, so that the handset could also identify whether the claimed caller ID actually matches the EMSI or not.
00:06:07.521 --> 00:06:14.110
Which I knew more about, the stir-shaken protocol, but it doesn't seem to be going to the hardware at that level.
00:06:14.110 --> 00:06:17.730
It looks to me like it's a software-only approach.
00:06:18.920 --> 00:06:31.149
Yeah, and you mentioned before, George, as we were preparing for this, that there is this sort of cross-protocol problem too, that telephony these days is mostly about IP telephony and not just using the network infrastructure.
00:06:31.149 --> 00:06:43.641
So we think that what happens is that even if you're using this protocol as a call, as the call data moves between an IP network and a mobile broadband network, a lot of that metadata gets lost.
00:06:43.641 --> 00:06:49.069
It's just too hard to keep the metadata across those different boundaries, so it disappears.
00:06:49.069 --> 00:07:04.067
Priority is given to the actual call data and maybe the data, the IP payload and all of that metadata that shows us where it's come from and what it's supposed to be used for and how does the data originate.
00:07:04.067 --> 00:07:05.446
All of that metadata gets lost.
00:07:05.446 --> 00:07:07.146
It's dropped on the floor.
00:07:07.519 --> 00:07:09.302
It's an important resource, but we just can't maintain it.
00:07:10.283 --> 00:07:12.264
So, steve, what have you seen with respect to solving this?
00:07:12.264 --> 00:07:13.586
It's such an important resource, but we just can't maintain it.
00:07:13.586 --> 00:07:16.228
So, steve, what have you seen with respect to solving this ubiquity problem?
00:07:16.228 --> 00:07:19.310
And I'm going to take up some more airspace here.
00:07:20.232 --> 00:07:35.944
In the payments world where I come from, apple Pay been around for almost a decade, had a very long time to reach hockey stick level adoption because it required handsets.
00:07:35.944 --> 00:07:41.033
It required the comfort level to be attained by people to load their phones with payment credentials.
00:07:41.033 --> 00:07:41.853
That was a new thing.
00:07:41.853 --> 00:07:45.550
Of course, it took a contactless footprint all around.
00:07:45.550 --> 00:07:50.451
The convenience factor is way up there, so it's getting used more and more.
00:07:50.451 --> 00:07:54.100
It's still not ubiquitous Even in that case.
00:07:54.100 --> 00:08:03.971
The specification on which Apple Pay is based and Google Pay and Samsung Pay all follow it the EMV tokenization specification, framework specification.
00:08:03.971 --> 00:08:08.096
It specs a lot of data, specifies a lot of metadata types.
00:08:08.096 --> 00:08:17.569
It's really handy for risk management and the challenge here is that a lot of entities that might use that metadata don't.
00:08:17.569 --> 00:08:22.411
They don't adjust it and use it for risk management capabilities.
00:08:22.411 --> 00:08:31.632
Back to my question is how do we get security to be a priority against the functional stuff?
00:08:32.679 --> 00:08:34.768
It's our old friend regulation, isn't it?
00:08:34.768 --> 00:08:36.405
I was wondering where you'd go.
00:08:38.284 --> 00:08:42.320
Look, it's hardly our lone voice calling for regulation.
00:08:42.320 --> 00:08:54.388
I mean none other than Bruce Schneier, for example probably the world's most preeminent security commentator and security engineer has said for a long time of things like IoT, the Internet of Things, IoT.
00:08:54.388 --> 00:08:56.932
Security is such an important thing.
00:08:56.932 --> 00:09:03.094
It doesn't get a voice at the table in the competitive product engineering landscape.
00:09:03.094 --> 00:09:10.673
So Bruce Schneier calls for regulation to mandate minimum security on IoT devices, and I think he's right.
00:09:11.600 --> 00:09:13.889
I think you get a market failure with safety.
00:09:13.889 --> 00:09:17.389
I mean, Lord, let's go back to automotive safety.
00:09:17.389 --> 00:09:33.643
With the best will in the world, competitive businesses don't prioritise safety, especially when it's not a competitive differentiator, and we don't want safety to be thus differentiator and we don't want safety to be thus so.
00:09:33.643 --> 00:09:37.152
The brutal truth is that capitalism fails to deliver safety when safety is not a competitive differentiator.
00:09:37.152 --> 00:09:39.043
That's almost like a law of nature.
00:09:39.043 --> 00:09:46.010
So we do look to regulators, and perhaps that's why these things move so slowly, because regulators are notoriously slow.
00:09:46.010 --> 00:09:54.184
But I think that the parallels between car safety and internet safety and cyber safety are very strong and very obvious.
00:09:55.368 --> 00:10:01.215
Sure, we've seen it with automobiles and, of course, we've seen it in airlines and aircraft.
00:10:01.736 --> 00:10:09.543
Faa is very strong, your favorite example, the importance of airline safety and the advances in airline safety are down to regulations.
00:10:09.543 --> 00:10:11.469
I think everybody would have to agree on that.
00:10:11.469 --> 00:10:11.850
That's right.
00:10:12.600 --> 00:10:19.288
Very rigorous certification requirements for every type of aircraft and every modification to that aircraft.
00:10:19.821 --> 00:10:31.134
So we're actually asking politicians, I guess, to regulate things that lead to robocalls, and maybe the political competitive imperative to regulate robocalls is not there.
00:10:31.134 --> 00:10:33.527
I mean, where do most of our robocalls come from?
00:10:33.527 --> 00:10:34.509
Politicians?
00:10:35.081 --> 00:10:38.100
Do we just stop and weep at this point in frustration?
00:10:38.100 --> 00:11:07.251
You know, I do think that and we've talked about this a lot amongst ourselves is that how do you build in economic incentives to improve security, incentive to build to improve security and you know, you and I have talked a lot about in our own thinking about a solution is that there are economic models that could actually, in terms of sharing verifiable credentials, there are ways that a party that's consuming those credentials, that has to make a risk decision based on it, has an economic incentive for paying for it.
00:11:07.700 --> 00:11:08.663
Paying for better data.
00:11:08.663 --> 00:11:10.628
You're saying Pay for the quality signals.
00:11:10.628 --> 00:11:12.292
Maybe they're optional quality signals.
00:11:13.645 --> 00:11:27.278
We've got a ton of relying parties who subscribe to services like LexisNexis Risk Solutions and and other data providers because they need to spend money to manage their risks.
00:11:27.278 --> 00:11:42.375
There's a way you know alternatives that require less storage of data, stronger proofs of data provenance, just to say that there's not an economic engine that's available.
00:11:42.375 --> 00:11:44.399
That's not the case?
00:11:45.784 --> 00:11:46.889
No, it's plainly not the case.
00:11:46.889 --> 00:11:52.291
We have a free market that has led to a marketplace of data signals.
00:11:52.291 --> 00:11:58.469
Businesses do pay, and they pay a lot for better data, and in a sense, it's a good thing.
00:11:58.469 --> 00:12:02.688
I don't think the way that that data is distributed at the moment makes a lot of sense.
00:12:02.688 --> 00:12:09.149
I think that the market is corrupted by a number of misaligned interests, shall we say, to be politically correct.
00:12:09.149 --> 00:12:12.566
But clearly, in a sense, information wants to be free.
00:12:12.566 --> 00:12:19.428
There's so much free information out there and yet businesses do pay a premium to get those risk management signals.
00:12:20.070 --> 00:12:23.738
Information wants to be free is just some hippie nostrum call.
00:12:23.738 --> 00:12:27.793
We have always paid for quality information.
00:12:27.793 --> 00:12:30.006
We've paid for books for centuries.
00:12:30.006 --> 00:12:31.971
That's quality information.
00:12:31.971 --> 00:12:39.557
Just because I don't have to go to a library or a store to buy a book online, there's no reason why it should be free.
00:12:39.557 --> 00:13:01.008
I think, as an industry looking at systemic economic incentives and getting those aligned around the sharing of data using more broad mechanisms rather than the I have to contract with company A, company B, company C to get the data that I'm looking for and hoping that it's accurate we can do a lot better.
00:13:01.008 --> 00:13:04.629
All right, we leave it there, steve.
00:13:06.666 --> 00:13:20.779
Yeah, it's one of those little conversations that raise more questions than answers, so we always hope that our listeners and our audiences have come here for ways of thinking about problems and unpacking the dimensions of this wicked problem.
00:13:20.779 --> 00:13:25.076
There's no easy solutions, but I think the principles are becoming clearer.
00:13:25.076 --> 00:13:37.897
How do you make data quality, signals, metadata, how do you make it available and how do you have a flatter playing field, I guess, on how to access that data and how to pay reasonable?
00:13:38.238 --> 00:13:38.739
fees for it.
00:13:38.739 --> 00:13:39.466
Well, that's it.
00:13:39.466 --> 00:13:44.457
I think it's this combination of sure regulation when it's feasible, possible.
00:13:44.457 --> 00:13:49.114
Living in the US regulation is a challenging piece.
00:13:49.975 --> 00:13:51.018
How very polite of you.
00:13:58.653 --> 00:14:12.096
Politics drives our regulation hugely, of course, and tempt businesses to deploy with a regulatory kick in the back, because I do agree that a regulatory push, it really moves markets.
00:14:12.096 --> 00:14:26.450
You know, one of the reasons I'm excited to have this conversation with you, steve, is what appears to be happening in Australia is that there's a lot of strong, focused thinking on this topic and what's the role of regulators, what's the role of the market?
00:14:26.450 --> 00:14:32.719
It's top of mind, so at least I hope our conversation is useful in your neck of the woods.
00:14:40.225 --> 00:14:40.706
Definitely so.
00:14:40.706 --> 00:14:43.715
We could flag another podcast from National Australia Bank, which had me as a guest, on their Digital Next podcast.
00:14:43.715 --> 00:15:03.750
That's going to be posted next week sometime, and we've got a couple of blogs lined up that you'll also see at the Lockstep website, discussing what we think is shaping up to be Wall's best practice in terms of regulating digital ID and a vision for how this might be extended to regulating all sorts of other data as well.
00:15:03.750 --> 00:15:08.458
So it is a really interesting time here in Australia.
00:15:08.458 --> 00:15:09.539
It's been a long time coming.
00:15:09.539 --> 00:15:16.054
We've got probably the third iteration of what used to be called digital identity legislation third iteration in 15 years.
00:15:16.054 --> 00:15:19.254
But no, we're absolutely getting there.
00:15:19.254 --> 00:15:20.470
It's good to see some progress.
00:15:21.232 --> 00:15:21.432
Good.
00:15:21.432 --> 00:15:24.350
Well, on that optimistic note, I'll see you next time.
00:15:24.350 --> 00:15:26.214
Got to be optimistic, dave.
00:15:26.214 --> 00:15:26.995
Absolutely.
00:15:26.995 --> 00:15:28.477
Thanks, my friend.
00:15:28.477 --> 00:15:32.345
Talk to you later, cheers, thank you.
