iOS 14 : Safari, vie privée plus stricte, Santé et Car Keys

iOS 14 : Safari, vie privée plus stricte, Santé et Car Keys

Les applications au pas

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

05/08/2020 9 minutes
6

iOS 14 : Safari, vie privée plus stricte, Santé et Car Keys

Après avoir évoqué les nouveautés les plus visibles d'iOS 14, penchons nous sur les détails, et notamment sur Safari et tout ce qui touche à la vie privée. Le navigateur hérite en bonne partie des améliorations prévues pour la version macOS. Santé et Car Keys complètent le tour de piste.

Les nouveautés de la version mobile de Safari sont reprises de celle macOS Big Sur, à laquelle nous avons consacré un article. Toutes ne sont cependant pas disponibles. On retrouve plus particulièrement la traduction. La fonction est censée être disponible vers l’anglais, l’espagnol, le chinois, le français, l’allemand, le russe et le portugais brésilien.

Safari s’aligne partiellement sur la version macOS

« Censée » parce qu’en pratique, l’icône de traduction – qui doit apparaitre dans la barre d’adresse quand une page compatible est détectée – ne s’est jamais présentée à nous. On attend donc les prochains bêtas pour mieux cerner l’efficacité du mécanisme.

Côté vie privée, Safari pour iOS fournit les mêmes rapports que sous macOS. On y accède par la même icône « aA » à gauche de la barre d’adresse des fonctions de présentation (ce qui n’est d’ailleurs pas particulièrement logique). Dommage cependant, la version iOS ne se limite qu’aux rapports de synthèse. 

On peut certes y voir le nombre de traqueurs bloqués sur les 30 derniers jours, la proportion de sites web ayant contacté au moins un traqueur, le traqueur le plus contacté et ainsi de suite, mais pas les statistiques pour le site en cours.

iOS 14 SafariiOS 14 SafariiOS 14 SafariiOS 14 Safari

En outre, et comme sur macOS, on ne peut pas couper la protection pour un site spécifique, alors que les concurrents équipés de mécanismes de ce genre le proposent tous.

On retrouve également la surveillance des mots de passe. Si (et seulement si) l’utilisateur se sert du Trousseau pour les stocker, Apple se charge de surveiller d’éventuelles correspondances avec des fuites d’informations. Dans ce cas, un avertissement sera lancé à l’utilisateur, qui sera invité à changer son mot de passe.

Pour rappel, Safari propose déjà des mots de passe aléatoires et complexes en suggestion dans les formulaires. En outre, l’utilisateur pourra basculer sur Sign In with Apple, si la fonction est supportée par l’application tierce.

Notre dossier sur iOS 14 :

Vie privée : la vis se resserre

Plusieurs apports important dans le domaine de la vie privée, avec toujours la même volonté de faire marcher au pas les applications, qui auront plusieurs nouvelles obligations.

Apple requiert ainsi qu’elles demandent expressément à l’utilisateur la permission de traquer leurs habitudes, donc de personnaliser les publicités. On attend de voir à quel point les éditeurs rivaliseront d’imagination pour faire passer la pilule, Apple ayant une opinion très arrêtée sur tout ce qui touche au pistage (voir notre article sur Safari 14).

Autre mécanisme implanté, une surveillance des accès au presse-papier. TikTok en a fait les frais, épinglé par iOS 14 pour ses accès fréquents, sans raison valable. L'entreprise a bien tenté d'expliquer qu'il s'agissait de lutter contre le spam, mais elle s'est surtout empressée de corriger le problème. Même sanction pour LinkedIn depuis.

Attention, le fait d'accéder au presse-papier n'est pas un problème en soi, si l'utilisation est justifiée. Par exemple, quand Pocket détecte un lien copié et propose automatiquement de l'ajouter à la collection.

iOS 14 vie privéeiOS 14 vie privéeiOS 14 vie privéeiOS 14 vie privée

L’accès aux photos est également plus contrôlé. Quand une application demande l’autorisation d’y jeter un œil, l’utilisateur peut maintenant accepter, refuser ou ne donner accès qu’à une sélection spécifique, dont l’application devra se contenter.

De même, en cas de demande d’accès à la position géographique, il est possible de ne fournir qu’une information approximative, et non la géolocalisation précise. Dans la même veine, un indicateur de couleur apparait maintenant en haut à droite de l’écran selon qu’on utilise l’appareil photo (pastille verte) ou le micro (pastille orange).

Aucune application ne peut plus utiliser l’un ou l’autre sans que le témoin lumineux soit présent, y compris celles d’Apple. Chaque fois qu'un témoin s'allume, l'application l'utilisant est pointée dans le centre d'actions.

DNS over HTTPS/TLS feront aussi leur arrivée dans iOS 14. 

Santé se penche davantage sur le sommeil

Les améliorations de Santé se découpent surtout en deux lots : le sommeil et les données supplémentaires.

