Sous iOS/iPadOS 14, l'accès au réseau local par une application nécessitera une autorisation

Sous iOS/iPadOS 14, l’accès au réseau local par une application nécessitera une autorisation

Bonjour ou Au revoir ?

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

26/06/2020 3 minutes
34

Sous iOS/iPadOS 14, l'accès au réseau local par une application nécessitera une autorisation

Pour quelle raison un jeu ou une application de messagerie irait accéder à votre réseau local ? Aucune. Et si cela venait à être le cas, elle devrait désormais vous en demander l'autorisation au sein des OS mobiles d'Apple.

Avec la version 14 d'iOS/iPadOS, Apple va un peu plus loin dans ses fonctionnalités liées à la vie privée. On l'a vu avec le support de DNS over HTTPS (DoH) et DNS over TLS (DoT) ou encore le renforcement de Safari. Mais d'autres petits changements devraient faire la différence au quotidien.

L'accès au réseau local : une mine d'informations

Parmi elles, l'obligation pour les applications d'obtenir une autorisation de l'utilisateur pour accéder au réseau local. L'ingénieur Tommy Pauly en explique les raisons, dont la première est simple : une application qui n'a pas besoin d'accéder au réseau local et à ses appareils pour fonctionner n'a pas de raison de le faire.

D'autant que cela ouvre de nombreuses possibilités, comme connaître les équipements de la maison, accéder à leurs interfaces de gestion distante. Mais surtout forger un identifiant unique avec les données de l'appareil et ceux du réseau, pouvant être récupéré par le protocole Bonjour, par exemple. De quoi savoir si l'utilisateur se trouve dans un lieu précis.

 

  • Apple iOS iPadOS 14 Local Network Privacy
  • Apple iOS iPadOS 14 Local Network Privacy
  • Apple iOS iPadOS 14 Local Network Privacy
  • Apple iOS iPadOS 14 Local Network Privacy
  • Apple iOS iPadOS 14 Local Network Privacy
  • Apple iOS iPadOS 14 Local Network Privacy
  • Apple iOS iPadOS 14 Local Network Privacy

Des exceptions pour les services Apple

Avec iOS/iPadOS 14, cela change. Une permission devra être accordée par l'utilisateur pour toute connexion TCP/UDP non destinée à Internet, Bonjour (Advertise, Browse), ICMP ou du broadcast/multicast IP. Mais pas les services du système, proposés par Apple, tels qu'AirDrop, AirPlay, AirPrint ou encore HomeKit.

Le développeur devra fournir une description, dans les champs relatifs à la vie privée, indiquant à l'utilisateur pourquoi il a besoin de l'accès au réseau local. S'il veut identifier des services via Bonjour, il devra également préciser lesquels. Dans le cas des requêtes broadcast/multicast ou cherchant à détecter l'ensemble des services Bonjour, une autorisation spécifique (Entitlement) sera également nécessaire. Elle peut être demandée à travers le portail développeur d'Apple.

En cas de refus par l'utilisateur, une navigation au sein des services Bonjour renverra une liste vide, les autres connexions ne pourront pas aboutir. Il faudra donc prendre garde à bien gérer ces différents cas. Demandée à la première tentative d'accès au réseau local, la permission peut ensuite être donnée ou retirée dans les paramètres d'iOS.

Enfin, Pauly livre quelques recommandations aux développeurs. La première est de profiter de la mise à jour de leur application pour ne plus effectuer un accès au réseau dès le lancement, mais plutôt après une action de l'utilisateur. C'est à ce moment que la permission lui sera demandée, la rendant plus simple à comprendre et plus légitime.

La raison invoquée doit être claire et transparente, pour les mêmes raisons.

34

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

L'accès au réseau local : une mine d'informations

Des exceptions pour les services Apple

Commentaires (34)


La même chose dans Android svp.


C’est marrant le “sauf pour apple”.

En gros, on veut protéger l’utilisateur mais nos applications ne posent pas de problèmes, alors on n’a pas besoin de demander l’autorisation, faites nous confiance.



Quel raisonnement de merde….


