Le 23 décembre, le blog de Cyanogen Inc. publiait une courte note titrant « Les services Cyanogen s'arrêtent ». Le célèbre OS open source pour smartphone Android, CyanogenMod, est étroitement lié à la société du même nom. Sans le support de Cyanogen Inc., plusieurs questions se posent donc aujourd'hui concernant l'avenir de la plateforme. Essayons de faire le tour de la question.

CyanogenMod et Cyanogen Inc.

Je vous propose un rapide historique de l'histoire de Cyanogen. Dès les premières versions d'Android, un groupe de développeurs trouve une faille de sécuríté permettant l'escalade de permissions, et donc de gagner un accès root sur un appareil Android. C'est à partir de là qu'est né un système d'exploitation alternatif basé sur la partie open source d'Android développée par Google (AOSP). Ce système c'est CyanogenMod.

L'accès root combiné à la maîtrise des sources de l'OS ont permis de pousser les options de personnalisation d'Android (initialement assez austères), d'assurer les mises à jour de téléphones abandonnés par les constructeurs, de virer les lourdes surcouches constructeurs souvent accompagnées de publicités, etc. Bref, grâce à ces possibilités, le gain de popularité de CyanogenMod a été fulgurant.

Un succès qui a entraîné la création en 2013 de Cyanogen Inc., une société destinée à commercialiser CyanogenMod, ayant très rapidement levé 7 millions de dollars. L'entreprise obtiens rapidement des résultats par l'intermédiaire de partenariats avec des constructeurs, comme pour le célèbre OnePlus ; mais également avec éditeurs logiciels, comme avec Microsoft en incluant ses services (Bing, Skype, Outlook, etc.) par défaut dans son système d'exploitation.

Cyanogen Inc. shutdown

Face à ce succès, on peut se demander ce qui pousse la société à cesser ses activités aujourd'hui. Il s'agit en fait d'une très mauvaise décision, pour ne pas dire malhonnête, prise par son PDG Kirt McMaster.

En 2014, Cyanogen Inc. se lie d'un partenariat avec le constructeur OnePlus pour équiper ses téléphones de CyanogenMod. Au vu du succès du OnePlus, on pourrait croire à un beau succès.

Sauf que quelques mois plus tard, Cyanogen Inc. s'associe à une autre entreprise, au travers d'un partenariat exclusif, le constructeur indien MicroMax. La société indienne attaque alors en justice OnePlus pour l'utilisation de l'OS sur lequel il a l'exclusivité sur le marché indien, et obtient l'interdiction de la commercialisation du OnePlus en Inde pendant plusieurs mois.

Autant dire que le capital confiance accumulé par l'entreprise et son PDG avait autant de valeur que le cadeau de noël offert au cousin par alliance que l'on croise pour la 3ème fois de sa vie.

Quoiqu'il en soit, en ce mois de décembre 2016, Cyanogen Inc. annonce sa décision de cesser ses activités.

La suite

Toutefois, n'oublions pas que le code source de CyanogenMod est libre et qu'une majorité de ses contributeurs ne sont pas liés à Cyanogen Inc. L'équipe de développement a donc publié une note expliquant la route qu'allait prendre le système d'exploitation. Cette note aujourd'hui indisponible peut être retrouvée ici^(en).

CyanogenMod est mort, vive le Roy LineageOS.

En effet, suite à la débâcle de Cyanogen Inc., de l'avenir incertain de l'entreprise, l'équipe a préférer se dédouaner complètement de celle-ci en passant par un rebranding - c'est-à-dire un fork. Fini donc Cyanogen.

Rien ne devrait être perdu en passant à LineageOS puisque CyanogenMod n'incluait pas de contenu au sources propriétaires (sauf peut être au travers de ses partenariats avec les constructeurs). Il faut tout de même s'attendre à un petite période de flottement puisque, rappelons-le, toute l'infrastructure serveur de CyanogenMod est aujourd'hui indisponible.

Quoiqu'il en soit, n'installez plus de nouvelle version de CyanogenMod et faites attention à l'endroit où vous récupérez vos binaires, ces périodes sont toujours propices au petits malins mal intentionnés.

