Safari 14 : une version majeure, riche en nouveautés

Safari 14 : une version majeure, riche en nouveautés

Vie privée contre fonctionnalités

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

08/07/2020 20 minutes
30

Safari 14 : une version majeure, riche en nouveautés

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 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.

Safari Web Authentication

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.

Safari Web Authentication

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.

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.

  • Safari vie privée
  • Safari vie privée
  • Safari vie privée

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.

  • Firefox Edge vie privée
  • Firefox Edge vie privée

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 24h 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.

Safari performances

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.

  • Safari extensions
  • Safari extensions

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.

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.

30

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

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

Safari 14 a ses propres rapports de vie privée

Le blocage complet des cookies tiers

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

HTTP/3 pris en charge

Un mot sur les performances

Safari s’ouvre aux Web Extensions… en quelque sorte

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

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 (30)


A quand le support de user style sheet par Safari sur iOS ? Agaçant de ne pas avoir de dark theme sur certains sites qui ne le proposent pas nativement :(








NextInpact a écrit :



Mais puisqu’il faut passer par le Mac App Store, cela signifie pour les développeurs avoir au moins un Mac avec Xcode 12 pouvoir publier le code. Et payer l’abonnement de 99 dollars par an qui va avec.







<img data-src=" /><img data-src=" />. Autant dire que toutes les petites extensions développées par des passionnés sur leur temps libre, et qui ne les monétise pas, ne verront pas le jour ici. Le nombre va fondre comme neige au soleil ! (je parle surtout de l’abo à 99$/an ! Le reste, ça peut limite se trouver dans notre entourage pour les tester si on ne possède pas personnellement un mac)





Voici les interfaces en question, qui permettent aux sites web de : […] 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.





C’est plus simple pour l’utilisateur qui sait à quoi correspond chaque chose.

La tendance à appifier le web est la cause des problèmes liés à la vie privée. Bien que l’AppStore soit aussi un magasin de l’inutile mais c’est une autre affaire qui regarde Apple ou les autres stores. <img data-src=" />


Ce n’est en rien plus simple. Si une app web n’a fonctionnellement aucune différence avec une app native, l’utilisateur s’en moque pas mal du langage utilisé pour l’écrire.


Des exemples parlants ?



Je suis d’accord que le portage est quasi-immédiat, mais cela ne fonctionne pas pour tous les usages.

Pour les pro notamment, le travail cloud n’est pas mûr à moins de payer un service incluant une protection dimensionnée pour.

C’est difficile à obtenir avec un standard qui à la fin peut ne pas être suivi par tout le monde… et l’intégration native permet aussi de mettre les mains dans le cambouis lorsque c’est nécessaire sans l’assistance technique fournie par internet.



Au contraire, je trouve que la distinction cloud, native, et web a encore du sens. Maintenant oui, c’est sûr que cela fait moins de chevaux de Troie dans la nature. <img data-src=" />


Tu sembles faire un lien entre web-app et cloud / tracking. Ce sont deux sujets assez largement indépendants.

Tu peux avoir une appli native qui te traque et stocke tout sur le cloud, comme tu peux avoir une webapp qui ne te traque pas et fonctionne totalement en local.

Comme l’indique Vincent, c’est plus une question de langage / techno sous-jacente qu’autre chose, ce dont l’utilisateur se fiche généralement.


Adobe propose déjà un “créative cloud”. Pour le néophyte, tu ranges cette offre dans la catégorie webapp ou cloud ?



Techniquement tout est possible oui. En pratique je ne saisis pas l’utilité de faire des webapp sauf quand la puissance de calcul est requise, et pour cela, il existe déjà des portages tournant sur serveur, avec sécurisation de la licence…

Ce serait techniquement plus difficile de se mêler de calculs complexes car je les imagines mal reposer sur une techno standardisée tant les méthodes diffèrent d’une entreprise à une autre.



Donc l’utilité générale m’échappe en effet, même pour un programmeur.





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.





Là par contre, Apple pompe pas mal. <img data-src=" />



En plus il y a pas mal de brevets impliqués dans les natives, porter certaines app sur du web en se disant que ce serait mieux risque là encore de faire passer à la caisse. Maintenant je ne suis suffisamment informé pour comparer le détail, mais je ne doute pas qu’à terme cette flèche puisse servir.


La PWA de Twitter, qui sur Android s’installe comme une app native et en a pratiquement toutes les fonctions. Une PWA peut aussi bien avoir un mode hors ligne.


Ta question n’a pas de sens parce qu’elle consiste à catégoriser entre deux choses qui n’ont rien à voir.

C’est un peu comme si tu me montrait une voiture et que tu me demandais si je la classe dans la catégorie Renault ou rouge. Ça n’a pas de sens d’opposer ces deux catégories.



Une PWA, ce n’est jamais qu’une application dont la conception repose sur une famille de technologies (dite techno web). Une application native c’est une application qui repose sur d’autres familles de technos



L’intérêt essentiel de la PWA, c’est qu’avec un code quasi identique, elle permet de faire tourner un site web classique, une application Android, une application iOS, une application Windows…

C’est une énorme mutualisation du code, donc une énorme économie de conception et de maintenance.


Pour lui les webapp ne sont utile que pour faire du gros calcul distant.&nbsp; (enfin c’est l’usage qu’il voit)


Il faut déjà faire tourner le navigateur qui contiendra l’application. Proposer la même application me convient très bien. Mais l’intérêt me semble très limité à une famille d’applications type formulaires quand même.

Sans compter que rien n’interdit à Google ou Mozilla, par la suite, de mettre en place une certification des apps comme le font les OS.



J’ai vraiment l’impression que le gain est peu évident. Ou alors la mutualisation permet de proposer un web propre et gérable par le cache du navigateur. Ce serait bien pratique pour filtrer les données envoyées aux sites ou les partager en E2E avec les autres membres d’un réseau social par exemple. (je n’utilise pas Twouitteur mais je vais regarder <img data-src=" />).


Pas que. C’est du même ordre que de demander à un cache d’accélérer le rendu d’une page normalement hébergée sur un serveur distant que de demander à un cloud de faire un rendu qui fait strictement le meêm travail mais dans le sens inverse !

Qu’on se place du côté client ou du côté serveur ne change rien. On peut tout à fait dire que la technologie est différente elle n’a de sens qu’en fonction de l’usage… on ne programme pour le plaisir de programmer que rarement. Il suffit de voir les réactions à la taxe Apple. <img data-src=" />


avec les PWA, en général, on est dans le cadre d’un terminal mobile, donc non, coté client ou coté serveur ce n’est pas pareil.

si c’est coté serveur, à chaque chargement de page, tu re DL tout, y compris le contenu statique.

si c’est dans le cache client, tu ne télécharge le statique qu’une seule fois, ensuite tu ne récupère que ce qui change, donc gain sur les datas et rapidité de chargement de la page.



la base de PWA c’est surtout ça: rapidité de chargement des pages. tout le trip de fonctionnement offline et autre c’est des plus.


Des plus sous-exploités donc. <img data-src=" />


La news tombe bien!!!

je connais quelqu’un qui a une merde sur safari : search marquis. Comment faire pour virer cette merde? je n’y connais rien sur Mac, j’ai rien pu faire.

merci!








jeje07bis a écrit :



La news tombe bien!!!

je connais quelqu’un qui a une merde sur safari : search marquis. Comment faire pour virer cette merde? je n’y connais rien sur Mac, j’ai rien pu faire.

merci!







https://macsecurity.net/view/289-search-marquis-com



Ce que je retiens :




  • Safari reste le navigateur de Apple pour les devices Apple selon la politique de Apple

  • si on veut exploiter certaines fonctionnalités du IDevices, faut payer sa dime à Apple en passant par une App, sur l’app store et ce qui va avec

  • les API ouvertes et documentées c’est mort dans Safari



    Bon ben c’est cool, ça confirme qu’acheter un Mac ou un Ipad/Iphone, c’est tout sauf une bonne idée. On va me dire qu’on peut installer d’autres navigateur, mais honnêtement, qui sur Mac fait ça ? Safari est tellement bien pensé pour enfermer les utilisateurs.








linkin623 a écrit :



Ce que je retiens :




  • Safari reste le navigateur de Apple pour les devices Apple selon la politique de Apple

  • si on veut exploiter certaines fonctionnalités du IDevices, faut payer sa dime à Apple en passant par une App, sur l’app store et ce qui va avec

  • les API ouvertes et documentées c’est mort dans Safari



    Bon ben c’est cool, ça confirme qu’acheter un Mac ou un Ipad/Iphone, c’est tout sauf une bonne idée. On va me dire qu’on peut installer d’autres navigateur, mais honnêtement, qui sur Mac fait ça ? Safari est tellement bien pensé pour enfermer les utilisateurs.



    Tu peux installer un autre navigateur, mais il utilisera forcément le moteur de Safari… Du coup la différence sera uniquement esthétique.



C’est vrai sur iOS seulement, sur macOS les navigateurs peuvent avoir leur propre moteur (encore heureux).



Perso je n’ai jamais utilisé Safari sur macOS, quand je l’ai testé il était pensé pour des grand-mère-qui-ne-conaissent-pas-grand-chose-à-l’informatique ou des ados-sur-Facebook plus que pour la productivité, même si il pompe clairement moins de jus que Firefox et Chrome.


Autour de moi la majorité des gens ont un Mac et la très grande majorité de ceux-ci n’utilisent pas safari. Les seuls dessus sont des gens peut habitués à l’informatique et pour qui internet c’est l’icône de safari, comme l’icône d’ie / edge sous Windows.



iOS c’est une autre histoire par contre.


Comment l’avantage de ne pas avoir à développer plusieurs fois la même app, sans parler d’avoir d’avoir besoin degens dans l’équipe qui ont de l’expertise dans trois langages différents et se passer de la soumission d’une app à un stores, peut ne pas être évidant pour un développeur ?



C’est le concept même d’application native qui n’a plus beaucoup de sens aujourd’hui, sauf pour des applications ayant des besoins spécifiques de performance, puissances ou accès à des fonctionnalités natives rares. Là où je travaille on se retrouve à faire des apps natives uniquement parce que les gens ont l’habitude de les chercher dans les stores. Mais ça n’a aucune plus-value.


on peut signer une app native, garantir sa provenance, l’utilisateur contrôle son installation (du moins sur mac). elle peut généralement fonctionner offline, chiffrer correctement Sans que l’on ne s’inquiète des modifications en amont… Une app native a au contraire tout son sens. Sans compter qu’elle facilite la diversité du code.


Apple freine des quatre fers quand il s’agit de techno rendant leur store obsolète, c’est dommage.








wagaf a écrit :



C’est vrai sur iOS seulement, sur macOS les navigateurs peuvent avoir leur propre moteur (encore heureux).







Pour l’instant.



Avec leur projets à long terme d’une fusion iOS / macOS qui commence par le passage sur ARM, c’est pas sur que ça reste



A mon sens ça ne confirme rien d’autre qu’un utilisateur Apple, ne se pose pas 10000 questions et profite sereinement d’un matériel à peu près abouti et de manière optimale.

&nbsp;

Un utilisateur reste un utilisateur, et ne se transforme pas en bricoleur software comme on a eu tendance à le faire bien trop souvent par le passé dans un environnement différent.








Zerbus a écrit :



Là où je travaille on se retrouve à faire des apps natives uniquement parce que les gens ont l’habitude de les chercher dans les stores. Mais ça n’a aucune plus-value.





une PWA peut etre déclaré dans le store Android et Windows (je ne sais plus pour Apple et la flemme de chercher ^^’ )



Ah non chez Apple ça ne risque pas :)


“On va me dire qu’on peut installer d’autres navigateur, mais

honnêtement, qui sur Mac fait ça ? Safari est tellement bien pensé pour

enfermer les utilisateurs.”

Euh… Absolument beaucoup de personnes… -_-


Même ma mère utilise Firefox sur Mac donc bon :P