Les DRM sont généralements des binaires avec lesquels on ne peu pas travailler car on ne comprend pas leur fonctionnement en tant qu'ingénieur.
Dans l'esprit, on veut verrouiller l'accès à un contenu.
Dans la pratique on rajoute parfois même une couche de colle opaque pour ne pas rétro-ingénieriés les hardware (les bios par exemple).
C'est pour rassurer les marchés et leur partenaires commerciaux sur l'utilisation des données : on appel cela le secret industriel, d'autres l'intelligence collective car c'est un pan de mur d'une politique globale et pour eux ca fonctionne.
Dans une démarche d'open data on n'a pas forcément d’intérêt à publier la donnée brute (raw) et on veut parfois contrôler sa diffusion et sa revalorisation. Alors on peu créer une DRM mais si elle est trop complexe elle peu faire du tord à ces données, en faisant cela on s'éloigne des démarches comme celle que l'on voit fleurir actuellement.
En France on a clairement une politique de développement de l'open data, il y a eu deux étapes pour le développement :
- Publication d'une partie des data brutes (raw) de l'état sans restrictions
- Exploitation des données de contenus artistiques sous licence libre par les différents ministères mais aussi par des organismes privés (détournements)
Cette politique fait du tord aux entreprises dont le modèle économique est propriétaire car ils ne savent pas travailler de cette manière et devront s'adapter. Parfois cela signifie mourir car cela coûte trop cher c'est pour cela que l'on doit assister cette filière lorsqu'elle devient déficitière
En passant j'ajouterai que les données brutes sont de plus en plus riches ou alors se sont les site d'open data qui publient de plus en plus leurs contenus valorisés.
Pour ma part ma démarche concerne un accès telnet sur un 'terminal' d'une borne sur laquelle devait transiter des méta-données d'une base alimentaire pour un organisme social de restauration. (le projet est en stand-by) J'avais peur que si un jour je veux distribuer mon programme il ne mette en danger la sécurité des utilisateurs et de leurs données (je voulais en tirer un profit monétaire), alors j'ai un peu obfusqué le code en essayant de le rendre moins lisible.
Mais il ne faut jamais faire cela. Il faut une pratique de l'internet pondéré et réfléchie avec un écosystème ouvert où le fonctionnement de la machine entière est publié et documenté dans le but de garder le contrôle sur les données et leur partage et non pas dans le but de se protéger en première instance.
La clé on la duplique et on la confie à un tiers et on documente les procédures de connexion que l'on ne base pas sur un DRM contrairement au QG de James Bond et cela même si on est attaqué par la police des polices.
Je vous rassure pour le moment je n'utilise pas cet algorithme révolutionnaire car il est très lent dans sa forme actuelle, je pense qu'il va muter. Ce serait amusant de comparer le code à travers différents portages dans d'autres langages et faire des benchmarks en plus c'est tendance.
# En gros
Posté par n0wic . En réponse au message Comment j'ai fabriqué un DRM pour la gestion de mon password.. Évalué à -10.
Les DRM sont généralements des binaires avec lesquels on ne peu pas travailler car on ne comprend pas leur fonctionnement en tant qu'ingénieur.
Dans l'esprit, on veut verrouiller l'accès à un contenu.
Dans la pratique on rajoute parfois même une couche de colle opaque pour ne pas rétro-ingénieriés les hardware (les bios par exemple).
C'est pour rassurer les marchés et leur partenaires commerciaux sur l'utilisation des données : on appel cela le secret industriel, d'autres l'intelligence collective car c'est un pan de mur d'une politique globale et pour eux ca fonctionne.
Dans une démarche d'open data on n'a pas forcément d’intérêt à publier la donnée brute (raw) et on veut parfois contrôler sa diffusion et sa revalorisation. Alors on peu créer une DRM mais si elle est trop complexe elle peu faire du tord à ces données, en faisant cela on s'éloigne des démarches comme celle que l'on voit fleurir actuellement.
En France on a clairement une politique de développement de l'open data, il y a eu deux étapes pour le développement :
- Publication d'une partie des data brutes (raw) de l'état sans restrictions
- Exploitation des données de contenus artistiques sous licence libre par les différents ministères mais aussi par des organismes privés (détournements)
Cette politique fait du tord aux entreprises dont le modèle économique est propriétaire car ils ne savent pas travailler de cette manière et devront s'adapter. Parfois cela signifie mourir car cela coûte trop cher c'est pour cela que l'on doit assister cette filière lorsqu'elle devient déficitière
En passant j'ajouterai que les données brutes sont de plus en plus riches ou alors se sont les site d'open data qui publient de plus en plus leurs contenus valorisés.
Pour ma part ma démarche concerne un accès telnet sur un 'terminal' d'une borne sur laquelle devait transiter des méta-données d'une base alimentaire pour un organisme social de restauration. (le projet est en stand-by) J'avais peur que si un jour je veux distribuer mon programme il ne mette en danger la sécurité des utilisateurs et de leurs données (je voulais en tirer un profit monétaire), alors j'ai un peu obfusqué le code en essayant de le rendre moins lisible.
Mais il ne faut jamais faire cela. Il faut une pratique de l'internet pondéré et réfléchie avec un écosystème ouvert où le fonctionnement de la machine entière est publié et documenté dans le but de garder le contrôle sur les données et leur partage et non pas dans le but de se protéger en première instance.
La clé on la duplique et on la confie à un tiers et on documente les procédures de connexion que l'on ne base pas sur un DRM contrairement au QG de James Bond et cela même si on est attaqué par la police des polices.
Je vous rassure pour le moment je n'utilise pas cet algorithme révolutionnaire car il est très lent dans sa forme actuelle, je pense qu'il va muter. Ce serait amusant de comparer le code à travers différents portages dans d'autres langages et faire des benchmarks en plus c'est tendance.