Ph Husson a écrit 2703 commentaires

Tu as les outils pour faire ton propre registrar.
Juste, de la même manière que pour un certificat, les gens devront configurer leur machine pour l'accepter.

Je comprends pas pourquoi tu acceptes DANE, et plus largement les DNS comme autorité.
Les noms de domaines sont même pires que des CAs comme autorité, car c'est l'argent/le premier arrivé premier servi qui décide qui a quel domaine, alors que pour les CAs, tout les domaines sont égalitaires et ont le droit à leur certificat personnel.

Les XPeria, Sony a distribué de quoi compiler Android M pour ses téléphones (y compris des très vieux comme le Xperia Z) avant que Google ne publient eux-même leurs binaires.

Attention. CyanogenMod n'est plus complètement opensource, ils ont maintenant des applications closed source dans leurs firmware.

C'est clairement plus complexe.

Je comprends parfaitement ton mécontentement t'inquiète pas :-)
Je dis juste que c'est principalement une limitation technique.
Typiquement, sur une distrib pas trop moderne, n'importe quelle application que tu installes/lances en tant que ton utilisateur a déjà tous ces droits, et ça ne te choque pas. (la différence étant qu'il ne l'affiche pas)

Et quand bien même le bootloader serait moins fermé qu'avant, je ne vois pas en quoi un téléphone Android bloaté serait fondamentalement différent d'un ordinateur livré ous Windows : pour avoir un truc libre, il faut réinstaller l'OS.

On est parfaitement d'accord. C'est d'ailleurs exactement ce que j'ai dit: « De mon point de vue, un téléphone Android est actuellement aussi libre qu'un ordinateur. »

Ma réaction était sur:
« De manière générale, et ça n'est pas nouveau, ces appareils ne font pas ce qu'on leur demande. Ils n'appartiennent pas à leur propriétaire légitime, ils travaillent pour l'entreprise qui les a programmé. »

Ton commentaire me fait rugir.
Google/Android est férocement anti-NSA, et anti logiciel proprio pour les services "de coeur".
Les services de communication avec le modem ont des politiques SELinux des plus violentes (d'ailleurs ils se prennent pas mal d'erreurs)
La grande majorité des téléphones Android récents ont un bootloader ouvert/ouvrable.
L'architecture des téléphones a pas mal changé depuis l'époque des smartphone.
À l'heure actuelle un téléphone à base de Qualcomm peut être compilé et fonctionnel avec juste des daemons de communication avec le modem. Les sources Android modifiées par Qualcomm sont disponibles sur https://www.codeaurora.org
Certains constructeurs fournissent les quelques binaires à mettre pour avoir un support matériel complet sur l'Android opensource (AOSP), par exemple: http://developer.sonymobile.com/knowledge-base/open-source/open-devices/list-of-devices-and-resources/

Les modems n'ont même plus d'accès direct au stockage (trop complexe à implémenter), tout passe par un proxy userland, non root, et ils se font booter par Linux lui-même.

De mon point de vue, un téléphone Android est actuellement aussi libre qu'un ordinateur.
Les communications avec l'extérieur ne sont pas libres, le début du boot n'est pas libre/dans un autre processeur, les drivers 3D ne sont pas libres, et il n'y a pas de morceau proprio dans le kernel.

En fait, le fait que que tu ne puisses pas désinstaller l'appli, ça veut dire que c'est une application dites shareduid system, ou platform. Ce pouvoir est utilisé pour certaines fonctions non prévues par l'API standard Android, et donc pour lesquels il faut les droit tout puissant. En particulier, pour tuer toutes les applications, il faut avoir ce droit.
Maintenant, quand une application utilise le mécanisme de shareduid (littéralement que deux applications partagent le même uid unix), Android affiche (et donne de fait.) tous les droits que chacune de ces applications ont demandés à toutes les applications.
Le développeur de cette application ne peut pas afficher "pour de vrai" les permissions utilisées.
En pratique tu trouveras de nombreuses applications dans ton téléphone qui ont cette liste intégrale de permissions.

Un article dans Nature, on considère qu'il est publié?

Que le code GPL soit publié, c'est "juste" une obligation légale, encore heureux qu'ils le publient!
Y a pas de quoi générer un firmware alternatif pour autant

