Archive for the ‘web’ Category

Amazon propose un webservice de base de données simplifiée que se nomme SimpleDB, qui permet de stocker n’importe quelle information dans une base de données dans les nuages.

SimpleDB : base de données simplifiée

A l’opposé des bases de données relationnelles, SimpleDB propose juste de stocker des informations hétérogène dans une même table.

Si on devait faire un rapprochement avec les bases du type MySQL, ce serait celui-ci :

  • Amazon vous met à disposition plusieurs bases : en fait, ces bases sont les différentes régions pour lesquelles le service est disponible (Asie, Europe, East-US, …).
  • Dans cette base, vous pouvez créer jusqu’à 250 tables, appelés domain.

Au niveau des données, le système est un peu déroutant au début : pour stocker un objet, vous lui donnez un nom (Name) et ensuite une liste de paires clé/valeur (Attributes). Vous pouvez même donner plusieurs valeurs à un même attribut pour un seul objet.

Exemple de données

Considérons donc une liste de personnes, de dates de naissance et de diplômes : on pourra donc stocker des informations selon le schéma suivant :

  • Name => Jean, Attributes => { Age => 16, Diplome => Brevet des collèges }
  • Name => Paul, Attributes => { Age => 19, Diplome => { Brevet des collèges, Baccalauréat } }

SimpleDB et Select

La base de données est simplifiée à la fois au niveau de son format, mais aussi du select : on ne peut pas tout faire, notamment à cause de la structure du stockage.

Format des données

Les données n’ont pas vraiment de format. Elles sont stockées sous forme de chaine de caractère. Vous pouvez cependant continuer à stocker des données au format binaire sans soucis.

Comparaison

C’est là que les choses se compliquent (hélas !). La comparaison se fait selon le type d’objet que l’on compare, et dans notre cas SimpleDB va comparer des chaînes de caractères. C’est donc l’ordre lexicographique qui est de rigueur (équivalent de strcmp en ASCII).

Il faut donc formater ses données si l’on souhaite effectuer des comparaisons du type inférieur < / supérieur > :

  • Chaînes de caractères : pas de soucis ! 🙂
  • Nombres :
    • il faut qu’ils soient tous positifs – en rajoutant un offset (car l’ordre lexicographique ne pourra pas interprêter que -5 < -3, car pour lui ce serait équivalent ) 5 < 3 !). Pour cela, il faut ajouter un nombre à toutes les valeurs. Ce nombre doit être plus grand que la valeur absolue du plus petit nombre que l’on va rencontrer. Concrètement, si on stocke des nombres entre -1000 et 10000, on peut rajouter 1000 à tous les nombres stockés, et on aura des nombres entre 0 et 11000.
    • mais aussi faire du zero-padding, c’est à dire faire précéder les nombres que l’on enregistre par des zéros, car sinon on aurait 5 > 10 dans l’ordre lexicographique. Il faut donc que, au sens des chaines de caractères, les nombres fassent tous la même taille. Dans notre exemple précédent, il faut qu’ils fassent tous 5 caractères, pour avoir 00005 < 00010.
  • Dates : on peut utiliser un format timestamp, mais ce n’est pas recommandé car on a à la fois un format illisible, et en plus on tombe dans le cas des nombres. On peut utiliser des formats type MySQL ou ISO8601 qui respectent ceci : d’abord les années, puis les mois, les jours, les heures, les secondes, et tous le même timezone (par exemple +02:00 ou bien stocker en GMT) si l’on souhaite avoir cette précision. Exemple : 2011-11-30 10:00:00 < 2013-01-01 00:00:00.

SimpleDB Group By

Si vous avez besoin du group by ou des fonctions d’aggrégation qui vont avec (avg, sum, …), alors passez votre chemin : SimpleDB ne propose d’aggrégation. La seule fonction disponible dans ce registre est count().

Performances et temps réel

Les performances ne sont pas forcément au rendez-vous : je n’ai testé que des inserts simples dans une base quasiment vide, et les performances ne sont pas terribles : 500ms pour une insertion simple, 200ms si vous appelez votre script depuis une instance de serveur chez Amazon (EC2).

Par ailleurs, si vous avez besoin de l’information tout de suite après, SimpleDB n’est pas pour vous. Il peut se passer plusieurs secondes entre le moment ou vous faites une modification et le moment ou celle-ci est répliquée sur tous les serveurs : SimpleDB va donc vous retourner un résultat non modifié si votre appel suit de trop près.

