Getting rid of Comic Sans in Firefox

Test page: the Microsoft Comic Sans Café.
Original look:

How to get rid of Comic Sans for Mozilla Firefox

1. Look for the following folder: %userprofile%\Application Data\Mozilla\Firefox\Profiles\chrome under Windows or the equivalent under your OS.
2. Create a file named userContent.css in it. If it already exists, you can simply append the following at the end of it.
3. Copy-paste the following line into it: @font-face { font-family: 'Comic Sans MS'; src: local('Lucida Sans Unicode'); }
4. Lucida Sans Unicode is a good choice because it has approximately the same height and weight as Comic Sans MS, but you can replace it with any other font, such as Arial, Deja Vu Sans or Century Gothic.
5. Save the file and restart Firefox.

Resulting look:

I'm a Google Orphan – Epiphany

Sigh... I'm a Google orphan, that's the sad epiphany I had the other day.

• Google Reader is closing and no online application seemingly reaches the level. If you cross one, please let me know.
• With the fall of Google Reader, I'm really worried for the future of RSS feeds, which were a founding pillar of free communication on the internet.
• The need to share and sync files from anywhere made me try Google Drive. I clearly find that Drive is made to satisfy an all-Google user's need but not that of someone else. If all you want to use is Google applications and phones, then it's fine. But I'm not buying into that. Dropbox is far superior and even easier to use.
• Google Search isn't anymore a powerful tool. It finds the same results as other engines and I sometimes miss the old days of Altavista, where you could simply type the precise words you wanted and there was no kind of "intelligent" understanding of requests. Between the multiplying intrusions of states, copyright holders and commercial customers of Google services, the Google Search engine is really going into garbage and the user is the looser. And the "intelligent" handling of requests is frustrating me: I know what I want better than machines, stop correcting my orthograph, using synonyms, etc.!
• I'm satisfied with my Android phone as a tool for mobility. E-mail, SMS, web have never been so easy. But I'm appalled when I see the new ads they broadcast on every major TV channel: they show it as something funky, graphical, fashionable... it's not! and I don't want it to be.

So I'm a Google orphan.
Google – as I saw it – is dead. Or, at least, an era is over... and Google now resembles Microsoft 10 years ago.

On ne peut pas faire de Sécurité du SI sans compter

Un discours que j'ai tenu plusieurs fois, autant le mettre par écrit, sur la gestion des risques et le besoin pour un RSSI de s'appuyer sur des données chiffrées.

En matière de sécurité, on peut faire tout, rien, n'importe quoi ou quelque chose.


Si l'on fait rien, on est en position suboptimale. En effet, si rien était une situation satisfaisante, on n'aurait jamais entendu parler de Sécurité du SI et encore moins de RSSI.


Si l'on fait tout, on a besoin de plus de moyens que l'activité-même que l'on tente de sécuriser. Ce n'est pas toujours évident pour les gens qui ne travaillent pas dans la sécurité. De façon abstraite, on peut l'expliquer en disant que sécuriser une activité signifie maîtriser ce qui n'est pas dans le fonctionnement normal de l'activité, c-à-d avec des acteurs imprévus, des conditions extérieures imprévues, des pannes imprévues, etc. Le périmètre à sécuriser est bien plus grand que celui de l'activité elle-même.
Un exemple du SI : pour sécuriser tout en matière de site web, il faut maîtriser les attaquants extérieurs, ainsi que les fournisseurs de logiciels. Aucune entreprise, petite ou grande, aucun gouvernement, ne peut se targuer de sécuriser ainsi totalement un site web.
Un exemple hors-SI : pour sécuriser totalement une flotte de voitures, il faudrait maîtriser entièrement l'état des routes, les autres véhicules utilisant la chaussée, le niveau d'aptitude et de concentration des chauffeurs. Là encore, aucune entreprise ni aucun gouvernement ne peut s'en targuer.
Il n'est donc pas possible de faire tout, en sécurité. Ce que l'on résume souvent par la formule journalistique galvaudée « le risque zéro n'existe pas ».


