1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Mountain Lion : la revue de Ars technica (14)

Là où Lion a trébuché, Mountain Lion regroupe et va de l'avant.

Par John Siracusa, 25 Juillet 2012


Gatekeeper

Gatekeeper est la dernière station sur le chemin pris par Apple pour assurer une expérience informatique sur le Mac plus sécurisée et sans soucis. Une fois encore, iOS en est le modèle. En rendant les opérations d'achat, d'installation et de suppression de logiciels tellement simple et sans risque, iOS a construit une place de marché pour logiciels très vivante, à partir de rien, en seulement quelques années.

L'introduction du Mac App Store l'an dernier, a fait faire à la plateforme Mac un pas de géant vers l'idéal d'iOS. Mais ce n'est pas seulement le processus mécanique par lequel des applications sont achetées et installées qui a conduit à la croissance explosive de l'App Store iOS. iOS a aussi surmonté une barrière mentale historique à l'achat de logiciels : cette nouvelle application ne va-t-elle pas bloquer mon ordinateur ?

Avec iOS, Apple a prouvé aux clients que la réponse à cette question est un "non" franc. Elle a réussi en conservant un contrôle complet sur les applications qui sont autorisées sur la plateforme, et en limitant sévèrement ce que ces applications sont autorisées à faire. Le résultat final : des millions de clients de l'iOS App Store heureux et sans craintes.

Beaucoup des technologies sous-jacentes qui ont rendu les aspects techniques du modèle d'application iOS fonctionnels sont installés au niveau du cœur de l'OS qui est partagé par iOS et OS X. Les incarnations OS X de ces technologies ont été mise en place lentement, séparément, sur plusieurs années.

La signature de code

Mac OS X 10.5 Léopard, lancé en 2007, a introduit la signature de code sur la plateforme Mac. La signature de code est un moyen de prouver de façon cryptographique que les composants essentiels d'une application n'ont pas subi d'altérations.

Au moment où la signature de code a été ajoutée à Mac OS X, elle était considérée principalement comme un objet de curiosité. Son plus gros bénéfice pratique est qu'elle permettait aux développeurs sur Mac de diffuser des mises à jour de leurs applications qui n'exigeaient pas que l'utilisateur autorise à nouveau l'accès de l'application à la Keychain. Avec la signature de code, une application pouvait "prouver" qu'elle était une nouvelle incarnation, légitime, de l'application qui avait déjà été autorisée.

A cette époque, le SDK de ce qu'on connaissait comme l'OS d'iPhone venait juste d'être annoncé mais n'était pas encore disponible. Ce que personne ne savait alors, c'est que la signature de code serait un des piliers sur lesquels l'écosystème de l'App Store iOS serait construit.

Les bidules iOS refusent tout simplement de faire tourner n'importe quelle application qui n'a pas sa propre signature -la signature d'Apple. C'est la moitié technique de la manière dont Apple contrôle quelles applications sont autorisées sur la plateforme iOS. Un développeur signe cette application, et la soumet à l'App Store. Si l'application remplit les conditions d'Apple, Apple re-signe celle-ci de sa propre clé privée, et la publie alors sur l'App Store.


Le bac à sable

La livraison de OS X 10.7 Lion l'an dernier a introduit le bac à sable pour les développeurs Mac.

Faire tourner une application dans un bac à sable a pour but de minimiser les dommages qui pourraient être provoqués si cette application est compromise par un élément de logiciel malvaillant. Une application en bac à sable renonce volontairement à la possibilité de faire beaucoup de choses qu'un processus normal, exécuté pas le même utilisateur, pourrait faire. A l'évidence, une application qui se comporte bien, ne fera pas cela. Mais si une application devient compromise, elle peut être forcée à faire quelque chose de destructeur.

Chaque application pour bac à sable doit déclarer ses intentions en réclamant des "droits" qui décrivent exactement de quelles ressources elle a besoin pour faire son travail. Imaginez un bac à sable comme une sorte de liste blanche de fonctionnalités. Cela se distingue du modèle traditionnel du Mac, où les applications peuvent faire n'importe quoi à l'exception des choses qui sont sur la liste noire du système. Vous pouvez en savoir plus sur le bac à sable dans le compte-rendu de Lion de l'an dernier, et dans la documentation d'Apple pour les développeurs.

Le bac à sable est une technologie à laquelle vous choisissez de participer ; les développeurs Mac doivent choisir d'adapter leurs applications au bac à sable. Du point de vue du développeur, les inconvénients du bac à sable sont évidents. Le simple fait de mettre une application existante dans le bac à sable la rendra à peu près certainement inutilisable. Pour tous les points où l'application ne fonctionne pas correctement un message est affiché qui indique quelle action est interdite dans le bac à sable. Le développeur doit alors trouver de quelles autorisations l'application a besoin pour effectuer la fonction interdite. Faire mousser, rincer, recommencer.

C'est un gros travail que d'arriver à une application qui ressemble à, et se comporte exactement comme celle d'où vous êtes parti(e), si vous avez de la chance. Dans le cas contraire, vous allez trouver qu'il n'y a pas d'autorisation pour l'action que votre application a besoin d'entreprendre. Que faire alors ?