AWS SimpleDB pour quelle utilisation ?

SimpleDB n’est donc pas fait pour toutes les utilisations, loin de là ! Mais on peut trouver des cas où SimpleDB se révèle être un bon choix : prix, taille du stockage, disponibilité (pas de problèmes serveur ou machine à gérer), redondance…

Il y a beaucoup de contraintes, comme on a pu le voir, et celles-ci ne sont pas toutes listées… Mais je trouve quand même ce système bien utile dans certains cas, notamment pour tout ce qui est log system : en effet, en général on stocke une information mais on n’en a pas besoin immédiatement, les requêtes se font sur des sous-ensembles bien déterminés. En plus, on peut stocker des attributs complètement hétérogènes dans la même base de données selon le type d’évènement que l’on désire logguer.

Aller plus loin

Référence Amazon AWS SimpleDB

Introduction

Il y a en général besoin de 3 fichiers différents avec SSL : une clé privée pour le serveur (key ou pem), un certificat (cer ou crt) distribué au client pour le chiffrement SSL, et la chaine de confiance (chain ou txt)  qui consiste en une suite de certificats tous signés les uns par les autres, et qui permet ensuite de remonter à un certificat racine installé sur votre ordinateur.

Le script que je vous propose permet de vérifier si un certificat serveur SSL est valide, c’est à dire :

  • de vérifier que la clé privée correspond bien au certificat ;
  • de vérifier que la chaine de confiance est valide.

Fonctionnement du script

Pour vérifier votre domain example.com, il vous faudra les 3 fichiers mentionnés plus haut, c’est à dire :

  • example.com.key : la clé privée
  • example.com.cer : le certificat
  • example.com.chain.txt : la chaine de confiance

Le script va vérifier que la clé et le certificat ont la même signature (avec l’argument -modulus de openssl), et vérifier le certificat avec la commande openssl verify.

 Le script

  1. #!/bin/sh
  2.  
  3. DOMAIN="$1"
  4.  
  5. [ -z "$DOMAIN" ];
  6.   "Usage : "$( "$0")" domain" >&2
  7.   "  Will check if \$domain.key, \$domain.cer and \$domain.chain.txt are correct" >&2
  8.   1
  9.  
  10. # Check key and certificate modulus
  11. KEY_MOD=$(openssl rsa  -noout -modulus - ${DOMAIN}.key | openssl md5)
  12. CER_MOD=$(openssl x509 -noout -modulus - ${DOMAIN}.cer | openssl md5)
  13.  
  14. [ "${KEY_MOD}" != "${CER_MOD}" ];
  15.   "Error : key does not match certificate" >&2
  16.   2
  17.  
  18. # Check certificate consistency
  19. openssl verify -CApath /etc/ssl/certs -CAfile ${DOMAIN}.chain.txt ${DOMAIN}.cer | -q "^${DOMAIN}.cer: OK$"
  20. [ $? -ne 0 ];
  21.   openssl verify -CApath /etc/ssl/certs -CAfile ${DOMAIN}.chain.txt ${DOMAIN}.cer >&2
  22.   "Error while verifying certificate chain" >&2
  23.   3
  24.  
  25. "Success"
  26. 0
  27.  

Télécharger le script

Les développeurs HTML le savent bien : impossible de faire des styles uniformes sous tous les navigateurs ! Chacun a ses particularités : chrome et ses webkit-, safari qui n’en met pas et firefox qui -moz ifie un peu tout… et IE qui ne fait rien !

La solution pour IE : PIE.htc

La solution proposée ici a été développée pour supporter le CSS 3 sur Internet Explorer. Pour ce faire, on utilise une particularité CSS de Internet Explorer pour exécuter du JavaScript, qui va recréer le style CSS 3.

Voir la démo sur css3pie.com

Mise en place

Il suffit de rajouter une ligne CSS au style des éléments qui ont du CSS3.

  1. <style type="text/css">
  2. .rounded-corner5
  3. {
  4.   -webkit-border-radius: 5px; /* Chrome */
  5.   border-radius: 5px; /* CSS3 */
  6.   -moz-border-radius: 5px; /* Mozilla */
  7.   behavior: url(PIE.htc); /* Internet Explorer */
  8. }
  9. </style>

Exemple d’utilisation

Ceci est un div en exemple, avec des bords arrondis

Dépannage : quelques règles à respecter tout de même…