LineageOS sera disponible par ici.

Le 10 février, Mozilla a annoncé sur son blog qu'ils allaient prochainement introduire une nouvelle feature au sein de son navigateur Firefox : la signature des extensions. L'idée en soi est plutôt bonne ; jusqu'à la lecture du paragraphe qui nous explique que la signature des extensions sera obligatoire après la période de transition. Il ne sera alors plus possible d'installer des extensions qui n'auront pas été signées sur la plateforme de développement de Mozilla. Qui a dit Apple App Store ? Voyons pourquoi c'est la plus mauvaise idée venant de Mozilla que j'ai entendu depuis longtemps.

La première raison est parfaitement évidente. Firefox est un navigateur qui s'est construit grâce à son ouverture et à sa liberté utilisateur. Le verrouiller ne peut pas être considéré comme une bonne chose, surtout lorsque l'objet du verrou est également ce qui fait la force de ce navigateur : les extensions.

En ne prenant en compte que des considérations pratiques, s'il y a une seule raison qui m'empêche d'aller voir chez la concurrence, ce sont les extensions de Firefox. Et plus particulièrement celle-ci. Parlant de cette extension, j'ai déjà du la mettre plusieurs fois à jour récemment à partir du site du site du développeur parce qu'elle n'était pas à jour sur le "Mozilla Store". Je ne sais pas à quoi était dû la latence, mais toujours est-il qu'avec ce système de signature j'aurais pu me garder ma version buguée quelque temps.

Cela dit, ne tombons pas dans le procès d'intention, et étudions d'un peu plus près ce qu'on nous dit concrètement à propos de cette... feature.

1. C'est devenu indispensable pour la sécurité du navigateur et des utilisateurs.

D'une part, si je comprends que cette sécurité puisse être utile pour ma tante incapable de résister à l'envie d'installer toutes les toolbars et autres crapwares qui croisent sa route, je pense être un utilisateur un peu plus avisé. Le fait de ne même pas me laisser une option pour installer des addons non-signés est déconcertant.

D'autre part, durant le mois de janvier passé, de nombreuses voix se sont élevées pour rappeler au pouvoir en place que la surenchère de sécurité au détriment des libertés individuelles est inadmissible et contre-productive. Je pense notamment à la Quadrature. Je trouve que l'analogie est particulièrement juste ici, dans une moindre mesure évidemment.

2. Vous pouvez toujours installer des extensions non-signées... sur les versions beta et alpha.

Je sais qu'il y en a parmi vous qui sont des adeptes du bleeding edge, mais de mon côté je préfère avoir du stable quand on parle de quelque chose aussi central que le navigateur. Ça n'est pas ce que j'appelle une solution.

Mais surtout, dans quel monde est-il envisageable de développer une extension lorsque l'on ne peut pas la tester le même environnement que celui utilisé par les utilisateurs ? La question a été posée dans les commentaires, et je trouve la réponse délicieuse.

"There will be unbranded builds of Beta and Release where developers will be able to test their add-ons. The only differences between those builds will be the signature checking and the branding (name and logo)."

Clairement, ils vont proposer eux même un fork de Firefox qui fait sauter la sécurité et la marque Firefox. C'est beau.

3. Il y aura une période de transition de deux releases (12 semaines en tout) durant laquelle les extensions non-signées ne génèreront qu'un avertissement dans Firefox.

Sous entendu, lorsque le système de signature sera mis en place, TOUTES les extensions de l'écosystème Firefox devront être mises à jour (et signée) dans un délai de 12 semaines. Au delà : extension non autorisée. Et bien sûr les anciennes version : poubelle.

Conclusion

Il n'y a pas grand chose de plus à en tirer sinon qu'on nous sort la carte de la sécurité utilisateur à toutes les sauces. Je ne sais pas trop quelle mouche les a piqué mais ce verrouillage non optionnel est ridicule. Même Android (Google) permet d'installer des applications en dehors de son Play Store.

