0 00:00:00,000 --> 00:00:30,000 Dieser Untertitel ist noch nicht fertig. Wenn du kannst, bitte unterstütze uns hier und schau den Talk in Amara an für die letzten Korrekturen: https://c3subtitles.de/talk/1448 Danke! 1 00:00:18,760 --> 00:00:20,380 *Wikipaka Intro Musik* 2 00:00:20,380 --> 00:00:29,390 Herald: Welcome to the next talk about free substitution for schools. Yeah. By… 3 00:00:29,390 --> 00:00:36,200 if it was done by Fynn […]. Thank you, for the translators for translating into 4 00:00:36,200 --> 00:00:40,980 German. Let's start. 5 00:00:40,980 --> 00:00:47,970 Fynn: In general, as you know, teachers can't always teach as planned, so students 6 00:00:47,970 --> 00:00:54,199 need to be informed when their lessons are moved in time or space or both, or don't 7 00:00:54,199 --> 00:00:59,930 take place as they should, or they have a different teacher. All that. And for that, 8 00:00:59,930 --> 00:01:05,260 schools create a substitution plan. There's software for that. For example, 9 00:01:05,260 --> 00:01:09,430 Untis. And these substitution plans need to be distributed. And in Germany, a lot 10 00:01:09,430 --> 00:01:16,710 of schools use Digitales Schwarzes Brett or Digital Signage Board or DSB for that. 11 00:01:16,710 --> 00:01:23,280 And it works like this. Um. Oh, yeah. And it works like this that the school uploads 12 00:01:23,280 --> 00:01:30,500 the plan. Pupils can read this substitution plan on these DSB screens, on 13 00:01:30,500 --> 00:01:36,140 their mobile devices using the client software developed by Heinekingmedia and 14 00:01:36,140 --> 00:01:41,960 using the website, once they have the credentials that they acquired from their 15 00:01:41,960 --> 00:01:46,670 school. It's one pair of username and password for all pupils and one for all 16 00:01:46,670 --> 00:01:55,840 teachers. Well. And this costs money, schools buy way to expensive screens from 17 00:01:55,840 --> 00:02:01,920 Heinekingmedia. And then the schools pay extra for this, uh, fantastic web 18 00:02:01,920 --> 00:02:07,300 interface here where you can sign in and view your substitution plans. You can also 19 00:02:07,300 --> 00:02:14,530 use this mobile app. It's not really good, though, as I will explain. Um, this is 20 00:02:14,530 --> 00:02:21,310 what it looks like. Things are tiny, as you can see. It's obviously proprietary 21 00:02:21,310 --> 00:02:27,450 software. It depends on Google Play services. You need to zoom around. You 22 00:02:27,450 --> 00:02:31,790 need to scroll around to see all the information because it's so tiny. So this 23 00:02:31,790 --> 00:02:39,209 is super suboptimal. Um, I don't even know why this is so small. If you look it up on 24 00:02:39,209 --> 00:02:44,629 a Web browser, it zooms fine when you have a small device. And I really don't know 25 00:02:44,629 --> 00:02:50,910 how that… screwed up like that. It has useless push notifications like new 26 00:02:50,910 --> 00:02:55,439 content available. It's not not useful. And you have to click at least one time 27 00:02:55,439 --> 00:03:00,370 too much all the time. And due to these issues, I always wanted something that is 28 00:03:00,370 --> 00:03:06,480 better than DSB mobile. So I began capturing DSB mobiles network traffic. 29 00:03:06,480 --> 00:03:13,180 Surprisingly, in Android, this is really easy. Um, you can use user friendly 30 00:03:13,180 --> 00:03:20,090 software like HTTPCanary, which is this one, or packet capture, which is this one. 31 00:03:20,090 --> 00:03:25,159 It's unfortunately proprietary, but I don't know any non-proprietary software 32 00:03:25,159 --> 00:03:32,930 for this is. If you know any, please tell me. Um, it acts like a VPN provider app 33 00:03:32,930 --> 00:03:38,749 and proxies all the traffic that is going out, uh, through it; installs a 34 00:03:38,749 --> 00:03:43,380 certificate in your system so that apps still think that the net…work connection 35 00:03:43,380 --> 00:03:49,790 is secure, and then this app will decrypt and store and re-encrypt all the traffic 36 00:03:49,790 --> 00:03:54,659 that is going out and in. And so you can read it, then. Uh, this is essentially 37 00:03:54,659 --> 00:04:01,659 like a attacker-in-the-middle attack that you're doing yourself on your own network 38 00:04:01,659 --> 00:04:07,489 traffic. Uh, yeah, except on recent Android versions. Apparently Android 39 00:04:07,489 --> 00:04:12,769 doesn't trust certificates that you install, anymore. So you actually now have 40 00:04:12,769 --> 00:04:20,799 to have root access to move them to this location /systems/etc/security/cacerts so 41 00:04:20,799 --> 00:04:25,430 that they are ultimately trusted. And that is unfortunate because it makes it a 42 00:04:25,430 --> 00:04:33,020 little more difficult. But in all our Android versions, it works really easy. 43 00:04:33,020 --> 00:04:41,350 Um, with more effort, this capturing of network traffic can be circumvented by 44 00:04:41,350 --> 00:04:46,580 implementing a kind of certificate pinnings so that the app checks beforehand 45 00:04:46,580 --> 00:04:50,630 which certificates it trusts, and which it doesn't. With more effort, such a 46 00:04:50,630 --> 00:04:57,350 prevention could also be circumvented. Uh, but DSB Mobile didn't have that, so I 47 00:04:57,350 --> 00:05:03,620 could figure out how this end point works. As you can see, it's called the iPhone 48 00:05:03,620 --> 00:05:14,250 Service. On Android. Using your user ID and password, you can request an auth 49 00:05:14,250 --> 00:05:20,690 token. It has the form of this. Actually, that's what it looks like when you have 50 00:05:20,690 --> 00:05:25,980 invalid credentials. So if it returns this, then your credentials are not valid. 51 00:05:25,980 --> 00:05:35,150 It never changes. So I don't know what the use of this token is. Um, however, DSB 52 00:05:35,150 --> 00:05:43,340 Mobile never stored it, even though it's the same all the time. So it took one 53 00:05:43,340 --> 00:05:49,590 extra round trip time, every log in to fetch this, never changing auth token. 54 00:05:49,590 --> 00:05:56,410 Using this auth token, you can request your substitution plan URL, and then once 55 00:05:56,410 --> 00:06:02,830 you have this substitution plan URL, you can access your substitution plan. OK, so 56 00:06:02,830 --> 00:06:08,230 using this knowledge, I developed a client that allows me to directly have access to 57 00:06:08,230 --> 00:06:13,270 just the relevant information and I call it DSBDirect. Uh, the very first thing it 58 00:06:13,270 --> 00:06:19,770 did better than DSBmobile is that it display things not as tiny. This is a kind 59 00:06:19,770 --> 00:06:26,180 of old screenshot as you can see. These HTML files here can be parsed using a 60 00:06:26,180 --> 00:06:36,210 parser and such that, uh, you can filter it, you can, um, have useful notifications 61 00:06:36,210 --> 00:06:44,510 that I added later on. This is a native list, not a web view. So it has… it feels 62 00:06:44,510 --> 00:06:54,440 better. And uh, yeah, of course it's not proprietary but Free Software. Uh yeah. 63 00:06:54,440 --> 00:07:02,420 Oh, by the way, this logo, it's supposed to represent my school's logo. Uh, this 64 00:07:02,420 --> 00:07:08,830 one. Hmm. Please don't tell me I did, too bad. OK? At least it's different from the 65 00:07:08,830 --> 00:07:15,310 DSB mobile logo. This endpoint is fun in other regards. The first time I 66 00:07:15,310 --> 00:07:19,840 encountered it, it allowed completely unencrypted connections, and the website 67 00:07:19,840 --> 00:07:27,500 did not redirect users to HTTPS. So actually you'd most of the time input your 68 00:07:27,500 --> 00:07:34,990 username and password and transmit it unsecurely. It supported up to TLS version 69 00:07:34,990 --> 00:07:42,230 1.0, which is obsolete. It supported SSLv2, which enables a DROWN attack, which 70 00:07:42,230 --> 00:07:47,860 I didn't quite understand. But apparently those aren't very likely to be exploited 71 00:07:47,860 --> 00:07:53,630 here. But it could allow attackers to read your traffic. I informed the company about 72 00:07:53,630 --> 00:07:59,110 this on August 11th. And I believe this is when I introduced the "not my fault 73 00:07:59,110 --> 00:08:05,820 grumble" tag in the issue tracker… tracker. They were happy to be informed 74 00:08:05,820 --> 00:08:17,550 about this. On August 22nd, they enabled TLS version 1.2, disabled SSLv2, er, still 75 00:08:17,550 --> 00:08:23,020 allowed insecure connections. And I also noticed that they embedded fonts from 76 00:08:23,020 --> 00:08:29,560 Google and this is obviously bad for privacy. So I told them about that. Uh, 77 00:08:29,560 --> 00:08:37,260 Twice. September 19th, the iPhone service 404s if the connection is insecure. 78 00:08:37,260 --> 00:08:43,860 Although Google fonts are still embedded. Anyhow, it's October 4th that the iPhone 79 00:08:43,860 --> 00:08:54,240 service is shut down. So I start focusing on the new endpoint that apparently the 80 00:08:54,240 --> 00:09:01,050 DSB apps have been using for a while, but I didn't notice that. Uh, so I had to 81 00:09:01,050 --> 00:09:11,290 figure out how this data format works. It looks like this. So you can see it has a 82 00:09:11,290 --> 00:09:22,870 JSON body usi– which has a request, which is an object that has data, which is a 83 00:09:22,870 --> 00:09:29,170 string. So I wanted to figure out how to read this. It looks like base64 when I'm 84 00:09:29,170 --> 00:09:36,310 escaping these slashes, of course, because it's quoted in JSON. Um, however, decoding 85 00:09:36,310 --> 00:09:41,550 this JSON string here did not, er, this base64 string did not deliver a nice 86 00:09:41,550 --> 00:09:49,270 result. Uh, so I had to look for clues by decompiling the app. There are online 87 00:09:49,270 --> 00:09:55,110 tools for that. Unfortunately, the app was minified or… which is obfuscated during 88 00:09:55,110 --> 00:10:00,630 compile time, which made the results not very readable, which means that once you 89 00:10:00,630 --> 00:10:05,400 have it decompiled, you will have, the first function that appears is "A", and 90 00:10:05,400 --> 00:10:09,860 the second one is "B" or something. Fortunately, I don't remember how exactly 91 00:10:09,860 --> 00:10:15,190 I did that. So instead we're going to have to look at whether this was legal or not. 92 00:10:15,190 --> 00:10:25,680 Because that's interesting, too, because I think it is. Let's look at § 69e UrhG, 93 00:10:25,680 --> 00:10:30,340 copyright law, Urheberrechtsgesetz, "Dekompilierung". "Die Zustimmung des 94 00:10:30,340 --> 00:10:36,520 Rechteinhabers ist nicht erforderlich, wenn die," und hier steht "Verviefältigung 95 00:10:36,520 --> 00:10:41,230 des Codes oder die Übersetzung der Codeform im Sinne der in § 69c Nr. 1 und 96 00:10:41,230 --> 00:10:44,050 2.," gemeint ist Dekompilierung, "unerlässlich ist, um die erforderlichen 97 00:10:44,050 --> 00:10:46,260 Informationen zur Herstellung der Interoperabilität eines unabhängig 98 00:10:46,260 --> 00:10:50,260 geschaffenen Computerprogramms mit anderen Programmen zu erhalten, sofern folgende 99 00:10:50,260 --> 00:10:54,940 Bestimmungen erfüllt sind." So. It says you may decompile without permission when 100 00:10:54,940 --> 00:10:59,790 it is strictly necessary while trying to create interoperability between two 101 00:10:59,790 --> 00:11:06,570 programs created independently from each other. Under these conditions. And here 102 00:11:06,570 --> 00:11:12,270 are three conditions. Um, "Die Handlungen werden von dem Lizenznehmer oder einer 103 00:11:12,270 --> 00:11:14,930 anderen zur Verwendung eines Vervielfältigungsstückes des Programms 104 00:11:14,930 --> 00:11:18,870 berechtigten Person oder in deren Namen von einer hierzu ermächtigten Person 105 00:11:18,870 --> 00:11:23,060 vorgenommen". It says, you must have permission to use the program. Hey, I 106 00:11:23,060 --> 00:11:27,050 think I'm allowed to use the program. I'm assuming I am. My school paid for it. 107 00:11:27,050 --> 00:11:30,940 Second, "die für die Herstellung der Interoperabilität notwendigen 108 00:11:30,940 --> 00:11:36,440 Informationen sind für die in Nummer 1 genannten Personen noch nicht ohne 109 00:11:36,440 --> 00:11:39,480 weiteres zugänglich gemacht". So the information you want to know is not 110 00:11:39,480 --> 00:11:44,670 already provided. Oh yeah. Actually Heinekingmedia didn't document this 111 00:11:44,670 --> 00:11:48,750 obviously. So yeah. This *indistinguishable*. Third, "Die 112 00:11:48,750 --> 00:11:53,540 Handlungen beschränken sich auf die Teile des ursprünglichen Programms, die zur 113 00:11:53,540 --> 00:11:56,980 Herstellung der Interoperabilität notewndig sind". So you're only planning 114 00:11:56,980 --> 00:12:03,180 the part that contains the information you want to know. Uh, yeah. I don't think this 115 00:12:03,180 --> 00:12:10,649 Android app is divided into parts. So let's just, let's just skip that. The law 116 00:12:10,649 --> 00:12:14,390 text goes on stating three things you may not do with the information you gain from 117 00:12:14,390 --> 00:12:19,410 decompiling. "Bei Handlungen nach Abs. 1 gewonnene Informatione dürfen nicht zu 118 00:12:19,410 --> 00:12:23,520 anderen Zwecken als zur Herstellung der Interoperabilität des unabhängig 119 00:12:23,520 --> 00:12:27,390 geschaffenen Programmes verwendet werden." So don't use it for other purposes than 120 00:12:27,390 --> 00:12:31,220 creating interoperability, interoperability with the independently 121 00:12:31,220 --> 00:12:37,110 created program. Oh yeah, of course. I never did use my knowledge for any other 122 00:12:37,110 --> 00:12:44,980 reasons. Never. "…an Dritte weitergegeben werden, es sei denn, das dies für die 123 00:12:44,980 --> 00:12:50,220 Interoperabilität des unabhängig geschaffenen Programms notwendig ist". So 124 00:12:50,220 --> 00:12:54,600 don't tell third parties about the information unless necessary for 125 00:12:54,600 --> 00:13:01,339 interoperability. Oh, yes, my Free Software implementation couldn't be 126 00:13:01,339 --> 00:13:06,860 interoperable if the information wasn't public. Unless it was Non-Free Software, 127 00:13:06,860 --> 00:13:10,970 which is not obviously. "Für die Entwicklung, Herstellung oder Vermarktung 128 00:13:10,970 --> 00:13:15,430 eines Programms mit im Wesentlichen ähnlicher Ausdrucksform oder für 129 00:13:15,430 --> 00:13:19,880 irgendwelche anderen das Urheberrecht verletzenden Handlungen verwendet werden". 130 00:13:19,880 --> 00:13:25,550 So don't violate the rest of the copyright law. Of course, we're not. Surely, 131 00:13:25,550 --> 00:13:29,440 creating an alternative to something, on its own, doesn't violate copyright law. 132 00:13:29,440 --> 00:13:36,649 Right? So yeah, after doing it, I discovered that I did so legally. So I 133 00:13:36,649 --> 00:13:41,320 found a usage of some class related to gzip. So I tried around a bit and figured 134 00:13:41,320 --> 00:13:50,510 you could use this command to decrypt this string. And guess what it is? It's more 135 00:13:50,510 --> 00:13:57,180 JSON! What an efficient data format. You're hiding our encoded JSON inside more 136 00:13:57,180 --> 00:14:03,480 JSON. Let's look at the data we are sending. Of course, we have a user ID and 137 00:14:03,480 --> 00:14:09,730 a pass. Besides that we have a lot of data, apparently for statistics. You have 138 00:14:09,730 --> 00:14:17,200 the app's version, you have the package ID, the device model, the Android version 139 00:14:17,200 --> 00:14:22,570 and API level, the user's language and the current date. I don't know why you have 140 00:14:22,570 --> 00:14:28,140 the date. I think they know the date that the query arrives at, but, ya, you have 141 00:14:28,140 --> 00:14:35,010 that anyway. You have a… oh sorry, some of this is redundant from the request header 142 00:14:35,010 --> 00:14:44,590 or user agent that is already sent. I don't know why they do that twice. Um, you 143 00:14:44,590 --> 00:14:48,670 have App ID, which is a unique-per- installation ID, which I at first didn't 144 00:14:48,670 --> 00:14:54,370 know how to generate. And you push ID, which is, I'm assuming, an ID generated by 145 00:14:54,370 --> 00:14:58,780 Google Mobile Services now known as Google Play Services to enable push 146 00:14:58,780 --> 00:15:05,080 notifications. So it becomes obvious that they're able to link requests together and 147 00:15:05,080 --> 00:15:10,180 possibly create usage patterns. What are they doing with this data? No clue! 148 00:15:10,180 --> 00:15:17,460 There's no privacy policy anywhere. Which of these fields are required? All of them, 149 00:15:17,460 --> 00:15:23,270 but push ID. But most strings can be left empty. So DSBdirect sent the minimal 150 00:15:23,270 --> 00:15:30,910 amount of requested data, which is everything but with empty strings. And 151 00:15:30,910 --> 00:15:39,660 yeah, actually guess what, this server allows insecure connections again. So, uh, 152 00:15:39,660 --> 00:15:51,670 something happened. Um. On some date, the server side verification of this query was 153 00:15:51,670 --> 00:15:57,970 changed and the field AppVersion suddenly became mandatory. I ran some experiments 154 00:15:57,970 --> 00:16:03,230 and found examples of valid and invalid version names. These are examples of valid 155 00:16:03,230 --> 00:16:09,850 version names. These are examples of invalid version names. Finally, 156 00:16:09,850 --> 00:16:14,649 AppVersions that aren't real versions of Heinekingmedia's apps are accepted anyhow, 157 00:16:14,649 --> 00:16:28,029 like version 7.0.0. We're only at version 2.5.… I don't remember, 6, I think. So, 158 00:16:28,029 --> 00:16:33,760 DSBlight started sending along some AppVersion… its own actually, which was 159 00:16:33,760 --> 00:16:40,880 2.5, and the same as an older DSBmobile release. And because I thought maybe 160 00:16:40,880 --> 00:16:46,720 they'd have more server side changes in the future, I implemented a new system. It 161 00:16:46,720 --> 00:16:52,350 was to prevent server side changes from requiring an update because that would 162 00:16:52,350 --> 00:16:57,100 mean I have to write change logs because after it releases are slow because the one 163 00:16:57,100 --> 00:17:03,130 who was uploading it to Google Play for me also always took a while. And because of 164 00:17:03,130 --> 00:17:07,730 that, there was now a "look for a fix" button that creates the news file, which 165 00:17:07,730 --> 00:17:12,850 is located at the repository's root, which allows me to inform users when they can 166 00:17:12,850 --> 00:17:19,730 expect a fix. It allows me to change this base JSON, that credentials are appended 167 00:17:19,730 --> 00:17:26,020 to which is this without the user ID and user password. So they're added to this 168 00:17:26,020 --> 00:17:35,970 JSON later. And… in case they checked that I added an option to send the real date. I 169 00:17:35,970 --> 00:17:42,100 thought maybe that's what they would do next. They never did that, unfortunately. 170 00:17:42,100 --> 00:17:48,760 This was the same release as the one with the version number fix, this one. Uh, we 171 00:17:48,760 --> 00:17:55,220 have good news elsewhere, though. It was the same day, October 15th, that I 172 00:17:55,220 --> 00:18:02,000 received an email that app.dsbcontrol.de was no longer accessible on Port 80 and 173 00:18:02,000 --> 00:18:08,030 that Google fonts were now being loaded locally. This e-mail contained no usual 174 00:18:08,030 --> 00:18:11,520 "bei Rückfragen können Sie sich gerne direkt an mich wenden", unfortunately, 175 00:18:11,520 --> 00:18:17,370 maybe they didn't want to hear from me anymore. I couldn't verify this at first. 176 00:18:17,370 --> 00:18:23,290 Uh, October 16th, I could verify this. So a friend noted that they have slow deploy 177 00:18:23,290 --> 00:18:29,480 times, apparently. Uh, round 3, it's October 17th, and we're getting an invalid 178 00:18:29,480 --> 00:18:38,670 answer from the server again. And now the App ID has to be set to a UUID and last ID 179 00:18:38,670 --> 00:18:46,360 has to be set to something. It can't be empty. So we are now sending 180 00:18:46,360 --> 00:18:55,030 "zurfrühstückszeit". I wasn't aware of how to generate App IDs yet, so I just took 181 00:18:55,030 --> 00:19:00,080 the one that I had captured from my device. Contributor Pixilon and me learned 182 00:19:00,080 --> 00:19:04,010 this through trial and error. I thought it was very bothersome because the service 183 00:19:04,010 --> 00:19:10,390 sometimes accepted and sometimes rejected the very same query. Uh, so this slow 184 00:19:10,390 --> 00:19:15,510 update cycle we noticed earlier turned out to be really bothersome and frustrating 185 00:19:15,510 --> 00:19:19,090 because you'd, you try something and then it would work and then you'd remove it 186 00:19:19,090 --> 00:19:21,760 again and that wouldn't work anymore. And then you thought this was the cause for 187 00:19:21,760 --> 00:19:30,230 it… actually was just the slow release, deploy cycle. Um, likely, or maybe, they 188 00:19:30,230 --> 00:19:35,160 had just banned this app ID at this point in time, but I didn't realize, I'm not 189 00:19:35,160 --> 00:19:39,950 sure. Rather, I believe the server was generally are struggling and rejecting log 190 00:19:39,950 --> 00:19:45,240 ins because my DSBmobile installation, with this app ID, was also sometimes 191 00:19:45,240 --> 00:19:53,370 rejected. *incomprehensible*. They seem to have reverted some of these changes later, 192 00:19:53,370 --> 00:19:57,520 which reaffirmed my belief that all DSBmobile installations were affected. 193 00:19:57,520 --> 00:20:04,250 Contributor Pixelon figured that device was now mandatory, which meant not empty. 194 00:20:04,250 --> 00:20:11,560 So we sent device "a". I remembered to have at some point in time sent the words 195 00:20:11,560 --> 00:20:16,990 "kartoffel" or "poster" as a device eventually. Now, I thought we were smart. 196 00:20:16,990 --> 00:20:22,370 I added new functionality to this new system I explained earlier. Firstly, as a 197 00:20:22,370 --> 00:20:28,290 precaution, I could remotely activate sending the last date, in case that, I 198 00:20:28,290 --> 00:20:33,730 mean remotely means that it happens when users click on "Look for a fix". Secondly, 199 00:20:33,730 --> 00:20:38,540 I could now set an array of headers to send to the server. And thirdly, we had 200 00:20:38,540 --> 00:20:43,590 discovered some alternative endpoints. To understand this, you first have to know 201 00:20:43,590 --> 00:20:49,760 that they have sold skinned versions of DSB. Uh, so this is the normal DSBmobile. 202 00:20:49,760 --> 00:20:56,679 I showed it earlier already. This is the IHK skinned DSBmobile. It's accessible via 203 00:20:56,679 --> 00:21:03,370 two URLs, that delivers the same data as this website. Uh, it also has a 204 00:21:03,370 --> 00:21:12,910 corresponding skinned Android app. So I configured… so I could configure the 205 00:21:12,910 --> 00:21:18,460 endpoint the client would send the data to because each of these had a different 206 00:21:18,460 --> 00:21:30,600 endpoint and this app used one of these two. However, this was tricky because I 207 00:21:30,600 --> 00:21:37,919 had to prevent myself from giving myself the power to redirect users' queries to my 208 00:21:37,919 --> 00:21:44,780 own server, so I hardcoded four URL endpoints… endpoint URLs, mobile, web, IHK 209 00:21:44,780 --> 00:21:52,200 mobile and app IHK BB into the app so I could switch between them using an integer 210 00:21:52,200 --> 00:21:58,799 and I set it to the IHK mobile endpoint. I believe it was the very next day that IHK 211 00:21:58,799 --> 00:22:04,630 mobile and and app IHK BB endpoints were broken. Actually, they returned invalid 212 00:22:04,630 --> 00:22:14,059 data in a way that crashed my app. Oops. And suddenly the web endpoint from the 213 00:22:14,059 --> 00:22:19,270 normal website was constantly moving to new locations and there was a 214 00:22:19,270 --> 00:22:25,900 configuration.js script that contained where it was, so I hard coded into the app 215 00:22:25,900 --> 00:22:31,370 as a precaution in case I'd need it later a very specific way to to find this 216 00:22:31,370 --> 00:22:36,470 location. And it was like behind this seventh quotation mark or something. 217 00:22:36,470 --> 00:22:40,320 Clearly unreliable, and suddenly the string was moved a line downloads, so it 218 00:22:40,320 --> 00:22:48,490 was now the ninth quotation mark. Interesting. Um, also this App stopped 219 00:22:48,490 --> 00:22:53,280 working. It's still on the Play Store now and it's still not working. This website 220 00:22:53,280 --> 00:23:00,400 is still available and it's not working because they broke their end point. Uh, 221 00:23:00,400 --> 00:23:04,500 this was around the time that this Google Play takedown notice reached us because 222 00:23:04,500 --> 00:23:10,559 apparently DSBdirect infringes the trademark of DSB. I don't feel qualified 223 00:23:10,559 --> 00:23:15,110 to comment on this as I don't understand trademark law. I tried to ask for a 224 00:23:15,110 --> 00:23:20,919 specific clarification as to why they removed my app, three times, but they 225 00:23:20,919 --> 00:23:25,130 never responded. Oh, by the way, that's a nice trick you can do with emails you 226 00:23:25,130 --> 00:23:31,430 don't like. You can just pretend you never received them. So a few days later, the 227 00:23:31,430 --> 00:23:36,460 website JavaScript, including configuration.js, was obfuscated in such a 228 00:23:36,460 --> 00:23:43,191 way that I don't understand how it works, but it constantly evokes the debugger, if 229 00:23:43,191 --> 00:23:48,320 the developer tools are open. You can in theory easily circumvent this by telling 230 00:23:48,320 --> 00:23:52,970 the browser to ignore breakpoints. This doesn't seem to work with Firefox, but it 231 00:23:52,970 --> 00:23:57,340 works in chromium. I don't know why. I'm just going to assume you could have 232 00:23:57,340 --> 00:24:02,760 figured this out somehow. Be it that we could have had a web view running in the 233 00:24:02,760 --> 00:24:07,000 background if we absolutely had to. But fortunately, contributor Pixon had come up 234 00:24:07,000 --> 00:24:12,950 with what is needed to talk to the mobile endpoint now. Because it's more data. 235 00:24:12,950 --> 00:24:17,730 Through decompilation he learned that it was being generated using the default Java 236 00:24:17,730 --> 00:24:29,660 UUID class, UID. … randomUUID.toString. Also device idea was mandatory. So I added 237 00:24:29,660 --> 00:24:36,400 spoof data. I took a random device ID from this list. I took a random OS version from 238 00:24:36,400 --> 00:24:41,840 anything between 4.0.2 and 10.0, I took a random language, mostly German, sometimes 239 00:24:41,840 --> 00:24:50,080 English. And as a BundleId, I took the package ID of DSBmobile. With an option to 240 00:24:50,080 --> 00:24:55,200 disable this via news in case it would get in the way somehow. And that was the end 241 00:24:55,200 --> 00:25:01,330 of that. Apparently they stopped trying to prevent DSBmobile from working. Apparently 242 00:25:01,330 --> 00:25:05,300 after it releases don't count to them and it isn't worth their time. Or maybe they 243 00:25:05,300 --> 00:25:09,760 were just uncreative. I could still think of a few ways to tell DSBlight and 244 00:25:09,760 --> 00:25:17,169 DSBmobile apart, but I'm clearly not going to tell them. However, just this month, 245 00:25:17,169 --> 00:25:22,960 Pixilon asked again why DSBmobile was removed from the Play Store, also because 246 00:25:22,960 --> 00:25:27,590 he believed we didn't violate German trademark law, currently, but, uh, 247 00:25:27,590 --> 00:25:33,210 Jasmich, who, uh, is sitting here, by the way, had uploaded DSBdirect to the Play 248 00:25:33,210 --> 00:25:38,700 Store again and received a rather interesting response. "Sehr geehrter Herr 249 00:25:38,700 --> 00:25:42,809 Zwerger", dear Pixilon, "Vielen Dank für Ihre E-Mail. Leider sehen wir uns 250 00:25:42,809 --> 00:25:48,450 außerstande mit Ihnen einen qualifizierten Diskurs zu diesem Thema zu führen. Uns 251 00:25:48,450 --> 00:25:52,490 sind weder Daten zu Ihnen noch zum Herrn Godau bekannt." This means, unfortunately, 252 00:25:52,490 --> 00:25:56,740 we don't have your address and thus can't send you legally meaningful messages. 253 00:25:56,740 --> 00:26:02,780 Heißt, sie wollen Einwurfeinschreiben machen. "Ebenfalls ist uns nicht klar, in 254 00:26:02,780 --> 00:26:07,540 welcher Rechtsbeziehung Sie zueinander stehen". We don't know about your legal 255 00:26:07,540 --> 00:26:11,360 relationship. This is a bit strange because I don't know either. According to 256 00:26:11,360 --> 00:26:16,450 my father, we might be a "Gesellschaft bürgerlichen Rechts", but it's not exactly 257 00:26:16,450 --> 00:26:22,330 proof of familiarity with Free Software. "Dennoch möchte ich im Folgenden unsere 258 00:26:22,330 --> 00:26:27,010 Position nochmals klar ausdrücken. Es ist weder Ihnen noch anderen Dritten 259 00:26:27,010 --> 00:26:30,420 gestattet, unsere interne DSBmobile-API für eigene Softwareprodukte abzufragen. 260 00:26:30,420 --> 00:26:34,830 Wir untersagen es Ihnen hiermit schriftlich und letztmalig." You may not 261 00:26:34,830 --> 00:26:40,580 use our internal API, I find it questionable whether a publicly facing API 262 00:26:40,580 --> 00:26:45,900 is to be considered internal. One might argue that it is only for communication 263 00:26:45,900 --> 00:26:51,390 between software they control. But I believe I control my device and my client 264 00:26:51,390 --> 00:26:57,540 installation, not them making the API, not internal. "Eine Inverkehrbringung einer 265 00:26:57,540 --> 00:27:02,330 App mit gleichem oder ähnlichen Namen zu DSB ist Ihnen im europäischen Raum 266 00:27:02,330 --> 00:27:07,390 ebenfalls untersagt. Hier liegt Markenschutz durch Heinekingmedia vor." I 267 00:27:07,390 --> 00:27:10,190 don't understand trademark law. There are so many trademarks starting with this or 268 00:27:10,190 --> 00:27:15,429 just consisting of the letters DSB with partially overlapping registered use cases 269 00:27:15,429 --> 00:27:17,910 and their trademark doesn't have distinctive character, 270 00:27:17,910 --> 00:27:23,030 "Unterscheidungskraft", and I just don't understand it. By the way, there are other 271 00:27:23,030 --> 00:27:27,990 trademark "Digitales Schwarzes Brett" which is registered as a different one 272 00:27:27,990 --> 00:27:32,660 from DSB was once rejected as a national trademark just because it didn't have 273 00:27:32,660 --> 00:27:37,900 distinctive character. Why can there be European trademark laws without– European 274 00:27:37,900 --> 00:27:41,940 trademarks, without distinctive character? I do not understand and I'm not qualified 275 00:27:41,940 --> 00:27:47,020 to comment. "Eine App-Bereitstellung im Store ist dabei eine geschäftliche 276 00:27:47,020 --> 00:27:51,240 Tätigkeit, ganz egal welchem wirtschaftlichen Zweck diese folgt, es 277 00:27:51,240 --> 00:27:54,350 besteht Verwechslungsgefahr. Wir untersagen Ihnen hiermit die Benutzung der 278 00:27:54,350 --> 00:28:02,820 geschützten Wortmarke DSB letztmalig." Um, the first part is true. I had gotten lot 279 00:28:02,820 --> 00:28:05,710 wrong. It counts as "geschäftlicher Verkehr" when you provide a service even 280 00:28:05,710 --> 00:28:11,440 for free to the public. Er, there's danger of confusion, this has to be about the 281 00:28:11,440 --> 00:28:16,159 letters DSB, right? Because as I explained earlier our logo is completely unrelated. 282 00:28:16,159 --> 00:28:21,220 Either, I'm not too certain that there really is danger of confusion that 283 00:28:21,220 --> 00:28:26,140 Heinekingmedia is directly affected by or exclusively affected by. After all, one 284 00:28:26,140 --> 00:28:30,780 could also believe that it is an app that provides access to something related to 285 00:28:30,780 --> 00:28:35,100 the Danish railway company. Of course it does not, but it is about recognition 286 00:28:35,100 --> 00:28:39,600 value, which is not something that the DSB has exclusively for sure. "Wir untersagen 287 00:28:39,600 --> 00:28:43,850 Ihnen hiermit die Benutzung der geschützten Wortmarke DSB letztmalig." 288 00:28:43,850 --> 00:28:47,659 *undistinguishable" "Sollten Sie weiterhin gegen unsere deutlichen Aufforderungen 289 00:28:47,659 --> 00:28:53,390 verstoßen, werden wir den Fall an unsere rechtliche Vertretung, Herrn Doktor Selig 290 00:28:53,390 --> 00:28:58,630 übergeben. Dieser ist in dieser E-Mail bereits CC." Scaring us. "Ebenfalls werden 291 00:28:58,630 --> 00:29:03,289 wir weiterhin gegen jede Veröffentlichung einer solchen App vorgehen. Entsprechend 292 00:29:03,289 --> 00:29:07,530 dadurch entstehende Kosten würden wir bei Ihnen als Schadensersatz geltend machen. 293 00:29:07,530 --> 00:29:12,900 Wir bitten um zwingende Beachtung. Mit freundlichen Grüßen, Andreas Noack. Noag, 294 00:29:12,900 --> 00:29:19,669 Norg, Noack. That's the CEO of Heinekingmedia. Yeah, we are famous! We 295 00:29:19,669 --> 00:29:23,270 redirected this email to contributor Jasmich who had DSBdirect up on the Play 296 00:29:23,270 --> 00:29:27,270 Store at this point of time. And he decided to take it down and apologize. 297 00:29:27,270 --> 00:29:31,390 Suddenly, and this was the very next day he received an email that sounded a lot 298 00:29:31,390 --> 00:29:36,490 friendlier. "Hallo. Vielen Dank für Ihr Entgegenkommen. Wir finden Ihren Ansatz 299 00:29:36,490 --> 00:29:41,160 prinzipiell sehr gut. Allerdings hätten wir uns gewünscht, dass Sie uns vor 300 00:29:41,160 --> 00:29:44,540 Veröffentlichungen und Nutzung unserer API um Erlaubnis gebeten hätten." If we had 301 00:29:44,540 --> 00:29:50,250 asked for permission, I'm quite sure we would not have received it. "Dennoch 302 00:29:50,250 --> 00:29:58,480 möchten wir Ihr Engagement gerne würdigen, und würden Sie daher gerne zu uns nach 303 00:29:58,480 --> 00:30:02,640 Hannover einladen. Vielleicht können Sie uns mit Ihren Ideen helfen eine bessere 304 00:30:02,640 --> 00:30:08,110 App zu bauen? Vielleicht finden wir ja sogar einen Weg, dass Sie daran mitbauen? 305 00:30:08,110 --> 00:30:12,799 Gerne fördern wir junge Talente. Wir würden uns freuen, Sie kennenlernen zu 306 00:30:12,799 --> 00:30:16,700 dürfen. Ich freue mich auf Ihre Rückmeldung. Mit freundlichen Grüßen, 307 00:30:16,700 --> 00:30:21,230 Noack." I rather– I'll rather leave this largely uncommented. I don't know exactly 308 00:30:21,230 --> 00:30:27,179 what they want from us, but I guess we'll have to see. And that's the dramatic 309 00:30:27,179 --> 00:30:33,260 cliffhanger that we have to end our talk with. Events are yet to unroll. There's 310 00:30:33,260 --> 00:30:36,820 one thing that I can learn from this. Don't use other people's trademarks. 311 00:30:36,820 --> 00:30:41,270 Because trademark law is too complicated. Apologizing instead of being rebellious 312 00:30:41,270 --> 00:30:46,140 seems to work better, even if the thought of conflict intrigues you and you really 313 00:30:46,140 --> 00:30:50,950 do believe you're in the right, you probably just misunderstood the law. 314 00:30:50,950 --> 00:30:56,250 Alternatively, exclusively do such things anonymously. Decide beforehand what you 315 00:30:56,250 --> 00:30:59,690 want to put your name on. Thank you. 316 00:30:59,690 --> 00:31:00,690 *Applause* 317 00:31:00,690 --> 00:31:01,690 *postroll music* 318 00:31:01,690 --> 00:31:03,190 Subtitles created by c3subtitles.de in the year 2021. Join, and help us!