Migration auf neues MacBookPro: Via TimeMachine oder von Mac zu Mac?

[thulium]

Die Migration vom TM-Backup lief glatt durch.

Einen ärgerlichen Bug gibt es: die Einstellungen des Launchpads wurden nicht übertragen. Das ist viel Handarbeit, es so einzurichten, wie's war.

Unschön auch, dass man alle erteilten "Erlaubnisse" erneut gewähren muss. Dabei war das Backup verschlüsselt.

Weiterhin ist es nötig, sich bei Diensten/Apps mit Anmeldung neu anzumelden.
Aus meiner bescheidenen Sicht sind das alles Bugs. Ein Wiederherstellungsprozess aus einem Backup sollte nicht einen einzigen solcher Schritte erfordern.

Insgesamt bin ich jedoch sehr zufrieden mit dem Prozess.

 

[lulesi]

Was meinst Du mit "Dienste/Apps"?
Aus Sicherheitsgründen muss man sich mit der Apple ID neu anmelden, das ist kein Bug.

Schon mal mit Windows auf einen neuen Rechner umgezogen?
Wie klappte das?

 

[thulium]

@lulesi
"Sicherheitsgründe" empfinde ich bei einer Migration von einem verschlüsselten Backupmedium als völlig unplausibel. Aber ich lasse mich gerne aufklären, wenn ich damit falsch liege.

Es geht sogar nach hinten los. Je öfter Nutzer vermeidbar mit immer wieder neuen (mehrstufigen) Anmeldeprozessen und Zustimmungsanfragen belästigt werden, desto unvorsichtiger werden sie.

 

[lisanet]

... geht es bei den "Diensteanmeldungen" um irgendwelche Webseiten / Web-Dienste? Da könnte das Ganze dadurch erklärbar sein, da deren Anmeldedaten in Cookies gespeichert werden. Und Cookies aus Backups wiederherzustellen widerspricht für mich dem (wünschenswertem) sehr restriktiven Umgang mit Cookies.

Hast du die Frage nach automatischer Einrichtung von iCloud beim Restore verneint? Könnte auch so was ausmachen.

Für mich ist für die Sache "Berechtigungen" folgendes Sczenario technisch gesehen durchaus logisch:

Die Berechtigungen eines Programmes basieren auf dem binary eines App-Bundles, nicht auf dem App-Namen.

Wenn du von einem Intel auf einen Apple Silicon Mac umsteigst, dann müssen aus dieser Sicht eben alle Berechtigungen neu erteilt werden, weil alle Berechtigungen im Backup immer auf dem Intel-binary basierten. Auf AS müssen aber a) ein Intel-binary erst durch Rosetta übersetzt werden und dann wird natürlich für das übersetze AS-binary die Berechtigung notwendig und b) bei Universal-Apps wird nun eben das AS-binary verwendet für das im Backup keine Berechtigung vorhanden ist, da ja bisher das Intel-binary ausgeführt wurde.

Der Ruf "Das ist ein Bug!" ist oft zu kurz gesprungen. Moderne Systeme sind halt etwas komplexer, als man sich das so einfach auf die Schnelle zusammen reimt.

 

[bernie313]

Sicherheitsgründe" empfinde ich bei einer Migration von einem verschlüsselten Backupmedium als völlig unplausibel.

Das neue Gerät muss sich bei allen sicherheitsrelevanten Diensten oder auch Programmen neu anmelden, es ist neu und für diese Dienste eben nicht autorisiert, daran ändert auch ein Backup eines anderen Gerätes nichts denn diese Einstellungen, Token oder wie das auch immer geregelt wird beziehen sich nur auf das andere Gerät.

 

[thulium]

... geht es bei den "Diensteanmeldungen" um irgendwelche Webseiten / Web-Dienste? Da könnte das Ganze dadurch erklärbar sein, da deren Anmeldedaten in Cookies gespeichert werden. Und Cookies aus Backups wiederherzustellen widerspricht für mich dem (wünschenswertem) sehr restriktiven Umgang mit Cookies.