Pour le sommeil, plusieurs apports sont présents. D’abord, la possibilité de définir une routine personnalisée pour préparer au repos. Dans ce mode, les fonctions Sommeil et Ne pas déranger sont actives. L’utilisateur peut définir une série d’étapes et de déclenchements selon ses goûts, comme la lecture de sons d’ambiance ou d’une musique, le lancement d’une application de relaxation, etc. Il définit le temps à accorder à ces étapes avant l’heure supposée de sommeil. Il peut couper cette préparation quand il le souhaite, ou la repousser.

Le mode Sommeil est également une nouveauté. Quand il est déclenché, l’écran du téléphone affiche un fond de verre givré sur lequel sont présentes l’heure, la date, l’alarme prévue pour le jour suivant et les actions éventuellement prévues pour aider à s’endormir. Il est conçu pour préparer au sommeil, en limitant les informations disponibles et en donnant le signal qu’il est temps de moins regarder son téléphone.

iOS 14 SantéiOS 14 SantéiOS 14 SantéiOS 14 Santé

Dans iOS 14, Santé inaugure de nouvelles données. Elles seront liées aux enregistrements effectués par le téléphone et les appareils connectés (comme une Apple Watch), la mobilité, les symptômes et l’ECG. Ces informations seront présentées dans la vue de synthèse. L’application est en outre nettement plus personnalisable.

On peut configurer l’écran afin d’afficher en priorité les fonctions privilégiées, y voir les données en cours, vérifier leur état d’activation sur les appareils, etc. Le tout est organisé sous forme de liste de contrôle, permettant de voir notamment quand des informations ont été reçues pour la dernière fois.

Enfin, un ajout permet de mesurer la quantité de volume sonore reçu sur une semaine. En option, un utilisateur pourra décider de suivre les recommandations de l’OMS afin d’être averti quand il dépasse le quota recommandé, avec baisse automatique du volume dans les écouteurs.

Car Keys et CarPlay : intéressant, mais uniquement chez BMW pour l’instant

Les fonctions relatives à l'automobile sont intéressantes, mais nous n’avons pas (encore ?) été en mesure de tester. Car Keys, tout d’abord, propose de substituer l’iPhone aux clés traditionnelles de voiture, si bien sûr cette dernière est compatible. Il suffit par exemple de toucher la poignée de porte avec le téléphone pour l’ouvrir.

Pour être tout à fait exact, ce ne sera pas une nouveauté d’iOS 14, la fonction venant d’apparaitre dans la très récente version 13.6. Son usage sera cependant étendu et généralisé dans la prochaine version majeure du système. Pour l’instant, seul BMW propose quelques véhicules compatibles.

La voiture peut démarrer si on approche l’iPhone d’une zone prévue à cet effet ou sur un chargeur sans fil. Point (très) important, un mode batterie faible est prévu : si l’iPhone s’éteint par manque d’énergie, la fonction reste disponible pendant cinq heures selon Apple. Car Keys permet en outre de partager ses clés, par exemple avec sa famille.

La fonction étant intégrée dans le Wallet, il devient possible de partager les clés via Messages. De même, depuis Wallet, on pourra supprimer ces accès.

iOS 14 Car Keys

Côté Car Play, on note une ouverture bienvenue à plusieurs nouvelles catégories d’applications tierces : disponibilité et emplacements des parkings, bornes de recharge pour les véhicules électriques et commandes pour la restauration rapide. Des API et des outils sont fournis aux développeurs pour adapter l’interface de leurs services aux écrans Car Play.

Puisque l’on parle interface, signalons deux ajouts. Un purement esthétique d’abord avec la possibilité de désigner un fond d’écran pour le Tableau de bord et l’écran d’accueil. Un autre beaucoup plus utile ensuite, avec le positionnement en bas de la barre de statut quand un écran en mode paysage est détecté.

Parmi les autres améliorations, citons la possibilité de partager l’heure d’arrivée estimée (ETA) avec des contacts via Siri, tout comme des messages audio. Les claviers chinois et japonais sont également de la partie. Les développeurs auront quant à eux de nouveaux outils et API pour renforcer les fonctions audio, VoIP et la messagerie.

Pour ces deux dernières par exemple, une application pourra proposer les conversations passées, une fonction qui faisait en fait cruellement défaut jusqu’ici. Spotify et Deezer, une fois à jour, pourront en outre afficher la pochette de l’album.

6

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Safari s’aligne partiellement sur la version macOS

Vie privée : la vis se resserre

Santé se penche davantage sur le sommeil

Car Keys et CarPlay : intéressant, mais uniquement chez BMW pour l’instant

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (6)


Merci pour l’article Vincent.





Un autre beaucoup plus utile ensuite, avec le positionnement en bas de la barre de statut quand un écran en mode paysage est détecté.

J’ai pas bien compris ce passage. Ce n’est pas plutôt l’inverse qui est illustré au dessus?



Sinon pour le mode sommeil, tu ne sais pas si ils ont (enfin) pensé à mettre une sorte de “mode vacances” ? Je suis hyper tête en l’air et j’adorerai pouvoir désactiver le réveil pour X jours en ayant l’assurance qu’il se rétablisse tout seul par la suite. Combien de fois je me suis levé à la bourre après un jour ferié ou des vacances.


Franchement que du bon côté Safari, presse papier, indicateur d’utilisation des photos, micros et de la position géographique approximative.

