L’Assemblée se dote d’une commission sur le numérique - Chambres à part

Vie privée : Yahoo arrête de prendre en compte le Do Not Track - Numerama

Opposés à YouTube, les indépendants saisissent la Commission européenne - Next INpact

Edward Snowden, futur citoyen d'honneur de la république française ? - Numerama

Reset The Net - LinuxFR.org

Caliopen, encourager le chiffrement - LinuxFR.org

L'écosystème fermé d'Apple critiqué en chanson - Numerama

Un an après Prism, Reset the Net veut mobiliser autour de la vie privée - Next INpact

Se passer de Google, Facebook et autres big brothers 2.0 #1 - les moteurs de recherche - LinuxFR.org

Traité transatlantique : quels enjeux pour le numérique ? - L'Humanité

Encourager les DRM favorise le monopole : double peine pour Hachette - ActuaLitté

Tizen en force chez Samsung : smartphone Z, TV connectées et Galaxy Gear - Next INpact

Original post of Planet Libre.Votez pour ce billet sur Planet Libre.

Let's rump

Benjamin Morin, comme chaque année, présente la première rump au nom du CO du SSTIC. Cette année, les 450 places se sont vendues en 8 minutes (nouveau record) ce qui a un peu augmenté la trésorerie de l'association.

Le mode de soumission des conférences a changé cette année, c'est désormais « soumission libre » (au lieu de l'article de 10 pages minimum des années précédentes), et pourtant les actes ont battu des records cette année : 450 pages au total (ça fait lourd dans le sac 😉).

L'organisation des rumps a également été un peu modifiée : chaque rump dure 3 minutes et, si le public veut que l'orateur continue, il ne doit pas applaudir. Si au contraire le public veut que l'orateur s'arrête, il doit applaudir et un applaudimètre couplé à un petit lance-missile tire une flechette en mousse sur le speaker !

Tuto Miasm par Serpi (Fabrice Desclaux)

Il paraît que miasm est dur à installer. Serpi reçoit souvent (je cite) des mails lui disant que « Installer miasm c'est pire que de se mettre des caillous dans le c.l ».

Il montre en 2 slides et trois commandes qu'en fait, c'est pas si compliqué :]

Cloud ISO 14001 (v2) par Arnaud Ebalard

L'année dernière, en rump, Arnaud Ebalard montrait comment se créer son petit cloud perso pas cher et conforme à la norme ISO 14001. Il a poursuivi l'expérience en développant les patchs nécessaires pour faire tourner des Linux sur des NAS Netgear.