Nein, es geht nicht um Websites.

Beispiele, wo eine erneute Anmeldung nötig war:
Spotify.app
...

Beispiele, wo ein erneutes Erteilen von "Zugriffsberechtigungen" nötig war:
Dropbox.app
TypeIt4me.app
Forklift.app
Sketup.app
...

Hast du die Frage nach automatischer Einrichtung von iCloud beim Restore verneint? Könnte auch so was ausmachen.

Das habe ich bejaht.

Nochmal zur Einordnung meiner kritischen Aussage:
Ganz bewußt habe ich geschrieben, dass ich insgesamt sehr zufrieden mit dem Prozess bin. Und das war keine Floskel.

Die erwähnten manuellen Nacharbeiten bewerte ich jedoch als Bug. Entweder bei Apple bzw. bei den App-Anbietern.
"Sicherheitsgründe", die eine Wiederholung von Anmeldungen oder Berechtigungen rechtfertigen würden, sehe ich nirgendwo.

Wenn du von einem Intel auf einen Apple Silicon Mac umsteigst, dann müssen aus dieser Sicht eben alle Berechtigungen neu erteilt werden, weil alle Berechtigungen im Backup immer auf dem Intel-binary basierten. Auf AS müssen aber a) ein Intel-binary erst durch Rosetta übersetzt werden und dann wird natürlich für das übersetze AS-binary die Berechtigung notwendig und b) bei Universal-Apps wird nun eben das AS-binary verwendet für das im Backup keine Berechtigung vorhanden ist, da ja bisher das Intel-binary ausgeführt wurde.

Der Ruf "Das ist ein Bug!" ist oft zu kurz gesprungen. Moderne Systeme sind halt etwas komplexer, als man sich das so einfach auf die Schnelle zusammen reimt.

Natürlich sind solche Systeme komplex. Und natürlich ist es zusätzlicher Programmieraufwand die Binaries korrekt zu "mappen", so dass die Berechtigungen nicht erneut abgefragt werden müssen.

Entscheidend ist, ob es technische möglich wäre, zu erreichen, dass Nutzer nach einer Migration die Berechtigungen sie nicht erneut erteilen müssen.
Wenn das bejaht werden kann, ist die Bewertung "Bug" IMHO gerechtfertigt.

Zum Launchpad nochmal nachgehakt, aus Neugier:
Kennt ihr den von mir beschriebenen Fehler auch?

 

[thulium]

Token oder wie das auch immer geregelt wird beziehen sich nur auf das andere Gerät

Wenn das so ist, sollten geeignete Prozesse entwickelt werden, die nach einer Migration keinerlei Nacharbeit erfordern.
Denkst Du, das wäre unmöglich?

 

[bernie313]

Denkst Du, das wäre unmöglich?

Ja

 

[lulesi]

Beispiele, wo eine erneute Anmeldung nötig war:
Spotify.app
...

Beispiele, wo ein erneutes Erteilen von "Zugriffsberechtigungen" nötig war:
Dropbox.app
TypeIt4me.app
Forklift.app
Sketup.app

Das sind alles Fremdanbieter Apps, die nichts mit Apple zu tun haben.
Das sind Fremdanbieter, deren Sicherheitskonzept es nicht erlauben einfach per Backup und Restore
Zugänge auf andere Rechner zu kopieren. Meist hängt es damit zusammen, dass aus der Geräte-ID und dem
Passwort ein verschlüsseltes Token gebildet wird, das sich durch den Gerätewechsel ändert.

Wenn Anbieter aber ein einfacheres Sicherheitssystem haben, und es genügt das Passwort im Schlüsselbund
zu nutzen, ist es natürlich bequemer aber unsicherer.

