Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

WebView : un canal bêta pour Lollipop, mais toujours rien pour Android 4.3

Les joies des mises à jour chez Google...

WebView : un canal bêta pour Lollipop, mais toujours rien pour Android 4.3

Le 17 février 2015 à 11h00

Début janvier, une faille de sécurité sur WebView était dévoilée dans Android 4.3 et ses versions antérieures, mais Google avait rapidement annoncé qu'il ne la corrigerait pas. Quelques semaines plus tard, une version bêta de WebView fait son apparition, mais cela ne change rien pour les vieilles versions d'Android, cette mouture étant réservée à Android 5.0.

VebView : la faille Android qui n'est pas (et ne sera pas) corrigée

WebView est un composant important d'Android qui permet aux applications d'afficher des pages web. Problème, une faille de sécurité jugée critique a été découverte début janvier. Elle touche les versions 4.3 et précédentes d'Android, mais pas Android 4.4, alias KitKat. En effet, depuis cette mouture, ce composant a été remplacé par un autre basé sur Chromium.

Google avait par contre précisé qu'il ne corrigerait pas cette faille et un des responsables de la sécurité d'Android, Adrian Ludwig, s'était fendu d'un billet Google+ pour en expliquer les raisons. Il indique notamment qu'il est question de près de 5 millions de lignes de codes avec des « commits » par milliers chaque mois. Il ajoute que, « dans certains cas, appliquer des correctifs de sécurité à une branche WebKit vieille de plus de deux ans nécessite des changements significatifs sur des portions de code, une pratique qui ne peut pas se faire en toute sécurité ». Les clients concernés apprécieront.

En guise de solution, le géant du web préconise simplement de passer sur une version plus récente d'Android (4.4 ou 5.0). Problème, les opérateurs et les fabricants ne sont pas toujours réceptifs à ce genre de message et de nombreux utilisateurs sont bloqués sur Android 4.3 ou moins faute de mise à jour disponible.

Un canal bêta, pour Android 5.0 uniquement

Quoi qu'il en soit, Google vient de faire une autre annonce autour de WebView : la mise en place d'un canal bêta pour tester de nouvelles fonctionnalités. En effet, « dans Android 5.0 Lollipop, Google a la capacité de mettre à jour WebView indépendamment de la plateforme Android  ». Cela ne changera par contre rien pour Android 4.3 puisque le canal bêta n'est disponible que sur Android 5.0 minimum.

Parmi les nouveautés, il est question de corrections de bugs, de nouvelles API et d'autres mises à jour provenant de Chromium. La première version proposée sera basée sur Chrome 40, également en bêta pour le moment. Tous les détails se trouvent par ici.

Commentaires (50)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Sympa Google <img data-src=" />

votre avatar



Google avait par contre précisé qu’il ne corrigerait pas cette faille et un des responsables de la sécurité d’Android, Adrian Ludwig, s’était fendu d’un billet Google+ pour en expliquer les raisons. Il indique notamment qu’il est question de près de 5 millions de lignes de codes avec des « commits » par milliers chaque mois. Il ajoute que, « dans certains cas, appliquer des correctifs de sécurité à une branche WebKit vieille de plus de deux ans nécessite des changements significatifs sur des portions de code, une pratique qui ne peut pas se faire en toute sécurité ». Les clients concernés apprécieront.



C’est complètement con … Et reporter sur les fabricants le fait de smises à jour, c’est se défausser de toutes responsabilités aussi. Joli (façon de dire) …

votre avatar

Ils vont le payer commercialement sur les flottes mobiles en entreprise mais ce n’est qu’une goutte d’eau comparé aux ventes dans le smartphone grand public. Le problème étant que Google a mis du temps à rappatrier tous les services dans le Google Play Services. Probablement par stratégie pou attiré les constructeurs via l’ouverture et maintenant que c’est le système dominant ils reprennent le contrôle.



Au moins dans le futur tout ce qui concerne la sécurité et pas mal de mises à jour cela sera bénéfique pour le client qui ne sera plus dépendant de la politique de mise à jour des constructeurs.

votre avatar

C’est vrai que le process des mises à jour est tellement limpide <img data-src=" />

votre avatar

