Ce n’est pas un bug, iOS 17.4 va liquider les web apps (PWA) en Europe
Les craintes des développeurs et des utilisateurs des web apps avancées (PWA) étaient fondées : iOS 17.4 va gravement réduire leurs capacités sur iPhone en Europe. Les web apps ajoutées sur l’écran d’accueil ne s’ouvriront plus dans une fenêtre à part entière et perdront des fonctions, parmi lesquelles les notifications.
Sur son portail développeur, Apple indique finalement que ce nouveau comportement remarqué dans les premières bêtas d’iOS 17.4 n’est pas un bug mais un changement délibéré, un changement que l’entreprise met sur le dos du DMA.
« iOS a traditionnellement pris en charge les web apps de l'écran d'accueil en s'appuyant directement sur WebKit et son architecture de sécurité, commence par expliquer Apple. Cette intégration signifie que ces web apps sont gérées de manière à être conformes au modèle de sécurité et de confidentialité des applications natives sur iOS, y compris concernant la compartimentation du stockage et les demandes d’autorisation pour accéder aux fonctionnalités ayant un impact sur la vie privée, site par site. »
Sans ce type de mesures, des web apps malveillantes pourraient lire les données d’autres web apps ainsi que tirer parti de leurs autorisations, comme l’accès à la caméra, poursuit Apple. Et de pointer enfin ce qui bloque :
Répondre aux préoccupations complexes de sécurité et de confidentialité liées aux web apps utilisant des moteurs de navigateurs alternatifs [Apple est en effet contrainte d’autoriser d’autres moteurs que WebKit, ndlr] nécessiterait de construire une toute nouvelle architecture d’intégration qui n’existe pas actuellement sur iOS et qui n’était pas réalisable compte tenu des autres exigences du DMA et de l’adoption très faible des web apps sur l’écran d’accueil par les utilisateurs. Ainsi, pour répondre aux exigences du DMA, nous avons dû supprimer la fonctionnalité des web apps sur l’écran d’accueil dans l’Union européenne.
En résumé, prolonger les PWA tout en se conformant au DMA et en ne sapant pas la sécurité est trop compliqué et ne vaut de toute façon pas le coup compte tenu du faible nombre d’utilisateurs concernés, estime Apple.
« Les utilisateurs européens pourront continuer à accéder aux sites web directement depuis leur écran d’accueil via un signet avec un impact minimal sur leurs fonctionnalités », conclut l’entreprise. En réalité, l’impact n’est pas minimal du tout puisque les web apps vont perdre la possibilité d’envoyer des notifications ainsi que des possibilités de stockage avancées. Des services comme GeForce Now et Xbox Cloud Gaming qui reposent actuellement sur des PWA ne pourront plus fonctionner sur iOS en étant privés de ces fonctions.
Pour retrouver ces capacités, les développeurs n’auront d’autre choix que de créer des applications natives figurant dans l’App Store (dans le cas de GeForce Now, Apple vient tout juste d'ouvrir la porte aux services de cloud gaming) ou dans une boutique d’apps alternatives, un bouleversement complet en matière de développement et de distribution.
« Si ce changement finit par être présent sur les appareils des utilisateurs finaux, cela montrera qu’Apple cherche à empêcher activement le web de concurrencer équitablement l’App Store », avait déclaré Open Web Advocacy, une association qui milite pour une meilleure prise en charge des web apps par Apple, alors que des doutes existaient encore sur la nature de la modification. Cette dégradation des PWA va-t-elle passer auprès de la Commission européenne ?
« Cette dégradation des PWA va-t-elle passer auprès de la Commission européenne ? »
Certainement, quand on voit qu’elle laisse iMessage tranquille.
Rien à voir.
C'est le régulateur de l'UE lui même qui a fixé comme seuil les seuls usages dans le contexte professionnel pour décider si une messagerie instantanée doit être interopérable ou pas. Hors iMessage n'est pas si utilisé que cela pour cela en UE, semble-t-il.
Au régulateur de revoir ce concept de seuil et/ou de l'assoir sur les seuls usages en contexte professionnel.
Alors qu'en aucun cas le régulateur n'a définit comme objectif de la DMA de rendre les developpeurs tiers encore plus dépendant des conditions d'Apple, vu que justement tout le concept de DMA est de briser l'abus de position de tout contrôleur d'accès à des plateformes majeures tant économiquement que socialement, telles que les iphones.
Pas de doute, Apple butthurt much, ils jouent la mesquinerie complète et l’emmerdement maximum, de vrais fions.
J’ai raz le bol de cette boîte. J’arrête de leur filer mon pognon.
@fte
> "J’ai raz le bol de cette boîte. J’arrête de leur filer mon pognon."
J’en prends acte.
Néanmoins, connaissant le pouvoir addictif de cette came, j’aimerais être rassuré quant à l’absence de syndrome de sevrage et de douleurs fantômes.
@occam
"Néanmoins, connaissant le pouvoir addictif de cette came, j’aimerais être rassuré quant à l’absence de syndrome de sevrage et de douleurs fantômes."
J’ai laissé le Mac derrière moi depuis 2018 sans la moindre séquelle. J’apprécie Windows bien plus que j’apprécie macOS.
J’ai un Pixel 8 Pro pour le boulot et c’est un super engin. Je n’aurai aucun mal à l’adopter pour mon usage perso. Ce qui me retient sur iPhone n’a rien à voir avec l’écosystème, c’est le business model qui n’est pas basé sur l’exploitation de mes données pour me faire bouffer de la publicité. Mais le business model d’Apple est de pire en pire, insupportable, et au fond j’en suis à préférer bouffer de la publicité.
Remplacer l’Apple Watch ne sera pas difficile, les montres Samsung font ce que je veux : notifications silencieuses d’événements calendrier et réveil matin haptique. Rien ne m’attache à l’Apple Watch sinon l’iPhone. Je dois juste vérifier que je peux l’utiliser conjointement à un Pixel.
J’ai un iPad acheté pour mes besoins d’étudiant, mais j’ai achevé mon master il y a quelques mois et depuis je n’y touche plus. Je n’ai jamais aimé l’iPad. C’était une erreur d’en acheter un, je l’ai déjà expliqué ici, et j’aurais dû acheter une Surface ou un Yoga. Je ne referai pas cette erreur.
Bref. Mon 11 Pro Max ne sera pas remplacé par un 16 Pro Max comme je l’imaginais. J’en ai assez.
Une seule chose va me manquer très concrètement. Les AirTags.
@fte
Comme vous, j’exècre de plus en plus cette marque à cause des décisions de sa direction. Cela fait des années que cela infuse (cela correspond peu ou prou à l’arrivée de TC). Je ne prendrais toutefois pas votre décision pour 2 raisons :
1. Je suis prisonnier volontaire de cet écosystème avec que des produits Apple, tous interconnectés.
2. J’exècre encore beaucoup plus Google et Microsoft, ce qui fait que je n’ai pas d’alternative viable.
Plus le temps passe, plus j’ai envie de laisser tomber toutes ces technos (contrairement à beaucoup ici, je ne voue pas un culte à la déesse innovation), mais mon travail ainsi que la société m’y aliène. Peut-être qu’à la retraite ma dépendance sera devenue moins forte ? 🤷♂️ Mais bon, il y a encore de l’eau à passer sous les ponts…
@fte et @Derw
J'ai beaucoup de mal à vous comprendre : pourquoi tant de haine ? Comment un fabriquant de choses qui ne se mangent pas peut-il à ce point vous donner des aigreurs d'estomac ?
Il y a de bonnes machines sur d'autres OS, d'autres qualités, d'autres défauts également, le switch est simple, pourquoi en faire tout un plat ?
@yod75
> le switch est simple
Nettement moins quand vous devez quitter un ecosystème particulièrement plus fermé que d'habitude. Beaucoup d'investissements, financiers, temps, habitudes, doivent être abandonnés derrière vous.
@byte_order
Exactement ! Apple pour moi et ma famille (enfants, nous et nos parents) c’est 8 iPhones, 2 iPads, 6 Macs, le tout parfaitement intégrés (iMessages, AirDrop, FaceTime, iCloud, localisation…), parfaitement maîtrisés (« informaticien » sur Mac depuis 1990, je gère les appareils de tout le monde) et avec des outils qui me conviennent très bien que l’on ne trouve que sur Apple (Pages, Numbers, Affinity, Procreate…). Changer de crémerie me demanderait un investissement financier et intellectuel énorme !
De plus, comme je l’ai dit plus haut, je déteste encore plus Microsoft et Google, je n’ai donc pas vraiment d’alternative sur smartphone et uniquement Linux sur PC…
@yod75
"J'ai beaucoup de mal à vous comprendre : pourquoi tant de haine ?"
En effet, tu as du mal à comprendre. Aucune haine. Juste la constatation d’un foutage de gueule institutionnalisé.
"Comment un fabriquant de choses qui ne se mangent pas peut-il à ce point vous donner des aigreurs d'estomac ?"
À nouveau, tu as du mal à comprendre. Aucune aigreur d’estomac. Juste un désaccord avec la façon de faire de n’avoir rien à foutre du client qui n’est plus qu’un dommage collatéral insignifiant.
"Il y a de bonnes machines sur d'autres OS, d'autres qualités, d'autres défauts également, le switch est simple, pourquoi en faire tout un plat ?"
Le switch n’est pas simple. Il est d’autant moins simple qu’Apple a déployé un grand art pour verrouiller étroitement ces (avec un c) joujoux vendus rappelons-le, et que le choix n’existe parfois pas. Par exemple, je suis contrains de travailler avec du matériel de ce constructeur, ça fait partie de mon cahier des charges, environ à hauteur de 20% de mon emploi du temps.
Aussi, encore un mal à comprendre je suppose, car je n’en fais aucun plat. J’expose simplement que, alors que j’avais choisi de rester sur iOS parce que c’était jusqu’à maintenant le moins pire choix, iOS n’est plus le moins pire choix selon mes critères. Il est temps que je change d’horizon pour mes usages personnels.
Je suppose que cette impression d’intensité que tu ressens vient en réalité des fanboys qui s’offusquent fort vocalement qu’on puisse trouver que ce que fait Apple aujourd’hui est inacceptable. Ça doit être une insulte personnelle pour eux.
@fte
« Le switch n’est pas simple. »
Bof.
Je viens de switcher 8 mois sur du tout PC plus Android, j’ai pas eu de problème majeur… Juste augmenté un peu mon Googledrive.
Après, j’utilise toujours très peu les solutions propriétaire et les difficultés ne sont pas propres à Apple dans ce cas.
Bêtement, j’ai utilisé un peu le carnet de note Samsung de mon 23, j’ai les même galères qu’avec iNote…
Je retourne sur Apple sans difficulté non plus, et avec beaucoup de bonheur, Windows ne m’apportant pas d’amélioration en réseau sur le Citrix de mon boulot, et me demandant trop de resources en terme d’attention. Il m’épuise.
@yod75
> "le switch est simple"
@fte et @byte_order expliquent très bien pourquoi ce n’est pas le cas.
Mais vous faites en plus l’erreur de ne prendre en compte que l’usage individuel, ou tout au plus familial.
Dès qu’il s’agit de groupes de travail, d’institutions, d’entreprises, ça devient encore plus compliqué. Surtout quand il ne s’agit pas d’organisations verticales, où l’IT règne, où vous avez le choix entre Mac et PC, mais avec Office et du soft d’entreprise obligé, et rien d’autre, et où le choix de la plateforme de terminal n’est qu’apparent, car en réalité il importe peu, voire pas du tout.
Dans mon cas, j’ai abandonné Mac et iPhone privé et professionnel, ainsi que l’ont fait la plupart de mes collègues permanents. Mais nous maintenons des réseaux de collaboration très étroits, et nous formons des stagiaires, qui restent 24-30 mois. Les plus jeunes proviennent souvent de la bulle Apple. Il faut leur assurer un minimum de support. Ce qui veut dire re-trouver des solutions à des problèmes qui traînent sur Mac, et que nous avions quittés en sortant de la bulle.
Idem, concernant iOS et iPadOS.
Il faut assurer l’interopérabilité avec le clos muré.
Donc, on s’y frotte.
Quand je ne serai plus en fonction, je ne travaillerai plus que sous contrat spécifiant que je n’ai plus rien à foutre d’AAPL. En attendant, je suis obligé de me farcir encore les emmerdes des collègues qui dépendent de moi.
Voilà pourquoi il ne suffit pas de dire « je switch ».
@fte Enfin quelqu'un qui va au bout de son raisonnement. Clap clap clap 🤗
Au delà des aspects techniques que peu de monde ici ne doit vraiment maîtriser, je me pose la question de la régulation qui freine l'innovation et aussi leur arrivée sur le marché européen. RGPD, AI Act, DMA ... Il faut sans doute un cadre légal, mais cela fait pas mal de contraintes qui commence à rendre l'innovation bien juteuse pour les cabinets d'avocats ... Et le consommateur y trouve t il vraiment un intérêt ? Entre les milliards de clics des bannières de cookies (que personne ne prend la peine de configurer), l'arrivée plus tardives des IA ici et, maintenant la perte de fonctionnalité des OS ...
Catastrophe, nous utilisons une web app pour un des logiciels de notre entreprise. Passez par Safari sera bien moins pratique, on va perdre en fonctionnalité.
@_Lion04_
“Catastrophe, nous utilisons une web app pour un des logiciels“
Respire.
Il y a olein de solutions pour retomber sur vos pattes.
@Bigdidou
C’est impressionnant de voir comment vous osez répondre à un sujet dont vous n’avez aucun tenant et aboutissant…
@_Lion04_
Ce qui m’étonne, c’est cette propension au malheur, à l’invoquer et à le subir puis la posture agressive en retour ;)
Vois le côté positif une magnifique occasion de passer à autre chose que ces webapps qui restent avec leurs limitations et sont bien rarement satisfaisante.
disons qu'une personne au sein d'une entreprise sait mieux qu'un externe les enjeux internes et leurs propres contraintes.
je vous aurai répondu comme lui si j'avais exprimé un soucis dans mon entreprise et que vous m'auriez répondu un "pfiulala avec vous ,y fait toujours noir , mais faut sourire mon bon petit monsieur"
et ne soyez pas tel un politicien, "Vois le côté positif une magnifique occasion de passer", à croire que vos mots magiques suffisent... n'imitez pas les politiciens.
@Bigdidou
Le problème c’est que vous ne comprenez toujours pas que la plus part des logiciels ne sont accessibles qu’à a partir d’un site web. Donc la web app permettait de simplifier cela. Donc on ne passe pas aussi facilement à autre chose comme vous le dites.
Sinon, sur Android "ça marche". Si le besoin est d'avoir des webapps avec des fonctions complètes reste à passer chez les verts.
Vous verrez comme par magie Apple trouvera rapidement une fonctionnalité originale et sécurisée.
Scandaleux. Les arguments d’Apple sont foireux.
Toujours dommage de perdre une fonction... Mais si on peut toujours mettre un raccourci sur le springboard vers un site, c'est le principal.
@Boboss29
On peut surtout transformer des webapp en app, avec des outils dediés, puis utiliser le sideloading
? Utiliser le side loading ?
Pas cool
> iOS a traditionnellement pris en charge les web apps de l'écran d'accueil en s'appuyant
> directement sur WebKit et son architecture de sécurité, commence par expliquer Apple.
> Cette intégration signifie que ces web apps sont gérées de manière à être conformes
> au modèle de sécurité et de confidentialité des applications natives sur iOS, y compris
> concernant la compartimentation du stockage et les demandes d’autorisation
> pour accéder aux fonctionnalités ayant un impact sur la vie privée
Le modèle de sécurité, de confidentialité des apps natives sur iOS, compartimentation du stockage et des autorisations, est géré par iOS.
Prétendre qu'une web app, donc une app native mais qui utiliserait un autre moteur web que webkit pour afficher un seul site, serait une app qui echapperait au modèle de sécurité des apps de iOS, c'est carrément comme dire que c'est le webkit qui implémente ce modèle de sécurité, pas iOS lui même.
C'est du bon gros bullshit.
C'est juste une décision pour encore plus forcer les développeurs, à commencer par Microsoft, Nvidia, par devoir accepter les nouvelles conditions d'Apple.
Au régulateur de l'UE de faire son enquète avec les meilleurs éclairages possibles pour qu'il se fasse sa propre idée.
Personnellement j'espère un retour de baton aussi long que le finger d'Apple à l'UE.
@byte_order
"Personnellement j'espère un retour de baton aussi long que le finger d'Apple à l'UE."
Plus long. Beaucoup plus long. J’espère.
@byte_order
"C'est du bon gros bullshit."
Non. En fait les navigateur web moderne sont capable de compiler du code JavaScript en code natif. En réalité il y a une première transpilation puis compilation en AST et ce code est ensuite compilé en JIT selon le processeur du terminal. Ceci crée d’immenses fenêtres d’opportunité d’attaque qui ne peuvent être mitigées qu’avec un contrôle fin sur le code du compilateur JavaScript.
Apple a fait un travail remarquable sur JavaScriptCore, le moteur JavaScript de Safari et an mis des sécurités au niveau de l’app (sandboxing), et par conséquent des PWA créés par Safari. Ceci a évité le déferlement d’attaques même s’il y en a eu quelques unes (la sécurité absolue n’existe pas).
Ouvrir ces possibilités aux autres navigateurs sans aucun contrôle sur leur moteur JavaScript ni sur leur app, serait … suicidaire.
Un bon compromis serait de ne permettre de créer des PWA que depuis Safari. Mais les couillons de l’UE ont spécifié que les autres navigateurs devaient avoir les même accès aux API, les même possibilités que Safari. Donc Apple a été forcé de supprimer les PWA aussi pour Safari. Bravo les couillons de l’UE!
@Brice21
> Ceci crée d’immenses fenêtres d’opportunité d’attaque qui ne peuvent être
> mitigées qu’avec un contrôle fin sur le code du compilateur JavaScript.
Et c'est pourquoi Apple installe un processus de validation spécifique des moteurs web alternatifs. Je n'en connais pas les détails, mais il y aura peut-être justement une API spécifique à devoir utiliser pour tout ce qui concerne code exécutable généré par un moteur web alternatif.
Donc une PWA qui s'exécutera avec un moteur web alternatif bénéficiera de facto du fait qu'Apple aura validé la sécurité de ce moteur web, dont la mécanique de génération de code exécutable.
Certes, cette validation ne sera pas parfaite, tout comme elle ne l'a pas été même avec seulement le moteur webkit, comme vous le rappelez.
Apple a les moyens d'implémenter cela, c'est l'entreprise la plus riche au monde.
Mais, ironie, même en étant la plus riche au monde, 24h reste 24h, et comme elle a attendue visiblement le dernier moment possible, celui de l'obligation, plutôt que de commencer à construire les fondations pour permettre une ouverture qu'elle ne pouvait pas ignorer qu'elle lui serait un jour imposée de toute façon, ben voilà.
Mais, surtout, elle a choisi de volontairement dégradé l'expérience de sa propre clientèle, car l'objectif recherché est visiblement de faire une grosse crise de gamine, quitte à pratiquer la terre brûlée sur une partie de sa clientèle.
Perso, je m'en contrefout car je ne suis pas client, et cela renforce mon choix. Mais à titre professionnel, je suis confronté parfois aux conséquences des décisions d'obstruction arbitraire d'Apple. Je me trouve donc légitime, comme tout un chacun, de partager mon opinion sur son attitude.
Nous ne tomberons clairement pas d'accord.
J'observe, moi, que l'on ne parle quasiment que d'Apple au regard de la DMA.
Pour citer Orelsan : "si t'es souvent seul avec tes problèmes, c'est parce que, souvent, le problème c'est toi".
À tous les critiques, merci de nous expliquer comment Apple pourrait faire pour assurer une sécurité maximale avec des moteurs autre que Safari pour pallier aux risques décrits dans l'article.
Je rappelle que par définition Apple n'a pas la main sur les moteurs tiers.
J'attends avec impatience votre expertise.
Merci.
@marc_os
Les moteurs web tiers sont composés de code, qui s'exécute sous iOS.
C'est iOS qui implémente le modèle de sécurité qui empêche du code s'exécutant dans une app, que ce code soit celui d'un moteur web ou pas, d'accéder à des données stoquées par d'autres apps, d'utiliser des API sans autorisation préalable, etc.
Aucun code d'une app ne le peut, pourquoi une app qui embarquerait son propre moteur web plutôt qu'utiliser l'API WebKit le pourrait comme par miracle !?
Prétendre que c'est le webkit qui implémente ces mécanismes pour les webapps est du bullshit.
Que Apple n'ait pas le temps d'implémenter les API necessaires pour permettre l'utilisation de moteurs web alternatifs pour les webapps, cela aurait pu se comprendre, et elle aurait put argumenter de ce besoin pour justifier que pour le moment les webapps, et seulement les webapp, continueront a nécessiter d'utiliser le moteur webkit exclusivement et voir la réaction de l'UE.
Mai à la place, elle a choisi de retirer cette possibilité des webapps, car derrière elle sait que cela force Microsoft et Nvidia et quelques autres gros acteurs à devoir accepter ses nouvelles conditions commerciales, car même l'usage de XGames Pass ou NVidia Geforce Now via leurs webapps ne sera plus possible en UE. C'est volontaire !
> Je rappelle que par définition Apple n'a pas la main sur les moteurs tiers.
Apple à la main sur ce qui fait tourner tout code tiers sur iOS : iOS. Le sandboxing, c'est dans les mains d'Apple. Le contrôle des droits d'accès à certaines API (caméra, bluetooth, notification, etc), c'est dans les mains d'Apple !
Prétendre que c'est webkit qui fait ça, c'est comme dire qu'en fait iOS c'est webkit.
Ridicule.
@byte_order
C’est très loin d’être ridicule, WebKit implémente bien certaines limitations aussi notamment au niveau de la confidentialité. Le relais privé ne fonctionne qu’avec WebKit au dernière nouvelle, pareil pour le blocage des cookie tiers. Les arguments d’Apple se tiennent d’un côté. Je suis d’accord pour ce qui est Bluetooth,… que c’est iOS qui le fait avec son sandboxing.
Est-ce qu’Apple ne pourrait pas obliger les navigateurs tiers à respecter ces règles de confidentialité ? Certainement, mais cela demanderait un gros travail et un accord avec l’UE. Et ouvrir aux magasins tiers, veut dire que d’autres Web App pourraient très bien fonctionner.
Là, où je ne suis pas d’accord avec Apple, c’est le Core Technology Fee, qui est bien trop élevé. Je pense qu’un centime serait plus raisonnable.
"Est-ce qu’Apple ne pourrait pas obliger les navigateurs tiers à respecter ces règles de confidentialité ? Certainement, mais cela demanderait un gros travail et un accord avec l’UE. Et ouvrir aux magasins tiers, veut dire que d’autres Web App pourraient très bien fonctionner."
ben c'est la vie de l'industrie hein.... je bosse dans une boite où on intègre constamment notre produit à des produits d'autres industriels
on a des audits, des normes, des exigences, une base de bugs et d'exigences à faire fissa, des contrats, des échanges de technos, des ingés qui s'échangent
c'est la VIE BANALE de l'industrie !
@valcapri
> C’est très loin d’être ridicule, WebKit implémente bien certaines limitations aussi
> notamment au niveau de la confidentialité.
Une app qui utilise WebKit, webapp comprise. Elle est sandboxée, et le webkit ne pourra pas acceder à des données hors de ce bac à sable, quand bien même le code de webkit ne ferrait rien pour l'éviter.
En ce qui concerne la confidentialité, c'est à l'utilisateur de décider s'il fait confiance à tel moteur web ou pas. Et rien n'empêche Apple d'imposer d'utiliser une API (et c'est d'ailleurs dans les conditions imposées pour l'ouverture des moteurs web tiers) pour certaines fonctionalités, comme tout ce qui concerne la confidentialité. Mais à la place Apple préfère supprimer les webapps. Qu'elle n'a de toute façon jamais aimé, car cela échappe trop à son contrôle, justement.
> Le relais privé ne fonctionne qu’avec WebKit au dernière nouvelle
> , pareil pour le blocage des cookie tiers.
Y'a d'autres moteurs web qui disposent eux aussi des mécanismes comparables.
> Est-ce qu’Apple ne pourrait pas obliger les navigateurs tiers à respecter
> ces règles de confidentialité ? Certainement, mais cela demanderait un gros travail
Et ? Pour rappel, les règles DMA sont là *parce* que certains acteurs contrôleur d'accès à des plateformes ont *trop* abusés de leur position, et parmi eux Apple est la reine, sans aucun doute. Elle n'avait qu'a faire les efforts y'a longtemps, pour éviter de s'y retrouver contrainte de le faire. L'impunité du passé n'est pas une excuse quand le coût des conséquences tombe enfin. C'est même pire : avec les profits indus fait en abusant de cette position, y'a forcément eu de l'argent, donc le coût n'est pas une excuse.
> et un accord avec l’UE.
Et l'on voit qu'Apple est dans une démarche de trouver un accord avec l'UE pour obtenir un délais concernant la difficulté technique d'implémenter le support des webapps tout en supportant des moteurs web de tiers ?
Ouais, clairement !
@byte_order
Je suis d’accord avec toi, qu’Apple fait depuis trop longtemps la sourde oreille à plusieurs niveaux, et qu’elle en paie les pots cassés, me paraît logique. Certains contenus devraient pouvoir se trouver sur iOS sans problème et les navigateurs tiers en sont exemple criant, mais cette ouverture aurait dû être mondiale et non uniquement Européenne. Et pas seulement sur iOS met sur iPadOS et toute le reste. Pareil pour le Cloud Gaming, certains contenus pour adultes (je parle bien en respectant les règles tout en protégeant les enfants des Casinos et autres).
Maintenant, je ne suis pas fan des web app ayant un accès trop ouvert et qu’Apple pourrait faire comme Google, les trusted web app. Ou seul ceux qui ont été validés peuvent être mis sur la page d’accueil.
Mais Apple devrait pouvoir aider l’utilisateur à faire son choix, en étant le plus neutre possible et tout en respectant la confidentialité et la sécurité. En mettant le fait que certains respecte plus la vie privée que d’autres par exemple.
@valcapri
"Là, où je ne suis pas d’accord avec Apple, c’est le Core Technology Fee, qui est bien trop élevé. Je pense qu’un centime serait plus raisonnable."
Moi je trouve que ton salaire est bien trop élevé et devrait être divisé par 50.
@Brice21
"Moi je trouve que ton salaire est bien trop élevé et devrait être divisé par 50."
Son salaire rémunère son temps.
Le temps d’Apple est rémunéré par la vente des iPhone. On peut le voir dans les chiffres trimestriels, Apple est très bien rémunéré par la vente des iPhone.
La revente de ce qui a déjà été vendu sans y consacrer du temps supplémentaire n’est plus comparable à un salaire.
@Brice21
> Moi je trouve que ton salaire est bien trop élevé et devrait être divisé par 50.
Interessant parallèle. Vous vous placer dans un rôle de supérieur hierachique, d'employeur.
Depuis quand Apple est l'employeur des développeurs d'apps tiers !?
Ce n'est pas Apple qui rémunère les développeurs, ce sont les consommateurs des apps (et services payants auxquels elles donnent accès, le cas échéant) qui les rémunèrent.
Et ces apps tournent sur des plateformes achetées par ces consommateurs. Ces plateformes ne sont pas louées par Apple, ni au consommateur ni aux développeurs tiers, le consommateur accepte que l'app d'un développeur tiers puisse tourner sur sa plateforme en contrepartie d'un nouvel usage possible sur *sa* plateforme à lui seul, usage apporté par cette app.
De facto, la "Core Technology Fee", l'acheteur d'un iPhone l'a déjà payé, puisqu'il achète ce produit largement en partie pour sa capacité à exécuter ensuite des apps développés par des tiers permettant d'ajouter des usages et fonctionnalités non présente au départ.
On notera que iOS deviendra donc le tout premier OS généraliste (au sens taille du parc de plateformes compatibles) dont l'usage des API est soumis à une redevance. Un pas de plus vers la négation du concept d'achat d'une plateforme, mais tout en pratiquant des prix justifiés par la "vente" plutôt qu'une "location" et en n'assumant aucun frais de maintenance de ces plateformes.
Autrement dit le beurre et l'argent du beurre...
@byte_order
"C'est iOS qui implémente le modèle de sécurité qui empêche du code s'exécutant dans une app"
Absolument, tant que ces apps ne peuvent pas aller chercher sur Internet une page web et compiler arbitrairement du code natif, ce qui est l’exception unique faite pour Safari…
@Brice21
> Absolument, tant que ces apps ne peuvent pas aller chercher sur Internet une page web
> et compiler arbitrairement du code natif,
Euh, je ne vois pas en quoi cela menace un modèle de sécurité basé sur le bac à sable.
C'est comme de dire que le modèle de sécurité d'un OS tel que macOS classique, DOS etc reposait sur le fait que les différents programmes qui s'exécutaient n'allait pas foutre le basard là où il ne faut pas parce que les programmes ne venait pas de n'importe où. C'est ridicule.
Un bac à sable est censé resister à tout type de code qui tente d'en sortir sans présenter les demandes de droits d'utiliser tel ou tel API pour cela, c'est le principe même du concept !
Si pour que cela marche il faut avoir la garantie à l'avance que le code sera toujours un code pré-validé par quelqu'un à l'avance, vous n'avez pas un mécanisme de sécurité par bac à sable mais seulement une sécurité qui repose sur la seule qualité de validation au préalable de toute code exécutable.
Le mécanisme de génération de code d'un moteur web génère du code qui s'exécutera, lui aussi dans le bac à sable de l'app.
Donc soit ce bac à sable est une chimère, de l’esbroufe, et dans ce cas pourquoi prétendre que iOS est l'OS le plus sûr, soit ce n'est pas une chimère, et il sera tout autant capable d'intercepter un code présent à la validation de moteur qu'un code généré durant l'exécution du moteur.
Enfin, Apple met en place un processus spécifique de validation des moteurs web tiers, justifiable et, j'espère, justifié uniquement pour les raisons légitimes de sécurité. J'imagine que la partie JIT ou similaire fera l'objet d'une validation approfondie, ce qui bénéficiera à la qualité des moteurs web également in fine, car des éventuelles failles détectées pourront être corrigées, y compris pour les autres plateformes...
@byte_order
"Aucun code d'une app ne le peut, pourquoi une app qui embarquerait son propre moteur web plutôt qu'utiliser l'API WebKit le pourrait comme par miracle !?"
Parce que les moteurs web, par le biais de JavaScript sont les seules app autorisée à compiler du code natif en JIT, qui pourrait échapper à la sandbox de l’app, car le sandboxing n’est pas “dynamique’. Il est ‘enforced’ au lancement de l’app, pas à chaque page web.
@Brice21
Il ne serait pas possible de passer du WASM avec la sandbox?
@valcapri
J’ai fait simple dans mon explication car il semble que certains ne comprennent pas les bases d’un navigateur, et tout le monde connaît JavaScript.
Alors si on rajoute le WebAssembly, qui est encore une niche, ils vont peter des plombs. En effet avec du wasm tu peux aussi potentiellement attaquer iOS depuis une bête page web. C’est pour cela qu’Apple implement WebAssembly sur Safari iOS à pas de loups.
Une autre fenêtre d’attaque est WebGL sur les autres moteurs de rendu. Bref on va bien rigoler et je conseille de vider les comptes de ta grand mère avant qu’elle ne lance le spyware sur son iPhone. (Chrome) On peut toujours bloquer des URLs vérolées, mais pas du code JavaScript qui est dans le cache d’une PWA.
Bref ce qui est certain c’est qu’Apple limite les dégâts en évitant les PWA.
@Brice21
J’utilise que du natif donc Objective-C/Swift et Kotlin/Java. On a testé Cordova, Sencha ExtJS et Appcelerator Titanium mais il n’y a rien à faire, le mobile natif est le meilleure.
@Brice21
> car le sandboxing n’est pas “dynamique’. Il est ‘enforced’ au lancement de l’app,
> pas à chaque page web.
Et comment cela se passe alors pour Safari !?
Apple fait justement confiance à la qualité de JavaScriptCore pour ne jamais générer du code "mauvais" !?
Apple n'a qu'à imposer l'usage d'une API notifiant iOS qu'il faut regénerer le sandboxing sur le nouveau code exécutable de l'app, ou, mieux, mettre en place un mécanisme qui le détecte tout seul comme un grand.
Un OS moderne sait très bien quel segment de mémoire est marquée par l'autorisation d'exécuter son contenu, hein, et c'est d'ailleurs lui-même, OS, qui affecte cette autorisation via son gestionnaire de mémoire virtuelle.
Apple a bien été capable d'implémenter Rosetta 2, donc elle a parfaitement les moyens d'implémenter un mécanisme de sandboxing dynamique.
Si elle s'est abstenu de le faire jsuqu'ici en se pensant à l'abri à la fois par le processus de validation des apps et le fait que c'était forcément son WebKit pour tout ce qui concerne le web, c'est ballot, mais surtout cela signifie que son affirmation comme quoi iOS est l'OS le plus sûr était faux.
Pour rappel, on fait tourner chaque jour dans le monde sur des millions de machines des tas de programmes, tous capables de générer du code à la volée si cela leur chante, depuis des dizaines d'années sur des OS modernes, et c'est pas pour autant que des virus, des vols de données etc ont lieu à foison.
Donc, si la technique de bac à sable de iOS est trop statique, c'est un défaut de iOS, pas une conséquence de l'UE, hein.
Apple étant la plus riche, elle a, elle plus que toute autre, les moyens de corriger cela.
Faut-il qu'elle en ait la volonté, plutôt que de jouer à la terre brûlée dans l'espoir de s'aliéner l'UE (mais en fait, ses clients européens surtout, qui ne migreront pas hors de l'UE en masse pour autant, et ceux n'étant pas ses clients n'étant pas concernés ni impactés...).
"À tous les critiques, merci de nous expliquer comment Apple pourrait faire pour assurer une sécurité maximale avec des moteurs autre que Safari pour pallier aux risques décrits dans l'article."
en cloisonnant (bac à sable) dans leurs propres environnements le moteur et l'exécution du code de la page. comme fait webkit sur ios.
à charge aux moteurs alternatifs de s'intégrer sans heurts dans un cloisonnement, de se connecter aux fonctions fournies par le système pour animer l'app web (la page html+js+css+code précompilé) comme attendu.
Apple a la main sur tout l'environnement autour de l’exécution d'un logiciel (ce que vous nommez "moteurs" est un logiciel, pas bien différent d'un logiciel de prise de note par exemple)
@oomu
Bof quand on voit sur macOS 😉
@marc_os
> Je rappelle que par définition Apple n'a pas la main sur les moteurs tiers.
C'est faux.
Les nouvelles conditions d'Apple inclus un processus *spécifique* des moteurs web de tiers.
Apple va les valider, chacun. Et cela est justifiable en raison de la sécurité, en effet, en particulier parce que de nos jours un moteur web performant doit pouvoir générer du code exécutable à la volée, la partie dynamique de la technologie web.
Et on imagine aisément que, d'une part, le nombre de moteurs web ne se compte pas en millions ni même en milliers et, d'autre part, qu'Apple en fera une validation particulièrement approfondie, bien plus que pour la majorité des autres apps qu'elle valide régulièrement.
Elle introduit justement de nouvelles API dédiés aux moteurs web tiers, justement pour mieux avoir la main en matière de sécurité (mais peut être aussi d'autres choses).
Les apps avec leur propre moteur web ne seront donc pas traité comme n'importe quelle autre app.
Dire qu'Apple n'aura pas la main est donc incorrect.
Elle aura plus la main que sur l'immense majorité des apps, en fait.
Et, pour des raisons de sécurité - mais uniquement quand c'est pour cette raison - c'est parfaitement compréhensible, même par le régulateur de l'UE.
L’Europe paye là son besoin d’aller foutre la panique là où tout roulait parfaitement. Pour faire plaisir à quelques lobbyistes ils ont voulu mettre un coup de pied dans le cul de l’âne et ils se prennent un bon gros retour de sabots. Bien fait.
Pages