Kommentar zum Dev Corner Artikel Live Activities in Mac & i Heft 1/2023

Ich habe ein Abo für Mac & i und bin immer besonders gespannt auf die Developer's Corner.

Kurzfassung

Dieses Mal habe ich den Artikel gelesen, um zu schauen, ob ich noch etwas zur Programmierung des iOS-16-Features "Live Activities" lernen kann. Dabei ist mir als iOS-Entwickler aufgefallen, daß die Passage, bei der es um Notifications geht, schlicht veraltet und falsch, und die, bei der es um Deep Links geht, veraltet und ein Sicherheitsrisiko ist.

Ich beginne mit der Stelle über Notifications und widme mich danach den Problemen mit den Deep Links.

Notifications

Zu Beginn führen sie als Motivation für den Einsatz von Live Activies an, daß diese aktualisiert werden können, während das mit Notifications angeblich nicht möglich wäre:

Das war bis 2015 so. Die Aussagen sind jedoch seit iOS 10 bzw. seit 2016 und der Einführung des User Notifications Framework falsch. Erstmals wurde das in der WWDC 2016 - Session 707 Introduction to Notifications erklärt.

Schauen wir uns zuerst die lokalen Notfications an und weiter unten die Remote Notifications.

Lokale Benachrichtigungen (Local Notifications) löschen und aktualisieren

Lokale Notifications können sowohl gelöscht als auch aktualisiert werden, wie man in diesem Zitat aus dem Transcript des Videos lesen kann:

Code-Beispiel aus dem PDF zu "Introduction to Notifications", das zeigt, wie man lokale Notifications löscht:

// Pending Notification Removal
let gameStartIdentifier = "game1.start.identifier"
let gameStartRequest = UNNotificationRequest(identifier: gameStartIdentifier,
                                             content: content,
                                             trigger: startTrigger)
UNUserNotificationCenter.current().add(gameStartRequest) { (error) in // ... }
// Game was cancelled
UNUserNotificationCenter.current()
    .removePendingNotificationRequests(withIdentifiers: [gameStartIdentifier])
}

// Delivered Notification Removal
let gameScoreIdentifier = "game1.score.identifier"
let gameScoreRequest = UNNotificationRequest(identifier: gameScoreIdentifier,
                                             content: scoreContent,
                                             trigger: trigger)
