Sandboxing OS X : deux expériences de développeurs

Florian Innocente |
sandboxingapple-1
Le sandboxing des applications dans Lion sera obligatoire pour qu'elles soient acceptées sur le Mac App Store. Apple a informé les développeurs cette nuit que le délai de mise en conformité avait été repoussé au début de l'année prochaine (lire Mac App Store : bac à sable obligatoire en mars 2012). Deux développeurs expliquent concrètement ce que cela implique pour leurs logiciels.

Andrew Pepperrell, l'auteur du lanceur multifonction Alfred a publié un billet sur son blog. (lire aussi Alfred 1.0 en approche).

Il rappelle que son utilitaire sollicite diverses ressources d'OS X pour lancer des fichiers, ouvrir des URL, exécuter des AppleScripts ou commandes Terminal «Il est en résumé une interface rapide avec le coeur de Mac OS X».

Le PowerPack est une option payante d'Alfred qui déverrouille des fonctions supplémentaires (accès à Carnet d'adresses, historique d'album, création de commandes Shell par l'utilisateur, etc). Même si ce PowerPack utilise des interfaces de programmation publiques, sa nature contrevient au sandboxing d'OS X puisqu'il met en relation étroite Alfred avec d'autres applications ou éléments système.

Un obstacle technique qui se double d'une perte financière puisque l'absence de cette option dans Alfred sur le Mac App Store - désormais un puissant circuit de promotion pour une application - représente une source de revenus en moins pour l'auteur.

Pepperrell va donc proposer deux versions d'Alfred, celle du Mac App Store sans cette option intégrée et une autre, complète, distribuée depuis son site web. La solution intermédiaire qui consisterait à proposer le PowerPack sur le Mac App Store pour ensuite l'ôter à compter de mars prochain - au grand dam des clients qui verraient leur achat déprécié fonctionnellement - étant pour lui exclue.

alfred10


Autre expérience, celle de Louka Desroziers, développeur du lecteur audio Ecoute qui s'appuie sur le contenu d'iTunes sans avoir besoin qu'il soit ouvert [2.0.9 – Français – 6,99 € – Louka Desroziers].

J'ai essayé de faire passer Ecoute dans son bac à sable… sans grande satisfaction. Déjà, il faut entièrement retester son application, parce qu'il y aura toujours un petit quelque chose qui ne marchera pas. Après avoir regardé les choses d'un peu plus près, le premier problème auquel je me heurte est bel et bien l'accès simple en lecture des fichiers. Mais je suis un cas assez isolé. Ecoute se sert d'un fichier XML généré par iTunes. Ce fichier contient les informations des morceaux de votre bibliothèque iTunes, ainsi que le chemin d'accès de chacun des fichiers audio et vidéo.

Problème, ce chemin est absolu et il est récupéré via un fichier (et non pas au moyen d'interfaces de programmation conçues pour récupérer divers dossiers clés d'OS X). Ça pose donc un gros problème pour quelqu'un comme moi qui laisse iTunes gérer l'organisation de ses fichiers. C'est à dire dans '~/Musics/iTunes/'. Or, il s'agit là du dossier 'Music' qui, une fois l'application mise dans son bac à sable, n'est plus accessible comme auparavant. On est obligé de passer par la sandbox pour accéder à ce dossier spécifique du système.

Bien sûr ça peut toujours être résolu en détectant que le fichier se trouve dans le dossier "Music" de l'utilisateur, et en transformant donc le chemin en utilisant directement l'API permettant de récupérer le 'NSMusicDirectory'. Mais ça implique de rajouter du code. Le sandboxing n'est donc pas aussi facile qu'Apple veut bien le laisser entendre.

Autre problème, je n'ai, pour le moment, pas trouvé comment autoriser mon application à envoyer des notifications à travers OS X. C'est bien utile pour les développeurs tiers qui souhaiteraient faire une application qui se servirait d'Ecoute.

Je pense notamment à Sleepytime [2.0 – US – 3,99 € – 24,1 Mo – Michael Fortin] qui utilise les notifications envoyées par Ecoute à chaque fois que le lecteur change d'état ou de morceau.

sleepytime


La réponse d'Apple à ce sujet est claire: le sandboxing n'autorise pas les 'distributed notifications' qui contiennent un 'userInfo', autrement dit, il est impossible d'envoyer une 'distributed notification' avec des informations complémentaires.

