wertzuiop123

• 16.06.26
• 17:44
• Artikel
• +1-1

@topsi.kret: wenn man das schon 2-3mal genutzt hat, erkennt man das an den wörtern und der satzstellung. das tool ist meist so generisch, dass die phrasen eben so vorkommen (zu einfach, sehr klar, nicht zu - zeigt aber, die so gesetzten anführungszeichen, dreisatz an beispielen am ende eines satzes wie "Frust, politischer Entfremdung oder Unzufriedenheit..." usw.)

ob man das "braucht" steht nicht zu debatte. um deine frage zu beantworten: nein. OT kann auch sagen -> "hier 3 stichworte, formulier mir aus" ... kommt dann so raus

• 16.06.26
• 17:15
• Artikel
• +1-1

@Schwips2020: schön per chatgpt geschrieben

• 10.06.26
• 20:38
• Artikel

@Desoxyribonuklein: Ja, beim Grundprinzip sind wir da gar nicht weit auseinander. Ein Trusted Agent bzw. eine OS-vermittelte Sicherheitsschicht ist genau der richtige Ansatz.

der Streitpunkt ist für nicht Trusted Agent ja oder nein.
Der Streitpunkt ist: Ist dieser Trusted Agent neutral und gleichwertig? Also darf Apple Intelligence über diese Schicht exakt dieselben Arten von Kontext, App-Actions, Defaults und Systemfunktionen nutzen wie ein anderer bewusst gewählter Assistant? Oder hat Apple intern weiter private Abkürzungen, mehr Kontext, weniger Reibung und bessere Systemrechte?

Wenn der Trusted Agent wirklich bedeutet iOS bleibt Sicherheitsgrenze, alle Assistenten laufen über dieselben Scopes, Permissions, Intents, Confirmations und Widerrufsrechte, dann ist das aus meiner Sicht genau die technische Lösung.

Wenn er aber bedeutet Apple baut den Wächter, Apple definiert die Regeln und Apple Intelligence bekommt trotzdem mehr Möglichkeiten als alle anderen, dann ist es kein reines Sicherheitsmodell mehr, sondern weiterhin ein Wettbewerbsfilter

• 10.06.26
• 18:22
• Artikel
• +1

@Robin02: Danke, sehe ich auch so

• 10.06.26
• 18:17
• Artikel
• +1

@Desoxyribonuklein: so funktioniert das nicht... https://winfuture.de/comments/thread/#3910301,3910301

Genau deshalb wäre ein Blankozugriff auf so einen semantischen Index ja auch völlig irre. Da bin ich komplett bei dir.

Nur folgt daraus für mich nicht: Dann darf ausschließlich Apple diese Ebene nutzen.

Die technische Lösung wäre ja gerade nicht, dass irgendeine KI-App den kompletten Index bekommt oder Gesundheitsdaten, Mails, Kontakte und Dateien frei in die Cloud schiebt. Die Sicherheitsgrenze muss weiter iOS sein.

-> OS-vermittelter Zugriff statt Rohdatenzugriff. Der Assistant stellt eine Anfrage, iOS prüft Berechtigungen, Scope und Kontext, gibt nur die minimal nötigen Informationen frei, führt sensible Aktionen selbst aus oder fragt nochmal nach. Mit Consent, Sandbox, Entitlements, Logs, Revocation und Confirmation bei kritischen Aktionen.

Beispiel -> Nicht "Claude bekommt deinen kompletten semantischen Index“, sondern "iOS beantwortet: Es gibt einen Arzttermin am 12. Juni, relevante Unterlagen sind diese lokal gefundenen PDFs, darf ich sie einbeziehen?“ Oder "darf dieser Assistant auf Kalender + Mail für diese konkrete Aufgabe zugreifen?“

Genau solche Vermittlungsschichten hat Apple ja in anderen Bereichen längst: Fotos, Kontakte, Kamera, HealthKit, HomeKit, Bluetooth, Location, Tastaturen usw. Keine App bekommt das ganze System, sondern definierte Fähigkeiten unter Kontrolle des Betriebssystems.

Apples Trusted-System-Agent-Ansatz klingt deshalb grundsätzlich nicht falsch. Die offene Frage ist nur: War er wirklich gleichwertig? Oder hätte Apple Intelligence intern weiterhin mehr Kontext, mehr App-Actions, bessere Defaults und weniger Reibung gehabt als jeder andere bewusst gewählte Assistant?

