La version 14 de Safari pour macOS – et dans une moindre mesure pour iOS/iPadOS – sera nettement plus significative que les précédentes. Les ajouts y sont nombreux, particulièrement sur le terrain des performances, de la sécurité et de la vie privée.

Comme nous l’avons souligné récemment, Safari est un bon navigateur. Il est rapide, intègre des mécanismes de défense de la vie privée et jouit d’une intégration difficile à combattre dans macOS. Dans iOS, il est utilisé par défaut, mais iOS 14 permettra – enfin ! – de le remplacer par un autre. En revanche, les produits tiers auront toujours l’obligation d’utiliser une vue déportée de Safari, donc le moteur WebKit.

• Safari : très bon sur la vie privée, anémique face à la concurrence

Safari 14 sera la version du navigateur fournie avec iOS/iPad 14 et macOS 11 (Big Sur). Si les mises à jour précédentes étaient assez tranquilles, la nouvelle venue montre qu'Apple en a fini avec sa sieste : oui, il y a des nouveautés, et elles sont nombreuses.

Le navigateur n'est actuellement disponible auprès du grand public que sous forme d'une Technology Preview de WebKit pour macOS Catalina. Pour Big Sur et iOS 14, il faudra attendre la bêta publique plus tard dans le mois. Les avertissements habituels seront alors de rigueur.

Voici donc un bilan de tous les principaux apports, en commençant par la sécurité et la vie privée.

Face ID ou Touch ID pour l’authentification à deux facteurs

Apple a particulièrement travaillé la partie authentification sur son navigateur, tant pour prendre en compte ses propres technologies que pour se mettre à niveau face à la concurrence. Premier point, la prise en charge de Face ID et Touch ID pour les sites compatibles avec la double authentification.

De nombreux services s’appuient encore sur le SMS et le code à six chiffres, même si beaucoup supportent aujourd’hui les applications de type Authenticator. Plus rarement, un service permet l’utilisation d’une clé de sécurité de type Yubico ou Titan (Google). Malheureusement, certains font payer cette fonctionnalité, comme le gestionnaire de mots de passe LastPass, qui la réserve à son offre Premium.

L’idée d’Apple est de simplifier autant que possible cette étape, particulièrement pour les services déconnectant automatiquement l’utilisateur au bout de quelques heures d’inactivités, réclamant à nouveau la double authentification.

L’entreprise ne réinvente pas la roue : elle se base sur le standard Web Authentication du W3C (Webauthn), que la plupart des acteurs supportent maintenant. C’est aussi une manière – et la firme insiste particulièrement sur ce point – d’interpeler les développeurs web pour leur faire prendre conscience des avantages qu’il y aurait à adopter ce standard : une authentification forte basée sur une infrastructure à clé publique et une résistance naturelle au phishing.

Les appareils Apple possédant une enclave sécurisée pourront donc se servir de Face ID ou Touch ID puisque les clés privées attenantes y sont également stockées. C’est tout simplement une exploitation de la biométrie.

Elle n’est d’ailleurs pas nouvelle, puisque Microsoft (par exemple) l’utilise déjà depuis plusieurs années sur les portables équipés de webcams compatibles via Windows Hello. Si l’on plonge un peu dans les détails, on peut voir cependant qu’il y aura une différence dans la manière dont Apple manie les attestations de certification. Ces éléments servent à prouver qu’un appareil est bien ce qu’il prétend être. Plutôt que d’envoyer la même à tous les sites, Apple va un peu plus loin.

Elle dispose de son propre service d’attestation et en présentera une différente à chaque site, émanant du même certificat. Selon l’entreprise, une méthode de suivi plus évoluée permet de suivre l’utilisation d’une même attestation à travers la navigation web. Elle applique donc la même recette qu’avec son Sign-In with Apple. La technique s’appelle cette fois Apple Anonymous Attestation (AAA). Elle n’est pas encore incluse dans Safari, mais le sera dans une prochaine bêta.

Apple a consacré une vidéo sur la manière dont les développeurs peuvent implémenter WebAuthentication. Ils n’ont évidemment pas attendu la pomme pour se lancer, mais comme toujours quand la société jette tout son poids dans un domaine, le mouvement devrait prendre de l’ampleur. D’autant qu’une fois le protocole géré, la compatibilité avec Face ID ou Touch ID n’est plus bien loin.

