Apple va demander aux développeurs de justifier leur utilisation de certaines API

Nicolas Furno |

Apple a introduit une nouvelle règle pour les apps mises en ligne sur l’un de ses App Store. À partir de l’automne et avec la sortie des nouvelles versions de ses systèmes d’exploitation, l’entreprise va demander aux développeurs de justifier leur usage de plusieurs API jugées problématiques. Dans un premier temps, les soumissions sans justification seront simplement signalées par un message, mais la justification deviendra obligatoire à compter du printemps 2024 et une app sera refusée si elle ne justifie pas un usage légitime.

Les applications créées par les développeurs tiers reposent sur un ensemble d’API publiques fournies par Apple, des fonctions qui leur permettent de créer des interfaces, accéder à internet ou encore utiliser les fonctionnalités des appareils. La règle était jusque-là simple : tant qu’une API est publique et documentée, un développeur peut l’utiliser dans son app sans problème, mais la validation de l’App Store refusait les apps qui font appel aux API privées, que seules Apple a le droit d’exploiter. Avec ce changement de politique, un développeur devra montrer patte blanche pour cinq catégories d’API, alors même qu’elles sont publiques.

Image MacGeneration.

Ces cinq catégories ont été sélectionnées par le constructeur en raison des possibilités de détournement à des fins de fingerprinting. Cette technique consiste à établir une empreinte de votre appareil en se basant sur des caractéristiques uniques afin de créer un profil et, typiquement, de fournir des publicités adaptées. Pour contrer cette méthode de suivi qui ne nécessite aucune autorisation, Apple réduit depuis des années les caractéristiques uniques accessibles aux développeurs. Le numéro de série de votre iPhone est désormais inaccessible, tout comme l’adresse MAC de sa puce Wi-Fi, mais il reste des informations qui peuvent être collectées via les API publiques et qui peuvent suffire pour établir un profil.

La liste des cinq catégories d’API dont l’usage devra désormais être justifié permet de comprendre les données ciblées par la nouvelle mesure :

  • File timestamp APIs : elles permettent d’obtenir la date de fichiers, en particulier la date de création qui ne change jamais, mais qui est spécifique à chaque appareil et qui pourrait ainsi servir à établir un profil unique ;
  • System boot time APIs : elles servent à connaître la date et l’heure du démarrage de l’appareil, là encore une information spécifique et qui peut servir à repérer un utilisateur à condition de la mettre à jour régulièrement ;
  • ‌Disk space APIs : elles informent sur l’espace restant sur l’appareil utilisé, ce qui peut renforcer un profil personnel si elle est mise à jour régulièrement ;
  • Active keyboard APIs : la liste des claviers activés sur votre iPhone ou iPad peut constituer un bon moyen de vous identifier ;
  • User defaults APIs : elles servent à de nombreuses apps pour enregistrer une information, qu’il s’agisse d’un réglage ou d’une donnée générée par l’utilisateur.

Naturellement, ces API peuvent toutes avoir un rôle légitime dans les apps. C’est d’ailleurs pour cette raison que la nouvelle politique d’Apple ne retire pas leur accès, les apps tierces pourront toujours les exploiter… à condition quand même de pouvoir justifier leur utilisation. C’est sur ce point que le problème peut émerger : une personne de l’équipe en charge de la validation devra juger si la justification donnée par le développeur est légitime ou non. Avec tous les risques d’erreurs que l’on connaît déjà aujourd’hui, où des apps sont bloquées à l’entrée de la boutique suite à une mauvaise interprétation de la validation de l’App Store.

avatar denisdp | 

J’ai un peu du mal à saisir que UserDefaults fasse partie de cette liste, sachant qu’il s’agit d’une API utilisée très couramment pour des choses assez triviales (e.g. du stockage de préférence utilisateur).

avatar Nico_Belgium | 

@denisdp

Yep. Avec UserDefaults en gros chaque app devra justifier son utilisation. Je pense pas un jour avoir du coder une app sans l’utiliser 😅

avatar denisdp | 

@Nico_Belgium

Idem 🤣 ça sent l’embouteillage côté validation à l’automne !

avatar Nico_Belgium | 

@denisdp

En soi on peut penser que ça a du sens. On peut effectivement faire du fingerprinting en utilisant UserDefault…mais on peut aussi utiliser CoreData ou le nouveau SwiftData ou même une librairie tierce comme realm 😅

Donc de fait je suis assez d’accord. Ça a pas beaucoup de sens.

avatar Nicolas Furno | 

@denisdp

C’est la plus surprenante des 5 en effet. En plus, une app ne peut pas accéder aux user defaults d’une autre app, on est d’accord ? Ça me semble limité pour du fingerprinting.

avatar Nico_Belgium | 

@nicolasf

Si c’est possible en utilisant les AppGroups. On peut avoir un dictionnaire de userDefaults partagé entre plusieurs apps.

avatar Nicolas Furno | 

@Nico_Belgium

En effet, mais ça reste limité à un seul développeur. Après, c’est sûr que si le développeur est Meta, ça doit suffire.

avatar Nico_Belgium | 

@nicolasf

