-
Aissen plus de 8 ans | lien | sur : la société GETTY IMAGE met Framasoft en demeure de supprimer un article (2014, maj 2016)
Attention au titre, si l’article est de 2014, la MàJ est bien du 8 mars 2016.
-
merci, je mets à jour
-
-
La Raspberry Pi, la Wi-Fi… mes yeux !!!
-
Pas fou la conf, y'a mieux :/
-
C’est clair, plutôt que de copier/coller la conf d’un blog, je vous conseille d’utiliser le générateur de config TLS de Mozilla:
https://mozilla.github.io/server-side-tls/ssl-config-generator/
Ça supporte plusieurs serveurs web, plusieurs version de nginx, et trois paliers de compatibilité qui vous permettront d’ajuster selon vos besoins.
-
et moi qui me le suis coltiné à la main la semaine dernière pour le Jdh ! :D Merci, je note le lien pour l'avenir.
-
Ou sinon… :D https://angristan.fr/configurer-https-nginx/
-
-
-
Je trouve l’approche de keybase.io bien plus intéressante. Et eux aussi savegardent un hash de vérification dans la blockchain bitcoin.
-
Document non trouvé.
-
L’URL actuelle: http://genma.free.fr/?FirefoxOS-Export-des-SMS
Petit message pour @genma : http://www.w3.org/Provider/Style/URI.html =P
-
En effet un petit problème avec l'url, c'est corrigé. merci pour le retour :)
-
-
-
Un inconvénient de la règle “contenu francophone uniquement” sur jdh, c’est que du coup pas mal de contenu devient du “blogspam”; en gros un contenu que quelqu’un vu sur internet, et repompé en traduisant quelques lignes. Néanmoins, très peu de fois on voit une quelconque valeur ajoutée, à part bien sûr l’aspect francophone.
Vous en pensez quoi de cette limitation ? cc @Cascador @carlchenet
-
-
Salute,
L'aspect francophone est important et non anecdotique, la réalité c'est que beaucoup de personnes ne lisent pas l'Anglais. Traduire ce n'est pas rien, c'est même un gros +. C'est dans les gênes du Jdh de faire du contenu en Français pour justement que ce soit accessible au plus grand nombre.
Je t'invite à venir m'en parler en privé si tu souhaites qu'on prolonge la réflexion, des idées/propositions à soumettre par exemple.
Merci, Tcho !
-
-
Plutôt bien écrit et assez naturel pour un poste sur le blog d’une entreprise.
-
yup, tout à fait d'accord, ce blog produit souvent du contenu de qualité
-
-
Pour info, le mot de passe ssh est tombé:
<<< %s(un=‘%s’) = %u
-
haha… ou snif snif je ne sais pas
-
C’est pas tout, ils utilisent OpenSSL 0.9.6c (2001): https://twitter.com/staatsgeheim/status/678849497351503872
-
lol quoi
-
-
-
-
Mouaip. Potentiellement très dangereux du point de vue du droit du travail (utilisation des ressources de l’entreprise = appartient à l’entreprise), car alors les projets ne sont plus “persos”.
Ensuite, je ne suis pas d’accord que la veille c’est du télémaison; pour moi elle est partie intégrante du travail de l’employé, surtout si l’entreprise s’y retrouve au final.
-
-
J’utilise Muzei, et c’est excellent pour faire tourner des fonds d’écrans. Mais ce qui est extraordinaire, c’est surtout la standardisation apportée par l’application, avec des API permettant l’extensibilité à tous les niveaux: https://medium.com/google-developers/only-on-android-45ff04d5722e
L’intégration Android Wear est de plus excellente.
-
Ce qui me parait fou, c’est qu’elle permet d’avoir le contrôle de l’appareil (root). Les détails ne sont pas publics pour l’instant, mais ça m’intrigue.
C’est évidemment une chaine d’exploits qui a été conçue pour cet évènement (comme c’est habituellement le cas), donc ce n’est pas uniquement Chrome pour Android qui est touché. On devrait voir le correctif pour ce “root” arriver dans la mise à jour de sécurité de décembre ou janvier.
-
intéressant, merci !
-
-
Comment osent-ils appeler ça Firefox ? Ça n’est ni plus ni moins que le Firefox Home d’autrefois avec une webview en plus. Au moins dans Chrome pour iOS ils ont la stack réseau de Chrome, ça donne un petit avantage maintenant que le JIT est accessible dans la webview… C’est un peu triste de voir Mozilla céder ainsi, mais étant donné leurs parts de marchés mobiles (quasi inexistantes), ça peut se comprendre.
-
Cet article semble montrer une grand méconnaissance du fonctionnement de TextSecure : Aeris y parle par exemple de meta-données, qui sont exposées plus facilement (selon moi) par SMSSecure que par TextSecure; en effet, les méta-données SMS transitent de manière non chiffrées, et donc tous les acteurs de la chaine (opérateur d’envoi et de réception, états), ainsi que ceux prochent de vous (imsi catchers…) ont connaissance d’avec qui vous dialoguez. Dans le cas de TextSecure, seul le serveur d’Open Whispers Systems sait dire avec qui vous parlez, et vous faites donc confiance aux mêmes personnes qui ont développé l’application et le protocole.
Ensuite, il semble balayer l’argument principal des développeurs: la sécurité n’est pas absolue, et il faut donc la possibilité de rester toujours à jour sur la dernière version. Sait-on si F-Droid a la même rapidité de déploiement que Google Play ? Que se passe-t-il si les développeurs de SMSSecure “oublient” de le déployer sur l’ensemble des stores disponibles ? Si on installe SMSSecure depuis Google Play, on en revient sur la dépendance à Google, et ça m’amène à mon prochain point.
Pour maximiser la batterie d’un téléphone, il faut minimiser le nombre de fournisseurs de solutions push (i.e en avoir un seul) qui gardent une connexion TCP ouverte en permanence sur l’appareil avec un serveur distant. Et là, malheureusement GCM est la référence, donc la dépendance à Google Play (venant déjà du Store d’installation) n’est au final qu’un moindre mal.
Les arguments sur son forfait data vs les SMS illimités sont par contre tout à fait valides, et une spécificité française; de mon point de vue 50mo de data (=50 secondes de vidéo YouTube 1080p) est bien trop peu, mais c’est un autre débat.
En bref, à moins que vous ne conseillez déjà à vos contacts d’installer AOSP et toutes leurs applications depuis F-Droid, il vaut mieux utiliser Signal qui a un protocole considéré comme fiable(au contraire de Telegram), est compatible multi-OS, libre et permet les appels (au contraire de SMSSecure).
-
Quand je parle « méta-données », c’est tout compris, pas forcément ce qu’il y a DANS les paquets, mais aussi le paquet lui-même, sa date d’arrivée sur GCM, etc. Et là ça pique, une attaque par corrélation (timing attack) et tu arrives à savoir qui communique avec qui (cf dans les commentaires de l’article pour plus de détail). GCM centralise aussi plus fortement les connexions, donc permet de remonter plus facilement à TOUS tes contacts, alors qu’un opérateur autre que le tient n’a accès qu’à tes contacts chez eux.
Pour les mises-à-jour, F-Droid est même plus rapide à déployer que Google Play, puisqu’il n’y a pas de période d’approbation.
Pour la minimisation des fournisseurs push, je suis d’accord. SMSSecure le minimise même au maximum puisqu’il est de 0 (pas besoin de push pour faire du SMS) ! Contre au moins GCM pour TextSecure.
-
Merci du retour. Effectivement, l’utilisation de GCM ajoute Google comme tiers de confiance au niveau des méta-données (mais encore une fois, pas les états ni les opérateurs). Je ne sais pas par contre si GCM est utilisé de manière systématique pour tous les échanges, mais ça ne change pas grand chose.
Pour Google Play, la période d’approbation existe effectivement, c’est très nouveau et non systématique (et assez opaque). Elle reste réduite à quelques heures.
Je pense qu’on est d’accord sur les faits, après la conclusion est différente car les priorité sont différentes: expérience utilisateur, confiance dans les opérateurs locaux vs une entreprise étrangère, etc.
-
-
-
Bon, l'article vient de mozillazine-fr.org, on fait donc de la pub. Mais quand même… L'article n'a aucune information utile… On ne sait pas vraiment où en est vraiment Firefox OS sur TV, quels sont ses avancés, s'il y a des retours utilisateurs, etc etc.
-
-
le peu de vote de la dépêche montre qu'elle n'a pas eu un succès fou :) proposer une dépêche n'est jamais un problème, cela ne lui garantit pas d'apparaître en première page du site, loin de là.
-
-
D’autant plus bizarre que Free supporte openvpn sur sa Freebox. D’autres ont déjà eu des soucis similaire il semble: https://linuxfr.org/forums/linux-android/posts/configuration-openvpn-en-udp-sur-connexion-freemobile (blocage) https://lafibre.info/free-mobile/openvpn-obtimisation-de-debit-en-3g/ (bridage)
En 2014: http://forum.korben.info/topic/25026-aide-openvpn-et-free-mobile-en-itin%C3%A9rance/ (ça viendrait de l’itinérance avec Orange).
-
À noter que pour le tracking Wifi/Bluetooth, Android 6.0 génère désormais une adresse MAC aléatoire lors du scan: http://arstechnica.com/gadgets/2015/10/android-6-0-marshmallow-thoroughly-reviewed/5/ (comme iOS8)
-
Que le logiciel des calculateurs soit libre ne garanti pas que ce soit bien celui dont le code est donné qui tourne sur les véhicules de série.
-
J’élabore: c’est une condition nécessaire, mais pas suffisante. Il faudrait coupler à cela différentes choses: - une revue de code indépendante (souvent long et couteux) - un système de build déterministe libre - un moyen de lire le logiciel installé dans les calculateurs et de le comparer avec ce qu’on a re-généré à partir des sources.
-
-
carlchenet il y a 9 ans | lien | sur : Google commence à punir les utilisateurs d’AdBlock en leur imposant de longues pubs vidéo
De l'eau au moulin : il s'agirait d'un bug dans Chrome (et non donc d'une volonté de Google de punir les utilisateurs de bloqueurs) : à lire sur nextinpact (et merci à Creak via le compte Diaspora* du Journal du hacker)
-
Et quand on lit le détail, il s’agirait d’isoler les extensions entre elles: https://codereview.chromium.org/1267183003 ; ce qui peut être logique d’un point de vue sécurité… Par contre ça empeche adblock d’agir sur les requetes de l’extension YouTube…
-
-
oui heureusement (même setup, copaing :)
-
-
-
-
Mise à jour : une source proche du dossier nous précise que les huissiers avaient en réalité fait un constat sur place chez les abonnés pour vérifier le déploiement des fonctionnalités qui étaient l'objet du litige, sans procéder à l'emport du matériel.
-
ouf, me voilà rassuré :D
-
À noter que ce nom “ESNI” va disparaître au profit d’ECH (“Encrypted Client Hello”), le nouveau nom de la RFC: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/