• Voir la session WWDC dédiée à Web Authentication et Face ID/Touch ID

Cette prise en charge ne servira pas que sur les iPhone et iPad, puisque tous les MacBook actuellement vendus disposent d’un capteur Touch ID. Si la sauce prend, on imagine un plaisir certain à poser son doigt sur un capteur plutôt qu’à se servir d’un code supplémentaire à six chiffres ou à brancher une clé USB. Il est probable que les constructeurs accentuent également la poussée de ce type de solution dans leurs équipements.

Plusieurs autres améliorations liées à l’authentification sont présentes. D’abord, le support du code PIN et la sélection de comptes pour les clés Web Authentication externes (USB). Ensuite, la prise en charge de l’API Security Code AutoFill pour le remplissage automatique du code reçu par SMS, jusqu’à présent exploitée dans les applications uniquement.

Enfin, Safari sera capable d’avertir l’utilisateur si l’un de ses mots de passe se retrouve impliqué dans une fuite de données. Condition, que ledit mot de passe ait été enregistré dans le Trousseau bien sûr. Dans le cas d’un gestionnaire tiers, c’est ce dernier qui récupère cette mission (ils le font presque tous).

Safari 14 a ses propres rapports de vie privée

Safari se met à la page sur les traqueurs. La version 13 en bloquait déjà une partie, via une technologie maison nommée Intelligent tracking Protection (ITP). En fait, une utilisation du machine learning pour apprendre à cerner les cookies ayant le droit ou non d’accéder aux données de navigation.

La nouvelle mouture va plus loin, en incorporant un panneau qui résume la situation, comme le font presque tous les concurrents aujourd’hui. Mais Safari se contente un peu pour l’instant du minimum : il indique combien il a bloqué de dispositifs de suivi et lesquels.

Comme on peut le voir sur les captures ci-dessus, le résultat est conforme à ce que l’on peut en attendre. Il lui manque toutefois l’option simple de pouvoir désactiver directement la protection pour le site en cours de visite.

Si on le compare avec celui de Firefox ou même d’Edge, il est clair que le panneau d’information de Safari dispose d’une solide marge d’amélioration. On ne peut rien y changer dans l’état actuel des choses. On remarque que le panneau est muni d’un petit « i » d’information, qui ouvre une synthèse des rapports.

Safari fournit alors des statistiques sur les 30 derniers jours, avec le nombre total de traqueurs, le pourcentage de sites visités en possédant au moins un, le plus contacté par les sites visités et la liste complète des traqueurs bloqués, classés par site ou par nombre d’occurrences.

Le blocage complet des cookies tiers

Bien qu’Apple l’ait mentionné parmi les nouveautés de Safari 14, ce n’en est pas une. Le blocage complet des cookies tiers existe en fait depuis iOS/iPadOS 13.4 et Safari 13.1 pour macOS. Certes le mécanisme n’est en place que depuis quelques mois, mais il existe bel et bien. Si la société en remet une couche, c’est que le changement est important.

Le billet des développeurs sur le blog de WebKit date du 24 mars. Ils expliquaient alors que le mouvement allait dans le sens d’une meilleure protection de la vie privée, et qu’ITP avait été si renforcée au cours du temps (persistance maximale de 24 h notamment) qu’un blocage complet n’était que l’aboutissement logique.

Bien que Tor Browser et Brave aient ce comportement par défaut, Safari est le premier navigateur grand public massivement utilisé à avoir sauté le pas. Les développeurs estimaient d’ailleurs qu’ils « pavaient la voie » aux autres navigateurs. Pour être exact, Firefox le fait déjà partiellement depuis l’année dernière. Le blocage est actif sur les cookies tiers « connus » mais il reste à franchir le pas. Chez Google, Chrome finira aussi par le faire, mais pas avant… 2022.

Il faut dire que la bascule entraine dans son sillage de nombreux changements pour le monde de la publicité, certes, mais également pour les sites au sens large. Par exemple, toutes les intégrations intersites passant par ce biais ne peuvent plus fonctionner. Pour stocker des informations de manière « vertueuse », Apple a proposé l’API Storage Access en 2018. Elle est en cours de standardisation par le W3C, est implémentée dans Firefox, en cours de travail dans Edge, acceptée dans Brave (l’implémentation se fera donc), tandis qu’il ne semble pas y avoir encore de réponse pour Chrome.