C’est surtout leur business model … C’est ce qui leur a permis d’avoir ce niveau de pdm : laisser les constructeurs faire ce qu’ils veulent et ne les contraindre qu’à la validation du produit.



&nbsp;Il va vraiment falloir que Google fasse quelque chose pour ça (et d’ailleurs le “correctif” qu’ils ont sur 4.4+ est justement un “premier pas” dans cette direction =&gt; on met à jour la webview sans demander aux constructeurs).



Mais bon dieu il faut vraiment qu’ils fassent quelquechose pour permettre les mises à jour tout en laissant les constructeurs faire leur customisation …

votre avatar







chrismaurice a écrit :



Ils vont le payer commercialement sur les flottes mobiles en entreprise mais ce n’est qu’une goutte d’eau comparé aux ventes dans le smartphone grand public. Le problème étant que Google a mis du temps à rappatrier tous les services dans le Google Play Services. Probablement par stratégie pou attiré les constructeurs via l’ouverture et maintenant que c’est le système dominant ils reprennent le contrôle.



Au moins dans le futur tout ce qui concerne la sécurité et pas mal de mises à jour cela sera bénéfique pour le client qui ne sera plus dépendant de la politique de mise à jour des constructeurs.







Pas étonnant que la boite pour laquelle je bosse (multinationale américaine) , qui ne jure que pas des produits américains, n’autorise que iOS ou Windows Phone pour la flotte de téléphones.

Android est complètement interdit.


votre avatar

En même temps c’est au constructeur de migrer en 4.4+ …

votre avatar

C’est pas comme si la Webview était un composant de qualité <img data-src=" />



Ce truc est une catastrophe pour le développement mobile hybride.

votre avatar

C’est en bonne voie, mais ça sera impossible.

Google publie de plus en plus d’applis sur le Play store, et appuie de plus en plus d’APIs sur les Google services, que l’on peut mettre à jour sur le play store.

Mais le code d’Android est ouvert, les constructeurs font ce qu’ils veulent et il est impossible de leur laisser autant de latitude tout en ayant le contrôle sur les mises à jour. D’ailleurs, beaucoup de failles sont introduites par les constructeurs eux-même.

La seule chose à faire, c’est mettre la pression sur les constructeurs pour mettre à jour leurs anciens terminaux. Mais commercialement, c’est compliqué car ça coûte très cher.

Et certains constructeurs ne peuvent tout simplement pas se le permettre car ils dépendent des fabricants de SoC qui ne fournissent pas toujours les drivers/kernels à jour pour leurs plateformes.



Le problème est un poil plus compliqué qu’il n’y paraît, mais la seule chose que l’on peut faire, c’est pousser les gens à acheter des produits mis à jour par les constructeurs, ou pour lesquels l’AOSP est disponible, comme sur tous les modèles de Sony.

votre avatar

C’est le développement mobile hybride qui est une catastrophe. C’est une solution bas de gamme pour les entreprises qui ne veulent pas mettre trop d’argent dans leur appli. Il n’y a RIEN que l’on puisse faire dans une webview et que l’on ne peut pas faire en natif.

votre avatar







ErGo_404 a écrit :



Il n’y a RIEN que l’on puisse faire dans une webview et que l’on ne peut pas faire en natif.





Genre du code multi-plateformes ?


votre avatar







ErGo_404 a écrit :



C’est le développement mobile hybride qui est une catastrophe. C’est une solution bas de gamme pour les entreprises qui ne veulent pas mettre trop d’argent dans leur appli. Il n’y a RIEN que l’on puisse faire dans une webview et que l’on ne peut pas faire en natif.





oui mais ça permet plus aux commerciaux de se branler la nouille en parlant de responsive design <img data-src=" />


votre avatar







jb18v a écrit :



oui mais ça permet plus aux commerciaux de se branler la nouille en parlant de responsive design <img data-src=" />







dessein répondant <img data-src=" />



<img data-src=" />


votre avatar

Le développement hybride&nbsp;&nbsp;permet d’offrir des applis à très bas coût et rien que pour cela c’est remarquable.

J’ai beaucoup de clients qui veulent avoir une petite application avec un petit budget (surtout pour être présent dans les boutiques en ligne) et qui sont très heureux du résultat.

Facturer un triple développement natif quand ça n’est pas nécessaire … je ne vois pas l’intérêt.