Non, c’est juste qu’une brique système (on ne parle pas d’applications spécifiques), Apple sait ce qu’elle fait et pourquoi. Comment elles sont encadrées dans leur usage (vu que ce ne sont pas des protocoles tiers).



Après tu peux te méfier des briques système ou de l’OS, mais ce n’est pas une mécanique d’autorisation qui résoudra le problème dans ce cas.



Une application tierce, passant par le Store, peut faire tout ce qui ne lui est pas interdit. Donc l’utilisateur doit être averti d’un accès local vu ce que cela permet. C’est le sens de telles autorisations (qui devraient déjà être en place depuis un bail pour des éléments comme l’accès LAN amha).


“Une permission devra être accordée par l’utilisateur pour toute

connexion TCP/UDP non destinée à Internet, Bonjour (Advertise, Browse),

ICMP ou du broadcast/multicast IP.”



Du coup, l’utilisation de Bonjour requiert une autorisation ou non ? <img data-src=" />


y-a, encore, “de la route à faire”

pour arriver à ‘un vrai respect de la VP.’ !!! <img data-src=" />


J’ai commencé à lire l’article en me disant “ils font chier” et finalement je trouve ça très bien.

J’étais persuadé qu’Apple prenait la question de la vie privée à coeur juste pour se donner une bonne image mais ils poussent toujours les décisions dans ce sens et ils me font vraiment changer d’avis.



Certes, il faut leur faire confiance car leur code reste quand même fermé, mais à partir du moment où on a décidé de leur faire confiance, ils sont quand même très nettement au dessus d’Android sur cette question.



Oui, je ne vois pas ce qui t’en fait douter (sans parler de l’image plutôt claire sur le sujet en complément).









ErGo_404 a écrit :



Certes, il faut leur faire confiance car leur code reste quand même fermé, mais à partir du moment où on a décidé de leur faire confiance, ils sont quand même très nettement au dessus d’Android sur cette question.





Oui comme dit plus haut, ça reste le corolaire d’utiliser un OS fermé, de lui faire confiance sur ce qu’il fait. Même si des vérifications sont possibles, tout n’est pas accessible et donc le doute subsiste.



Ben je sais pas, le fait que l’article dise que toute “connexion TCP non destinée à Bonjour” demandera une autorisation ?



&nbsp;Je lis peut-être mal la phrase, mais telle que formulée, elle peut être comprise dans ce sens.








haelty a écrit :



Ben je sais pas, le fait que l’article dise que toute “connexion TCP non destinée à Bonjour” demandera une autorisation ?



 Je lis peut-être mal la phrase, mais telle que formulée, elle peut être comprise dans ce sens.





“Une permission devra être accordée par l’utilisateur pour [toute

connexion TCP/UDP non destinée à Internet], [Bonjour (Advertise, Browse)],

[ICMP] ou du [broadcast/multicast IP.]”



Il faut le lire comme ça. Après c’est vrai que même si c’est clair dans le reste de l’article, la phrase mériterait un petit éclaircissement.



Ha en effet, ça parait plus logique comme cela. Je ne sais pas trop pourquoi mais je ne parvenais pas à lire cette phrase comme ça, et ça collait pas avec le reste de l’article. ^^





Je crois que la confusion vient de l’absence de mot devant les termes Bonjour, ICMP, et Multicast/Broadcast IP (comme “requêtes” ou autre). On a envie des les relier au terme “connexion” plus haut.

&nbsp;

&nbsp;Merci.








ErGo_404 a écrit :



J’étais persuadé qu’Apple prenait la question de la vie privée à coeur juste pour se donner une bonne image mais ils poussent toujours les décisions dans ce sens et ils me font vraiment changer d’avis.







Y’a clairement une demande sur le marché et Google n’est clairement pas le mieux placé pour y répondre donc Apple s’engouffre là dedans et ils ont bien raison.

Je ne sais pas si ils sont convaincus de leur démarche mais en attendant, ils n’ont jamais réellement fait de blé avec les données persos (même si ils en ont eu la tentation avec iAd par exemple qui est vite parti à la poubelle) et ils poussent vers plus de transparence et de controle.

