Ben, toute la problématique évoquées dans l'interview porte sur des mesures de sécurité visant à protéger la vie privée… Donc dans le compromis, la sécurité, c'est la vie privée.
Dès le début de l'entretien, je ne suis pas d'accord avec l'approche:
il faut séparer deux aspects. Il y a d’une part la fonctionnalité et d’autre part il y a la sécurité. Si on ne se préoccupe pas de sécurité, on peut concevoir des systèmes qui ont les fonctionnalités qu’on souhaite.
Une voiture qui ne tient pas la route, un site qui partage nos données avec la terre entière ou une maison sans porte… Il suffit de réfléchir un peu pour trouver des milliers d'exemple où la sécurité fait partie des fonctionnalités ;-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Et visiblement tu n'as pas été plus loin. Sinon tu aurais compris ce propos liminaire.
La problématique est d'avoir des fonctionnalités pour exploiter des données (requêtes, simples recherches) chifrées par sécurité.
Si les données ne sont pas chiffrées, on peut envisager toutes les fonctionnalités. Si elles le sont, sans que le serveur puisse les déchifrer il devient très difficile de proposer des fonctionnalités de base comme une simple recherche.
Bof … on parle aujourd'hui de sécurité by design, tout simplement parce que l'approche "on fait la fonctionnalité et on sécurise après" ne marche pas et laisse plein de trous béants dans les applis.
Aujourd'hui si tu ne conçois pas avec l'objectif de sécurité dès le début, tu te retrouvera savec des pressions énormes de la part de non techniques qui te demanderont de bâcler cet aspect. A moins d'avoir un DSI qui a conscience des enjeux de sécurité, tu es a 90% sur de mettre en place un système peu sécurisé.
Certes. Mais ce n'est pas du tout ce dont il est question dans l'entretien mis en lien. C'est bien pourquoi je me suis permis de signaler au commentateur qu'il n'avait pas dû en lire l'intégralité.
# TL;DR
Posté par Xanatos . Évalué à -2.
Et c'est reparti… Jamais de
confidentialitévie privée dans l'équation.[^] # Re: TL;DR
Posté par aiolos . Évalué à 6.
Ben, toute la problématique évoquées dans l'interview porte sur des mesures de sécurité visant à protéger la vie privée… Donc dans le compromis, la sécurité, c'est la vie privée.
# Prémisse
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Dès le début de l'entretien, je ne suis pas d'accord avec l'approche:
Une voiture qui ne tient pas la route, un site qui partage nos données avec la terre entière ou une maison sans porte… Il suffit de réfléchir un peu pour trouver des milliers d'exemple où la sécurité fait partie des fonctionnalités ;-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Prémisse
Posté par Voltairine . Évalué à 0.
Et visiblement tu n'as pas été plus loin. Sinon tu aurais compris ce propos liminaire.
La problématique est d'avoir des fonctionnalités pour exploiter des données (requêtes, simples recherches) chifrées par sécurité.
Si les données ne sont pas chiffrées, on peut envisager toutes les fonctionnalités. Si elles le sont, sans que le serveur puisse les déchifrer il devient très difficile de proposer des fonctionnalités de base comme une simple recherche.
[^] # Re: Prémisse
Posté par totof2000 . Évalué à 3.
Bof … on parle aujourd'hui de sécurité by design, tout simplement parce que l'approche "on fait la fonctionnalité et on sécurise après" ne marche pas et laisse plein de trous béants dans les applis.
Aujourd'hui si tu ne conçois pas avec l'objectif de sécurité dès le début, tu te retrouvera savec des pressions énormes de la part de non techniques qui te demanderont de bâcler cet aspect. A moins d'avoir un DSI qui a conscience des enjeux de sécurité, tu es a 90% sur de mettre en place un système peu sécurisé.
[^] # Re: Prémisse
Posté par Voltairine . Évalué à 1.
Certes. Mais ce n'est pas du tout ce dont il est question dans l'entretien mis en lien. C'est bien pourquoi je me suis permis de signaler au commentateur qu'il n'avait pas dû en lire l'intégralité.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.