Si l'on ne fait ni rien, ni tout, on peut éventuellement faire quelque chose mais, à défaut d'une bonne façon de donner des priorités et des coefficients aux actions de sécurité, ainsi que d'une bonne façon de corréler ces actions de sécurité en un ensemble cohérent, ce quelque chose devient vite n'importe quoi. C'est ce que tendent à faire les entreprises qui commencent dans le domaine de la sécurité du SI.
Exemple SI : Sécuriser les bases de données.
Traduction hors-SI : Sécuriser les moteurs des voitures. Ça n'empêchera que très peu d'accidents.
Exemple SI : Définir un périmètre réseau de l'entreprise et filtrer l'entrée.
Traduction hors-SI : Empêcher les véhicules en mauvais état ou hors-gabarit de prendre l'autoroute. Ça empêchera certains accidents mais ça ne rendra pas les accidents sur l'autoroute moins graves, ça laissera passer les conducteurs ivres et ça ne protègera rien hors de l'autoroute.
L'ensemble des actions de sécurité qui se fondent sur une analyse purement technique du SI et des menaces qui pèsent sur lui souffrent de ce même défaut : elles ne peuvent distinguer ce qui est important de ce qui est anodin, faute d'un critère de comparaison.


Pour faire quelque chose qui ne soit pas n'importe quoi, le choix d'une stratégie s'impose. Or, qui dit stratégie dit objectifs. Qui dit objectifs dit « savoir ce que l'on veut protéger ».
Exemple hors-SI : essayer de diminuer le nombre d'accidents, ou le nombre d'accidents mortels, ou les embouteillages, ou le nombre de délits de fuite...
Exemple SI : essayer de diminuer les vols de données, ou les interruptions du travail liées au SI, ou les pertes de données, ou d'augmenter la traçabilité pour se mettre en conformité avec la loi...


Comment choisir parmi ces objectifs ? Ou, si l'on veut n'en négliger aucun, comment ventiler les actions et les moyens disponibles ? Pour ce faire, il faut être capable de positionner des valeurs, comparables entre elles, sur chacun de ces objectifs. C'est ce que l'on nomme la gestion des risques et qui est développé dans de nombreux standards tel ISO27005, EBIOS étant sans doute le plus mature. Les données nécessaires au RSSI devenu gestionnaire de risques pour pouvoir réaliser une sécurisation rationnelle du SI sont les mêmes que celles nécessaires à d'autres managers de l'activité : budgets, KPI, stratégie de l'entreprise, liste des projets en cours... Ces données permettant au RSSI de s'inscrire dans une logique globale de l'entreprise ainsi que de justifier les actions entreprises en utilisant un vocabulaire commun au reste des décideurs internes.

On ne peut pas faire de Sécurité du SI sans compter. Le RSSI doit donc disposer des moyens nécessaires et les utiliser.

De la culture du commandement à la culture de la décision

Je discute avec des élèves-ingénieurs et je vois passer de ces commentaires qui me font sourire. Leurs premières réactions à la vie en entreprise... ;-)
« Moi qui croyais qu'une réunion, c'était pour prendre des décisions ! »

Alors je reviens sur ce sujet qui me tient à cœur et qui fonde mon style de management, l'empowerment des collaborateurs.

En France, comme dans la majeure partie du monde latin, notre culture du management est une culture du commandement. On ne cherche pas quelle est la meilleure solution mais qui est le chef pour en décider. Cela a encore été renforcé par la centralisation, l'administration bonapartiste, le jacobinisme, etc. Le chef demande des informations et on les lui apporte, puis donne ses ordres. Point. Les collaborateurs s'exécutent et gare à celui qui remet les ordres en cause !

C'est un modèle largement suboptimal. Le chef n'explique pas les raisons des ordres, coupant ses collaborateurs de leurs capacités d'initiative et d'alignement. L'ordre est sujet à interprétation et l'interprétation la plus simple et la plus évidente est toujours celle choisie car on ne peut contrevenir à un ordre direct ; les collaborateurs sont donc coupés de leur volonté d'initiative. Le tout est égal au minimum des parties.

Un meilleur modèle est le management par la décision. Si l'on ne donne plus des ordres mais des directives, s'il n'y a plus un chef qui décide mais un cheminement connu de l'ensemble des collaborateurs vers une décision, alors on arrive à rentabiliser les capacités des différents acteurs. Et le tout se rapproche de la somme des parties.