Il y a principalement deux problèmes qui peuvent être rencontrés :

  1. Mime-type : par défaut sous linux, le fichier .htc est reconnu comme étant du type text/html, mais doit être du type text/x-component pour que ça fonctionne. Plusieurs solutions, en fonction de ce que vous pouvez faire : modifier la configuration du serveur /etc/mime.types pour rajouter ce champ, rajouter la ligne AddType text/x-component .htc à votre configuration apache ou .htaccess, ou enfin créer un fichier de script du type PHP en utilisant le code header('Content-type: text/x-component') pour spécifier le type contenu.
  2. Domaine, répertoire et droits : le CSS ne va fonctionner que si le fichier .htc est sur le même domaine que le site qui sert le HTML : impossible donc d’utiliser la traditionnelle et non moins nécessaire segmentation des contenus dynamiques/statiques. Du coup, les rendu CSS3 utilisant des url() risquent d’être mal considérées si le chemin est relatif.

English version : CSS3 for Internet Explorer with PIE.htc

Les développeurs le savent bien : comment faire marcher son site sur les autres navigateurs relève à la fois du casse-tête et de la patience : le casse-tête de faire des feuilles de styles compatibles, et la patience pour avoir un environnement permettant de tester tout ça…

IETester

IETester est un logiciel qui vous permet de tester votre site internet sous les différentes versions d’Internet Explorer : IE5.5, IE6, IE6, IE8, IE9, IE10…

Le principe est simple : vous avez des onglets qui vont appeler les différents moteurs de rendus des précédentes versions de IE.

Cerise sur le gâteau : des outils de développements

Non content de fournir déjà ce premier service, IETester englobe aussi des outils de développement : la possibilité de voir le code HTML interprété, mais aussi le style interprété (par le parser IE, pas par IE lui-même !), un DOM explorer…

Par ailleurs, le logiciel dispose aussi de boutons raccourcis bien pratique, comme le rechargement d’une page sans l’utilisation du cache.

Limites : les extensions

Malheureusement – et ce n’est pas du tout un reproche tellement la problématique est différente et complexe – ceci n’est pas une solution pour tester ses extensions sous les différentes version de IE, et ce pour plusieurs raisons :

  • IETester n’utilise que le moteur de rendu, donc il n’est pas possible d’ajouter des interfaces (boutons, toolbar, …) ou des BHO a fortiori ;
  • les extensions doivent aussi être testées sous les différentes version de windows et différents environnements : XP, Vista, 7 sous différents SP, mais aussi en mode de confidentialité ou non.

Pour ça, je crois que la seule solution est d’utiliser des Virtual Machines conjointement avec des Snapshots.

Voici un petit moyen de tester si un certificat ssl est valide, et s’il le restera encore pendant un certain temps…

Openssl s_client et openssl x509

Openssl donne deux outils qui vont nous servir.

1. Le premier permet de se connecter à un serveur pour envoyer des requêtes

openssl s_client -connect www.openssl.org:443

Cette commande va se connecter au server www.openssl.org sur le port 443 en utilisant le protocole SSL. Vous pourrez ensuite communiquer avec le serveur en HTTP :

GET / HTTP/1.0
Host : www.openssl.org

et le serveur va vous renvoyer la page. On peut aussi utiliser cette technique sur d’autres ports et d’autres protocoles, comme pour le SMTPs, le POPs, etc.

2. Le deuxième permet d’avoir des informations sur le certificat : est-il valide ? Quelle est sa date d’expiration ? Il suffit de piper la première commande avec la deuxième :

echo | openssl s_client -connect www.openssl.org:443 | openssl x509 -noout -enddate

Quelques astuces avec openssl

  • Si openssl vous sort qu’un certificat dans la chaîne n’est pas valide, donnez-lui le chemin vers le dossier contenant les certificats racines, par exemple -CApath /etc/ssl/certs
  • Si vous voulez éviter d’avoir les erreurs de la première commande en sortie, envoyez-les vers /dev/null : openssl s_client -connect www.openssl.org:443 2> /dev/null
  • Si vous voulez connaitres les différentes options de openssl s_client ou de openssl x509, essayez man ssl-s_client ou man ssl-x509

