L’alternative : DIGITEMIS a trouvé 75 milliards US$ pour réconcilier les « Gilets Jaunes » et Bercy, grâce au RGPD

Une des origines du mouvement des « Gilets Jaunes » est l’augmentation des taxes sur les carburants. L’augmentation prévue en janvier 2019 devait rapporter environ 3 milliards d’euros en 2019. Comment combler ce manque à gagner sans de nouveau impacter les contribuables français ?
Et bien une hypothèse serait d’utiliser les sanctions RGPD. Pour rappel, toute entreprise qui manquerait à ses obligations au Règlement européen sur la protection des données personnelles peut se voir infliger des sanctions allant jusqu’à 4% de son chiffre d’affaires mondial. Peu importe le lieu d’établissement de ces entreprises, à partir du moment où elles gèrent des données de résidents européens.
Donc, si l’Etat recherche 3 milliards d’euros, il faut identifier des entreprises ne respectant pas le RGPD qui cumuleraient au moins 120 milliards d’euros de chiffres d’affaires.
Or, le chiffre d’affaires cumulé des 100 plus grandes sociétés (hors secteur financier) cotées au NASDAQ était de 2 191 milliards de $ en 2017. 4% de ce montant représente un peu plus de 75 milliards d’euros. Il y a donc de la marge pour couvrir le manque à gagner de 3 milliards €.
Si cette approche peut paraitre brutale, il faut se souvenir que les banques ont été lourdement sanctionnées depuis 10 ans par les régulateurs. Les sanctions se sont ainsi élevées à plus de 300 milliards $, dont environ 180 milliards $ au profit des régulateurs américains. Les banques européennes ont payé environ 120 milliards $. Les régulateurs européens ne récupérant « que » 20 milliards $. Les 100 milliards $ de différence sont donc partis outre-Atlantique. Un manque à gagner certain sur l’impôt et les taxes payés en Europe par ces banques.
Désormais équipée de son RGPD, l’Union Européenne est en mesure de défendre les données personnelles de ses 500 millions d’habitants en sanctionnant notamment les entreprises non européennes.

Je partage

Derniers articles

Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client

Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?

Lire l'article

Angular, N’Tier et HttpOnly

Avec l’apparition au cours de la décennie 2010 des environnements de travail Javascript de plus en plus puissants, l’architecture N’Tiers, si elle était déjà une norme dans le contexte d’application d’entreprises au cours des années 2000, a pu voir son modèle s’étendre à de nombreuses solutions Web. Ce modèle repose sur l’utilisation de technologies exécutées par le navigateur. Or, il arrive parfois que cette couche doive gérer une partie de l’authentification de l’utilisateur, pourtant une recommandation courante sur l’authentification est qu’elle ne doit jamais être côté client. Aussi, les cookies devraient toujours posséder l’attribut HttpOnly, empêchant leur lecture par une couche Javascript et ce afin d’empêcher tout vol de session lors d’une attaque de type XSS. Pourtant, cet attribut empêche littéralement l’application front-end de travailler avec ces éléments. Comment gérer au mieux ces questions sur ce type de déploiement ?

Lire l'article