Je ne crois pas qu’on puisse leur reprocher un double discours sur le sujet en tout cas



Ça va troubler pas mal de personnes en entreprise, où les services internes utilisent des réseaux privés (108 et autres)


A côté ils ont finalement céder aux gouvernements récemment. Là pour le coup, Apple empêche d’autre entité de pomper les données des gens. Ce qui est bien vu que chaque appli installé en plus sur un téléphone est possiblement un siphon à donnée utilisateur. Les applis légit sauront mettre en avant le besoin d’accéder au réseau local.&nbsp;


Le tout est d’évaluer face à la concurrence. La réalité c’est que la majorité des gens utilisent une version d’Android complètement fermée car customisée par le fabriquant.

Aujourd’hui on a le choix entre :




  • Apple dont le modèle économique ne repose pas sur les données personnelles mais dont le code est fermé

  • Les téléphones Android classiques qui intègrent les apps Google qui dépend des données personnelles, et qui ont une surcouche du constructeur qui lui-même peut pomper allègrement des données personnelles (en plus d’introduire des failles)

  • Les téléphones customisés avec une ROM android vierge basée sur l’AOSP, où il manque un gros paquet d’apps qui nécessitent les services Google.

    Il faut se demander où est la menace qu’on veut éviter. Si c’est la surveillance étatique, la dernière option est la meilleure, mais si c’est uniquement la fuite des données personnelles vers des entités privées je pense qu’Apple est le meilleur choix.








jpaul a écrit :



a phrase mériterait un petit éclaircissement.





Oui, enfin la ponctuation n’existe pas pour rien dans les phrases ;)



Justement la ponctuation ne permet pas de différencier ces deux cas de figures.&nbsp; Le français est vite ambigü.&nbsp; Inutile de nous dire d’apprendre à lire le français, on le fait déjà bien ;)



Sur ce, cela ne n’a sans doute perturbé que ma personne. Il est inutile de changer la phrase ;)








Exagone313 a écrit :



Ça va troubler pas mal de personnes en entreprise, où les services internes utilisent des réseaux privés (108 et autres)





Techniquement c’est quoi un réseaux local ? Des adresses IP en 192...* ?









Nargas a écrit :



Techniquement c’est quoi un réseaux local ? Des adresses IP en 192...* ?





https://en.wikipedia.org/wiki/Private_network



10.0.0.0/8

172.16.0.0/12

192.168.0.0/16



Espérons que ça ne sera pas comme la ré-autorisations à refaire assez régulièrement comme “ Faites-vous confiance à cet ordinateur ” ou Tile qui veut le droit d’accéder à la localisation.



Donc risquer de se faire dire “ Voulez-vous autoriser VLC ( ou autre programme DLNA / SMB ) à accéder au réseau local&nbsp; ?” assez régulièrement.


Désolé mais une règle doit s’appliquer à tous sinon c’est une sécurité biaisée.

Si l’OS/services d’Apple a plus de droit que les autres apps non “Apple”, cela ne garantie en rien la sécurité et le recueil des informations sans demande explicite à l’utilisateur.


Dans ce cas là qu’est-ce qui prouve qu’Apple même en posant la question sur l’accès et en répondant non tu aurais confiance qu’il n’effectue pas ce que tu n’as pas autorisé. il faut bien faire confiance à l’OS sinon c’est pas possible.


pour l’instant c’est (encore) l’humain qui commande à la machine, mais

PLUS pour longtemps encore ! <img data-src=" />


Si le système pose la question, cela signifie que le code respecte de “bonne foi” les règles appliquées aux autres. Après, rien ne dit qu’il ne le ferait pas tout de même.

La confiance vient également de la transparence affichée et non dans des règles qui s’applique uniquement aux autres.


Si j’ai bien compris, l’idée c’est qu’une application a besoin de ton autorisation pour un accès libre au réseau, mais que pour l’instant découvrir des enceintes airplay ne nécessite pas d’autorisation.



Ça pourrait être considéré comme un abus de position dominante en favorisant uniquement ses propres services (pourquoi airplay uniquement et pas allplay ou chromecast, par exemple ?), mais l’argument comme quoi les informations pouvant en être retirées sont largement moindres qu’avec un accès open-bar est à minima défendable.