Ähnliches gibt es auch bei iPhones, sämtliche Bankzugänge bzw PushTan Anwendungen sind an genau das eine
Gerät gekoppelt und müssen beim Gerätewechsel neu installiert und freigeschaltet werden.

Ähnliches gilt für manche Email Provider wie google oder Microsoft, wo man auch zwingend explizit neu anmelden muss.

 

[thulium]

@lulesi
Danke für die Infos.

Ich halte es für kontraproduktiv für das Ziel "Sicherheit", wenn etwas so Gewöhnliches wie Migration (das ist ja ein Standardfall und nix Exotisches) nicht ohne manuelles "Nacharbeiten" geht.

Ein guter Sicherheitsprozess muss das Thema "Migration" behandeln und darf sich davor nicht wegducken.

Ich erlebe es vielfach im Alltag, dass Nutzer endlos genervt sind von der schier unendlichen Anzahl an Authentifizierungen, wieder und immer wieder. In zig Variationen.

Das muss IMHO fundamental überarbeitet und standardisiert werden. Wie genau, das würde hier zu weit führen und meine Kenntnisse sowieso übersteigen.
Stichworte wie FIDO und elektronischer Perso.

Wesentlich ist aus dem Blickwinkel der Usability das Ziel: Vereinfachung und Erleichterung. Gute technische Realisierungen lassen sich bestimmt finden.
Und Apple hätte die Marktmacht, Anbietern Standardverfahren vorzuschreiben.

Das alles erzeugt eine wirklich Verbesserung der Sicherheit.

Der heutige Kuddelmuddel und die Nerverei ist völlig kontraproduktiv.

 

[bernie313]

Stichworte wie FIDO und elektronischer Perso.

Deinen Ausführungen stimme ich zu, allerdings darf Vereinfachung und Erleichterung nicht einhergehen mit der üblichen Vorgehensweise, das Bequemlichkeit und Sicherheit einander spinnefeind sind.
zur Zeit gibt es ja durchaus Möglichkeiten abseits von gerätebezogene Sicherheitsüberprüfungen auch Portable übertragbare Lösungen zu nutzen, die dann andere Authentifizierungen erfordern.
zu den Stichworten sei nur angemerkt, das der elektronische perso in kleinster Weise sicher ist und solange derartig schlampig programmierte Software unters Volk gebracht wird, wird das vertrauen in staatlich organisierter Sicherheit nicht unbedingt gefördert.
Auf absehbare Zeit wird also die Migration nach wie vor Handarbeit erfordern.

 

[thulium]

Deinen Ausführungen stimme ich zu, allerdings darf Vereinfachung und Erleichterung nicht einhergehen mit der üblichen Vorgehensweise, das Bequemlichkeit und Sicherheit einander spinnefeind sind.

Mir geht es - natürlich - nicht um maximale Bequemlichkeit.

Die Verfahren sollten solange optimiert werden, bis eine Gruppe von renomierten Usability-Experten nichts mehr daran auszusetzen hat ; )
In enger Zusammenarbeit und Abstimmung mit renommierten Sicherheitsexperten.

Noch ein Beispiel für eine Zumutung:
zwei Geräte sind über ein System eng miteinander verzahnt: iCloud
Der Nutzer authentifiziert sich auf dem einen Gerät bei einem Dienst/einer App.

Selbstverständlich sollte er diese Authentifizierung nicht nochmals auf dem anderen Gerät durchführen müssen.

 

[lisanet]

Noch ein Beispiel für eine Zumutung:
zwei Geräte sind über ein System eng miteinander verzahnt: iCloud
Der Nutzer authentifiziert sich auf dem einen Gerät bei einem Dienst/einer App.

so einfach wie du tust ist das auch wieder nicht. Denke dir das mal durch, wo dann Lücken in einer sicheren Authentifizierung entstehen können.

Ist die App bei iCloud authentifiziert? Gibt es 2FA bei der App?