UNUserNotificationCenter.current().add(gameScoreRequest) { (error) in // ... }
// Wrong game score was published
UNUserNotificationCenter.current()
    .removeDeliveredNotifications(withIdentifiers: [gameScoreIdentifier])

Code-Beispiel aus dem PDF zu "Introduction to Notifications", das zeigt, wie man lokale Notifications aktualisiert:

// Pending Notification Update
let gameStartIdentifier = "game1.start.identifier"
let gameStartRequest = UNNotificationRequest(identifier: gameStartIdentifier,
                                             content: content,
                                             trigger: startTrigger)
UNUserNotificationCenter.current().add(gameStartRequest) { (error) in // ... }
// Game start time was updated
let updatedGameStartRequest = UNNotificationRequest(identifier: gameStartIdentifier,
                                                    content: content,
                                                    trigger: newStartTrigger)
UNUserNotificationCenter.current().add(updatedGameStartRequest) { (error) in // ... }

// Delivered Notification Update
let gameScoreIdentifier = "game1.score.identifier"
let gameScoreRequest = UNNotificationRequest(identifier: gameScoreIdentifier,
                                             content: scoreContent,
                                             trigger: trigger)
UNUserNotificationCenter.current().add(gameScoreRequest) { (error) in // ... }
// Score game was updated
let updateGameScoreRequest = UNNotificationRequest(identifier: gameScoreIdentifier,
                                                   content: newScoreContent,
                                                   trigger: newTrigger)
UNUserNotificationCenter.current().add(updateGameScoreRequest) { (error) in // ... }

Push Server Benachrichtigungen (Remote Notifications) löschen und aktualisieren

Und auch Remote Notifications kann man sogar nach ihrer Zustellung löschen oder wahlweise aktualisieren:

Um eine Remote Notification zu aktualisieren, muß der Push Server einfach nur eine weitere Push Notification mit dem korrigiertem Inhalt und derselben apns-collapse-id schicken:

Um eine Remote Notification zu löschen, muß der Push Server einfach nur eine weitere Push Notification schicken mit derselben apns-id oder derselben apns-collapse-id und content-available mit dem Wert 1. Mit dieser trickreichen Aktualisierung wird aus der normalen sichtbaren eine unsichtbare "silent" Remote Push Notification. Hier ist ein weiteres Beispiel mit einem kurzen Video, das ebenso vorgeht und zusätzlich noch lokal

UNUserNotificationCenter.current().removeDeliveredNotifications(withIdentifiers: [idToDelete])

aufruft.

Literatur zum Aktualisieren und Löschen von Notifications:

• Apple Push Notification Service: Payload Key Reference
• Sebastian Osiński: Implementing removable remote notifications on iOS
• Milan Kamilya: Remove a Published Push Notification Remotely iOS
• Transcript von WWDC 2016 - Session 707 Introduction to Notifications
• Apple: Sending notification requests to APNs
• Apple: PDF mit Beispiel-Code aus WWDC 2016 - Session 707 Introduction to Notifications
• Apple: UNUserNotificationCenter The central object for managing notification-related activities for your app

Deep Links

Für Deeplinks in die App verwenden sie ein Custom URL Scheme:

.onOpenURL { url in
	guard url.scheme == "de.agendaapp" else { return }
	if url.host () == "next" { 
		agenda.startNextTopic()
	}
}

Apple rät seit der Vorstellung von Universal Links mit iOS 9, also seit 2015, von Custom URL Schemes ab und empfiehlt stattdessen Universal Links zu verwenden. Solche Universal Links haben viele Vorteile, mir geht es in diesem Zusammenhang jedoch speziell um den Sicherheitsgewinn, der einer der Hauptgründe für Apple war, Universal Links einzuführen.

Im Gegensatz zu Custom URL Schemes können Universal Links nicht von anderen Apps feindlich übernommen werden. Je nachdem in welcher Reihenfolge Apps installiert werden, betrachtet iOS die eine oder andere App als zuständig, falls beide dasselbe URL Schema für ihre Deeplinks verwenden.

Das Problem ist seit vielen Jahren bekannt als URL Scheme Hijacking.

Warum der Artikel und das Demo-Projekt dennoch veraltete unsichere Technik verwenden, ist mir schleierhaft. Um so mehr als einer der beiden Autoren als "Experte für mobile Sicherheit sowie den Einsatz von iOS-Geräten im Unternehmensumfeld" beschrieben wird.

Eine mögliche Erklärung für solch einen Lapsus könnte sein, daß Universal Links einen Webserver erfordern, mit dem iOS für die App jeden Link zur Sicherheit abgleicht. Evtl. war das der Grund, den simplen, aber unsicheren Weg über Custom URL Schemes zu nehmen. Aber dann würde ich zumindest einen Hinweis erwarten, daß hier der Einfachheit halber eine nicht für die Praxis geeignete Abkürzung genommen wurde.

Literatur zu Custom URL Schemes und Universal Links:

• Apple: Defining a custom URL scheme for your app rät von Custom URL Schemes ab.
• Apple: Support Universal Links sagt, warum Universal Links die sicherere Alternative sind.
• David Thiel: iOS Application Security, S. 131ff erklärt das Sicherheitsproblem von Custom URL Schemes und nennt Universal Links als sichere Alternative.
• Ostorlab: iOS URL Scheme Hijacking erläutert das Hijacking und rät zu Universal Links.
• The Hacker News: iOS URL Scheme Could Let App-in-the-Middle Attackers Hijack Your Accounts beschreibt, warum Logins durch Custom URL Schemes anfällig sind für Account-Übernahme.

Fazit

Wenn mir fachliche Fehler auffallen bei den Themen, mit denen ich mich selbst gut auskenne, dann frage ich mich, ob andere Themenbereiche im Artikel, mit denen ich mich weniger auskenne, vielleicht auch problematisch sind. Mac & i sollte gründlicher recherchieren, wenn sie nicht das Leservertrauen in ihre Artikel verlieren wollen.

---