Pour faciliter la transition vers le bac à sable, Apple a mis en place des autorisations "temporaires" pour certains développeurs qui ne pourraient pas autrement adapter leur application au bac à sable. La vision optimiste de cette autorisation "temporaire" est que Apple finira par créer une autorisation officielle pour permettre aux applications d'accomplir cette action. La vision pessimiste, est que ces autorisations temporaires ne fournissent qu'un délai de grâce pendant lequel les développeurs doivent se représenter comment reconstruire leurs applications pour qu'elles s'adaptent au bac à sable, ou qu'ils abandonnent leurs efforts.

Dans la pratique, les deux cas sont arrivés. Apple a introduit beaucoup de nouvelles autorisations et a amélioré le bac à sable d'OS X dans les livraisons intermédiaires d'OS X 10.7. Certains développeurs ont aussi revu leur stratégie de conception de l'application pour mieux s'adapter au modèle du bac à sable. Néanmoins, le processus de mise en place du bac à sable a provoqué des tiraillements entre les développeurs et Apple.

Apple a par le passé demandé aux développeurs de faire des choses beaucoup plus difficiles, comme de porter leurs applications sur un système d'exploitation pour Mac radicalement différent, par exemple. Mais dans ces cas, les avantages étaient évidents à la fois pour les développeurs et les utilisateurs ; les bénéfices du bac à sable semblent un peu plus ésotériques.

C'est vrai, les applications mises dans le bac à sable sont beaucoup moins susceptibles d'être exploitée par un logiciel malveillant (malware), mais est-ce un problème réel sur le Mac en ce moment ? Et même si un développeur adapte son application au bac à sable, qu'en est-il des autres applications qui n'ont pas été adaptées sur le Mac ? Le malware ne va-t-il pas les cibler de préférence ? Et à quoi tout cela sert-il si les utilisateurs n'accordent pas une certaine importance au bac à sable ? Le temps des développeurs ne serait-il pas mieux utilisé à rajouter des fonctionnalités que les utilisateurs puissent apprécier et payer ?

Pour résoudre ces problèmes, Apple a décrété que toutes les applications vendues sur le Mac App Store devraient être compatible avec le bac à sable. La date originelle d'application de cette règle devait être Novembre 2011. Apple a plus tard repoussé cette date au 1er mars 2012, pour donner plus de temps aux développeurs, et pour se donner à elle-même plus de temps pour améliorer le bac à sable, et qu'il fournisse un meilleur support aux applications Mac existantes.

Au début de 2012, Apple a une nouvelle fois repoussé la date fatidique cette fois au 1er juin 2012. A mesure que juin approchait, certains développeurs Mac s'attendaient à ce que Apple repousse cette date à nouveau. D'autres espéraient simplement. Mais cette fois, Apple est restée ferme.

Le résultat immédiat a été que plusieurs applications Mac, -certaines très populaires- ont dû abandonner le Mac App Store. Dans d'autres cas, de nouvelles applications Mac dont le processus de développement démarrait ont été pré-emptivement accélérées quand il est devenu évident que le bac à sable était la nouvelle loi de la jungle.

Apple ne fait pas cela pour être vindicative. Le Mac App Store est une partie de plus en plus importante de l'écosystème logiciel du Mac. La facilité d'achat et d'installation, l'interface standardisée pour les mises à jour d'applications, et l'exposition qui s'est considérablement accrue aux clients potentiels que fournit le Mac App Store en a fait un canal de distribution de logiciel extrêmement recherché, qui représente un pourcentage de plus en plus grand des ventes des développeurs. Etant donné le succès haut la main de l'iOS App Store, il est facile d'envisager la domination du Mac App Store sur toutes les autres formes de distribution du logiciel pour Mac (si ce n'est pas déjà fait).

Dans ce scénario, les bénéfices du bac à sable -au moins pour les utilisateurs finaux- sont plus clairs. Apple elle-même a mis délibérément dans le bac à sable ses démons et ses applications dédiées dans OS X depuis plusieurs années maintenant. (Dans Mountain Lion, Facetime, Mail, Rappels, Notes, Game Center et Safari sont tous ensablés). Si la plupart des utilisateurs de Macs achètent aussi toutes leurs applications tierces sur le Mac App Store, un logiciel malveillant risque d'avoir beaucoup plus de difficultés à trouver une application qu'il puisse exploiter. Songer à une forme d'immunité du troupeau pour les logiciels Mac.

Alors que cela peut grossir les bénéfices du bac à sable pour les utilisateurs et pour la plateforme dans son ensemble, cela apporte peu de réconfort à la détresse des développeurs. Pire, l'importance accrue de Mac App Store marginalise encore plus les applications qui n'ont jamais pu se vendre dans le Mac App Store. Une fois encore, certaines sont très populaires et hautement respectées. Quel est l'avenir dans le Store pour ces applications, et celles qui en ont été rejetées à cause du bac à sable ? Maintenant, en fin de compte, nous sommes revenus au point de départ : Gatekeeper