J'espère sincèrement un rétro-pédalage de leur part, ou au pire, s'arrêter à l'idée de la période de transition : une extension non signée génère un warning, un peu comme un certificat SSL non signé.

Sinon, un n-ième fork verra probablement le jour, et il se pourrait bien que ça soit le bon pour moi ; faute d'une meilleure alternative en tout cas.

PS : La phase de transition est prévue pour le deuxième trimestre 2015.

A l'heure avancée du web 2.0, ou le minitel 2.0 (centralisé) comme l'appellent certains, les services web pullulent sur internet. Un service est tout simplement un logiciel accessible en ligne fourni par un site web, qu'il soit une entreprise ou une âme généreuse. En tant qu'utilisateur final, il est facile de s'appuyer sur ces outils en raison de leur simplicité. Je pense que c'est une erreur, et voilà pourquoi.

La solution facile

Pourquoi y a-t-il autant de service en ligne aujourd'hui, et pourquoi sont-ils autant populaire ? La réponse est très simple. Ils ne sont que la réponse au besoin d'immédiateté qu'a créée l'information moderne.

Un service est une boîte noire. Sans le moindre effort, vous n'avez qu'à copier/coller un code, suivre un lien, donner une information personnelle, et la boîte noire se charge pour vous de ce que vous auriez mis des heures à réaliser. On peut prendre l'exemple très connu et répandu : Google Analytics, le service de statistiques.

Je pense que cet exemple est excellent, parce Piwik existe. Piwik c'est un logiciel open source qui fait globalement exactement la même chose que Google Analytics, qu'il est open source et qu'il faut héberger. Quel est la part de sites qui utilisent le service Google ? D'après W3techs, plus 55% des sites internet utilisent Google Analytics !

En clair, plus de 55% des sites web préfèrent utiliser un service externe, une boîte noire gérée par une entreprise, plutôt qu'ils gèrent eux même. Je rappelle que la qualité du rendu est vraiment très similaire. La solution facile du service est donc celle privilégiée par les acteurs du web...

Fermeture inévitable

Tout cela est assez basique et connu de la plupart d'entre nous. En revanche, saviez-vous que le service que utilisez ou avez prévu d'utiliser allait fermer ? Non, je n'exagère pas. Un service est par essence éphémère et destiné à fermer tôt ou tard. Cela peut être dans un an comme dans 5, 10, ou même 30 ans. Internet est un monde qui change extrêmement vite. Finalement, il s'est démocratisé il y a moins de 15 ans.

Puisque les explications théoriques ne sont pas ma spécialité, prenons des exemples concrets. Commençons par un service web, géré par une entreprise, comme il en existe des milliers. Prenons par exemple l'excellent éditeur d'images en ligne Pixlr (j'en avais parlé ici). Cet outil est donc fourni par Autodesk, une entreprise de génie mécanique. Hors vous connaissez la loi des marchés, il arrivera forcément un jour où l'outil coûtera trop cher par rapport à ce qu'il rapporte, où l'entreprise fermera, où la technologie sera dépassée et nuira à l'image de l'entreprise, etc.

J'ai pris un exemple marginal, et peu critique (j'utilise moi-même Pixlr lorsque je suis sûr un PC où je ne peux rien installer). Mais c'est vrai pour TOUS les services web. Je n'ai pas besoin de citer le géant Google. En clair, s'appuyer sur un service dans la conception d'un outil, est un risque énorme ; et souvent inutile. Un exemple qui me vient à l'esprit sont ces startups qui ne proposent qu'un enregistrement Facebook/Google. Elles se rendent dépendantes d'une API qui de toute façon évoluera ou fermera un jour.

J'ai parlé d'entreprise, mais je propose aussi un service : rssbridge.org. Là, il n'y a aucun enjeu financier. Par contre, si je me fais écraser par un bus demain ou que je décide d'aller vivre en ermite au Népal, le problème est le même.

Soyez intelligent

Dans cet article, je n'essaye pas de montrer que les services web sont le mal absolu. Ils peuvent même être très utiles dans certains cas. Il faut juste qu'avant de l'utiliser, vous vous posiez cette question : quand (et non pas "si") le service fermera, que se passera-t-il ?