Pour les clients qui veulent des applications robustes et qui arrivent avec un budget correct, on est d’accord qu’on oublie l’hybride.

&nbsp;

votre avatar

Personne ne remet en cause la supériorité technique d’un développement natif : c’est une évidence. 




 Le fait est que les TPE et associations n'ont pas toujours (rarement même) un budget assez important pour se lancer dans un développement natif pour plusieurs plateformes. Celui qui me dira le contraire n'est clairement pas un professionnel du secteur (ou exerce sa profession au pays des Bisounours peut-être ?)       







 Dans ce cas : soit on abandonne le projet, soit on se tourne vers une solution abordable (même si moins performante que les autres).
votre avatar

Je n’estime pas avoir dit n’importe quoi. Je parle de capacités techniques d’une appli. Effectivement, si on parle aussi de méthode de développement, la webapp permet de faire des bouts de codes universels.



Universels, mais mal intégrés, et peu performants.



Le post de base râlait contre la performance de la webview. Tout ce que je réponds, c’est que le vrai problème c’est d’utiliser la webview quand il existe d’autres alternatives plus efficaces.

votre avatar

Vu les réactions à mon commentaire j’ai l’impression que j’ai été un peu agressif, et je m’en excuse. Apparemment on est d’accord.



Je ne suis pas foncièrement contre l’utilisation de la webview, je rappelle juste qu’il existe d’autres alternatives pour ceux qui l’auraient oublié. Visiblement, ce n’est pas ton cas&nbsp;<img data-src=" />

votre avatar

C’est marrant que d’une news qui annonçait un amoncellement de commentaires trollesques au possible on en arrive à une discussion plutôt constructive et intéressante.

votre avatar

En même temps je comprends la position de Google, s’ils sortent de nouvelles versions de système gratuitement, à quoi bon boucher des versions vieilles de deux ans ? Les constructeurs n’ont qu’à se sortir les doigts du cul et mettre à jour l’OS, comme n’importe quel système ailleurs…



Vous croyez que sous Linus Torvald s’amuse à MAJ les vieux noyaux Linux pour combler des failles ? Non, c’est à ceux qui reprennent le noyau dans leur distrib de le faire si elle l’estiment nécessaire, lui se concentre uniquement sur les nouvelles versions… Bah là c’est pareil, les constructeurs veulent personnaliser Android à leur sauce avec toutes les bidouilles qu’ils veulent ? Bah ils assument les MAJ, comme n’importe quelle distribution, d’autant plus avec un hardware spécifique…

votre avatar







ErGo_404 a écrit :



Il n’y a RIEN que l’on puisse faire dans une webview et que l’on ne peut pas faire en natif.






 Au hasard comme ça je dirai: du vrai multiplateform ?(Windows, Linux, OSX, ChromeOs, Android, iOS, Wp, FirefoxOs...)

votre avatar

En même temps, Android est aussi américain <img data-src=" />



Ils refusent Android pourquoi ? Par manque de sécurité ? Qu’on ne me parle pas d’ouverture, car ça serait une bonne blague quand on voit qu’il y a iOS dans le tas…



Pour l’anecdote, en Suisse, certains bureaux d’expertise automobile commencent à se mettre aux tablettes et ce sont des Samsung Galaxy Tab. Donc Android n’est pas forcément incompatible avec le milieu pro <img data-src=" />

votre avatar

Ah, combler une faille de sécurité, ça ne se corrige pas en 90 jours ?



<img data-src=" />

votre avatar

Google a du demander a Google un délai de 14 jours <img data-src=" />

votre avatar

Les rares fois où j’utilise des WebView dans mes développements, c’est pour afficher du texte formaté (HTML), sinon ça ne me sert pas.



&nbsp;Quant aux applications qui ne sont qu’une WebView qui charge un site derrière, je trouve ça un tantinet débile <img data-src=" />

votre avatar

Un tantinet du foutage de gueule des utilisateurs ? :)



Les webView, c’est pas les trucs où les gestes sont mal implémentés, où ça ramme vite et bien ?

votre avatar







marquis a écrit :



Ah, combler une faille de sécurité, ça ne se corrige pas en 90 jours ?



<img data-src=" />