Et côté avantages ? Le principal est qu’il bloque une bonne partie des informations que les traqueurs peuvent rassembler sur un(e) internaute pour constituer un identifiant unique : le fameux fingerprinting. De fait, bien que cette annonce ait plusieurs mois, Apple la ressert au menu des nouveautés. Safari 14 va faire parler de lui et de nouveau attirer l’attention sur le cas des cookies tiers. Côté Apple, la situation est claire : ils n’ont plus droit de cité nulle part.

Ces API dont Safari ne veut pas pour des raisons de vie privée

Si Safari rattrape son retard ou prend de l’avance sur la vie privée en fonction des sujets abordés, Apple garde sa réputation de ne pas faire dans le consensualisme. L’éditeur a refusé d’intégrer 16 interfaces de programmation liées aux technologies du web pour la seule raison qu’elles posent problème : elles peuvent participer à la construction d’une empreinte unique, comme les cookies tiers décrits plus tôt.

Voici les interfaces en question, qui permettent aux sites web de :

• Web Bluetooth : se connecter aux équipements Bluetooth LE (Low Energy)
• Web Bluetooth Scanning : scanner l’entourage Bluetooth pour y trouver des périphériques LE
• Web MIDI API : détecter et manipuler des périphériques MIDI
• Magnetometer API : accéder au magnétomètre de l’appareil
• Web NFC API : communiquer avec les tags NFC via le lecteur de l’appareil
• Device Memory API : connaitre la quantité de mémoire vive
• Network Information API : fournir des informations sur le type de connexion utilisé, afin que d’éventuels scripts puissent se déclencher en cas de changement
• Battery Status API : d’être informés de l’état de la batterie
• Ambient Light Sensor : de recevoir des informations sur la quantité de lumière ambiante, via les capteurs de l’appareil
• HDCP Policy Check extension for EME : d’interroger l’appareil sur les droits numériques disponibles pour la lecture de contenus
• Proximity Sensor : récolter des données depuis les capteurs impliqués dans la mesure de proximité
• WebHID : de détecter la présence de périphériques HID (notamment les claviers et souris)
• Serial API : communiquer avec les appareils branchés sur ports série, comme imprimantes 3D, les microcontrôleurs et autres
• Web USB : communiquer avec des périphériques USB
• Geolocation Sensor : d’obtenir la position géographique. Elle doit remplacer l’ancienne API Geolocation et peut travailler en tâche de fond
• User Idle Detection : détecter quand un utilisateur est absent (plus devant l’écran depuis un certain temps)

Presque toutes ces API sont aujourd’hui implémentées dans les navigateurs Chromium, quelques-unes dans Firefox. Aucune dans Safari, donc.

Certes la lutte contre le fingerprinting chez Apple est authentique. Avec le temps, Safari a supprimé divers éléments pour empêcher le marquage de l’utilisateur : polices personnalisées, informations mineures dans l’agent utilisateur, marqueur Do Not Track (cruel paradoxe), support des plug-ins sur macOS et autres. En outre, tout accès aux informations des capteurs de mouvement réclame une autorisation et le marquage des caméras et microphones via WebRTC est coupé.

Mais à la lecture de cette liste, on se demande si Apple ne fait pas d’une pierre deux coups. Toutes ces API ont en effet un point commun : elles font progresser les applications web sur le terrain des fonctionnalités, accédant aux mêmes capacités que les natives. Or, le choix de Cupertino est clair dans ce domaine : elles ont le droit d’être épinglées sur l’écran d’accueil, mais certainement pas d’avoir d’autres fonctionnalités, comme les notifications ou les Service Workers.

Apple ne jure que par le code natif, une approche inverse à Google – et même Microsoft dans une certaine mesure. Même en prenant pour argent comptant les déclarations d’Apple sur le fingerprinting, on ne peut s’empêcher d’y voir une occasion de creuser le fossé entre applications natives et web, surtout sur iOS.

HTTP/3 pris en charge

Safari sera le dernier navigateur grand public à insérer le support de HTTP/3 dans son code. Il ne s’agissait pas jusqu’ici d’une urgence, mais puisque l’automne marquera en quelque sorte le top départ de cette nouvelle brique technologique – elle n’est pas finalisée – il était temps qu’Apple s’y mette. Il se retrouvera aussi bien dans les versions iOS/iPadOS que macOS, mais uniquement pour les dernières réversions majeures.

