Devoxx 2016 était ma première conférence Devoxx, j’ai été comblé autant par l’organisation que par la qualité des présentations. Beaucoup tournent autour du web, mettent en avant des lacunes mais surtout apportent des solutions. Voici quelques éléments concernant la direction que prend le Web en 2016.
Le web se veut plus sécurisé
Quand j’écoute ma grand-mère parler du Web (ou plutôt d’Internet car elle ne fait pas la différence), j’entends souvent “fais attention mon petit, c’est dangereux tu sais”. Assez réducteur mais pas tout à fait faux… Tout le monde a déjà entendu parler d’attaques en tout genre, d’arnaques, de phishing… Pardon, hameçonnage, c’est comme ça qu’on dit dans notre contrée. Oui mais sur le Web, on trouve surtout du très bon et du très utile. Alors comment garder ses forces et éliminer ses faiblesses ?
La démocratisation de HTTPS
HTTPS existe tout de même depuis 1994, comme évolution du protocole HTTP, intégrant une couche de chiffrement TLS (anciennement SSL). Cette couche de chiffrement a connu plusieurs révisions pour en arriver à la version 1.2 de TLS en 2016. Un brouillon de la v1.3 est en développement depuis 2014. Le souci jusqu’à présent c’est que l’utilisation de HTTPS reposait plus ou moins sur la bonne volonté des développeurs de sites Web. Forcément, votre banque est à la page depuis un bon bout de temps (sinon, posez-vous des questions), mais le petit site web indépendant que vous consultez tous les jours a beaucoup moins de chances de l’être.
Oui mais à quoi ça sert ?
Imaginons un cas simple : Vous voulez vous connecter sur votre site web favori, pour cela vous entrez votre login et votre mot de passe et validez le formulaire. l’information part de votre navigateur sur le réseau sous forme de trame HTTP et arrive sur une première passerelle (souvent votre routeur) qui l’envoie à la passerelle suivante (les FAI et leurs infrastructures), jusqu’à destination : le serveur du site web. Avec le protocole HTTP, cette information est transmise en clair, ce qui signifie que chaque passerelle peut lire le contenu de la trame. Pire encore, une personne présente sur le réseau peut écouter ces trames, car en réalité elles sont transmises à toutes les machines d’un réseau mais par défaut ignorées si elle ne leur sont pas destinées. Il s’agit de la fameuse attaque Man In The Middle. Chez vous le risque est mesuré (bien que non nul), mais sur un réseau WiFi public c’est très différent.
HTTPS propose une solution contre ce problème : chiffrer les données qui passent sur le réseau. Une personne malveillante pourra alors tout autant intercepter la trame, mais cette dernière ne voudra rien dire pour eux. Seul le serveur pourra déchiffrer vos informations d’identification avec une clé qu’il a en sa possession.
Pour quelles raisons c’était si difficile de se mettre à HTTPS avant ?
Proposer HTTPS sur son site implique d’obtenir un certificat de la part d’une autorité de certification. Cela permet de valider que le site que vous êtes en train de consulter est bien celui que vous pensez. Jusqu’à présent, ce service était payant. La raison est qu’une autorité de certification doit être reconnue comme fiable par les navigateurs et cela demande du travail. Si vous signez votre propre certificat, vous obtiendrez une grosse page sur fond rouge vous avertissant que vous vous trouvez peut-être sur un site malveillant, avec une option pour reconnaître ce certificat comme valide (mais uniquement chez vous). Un certain nombre d’autorités de certifications sont reconnues et intégrées en dur dans les navigateurs. On ne fait pas confiance à n’importe qui pour protéger ces certificats ! De plus, générer et installer un certificat demandait un minimum de connaissances sur le sujet.
Mais fin 2015, une nouvelle autorité est venue bouleverser les standards. J’ai nommé Let’s Encrypt. Elle vient résoudre les deux plus gros freins à HTTPS : le prix et la difficulté de mise en place.
- Le prix d’abord car elle est gratuite. C’est une première ! Et elle est bien entendu disponible dans la dernière version de votre navigateur.
- La difficulté de mise en place ensuite, car elle est automatisée. Elle propose un outil nommé Certbot qui fait le boulot à votre place. Il génère d’abord un certificat et va même jusqu’à l’installer sur votre Apache ou votre Nginx.
Mais ça reste du boulot… Et si j’ai pas envie d’installer un certificat ?
Alors il vous faudra rester bloqué en 2015. Les navigateurs, Google Chrome en tête, ont tendance à réserver leurs nouvelles fonctionnalités aux utilisateurs de HTTPS. Les Service Workers sont un bon exemple. ils sont un excellent moyen de cacher des données dans le navigateur et, alliés à d’autres fonctionnalités comme les Push Notifications et l’installation d’un site sur l’écran d’accueil, s’apprêtent à concurrencer bon nombre d’applications natives.
Le web se veut plus accessible
Rien ne plus ennuyant que de vouloir accéder à un site web depuis son smartphone et d’attendre… d’attendre… En face d’une page blanche. Chez soi la connectivité est souvent bonne mais dans le train ou ailleurs, il arrive régulièrement que vous soyez connectés au “presqu’internet”.
Jake Archibald, ingénieur chez Google, s’est mis en tête de tuer l’Offlinosaurus de Chrome, comme il l’appelle. Il est à l’origine des Service Workers, fonctionnalité très intéressante des nouvelles versions de Google Chrome qui arrive chez les concurrents, agissant comme un proxy au sein du navigateur, permettant d’intercepter les requêtes envoyées et reçues. Il est ainsi possible de cacher des résultats de requêtes dans le navigateur afin de les afficher directement lors du prochain chargement de la page. Associé aux Push Notifications, à l’installation sur un écran d’accueil et à d’autres fonctionnalités, ils déterminent le concept de Progressive Web Apps.
Les Progressive Web Apps
Aujourd’hui lorsqu’on visite un site sur mobile, on réalise souvent les mêmes actions :
- Attendre que la page se charge
- Fermer la publicité
- Fermer le bandeau d’acceptation de l’utilisation des cookies
- Refuser (ou accepter, mais c’est rarement le cas) d’installer l’application native que propose le site.
C’est cette dernière action que les Progressive Web Apps se proposent de supprimer. Le but est de remplacer l’application native. Non seulement pour les développeurs, cela supprime deux applications (voire plus) à développer, mais en plus cela libère de la mémoire sur le téléphone de l’utilisateur. Une Progressive Web App veut donner à l’utilisateur l’expérience d’une application native, dans le navigateur. Et la bonne nouvelle c’est que vous pouvez commencer à en développer dès maintenant. Une Progressive Web App lancée dans un navigateur non compatible est juste un site web… Comme un escalator à l’arrêt est un escalier, mais permet toujours d’acheminer des gens.
Quels sont les points clés d’une Progressive Web App ?
Une Progressive Web App se veut:
- Progressive : Elle fonctionne partout. Elle se “dégrade” correctement sur les anciens navigateurs et les nouveaux profitent des dernières avancées (Service Workers, Push Notifications, …)
- Responsive : On en parle depuis plusieurs années mais bien entendu une Progressive App se doit de fonctionner sur toutes les tailles d’écrans
- Indépendante de la connectivité : Le Service Worker peut utiliser les données en cache pour les afficher avant de se mettre à jour. Comme une application native avec une base de données, mais en plus facile ! Cela évite le syndrome de la page blanche.
- App-like : On se croirait dans une application native !
- A jour : Le Service Worker fait son travail et met à jour son cache et la page.
- Sécurisée : Elle ne fonctionne qu’en HTTPS
- Découvrable : Elle est identifiable comme une application grâce aux manifests W3C. Cela permet notamment aux navigateurs de vous proposer de l’installer sur votre écran d’accueil
- Installable : Vous pouvez ajouter une icône vers l’application sur votre écran d’accueil
- Ré-engageante : La fonctionnalité de Push Notifications n’est plus réservée aux applications natives
- Référençable : Il est possible de faire un lien vers une Progressive App, puisque c’est un site web.
Pour visualiser un exemple de Progressive Web App, testez Pokedex.org.
Conclusion
Le web évolue et évolue vite, il comble à la fois ses lacunes et s’adapte aux nouveaux modes d’utilisation des gens. Comme pour les “logiciels” sur desktop, je crois fermement en la diminution drastique du nombre d’application natives sur les Stores car bon nombre de ces applications aujourd’hui n’offrent pas d’information en plus par rapport aux sites webs mobiles, mais donnent des possibilités que le web ne permettait pas jusqu’à présent, tel que le comportement Offline first.
Un grand merci pour l’inspiration à :
- Grégory Paul et sa présentation sur HTTPS
- Cyril Balit et Florian Orpelière et leur présentation sur les Progressive Apps
- Hubert Sablonnière, qui me parle de Service Workers et de Progressive Web Apps tellement souvent que j’ai du mal à dormir la nuit