Non, c’est pas ce que dit Google avec son Project Zero. Ce qu’ils disent ‘est qu’après 90 jours les utilisateurs ont le droit d’être au courant.



Genre là “tout le monde” est au courant.



Par contre faut vraiment que Google améliore sa communication sur les différents bug trouvés et corrigés. Bien souvent le seul moyen de savoir qu’une faille a été trouvé et corrigé c’est de regarder les messages de commits…


votre avatar

Oui j’ai été trop tendre dans mes propos <img data-src=" />



Le pire, ce sont les développeurs malhonnêtes qui affichent une malheureuse WebView et mettent un bandeau publicitaire, histoire de rentabiliser les 30 secondes nécessaires à la réalisation du projet <img data-src=" />

&nbsp;

Et oui, les WebView ont des performances minables, même pour afficher une malheureuse ligne de code HTML locale…

votre avatar

De toute manière que Google corrige ou non sur les versions anciennes d’android ne changerai rien puisque la plus part des constructeurs/opérateurs qui sont en 4.3 et &lt; ne mettront pas à &nbsp;jour …

votre avatar

Pourquoi? Si tu veux développer une application multi-plateforme rapidement et pour un prix raisonnable sans avoir de contrainte de performance, c’est une solution idéale…



Si tu veux le faire en natif, tu dois:





  • Apprendre à coder en natif (Android, iOS, Windows, voire d’autres si tu vises d’autres supports)

  • Coder trois applications

  • T’amuser à essayer de trouver les équivalents en natif entre les OS (parce que oui, beaucoup de clients veulent des apps “identiques” quel que soit le support)

votre avatar

+1



Je fais du développement natif ou hybride, selon le budget et le besoin de mes clients.



L’hybride répond parfaitement à certains besoins (applications simples et micro-budgets).

votre avatar







Vekin a écrit :



En même temps, Android est aussi américain <img data-src=" />



Ils refusent Android pourquoi ? Par manque de sécurité ? Qu’on ne me parle pas d’ouverture, car ça serait une bonne blague quand on voit qu’il y a iOS dans le tas…



Pour l’anecdote, en Suisse, certains bureaux d’expertise automobile commencent à se mettre aux tablettes et ce sont des Samsung Galaxy Tab. Donc Android n’est pas forcément incompatible avec le milieu pro <img data-src=" />







Oui je sais que c’est Américain, et c’est justement pour ca que le fait que ca ne fasse pas parti des outils autorisés me fait réagir.

Je ne suis pas dans l’équipe qui détermine quels produits sont utilisables ou non dans cette boite, mais les échos que j’ai eut sont liés à la sécurité oui.


votre avatar

Ben autant mettre un raccourci sur le launcher qui ouvre le navigateur à la bonne page, non ?

votre avatar







marquis a écrit :



Ah, combler une faille de sécurité, ça ne se corrige pas en 90 jours ?



<img data-src=" />









detlef a écrit :



Google a du demander a Google un délai de 14 jours <img data-src=" />





C’est des troll ou c’est juste le plaisir de passer pour des cons en disant n’importe quoi, en montrant qu’on a rien compris à la news ?&nbsp;<img data-src=" />&nbsp;&nbsp;

&nbsp;

le correctif s’appelle Android 4.4, Google l’a sorti dans les temps et la faille est disponible aux yeux de tous …&nbsp;



C’est si compliqué que ça ?&nbsp;<img data-src=" />


votre avatar







DHKold a écrit :



Pourquoi? Si tu veux développer une application multi-plateforme rapidement et pour un prix raisonnable sans avoir de contrainte de performance, c’est une solution idéale…



Si tu veux le faire en natif, tu dois:





  • Apprendre à coder en natif (Android, iOS, Windows, voire d’autres si tu vises d’autres supports)

  • Coder trois applications

  • T’amuser à essayer de trouver les équivalents en natif entre les OS (parce que oui, beaucoup de clients veulent des apps “identiques” quel que soit le support)





    Ou utiliser Xamarin ou tout autres outils permettant de faire du code cible natif à partir d’un code source unique.


votre avatar

Outre le fait que ce soit super moche et mauvais pour le referencement+install (ce qui en fait deja une idée de merde), c’est techniquement réalisable de créer un raccouris dans le launcher vers du contenu web local sur android?