Si la réponse est que ça n'a pas d'importance, aucun problème. Sinon cherchez une solution alternative. Il y en a toujours.

En bref, utilisez les services web intelligemment, et n'appuyez pas tous vos espoirs dessus. Sans quoi, vous allez au devant d'ennuis ultérieurs inutiles.

EDIT : Je n'en parle pas parce que ça n'est pas le sujet du billet, mais la protection de vos données et de celles de vos utilisateurs est également à prendre en compte.

A l'heure avancée du web 2.0, ou le minitel 2.0 (centralisé) comme l'appellent certains, les services web pullulent sur internet. Un service est tout simplement un logiciel accessible en ligne fourni par un site web, qu'il soit une entreprise ou une âme généreuse. En tant qu'utilisateur final, il est facile de s'appuyer sur ces outils en raison de leur simplicité. Je pense que c'est une erreur, et voilà pourquoi.

La solution facile

Pourquoi y a-t-il autant de service en ligne aujourd'hui, et pourquoi sont-ils autant populaire ? La réponse est très simple. Ils ne sont que la réponse au besoin d'immédiateté qu'a créée l'information moderne.

Un service est une boîte noire. Sans le moindre effort, vous n'avez qu'à copier/coller un code, suivre un lien, donner une information personnelle, et la boîte noire se charge pour vous de ce que vous auriez mis des heures à réaliser. On peut prendre l'exemple très connu et répandu : Google Analytics, le service de statistiques.

Je pense que cet exemple est excellent, parce Piwik existe. Piwik c'est un logiciel open source qui fait globalement exactement la même chose que Google Analytics, qu'il est open source et qu'il faut héberger. Quel est la part de sites qui utilisent le service Google ? D'après W3techs, plus 55% des sites internet utilisent Google Analytics !

En clair, plus de 55% des sites web préfèrent utiliser un service externe, une boîte noire gérée par une entreprise, plutôt qu'ils gèrent eux même. Je rappelle que la qualité du rendu est vraiment très similaire. La solution facile du service est donc celle privilégiée par les acteurs du web...

Fermeture inévitable

Tout cela est assez basique et connu de la plupart d'entre nous. En revanche, saviez-vous que le service que utilisez ou avez prévu d'utiliser allait fermer ? Non, je n'exagère pas. Un service est par essence éphémère et destiné à fermer tôt ou tard. Cela peut être dans un an comme dans 5, 10, ou même 30 ans. Internet est un monde qui change extrêmement vite. Finalement, il s'est démocratisé il y a moins de 15 ans.

Puisque les explications théoriques ne sont pas ma spécialité, prenons des exemples concrets. Commençons par un service web, géré par une entreprise, comme il en existe des milliers. Prenons par exemple l'excellent éditeur d'images en ligne Pixlr (j'en avais parlé ici). Cet outil est donc fourni par Autodesk, une entreprise de génie mécanique. Hors vous connaissez la loi des marchés, il arrivera forcément un jour où l'outil coûtera trop cher par rapport à ce qu'il rapporte, où l'entreprise fermera, où la technologie sera dépassée et nuira à l'image de l'entreprise, etc.

J'ai pris un exemple marginal, et peu critique (j'utilise moi-même Pixlr lorsque je suis sûr un PC où je ne peux rien installer). Mais c'est vrai pour TOUS les services web. Je n'ai pas besoin de citer le géant Google. En clair, s'appuyer sur un service dans la conception d'un outil, est un risque énorme ; et souvent inutile. Un exemple qui me vient à l'esprit sont ces startups qui ne proposent qu'un enregistrement Facebook/Google. Elles se rendent dépendantes d'une API qui de toute façon évoluera ou fermera un jour.

J'ai parlé d'entreprise, mais je propose aussi un service : rssbridge.org. Là, il n'y a aucun enjeu financier. Par contre, si je me fais écraser par un bus demain ou que je décide d'aller vivre en ermite au Népal, le problème est le même.

Soyez intelligent