Und mal ganz abseits davon: Hast du denn ein Problem mit einer App, die sich über iCloud authentifiziert und beim Restore auf einem neuen Rechner erneut authentifiziert werden müsste? Oder hast du nicht eher die erneuten Authentifizierung bei Apps erlebt, die eben nicht per iCloud "authentifiziert" sind, sondern wie deine Beispiele weiter oben eigentlich alle auf eigene Authentifizierungsmaßnahmen setzen?

Mir kommt es zudem so vor, als ob du deine kritik an fehlender Usability nur darauf beziehst, was du als sinnvoll erachtest und nicht was tatsächlich aus Sicherheitsaspekten notwendig ist, um auf einem anderen Rechner eine Kompromittierung zu verhindern. Zudem kommt es mir so vor, als ob du deine Erfahrungen mit der Berechtigungserteilung von Zugriffen auf bestimmte Verzeichnisse mit einem erneuten Login bei Web-Services / Streaming-Diensten / Service-Anbietern vermischt und durcheinander bringst.

 

[thulium]

@lisanet
Es geht mir nicht darum, ob das einfach zu implementieren ist.
Das Konzept lautet vielmehr bei guter Usability: Einer macht sich viel Arbeit, damit viele wenig Arbeit haben.

Weiter oben schrieb ich ja auch, dass es um moderne Standards bei der Authentifizierung geht, nicht um Feld-Wald-und-Wiesen-Methoden. Und darum, dass Apple diese Standards dann zwingend vorschreibt.

Du erwähnst ja, dass die "Authentifizierung via iCloud" kein manuelles erneutes Authentifizieren erfordert.
Wenn das so ist, würdest Du denn befürworten, dass Apple eine solche Authentifizierungweise vorschreibt?

Zu Deiner Vermutung, ich würde Sicherheitsaspekte nicht als nötig erachten: da irrst Du.
Ich bin selber in diesem Bereich nicht kompetent, wie ich schon schrieb, daher kann ich dazu nichts eigenes sagen.
Siehe auch meine Anmerkung im letzten Posting "In enger Zusammenarbeit und Abstimmung mit renommierten Sicherheitsexperten."

Mir geht es vor allem um die Richtung! Ich wünsche mir weit mehr Anstrengungen der Plattformbetreiber MS und Apple die Usability zu Authenfizierungsverfahren zu verbessern und zu vereinheitlichen.

Zudem kommt es mir so vor, als ob du deine Erfahrungen mit der Berechtigungserteilung von Zugriffen auf bestimmte Verzeichnisse mit einem erneuten Login bei Web-Services / Streaming-Diensten / Service-Anbietern vermischt und durcheinander bringst.

Wie schon erwähnt, es geht mir nicht um Web-Services. Nur um Apps.

 

[L with]

@lulesi
Ich erlebe es vielfach im Alltag, dass Nutzer endlos genervt sind von der schier unendlichen Anzahl an Authentifizierungen, wieder und immer wieder. In zig Variationen.

Amen! Amen! Dazu kommt, dass sich die Prozesse im Allgemeinen auch noch über die Dauer verändern und insgesamt einfach häufig undurchschaubar kompliziert sind.
Ein Freischaldcode hier, noch einer und noch einer und dort muss dieses, an anderer Stelle jenes - wie, drei mal falsch?... ach, es geht plötzlich um den Code.
Vieles wurde verkopft entworfen, aber nicht aus der Sicht des Anwenders, der das nicht täglich macht, sondern vielleicht ein mal in zwei Jahren.
So habe ich vor ein paar Jahren mein Google-Kontro geschrottet bzw. als Usernamen meine eigene Domain gegen so ein scheiß schlagmichtot2345XYZ@gmail.com ersetzt bekommen.
In einem anderen Fall klickte ein Freund von mir unbedarft bei Chrome auf "Konto hinzufügen". Nun ist diese zweite Email plötzlich integraler Bestandteil seines Accounts. Untrennbar.
Es geht hier nicht um Google und Chrome, aber es ist ein industrieweites Problem. Die Prozesse sind kompliziert, oft noch nicht mal dokumentiert und man muss manchmal hellwach sein, um oft nachvollziehen zu können,
was gerade passiert.

