Chrome 56 bêta : alertes sur les pages HTTP et nouveautés pour les développeurs

Chrome 56 bêta : alertes sur les pages HTTP et nouveautés pour les développeurs

En même temps, un mot de passe en HTTP...

Avatar de l'auteur
Sébastien Gavois

Publié dans

Logiciel

09/12/2016 2 minutes
7

Chrome 56 bêta : alertes sur les pages HTTP et nouveautés pour les développeurs

Chrome 56 est disponible en version bêta et marque le début d'une vaste campagne visant à marquer les pages HTTP comme non sécurisées. Plusieurs nouveautés sont également disponibles pour les développeurs.

Alors que Chrome 55 est disponible depuis une semaine sur le canal stable, le travail continue évidemment et la mouture 56 est disponible en version bêta. La première nouveauté, et pas des moindres, concerne les pages qui sont en HTTP. Historiquement, elles n'ont jamais été présentées comme non sécurisés, mais la situation est progressivement en train de changer.

Un  « Not Secure » arrive pour les pages HTTP

Pour commencer, les sites réclamant des mots de passe ou des numéros de carte bancaire seront clairement affublés d'un « Not Secure » dans la barre d'adresse. Cette fonctionnalité sera progressivement déployée au cours des prochaines semaines précise Google.

Et il ne s'agit que d'une première étape puisque cette démarche s'inscrit dans « le cadre d'un plan à long terme visant à marquer tous les sites HTTP comme non sécurisés ». Aucun détail sur le calendrier n'a par contre été précisé.

Nouvelles API, positionnement CSS Sticky

Juste après l'annonce officielle du Bluetooth 5 (voir cette actualité), Google annonce que les sites peuvent interagir avec le Bluetooth Low Energy sur Android, macOS et Chrome OS. Ils passeront par l'API Web Bluetooth, qui utilise le protocole GATT, permettant aux développeurs d'établir une connexion en quelques lignes de JavaScript, selon Google.

Chrome 56 bêta permet également de positionner un élément CSS en « adhérence » grâce à la balise Sticky. Pour résumer, l'élément est d'abord mis en place sur la page de manière relative, avant d'être fixé lorsqu'un certain niveau de défilement est atteint. 

Parmi les autres nouveautés, l'API WebGL 2.0 est désormais utilisée par défaut sur les ordinateurs, tandis que l'API WebVR est disponible sur Android à des fins de test. Les notes de version détaillées se trouvent par ici. Pour télécharger Chrome 56 bêta il suffit de suivre le lien ci-dessous, mais attention  : il remplacera votre installation stable de Chrome si vous en avez une.

7

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Un  « Not Secure » arrive pour les pages HTTP

Nouvelles API, positionnement CSS Sticky

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (7)


C’est cool pour sticky, mais toujours pas utilisable.


Je connaissais pas sticky. Enfin. Plus besoin de JS pour faire ça. A tester.


Ben… Comme pour toutes les features depuis toujours ?!?

  

Avant d’être implémenté c’est … pas implémenté. Là il s’agit d’une implémentation dans un des browser.


Enfin pour les HTTP… J’imagine qu’il fallait en passer par Let’s Encrypt et une dynamique suffisante, d’où l’attente



Par contre JS et bluetooth? With great power comes great responsibility


L’annonce de l’avertissement qu’un site est “non-sécurisé” a été faite en janvier 2016 pour une release publique en janvier 2017. Pourtant Chrome Canary n’a jamais affiché cet avertissement et aujourd’hui Chrome Beta non plus. Le seul endroit où on peut avoir un aperçu de cet avertissement est ici :&nbsphttps://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

 Difficile de voir si c’est un message vraiment inquiétant pour l’utilisateur ou non.








Tristan77 a écrit :



Ben… Comme pour toutes les features depuis toujours ?!?

  

Avant d’être implémenté c’est … pas implémenté. Là il s’agit d’une implémentation dans un des browser.





Non mais si Ms Edge le supportait ça serait à moyen terme, mais même pas.



Comme avec MD5 et SHA-1 Mozilla et Google semble se coordonner (ou s’influencer/copier ?) sur les problèmes de sécuritéhttps://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/

C’est vrai qu’avec Let’s encrypt, des contraintes sur TLS ont disparu.