Petit bonus : le script PHP qui teste si un certificat expire bientôt

  1. $args = 'www.openssl.org:443';
  2. $command =
  3.   'date +%s -d "$(LANG=C openssl s_client -connect '
  4.   .escapeshellarg($args)
  5.   .' -CApath /etc/ssl/certs/ < /dev/null 2>/dev/null | openssl x509 -noout -text -enddate | tail -n1 | cut -d= -f2)"';
  6.  
  7. exec($command, $output);
  8.  
  9. $time = array_shift($output);
  10. if(!is_numeric($time) || $time == 0)
  11. {
  12.   // Erreur : impossible de tester la validité du certificat : pourquoi ?
  13. }
  14. else
  15. {
  16.   // On va avoir le nombre de jour restant
  17.   $nDaysLeft = floor(($time - time())/86400);
  18. }
  19.  

Articles sources

Tester la date de fin d’un certificat : http://www.brandonhutchinson.com/When_does_my_certificate_expire%3F.html
Tester la validité du certificat avec les certificats racines : http://stackoverflow.com/questions/4103472/ssl-handshake-fails-with-a-verisign-chain-certificate-that-contains-two-ca-si

Voici un cas pratique d’une fonctionnalité bien utile de Firefox : exécuter un code Javascript prédéfini sur une page web donnée.

Lorsque l’on va sur les sites iPhone avec Firefox (pourquoi faire ???), la barre de scroll n’est pas affichée. Il existe pourtant un moyen tout simple de l’afficher :

  • Créez un raccourci (bookmark) dans vos marques pages (sur la barre de marques-page personnelle, c’est encore mieux !) : « Marque-pages », « Organiser… » puis créez un raccourci (vous pouvez aussi faire un clic-droit sur la barre personnelle, puis « Nouveau marque-page ») ;
  • Nom : mettez ce que vous voulez ;
  • Adresse : mettez le code suivant : javascript:document.body.style.overflow="auto";(function(){})() ;
  • Ensuite, rendez-vous sur une page sans scrollbar, par exemple le portail sport de Orange pour mobile : http://sports.iphone.m.orange.fr/, et cliquez sur votre favori !

Astuce supplémentaire : utiliser un mot-clé pour les favoris

Pour appeler un favori directement depuis la barre d’adresse (sans avoir à chercher dans vos favoris), attribuez un mot-clé à votre marque page. Il suffit alors de taper le mot clé dans la barre d’adresse pour accéder à la page.

Par exemple, dans notre cas, tapez « M » comme mot-clé pour ce marque page. Rendez-vous sur la page, puis tapez « M » dans la barre d’adresse.

javascript:document.body.style.overflow= »auto »;(function(){})()

HSTS est (et j’adore ce genre de formule auxquelles on ne comprend rien) une norme qui permet de sécuriser l’accès aux sites sécurisés. HSTS signifie HTTP Strict Transport Security (précédemment nommé STS).

Limites actuelles

Aujourd’hui, le protocole HTTPS (HTTP sécurisé) est très robuste. Les principales failles de sécurité proviennent non pas du protocole de sécurisation en lui-même, mais plutôt du phishing, c’est-à-dire de l’identité réelle du site que vous visitez. Vous pouvez très bien aller sur le site par exemple de lcl.fr, mais en réalité vous êtes sur le site de lc1.fr. Pas forcément évident de faire la différence entre les deux au premier coup d’oeil.

Autre problème : vous vous connectez à un réseau wifi gratuit, et alors que vous pensez vous connecter sur le site de lcl.fr, vous êtes en réalité sur une copie de ce site, et c’est le serveur DNS (qui associe une IP à lcl.fr) qui vous trompe. Le certificat de sécurité, en revanche n’est pas valide, mais vous avez l’habitude que ça arrive sur Internet…

La solution proposée

En fait, cette solution n’est pas miraculeuse. Elle permet deux choses :

  1. Si j’arrive sur le site de ma banque, alors je suis obligatoirement en HTTPS. Cela évite les attaques qui consisteraient à y changer les liens en des liens vers un autre site avec une adresse similaire et un certificat valide.
  2. Si quelqu’un cherche à se faire passer pour ma banque et que je suis un abruti qui accepterait un certificat non valide, alors je suis protégé, car le certificat sera automatiquement refusé par mon navigateur.

Mise en place

Un site se déclare HSTS par deux manières différentes :

  • soit il fournit un header HTTP nommé Strict-Transport-Security, qui contient pour combien de temps et sur quelles parties du site appliquer HSTS  (exemple : Strict-Transport-Security: max-age=16070400; includeSubDomains) ;
  • soit il se déclare comme tel auprès des navigateurs (ou bientôt d’une autorité ?). Cette solution permet d’éviter de se faire avoir lors de la première connexion au site internet avec un navigateur tout neuf.