Ein anderes Beispiel ist das Verwirrspiel mit dem Schlüsselbund. Mein Mac und mein iPhone tauschen die Passwörter natürlich ebenso wie die Lesezeichen via iCloud. Ich benutze zwar standardmäßig iPassword, aber es ist immer
gut, es auch im Browser zu haben. Was soll ich sagen? Manche Passwörter gibt es auf beiden Geräten, andere wiederum nicht. Why? Das sind so Prozesse from hell.

 

[lisanet]

@lisanet
Es geht mir nicht darum, ob das einfach zu implementieren ist.
Das Konzept lautet vielmehr bei guter Usability: Einer macht sich viel Arbeit, damit viele wenig Arbeit haben.

Weiter oben schrieb ich ja auch, dass es um moderne Standards bei der Authentifizierung geht, nicht um Feld-Wald-und-Wiesen-Methoden. Und darum, dass Apple diese Standards dann zwingend vorschreibt.

Du erwähnst ja, dass die "Authentifizierung via iCloud" kein manuelles erneutes Authentifizieren erfordert.
Wenn das so ist, würdest Du denn befürworten, dass Apple eine solche Authentifizierungweise vorschreibt?

Zu Deiner Vermutung, ich würde Sicherheitsaspekte nicht als nötig erachten: da irrst Du.
Ich bin selber in diesem Bereich nicht kompetent, wie ich schon schrieb, daher kann ich dazu nichts eigenes sagen.
Siehe auch meine Anmerkung im letzten Posting "In enger Zusammenarbeit und Abstimmung mit renommierten Sicherheitsexperten."

Mir geht es vor allem um die Richtung! Ich wünsche mir weit mehr Anstrengungen der Plattformbetreiber MS und Apple die Usability zu Authenfizierungsverfahren zu verbessern und zu vereinheitlichen.

Wie schon erwähnt, es geht mir nicht um Web-Services. Nur um Apps.

mann, mann, mann, ich habe den Eindruck, dass du gefühlt bei jeder Antwort die dir gegeben wird, einen neuen Aspekt herein bringst, der nichts mit der Antwort zu tun hat und du dadurch permanent die Antworten in Frage stellst.

Ich habe nirgends was von einfach zu implementieren geschrieben, sondern dass du es dir zu einfach machst, deine Anforderungen als umsetzbar darzustellen und du dir das erst mal nicht selbst durchdenkst.

Auch deine Behauptung, dass du moderne Standards forderst und das bisherige als Feld-Wald-und-Wiesen-Methode darstellst haben nichts mit den Antworten von mir und bernie313 zu tun.

Ich habe dir bereits geschrieben, dass es für mich durchaus logische Szenarien gibt, die eine erneute Authentifizierung erforderlich machen. Erforderlich. Das hat nun mal leider nichts mit mit einer von dir proklamierten Feld-Wald-und-Wiesen-Methode zu tun, sondern es gibt eben Szenarien, die es logisch erfordern so zu handeln. @bernie313 hat dir dazu auch das Beispiel mit den Token genannt. Und ich habe es als Web-Service bezeichnet.

Und du kommst nun her und behauptest, dass es dir nicht um Web-Services gehen würde, nennst aber gleichzeitig weiter oben z.B. Spotify und Dropbox.

Meinem dezentesten Hinweis, ob es sich nicht vielleicht doch um Apps handelt die sich nicht über iCloud authentifizieren gehts du ebenso einfach nicht nach und kommst nicht auf die Idee, dass mal zu durchdenken.: Hinweis: Spotify und Dropbox.