Ainsi, bien que Catalina ait son Safari 14 au début de l’automne, le HTTP/3 n’y sera pas fonctionnel. Dans les préversions actuelles, il n’est pas non plus encore actif par défaut. Il faut se rendre dans les fonctions expérimentales pour l’activer. N’attendez cependant de différence dans votre navigation pour l’instant.

HTTP/3 est conçu pour simplifier et accélérer l’usage moderne du web, en offrant par exemple de meilleures performances pour le chargement des pages web, en autorisant le multiplexage des flux vidéo ou encore en améliorant la fiabilité des connexions. À condition que les serveurs contactés le prennent en charge.

Actuellement, seuls 6,3 % des sites web sont actuellement compatibles. Et encore, certains le sont avec une ancienne version du protocole, quand HTTP/3 n’était encore que QUIC, issu des travaux de Google. Mais au moins, Safari sera prêt.

Un mot sur les performances

Safari est rapide. Lors de notre bilan, il ressortait premier sur plusieurs tests. On peut expliquer en partie ces résultats par le degré d’intégration du navigateur au sein de macOS, auquel cas les concurrents restent libres de faire de même. L’autre partie est tout simplement un bon travail réalisé par Apple sur son moteur de rendu et la machine virtuelle JavaScript.

La version 14 introduit une nouvelle série d’optimisations. Par exemple, le support du chargement incrémentiel des PDF. On pourra ainsi lire rapidement la première page d’un document en contenant de nombreuses, plutôt que d’attendre le chargement complet. Parmi les autres améliorations, signalons le défilement asynchrone pour les éléments overflow: scroll et iframe sur macOS, la fermeture plus rapide des onglets, ou encore l’amélioration des performances d’IndexedDB, de l’accès aux cookies et de for-of.

La préversion apparait donc comme très réactive. Les utilisateurs Mac qui aimeraient s'en rendre compte par eux-mêmes n’ont pas besoin de la bêta de Big Sur. La dernière préversion de WebKit contient toutes les nouveautés de Safari 14 et peut s’installer sur Catalina.

Apple n’hésite pas à vanter les mérites de son navigateur face à la concurrence, tout particulièrement Chrome. Safari chargerait ainsi certaines pages jusqu’à 50 % plus rapidement. Sur iOS, les performances JavaScript seraient deux fois plus élevées que Chrome sur Android. On ne sait bien entendu rien du protocole de test, sachant que les deux moteurs – WebKit et Blink – ne peuvent pas être réunis sur une même plateforme mobile.

Quant à Safari sur iPadOS 14, il ferait même mieux que Chrome sur Windows. Pourquoi pas.

Safari s’ouvre aux Web Extensions… en quelque sorte

C’était l’une des annonces les plus attendues, puisque la stratégie adoptée jusqu’ici par Apple a échoué. Safari 14 va s’ouvrir aux Web Extensions, débloquant d’un coup des milliers déjà disponibles. Il s’agit d’un standard adopté initialement par Chrome, puis Firefox. Ce format, standard du W3C, est utilisé aujourd’hui par la majorité des navigateurs.

Pour rappel, Apple avait décidé qu'elles n’étaient pas assez bien pour Safari. Elle avait assuré la promotion d’extensions sous forme d’applications, distribuées par le Mac App Store. À charge pour les développeurs de traduire leur code HTML/CSS/JavaScript en Objective-C ou en Swift.

La sauce n’a que très moyennement pris. Pour Safari 12, Apple a tranché : seules ces applications avaient droit de fonctionner sur son navigateur. Et de perdre au passage l’immense majorité des extensions auparavant disponibles. L’ouverture aux Web Extensions est donc un retour. Mais, Apple oblige, ne vous attendez à pouvoir récupérer des extensions dans le Chrome Web Store comme on pourrait le faire depuis un Edge, un Opera ou un Vivaldi.

L'entreprise continue d’imposer le passage par le Mac App Store. À ceci près que les développeurs n’auront plus à écrire en Objective-C ou en Swift. Elles seront toujours fournies sous forme d’applications, qui ne contiendront que le code de la version web. La boutique se chargera simplement de l’intégration dans Safari.