Bah, le monsieur du journal dit:
« La question qui fache : combien de blobs binaires à sources fermées là dedans ? En attendant, moi je choisi Parrot (un seul module non libre : pour l'audio, et pas fait par parrot. Le reste est sous GPL. Bravo. Accès root, source, facilités, bonnes docs/commentaires. »
Du coup je comprends pas vraiment…
(pour Qualcomm c'est un peu pareil, ce qui est sur le processeur principal est libre, à part le driver GPU, le code des DSPs est proprio, mais programmable)

Ça tient plus de l'interprétation, mais « dont les spécifications techniques sont publiques et sans restriction d'accès ni de mise en œuvre »
pour moi ça signifie qu'on peut le modifier pour faire sa propre version/on est pas obligé de respecter à la lettre la specif.

D'ailleurs, la licence d'Adobe Flash est identique à celle de VP9 depuis un certain temps (la différence étant que dans un cas c'est du copyright, dans l'autre des patents). Le format est publiquement disponible, et tu as le droit d'implémenter ton propre player, à condition qu'il soit pixel perfect.

Le développeur n'est même pas libre d'avoir de bug.

Si vous ne définissez pas de phrase secrète, vous pouvez utiliser le cloud de Google en laissant Google lire vos données.

Si tu ne mets pas de clefs de chiffrement, alors les données sont "en clair" (chiffrées avec mot de passe du compte, whatever), donc Google peut y accedér.
Pour moi c'est une formulation purement technique, et ne veut pas dire que Google le fera.
Une formulation beaucoup moins "Google is the evil" est juste que s'ils se reçoivent un mandat de la police, alors ils pourront le lire, donc si tu veux te protéger de ça, mets une passephrase.

Tu te plains que tu demandes à ton navigateur web d'enregistrer tes mots de passes dans le cloud, et t'es choqué de pouvoir relire les mots de passes en question ?
Ça perdrait de son intérêt s'il n'était pas capable de les relire…

Je vois pas vraiment comment sans mot de passe (ou du moins sans secret partagé entre les clients) un client peut chiffrer les données.
Ou alors on parle de chiffrements de communication entre le client et le serveur, ce que Google fait déjà?

S'ils font ça, c'est pas par volonté de nuire, d'espionner ou quoique ce soit de vilain, c'est que ça existe déjà et ça marche.
Cf http://fortune.com/2015/05/22/a-chinese-app-that-steals-wifi-passwords-just-raised-50-million/ :
Il existe en Chine une application mobile de partage de mot de passes sur exactement le même principe, qui est utilisée par 270 Millions d'habitants. Genre, plus que le marché de Windows aux USAs.
Donc proposer l'option ne parait pas déraisonnable, vu qu'il doit répondre à un besoin de plus d'un quart des clients de Microsoft (bon euh client… utilisateurs du moins.)

D'autre part, cf http://arstechnica.com/gadgets/2015/07/wi-fi-sense-in-windows-10-yes-it-shares-your-passkeys-no-you-shouldnt-be-scared/
C'est un opt-in par réseau. On dit explicitement chacun des réseaux qu'on veut partager.

Euh…
Le lien que tu cites ne parles que des services en hotel/aéroport/centre de conférence, bref certainement pas les WiFi personnels, dont il est question ici.

Je pense que s'ils prévoient de partager les mots de passes WiFi à plus que juste les amis facebook, ça sera pour un service type Fon.

En plus, ces WiFi sont généralement trustés depuis plusieurs générations et pour encore plusieurs autres à venir, par nos gros opérateurs adorés.
Aucune information n'est donnée, mais pour moi c'est juste un partenariat avec les opérateurs WiFi de "centres d'intérêts", dont il est question ici.

Ouaip, mais globalement ça va en s'améliorant.
Tous les constructeurs de puces (même les chinois, Mediatek, Rockchip, Allwinner du moins) se mettent à pousser des morceaux dans Linux, et Qualcomm (le constructeur Android "historique") se met au vert, en avançant sur l'usage d'API standard (genre leur driver 3D utilise DRM maintenant, ils ont l'API standard de GPIO et clocks, ils utilisent les device-tree, …).

Ils tournaient avec des kernel fait par Qualcomm (kernel dispo sur leur page opensource, https://www.codeaurora.org), potentiellement légèrement modifié par le constructeur
Et ça va durer, même maintenant que Linux 4.1 est sorti, vu que les kernel Android ont toujours 3 ans de retard.

Je peux être à côté de la plaque, mais ma compréhension du terme est très différente.
Pour moi, DevOps désigne les administrateurs systèmes qui travaillent comme des développeurs:
Par exemple:
Une configuration est sous git, et faire le git push déploie automatiquement la configuration partout.
Une nouvelle machine à déployer prend quelques minutes au devops.
Il existe des branches master et des branches "stables", les branches master étant les systèmes "en dév"
Et ensuite, il y a des outils de tests continu d'intégration pour vérifier sur la branche master que rien n'est cassé

Il se trouve que les outils les plus couramment utilisés pour ce type de développement est docker, lxc, ou plus basiquement des scripts autour de debootstrap, et il est plus difficile de faire la même chose sur des systèmes propriétaires, donc il se trouve que la majorité des DevOps utilisent des outils libres, mais il n'y a pas de lien dur entre DevOps et libre.

J'ai testé Sailfish OS (l'os de jolla) sur Nexus 5
Et pour le coup je trouve le store beaucoup trop petit, mais l'UI super bien léchée, et avec des bonnes idées.
Mais tu viens de me faire découvrir qu'il est compatible avec des applis Android, donc ça m'ouvre plein de possibilités, merci :)

Rajouter un mode d'économie d'énergie pour avoir plus d'autonomie, c'est pas dur, suffit de couper les data, le wifi, réduire la luminosité, etc.
Google a annoncé des optimisations batteries pour Android L et M, qui sont du même acabit:
- En dessous de 15%, t'as une notification qui te propose d'activer le mode économie (qui fait ce que j'ai dit au dessus)
- Sur Android M ils essaient d'être plus intelligents, et déterminent avec l’accéléromètre si le téléphone est utilisé, et ne réactiver les communications avec les serveurs que quand y a du mouvement.
Perso sur mon Nexus 5, c'est une catastrophe, mes mails ne sont plus synchronisés que deux fois par jour

Moui, alors effectivement, quand t'as une caméra à profondeur de champ, dans une tablette prévue pour faire du SLAM (Simultaneous Localisation and Mapping), encore heureux qu'ils arrivent à faire de la localisation -_-'
Mais sans caméra ils pourraient pas.

Même quelques minutes c'est assez optimiste…

Ma formulation est volontairement flou.
Je fais partie des gens qui considère que le NAT n'est jamais une solution de sécurité en soit, et effectivement ici non plus, le NAT n'apporte pas intrinsèquement de sécurité.
Juste, le NAT fait qu'il est plus facile de comprendre/faire des schémas de ce qu'il se passe, et le pare-feu se fait de la manière classique, à savoir selon l'adressage réseau.
Aussi, le filtrage par cgroups est moins testé, et a plus de chances d'avoir des failles. (typiquement je vois pas d'option à lxc pour rester dans le même namespace réseau, mais après c'est peut-être plus philosophique de leur part)