votre avatar

Pour moi il n’est clairement pas question d’une page locale dans ce cas là, mais d’un lien externe =&gt; pas utilisable offline.

votre avatar

Maintenant que tu en parles, je sais que les navigateurs peuvent créer de tels raccourcis sur des sites. Quant à le faire par programmation ET pour du contenu local, j’avoue que je n’en sais rien !



Bon si le contenu web est purement local, alors je comprends l’intérêt d’une telle application : contenu HTML écrit une fois pour tous les supports et affiché dans le WebView natif de la plateforme. Peu de code écrit, grande compatibilité sans trop de complexité.



Ce que je dénonçais, ce sont les WebViews qui affichent du contenu distant parfaitement accessible par le navigateur. Là, c’est un peu overkill comme solution.

votre avatar

Le but étant généralement d’avoir une partie hors ligne, c’est pas toujours une solution.



&nbsp;





the_mei a écrit :



Ou utiliser Xamarin ou tout autres outils permettant de faire du code cible natif à partir d’un code source unique.





Je ne connais pas Xamarin, mais d’après ce que je vois, c’est du C#, il nous faudrait donc former les devs là-dessus.



Et typiquement, l’application sur laquelle je bosse est fournie comme base à plusieurs clients qui changent le design et retouchent légèrement quelques fonctionnalités. Travailler avec des technos web permet cette personnalisation de manière simple et peu coûteuse.



En pratique, la seule question que le client se pose c’est de savoir à quel prix on va lui fournir l’app avec les specs qu’il a donné. Vouloir à tous prix produire du code natif n’a pas plus de sens que de vouloir tout faire en hybride…



&nbsp;edit:



&nbsp;





Vekin a écrit :



Ce que je dénonçais, ce sont les WebViews qui affichent du contenu&nbsp;distant&nbsp;parfaitement accessible par le navigateur. Là, c’est un peu overkill comme solution.





Là on est d’accord.


votre avatar







atomusk a écrit :



C’est des troll ou c’est juste le plaisir de passer pour des cons en disant n’importe quoi, en montrant qu’on a rien compris à la news ?&nbsp;<img data-src=" />&nbsp;&nbsp;

&nbsp;

le correctif s’appelle Android 4.4, Google l’a sorti dans les temps et la faille est disponible aux yeux de tous …&nbsp;



C’est si compliqué que ça ?&nbsp;<img data-src=" />





Les smileys ne s’affichent pas chez toi ?&nbsp; <img data-src=" />


votre avatar

