[00:00.000 --> 00:12.240]  And it fails them, so everybody will be tired and wasted and then I'm here with talk, with
[00:12.240 --> 00:19.280]  sheets, with full of text and some really interesting policy stuff combined with some
[00:19.280 --> 00:21.200]  technical questions.
[00:21.200 --> 00:28.040]  So that's a nice way to get you all asleep and not leaving for them anymore.
[00:28.040 --> 00:36.400]  I'm Winfrey Tilanus, I'm privacy consultant, I'm also a member of the XMPB Standard Foundation
[00:36.400 --> 00:46.120]  and I'm long term and more and more also at the brink between technology and policy.
[00:46.120 --> 00:55.040]  So I tend to look at acts from the European Union and things like that and this act caught
[00:55.040 --> 01:01.000]  my eye, you may have heard about it because it also got some more news, it's a digital
[01:01.000 --> 01:02.920]  market act.
[01:02.920 --> 01:09.320]  And it has some interesting things because the European Commission can designate big
[01:09.320 --> 01:21.640]  companies as gatekeeper and you have to think about Meta with WhatsApp and Facebook chat,
[01:21.640 --> 01:34.080]  you can think about Apple's chat, about Google's chat, Instagram, maybe perhaps Telegram because
[01:34.080 --> 01:41.760]  it has also quite big user base with companies like that might be designated as gatekeepers.
[01:41.760 --> 01:46.400]  And when you're designated as gatekeeper, there's a process that will be in the second
[01:46.400 --> 01:51.320]  half, started in the second half of this year.
[01:51.320 --> 01:57.840]  After you've been designated, you have to open up your chat within three months.
[01:57.840 --> 02:05.280]  Two years later, you must also open up your group chat and four years later, you also
[02:05.280 --> 02:12.080]  must have your video and voice calling opened.
[02:12.080 --> 02:18.280]  And right now in the start, it's okay to open it by just publishing an API.
[02:18.280 --> 02:27.640]  But the European Commission in all its wisdom may decide to draft a standard for interoperability
[02:27.640 --> 02:34.800]  and if they do so, then all these, the own API won't suffice anymore, then you have to
[02:34.800 --> 02:37.520]  follow that standard.
[02:37.520 --> 02:45.200]  And they also said that standard has to be drafted by European standards organization,
[02:45.200 --> 02:48.360]  so it has to be the Zen or the Etsy.
[02:48.360 --> 02:57.960]  Also interesting, there's some more nice things about it because that API or that standard
[02:57.960 --> 03:05.400]  has missed have the same security features as the own product of the company and it must
[03:05.400 --> 03:11.560]  be neutral, so it must not be crippled in such a way that nobody wants to use it or
[03:11.560 --> 03:18.160]  that I have some conditions to it that really puts it backwards compared to the own product.
[03:18.160 --> 03:24.720]  Well, I read this and I had a deja vu.
[03:24.720 --> 03:31.480]  Because some years ago, the Dutch Ministry of Health had a problem with interoperable
[03:31.480 --> 03:33.280]  and secure chat.
[03:33.280 --> 03:42.160]  So they asked for a standard about chat to make it interoperable and secure.
[03:42.160 --> 03:49.800]  And they gave the assignment to the NEN that's the Standardization Institute and I happened
[03:49.800 --> 03:54.800]  to be chairing the working group drafting that standard.
[03:54.800 --> 04:03.720]  So I went in all kind of things and questions and things that happened there.
[04:03.720 --> 04:09.760]  So I thought why not combine my two experiences of this experience with what the European
[04:09.760 --> 04:15.440]  Commission is aiming at and let's have a look on what we're dealing with.
[04:15.440 --> 04:23.440]  Now, when I think about the European Commission, it's about the question, what do you mean
[04:23.440 --> 04:26.000]  by secure?
[04:26.000 --> 04:34.880]  Fender A says we are secure because we offer the best end-to-end encryption in the world.
[04:34.880 --> 04:35.880]  Nobody can eavesdrop.
[04:35.880 --> 04:40.960]  This is the most secure solution you have.
[04:40.960 --> 04:48.960]  Fender B says, nah, we monitor all communications and filter all harm for content.
[04:48.960 --> 04:54.120]  Well everybody is safe on this platform.
[04:54.120 --> 05:02.560]  This, well, tell me, well, let's put your hands, would you think A is the most secure
[05:02.560 --> 05:06.120]  one?
[05:06.120 --> 05:10.320]  We think B is the most secure one?
[05:10.320 --> 05:11.320]  Nobody.
[05:12.080 --> 05:21.560]  But this, even the European Commission is sometimes aiming at security like B. So there's a big
[05:21.560 --> 05:25.840]  misunderstanding about what do you mean by secure.
[05:25.840 --> 05:36.440]  And it's kind of difficult to add A to B, isn't it?
[05:36.440 --> 05:41.720]  And end-to-end encryption does have its drawbacks because both clients must support the same
[05:41.720 --> 05:44.360]  end-to-end protocol.
[05:44.360 --> 05:51.080]  So you can't have one do end-to-end encryption based on the matrix or open PGP and the other
[05:51.080 --> 05:53.880]  one an open WISP or something like that.
[05:53.880 --> 06:00.240]  It must be the same and there's all the key exchange and everything.
[06:00.240 --> 06:06.680]  And spam detection, harmful content detection, we may like it or we may not like it.
[06:06.680 --> 06:15.000]  It is a thing and it is an important part of the security model of some platforms.
[06:15.000 --> 06:21.360]  And there's also one interesting thing that I saw about, well, nice end-to-end encrypted
[06:21.360 --> 06:23.880]  platform opens up with a nice API.
[06:23.880 --> 06:26.080]  So I can connect to that API.
[06:26.080 --> 06:30.720]  That API is also end-to-end encrypted.
[06:30.720 --> 06:36.840]  Before it was open, they had their own clients that sent and received the message.
[06:36.840 --> 06:41.120]  So they knew what was injected into the network.
[06:41.120 --> 06:45.400]  And it was in such a way that nothing went wrong when it was received by the client.
[06:45.400 --> 06:50.880]  But now I can write my own client, maybe even a first-in-client or something like that,
[06:50.880 --> 06:53.640]  and inject whatever I want into the network.
[06:53.640 --> 07:01.640]  So they may even get a security risk because they can't monitor, can't filter out all the
[07:01.640 --> 07:04.200]  nice attacks I inject into the network.
[07:04.200 --> 07:09.360]  So that might be quite interesting.
[07:09.360 --> 07:14.480]  And end-to-end encrypted may also have intellectual property issues.
[07:14.480 --> 07:21.800]  When there's some propriety encryption protocol that a vendor boards a nice license to, like
[07:22.800 --> 07:27.640]  what's apt-it, then they may say, well, here's the API.
[07:27.640 --> 07:29.000]  This is the protocol.
[07:29.000 --> 07:33.640]  And if you want to use it by your own license, well, that's an interesting business case
[07:33.640 --> 07:35.960]  for Maximali Spike.
[07:35.960 --> 07:43.840]  So there's quite a bit of issues of already one's being secure.
[07:43.920 --> 07:50.440]  Oh, that was going too fast.
[07:50.440 --> 07:55.800]  What's really important here to understand, this is a political decision.
[07:55.800 --> 08:02.760]  The European Commission must say what they mean with secure and how end-to-end encryption
[08:02.760 --> 08:04.800]  would fit in that picture.
[08:04.800 --> 08:12.200]  If they don't and try to push it to a standardization organization, then it will be mayhem.
[08:12.200 --> 08:18.520]  And I can tell from my own experience, I can also reveal the standardization project in
[08:18.520 --> 08:26.800]  the Netherlands failed because they didn't define what they meant by secure.
[08:26.800 --> 08:40.680]  So, but if it did come up with a standard in the Netherlands, it was for health care.
[08:40.680 --> 08:45.280]  So it is quite a specific use case.
[08:45.280 --> 08:48.960]  We standardized to secured servers.
[08:48.960 --> 08:58.400]  So the premise was that when a health care organization sets up a certain server or buys
[08:58.400 --> 09:08.720]  a certain sales server offer, that server was meant for this job and secured in a proper level.
[09:08.720 --> 09:15.840]  No end-to-end encryption because some of them had a security model that relied on securing
[09:15.840 --> 09:20.440]  the data on the server and not keeping anything on the client.
[09:20.440 --> 09:29.160]  And the whole network between the whole health care providers would be authorized, it won't
[09:29.160 --> 09:32.640]  be an open network.
[09:32.640 --> 09:40.320]  And exactly that last point was where the project was killed because some vendors wanted
[09:40.320 --> 09:43.480]  to have another direction there.
[09:43.480 --> 09:52.840]  And then the next question is, when you say interoperable, interoperable with who?
[09:52.840 --> 10:00.160]  When you publish an API, is it sufficient to publish an API so a client can connect?
[10:00.160 --> 10:06.840]  You said, nobody knows, European Commission didn't say anything here.
[10:06.840 --> 10:16.280]  Maybe when you read the law quite close, this is maybe not exactly what they meant, but
[10:16.280 --> 10:18.520]  they're not really clear about it.
[10:18.520 --> 10:23.440]  It would also mean that when you write a chat client, it would be interoperable with all
[10:23.440 --> 10:27.960]  vendors that it needs to implement all those APIs.
[10:27.960 --> 10:38.040]  Or is it, like we did in health care, is this a server-to-server with limited parties?
[10:38.040 --> 10:45.320]  So a walled garden of some systems that are interoperable with each other, or is it really
[10:45.320 --> 10:53.680]  open federation, server-to-server for whoever sets up a server and connects to it?
[10:53.680 --> 10:54.680]  No idea.
[10:55.000 --> 11:01.400]  But it's quite hard to start standardization process if you don't have any idea about what's
[11:01.400 --> 11:04.400]  happening here.
[11:04.400 --> 11:10.920]  And, oh, I'm good in time.
[11:10.920 --> 11:19.360]  Then there are the big question about functionalities because chat isn't just chat.
[11:19.360 --> 11:24.720]  You know, when you look at whatever chat clients you use, you have all nifty features starting
[11:24.720 --> 11:35.000]  with slash me and then repeating your, this is your own nickname, up to all kinds of fancy
[11:35.000 --> 11:43.200]  stickers being sent around of emoji you can add to message and things like that, there
[11:43.200 --> 11:48.080]  are lots of functionalities that a chat can have.
[11:48.080 --> 11:55.720]  And certainly when you enter into encryption, they can't have the server in between translated
[11:55.720 --> 12:03.600]  or say, well, I handle this and this way, that must then all be done by the clients.
[12:03.600 --> 12:07.600]  And that means that for all of these functionalities, you must make a choice about how you're going
[12:07.600 --> 12:09.600]  to handle it.
[12:09.600 --> 12:15.400]  Is this an obligatory functionality that must be part of the protocol that must be implemented
[12:15.400 --> 12:21.920]  then by all the clients or is it optional and making a functionality optional means
[12:21.920 --> 12:27.960]  that you need to have something like service discovery or do you say, no, this is not part
[12:27.960 --> 12:34.200]  of the standard and you don't have to be interoperable for this functionality.
[12:34.920 --> 12:39.920]  Well, we're talking about, about what kind of functionality it is.
[12:39.920 --> 13:09.760]  Almost, I did, I did leave things out mainly because
[13:10.760 --> 13:17.200]  for example, like service discovery, certain ways of connecting, how you standardize exactly
[13:17.200 --> 13:18.200]  the connection.
[13:18.200 --> 13:23.600]  I guess that's in the upper layer and not on the functionality layer you have to choose.
[13:23.600 --> 13:29.800]  But this is the kind of things you're talking about when you start standardizing this.
[13:29.800 --> 13:37.080]  And I have nice time to discuss some of them.
[13:37.400 --> 13:45.960]  When you look at attaching an emoji to a message, well, you think emoji, that's part of the
[13:45.960 --> 13:52.040]  UTF-8 character set, so you can just say, this is the message and then put this emoji
[13:52.040 --> 13:54.040]  to it.
[13:54.040 --> 14:03.520]  But some clients don't, just don't support all kind of emojis, either in sending or
[14:03.520 --> 14:05.520]  receiving.
[14:05.520 --> 14:09.960]  They have only limited set of emoji you can attach to a message.
[14:09.960 --> 14:17.360]  And also, to get something like that done, you maybe need some services discovery to
[14:17.360 --> 14:24.680]  check what emoji are available at the other client and then you can tell your client these
[14:24.680 --> 14:26.840]  are the emoji you can send.
[14:26.840 --> 14:31.200]  Or maybe you just sent an emoji and notice it doesn't work.
[14:31.200 --> 14:33.800]  Not really the best way of interoperability.
[14:33.800 --> 14:38.080]  And then there's also something like, oh, no, that was the wrong one.
[14:38.080 --> 14:43.080]  I need to tap another one, so you need to correct that one or delete it from this.
[14:43.080 --> 14:49.080]  It was inappropriate to do this, so let's get it out.
[14:49.080 --> 14:54.840]  So when you start looking at attaching an emoji to a message, it just looks like a quite
[14:54.840 --> 14:55.840]  straightforward functionality.
[14:56.160 --> 15:08.160]  When you start thinking through an interoperability context, then it might be quite interesting,
[15:08.160 --> 15:10.600]  quite a nice thing.
[15:10.600 --> 15:17.720]  I also like to move notification when you send a message to somebody on platform A, that
[15:17.720 --> 15:22.520]  you can get a response back, no, I'm now somewhere else on a different account on the
[15:22.520 --> 15:29.440]  same platform or maybe on a different account on a totally different platform.
[15:29.440 --> 15:32.400]  It's a nice one to standardize, maybe.
[15:32.400 --> 15:36.760]  I don't know if all platforms would like that and if they'd like to cripple that one
[15:36.760 --> 15:37.760]  or not.
[15:37.760 --> 15:45.760]  Well, I'll just, one minute.
[15:45.760 --> 15:57.040]  Yeah, it's great, is there one other one maybe I should talk about or should we just go straight
[15:57.040 --> 16:00.560]  on to the questions.
[16:00.560 --> 16:06.560]  So thank you.
[16:06.560 --> 16:15.560]  So, first in the back, that was the first and that was it.
[16:15.560 --> 16:37.760]  The question is when is a party designated as gatekeeper and there's a whole set of rules
[16:37.760 --> 16:44.880]  and it mainly means that you have a big market share, a big turnover on it one way or the
[16:44.880 --> 16:54.160]  other, either on advertising or on this paying customers and it looks really like the list
[16:54.160 --> 17:00.880]  I mentioned at the beginning will be the list that will be designated and others not.
[17:00.880 --> 17:09.040]  But you really have to be very large and be one of the biggest players in the fields
[17:09.040 --> 17:11.040]  to get that nice status.
[17:11.040 --> 17:20.240]  You mentioned that the Dutch initiative failed because what was meant with security was not
[17:20.240 --> 17:25.680]  defined, but why didn't somebody in the group say, okay, we're going to define security
[17:25.680 --> 17:28.120]  like this and go ahead?
[17:28.120 --> 17:31.000]  Well, I did.
[17:31.000 --> 17:32.280]  Oh, yeah, I should repeat.
[17:32.280 --> 17:36.920]  So the question is why didn't somebody in the Dutch group define security and just go
[17:36.920 --> 17:37.920]  ahead?
[17:37.920 --> 17:39.920]  Well, I did.
[17:39.920 --> 17:44.480]  And that was exactly the moment that it failed.
[17:44.480 --> 17:53.840]  Yeah, that is a lesson indeed.
[17:53.840 --> 17:58.680]  The issue was really from a commercial perspective, there were some vendors on the table that
[17:58.680 --> 18:11.640]  had different reasons to say, well, I don't want this definition of security.
[18:11.640 --> 18:14.560]  And they made a big mess.
[18:14.560 --> 18:22.520]  I wasn't really prepared for that meeting that I really was totally furthered by one
[18:22.520 --> 18:23.720]  vendor.
[18:23.720 --> 18:27.960]  There was all kind of confusion raised in the group.
[18:27.960 --> 18:38.200]  And then we needed to do some new cycles about how to get out of this.
[18:38.200 --> 18:43.720]  And that was the moment that the government said, well, this takes too long, we're gone.
[18:43.720 --> 18:51.320]  Well, the start of the problem was they didn't define what security is.
[18:51.320 --> 18:53.840]  So lesson learned.
[18:53.840 --> 19:00.640]  And I think it's a very good question because we should do the same trick of be careful
[19:00.640 --> 19:06.720]  for the same issue and maybe be clear to the European Commission, tell us what you mean
[19:06.720 --> 19:07.720]  by secure.
[19:07.720 --> 19:12.160]  We can't standardize if you don't tell us.
[19:12.160 --> 19:23.680]  Yeah, I saw two fingers there were probably basically saying, so my question was, did
[19:23.680 --> 19:28.680]  somebody ask and he said, the problem with asking is that they might actually tell you
[19:28.680 --> 19:33.960]  and they might actually tell you at least if they don't tell you, we can dream a little
[19:33.960 --> 19:38.920]  bit that it might be a.
[19:38.920 --> 19:50.760]  The point is, in most standardization situations, you have a bunch of vendors who are intrinsically
[19:50.760 --> 19:55.360]  motivated to cooperate and to work together.
[19:55.360 --> 19:59.640]  And then they can discuss nicely about the good questions.
[19:59.640 --> 20:04.080]  Standardization like this is with vendors we don't want to.
[20:04.080 --> 20:08.560]  And that's a big, also a big issue when you push this to a standardization organization
[20:08.560 --> 20:10.600]  because they're not up to it.
[20:10.600 --> 20:15.840]  But if you're sitting there with vendors we don't want to, they will blow up the process.
[20:15.840 --> 20:23.440]  So the only way to avoid that is to make sure that somebody sets the limits, makes clear
[20:23.440 --> 20:31.120]  you have to do it this way and otherwise you can leave the table but you will still have
[20:31.120 --> 20:50.440]  a stump that you have to adhere to.