David_L a écrit :



Non, c’est juste qu’une brique système (on ne parle pas d’applications spécifiques), Apple sait ce qu’elle fait et pourquoi. Comment elles sont encadrées dans leur usage (vu que ce ne sont pas des protocoles tiers).



Après tu peux te méfier des briques système ou de l’OS, mais ce n’est pas une mécanique d’autorisation qui résoudra le problème dans ce cas.



Une application tierce, passant par le Store, peut faire tout ce qui ne lui est pas interdit. Donc l’utilisateur doit être averti d’un accès local vu ce que cela permet. C’est le sens de telles autorisations (qui devraient déjà être en place depuis un bail pour des éléments comme l’accès LAN amha).





Je dis juste que quand Apple fait ça, c’est rarement pour la sécurité, c’est souvent pour pousser une fonctionnalité que les concurrents auront plus de mal à mettre en place… car moins amicale dans le fonctionnement.









Cclaudic a écrit :



Désolé mais une règle doit s’appliquer à tous sinon c’est une sécurité biaisée.

Si l’OS/services d’Apple a plus de droit que les autres apps non “Apple”, cela ne garantie en rien la sécurité et le recueil des informations sans demande explicite à l’utilisateur.





Ce n’est pas des Apps Apple ou pas Apple. Toutes les applications sont concernées (donc celles d’Apple aussi). Bonjour est une brique Apple mais son accès est bridé. Si une application Apple l’utilise, elle aura besoin du même niveau de permission qu’une autre.



Pourquoi brider Bonjour et pas AirPlay ? Parce que c’est une brique réseau ouverte, comme les requêtes bloquées (aux possibilités bien plus larges). On peut l’activer en douce, récupérer des infos, les utiliser, l’utilisateur ne voit rien. AirPlay & co sont des fonctionnalités spécifiques, encadrées, liées à des actions volontaires de l’utilisateur.



Moi j’aurais mis “ou pour toute connexion&nbsp;TCP/UDP&nbsp;non destinée à Internet” en fin de phrase&nbsp;<img data-src=" />


Netguard, logiciel libre, agit comme un vpn local, et on peut paramétrer pour chaque appli le droit d’accéder au réseau mobile, WiFi, en itinérance, quand l’écran est déverrouillé uniquement ou tout le temps.


Bon j’ai pas tout lu mais,

en fonction du routeur, tu peux créer un wifi ‘guest’ et interdire l’accès au LAN.

Je fais ça pour mes ioT.


Ça ne change rien : si tu veux accéder à un partage réseau depuis ton iPhone, tu ne pourras pas avec ton réseau guest.



Avec le système de la news tu ne pourras pas par défaut mais on te demandera ton accord.



Contrairement à ton ampoule wifi il y a des usages légitimes d’accès au LAN depuis un smartphone.


Je vais te donner une autre réponse… Les 2 données pointent vers des IP privées.

Je ne sais pas ce que veux dire Apple, mais un réseau local, c’est tout ce à quoi tu peux accéder sans passer par un routeur, donc tout ce qui est sur le même sous-réseau que toi.



Certaines grandes sociétés utilisent des IP publiques dans leur réseau local. A contrario, tu peux avoir un réseau très étendu utilisant des IP privées.



&nbsp;Sur le réseau local, on peut faire du broadcast, et on peut faire du ARP ou NDP (suis pas très au fait d’IPv6, NDP peut peut-être s’appliquer à plus qu’au réseau local).



Maintenant, quand Apple parle de réseau local (ou quand c’est traduit ainsi), se peut-il que ça veuille dire réseau privé ? Aucune idée.


Google se passe bien des autorisations pour collecter la localisation tout le temps meme en mode avion sur Android.



Les OS sont au dessus des permissions et jouent parfois de cette position dominante pour etre les seuls a disposer d’informations qui ont une valeur. Ce n’est pas le seul objectif ( la vie privée est aussi un facteur d’achat) heureusement.



Mais bon, un code source libre des applis sans payload resoudrait bien miux le problème que le systeme de permissions actuel.