Aber was soll's. Mir wird das hier zu anstrengend, dir immer erneut belegen zu müssen, dass das was ich schreibe Sinn ergibt / korrekt ist / erforderlich ist.

 

[jubo14]

Ich habe den Eindruck, dass hier "Usability" mit Bequemlichkeit, oder weniger neutral, Faulheit verwechselt wird.
Und vor Allem, dass völlig aus dem Auge verloren wird, dass es bei Software um die einfache Bedienung geht. Die Migration ist eben nicht die vorrangige Nutzung einer Software, sie ich die Ausnahme.

Klar kann man sich eine Vereinheitlichung bei der Migration wünschen. Nur dürfte die völlig anders aussehen, als hier offensichtlich gewünscht.
Beim Zugriff auf Online-Banking-Konten oder Firmennetze mit personenbezogenen Daten, ist es nun mal erforderlich, dass es den "einfachen Weg" einfach nicht geben darf!
Während ich es von meiner Bank schlicht verlange, dass sie bei neuen Geräten, die mit meinem Konto kommunizieren wollen, ein paar Sicherheits-Hürden einbaut, bei meinem Firmen-Account es völlig normal ist, dass ich erst auf Daten zugreifen kann, wenn mein neuer Rechner dazu autorisiert wird, gibt es nun mal ein paar andere Bereiche, wo ich diesen Aufwand ehr weniger bereit bin zu treiben.
Deswegen wird es zwangsläufig immer unterschiedliche Konzepte geben müssen.

 

[thulium]

@lisanet
Es war nicht meine Absicht, Dich zu verärgern, das tut mir leid. Du weißt, dass ich Deine Beiträge außerordentlich schätze.

Mir geht es hier nie darum, jemanden zu verärgern.

... sondern dass du es dir zu einfach machst, deine Anforderungen als umsetzbar darzustellen und du dir das erst mal nicht selbst durchdenkst.

Ich lasse mich wirklich gerne belehren. Wenn Du/ihr sagt, dass keinerlei Wege existieren, das Ziel (Anmeldung bei einer App auf zweitem Gerät ohne erneute Anmeldung) umzusetzen, akzeptiere ich das.

Du hast z.B. ungleich tiefere technische Kenntnisse als ich. Daher fällt es Dir naturgemäß leicht, Ausnahmefälle zu nennen.

In einer guten Debatte ist es nützlich sich vor einer weiteren Argumentation über Ziele zu verständigen. Also "Ist Usability-Ziel A sinnvoll?" "Wenn ja: kann es technisch in der überwiegenden Zahl der Fälle umgesetzt werden? Was wäre dafür nötig? In welchen Usecases kann es nicht umgesetzt werden?"

Hier geht es IMHO oft zu schnell um spezifische einzelne Fälle, ohne zuvor mal die Richtung einer Debatte zu klären.

sondern es gibt eben Szenarien, die es logisch erfordern so zu handeln. @bernie313 hat dir dazu auch das Beispiel mit den Token genannt. Und ich habe es als Web-Service bezeichnet.

Hier verstehe ich eure Argumentation leider noch nicht.
Ist es richtig, dass ihr sagt, es existieren keine anderen Methoden (hier wäre es ein gerätespezifisches Token), die die Aufgabe ebenfalls lösen könnten, aber mit besserer Usability?

Während ich es von meiner Bank schlicht verlange, dass sie bei neuen Geräten, die mit meinem Konto kommunizieren wollen, ein paar Sicherheits-Hürden einbaut, bei meinem Firmen-Account es völlig normal ist, dass ich erst auf Daten zugreifen kann, wenn mein neuer Rechner dazu autorisiert wird, gibt es nun mal ein paar andere Bereiche, wo ich diesen Aufwand ehr weniger bereit bin zu treiben.

Klar, ich plädiere natürlich auch für Sicherheitshürden bei sensiblen Diensten.
Die Frage ist, wie sie ausgestaltet sind.