Dans cet article, je n'essaye pas de montrer que les services web sont le mal absolu. Ils peuvent même être très utiles dans certains cas. Il faut juste qu'avant de l'utiliser, vous vous posiez cette question : quand (et non pas "si") le service fermera, que se passera-t-il ?

Si la réponse est que ça n'a pas d'importance, aucun problème. Sinon cherchez une solution alternative. Il y en a toujours.

En bref, utilisez les services web intelligemment, et n'appuyez pas tous vos espoirs dessus. Sans quoi, vous allez au devant d'ennuis ultérieurs inutiles.

EDIT : Je n'en parle pas parce que ça n'est pas le sujet du billet, mais la protection de vos données et de celles de vos utilisateurs est également à prendre en compte.

J'adore le Markdown. C'est un langage de formatage simple, lisible et parfaitement adapté au web. J'en mange 5 fois par jour, matin midi et soir sur ce blog, sur Github, sur GitLab, sur mon Wiki (en fait ça n'est pas du Markdown mais un type de markup language), sur Stack Overflow, etc. Le hic, c'est que le Markdown original n'a codifié qu'un nombre limité d'éléments HTML standards. Du coup, la plupart des services qui l'utilisent y ajoutent une surcouche ; le fameux Flavored Markdown.

Mais vous vous en doutez, sinon ça serait trop simple, cette surcouche ne reprend généralement pas les mêmes conventions en fonction des services. Faisons un petit tour d'horizon.

Markdown standard

Je fais un rappel rapide de ce qu'est Markdown, pour ceux qui ne connaitraient pas. Cet outil permet donc de formater du texte très simplement. C'est un peu le même principe que le BBCode à la grande époque des forums, sauf qu'on ne s'arrache plus les cheveux.

Un petit exemple :

# Titre principal

## Sous titre   

Ceci est une super liste :

 * Elément 1
 * Elément 2    

[Lien](http://hoa.ro "Titre : Tu m'emmerdes avec ton exemple")

Enfin bref, vous pouvez retrouver toute la syntaxe sur la page de documentation et encore plus dans l'image-mémo ci-dessous.

Flavored Markdown

L'image précédente n'est pas là tout à fait par hasard. Vous pouvez voir en bas de celle-ci quelques éléments clés du Github Flavored Markdown (que je vais appeler le GitFlav dans la suite, parce que c'est plus court).

Ainsi, comme vous pouvez le constater, sur Github vous pouvez écrire votre code après un triple backquote et le nom du langage. Par contre, vous ne pourrez faire ça QUE sur Github (ou un service qui implémente arbitrairement la même règle).

Sur ce même service, vous avez également la possibilité d'afficher des cases cochées/décochées. Pourquoi pas.

Une fois sur Stack Overflow, si vous voulez définir le langage utilise dans votre bout de code, il vous en coutera un :

<!-- language: lang-js -->

C'est l'exemple le plus parlant, mais il y a très certainement d'autres subtilités.

Note : La liste des différences entre GitFlav et l'original est ici (et elle est longue). De plus, à ma connaissance, les sources de GitFlav ne sont pas disponibles.

Normalisation

En bref, chaque fois qu'apparaît un besoin spécifique sur Markdown, mais non moins global, chacun y va à son coup de spécification. Un autre exemple, tout simple : Markdown ne prévoit pas dans sa norme le strike (barré). Basique, mais non implémenté. Que fait-on alors ? On forke et on rajoute un strike entre deux signes égals ? Ou deux dollars ?

Il est clair que le langage Markdown aurait un bon besoin de dépoussiérage, de normalisation et d'évolution. Vous saviez que la dernière version, la 1.0.1 date de 2004 ? Les usages ont tout de même un peu évolués en 10 ans.

Je pense qu'aujourd'hui les mieux placés pour porter ce changement sont les deux semi-géants de l'Internet cités précédemment : Github et Stack Overflow. Après tout, Twitter a bien révolutionné le monde des framework CSS, pourquoi un meilleur Markdown ne serait-il pas possible ?

Note : Image via le Colibri.