Comments on Polices, et partages des ressources par haché

a3nm (2015-09-25T23:04:38Z)

Mozilla s'est dit hier que ce serait une bonne idée d'indiquer des hachés lors du chargement de ressources tierces, mais à des fins de sécurité : https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/

Peut-être qu'ils se rendront compte ensuite que ça peut servir aussi au cache…

a3nm (2013-04-02T08:51:59Z)

Il y a une idée de ce genre dans ce vieux draft (utiliser des URN pour adresser le contenu et spécifier des miroirs pour ces URN en utilisant sha1 pour ne pas avoir besoin de leur faire confiance) :

<URL: http://web.archive.org/web/20090227014730/http://open-content.net/specs/draft-jchapweske-caw-03.html > (trouvé via <URL: http://www.waterken.com/dev/YURL/ >)

De manière générale, il manque une indirection entre l'identité du contenu (qui n'a pas besoin d'être human-readable ou routable) et son emplacement. Le rant que j'ai écrit sur OpenID <URL: http://a3nm.net/blog/openid_problem.html > (et que tu as peut-être vu passer sur forum) parle essentiellement du même problème. Une idée liée est <URL: https://en.wikipedia.org/wiki/Host_Identity_Protocol > (pour séparer l'identité et l'emplacement pour les hôtes et non pour les ressources).

simple-touriste (2013-03-21T21:02:50Z)

L'URN hash est non seulement une idée évidente et évidemment utile, c'est insupportablement évident.

Ce schéma permet d'intégrer les éléments téléchargés via HTTP dans une page HTTPS sans casser la sécurité (pour le navigateur : "https:" barré dans Chrome).

Il faut aussi l'URN avec signature : télécharger un objet nommé X signé par la clef K (ou la clef de hash H_k). Cela permettrait de télécharger la dernière version d'un logiciel. (Et pour les polices : il n'y a jamais de bugfix?)

Pour éviter de mettre la clef K dans l'URN, il faut indiquer le CN du certificat exigé, certificat qui sera vérifié de façon usuelle.

On pourra aussi combiner ça avec HTTPS : schéma https avec clef intégrée, avec hash de clef intégrée, avec le hash du certificat intégré dans l'URL…

On pourra aller plus loin : un schéma d'URI javascript PUR (sans contexte, sans same-origin!) indiquant comment obtenir la données et valider son intégrité : une sorte de data: mais exécutable.

Je m'égare…

(Mon texte n'est peut-être pas bien rédigé, mais l'intuition est tellement évidente que ça se passe de phrases. On devrait rédiger les normes comme ça, avec des : "bon là tout le monde comprend intuitivement".)

Damien (2013-03-19T07:27:52Z)

Voir notamment ce comparatif, cité dans l'article que j'indiquais juste avant :
http://www.smashingmagazine.com/2010/10/20/review-of-popular-web-font-embedding-services/

Je n'en ai pas trouvé de plus récent aussi complet, même si je suppose que cela a dû évoluer depuis…

Damien (2013-03-19T07:23:16Z)

Légèrement HS, un point de vue sur Typekit qui est une alternative à Google Fonts mais qui comporte quelques inconvénients.
http://vincent.bernat.im/fr/blog/2011-typekit.html

ScanX (2013-03-18T13:13:32Z)

Le site de Red Hat (<URL: https://access.redhat.com/downloads/other > est intéressant car il fournit différentes solution.
On peut voir qu'ils permettent le téléchargement de la police "Liberation".
Apres analyse du code source, on peut voir que les polices sont disponibles au format WOFF, à partir de la page Red Hat et de Google.

ScanX (2013-03-18T13:06:20Z)

Tu peux simplement préciser que ton site s'affiche mieux avec telle police de caractères et indiquer où la télécharger.
Le site de Red Hat fait ça:
https://access.redhat.com/downloads/other


You can post a comment using the following fields:
Name or nick (mandatory):
Web site URL (optional):
Email address (optional, will not appear):
Identifier phrase (optional, see below):
Attempt to remember the values above?
The comment itself (mandatory):

Optional message for moderator (hidden to others):

Spam protection: please enter below the following signs in reverse order: f68ee2


Recent comments