Wenn auf Gerät A (Teil eines Systems, damit ist z.B. iCloud gemeint) ein Banking-App bereits authenfiziert ist und ein Gerät B hinzukommt, dann könnte z.B. auf Gerät A die App ein Bestätigungsfenster aufpoppen lassen, wenn die Banking App auf dem neuen Gerät B geöffnet wird.
Also völlig ohne erneute Eingaben von Codes.

Analog zu Hardware-Methoden wie das Drücken eines Knopfes auf einem Router, wenn Geräte verbunden werden.

Solche Sachen meine ich:
Gibt es Verfahren, die Sicherheit gewährleisten, die aber dennoch nicht "nerven"?

Meine Vermutung: ja, die gibt es.

 

[tocotronaut]

Noch ein Beispiel für eine Zumutung:
zwei Geräte sind über ein System eng miteinander verzahnt: iCloud
Der Nutzer authentifiziert sich auf dem einen Gerät bei einem Dienst/einer App.

Selbstverständlich sollte er diese Authentifizierung nicht nochmals auf dem anderen Gerät durchführen müssen.

Doch.
Gerade bei der iCloud ist essentieller bestandteil der Sicherheitsarchitektur, dass jedes einzelne gerät als vertrauenswürdiges Gerät authorisiert wird.
Und jedes neue gerät muss individuell behandelt werden.

Zum teil musst du sogar die Passörter von anderen Geräten eingben, um an die ganz sensiblen informationen (insbesondere iCloud Schlüsselbund) zu kommen.
Dann fragt das Macbook plötzlich nach dem Entsperrcode für das iPhone oder iPad. Zum teil auch für zwei andere geräte hintereinander.

Auch muss die Authorisierung eines Gerätes durchaus mal (Zufallsbasiert oder nach einer gewissen zeit der nichtnutzung) erneuert werden.
(sie müssen sich erneut anmelden um die Dienste weiterhin nutzen zu können)

Auch OAuth (2) als Authorisiungsstandard erlaubt es nicht, dass ein konto oder eine anmeldung auf ein neues gerät übertragen wird...

 

[lisanet]

Wenn auf Gerät A (Teil eines Systems, damit ist z.B. iCloud gemeint) ein Banking-App bereits authenfiziert ist

du verstehst es immer noch nicht: nicht die Banking-App selbst wird authentifiziert, sondern der Server der Bank muss wissen, dass das Gerät authentifiziert ist. Woher soll der Server der Bank nun also wissen, welche Geräte du dir kaufst, installierst, verkaufst etc.? Was du vorschlägst bedeutet dann: du willst mit Gerät A eine App auf B authentifizieren, diese soll dann dem Server sagen: ich bin vom gleichen Nutzer nur ein neues Gerät. Und nun verlangst du das der Server das glaubt. Welche Sicherheit hat den der Server, dass diese Aussage korrekt ist? Der Server hat keinen Zugang zu den Daten deiner iCloud und kann daher die Aussage der App nicht verifizieren. Du siehst, genau an dieser Verifizierung hängt es also.

Hier kommen dann die Token ins Spiel: Die sind so gestaltet, dass sie geräteabhängig sind. Der Server kennt dieses Token und kann daher das Gerät verifizieren. Neues Gerät und altes Token (aus dem Backup) funktioniert also nicht. Es ist _erforderlich_ das neue Gerät - nicht die App _ zu authentifizieren. Mit einem neuen token.

So, jetzt habe ich zum letzen Mal versucht dir was beizubringen. Es wäre schön, wenn du mal nicht nur drauf los fragst, sondern dich auch mal über die Antworten selbst weiter informierst und nicht alles in Frage stellst. Ein klein wenig Mitarbeit wäre schöne. Denn: ich bin nicht dafür da, dein Wissen zu erweitern. ich mache das hier aus Freude daran. Und mit deiner permanenten In-Frage-Stellerei wird es einfach Spaß, da ich eben keine Mitarbeit erkenne.