Il a mis en ligne sur natisbad.org les images du kernel Linux pour 6 NAS différents (il remercie d'ailleurs Netgear pour lui avoir filé du matos). Son prochain gros travail est le développement d'un SoC securisé.

SELKS par Eric Leblond

Slides

Eric Leblond, membre de la core team de Suricata déplore que tous les trucs un peu sexy en infosec soient tournés sur l'offensif. Il essaye de corriger ça en nous montrant une brique orientée défense : SELKS.

SELKS, pour « Suricata - ElastikSearch - Logstash - Kibana - Scirius », est une distribution basée sur Debian qui embarque Suricata 2 et tout ce qu'il faut pour avoir une interface Web un peu classe pour visualiser les évènements et surtout créer des règles qui vont lancer des actions en fonction des events reçus.

Par exemple, si un client SSH ne me plaît pas je le bloque, etc.

Kerby@parsifal par Olivier Levillain

Olivier Levillain avait présenté l'an dernier dans une présentation courte Parsifal, un outil qui permettait d'écrire très rapidement des parseurs pour des protocoles réseaux.

Il a refait une démo, cette fois-ci en prenant comme exemple les requêtes Kerberos envoyées par Aurélien Bordès dans sa présentation.

ssticy par Pierre Bienaimé

ssticy est un «truc poisseux en python » pour faciliter la résolution des challenges. C'est un framework à la Scapy, avec plusieurs modules (crypto, useful, useless, network, etc), autocomplétion et tout ce qu'il faut.

Pas de code source public, mais un bon conseil donné : écrire ses propres outils c'est pas compliqué et c'est très formateur.

Sinon, en marge de ça, j'avais trouvé pwntools, dans le numéro 73 de MISC, qui fait la même chose.

J'ai cru voir un grosminet par P.M. Ricordel & P. Capillon

Cette rump était indéniablement une des plus intéressantes ! Quand les machines infectées sont isolées du réseau ou que, plus généralement, l'exfiltration de données est impossible, une autre solution existe : faire fuiter des informations à travers des ultrasons.

Un programme C encode les informations à exfiltrer (texte ou images) dans des ultrasons et, comme par magie, les informations deviendront visibles quand on écoutera le son ambiant dans Audacity.

Une configuration spéciale est à appliquer dans Audacity :

En lisant le fichier son avec un iPhone, on peut s'écarter d'une bonne dizaine de mètres et recevoir les infos encore proprement sur un Mac Book Pro. Avec des enceintes correctes, on doit pouvoir aller vachement plus loin.

Il est donc possible d'envoyer des petits chats dans des ultrasons \\o/

My prefered rump at #SSTIC: kittens transmitted over ultrasound from a smartphone and displayed as a FFT in auhacity pic.twitter.com/dx2L8WaGfn

— Aurélien Francillon (@aurelsec) 6 Juin 2014

Les sources ne sont pas encore disponible sur Github, mais elles peuvent être émises dans un .wav d'1h26 et de quelques Go 😉 Et oui, ça a effectivement été développé avec l'argent de vos impôts (les orateurs sont de l'ANSSI).

L'obfuscation dont vous êtes le héros par Serge Guelton

Jeu de rôle rapide en quelques slides basé sur les Livres dont vous êtes le héros où un code source a été obscurssi suivant les choix du public.

Mind your languages par Pierre Chifflier (@pollux)

Écrire du code sécurisé c'est bien, mais attention aux petites erreurs de conception intrinsèques aux languages utilisés. Exemples en vrac :

Les égalités en Javascript sont complètement tordues :

{} + {} // NaN
[] + {} // "[object Object]"
{} + [] // 0
({} + {}) // "[object Object][object Object]

En Java, dans certaines égalités, les nombres inférieurs à 128 sont tous égaux.

En PHP, tous les hashs calculés débuteront par un certains nombres de 0, puis un e, puis une suite de chiffres, et seront tous égaux dans les égalités en ==.

La présentation complète, Mind your languages, est déjà dispo sur le site de « L'Agence » : http://www.ssi.gouv.fr/fr/anssi/publications/publications-scientifiques/articles-de-conferences/mind-your-languages-nouvel-article-sur-l-importance-des-langages-pour-la.html

Sécurité des ADSL exotiques par Nicolas Ruff

En Suisse, les immigrés ne peuvent pas avoir de l'ADSL sans quelques recherches approfondies. Nicolas Ruff a donc pu jouer pendant 3 semaines avec son modem Swisscom avant d'avoir accès à Internet.

Quelques vulnérabilités trouvées.

Les credentials sont admin:admin (ou admin:1234).

Depuis la ligne de commande on a accès à quelques commandes, dont le ping. Du coup, on peut très vite arriver à d'autres infos à base de : ping 8.8.8.8; head /etc/passwd, les process tournent en root, etc

Bonne nouvelle par contre, leur OpenSSL n'est pas vulnérable à la faille Heartbleed. Bon, c'est parce qu'il est trop vieux, mais au moins il n'y a pas de faille ! :p

Il s'est même permis un[^1] petit troll sur sa dernière slide : « _ _ _ _ recrute » qui se transforme en un « Google recrute », petite dédicace aux slides de l'an dernier de l'ANSSI et de la DGA.

Private meeting par Aurélien Bordes

Une des forces d'Outlook c'est son calendrier intégré. Le problème, c'est que quand on partage son calendrier, tout les évènements deviennent publics, exit les rendez-vous privés. Outlook a donc ajouté une option « Privé » sur les évènements.

Problème, ces évènements ne sont pas réélement privés, ils disposent simplement d'un flag de sensibilité qui est positionné sur « Private ». Et comme EWS est requêtable en HTTP, n'importe qui peut y accéder.

Tout ceci est documenté dans MSDN, donc Microsoft ne le considère pas comme une vulnérabilité et l'affichage ou non de ces évènements reste à la discrétion des clients Exchange.

From NAND till dump

Pour éviter de devoir déssouder des composants électroniques trop chiants à manipuler, l'orateur à passé sa carte aux rayons X, à repéré les pistes électroniques puis a découpé au laser certains parties pour isoler le composant. Il a ensuite dumpé la flash comme ça, puis à ressoudé le tout pour que la carte refonctionne.

x86 anti decode (PoC) par Axel Tillequin (@bdcht)

Too much reverse, too much assembly, j'ai décroché...

Stopper l'attaque DDoS de Bryan

Une boîte qui fait de l'advertising via des cookies a subi une attaque DDoS par un méchant Kevin^WBryan. Pour éviter de pommer trop de sous, ils se sont mis derrière plusieurs reverse proxys, puis on regardé d'un peu plus près l'attaque.

Pour remonter à Bryan, ils ont décidé de placer un cookie spécial sur son navigateur dès sa prochaine attaque pour pouvoir le suivre sur tous les sites sur lesquels ils ont des pubs, et donc remonter jusqu'à lui.

Sauf qu'il fallait qu'il relance une attaque. Et c'est là que les marketeux entrent en jeu. Comme des grands, sans rien demander à l'IT, ils ont lancé une campagne de mass mailing en disant qu'ils savaient gérer ce genre d'attaque et qu'ils n'étaient pas impactés.

Le gentil Bryan, touché dans son orgeuil, à relancé l'attaque, ce qui a permis aux équipes IT de lui envoyer le gentil cookie et de s'apercevoir que Bryan avait un compte chez eux. Ils ont fermé son compte et, depuis, plus aucune attaque.

jpg or mp4, pourquoi choisir ? par Christophe Grenier

Pas de rump sur photorec cette année, mais sur une technique permettant de créer un fichier polyglotte contenant du Jpg et du MP4.

TCP Fast Open par Synactiv

Slides

TFO est une amélioration de TCP massivement poussée par Gogole qui permet de réduire le temps d'établissement des sessions TCP. Comme généralement tout se passe bien, avec TFO on commence à envoyer de la data dès le premier SYN. Sauf que les IDS attendent d'avoir un SYN - SYNACK - ACK pour détecter des attaques.

Si on commence à envoyer des patterns malicieux dans le premier SYN, on peut pouttrer Snort et Suricata finger in the nose.

Eric Leblond attend donc le patch des ingé de Synactiv pour intégrer cette détection dans Suricata 😉

Pour info, TFO est supporté par le kernel Linux depuis la 3.6 et est activé par défaut depuis la 3.13. Il est aussi activé dans Chrome et peut l'être sur nginx (mais pas Apache pour le moment).

REbus

REbus est un bus de communication entre plusieurs outils pour faciliter le reverse des malwares. On peut ainsi coupler une analyse statique, des AV, IDA ou des analyses dynamiques pour obtenir des infos sur des malwares.

Classif

Avec toutes les informations obtenues avec REbus, il est donc possible de classer les malwares dans des grandes familles puis de générer des graphes pour visualiser les liens entre malwares.

La résolution du fameux challenge web100

Troll sur la déclaration d'impôts en ligne. Il manquait certains champs dans le formulaire en ligne. En les rajoutant à la mano dans le code HTML, l'orateur a pu déclarer toutes ses ressources et dépenses et économiser 900€ sur sa déclaration !

IRMA

Incident Response & Malware Analysis est un outil en ligne qui permet de combiner plusieurs moteurs d'analyse de fichiers pour obtenir plus d'informations, et des informations plus précises. On peut combiner des analyses anti-virus, Hashdb, des analyses statiques, des sandbox, etc

C'est disponible sous licence Apache 2.0, en ligne sur les dépôts GitHub de Quarkslab (quarkslab@github/irma-*) et une version de test est en ligne : http://frontend.irma.qb il n'y a pas encore de version de test en ligne.

Android 0dayz hunting, again

J'ai pas trop suivi...

Actes epub

Yves-Alexis Perez cherche des solutions pour transformer facilement et rapidement les actes du SSTIC qui sont au format LaTeX en fichiers epub. Pour l'instant, hormis MathML et les graphes Tikz, tout fonctionne.

Et c'est déjà en ligne.

???

Nodescan

Comment scanner Internet très simplement et avec peu de moyens. J'ai pas noté plus :/

Promo NSC

La NoSuchCon se déroulera du 19 au 21 Novembre 2014. Le CFP se termine fin septembre : http://www.nosuchcon.org/#cfp.

100% en anglais, 0% Bullshit (ou pas).

Do not make your own crypto

Une application française permettant de chiffrer ses sms utilise une crypto toute pourrie, du coup en peu de temps on a accès à tout.

A large scale analysis of the Security of Embedded Firmwares

Les orateurs ont scanné Internet pour obtenir des infos sur les firmwares utilisés sur les box, caméra IP, etc.

Encore une fois, on découvre des jolis bugs, comme la même clé privée utilisée pour toutes les caméras IP chez plusieurs fabricants, des firmwares vulnérables à des CVE connues depuis des années, etc

[^1]: Je vous rassure, ce n'était pas le seul troll ;)

Original post of Quack1.Votez pour ce billet sur Planet Libre.

Cette deuxième journée au #SSTIC était un poil moins dense que la première si on compte le nombre de conférences, mais la journée s'est terminée par 27 rumps, ce qui, en soit, est déjà assez intense !

Escalade de privilège dans une carte à puce Java Card par Guillaume Bouffard & Jean-Louis Lanet

La première présentation concernait les Java Card et était donnée par des chercheurs de Limoges[^1].

À peu près toutes les cartes à puces qui sont en circulation sont des Java Card, ce qui représente plus de 12 milliards de périphériques. Une Java Card, c'est donc une carte à puce qui embarque une JVM Java allégée et qui peut donc exécuter des applications Java.

2 étapes de sécurité différentes sont implémentées dans le modèle de sécurité Java Card :

1. Le PC qui compile vérifie que le bytecode Java qui sera exécuté est correct et il signe l'applet;
2. et un mécanisme de vérification des signatures et de sandboxing, ainsi qu'un pare-feu entre les applications sont également présent sur la carte elle-même.

Et c'est à peu près tout ce qu'il y a. Comme la carte est très légère (processeur 8bits, 32ko de ROM, 32ko d'EEPROM et 2ko de RAM) on ne peut pas implémenter beaucoup plus de choses. Par exemple, aucune implémentation connue de la JVM ne vérifie et empêche les débordements de tampons.

Du coup, plusieurs attaques sont encore possibles :

• Exécution de code natif à des adresses arbitraires ;
• Écriture de code à un index arbitraire dans la ROM ;
• Exécution de code et accès à un compte root sur l'OS de la carte ;
• Lecture de la ROM de la carte ;
• Appel de code natif.

Par contre des cartes à puce, même de développement, ça coûte un peu cher...

La recherche en France: "on a un class break dans toutes les cartes en circulation, mais on a pas l'argent pour s'acheter 2 cartes" #sstic

— newsoft (@newsoft) 5 Juin 2014

Recherche de vulnérabilités dans les piles USB : approches et outils par Fernand Lone Sang & Jordan Bouyat

Comme les cartes à puce, l'USB est ultra répandu. C'est donc intéressant de se pencher sur la sécurité de ces périphériques, surtout qu'y accéder est super rapide et peu coûteux.

Pour faire leurs tests, les deux ingénieurs de @Quarkslab ont développé un outil qui récupère les trames USB, extrait les octets à modifier puis les rejoue sur le périphérique. Une sorte de proxy USB.

En fuzzant un peu n'importe comment pour accéder aux couches hautes (les applications), le pilote USB de Windows (USBSTOR.sys) plante.

Au final, je n'ai pas vu de résultats très avancés, mais la démarche et l'outil développé sont prometteurs et vont sûrement conduire à des trucs assez sympa.

Bootkit revisited par Samuel Chevet

En gros (c'est pas trop ce que je préfère les bootkits) j'ai compris qu'en infectant la chaîne de boot de Windows, l'orateur arrive à bypasser le mécanisme d'authentification de Windows pour se logguer sur la machine avec un mot de passe faux.

Tests d’intégrité d’hyperviseurs de machines virtuelles à distance et assisté par le matériel par Benoît Morgan, Eric Alata & Vincent Nicomette

Pour lancer des machines virtuelles, on dispose d'un hyperviseur qui est installé directement sur l'hôte (en gros, c'est un OS) qui est chargé de créer et exécuter les machines virtuelles en allouant proprement les ressources.

Il est possible que l'hyperviseur soit compromis par le réseau, ou par un composant hardware, ce qui impliquerait que toutes les VM sont compromises.

Ce projet est en quelque sorte un nouvel hyperviseur, qui va faire tourner l'hyperviseur réel et donc va pouvoir lancer des checks pour vérifier l'intégrité de l'hyperviseur et détecter plus rapidement des compromissions.

C'est basé sur une carte FPGA sur un slot PCIe et ça peut lancer toute sorte de checks et remonter des alertes.

La sécurité des systèmes mainframes par Stéphane Diacquenod

On est tous habitués à avoir chacun un poste de travail et on oublie que dans certaines sociétés, il existe encore des systèmes mainframe, comme c'est le cas chez Volvo.

Ici, on est sur du matériel IBM et, franchement, la sécurité n'est pas au point. Les mots de passe sont composés d'au maximum 8 lettres majuscules et chiffres, l'administration se fait sur du telnet, dans la BDD le système stocke le login chiffré en DES avec le mot de passe pour vérifier l'authentification, cette base est accessible en lecture par tous les utilisateurs (qui pourront facilement casser les mots de passe avec John the Riper, etc.

Bref, c'est pas au top, et toute la sécu repose sur le boulot des sysadmins qui ont énormément de taf pour maintenir un truc un peu propre.

Présentation courte : Reconnaissance réseau à grande échelle : port scan is not dead par Adrien Guinet & Fred Raynal

Slides

Nouvelle présentation de Quarkslab, sur le scan réseau à grande échelle.

Les outils connus, comme nmap, Nikto, Blind Elephant et autres, sont utiles pour des petits réseaux, mais pas pour des /8, surtout qu'ici les infos recherchées sont en couche 7 (textes, images, certificats, clés, etc).

Ils ont donc développé un sorte de petit botnet qu'ils ont déployé sur les VM dans des « pays acceuillants (Estonie, Roumanie, ...) » et qu'ils pilotaient à distance. Un ordonnanceur distribuait quelques adresses IP aléatoires (scanner un range d'IP depuis le même host ça fait recevoir des mails depuis abuse@) à chaque agent qui scanne ensuite la cible avec nmap puis renvoie les infos au scheduler qui stocke tout ça dans une grosse base Mongo DB.

Et en plus, on peut mettre un peu d'intelligence dans le scan. Du genre « si le port tcp/80 est ouvert, teste le tcp/443 et récupère le certificat x509 ».

Après, ça devient tout simple de faire des recherches la dedans pour avoir des infos sur les machines françaises (encore faut-il savoir si on cherche les machines en .fr ou celles qui ont des IP françaises), ou faire des statistiques sur les logiciels utilisés dans certains pays.

Par exemple, en Espagne, un FAI met le nom de l'abonné dans la bannière du service FTP qui est en écoute sur l'Internet. Au final, scanner les 30 millions d'IP espagnole à demandé 25 heures de scan.

La bibliothèque développée est en ligne sur Github.

Cryptocoding par Jean-Philippe Aumasson

Slides

Dans cette période troublée par différents — gros — bugs crypto (Heartbleed, GNUTLS et « goto fail; »), Jean-Philippe Aumasson a été invité à faire une conférence sur le sujet.

Le monsieur est un peu calé sur le sujet puisqu'il fait parti du projet OpenCryptoAudit qui a pour but d'auditer le code de Truecrypt. Et il aime un peu les trolls puisqu'il ne s'est pas géné pour taper un peu sur tout le monde.

D'abord, sur OpenSSL et la « qualité » de son code. Un nommage non consistant, des bugs ou corner cases connus par les développeurs mais non fixés (présente de FIXME, QUICK AND DIRTY SOLUTION dans le code), des fonctions crypto qui ne suivent pas les RFC, des fonctions ou des API pas assez propres, etc.

Une autre raison aux bugs présents dans le code d'OpenSSL c'est la trop grande variété des protocoles et OS supportés.

Il a aussi parlé un peu de Tor et Cryptocat, renommés comme étant des références en matière de protection de la vie privée, mais qui pourtant ont contenu pendant longtemps des gros bugs dans l'implémentation de leur crypto.

Pour bien coder de la crypto, il est à l'origine d'un wiki qui donne une douzaine de bons conseils pour être résistant aux principales attaques (time attack, misuse attacks) et éviter que les compilateurs optimisent trop le code.

1 Compare secret strings in constant time

2 Avoid branchings controlled by secret data

3 Avoid table look-ups indexed by secret data

4 Avoid secret-dependent loop bounds

5 Prevent compiler interference with security-critical operations

6 Prevent confusion between secure and insecure APIs

7 Avoid mixing security and abstraction levels of cryptographic primitives in the same API layer

8 Use unsigned bytes to represent binary data

9 Use separate types for secret and non-secret information

10 Use separate types for different types of informationp

11 Clean memory of secret data

12 Use strong randomness

Coder de la bonne crypto ça demande d'être très bon en maths et crypto, et très bon en programmation. Réunir les deux qualités est compliqué, il faut donc que les deux parties travaillent ensemble pour éviter les gros bugs.

Buy it, use it, break it ... fix it : Caml Crush, un proxy PKCS#11 filtrant par Ryad Benadjila, Thomas Calderon & Marion Daubignard

PKCS#11 (ou Public Key Cryptography Standards, ou « Cryptoki » (Cryptographic Token Interface)) est un standard qui est destiné à éliminer les implémentation propriétaires en fournissant une API/driver pour dialoguer avec des HSM (composants sécurisés).

Notamment, les clés cryptographiques doivent généralement rester à l'intérieur des HSM (des tokens ou cartes à puce par exemple). PKCS#11 va donc permettre de réaliser des actions cryptographiques tout en gardant les secrets dans les composants crypto.

Ces HSM peuvent contenir plusieurs clés, ayant chacune des propriétés distinctes. Par exemple, on peut avoir une clé R avec l'attribut SENSITIVE (qui ne doit pas sortir de la carte) et une clé B avec WRAP (pour encapsuler une autre clé) et DECRYPT.

Et c'est là dessus qu'il existe des vulnérabilités, notamment puisque (en gros) DECRYPT = WRAP⁻¹. On peut donc « wraper » R avec B, puis déchiffrer le résultat avec B pour réobtenir R.

Caml Crush est donc un proxy PKCS#11 qui va intercepter toutes les requêtes et les modifier/supprimer pour empêcher des attaques exploitant ce type de vulnérabilités.

Martine monte un CERT par Nicolas Bareil

Nicolas Bareil, du CERT d'Airbus Group, a fini la journée (avant les rumps) par un retour d'expérience sur la création d'un CERT. Ce milieu semble assez fermé, c'est pourquoi il voulait partager son xp avec le SSTIC.

Finalement, un CERT, ça doit se concentrer uniquement sur les gros incidents, ça doit prendre du recul par rapport aux incidents, et surtout communiquer. Dans le CERT, avec les utilisateurs/admins, la hiérarchie, etc.

Niveau technique, les attaquants ne sont pas toujours très intelligents mais, dans le cas des APT, ils prennent leur temps pour garder une porte d'entrée saine au cas où. Il faut donc être capable d'analyser du réseau ou du système pour remonter les traces. Mais attention, des malettes de copie de disques sont inutiles, généralement il faut tout faire en live pour ne pas « géner » l'attaquant et ainsi prendre le temps de bien comprendre tout ce qu'il fait.

Il faut donc être capables de déployer rapidement des IDS pour observer le trafic, des agents sur les postes impactés pour suivre les actions lancées par l'attaquant, et pouvoir remonter jusqu'au « patient zéro » de l'attaque.

Enfin, de très bonnes capacités de communication sont essentielles. Une infrastructure dédiée et sécurisée pour les membres du CERT doit pouvoir être mise en place très vite (plusieurs serveurs, infra mails, Wiki, tickets, etc). Les noms des contacts IT et responsables de tous les pôles de l'entreprise, dans les filiales et chez les sous-traitants doivent également être connus, et ils doivent tous connaître le rôle du CERT et le leur dans la résolution de ces incidents.

Je trouve que l'article vaut vraiment le coup d'être lu, tout y est bien expliqué, et Nicolas était prêt à partager toutes les infos qu'ils avaient dans leur CERT à ceux qui voudraient se lancer !

Rumps

Enfin, un #SSTIC sans les rumps ne serait pas un SSTIC et, commme il y en avait 27, elles font l'objet d'un article à part.

[^1]: Où j'avais d'ailleurs fait mon Master

Original post of Quack1.Votez pour ce billet sur Planet Libre.

Selon cet article de ZDNet, Mozilla réfléchirait à une incitation financière pour que les fabricants mettent à jour Firefox OS sur leurs appareils. Cela permettrait (peut-être ?) d’éviter le phénomène qui se produit sur Android : des téléphones « abandonnés » par leurs géniteurs, ce qui nous pousse évidemment à acheter un nouveau téléphone plutôt qu’à mettre à jour. Combien d’entre nous n’ont pas été déçus de voir leur téléphone « figé dans le temps » avec Android Gingerbread (2.3) alors qu’Android 4 était sorti depuis plus d’un an ?

De plus, c’est ce qu’on appelle la « fragmentation » d’Android : les développeurs sont contraints de supporter de multiples versions de ce système, avec des possibilités plus ou moins étendues, chose que Mozilla voudrait éviter dès maintenant pour Firefox OS. Si Mozilla réussit ce pari, Firefox OS y gagnera en attractivité, et on pourra dire que sur ce point la fondation défend vraiment l’utilisateur, et le développeur !

Original post of mozillaZine-fr.Votez pour ce billet sur Planet Libre.

Ces prochains jours nous allons migrer notre infrastructure vers une autre solution, hébergée par Aquilenet, FAI associatif. Il y aura certainement dans les heures qui viennent des soucis quant à l’accès du site, au forum… Vous pourrez toujours nous contacter et avoir des nouvelles en réel sur l’IRC (chat en ligne) de l’association.

Cette migration s’inscrit dans notre volonté de réduire nos coûts d’infrastructure (par 10) afin de mieux répondre aux réalités de notre association, telles que définies dans notre dernier rapport d’Assemblée Générale Extraordinaire.

Original post of Dogmazic.Votez pour ce billet sur Planet Libre.