Une fois qu’un site est considéré comme HSTS par le navigateur :

  • Aucune connexion en HTTP non sécurisé ne sera faite. Tout passera directement par HTTPS. Les URL en HTTP (quand vous les tapez vous-même, ou bien à partir de lien trouvés sur des sites) seront automatiquement converties en HTTPS.
  • Si la liaison HTTPS contient une erreur (certificat auto-signé, ou non valide sur le domaine, …) alors la connexion sera automatiquement interrompue et aucune donnée ne sera transmise au site distant.

Conclusion

C’est une bonne couche de sécurité supplémentaire qui va être ajoutée, et qui va permettre d’éviter pas mal d’usurpation d’identité de site Internet. Internet n’est pas un monde magique où tout est rose, et il reste très important de sensibiliser les internautes aux problèmes de sécurité sur Internet, car malheureusement, une telle solution ne permet pas de protéger contre toutes les attaques.

Actuellement, Chrome 6 et Firefox 4 ont adopté la norme.

Sources : Strict Transport Security chez Chrome, la dépêche linuxfr.org sur HSTS dans Firefox

Le CSS évolue. Une des principales innovations dans ce standard est l’ajout des animations. En voici un aperçu.

Démo : opacité et rotation

Un peu de code

Principe de fonctionnement

Le principe des animations est simple :

  1. Vous ajouter des styles à vos objets : style normal, et style modifié sur un évènement, par exemple avec :hover. Par exemple, on définit opacity: 0.5; dans le cas normal et opacity: 1; dans le :hover.
  2. On rajoute un style normal qui s’intitule -webkit-transition et dans lequel on va programmer la transition : type de propriété à animer, courbe de vitesse. Par exemple, si on veut animer l’opacité avec une vitesse rapide, en rendant l’arrêt plus fluide : -webkit-transition: -webkit-transform 1000ms ease-out 40ms ;

Source de l’exemple

  1. <style>
  2. .p416_animated {
  3.    opacity:.5;
  4.   -webkit-transition: -webkit-transform 1000ms ease-out 40ms, opacity 1000ms ease-out 40ms;
  5.   -moz-transition: -moz-transform 1000ms ease-out 40ms, opacity 1000ms ease-out 40ms;
  6. }
  7. .p416_animated:hover {
  8.   opacity:1;
  9.   -webkit-transform: rotate(360deg);
  10.   -moz-transform: rotate(360deg);
  11. }
  12. </style>
  13.  
  14. <img decoding="async" class="p416_animated" src="http://blog.cyril.me/wp-content/uploads/2010/09/firefox-150x150.png" alt="" />

Compatibilité

Le grand problème des évolutions de langage, c’est qu’il faut attendre l’évolution des navigateurs. Parmi les navigateurs compatibles disponibles à ce jour, nous avons Firefox 4, Chrome et Safari.

Cependant, le manque de compatibilité, dans certains cas (opacité par exemple), ne rendra pas votre site incompatible, mais seulement moins fini.

Pour aller plus loin : la référence du w3 sur les transitions CSS3.

Aujourd’hui, j’ai cherché à injecter du code dans une page HTML depuis une extension Firefox. Ca permet de définir des objects dans le scope de la fenêtre, qui seront ensuite accessibles depuis le code javascript de la page. J’ai aussi cherché à communiquer dans l’autre sens : appeler des fonctions de mon extension depuis la page web.

Injection de script dans une page Web

L’injection se passe en deux étapes :

  1. Il faut savoir sur quelle page intervenir : on peut donc se binder sur l’évènement DOMContentLoaded du navigateur ;
  2. Il faut ensuite injecter le code à proprement parler, et qu’il soit visible.

Etape 1

Voici le code commenté (à inclure dans browser.xul) :

  1. var Injector =
  2. {
  3.   init: function()
  4.   {
  5.     var appcontent = document.getElementById('appcontent'); // On récupère le navigateur
  6.     if(appcontent) // On se bind sur le bon évènement
  7.       appcontent.addEventListener('DOMContentLoaded', Injector.onPageLoaded, true);
  8.   },
  9.  
  10.   onPageLoaded: function(aEvent)
  11.   {
  12.     if(aEvent.target instanceOf HTMLDocument) // Si on est sur un document HTML
  13.     {
  14.       var doc = aEvent.originalTarget; // Voici le HTMLDocument
  15.       var win = doc.defaultView; // Voici la DOMWindow
  16.     }
  17.   }
  18. }

