macOS Sierra isole et surveille les logiciels qui ne sont pas placés dans /Applications
La disparition du bouton « N'importe où » de Gatekeeper n'est pas la seule mesure de sécurité introduite par macOS Sierra vis-à-vis des applications distribuées en dehors du Mac App Store.
Dans sa documentation sur la signature des apps, Apple indique que les applications (signées ou non) nouvellement téléchargées qui sont lancées depuis leur image disque, une archive ou le dossier Téléchargements sont isolées par Gatekeeper dans un emplacement indéterminé en lecture seule. Notez que ces logiciels isolés restent visibles dans leur emplacement d'origine pour pouvoir être lancés facilement.
Ce n'est pas tout, puisque Gatekeeper vérifie également l'intégrité du logiciel à chaque ouverture s'il est lancé depuis le dossier où il a été téléchargé. L'objectif est commun : protéger l'utilisateur contre les malwares qu'il a téléchargés volontairement ou non et qui s'exécutent potentiellement dans son dos.
Ces deux nouvelles mesures de sécurité sont censées être transparentes pour l'utilisateur qui peut continuer à lancer ses apps depuis Téléchargements ou ailleurs, mais Ars Technica a constaté que plusieurs logiciels, dont Tunnelblick, demandaient à être déplacés dans le dossier /Applications. Or, ce déplacement ne fonctionne pas toujours. On imagine que cela sera corrigé dans une prochaine bêta.
C'est bien ça, vu le nombre d'app qui aiment fonctionner en arrière plan, mieux vaut être prudent. Même si un fonctionnement à la iOS serait mieux.
Super initiative de la part d'Apple.
le sandboxing, C'EST un fonctionnement "à la ios".
"nouvellement téléchargées qui sont lancées depuis leur image disque, une archive ou le dossier /Téléchargements sont isolées par Gatekeeper dans un emplacement indéterminé en lecture seule"
Ça ne concerne donc pas les logiciels hors Mac AppStore et installés ou copiés dans /Applications, comme Mamp par exemple?
Car être en lecture seule sur ce type de logiciels serait une catastrophe.
@Fennec72 : d'après la doc qui est assez claire, c'est bien ça :
Autrement dit, celles qui sont dans /Applications ne sont pas concernées par cette mesure. Sierra considère que l'application est en quelque sorte « approuvée » quand elle a été déplacée dans /Applications par l'utilisateur, ce qui est plutôt logique.
Est ce que cela s'applique au dossier Applications de l'utilisateur : ~/Applications ?
Sinon, je suis assez étonné qu'Apple n'ai jamais restreint l'exécution des applications aux seuls dossiers Applications. Il s'agit la d'une mesure de sécurité de base qui repose sur les droits Unix, et puisque Apple définit depuis le départ des dossiers Applications, en plus des ../bin, ../sbin et /opt standards, il est justifié de n'utiliser que ceux la pour les exécutables.
Il est aussi très étrange qu'Apple n'impose pas a l'installation de créer un compte administrateur et un compte utilisateurs, c'est pourtant la base en terme de sécurité sur Unix!
Enfin mieux vaut tard que jamais
O_o
non !
La bonne solution est de créer un compte utilisateur SANS pouvoir, capable éventuellement d'escalader vers + de pouvoir VIA des services de confiance, qui eux ont des acls au près du kernel.
C'est le chemin vers lequel s'achemine Linux et Os X.
Et pourquoi voudriez vous soudainement restreindre l'exécution qu'à un seul dossier, comme si cela était le cas dans le moindre système unix/linux...
Os X isole ce qui vient d'être téléchargé, et demande une opération explicite pour le sortir de quarantaine. C'est très bien.
@ C1rc3@0rc : « Sinon, je suis assez étonné qu'Apple n'ai jamais restreint l'exécution des applications aux seuls dossiers Applications. »
Beuark ! J’espère bien que ça n’arrivera jamais !
Depuis toujours, on range les applications où on veut et on les exécute depuis là sans problème (sauf pour quelques trucs mal écrits qui réclament d’être à un endroit précis et pas ailleurs, mais ils sont loin de représenter la majorité). Ce serait bien moche de changer ça.
« Il s'agit la d'une mesure de sécurité de base »
Ben non.
« qui repose sur les droits Unix »
En fait, non, avec les droits Unix seuls on ne peut pas mettre en place une telle restriction.
« et puisque Apple définit depuis le départ des dossiers Applications, en plus des ../bin, ../sbin et /opt standards, il est justifié de n'utiliser que ceux la pour les exécutables. »
Justifié par quoi ?
Ça ferait passer Mac OS brutalement du statut d’OS le plus souple pour la gestion des applications à celui de seul OS (de bureau) à limiter d’où l’utilisateur à le droit de lancer des exécutables.
Et après ça, la prochaine étape sera quoi ? On interdit les / dans les noms de fichiers ? :-)
> Et après ça, la prochaine étape sera quoi ? On interdit les / dans les noms de fichiers ? :-)
Déjà fait.
La prochaine étape c'est le ":" ;-)
@ byte_order : « Déjà fait. »
Heureusement, non, pas encore.
Il n’y a que le « : » (une idée pas bien brillante de la part de la bande d’origine, qui m’a toujours paru surprenante vu la qualité de leurs réalisations par ailleurs).
C'est juste mais c'est une connerie sans nom!
Sur un systeme qui utilise le / comme séparateur dans le path, c'est vraiment idiot. D'ailleurs si : est interdit c'est bien parce que c'est le separateur dans MacOS 9 et inferieur...
J'ai d'ailleurs jamais compris pourquoi dans les Unix la restriction de nom était aussi permissive. Cela permet des catastrophes grâce au bash et ça oblige le programmeur a faire un boulot qui devrait être fait par l'OS... les joies de gérer les noms avec espaces et operateurs dans les pipes!
Logiquement un nom de fichier devrait se limiter aux alphanumerique, virgule,point-virgule, souligné, tiret et parenthèse. Et sans espace!
Pour ma part j'ai jamais eu besoin d'autres caractères et j'en vois pas l'intérêt.
Mais sinon donnes moi une seule raison pourquoi exécuter une application depuis un autre dossier que (/ ou ~/) Applications?
Avec des droits unix il suffit de ne pas mettre le bit exec pour qu'un fichier ne puisse pas s'exécuter. On peut meme fixer ce bit selon l'utilisateur ou le groupe. Donc c'est bien suffisant. Va lancer un binaire restreint sur l'administrateur en exécutable si t'est pas administrateur...
Quand tu utilises Unix tu lances l'executable par son nom et celui-ci doit se trouver dans $PATH,... ok tu peux contourner et lancer en passant un chemin complet et a condition d'avoir le niveau de droit requis. Mais s'il y a des dossiers bin,sbin,... c'est pour une bonne raison.
Pareil pour le dossier Applications. L'utilisateur s'attend a trouver les applications dans le dossier Applications, pourquoi vouloir le perdre en mettant des applications ailleurs (deja lorsqu'il decouvre qu'il y a un dossier Application au niveau de la session c'est deja compliqué...)
@ C1rc3@0rc : « C'est juste mais c'est une connerie sans nom! »
Ben non, au contraire. C’est même très utile. Comment, sinon, pourrait-on nommer un fichier « Rapport 29/06/2016 » ou « Chapitre 1/2 » et « Chapitre 2/2 », par exemple ?
« Sur un systeme qui utilise le / comme séparateur dans le path, c'est vraiment idiot. »
Mais heureusement, on n’est pas vraiment sur un tel système, et du coup ça fonctionne bien. :-)
Il y a bien quelques bouts de l’OS qui reposent sur ce concept de chemin d’accès et qui utilisent le / comme séparateur, mais ce n’est pas fondamental et on leur présente donc une abstraction qui leur fait croire qu’il n’y a pas de / dans les noms de fichiers, et tout roule.
« D'ailleurs si : est interdit c'est bien parce que c'est le separateur dans MacOS 9 et inferieur... »
Oui, et ça, c’était une connerie sans nom ! Surtout sur un OS où le concept de manipulation de chemins d’accès était quasiment inconnu. Ils auraient dû créer un caractère dédié à ça, pour les très rares occasions où c’était utilisé.
« ça oblige le programmeur a faire un boulot qui devrait être fait par l'OS... »
Quand on développe en utilisant les bonnes API, le boulot est fait par l’OS (et on ne manipule normalement pas de chemins d’accès).
Mais sinon, oui, quand on fait du script en bash ou autre, il faut faire un peu d’efforts pour programmer proprement, en gérant les noms de fichiers « humains ».
« Logiquement un nom de fichier devrait se limiter aux alphanumerique, virgule,point-virgule, souligné, tiret et parenthèse. Et sans espace! »
Arf ! Heureusement pour nous, d’autres que toi se sont penchés sur l’idée de l’informatique en tant qu’outil pour les humains, à leur service et non l’inverse. :-)
Et grâce à eux, on peut utiliser presque ce qu’on veut comme noms de fichiers.
Et les noms qui ne sont pas en alphabet latin, tu voudrais les interdire aussi ? Si ça se trouve, pour toi, même les caractères accentués sont de trop… :-P
@ C1rc3@0rc : « Mais sinon donnes moi une seule raison pourquoi exécuter une application depuis un autre dossier que (/ ou ~/) Applications? »
Ben tout simplement parce que je l’aurai mise ailleurs ! Pourquoi irais-je forcément coller toutes mes applications dans un même dossier ?
J’ai l’impression que tu n’as pas utilisé un Mac avec un OS où il n’existait pas de dossier « Applications »…
« Avec des droits unix il suffit de ne pas mettre le bit exec pour qu'un fichier ne puisse pas s'exécuter. On peut meme fixer ce bit selon l'utilisateur ou le groupe. Donc c'est bien suffisant. »
Non, ce n’est pas suffisant pour faire ce dont tu parlais. Il n’est pas possible, en utilisant seulement les droits Unix, d’interdire l’exécution d’applications depuis d’autres dossiers que /Applications et ~/Applications.
Ce que tu viens d’expliquer, c’est qu’on peut retirer le droit d’exécution d’une instance particulière, clairement désignée, d’une application. Ce n’est pas la même chose.
Ou alors explique-moi comment du définis, avec les droits Unix, la règle : « dans ce dossier (et ses sous-dossiers), il ne sera pas possible d’avoir le droit d’exécution sur le moindre élément, y compris ceux qui y seront copiés dans le futur. »
« Quand tu utilises Unix tu lances l'executable par son nom et celui-ci doit se trouver dans $PATH,... »
Non. Aucune obligation.
« Mais s'il y a des dossiers bin,sbin,... c'est pour une bonne raison. »
Oui : pour organiser les choses en les rangeant (plus ou moins) logiquement. Mais absolument pas pour limiter les droits d’exécution aux éléments de ces seuls dossiers.
@ C1rc3@0rc : « Pareil pour le dossier Applications. L'utilisateur s'attend a trouver les applications dans le dossier Applications, pourquoi vouloir le perdre en mettant des applications ailleurs »
Il ne s’agit aucunement de lui mettre des applications ailleurs.
Il s’agit juste de lui laisser la possibilité de le faire.
Du coup, l’utilisateur facilement perdu profite du fait qu’on a créé pour lui un dossier Applications, qu’on y a mis d’office quelques applications, et que celles qu’il va éventuellement télécharger ensuite y seront mises automatiquement ou lui expliqueront que c’est là qu’il devrait les copier. Du coup, il n’est pas perdu, le pauvre, et il peut continuer tranquillement sa vie sans jamais avoir besoin de savoir qu’il pourrait organiser ses fichiers autrement.
Et il n’y a, du coup, aucune raison d’empêcher ceux qui veulent organiser les choses autrement de le faire. Absolument aucune raison valide.
Le dossier /Applications, c’est pratique pour avoir un endroit où mettre les applis fournies par défaut avec le système. Ça constitue aussi un bon guide pour ceux qui ne vont pas chercher plus loin. Et c’est utile sur une machine à plusieurs utilisateurs, pour regrouper facilement dans un endroit accessible à tous les applications destinées à tous les utilisateurs.
Mais on peut fort bien avoir des applications qu’on ne partage pas avec les autres utilisateurs. Ou n’avoir aucun autre utilisateur, et donc être libre de cette contrainte dans le rangement des applications.
C’est beau, l’informatique. :-)
« deja lorsqu'il decouvre qu'il y a un dossier Application au niveau de la session c'est deja compliqué... »
Oui, la présence de ce dossier est une mauvaise idée. Ça crée de la confusion chez ceux qui n’en ont pas besoin, et c’est inutile à ceux qui seraient susceptibles de l’utiliser.
Il aurait au moins dû être affiché en tant que « Mes applications », pour éviter l’ambiguïté.
@stephmouss :
Et si on met l'app dans /Applications/Utilitaires
Ce que j'ai plutôt tendance à faire est elle vérifiée ?
@Fennec72 :
Tu as juste à déplacer l'app dans le dossier applications si j'ai bien compris, et c'est bon.
@ Fennec72 : « Car être en lecture seule sur ce type de logiciels serait une catastrophe. »
Pourquoi donc ? Les applications n’ayant normalement aucune raison de se modifier durant leur exécution, ce ne serait pas gênant du tout.
parce que Mamp est un abominable hack, une créature de frankeinstein horrible, juste bon à éviter aux gens d'apprendre à monter un serveur linux ou installer PROPREMENT des services dans Os X.
Mamp s'attend à pouvoir modifier l'intérieur même de son dossier d'installation (ce qui devrait être le Mal, même pour installer des pinceaux photoshop...)
@ oomu : « parce que Mamp est un abominable hack [blabla] »
Oui, c’est bien ce que je disais : les applications n’ont normalement aucune raison de se modifier toutes seules une fois lancées. Qualifier MAMP d’abominable machin mal foutu confirme bien qu’il est hors du cas normal.
J’avoue que j’avais raté le fait que Fennec72 citait le cas de MAMP, ce qui fait que ma réponse était un peu en décalage par rapport à ce dont il parlait.
Mais à part cette sombre bouse de MAMP, qui n’est qu’un bricolage mal fichu réalisé à la va-vite par quelqu’un qui ne maîtrise pas les concepts de base de comment doit se comporter une application (essayer de faire utiliser MAMP par plusieurs utilisateurs sur une même machine, c’est toujours un plaisir), je ne connais pas d’autre exception (bien qu’il y en ait probablement).
Et de toute façon, ce serait une bonne occasion de dépister ces applications mal écrites.
Même chose pour ce qui est indiqué dans l’article, qui permet de se motiver pour chercher des alternatives à ces applications tellement mal fichues qu’elles refusent de s’exécuter hors du dossier Applications (sérieusement : si un développeur est incapable d’écrire une application qui fonctionne indépendamment de l’endroit où elle est installée, pourquoi aurait-on confiance en sa capacité à traiter nos données sans problème ?).
Bon il y a un cas ou l'application peut avoir besoin de se modifier mais c'est tordu: enregistrement d'achat d'une application disposant d'une periode de test. Faut bien modifier un fichier quelque part et faire en sorte qu'il ne soit pas jsute dans les preferences qui rendrait le piratage trop simple. Ou alors faut faire comme avec les tenors de l'horreur comme Adobe qui fout des fichiers partout en leur donnant des noms impossible (mais qui ne fait que limiter le risque vu qu'il y a un monitoring du FS qu'on peut utiliser facilement pour surveiller ce que fait une app...)
Aprés une application qui refuse de se lancer si elle est pas dans le dossier Applications:
- le chemin des fichiers est codé en "dur"
- l'app utilise un fichier (lib) d'une application qui est censé se trouver dans le dossiers Applications
- l'app vérifie son intégrité en considérant qu'elle doit se trouver dans le dossier Applications
Mais oui tout ça dénote d'une mauvaise approche. C'est au systeme de restreindre l'exécution a certains dossiers et pas aux applications de le décider.
@ C1rc3@0rc : « Bon il y a un cas ou l'application peut avoir besoin de se modifier mais c'est tordu: enregistrement d'achat d'une application disposant d'une periode de test. »
C’est tordu, mais c’est également inutile, car tout aussi facilement détectable/piratable que l’écriture dans les préférences ou tout autre fichier, et en plus ça ne permet pas de gérer les cas d’utilisateurs multiples sur la machine.
On retombe donc dans le cas d’une application mal écrite.
« Mais oui tout ça dénote d'une mauvaise approche. »
Oui, dans les trois cas cités, c’est un développeur qui a mal fait son boulot.
« C'est au systeme de restreindre l'exécution a certains dossiers et pas aux applications de le décider. »
Euh… non ! Mauvaise réponse au problème. :-)
C’est aux applications d’être capables d’être lancées depuis l’emplacement où l’utilisateur a décidé de les mettre et pas seulement depuis l’endroit où leur développeur a considéré qu’elles devaient se trouver.
"La disparition du bouton « N'importe où » " c'est bug, le bouton reviendra.
"sont lancées depuis leur image disque" sauf si l'image disque est signée.
Cela étant, comme on l'avait précisé dans notre article, il sera toujours possible de lancer des apps non signées à partir de leur menu contextuel ou avec la commande citée par arobasefr.
@Stéphane Moussie : C'est précisé par le gars qui fait la présentation à partir de la 22ième minute.
Edit : désolé : confondu avec le bouton temporaire qui apparait dans le panneau "Sécurité" des préférences systèmes.
Ce qui est anormal c'est de devoir lancer a chaque fois ces applications avec control click alors qu'il n'y a pas de raisons.
Si Apple impose d'utiliser les dossiers Applications, c'est justement que ça permet de limiter et contrôler les applications donc une fois qu'une app a ete validé par l'utilisateur de manière explicite, pourquoi lui casser les pieds ou le pousser a passer par le terminal pour contourner ce mécanisme?
"Ce qui est anormal c'est de devoir lancer a chaque fois ces applications avec control click alors qu'il n'y a pas de raisons."
O_o >_< *_* v_v, et autre ROFLCOTER !
NON !
Une fois autorisé, MacOs SORT L'application de Quarantaine, vous n'avez PLUS BESOIN DE REFAIRE CONTROLE CLICKQUEUH !
C'est UNE SEULE FOIS.
Ben semble pas non avec le nouveau systeme, c'est a chaque fois qu'on veut lancer une app qu'il faut faire la gymnastique.
Ce qui pousse progressivement a ne plus utiliser que des app qui viennent de l'AppStore
On peut retrouver « N'importe où » en entrant dans le Terminal:
sudo spctl --master-disable
:;
"La disparition du bouton « N'importe où » de Gatekeeper", qui devrait n'être que provisoire, vu avec quelle manière c'est mentionné dans les release note de cette première beta...
Moi je l'ai encore, l'option "N'importe où". il y a donc bien des trucs qui déconnent dans la beta ;-)
NON !
Comme dit dans une autre news de MacG, celle qui présente les nouvelles fonctionnalités de Gatekeeper, SI vous avez installé la béta par dessus une version précédente de Os X et SI vous aviez conservé le réglage "n'importe où", alors la MacOs Sierra continuera d'afficher l'option.
Si vous désactivez l'option une fois, MacOs Sierra cessera de vous la proposer pour toujours (ou presque, héhéhéhé...)
Petite correction à apporter à l’article : il n’existe pas de dossier « /Téléchargements » (un dossier « Téléchargements » à la racine du disque, quoi). Le dossier « Téléchargements » dont parle Apple est celui situé dans chaque compte utilisateur.
j'utilise Os X en réglage "Mac App Store et développeurs identifiés", et cela ne m'a jamais empêché d'exécuter des scripts python ramenés de serveurs de linuxiens hongrois du sud. Mais cela me protège éventuellement de gaffe.
C'est touUUUUuuuuuut... Cessez de paniquer de la vie.
DON'T PANIC!
Du moins, pas tant que la Hongrie du Sud n'est pas requalifié en patrimoine mondiale des malwares.
C'est pas seulement une mesure de sécurité mais aussi de bons fonctionnement parce que beaucoup de gens l'utilisent les apps en les lançant de leur image disque.
Cette info me suggère plusieurs questions:
1 - J'ai pour habitude d'installer certaines catégories d'applications (les jeux notamment) dans un dossier spécifique (pour ne pas surcharger inutilement le dossier /Applications).
Est-ce que cette pratique posera problème à Sierra? (ces applications ne sont ni dans le dossier Telechargement, ni dans leur image-disuqe d'origine, mais elles ne sont pas non plus dans /Applications)
2 - Est-ce que les sous-dossiers du dossier Applications sont autorisés (le dossier Utilitaires par exemple, mais aussi les dossiers tels que Microsoft Office 2011, ou les sous-dossiers créés par l'utlisateurs pour mettre de l'ordre dans ses applications)?
3 - Si un installeur place directement une application dans le dossier /Applications, est-ce que GateKeeper lève ses barrières sans contrôle ? (j'ose espérer que non, car ce serait un peu simple de contourner ses contrôles... Une application lancée volontairement par l'utilisateur depuis le dossier Telechargement, me semble a priori plus sûre qu'une application qui s'est auto-installée dans le dossier /Applications)
@ r e m y : « 1 - J'ai pour habitude d'installer certaines catégories d'applications (les jeux notamment) dans un dossier spécifique (pour ne pas surcharger inutilement le dossier /Applications).
Est-ce que cette pratique posera problème à Sierra? »
Poser problème, non, mais il est possible que ces applications se retrouvent lancées comme indiqué dans l’article : depuis un emplacement aléatoire et en lecture seule. Ce qui, en pratique, ne devrait absolument pas être gênant, ni même visible.
Mais on peut remarquer que la note technique à laquelle se réfère l’article parle bien de « newly-downloaded app from a disk image, archive, or the Downloads directory ». Est-ce que ça signifie que ce traitement ne sera appliqué qu’au premier lancement d’une application nouvellement téléchargée et qu’ensuite elle ne sera plus concernée ? Est-ce que ça signifie que si on la déplace ailleurs que son image-disque, l’endroit où elle a été dézippée ou le dossier Téléchargements, elle ne sera plus concernée ? Ce serait un peu bizarre, mais je crois qu’on ne peut pas conclure grand chose d’une description de ce système en seulement deux phrases dans une note technique. Il faudra attendre de le voir à l’œuvre pour être sûr de ce qu’il fait réellement.
« 3 - Si un installeur place directement une application dans le dossier /Applications, est-ce que GateKeeper lève ses barrières sans contrôle ? »
A priori non, le comportement semble être le même qu’actuellement.
En tout cas, cette note technique confirme qu’Apple s’obstine dans l’idée de recommander les images-disques comme mode de distribution des applications (hors App Store).
Dommage, car ce système est toujours aussi mal compris (et mal utilisé) par beaucoup d’utilisateurs, et fait référence à une approche de la distribution d’applications (sur disque physique) qui remonte au précédent millénaire.
Heureusement, Sierra apporte tout de même une avancée mineure sur ce point, en proposant de faire le ménage de l’image-disque une fois que l’utilisateur a copié son application ailleurs… s’il a compris qu’il fallait faire ça.
C'est sûr qu'Apple aurait interêt a minima, à modifier l’icône utilisée pour les images-disque (qui d'ailleurs ne représente pas une disquette, mais un lecteur de disquettes...).
Un paquet, un boitier de logiciel, serait déjà un peu plus explicite sur le fait que ce n'est qu'un conteneur duquel il faut sortir l'application!
@ r e m y : « qui d'ailleurs ne représente pas une disquette, mais un lecteur de disquettes... »
Non, tout de même, la référence n’est pas si ancienne. :-)
L’icône d’une image-disque montée représente un lecteur de CD/DVD, ce qui correspond à l’idée initiale de cette distribution via des images-disques : faire une version virtuelle de ce dont les gens avaient l’habitude à l’époque, c’est-à-dire l’installation de logiciels depuis un CD. Mais ça n’a jamais été bien compris (le côté virtuel venant tout gâcher), ça n’évoque plus grand chose de nos jours, et ça ne fait que ralentir de processus d’installation d’une application et faire faire des erreurs aux utilisateurs qui ne comprennent pas ce système. Ça n’a jamais été une bonne idée.
Et en plus, il y a un manque de cohérence dans les icônes, puisque celle du fichier d’une image-disque représente un disque dur (que peu d’utilisateurs reconnaissent, et qui est en décalage avec le fait que la plupart des images-disques qu’on croise sont en lecture seule, étant donc plus proches d’un CD que d’un disque dur).
Mais il semble que quelqu’un chez Apple aime bien ce système.
l’icône d'une image disque n'est pas celle d'un disque dur, mais d'un lecteur (au choix), de disquette ou de CD/DVD, reconnaissable à la fente représentée à l'avant.
Il vaudrait mieux que ce soit directement l’icône d'un CD/DVD, voire quelque chose de complètement nouveau montrant que ce n'est qu'une enveloppe dont il faut extraire l'application.
@ r e m y :
L’icône du fichier d’une image disque (le fichier avec extension dmg) utilise bel et bien l’image d’un disque dur (sur fond d’icône de document, en forme de feuille avec un coin retourné), comme je l’ai écrit. C’est uniquement l’icône de l’image disque une fois montée qui a l’apparence d’un lecteur de CD (et non de disquettes, en raison des proportions de la fente).
Et il faudrait effectivement changer ces deux icônes, pour passer à quelque chose de plus explicite et, au passage, uniformiser la représentation utilisée (parce qu’un disque dur interne d’un côté et un lecteur de CD de l’autre, ça manque franchement de cohérence !).
Je pense que le disque optique, bien qu’un peu daté, serait probablement le plus efficace pour faire comprendre de quoi il s’agit. Pourquoi est-ce qu’Apple n’a jamais utilisé ça alors que l’usage d’images disques visait manifestement à coller à l’usage des CD/DVD ? Mystère !