La firme se montrerait-elle raisonnable face à une technologie du web ? Oui et non. Les Web Extensions sont un standard, aussi bien du W3C que de l’industrie. Il pèse de tout son poids et Apple s’y résout. Mais puisqu’il faut passer par le Mac App Store, cela signifie pour les développeurs avoir au moins un Mac avec Xcode 12 pour pouvoir publier le code. Et payer l’abonnement de 99 dollars par an qui va avec.

Apple fournit un script traduisant automatiquement l’extension en application macOS. Celle-ci ne contiendra que le minimum, mais la fenêtre d’installation et de résumé peut être personnalisée… avec de l’Objective-C ou du Swift. Les applications déjà créées continuent à fonctionner et Xcode 12 fournit tout ce qui est nécessaire à la création d’une extension. Cette ouverture, bien que sous contrôle, n'en a pas moins été applaudie par Mozilla.

• Voir la session WWDC dédiée aux Web Extensions

Traduction, miniatures d’onglets, contenus 4K HDR et… adieu Flash

La principale différence aujourd’hui entre Safari et les navigateurs concurrents est qu’il ne reçoit qu’une mise à jour majeure par an. Beaucoup diraient que l’on s’y retrouve : si le projet Chromium cumulait ses apports d’une année, on parviendrait sans doute au même résultat. L’utilisateur, lui, fait face à bon nombre de nouveautés d’une seule traite.

En plus des éléments déjà vus, Safari 14 marque officiellement la fin du lecteur Flash sur les plateformes Apple. La décision est conforme au calendrier de toute l’industrie : Flash ne doit plus être utilisé d’ici la fin de cette année. On retrouvera donc cette suppression un peu partout dans les mois qui viennent.

Parmi les autres nouveautés, signalons l’intégration d’un module de traduction. Il fonctionne à la manière de celui de Google, mais avec une différence notable : il fonctionne localement. Il n’y a donc pas de transmission d’informations entre l’appareil de l’utilisateur et les serveurs de l’entreprise. La contrepartie, c’est que les langues prises en charge sont pour le moment peu nombreuses : anglais, espagnol, chinois simplifié, français, allemand, russe et portugais brésilien.

En outre, la traduction ne fonctionne pour le moment que dans un seul sens : vers l’anglais. Le seul moyen actuel de tester la traduction est donc de paramétrer le système en anglais et de se rendre sur des sites « étrangers ». Et encore là, le bouton disponible, qui doit s’afficher à droite de la barre principale, n’apparait pas toujours. Le mécanisme devrait être plus fiable dans les prochaines préversions du navigateur.

À noter également l’ajout d’une miniature quand on passe le curseur de la souris sur un onglet, déjà disponible chez nombre de concurrents depuis des années, mais qui reste sympathique. Cet apport accompagne en fait un léger remaniement de la barre d’onglets. Celle-ci affiche par exemple les favicons des sites, alors qu’il ne s’agissait que d’une option jusqu’ici. Ensuite, quand le nombre d’onglets devient trop important, le texte disparaît pour ne laisser que la favicon. Dommage que ce comportement soit réservé (pour l’instant ?) aux seuls Mac, tout comme les miniatures.

Safari 14 va également supporter davantage de contenus. D’abord, dans une moindre mesure, le format d’image WebP. Surtout, la 4K HDR est prise en charge dans les contenus vidéo, du moins tant que les verrous numériques et les codecs supportés le permettent. C’est le cas avec Netflix, qui affiche ses contenus 4K HDR sur les Mac compatibles, c’est-à-dire ceux sortis à partir de 2018 et fonctionnant avec la bêta de Big Sur. La gestion de la 4K pour YouTube n’est cependant pas encore de la partie, alors qu’elle est au programme des réjouissances pour tvOS 14.

Dans l’ensemble, cette mouture 14 sera importante. Elle contient bon nombre de nouveautés, affine à nouveau ses performances, blinde un peu plus la protection de la vie privée et relâche la pression sur les extensions. Dommage, finalement, que Safari 14 reste cantonné aux plateformes Apple.

Pour une personne travaillant en environnement hétérogène – par exemple un ordinateur fixe sous Linux ou Windows 10, un MacBook et un smartphone Android – Safari n’est pas envisageable. Elle se dirigera plus spontanément vers un navigateur transversal comme Chrome ou Firefox, disponibles sur toutes les plateformes. Les utilisateurs entièrement tournés vers Apple ont de bonnes chances d’apprécier quant à eux la mise à jour.