Durch Klaus Rodewig bin ich auf das Thema mit den COVID-19 Apps aufmerksam geworden. Der Beitrag zu Bruce Schneier habe ich auch durch ihn. Klaus ist ein cooler ITler und ein ausgewiesener Kenner der Security Szene. Leider werden wir uns dieses Jahr nicht zur macoun in FRA treffen, da diese Corona-bedingt ausfällt – sehr, sehr schade.
Der folgende Beitrag der Site mezdanak.de zeigt leider sehr deutlich, dass die Spötter wohl recht behalten. Die Corona Apps sind security mäßig überaus schlecht – zumindest, was sich bisher so zeigte. Wo soll da Vertrauen des Einzelenen entstehen für eine App, die mehr schlecht als recht zusammengeschuster wurde?
Was sind Universal Links eigentlich? Das sind diese Angaben auf Webseiten, um die – allerdings installierte – App dieser Seite anstelle der Webvariante auszuführen.
Wodurch weiß die Webseite, dass es eine App gibt, die mit dieser Webseite assoziiert ist? Des Rätsels Lösung ist die AASA – die Apple App Site Association, eine JSON-Datei, die alles beinhaltet.
Dabei gibt der erste rote Kasten die Apple Team ID an (zu finden unter „Certificates, Identifiers & Profiles“ im Developer-Bereich bei Apple). Der zweite Wert ist die Bundle ID, die entweder per Xcode (erkennbar am XC bei der App ID) oder im Developer Portal erstellt wird.
Wichtig ist, dass bei der App ID das Entitlement „Associated Domains“ ausgewählt ist. In Xcode wird dann bei den Einstellungen die Webseite angegeben, auf der sich die AASA-Datei (die Apple-JSON-Datei von oben) befindet. Die AASA kann entweder im WWW-Root liegen oder aber in einem versteckten Directory „.well-known“. Ich habe sie ins Root gelegt. Es gibt verschiedene Aussagen, die besagen, dass das mit dem Hidden-Directory entweder geht oder nicht, je nach dem wo man im Web schaut.
Zu der Associated Domain muss nun noch das Entitlement in Xcode angeben werden. Ich habe den Hinweis gelesen, wenn der Build gemacht wurde im Projektverzeichnis zu schauen, ob wirklich die „Projektname“.entitlement-Datei im Projekt mitenthalten ist. Ich selber hatte hiermit keine Probleme.
Der URL-Präfix bei der Associated Domain und dem Entitlement muss (für diesen Fall) zwingend „applinks:“ heißen.
Wenn das Projekt angelegt wird, ist ja – wie immer – die Bundle ID zu wählen. Diese muss ja zwingend mit der App ID korrelieren (wenn Xcode die Arbeit macht, kein Problem). Auch das Provisioning Profile muss natürlich die App ID beinhalten.
Was machte das ganze so schwierig und nervig? Die Anleitungen, die man im Netz bei Apple oder woanders findet, sind recht eindeutig. Doch es hat Stunden gedauert, bis ich schlußendlich den Universal Link hatte.
Folgend Dinge haben (mir) geholfen:
1. Eine .htaccess-Datei, die https erzwingt (sonst geht das lt. Apple nicht mit den Universal Links). 2. Das Erzwingen, dass die AASA-Datei an Apple mit dem richtigen MIME-Type JSON ausgeliefert wird. 3. Die AASA sollte man wie folgt erstellen: Touchen im Terminal, danach wurde sie per Terminal-Befehl in Visual Studio Code geöffnet und dann der der Inhalt eingepasted und gesichert. Ich habe sie auch getouched, dann aber mit Xcode bzw. TextWrangler erstellt. Ich habe sie dann mit Cyberduck übertragen und auf dem Webspace in den korrekten Namen umbenannt. 4. Das aber wohl alles entscheidende war die Tatsache, dass ich die Webseite nach unten gezogen habe. Und Wunder: Der Universal Link kam zu Tage.
Er deutete sich mit zart durschimmerndem Magenta links oben (rote Quadrat) als App Icon leicht an. Doch es hat sehr lange gedauert, bis ich das mit dem Runterziehen begriffen habe.
Hat mich richtig Nerven gekostet. Am Ende ganz einfach. Es musste nur eine .htaccess auf die Universal Link Seite und in dieser angegeben werden, dass die AASA-Datei mit dem richtigen MIME-Tye ausgeliefert wird – kinderleicht sozusagen! 😉
•••• Mit Klick auf die Abspielschaltfläche wird das Video im eingebetten IFrame gestartet. Das Vorschaubild kann schon auf diesem Blog vorhanden sein, so dass erst beim Abspielen eine Verbindung mit YouTube aufgebaut wird und Daten übertragen werden. ••••
Auch das Blog blog.softwing.de mag Kekse. Einige Cookies sind unerlässlich, andere helfen, das Blog für Dich zu verbessern. Du hast das Recht den nur funktionsfähigen Cookies zuzustimmen und Deine Einwilligung jederzeit zu ändern. Du bist unter 16 Jahre alt? Dann kannst Du nur den nur funktionsfähigen Cookies zustimmen oder Du kannst Deine Eltern oder Deinen Erziehungsberechtigten bitten, mit Dir gemeinsam anderen Cookies zuzustimmen.
Funktionale Cookies Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich, um die Nutzung eines bestimmten Dienstes zu ermöglichen, der ausdrücklich vom Teilnehmer oder Benutzer angefordert wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff wird ausschließlich zu statistischen Zwecken verwendet.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung bzw. der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu tracken.