“comme sur tous les modèles de Sony.” =&gt; Sauf achetés chez les opérateurs … :(

votre avatar

Il me semble que Xamarin peut aussi faire du Java, non ?

votre avatar







Vekin a écrit :



Ce que je dénonçais, ce sont les WebViews qui affichent du contenu distant parfaitement accessible par le navigateur. Là, c’est un peu overkill comme solution.





Ca c’est simplement pour le référencement… Imaginons que tu proposes un service en ligne qui a deja des equivalent qui s’executent localement (genre une bete application de facturation) pour concurencer lachement ceux qui se sont emmerdé à rendre leur app offline, tu ajoutes ton application au store, pour etre sur d’etre visible à un maximum d’endroit…

C’est assez méprisable comme démarche, mais les stores suivent plus une politique du chiffre que du nettoyage…


votre avatar

Ah parce que dire à tout le monde que tu es incapable de lire une news c’est drôle ?&nbsp;<img data-src=" />



Alors je veux bien que la définition du troll est large, mais là tu es juste hors sujet quoi … Justement toute cette polémique est là PARCE QUE Google est sujet aux mêmes règles qu’il impose à Apple/Ms …&nbsp;



La faille est au grand jour, Google a un correctif, les OEM veulent pas l’appliquer … c’est aussi simple que ça ..&nbsp;



Alors peut être qu’avec un chapeau c’est rigolo, mais il n’empêche pas que pour moi tu es passé pour un con …. et au final, ça doit être ça que tu trouve marrant&nbsp;<img data-src=" />

votre avatar







DHKold a écrit :



Et typiquement, l’application sur laquelle je bosse est fournie comme base à plusieurs clients qui changent le design et retouchent légèrement quelques fonctionnalités. Travailler avec des technos web permet cette personnalisation de manière simple et peu coûteuse.





Je connais pas vraiment xamarin, mais partant du principe que c’est équivalent à du C#+XAML de .NET, pour moi y’a pas photo:

Le degrée de personnalisation, la vitesse de conception, et la maintenabilité sont bien meilleure qu’avec des techno web….



Le probleme avec xamarin pour moi serait:




  • Pas totalement multiplateforme (ça build pas pour windows, linux, osx, chromeos, firefoxos)

  • Retard d’implementation des nouvelle features dispo pour chaques Os (sans aucune possibilité de faire un “pont” sois-meme avec le framework de l’os)

  • Solution payante (mais bon marché) et proprio (pas forcement pérenne)


votre avatar

La webView sert pour des applis multiplateformes, accessibles offline et dans le cas de Cordova/PhoneGap, donnant accès au matériel. Ce dernier point est essentiel pour comprendre l’utilisation de cette techno. Accéder à la géolocalisation, à l’appareil photo, au NFC depuis une appli javascript ça permet de faire des applications riches ET multiplateformes pour un montant dérisoire face à du tout-natif.

votre avatar

Dans ce cas, je vois mieux l’intérêt d’une telle solution <img data-src=" />

votre avatar







vloz a écrit :



Je connais pas vraiment xamarin, mais partant du principe que c’est équivalent à du C#+XAML de .NET, pour moi y’a pas photo:

Le degrée de personnalisation, la vitesse de conception, et la maintenabilité sont bien meilleure qu’avec des techno web….&nbsp;





Je dois dire que je ne connais pas les spécificités de XAML, mais ce dont je suis certain c’est que nos clients ont des devs capables d’écrire une feuille de style CSS, d’aller modifier un ou deux tags HTML voire même, dans certains cas, modifier du javascript. Par contre, des devs C#, XAML, .NET, ils en ont rarement.


votre avatar

Quand il s’agit d’IHM, le code multiplateforme c’est le nivellement par le bas. Je comprends que ça soit moins cher et plus rapide, mais il faut en accepter la conséquence inévitable : c’est moins efficace et ça s’intègre moins bien.

Du code interprété ne sera jamais aussi rapide que du code natif, même si les navigateurs récents sont de plus en plus efficaces pour compiler et exécuter le javascript.



Après il existe aussi des solutions pour faire de la traduction de code pour l’IHM, et donc du vrai multiplateforme sans passer par la webview, mais je n’ai jamais testé.

votre avatar

Je fais du développement Xamarin presque tous les jours.

C’est un excellent outil (mon préféré) mais le code est TRES loin d’être commun pour toutes les plateformes.



Avec les Xamarin Forms, on a une UI commune. On peut mutualiser la logique métier.

Mais tous le reste est spécifique à chaque plateforme.



Cordova/Phonegap, sauf besoin très spécifique (plugin non existant), c’est (pratiquement) un code unique pour cibler plus de plateformes que toutes les autres solutions.



Comme je l’ai dit 10000 fois : l’hybride répond à un besoin de développement rapide à très bas coût et c’est le seul moyen de parvenir à ce résultat.

votre avatar







ErGo_404 a écrit :



Quand il s’agit d’IHM, le code multiplateforme c’est le nivellement par le bas. Je comprends que ça soit moins cher et plus rapide, mais il faut en accepter la conséquence inévitable : c’est moins efficace et ça s’intègre moins bien.

Du code interprété ne sera jamais aussi rapide que du code natif, même si les navigateurs récents sont de plus en plus efficaces pour compiler et exécuter le javascript.



Après il existe aussi des solutions pour faire de la traduction de code pour l’IHM, et donc du vrai multiplateforme sans passer par la webview, mais je n’ai jamais testé.





On a pas dit le contraire mec, &nbsp;c’est juste toi qui a commencé à dire n’importe quoi:

“il&nbsp;n’y a RIEN que l’on puisse faire dans une webview et que l’on ne peut pas faire en natif.”


WebView : un canal bêta pour Lollipop, mais toujours rien pour Android 4.3

  • VebView : la faille Android qui n'est pas (et ne sera pas) corrigée

  • Un canal bêta, pour Android 5.0 uniquement

Fermer