2. Injection de code

Et voici comment injecter :

  1. /**
  2.  * Permet d'injecter du javascript dans une page
  3.  * @param win DOMWindow La fenêtre dans laquelle injecter le script
  4.  * @param id string Un id unique pour identifier le script
  5.  * @param src string Le code source
  6.  * @param [optional] boolean bRemove Vrai si on veut enlever le script de la page après son inclusion
  7. */
  8. Injector.addScript = function(win, id, src, bRemove)
  9. {
  10.   // On crée un élément script
  11.   var element = win.document.createElementNS('http://www.w3.org/1999/xhtml', 'html:script');
  12.   element.setAttribute('type', 'text/javascript');
  13.   element.setAttribute('id', id);
  14.   element.innerHTML = src;
  15.  
  16.   // Et on l'ajoute !
  17.   win.document.documentElement.appendChild(element);
  18.   // On supprime l'élément si demandé
  19.   if(bRemove) element.parentNode.removeChild(element);
  20. }

Communiquer avec un script qui tourne dans le browser.xul

Communiquer dans l’autre sens a des intérêts : ça permet d’accéder à des fonctions plus avancée (accès à toutes les librairies XPCOM !).

La méthode est plutôt simple : on crée un élément dans le HTMLDocument (utile pour faire passer des données, en utilisant des attributs auxquels on aura ensuite accès), et on envoie alors un évènement personnalisé, sur lequel écoute notre Injector.

1. Ecoute des évènements de la page

On modifie le onPageLoad pour rajouter le bind sur les évènements, que l’on va ensuite traiter avec la méthode onEvent :

  1. [...]
  2. doc.addEventListener('injector-event', Injector.onEvent, false, true);
  3. [...]
  4.  
  5. Injector.onEvent = function(aEvent)
  6. {
  7.   // On peut récupérer l'élément sur lequel a été passé l'évènement
  8.   var element = aEvent.target;
  9.   // Et le document associé
  10.   var doc = element.ownerDocument;
  11.   // Faites ensuite ce que vous voulez. Vous pouvez utiliser la méthode element.getAttribute pour récupérer d'éventuels arguments, éventuellement encodés avec JSON.stringify puis décodés avec JSON.parse
  12. }

2. Envoi d’un évènement

Et voici le code à mettre dans votre page HTML :

  1. // Creation de l'évènement
  2. var ev = document.createEvent('Events');
  3. ev.initEvent('injector-event', true, false);
  4. // On utilise documentElement pour envoyer le message. Vous pouvez utiliser un élément personnalisé, n'importe où dans le code
  5. document.documentElement.dispatchEvent(ev);

Bibliographie

  • Le code source de Firebug pour l’injection de code.
  • Un post sur stackoverflow qui décrit la deuxième partie.

A la suite de cet article sur les cookies en navigation privée sous Chrome, Firefox et Internet Explorer, je me suis penché sur le cas Safari. La version que j’ai utilisée est Safari 5.0.1 pour Windows (avec wine 😉 ).

1ère différence : des paramètres par défaut plus restrictifs

Par défaut, Safari n’autorise que les coookies « des sites que je visite ». Par défaut donc, Safari n’accepte pas les cookies tières. Cependant, il accepte tout de même de les supprimer (allez comprendre…).

2ème différence : persistance des cookies

J’ai ensuite effectué les mêmes tests que pour les autres navigateurs, et là aussi le résultat diffère.

  1. Je n’ai pas de cookies. Je passe en navigation privée, je récupère des cookies, et je repasse en mode normal. Là, tout est OK.
  2. Je me prends des cookies. Je passe en navigation privée : les cookies sont toujours présents. Je cherche à les supprimer (avec les headers HTTP) : impossible, les cookies restent en place. En fait, les cookies reprennent alors la valeur qu’ils avaient avant le passage en navigation privée.

Conclusion

Safari se comporte réellement différemment que les autres navigateurs. La principale « fuite » d’information étant causée par les cookies tièrce, en ce sens le paramétrage par défaut de Safari est plus sécurisé. Cependant, le fait que l’on reste connecté après le passage en navigation privée est assez perturbant dès lors que l’on est habitué aux autres navigateurs. Mais le pire, c’est que l’on n’arrive pas à se déconnecter des services en mode de navigation privée.

Lien : outil de test utilisé pour afficher, écrire et supprimer des cookies