Ce n'est pas chose facile, il faut se couper de certaines habitudes de secret (dans l'absolu, une équipe travaille pour son chef, il est donc raisonnable de lui faire confiance sur une grande majorité de sujets). Et il faut beaucoup de cohérence et de probité. Car si l'équipe connaît les raisons d'une décision, elle peut les contester et il faut reconnaître que, certaines fois, elle aura raison de le faire ! Il faut permettre aux collaborateurs de comprendre les objectifs à atteindre et leur montrer en quoi les décisions prises concourent à la satisfaction de ces objectifs. À ce prix seulement, les collaborateurs prendront l'habitude de l'initiative adjuvante et apporteront régulièrement à leurs chefs les rapports de bonnes idées qu'ils ont eues et exploitées.

Revenons aux réunions : « Moi qui croyais qu'une réunion, c'était pour prendre des décisions ! » Une réunion peut très bien être un lieu de prise de décision, à condition que les objectifs et les critères de décision ne soient pas secrets mais partagés. Enlevons les œillères ! Si dans certaines réunions, les chefs ne prennent pas de décisions et les collaborateurs s'abstiennent de contribuer, c'est tout simplement parce que les critères de décision sont l'apanage du chef, qu'ils deviendraient apparents si une décision était prise en direct par celui-ci et que les collaborateurs craignent de trahir le peu qu'ils en savent (et donc de trahir leur chef) en dévoilant leurs idées contribuant aux objectifs. De plus, les collaborateurs craignent souvent de se voir opposer un refus non-justifié, qui les frustre et les convainc un peu plus que, vraiment, ils n'ont pas à participer à la prise de décisions.

Dans une réunion productive, comme j'en ai vu, le chef n'explique pas seulement les objectifs à court-terme avant de recueillir les contributions de ses collaborateurs, il explique ses objectifs à moyen- ou long-terme et listes ses contraintes, avec un ordre de priorité qui permet aux collaborateurs de comprendre les critères de décision finaux et d'adhérer à la décision.

A Suggestion for MediaWiki

A Suggestion for MediaWiki, useful for multi-language wikis, based on my experience from Wikipedia.

The idea is to add multi-language search (exact) matches on the left panel of pages showing search results. Though this may not be feasible with the current data architecture within MediaWiki, there's no reason why it should be impossible to implement.

That would ease the look for information for people who can speak several languages. That would also stimulate the creation of articles by translation of articles from other languages. As a reminder, a big part of mankind speaks two or more languages, I'd say more than half of it.

Let's see an illustration. Figure 1: what you get when you search for "xades" on the English Wikipedia.

Figure 2: what you get when you search for "xades" on the French Wikipedia, no direct results.

Figure 3: What I suggest adding onto the search page (the French one, in this case).

On Client-Side Model Data Validation

Reversing an online Flash application is sometimes not needed if you can access the data inside the model directly.

When you're developing an online application that's running client-side with data server-side, you're faced with the localization of data. For clarity, let's assume you're developing it in a MVC design pattern. Basically, you'd want to put most of data on the server and only give the client a controller on it. The problem starts when you need high transfer rates and reactivity: you just can't go to the server and back for every tiny piece of data. That's when you need to have the model split between the server and the client. Either split or duplicated.

What I'm going to say may come as an obviousness for people used to security, but it may as well come as a shock for casual application developers: if some part of your data model is located on the client, you need not only do user input validation on the inputs from the controller but also on the inputs from the client-side model.

You can't trust the client's terminal to keep data stored in the model safe. So you need to protect it either through integrity or through server-side re-validation.

I just hacked into putting whatever score I wish for myself onto an online gaming platform, which inspired me to write this article. The same could be applicable for more critical applications.

Security ROFL 9

French communication through SSID labels (from Guillaume Germain's Twitter):
— The girl next door is so sexy!
— The girl next door is not interested.

Traffic sign jacking (from the blog Si vis pacem para bellum):

The complexity of using PGP. The bad guys don't use that tool anymore ^^ The good neither. (From XKCD)

A sorry but so plausible story of an engineer outsourcing his own job to China by himself. And comments about logging systems. (From Aaron Weiss @ eSecurity Planet)

A U.S. software programmer made headlines when he outsourced his own job to China. He probably never would have gotten away with it if his employer had been paying attention to its log files.

The pretty naughty story of what happens when you post a job offer through unprofessional people...

 

French swindler promising to fix any PC, including defective hard drives, through voodoo :-D