Une vrai avancé dans la lutte contre le tracking.




En outre, et comme sur macOS, on ne peut pas couper la protection pour un site spécifique, alors que les concurrents équipés de mécanismes de ce genre le proposent tous.



Pour le coup c’est très bien : Safari avec sa base d’utilisateurs peu enclins à changer de browser (que ce soit de bientôt de gré ou actuellement de force) sont les seuls à pouvoir imposer ce genre de choses nécessaires et qui profitera à tous.



Il y a aujourd’hui clairement un rapport de force entre l’industrie du tracking et les navigateurs à faible PDM en défaveur de ces derniers. En terme d’expérience utilisateur de base, il est clair que si Firefox par exemple ne permettait pas à l’utilisateur de désactiver (malgré son envie) la protection pour faire fonctionner des sites, ces derniers finiraient, de guerre lasse, par repartir chez Chrome & cie.



La décision d’Apple créera probablement des dommages collatéraux regrettables mais forcera clairement les développeurs à supporter un fonctionnement optimal de leur site/app même sans cookies tiers et autres joyeusetés. L’écosystème web s’en sortira globalement grandi dans l’ensemble.


Concernant l’outil de traduction automatique de sites, Apple indique sur son site qu’il n’est disponible qu’aux US et Canada, peut-être que votre téléphone de test était réglé sur France.


Dommage qu’Apple tue l’innovation en freinant des 4 fers l’intégration convenable des PWA… ils veulent garder la main mise avec leur Store au détriment de l’innovation en général. Dommage qu’ils ont un free-pass.


Encore faut-il être d’accord sur le principe que les PWA sont de l’innovation ou devraient être l’avenir.



Si l’“applification” du web est une tendance certaine, on peut légitimement discuter de sa pertinence.

Complexifier et dynamiser les interactions front sur un site de consultation comme le fait NXI, c’est légitime. Des applis complexes dans le web, ça se discute.



Dire qu’Apple freine des quatre fers l”innovation en n’implémentant pas certaines API c’est oublier que :




  • Les PWA ne sont qu’une méthode de concevoir des applis, pas un set minimal d’API.

  • A ma connaissance (pas sûr mais j’ai pas trouvé) cette méthode n’est nullement standardisée.

  • Le seul acteur qui pousse réellement les PWA est Google. Et quel que soit l’avis qu’on puisse avoir sur l’aspect technique, il faut bien se rendre compte que Google est le seul gros acteur dont les bénéfices sont directement corrélés au temps que passe l’humanité dans un browser (et Chrome de préférence).

  • Apple s’en est toujours tamponné, les autres suivent le mouvement pour pas être largué.



    Je parle même pas de la situation actuelle ridicule où une appli web est interprétée puis compilée puis exécutée dans un nombre ridicule d’encapsulations dans de sandbox et vm diverses.



    Attention, je suis pas contre l’évolution des standards du web et l’apparition d’API un peu chiadées et même des trucs un peu plus poussés comme le webassembly sont de réelles opportunités.



    Mais dans la plupart des cas, la plateforme web est juste totalement “overkill” en terme de complexité technique, d’utilisation de ressources et de l’absence totale de librairie standard d’interface graphique.



    La réalité c’est que si les apps web (ou les PWA) ont le vent en poupe (et je sais de quoi je parle, ça paie mon salaire) c’est parce que c’est facile à déployer (c’est toujours facile à déployer quand tu déploies chez toi et pas chez l’utilisateur, comme le minitel), “simple” à écrire (mais avec des frameworks hein, tiens, comme Angular, parceque sinon à poil en 2020, le js c’est toujours une tannée).



    Écrire des applis “natives” potables c’est facile quand il y a un minimum de taf fait en amont : Swift en est l’exemple. Ce qui est regrettable, c’est l’absence totale de frameworks natifs open source interopérables. Et cet état de fait vient uniquement du fait que le travail à abattre pour se positionner face aux PWA de Google, qui somme toute “font le job” est juste titanesque.



    Même Facebook, dont les employés sont quand même pas les pire brèles quand il s’agit de dev web, ont fini par revenir au full natif. Et les retours font état de codebases bien plus faciles à maintenir, plus petites, des applis plus rapides et moins gourmandes en ressources et en espace.



    Qu’est-ce qu’il s’est passé ? Facebook a tenté en vain la conquête du web (FBML, React …) parce qu’ils avaient un intérêt proche de celui de Google à ce que tu restes sur le web (avec leurs trackers partout). Maintenant que l’économie du tracking (telle qu’ils l’avaient conçue) commence à sentir le chaud, ils n’ont plus aucun intérêt à entretenir la hype des applis web malgré leurs contraintes. Et il faut pas énormément de pragmatisme pour se rendre compte que c’est moins la galère d’utiliser des APIs natives correctement conçues (Android SDK ou Swift/SwiftUI) dont le métier est de créer des interfaces utilisateurs facilement plutôt que des APIs Web dont le cœur de métier (sans surcouche) reste encore et toujours de manipuler un DOM qui ne sait rien faire de lui même.