(rappel : la seule faute est de ne pas avoir nommé l'auteur).
Vu que c'est une licence NC, il fallait aussi son accord. C'est une contre façon comme une autre. C'est juste beaucoup plus toléré dans le domaine de la photo (mention "Droit Réservé").
C'est nickel chez moi sur un nexus 5 avec écran HD. Tu as quoi comme appareil ?
Samsung S2
On peut mais comme je l'ai dit, c'est inutile. C'est juste les geeks qui râlent. Pour les enfants, il est pas plus mal d'un point de vu pédagogique présenter un clavier dans l'ordre alphabétique pour découvrir les lettres.
C'est pas faux. Mais avoir du mal, c'est frustrant.
Le seul cas intéressant pour les brevets était la protection des emplois en France, dans certain cas.
J'ai eu l'exemple d'une boite française qui faisait des super capacité. Le seul moyen de virer les copies chinoise, était de faire jouer le droit des brevets sur les marchés important (Europe, japon et EU).
Normalement on fait du PreserveAspectCrop sauf cas particulier. C'est sur quelle activité que tu as ce problème ?
Sur "envoie la balle à tux" et penalty, c'est juste flou.
sur "clique et dessine", c'est déformé.
Le fond du menu est moche aussi (flou).
On liste les fontes systèmes plus 2 fontes qu'on embarquent, Andika pour le cursif et Opendyslexic. On laisse la possibilité à l'utilisateur d'installer ses fontes et de les choisir. Dès lors on est bien obligé de les montrer toutes.
Oui, mais le widget de choix ne semble pas aligné. Cela fait bizarre.
De plus, si on prends une taille trop grosse, cela dépasse du cadre, par exemple le nom de la font choisi.
On y a pensé mais c'est trop compliqué de gérer l'implantation 'normale' d'un clavier pour chaque langue. On peut dire que cette activité est plus orienté pour le déchiffrage des lettres et le concept de clavier, pas pour apprendre la frappe.
Vous ne pouvez pas juste prendre les 3 lignes de lettre de chaque clavier ? cela pourrait se faire avec uniquement 3 string par clavier.
J'avais pensé à utiliser un couple de clés PGP échangé lors de la connexion entre les amis celui qui crée le canal de conversation, génère une clé publique/privée qui est envoyé via la clé publique de chaque utilisateur pour chiffré les échanges juste pendant cette conversation (ce qui ne retire pas le fait que si la clé est corrompu, l'envoie de la clé de discussion également) mais on peux penser à un échange de ce couple par un autre canal (mail chiffré ou autre) ce qui permet aussi de convier d'autres personnes à une "conférence" sans échanger avec celles-ci ses propres clés.
C'est différent. La crypto asymétrique est connu pour être moins fiable que la symétrique (genre AES en XTS). Ce que tu proposes est différent, tu propose de refaire un échange de clef asymétrique jetable. Cela doit te donner la propriété de forward secrecy une fois la clef privé jeté. C'est pas mal, je pense.
Fait aussi très attention à tes générateurs aléatoires, toute la sécurité repose dessus. Encore une fois, tu peux faire des couches : 128 bits d'entropie minimum par couche (genre /dev/urandom et une toutouille à toi) et le mélange des couches doit aussi être cryptographique et non un simple XOR (genre sha2). Attention à ne jamais dériver les clefs, tout doit être aléatoire.
de plus ce qui devrait pouvoir être fait, c'est de signer sa clé publique "publique" (qui est stockée dans l'application) avec une clé privée qui n'est JAMAIS publiée (utiliser une fois à chaque renouvellement de clé et stocké dans un coffre derrière un pitbull, ou chez la belle mère).
Du coup lors du changement de clé on peut vérifier celle-ci avec la signature de la clé publique "de référence" dont la clé privée est bien cachée.
Ici, le problème est de faire simple. J'aime bien la propriété qui consiste à dire que l'on peut garantir un réseau si >50% des nœuds du réseau sont fiables. En gros, un noeud compromis ne peut tout compromettre. Dans ton cas, cela reviendrait à partager tes informations.
Regardes les protocoles comme celui proposé dans la dépêche qui utilise git et bittorrent. Celui-ci te garanti contre tout modification (un serveur deviendrait membre d'un réseau et ne serait pas isoler). Tu dois même pouvoir rajouter une couche d'authentification en utilisant le réseau bitcoin.
Si on inclue la clef publique dans tout échange de mail entre 2 personnes, et que si la clef est présente, l'échange continu en crypté ?
Si on veut de la vrai sécurité rien n'empèche de vérifier le finger print après coup. De plus, la NSA devrait modifier à la volé tous les messages qui circulent, cela me parait bien lourd.
Si le fichier est en local, on peut imaginer qu'une faille de sécurité du navigateur serait insuffisant pour attraper le fichier en question à distance. Le principe est toujours d'avoir des couches de sécurité qui sont suffisantes et le plus indépendante possible.
D'ailleurs, vu que le seul moyen d'avoir une discussion en PGP sans man in the middle avec une personne connu, est de vérifier le finger print de la clef depuis un autre canal, tu devrais aussi voir pour utiliser une clef symétrique. Les 2 personnes se débrouillent pour se refiler la clef (un fichier image ?).
* avoir pour chacun la dernière clé publique utilisée.
* la clé publique des amis connus ne devrait changée et n'être acceptée QUE si la nouvelle est chiffrée avec l'ancienne etc…
Attention avec ces gestions de clef complexes, c'est facile que l'utilisateur fasse n'importe quoi. Si la clef est compromise, signer avec l'ancienne clef, ne sert à rien.
J'avais pensé, à utiliser une autre clef privé caché qui signe celle qui est effectivement utilisé. Pour gérer le vol de compte, je pense même crypter cette clef privé avec une clef découpé avec sss ( https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing ) ce morceau de clef étant filé à des amis de confiance. Ceux-ci devraient filer le code si besoin. Je l'avais appelé la fuck-you key :) Car, c'est imparable si tu as des amis prudent. Le but est de gérer une sorte de révocation des clefs publiques proprement. PGP gère des grosses listes de clef révoqué, c'est lourd comme mécanisme.
Tu as regardé cryptocat qui est censé être ce qui se fait de mieux ?
Ton architecture me pose quelques problèmes : la communication de message devrait se faire sans passer par le serveur, c'est maintenant possible sur un navigateur (cf Firefox Hello).
Tu ne semble pas proposer de moyen contre les attaques "man in the middle". Cryptocat utilise le principe de forward secrecy. Cela revient avec PGP à conserver les clef publique de tes correspondants, et comprendre pourquoi une clef change.
La passphrase de protection, en local, c'est un peu "léger". Il faudrait ajouter un secret (128 bits) sauvé dans le navigateur (voir un fichier complet ?). Un mot de passe "d'humain", cela se casse trop facilement.
"L'auteur de GCompris que tu vois sur le Play Store c'est moi ;)"
Le problème est que tu es moins connu que ton logiciel. Si l'auteur était la "fondation GCompris" ou équivalent, cela passerait mieux (cf VLC, firefox,…).
Sinon, une petite remarque, il y a parfois des images qui sont déformés dans l'application. On dirait un "zoom fit", surtout pour les images de fond. C'est vraiment très moche (image étiré et gros pixel carré flou).
Pour une application ludique pour enfant, c'est curieux d'avoir un menu option avec 12 000 fonts disponible. Cela fait un peu, "application pour enfant avec papa geek". Je limiterais le choix, avec peut être une font spécial comme opendyslexic.
Les jeux, avec le clavier en "abcdef", c'est moche de ne pas donner de clavier "azerty", j'ai raté une configuration ? Si c'est pour apprendre un clavier, autant prendre un clavier courant.
les caractéristiques revendiquées sont purement logicielles mais comme le brevet précise que le brevet couvre une machine, il est valable.
Je crois quand même que la seul présence d'un ordinateur pour exécuter le code n'est pas suffisant. Mais il y a d'autres mots magiques pour palier à ça.
Aujourd'hui et compte tenu de ce que j'ai vu dans les négociations auxquelles j'ai participé, je pense que le système des brevets est une fumisterie quel que soit le domaine d'application.
Tu peux développer ?
J'ai vu déjà plusieurs problèmes aux systèmes de brevet :
le brevet sur les découvertes en biologie (gène) qui ne sont pas des inventions,
le système de pool de brevet de constructeur pour mettre une barrière élevée à l'entré d'un marché (dans le prix d'un lecteur de DVD, le gros sont des royalties),
les brevets "champs de mines" : un gros acteur fait ce qu'il veut d'un petit, car le petit viole toujours un brevet du gros et est donc forcé de négocier (sauf patent troll qui ne produit rien).
Le principe d'amélioration du brevet qui permet de contourner un brevet existant, il suffit d'avoir un bon juriste
Le fait de pouvoir breveter n'importe quoi; l'état de l'art n'est pas brevetable, mais 2 choses ensemble de l'état de l'art l'est (ex : pont de résistance en diviseur de tension utilisé comme identifiant de batterie de téléphone portable)
Le fait que les offices n'ont aucun intérêt de refuser un brevet
Les vérifieurs de l'OEB n'ont qu'une demi-journée par brevet
A priori, le système de brevet détourne 15% de la R&D US selon une étude qui doit commencer à dater
Le problème principal concerne les politiques. Pour eux, le nombre de brevet déposé est un indicateur d'innovation ! On peut déposer un brevet, ou des dizaines pour la même chose (il y aurait 150 brevets sur la manière d'attachée le teflon sur un poêle Tefal).
Tant que les politiques seront autant ignare en science, on n'en sortira pas. Je croyais que la France était un pays d'ingénieur, mais c'est faux. La technique, c'est sale pour les élites. Les meilleurs vont dans la finance, ou les postes de direction.
" J'en retiens que le logiciel n'est pas brevetable et que les brevets logiciels demeurent illégaux en Europe."
Tout tient dans le en "tant que tel" ("as such") qui ne veut pas dire grand chose en droit. Ou plus exactement, n'est pas traduit pareil, selon les lois.
L'exemple typique sont les math non brevetables. On ne peut pas mettre de brevet sur une formule de compression. Mais si on lui trouve une application : sauver de la bande passante ou diminuer la taille d'un fichier, paf, brevetable. cf les turbo code.
C'est la théorie des mots magiques. Le droit allemand impose la présence des forces de la nature, au moins c'est clair.
Oui, donc pourquoi dire que c'est différent des US ? Dans les faits, c'est juste que cela ne tiendrait pas en justice. Cela veut dire que si tu as 1 M€ et 3 ans devant toi, tu peux aller contre un brevet. Bon courage.
Tu peux relire les liens que j'ai fournis, cela transparaît… Tu n'étais pas là lors des discussions sur les brevets triviaux (barre de progression et autres genre achat en un clic) ?
Si, j'ai même écrit plusieurs article sur le sujet et j'ai manifesté à Bruxelles.
Si tu es au courant, pourquoi dire qu'il y a une différence entre les US et l'UE sur le sujet ? Les textes sont différents, mais dans les faits, l'OEB s'en fout.
Si on fait une recherche "gcompris" sur la playstore, on tombe sur "Jeu educatif GCompris" avec pour auteur une personne. Difficile de savoir si il s'agit de gcompris, ou d'un clone.
Un bon point pour l'absence de demande d'autorisation, autre que le paiement à l'intérieur de l'application.
Pour cela, il faudrait utiliser des fonctions de l'OS ciblé. Pour être détecté, il "suffirait" que l'OS produise des logs. Dans ton exemple, c'est l'os qui gère les modules. Je pensais plus à des trucs genre hyperviseur.
Mais un malware en mémoire, peut réellement être invisible de l'OS ? J'ai du mal à le croire.
Si il active la moindre défense hardware, le cpu aura un comportement bizarre. Dans trustzone de ARM, il est possible de dérouter les interruptions dans la zone secure, avant de les envoyé vers l'OS. Il est peut être possible d'imiter un comportement normal, un peu comme avec les téchniques de VM x86 ?
Si les cpu peuvent recevoir des updates de microcode, on peut imaginer une manière de faire du masquage par ce moyen-là.
Cela doit être la partie la plus compliqué : Utilisation de la carte réseau (mettre les infos dans le padding parfois présent dans les protocoles), avec un drivers maison, ou usage des fonctionnalités d'un browser.
C'est sûr qu'ils doivent ruser pour ne pas se faire attraper par des firewalls. Ensuite, si les firewall sont des cisco…
Vu que le disque dure dispose d'un firmeware, il y a un cpu dessus. Les ordres de transmission viennent du bus SATA, à lui de renvoyer les données qu'il veut. Il peut donc créer des secteurs défecteux pour y stoquer des informations.
On peut même imaginer qu'il contrôle le boot, et se planque en ring0 ou au équivalent. Je serais curieux de voir si une vérification de la mémoire de ces zones est possible par les OS.
Les reconstructions des clefs RSA par analyse de la consommation existe depuis 10 ans sur les cartes à puces. Ce n'est qu'une version un peu plus évolué ici, qui utilise le son. Les contre mesures sont connu depuis longtemps.
[^] # Re: Sympa
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utilisation de photo sans autorisation. Évalué à 1.
Vu que c'est une licence NC, il fallait aussi son accord. C'est une contre façon comme une autre. C'est juste beaucoup plus toléré dans le domaine de la photo (mention "Droit Réservé").
"La première sécurité est la liberté"
[^] # Re: android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 2.
Samsung S2
C'est pas faux. Mais avoir du mal, c'est frustrant.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 2.
Le seul cas intéressant pour les brevets était la protection des emplois en France, dans certain cas.
J'ai eu l'exemple d'une boite française qui faisait des super capacité. Le seul moyen de virer les copies chinoise, était de faire jouer le droit des brevets sur les marchés important (Europe, japon et EU).
"La première sécurité est la liberté"
[^] # Re: android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 2.
Sur "envoie la balle à tux" et penalty, c'est juste flou.
sur "clique et dessine", c'est déformé.
Le fond du menu est moche aussi (flou).
Oui, mais le widget de choix ne semble pas aligné. Cela fait bizarre.
De plus, si on prends une taille trop grosse, cela dépasse du cadre, par exemple le nom de la font choisi.
Vous ne pouvez pas juste prendre les 3 lignes de lettre de chaque clavier ? cela pourrait se faire avec uniquement 3 string par clavier.
"La première sécurité est la liberté"
[^] # Re: cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 3.
C'est différent. La crypto asymétrique est connu pour être moins fiable que la symétrique (genre AES en XTS). Ce que tu proposes est différent, tu propose de refaire un échange de clef asymétrique jetable. Cela doit te donner la propriété de forward secrecy une fois la clef privé jeté. C'est pas mal, je pense.
Fait aussi très attention à tes générateurs aléatoires, toute la sécurité repose dessus. Encore une fois, tu peux faire des couches : 128 bits d'entropie minimum par couche (genre /dev/urandom et une toutouille à toi) et le mélange des couches doit aussi être cryptographique et non un simple XOR (genre sha2). Attention à ne jamais dériver les clefs, tout doit être aléatoire.
Ici, le problème est de faire simple. J'aime bien la propriété qui consiste à dire que l'on peut garantir un réseau si >50% des nœuds du réseau sont fiables. En gros, un noeud compromis ne peut tout compromettre. Dans ton cas, cela reviendrait à partager tes informations.
Regardes les protocoles comme celui proposé dans la dépêche qui utilise git et bittorrent. Celui-ci te garanti contre tout modification (un serveur deviendrait membre d'un réseau et ne serait pas isoler). Tu dois même pouvoir rajouter une couche d'authentification en utilisant le réseau bitcoin.
"La première sécurité est la liberté"
[^] # Re: Annuaire clés publiques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 2.
Si on inclue la clef publique dans tout échange de mail entre 2 personnes, et que si la clef est présente, l'échange continu en crypté ?
Si on veut de la vrai sécurité rien n'empèche de vérifier le finger print après coup. De plus, la NSA devrait modifier à la volé tous les messages qui circulent, cela me parait bien lourd.
"La première sécurité est la liberté"
[^] # Re: cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 3.
Si le fichier est en local, on peut imaginer qu'une faille de sécurité du navigateur serait insuffisant pour attraper le fichier en question à distance. Le principe est toujours d'avoir des couches de sécurité qui sont suffisantes et le plus indépendante possible.
D'ailleurs, vu que le seul moyen d'avoir une discussion en PGP sans man in the middle avec une personne connu, est de vérifier le finger print de la clef depuis un autre canal, tu devrais aussi voir pour utiliser une clef symétrique. Les 2 personnes se débrouillent pour se refiler la clef (un fichier image ?).
* avoir pour chacun la dernière clé publique utilisée.
* la clé publique des amis connus ne devrait changée et n'être acceptée QUE si la nouvelle est chiffrée avec l'ancienne etc…
Attention avec ces gestions de clef complexes, c'est facile que l'utilisateur fasse n'importe quoi. Si la clef est compromise, signer avec l'ancienne clef, ne sert à rien.
J'avais pensé, à utiliser une autre clef privé caché qui signe celle qui est effectivement utilisé. Pour gérer le vol de compte, je pense même crypter cette clef privé avec une clef découpé avec sss ( https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing ) ce morceau de clef étant filé à des amis de confiance. Ceux-ci devraient filer le code si besoin. Je l'avais appelé la fuck-you key :) Car, c'est imparable si tu as des amis prudent. Le but est de gérer une sorte de révocation des clefs publiques proprement. PGP gère des grosses listes de clef révoqué, c'est lourd comme mécanisme.
"La première sécurité est la liberté"
# cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 6.
Tu as regardé cryptocat qui est censé être ce qui se fait de mieux ?
Ton architecture me pose quelques problèmes : la communication de message devrait se faire sans passer par le serveur, c'est maintenant possible sur un navigateur (cf Firefox Hello).
Tu ne semble pas proposer de moyen contre les attaques "man in the middle". Cryptocat utilise le principe de forward secrecy. Cela revient avec PGP à conserver les clef publique de tes correspondants, et comprendre pourquoi une clef change.
La passphrase de protection, en local, c'est un peu "léger". Il faudrait ajouter un secret (128 bits) sauvé dans le navigateur (voir un fichier complet ?). Un mot de passe "d'humain", cela se casse trop facilement.
"La première sécurité est la liberté"
[^] # Re: android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 4.
Le problème est que tu es moins connu que ton logiciel. Si l'auteur était la "fondation GCompris" ou équivalent, cela passerait mieux (cf VLC, firefox,…).
Sinon, une petite remarque, il y a parfois des images qui sont déformés dans l'application. On dirait un "zoom fit", surtout pour les images de fond. C'est vraiment très moche (image étiré et gros pixel carré flou).
Pour une application ludique pour enfant, c'est curieux d'avoir un menu option avec 12 000 fonts disponible. Cela fait un peu, "application pour enfant avec papa geek". Je limiterais le choix, avec peut être une font spécial comme opendyslexic.
Les jeux, avec le clavier en "abcdef", c'est moche de ne pas donner de clavier "azerty", j'ai raté une configuration ? Si c'est pour apprendre un clavier, autant prendre un clavier courant.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 3. Dernière modification le 27 février 2015 à 09:40.
Je crois quand même que la seul présence d'un ordinateur pour exécuter le code n'est pas suffisant. Mais il y a d'autres mots magiques pour palier à ça.
Tu peux développer ?
J'ai vu déjà plusieurs problèmes aux systèmes de brevet :
Le problème principal concerne les politiques. Pour eux, le nombre de brevet déposé est un indicateur d'innovation ! On peut déposer un brevet, ou des dizaines pour la même chose (il y aurait 150 brevets sur la manière d'attachée le teflon sur un poêle Tefal).
Tant que les politiques seront autant ignare en science, on n'en sortira pas. Je croyais que la France était un pays d'ingénieur, mais c'est faux. La technique, c'est sale pour les élites. Les meilleurs vont dans la finance, ou les postes de direction.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 3.
Tout tient dans le en "tant que tel" ("as such") qui ne veut pas dire grand chose en droit. Ou plus exactement, n'est pas traduit pareil, selon les lois.
L'exemple typique sont les math non brevetables. On ne peut pas mettre de brevet sur une formule de compression. Mais si on lui trouve une application : sauver de la bande passante ou diminuer la taille d'un fichier, paf, brevetable. cf les turbo code.
C'est la théorie des mots magiques. Le droit allemand impose la présence des forces de la nature, au moins c'est clair.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 3.
Je parle pas de 1M€ pour aller en justice de ma manière général. Mais du cout d'un procès autour des brevets.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 2.
Oui, donc pourquoi dire que c'est différent des US ? Dans les faits, c'est juste que cela ne tiendrait pas en justice. Cela veut dire que si tu as 1 M€ et 3 ans devant toi, tu peux aller contre un brevet. Bon courage.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 3.
Si, j'ai même écrit plusieurs article sur le sujet et j'ai manifesté à Bruxelles.
Si tu es au courant, pourquoi dire qu'il y a une différence entre les US et l'UE sur le sujet ? Les textes sont différents, mais dans les faits, l'OEB s'en fout.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 4.
Tu m'expliques dans ce cas comment il peux exister un porte-feuille de brevets sur le mp3 déposés à l'OEB ?
Le mp3 c'est un algorithme mathématique et un format de fichier. Et pourtant, il y a des dizaines de brevet européenne dessus.
"La première sécurité est la liberté"
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
C'est "raw-Text-based protocol" qui n'existe pas.
"La première sécurité est la liberté"
# android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 2.
Si on fait une recherche "gcompris" sur la playstore, on tombe sur "Jeu educatif GCompris" avec pour auteur une personne. Difficile de savoir si il s'agit de gcompris, ou d'un clone.
Un bon point pour l'absence de demande d'autorisation, autre que le paiement à l'intérieur de l'application.
"La première sécurité est la liberté"
[^] # Re: Assis / debout
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Retour d'expérience : bureau assis/debout. Évalué à 2.
Tient, c'est des personnes de Withings, ceux qui font une balance qui marche mal à 150€ (oui,je suis un peu aigri).
"La première sécurité est la liberté"
[^] # Re: Pourquoi s'embêtent-ils ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Effacer le téléchargement d'Internet, Total Wipes a essayé. Évalué à 4.
Ils ne peuvent que contre attaqué en justice pour demande abusive ?
"La première sécurité est la liberté"
[^] # Re: Pourquoi s'embêtent-ils ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Effacer le téléchargement d'Internet, Total Wipes a essayé. Évalué à 8.
Google pourrait aussi dire qu'au delà d'un certain taux d'erreur, de refuser pendant un temps, toutes requêtes en provenance du même organisme.
"La première sécurité est la liberté"
[^] # Re: Question
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De Snowden, Kaspersky, CitizenFour et Gemalto. Évalué à 2.
Pour cela, il faudrait utiliser des fonctions de l'OS ciblé. Pour être détecté, il "suffirait" que l'OS produise des logs. Dans ton exemple, c'est l'os qui gère les modules. Je pensais plus à des trucs genre hyperviseur.
"La première sécurité est la liberté"
[^] # Re: Question
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De Snowden, Kaspersky, CitizenFour et Gemalto. Évalué à 2.
Mais un malware en mémoire, peut réellement être invisible de l'OS ? J'ai du mal à le croire.
Si il active la moindre défense hardware, le cpu aura un comportement bizarre. Dans trustzone de ARM, il est possible de dérouter les interruptions dans la zone secure, avant de les envoyé vers l'OS. Il est peut être possible d'imiter un comportement normal, un peu comme avec les téchniques de VM x86 ?
Si les cpu peuvent recevoir des updates de microcode, on peut imaginer une manière de faire du masquage par ce moyen-là.
"La première sécurité est la liberté"
[^] # Re: Question
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De Snowden, Kaspersky, CitizenFour et Gemalto. Évalué à 3.
Cela doit être la partie la plus compliqué : Utilisation de la carte réseau (mettre les infos dans le padding parfois présent dans les protocoles), avec un drivers maison, ou usage des fonctionnalités d'un browser.
C'est sûr qu'ils doivent ruser pour ne pas se faire attraper par des firewalls. Ensuite, si les firewall sont des cisco…
"La première sécurité est la liberté"
[^] # Re: Question
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De Snowden, Kaspersky, CitizenFour et Gemalto. Évalué à 5.
Quelques hypothèses :
Vu que le disque dure dispose d'un firmeware, il y a un cpu dessus. Les ordres de transmission viennent du bus SATA, à lui de renvoyer les données qu'il veut. Il peut donc créer des secteurs défecteux pour y stoquer des informations.
On peut même imaginer qu'il contrôle le boot, et se planque en ring0 ou au équivalent. Je serais curieux de voir si une vérification de la mémoire de ces zones est possible par les OS.
"La première sécurité est la liberté"
[^] # Re: À propos des clefs RSA
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Pour plus de sécurité au bureau, évitez les chips (ou alors, chuchotez) !. Évalué à 3.
Les reconstructions des clefs RSA par analyse de la consommation existe depuis 10 ans sur les cartes à puces. Ce n'est qu'une version un peu plus évolué ici, qui utilise le son. Les contre mesures sont connu depuis longtemps.
"La première sécurité est la liberté"