Apple stipule (officieusement, car ça n'est marqué nulle part, mais c'est la réponse qu'un développeur chez Apple m'a donnée) qu'il faudra préférer créer plusieurs notifications ayant des noms différents, ce qui permettra de distinguer les actions dans mon application. Autrement dit, plutôt que d'avoir une notification qui indique, de par son nom, que l'état du lecteur d'Ecoute a changé, puis ajouter un 'userInfo' contenant cet état, il faudra créer une notification par état. SleepyTime devra donc être mis à jour quand Ecoute sautera dans son bac à sable…

De plus, j'ai vraiment du mal à comprendre en quoi le sandboxing donne une impression de sécurité. Pour moi, c'est plus un sentiment de limitation. L'avantage avec iOS, c'est qu'on était prévenu dès le début, avant même que la première application n'apparaisse sur le store. OS X, même depuis l'arrivée du Mac App Store, restait un bonheur pour certains développeurs qui souhaitaient se libérer un peu de l'emprise d'Apple sur iOS. Le Mac App Store risque de devenir un magasin d'applications limitées. Et Cydia for OS X sera la bienvenue pour certains utilisateurs…

avatar Yohmi | 
Je présume que ces applications passeront le processus de vérification si les justifications s’avèrent compréhensibles (puisqu’Apple a bien précisé que si la demande était faite, le cas sera étudié)… sinon, ça risque d’être compliqué ^^
avatar Zouba | 
[quote]De plus, j'ai vraiment du mal à comprendre en quoi le sandboxing donne une impression de sécurité. Pour moi, c'est plus un sentiment de limitation.[/quote] C'est très étonnant de lire un développeur remettre en cause la sécurité apportée par le passage par un bac à sable. Ce qui fait débat, c'est la direction prise par Mac OS X, le contrôle d'Apple sur les applications, la manière de procéder vis-à-vis du Mac App Store, mais certainement pas la sécurité apportée le fait que les applications fonctionneront avec des privilèges limités.
avatar Jimmy_ | 
@Zouba : d'accord sur le principe du moindre privilège mais c'est un Mac pas un téléphone. Un ordinateur en sécurité est un ordinateur dans un coffre fort et ça n'est pas certains non plus.
avatar Rigat0n | 
Ben moi j'ai (comme beaucoup de monde) payé Ecoute sur le Mac App Store donc le monsieur est prié de se bouger, soit en adaptant son code, soit en m'offrant une version externe au MAS non-sandboxée, pour que je puisse continuer à l'utiliser. D'ici mars ça devrait aller, quand même... Je veux dire, je trouve ça assez mal géré de la part des devs. Le sandboxing devait être obligatoire à partir de novembre, et il a fallu qu'Apple le repousse parce que les devs avaient pas eu le temps ! Et maintenant, y'a encore des soucis. Je n'y connais _rien_ en programmation Mac OS X, mais là il me semble qu'il y avait deux solutions : - préparer l'arrivée du sandboxing, puisque c'était prévu pour novembre (il me semble qu'on entend parler de ça depuis un moment) - s'abstenir de publier sur le Mac App Store, si l'appli ne PEUT PAS fonctionner en sandboxing, ben pas de Mac App Store. Je suis en plus assez "choqué" (le mot est un peu fort, mais j'ai pas trouvé mieux) par cette communication, vu que j'ai acheté Ecoute suite à des infos de MacGé sur Ecoute 3 (sorte de pub un peu déguisée, faut avouer) et que ce n'est que maintenant qu'on entend les plaintes du dev...encore sur MacGé ! J'utilise ce logiciel vraiment quotidiennement et avec un grand plaisir (non parce que 6€ c'est pas la ruine, mais ça me ferait juste chier de plus pouvoir l'utiliser). Après, que les devs soient choqués qu'Apple ne disent que ce n'est "qu'une case à cocher", je comprends. Et si je puis me permettre, Cydia sur iOS est la pire boutique que j'ai jamais vu sur aucun OS : c'est un bordel monstre remplit de "toys" qui ne servent à rien et de thèmes tous plus moches les uns que les autres (les beaux thèmes on les trouve sur ModMyi, Macciti et ThemeIt, mais jamais sur Cydia) et surtout les devs qui vendent dessus se font pirater en masse, vu que c'est d'une simplicité enfantine pour l'utilisateur. De plus l'appli est moche au possible, remplit de pubs de la taille de l'écran, ne proposant qu'en fait des fenêtres sur des webviews affreuses. Cydia iOS est un passage obligé quand on jailbreak, donc on fait avec cette daube, Cydia sur Mac je passerai mon tour.
avatar USB09 | 
@Jimmy_ : C'est toujours un processeur et des fils. Avec des entrées et des sortie. Ce qui revient au même. La sécurité est la meme.
avatar Mark Twang | 
Je trouvea politique d'Apple excellente, et en poussant l'usage du Sandboxing, et en laissant un délai supplémentaire, et en acceptant un dispositif de dialogue avec les developpeurs pour obtenir des dérogations ou pourquoi pas améliorer la prise en charge du Sandboxing. C'est un pas en avant vers des applis plus propres, moins invasives dans le système.
avatar tipoli | 
Festival de la pleurniche.... "Mais ça implique de rajouter du code.". -> Sérieusement?? Prochaine étape pleurer car on doit utiliser un clavier pour coder? "j'ai vraiment du mal à comprendre en quoi le sandboxing donne une impression de sécurité". -> Bah ça donne pas une impression de sécurité, ça sécurise. Tout court. Le sandboxing est une technique qui a fait ses preuves. "'il faudra préférer créer plusieurs notifications ayant des noms différents, ce qui permettra de distinguer les actions dans mon application" -> Si c'était pas le cas avant, j'ose pas imaginer la tête du code... C'est la norme, qui d'ailleurs se retrouve dans les API d'Apple. Maintenant très loin d'être insurmontable même pour implémenter une rétro compatibilité. "Et Cydia for OS X sera la bienvenue pour certains utilisateurs" -> \o/ Ouais, ça s'appelle Mac OS X. Maintenant si la reference est a un store, avec des applications piratées, virusées, je trouve ça chevaleresque de la part d'un développeur. Enfin, ça a été prouvé, les restrictions d'Apple et le fait que ça soit le store officiel, font le succès de la plateforme. Suffit de voir ça: http://appbodega.com/ Combien achète la dessus? Combien connaisse? Le cas d'Alfred est (heureusement) plus intéressant, obligation de changement de mode de vente, restructuration majeur du soft, etc. Même si je connais la réponse d'Apple... Bon courage pour lui.
avatar dperetti | 
Heu... Cydia sur OS X ça n'a tout simplement pas de sens... Il faudrait qu'Apple interdise l'accès administrateur à son OS pour qu'on en arrive là. Ca n'arrivera tout simplement jamais.
avatar bigham | 
"puisqu’Apple a bien précisé que si la demande était faite, le cas sera étudié" Je pense que tant qu'on n'a pas été confronté au processus de validation de l'App Store ou du Mac App Store, on a une vision Bisounours du processus de validation. L'arrivée du Mac App Store et de l'App Store a sans doute fait exploser la consommation d'anti-dépresseurs mondialement. "Le sandboxing devait être obligatoire à partir de novembre, et il a fallu qu'Apple le repousse parce que les devs avaient pas eu le temps !" Oui, bien sûr, Apple : bien. Développeur tierce : pas bien. D'ailleurs le sandboxing est tellement bien foutu, stable et fonctionnel qu'Apple le supporte dans toutes ses applications… Ah tiens, on me dit que non. Que c'est uniquement Preview et TextEdit… et qu'il y a plein de logs d'erreurs de debug et d'erreurs dans Console.app si on y prête attention. Le sandboxing est complètement foiré dans Mac OS X Lion actuellement que ce soit au niveau stabilité, possibilité, documentation ou compatibilité. Comme le cite si bien Gruber : If You Release Shit, You Look Like Shit.
avatar liocec | 
@bigham : 'Je pense que tant qu'on n'a pas été confronté au processus de validation de l'App Store ou du Mac App Store, on a une vision Bisounours du processus de validation.' 200% d'accord.
avatar Ali Ibn Bachir Le Gros | 
Un jour viendra où le Mac App store sera le seul moyen d'installer des applications sur un Mac. Avec la convergence entre iOS et Mac OS X, ce n'est peut-être pas de la fiction. Apple fait des bons produits mais leur emprise sur leurs clients est inquiétante, d'autant plus que le fanatisme de certains d'entre eux leur fait tout accepter. Je sens que les insultes vont pleuvoir ...
avatar Gueven | 
Pour Ecoute, ça ne semble pas bien compliqué au vu du taff déjà réalisé. J'ai l'impression qu'ici l'article donne trop le ressentiment que c'est complexe alors que c'est clairement trivial.
avatar lmouillart | 
@Ali Ibn Bachir, Le Gros : Tous ce que les utilisateurs de Microsoft on refusé et rejeté pendant des années, certains utilisateurs d'Apple l'accepte en criant au miracle. Et la fuite de cette univers ne sera pas possible car les produits Apple qui étaient interopérable ne fonctionnent qu'entre eux, DRM spécifiques. Apple peut resserer cet écho système quand elle le souhaite... et c'est ce qu'elle fait.
avatar Yohmi | 
Je ne pense pas qu’Apple vérouillera un jour intégralement son système. Leur but est avant tout de proposer une expérience clés en main, simple et efficace, et c’est ce que l’AppStore initie. Pour autant, je ne vois pas quel serait le bénéfice pour Apple de bloquer totalement son écosystème, la clientèle des Macbook et autres iMac va au fur et à mesure se différencier drastiquement de la clientèle iOS, où Apple propose son système verrouillé qui convient d’ores et déjà à la majorité des clients de ces produits (sinon, pourquoi les achèteraient-ils, sachant à l’avance qu’ils ne peuvent pas, en théorie, sortir de l’écosystème verrouillé à la naissance même d’iOS ?). Personnellement, si j’utilise un Mac, en parallèle aux appareils iOS, c’est parce qu’il y a un confort pour certaines tâches que je ne retrouve pas sur les iDevices, et vice-versa. Il n’y a aucun intérêt pour Apple de verrouiller totalement son environnement de bureau, on sait d’ores et déjà où se procurer des programmes a priori sécurisés, avec des transactions (et micro-transactions) gérées sans aucun déboire, et un système de mise à jour, bien que ralenti pour les développeurs à cause de l’étape de validation, efficace pour les consommateurs (hors solutions professionnelles). Vu que cette catégorie de produits ne connaît pas les limitations de puissance/mémoire des iDevices, il n’y a pas d’intérêt pour Apple de tout maîtriser de A à Z, le choix sera vite fait par le consommateur en fonction de ses besoins. Apple ne gagne pas une fortune avec ses AppStore, mais avec le matériel qui permet d’y accéder. L’AppStore sur iOS est un moyen de s’assurer du bon fonctionnement (et de la sécurité) d’une génération d’appareil qui ne connaît pas les mêmes contraintes que l’environnement desktop du Mac. Je reste particulièrement sceptique face à cette hypothèse, par contre il me semble évident qu’Apple ne cherchera pas à faciliter la tâche aux développeurs qui souhaitent travailler en dehors de son écosystème.
avatar Rigat0n | 
@bigham : Comme je l'ai dit, je ne connais pas les détails. Mais le développeur d'Ecoute à l'air de dire que c'est faisable, mais qu'il lui faudrait "modifier son code". Ça me parait un peu fort. Et je le répète, mon (léger) mécontentement vient du fait qu'on sait depuis un moment que le sandboxing va devenir obligatoire et que les devs ne se sont visiblement pas penchés sur la question, ils se réveillent maintenant. Ils semblent profiter de la visibilité du Mac App Store sans en accepter vraiment les conditions, et à cause de ça, leurs clients risquent de se retrouver sans mise à jour ni support du logiciel acheté sur le MAS. Je suppose que le dev d'Ecoute adaptera son appli, ou se débrouillera sans le MAS, donc y'a aucun souci, mais j'aime pas trop cette façon de procéder.
avatar Rigat0n | 
@Ali Ibn Bachir, Le Gros : Apple n'a pas intérêt à aller dans cette voie-là. Ils perdront un tas de clients, moi le premier. Laissons-leur le bénéfice du doute.
avatar domd | 
En fait c'est parfait. Une version bridée sur le MAS pour les aficionados et une version en ligne complète (à -20%. Je leur laisse volontiers 10% pour les frais d'hébergement, même 15%) C'est parfait ;-)
avatar Eaglelouk | 
Ce qui m'emmerde surtout c'est de devoir écrire du code DEGEULASSE pour re-formatter les chemins des fichiers audio afin qu'ils pointent vers la sandbox, et non directement dans ~/Music/iTunes/... "Cydia pour OS X ça existe déjà, ça s'appelle OS X.." Pas vraiment, OS X ne regroupe pas toutes les applications que l'on pourrait trouver sur Mac.. Ce qui est bien avec l'App Store c'est qu'on a une boutique.. On ne se sert plus de google lorsqu'on cherche une application. L'intérêt de Cydia serait d'avoir un App Store avec des applications beaucoup moins limités, mais certes moins contrôlées.. Quand je dis que je ne vois pas ce qu'apporte le sandboxing en terme de sécurité, je me suis mal exprimé. En fait ce que je veux dire c'est que je doute que l'utilisateur lambda s'en pré-occupe. On a jamais eu de problème de sécurité concernant la majorité des applications sur Mac. Mis à part quelques malware par-ci par-là (qui se trouvent sur des réseaux pirates d'ailleurs.. pebkac..). Ce qui est important pour l'utilisateur c'est ce qu'une application est capable de lui fournir.. or on va se retrouver avec des limitations à cause du sandboxing. Et comme l'a dit le développeur de Alfred, le Mac App Store n'est pas un canal de distribution à négliger...
avatar BeePotato | 
@ Eaglelouk : En quoi ce code est-il si dégueulasse ?
avatar gel_hydroalcoolique | 
Assez instructif... En gros tu sais comment résoudre le problème mais cela t'embête car tu devras 'pour toi' écrire un code dégueulasse... Si tu penses que l'utilisateur se fout d'une sandbox, moi perso, je me fous de la qualité du code tant que l'application répond à mon besoin :) Et je dirai que tes propos angéliques sur la forteresse anti-virus intrinsèque du Mac émoustille ma curiosité sur la qualité de ton code en terme de sécurité mais je m'égare !
avatar gel_hydroalcoolique | 
Assez instructif... En gros tu sais comment résoudre le problème mais cela t'embête car tu devras 'pour toi' écrire un code dégueulasse... Si tu penses que l'utilisateur se fout d'une sandbox, moi perso, je me fous de la qualité du code tant que l'application répond à mon besoin :) Et je dirai que tes propos angéliques sur la forteresse anti-virus intrinsèque du Mac émoustille ma curiosité sur la qualité de ton code en terme de sécurité mais je m'égare !
avatar gel_hydroalcoolique | 
Assez instructif... En gros tu sais comment résoudre le problème mais cela t'embête car tu devras 'pour toi' écrire un code dégueulasse... Si tu penses que l'utilisateur se fout d'une sandbox, moi perso, je me fous de la qualité du code tant que l'application répond à mon besoin :) Et je dirai que tes propos angéliques sur la forteresse anti-virus intrinsèque du Mac émoustille ma curiosité sur la qualité de ton code en terme de sécurité mais je m'égare !
avatar Santa Claus | 
@lmouillart : '@Ali Ibn Bachir, Le Gros : Tous ce que les utilisateurs de Microsoft on refusé et rejeté pendant des années, certains utilisateurs d'Apple l'accepte en criant au miracle. Et la fuite de cette univers ne sera pas possible car les produits Apple qui étaient interopérable ne fonctionnent qu'entre eux, DRM spécifiques. Apple peut resserer cet écho système quand elle le souhaite... et c'est ce qu'elle fait.' Pourquoi je l'attendait celle là ? Et pire, pourquoi je m'attendais à ce que ça vienne de là ? Y'a des soirs, je m'épate !
avatar Santa Claus | 
Puisque certains se lancent dans la critique sans connaître le domaine dont ils parlent, pourquoi pas moi aussi ? Parmis le peu de choses que j'ai entendu dire sur la programmation, quelle qu'elle soit, est-il exact qu'un code dit de qualité doit être le plus concis possible ? Un code plus long qu'un autre pour obtenir le même résultat semblerait alors comme parasité...? Et à terme, suivant le volume de code utilisé pour une application, ce code parasite ne peut-il pas être source de lourdeur ou de ralentissement de l'appli ? J'avais cru comprendre que c'était de là que venaient l'obsession des développeurs pour un code "propre", ainsi que les critiques sur certaines applications générant du code à la place de l'utilisateur ou du développeur, à la base pour faciliter le travail, et finalement générant pas mal de problèmes... Auquel cas un procédé visant à obliger le développeur à ajouter du code pour obtenir un résultat identique serait aux yeux de ce même développeur, et de manière fort plus compréhensible, une hérésie... Et non un simple manque de motivation digne d'une feignasse... Si je me trompe, corrigez moi, j'aimerai comprendre mon erreur ! (sans rire)
avatar OVF | 
À quand Siri for Developers? "Fais moi une fenêtre là Non ton ascenseur là il est moche tu le changes Là faut une alerte Plus gros le bouton et plus bleu aussi" Nan sérieux faut encore écrire du code? Méchant Apple

Pages

CONNEXION UTILISATEUR