Ça me semble en tout cas l’explication la plus probable de l’ajout à cette liste..mais si c’est le cas ils auraient du demander le fait d’utiliser simultanément userDefaults et les app groups 🤷‍♂️

avatar Dimemas | 

oui en plus d'être une API qui est utilisée pour stocker des données légères
c'est bizarre

du coup, faudra-t-il persister toutes ses données dans des librairies comme Realm par exemple ?

avatar denisdp | 

@Dimemas

Pour moi ça ne change rien, il faudra juste remplir un peu plus de choses dans le formulaire de soumission des apps à validation.

Utiliser Realm dans un projet pour remplacer l’usage des UserDefaults / AppStorage, si on n’utilise pas déjà Realm dans ce projet me paraît un peu overkill. C’est justement tout l’intérêt des UserDefaults, avoir une solution légère qui permet de stocker des petits bouts de données avec une ligne de code.

avatar Tibimac | 

@Dimemas

Maybe mais c'est pas aussi simple. La bizarrerie c'est qu'on peut utiliser Realm dans un AppGroup et c'est d'ailleurs nécessaire quand, au sein d'une même app, on a une extension par exemple avec laquelle on veut partager du contenu. Perso l'extension à accès à Realm pour enregistrer du contenu dedans.

avatar mimolette51 | 

Ca me fait plus que rire. Toute entreprise US est obligé de collaborer avec les services... Tout ceci n'est que la poudre au yeux pour les pigeons!

avatar Krysten2001 | 

@mimolette51

Collaborer si on a quelque chose !!!
Ça me fait toujours rire ce genre de remarque 🙃

avatar vincentn | 

Bon courage aux développeurs.
Vu le comportement hiératique des lutins du côté de l’AppleStore, je vois poindre des situations kafkaïennes et chronophages (encore plus que d’habitude) pour la majorité des développeurs de bonne foi.

avatar Baptiste_nv18 | 

@vincentn

App Store *

avatar vincentn | 

@Baptiste_nv18

Les joies du correcteur automatique d’iOS et de ses coquilles « involontaires »… Vivement iOS 17 sur ce point.

avatar mansour | 

iOS devient Windows Vista 🤣🤣

avatar r e m y | 

Et sur VisionOS, je recommande à Apple de demander aux développeurs de justifier pourquoi ils ont besoin de suivre la position du "curseur de la souris"... car sur l'AppleVision, la position du curseur correspond au regard du porteur du casque. En enregistrant les positions du curseur (ce que toute app ou tout site web peut faire), on peut facilement étudier sur quoi se porte le regard de l'utilisateur, ce qu'il regarde, pendant combien de temps , etc.... En matière de profiling c'est du pain béni pour les marketeurs et publicitaires !

Aujourd'hui sur un site Web, impossible de savoir si une pub a été vue tant qu'on ne clique pas dessus. Avec l'AppleVision, inutile de cliquer pour savoir si la pub a été vue, si le regard est passé dessus sans s'arrêter, ou au contraire si on a été "accroché" par cette pub (même si on n'est pas allé jusqu'à cliquer dessus)

avatar kevbar | 

@r e m y

Il me semble que ça avait été évoqué durant la keynote de présentation 🤔

"Where a user looks stays private while navigating Apple Vision Pro, and eye tracking information is not shared with Apple, third-party apps, or websites." - https://www.apple.com/newsroom/2023/06/introducing-apple-vision-pro/

avatar r e m y | 

Au labo on attend impatiemment la réponse d'Apple à qui on a demandé un casque de développement (en passant par notre antenne californienne). Il me tarde de faire des tests (sur ce point notamment...)

avatar kevbar | 

@r e m y

Si justement dans la présentation ils avaient fait mention d'une sorte de couche intermédiaire qui transmet uniquement le clic sur un élément et non pas les déplacements des yeux: https://www.youtube.com/live/GYkq9Rgoj8E?feature=share&t=7176

avatar r e m y | 

👍

avatar macbook60 | 

Ce qui serait bien c’est aussi que les développeurs doivent mettre les nouvelles fonctionnalités ( API ) obligatoirement genre le PIP, widgets et autres

avatar Tibimac | 

@macbook60

Une telle obligation n'aurait aucun sens !
Ce n'est pas parce-que quelque chose est possible que c'est une bonne chose pour toutes les apps. Ça n'arrivera donc jamais, bien heureusement.

avatar Crkm | 

On sait déjà ce qui va se passer: les développeurs, qui sont systématiquement du côté du Bien, évidemment, vont s’offusquer de ne plus pouvoir tracer les utilisateurs comme bon leur semble. L’UE, également toujours du côté du Bien, va saisir l’opportunité et rappeler que grâce à elle, les développeurs vont pouvoir continuer à tracer leurs utilisateurs grace à l’ouverture d’iOS au sideloading et à l’exploitation des failles de sécurité, pour que les États membres puissent continuer à fliquer leurs chers citoyens. C’est les utilisateurs qui vont trinquer, mais le plus important c’est que la méchante Apple ouvre iOS, n’est ce pas?

avatar garba50 | 

« Le numéro de série de votre iPhone est désormais inaccessible »
Plutôt le identifierForVendor non?

CONNEXION UTILISATEUR