Darum geht es beim DMA-Kern: nicht "alle Daten für alle“, sondern gleiche relevante Fähigkeiten über eine sichere, kontrollierte OS-Schicht. Wenn Apple selbst tiefer rein darf als alle anderen, ist Sicherheit irgendwann nicht mehr nur Sicherheit, sondern auch Wettbewerbsfilter.

• 10.06.26
• 18:16
• Artikel
• +1

ich finde apples argument hier sehr stark geframt. "drittanbieter bekommen nahezu uneingeschränkten zugang zum gerät“ klingt nach: irgendein chatbot liest plötzlich frei mails, fotos, kalender und nachrichten. technisch muss es aber genau darum nicht gehen.

die sinnvolle lösung wäre nicht, fremde llms ungefiltert in apples siri-prozess zu laden. die sicherheitsgrenze muss weiter ios sein. also ein os-broker/trusted layer, der einzelne aktionen vermittelt: "fasse diese mail zusammen“, "erstelle einen termin“, "suche dieses foto“, "führe diese app-action aus“. mit permissions, scopes, sandboxing, entitlements, user-consent, confirmation vor sensiblen aktionen, logs und widerrufbaren rechten.

so ähnlich funktioniert ios ja längst bei kamera, fotos, kontakten, healthkit, homekit, bluetooth, tastaturen oder browser-defaults. keine app bekommt "das ganze system“, sondern sauber gekapselte funktionen unter kontrolle des betriebssystems.

natürlich ist das bei ai komplexer, weil prompt injection, datenminimierung, haftung und action-execution probleme sind. aber genau deshalb braucht man kontrollierte intents und keine rohdaten-flatrate. das modell darf nicht die sicherheitsgrenze sein, sondern das betriebssystem.

der eigentliche punkt ist da nicht privacy vs. eu. der punkt isteher so... wenn apple intelligence tiefen ios-kontext, app-actions und systemfunktionen nutzen darf, andere vom nutzer bewusst gewählte assistenten aber dauerhaft nur eine schlechtere schnittstelle bekommen, dann ist das kein reines sicherheitsmodell mehr. dann wird sicherheit gleichzeitig zum wettbewerbsfilter.

apple darf gerne die beste ai bauen. aber wenn der vorteil aus exklusivem zugriff auf die plattformschicht kommt, reden wir nicht mehr nur über produktqualität, sondern über gatekeeper-macht.

• 03.06.26
• 15:45
• Artikel

Ist da der hier gemeint? Weil die Entwicklung gabs schon länger https://www.indiegogo.com/de/projects/jimwong-38623042/worlds-first-portable-mosquito-air-defense?redirect_reason=language_detection

• 29.05.26
• 20:28
• Artikel

@cinema44: google hat google podcasts gekillt. war damals schon klar, dass sie das in youtube music (nicht youtube) integrieren

• 20.04.26
• 00:06
• Artikel
• +2

@ErichG: "Mit 50 Tools kann man auf den AppDataSpeicher zugreifen, ohne Jailbreak“
Das ist irreführend, weil man unterscheiden muss:

je nach iOS-Version und App-Konfiguration kann man mit Tools wie Finder, iMazing, Apple Configurator usw. auf bestimmte App-Daten zugreifen: Dokumente, Freigegebene Dateien, Backup-Daten, App File Sharing Bereiche
aber dss ist nicht gleichbedeutend mit vollem Zugriff auf den internen App-Sandbox-Speicher.

Wenn sie sauber im geschützten App-Container liegen und zusätzlich signiert/verifiziert werden ist es deutlich schwieriger.

Weil hier beide Kommentarw Dinge suggerieren:
Sandboxing existiert auf beiden Systemen.
Root/Jailbreak ist nicht die einzige Angriffsmöglichkeit.
Ohne Root/Jailbreak ist nicht automatisch alles sicher.
Mit PC-Tools hat man nicht automatisch Vollzugriff.

• 20.04.26
• 00:03
• Artikel
• +2

@floerido: Root ist ein Weg, aber nicht der einzige...
ADB / Entwickleroptionen
Backup-/Debugging-Schnittstellen
Exportierte Content Provider / falsch konfigurierte Komponenten
Shared external storage
Sicherheitslücken
App selbst schreibt unsicher