Sécurité web - Page 14

Un développeur web 1.0 de la bonne vieille école en effet. J'espère qu'il restera fidèle à ses convictions, à défaut de trouver du boulot.

Pour Zeph, qui s'étonnait récemment que des installations critiques soient connectées à Internet :


Ce que le mec a trouvé comme systèmes accessibles avec un simple navigateur, sans mot de passe :
- des systèmes domotiques
- des NAS
- plein de caméras, dont certaines qui filment des systèmes critiques
- des onduleurs (avec la possibilité de couper le courant)
- une ferme d'éoliennes
- des compteurs électriques
- des systèmes de contrôle d'éclairage, de chauffage/refroidissement et d'alarme de gros bâtiments industriels et commerciaux (stades, hôpitaux...)
- des process industriels
- des feux de circulation et radars feux rouges
- un barrage hydroélectrique en France
- des systèmes de transmission par satellite
- des systèmes de gestion des appels téléphoniques d'urgence
- un lavage de voitures, des hauts-parleurs connectés, une cave à vin...

Encore un mec avec un mac, c'est vraiment un outile de pirate ca devrait etre interdit

hey je suis choqué! J'utilise encore la balise "font"! (bon je ne suis pas dev Web )

aaah Dan Tentler et shodan.io

manoloben (./394) :
hey je suis choqué! J'utilise encore la balise "font"! (bon je ne suis pas dev Web )

Moi aussi, et <B> et <I> aussi. (<STRONG> et <EM> ne sont que des synonymes longs à taper et qui gaspillent de la largeur de bande, l'idée que ce soit "moins orienté présentation" que <B> et <I> est absurde, parce qu'en pratique les navigateurs affichent la même chose. Bref, déprécier <B> et <I> a été une décision absurde, tout comme pour <FONT>.)

Et j'écris toujours mes tags selon la définition traditionnelle du HTML: en ALL CAPS.

Le HTML est de la sémantique. <b> et <i> s'appellent ainsi parce qu'ils signifient "bold" et "italic", ce qui est du style.
Leurs remplaçants sont sémantiques : <strong> signale un élément important à mettre en avant, <em> est un élément à souligner (au sens figuré).
Le fait qu'ils soient respectivement gras et italique est un style par défaut qui peut être modifié : <strong> ne signifie pas "mettre en gras", en tout cas il ne doit pas être utilisé dans ce sens (sinon on finit avec des absurdités comme <h5><strong>bonjour</strong>>/h5>).
L'importance du respect de la sémantique est très important pour les appareils de lecture de code, comme l'aide aux déficients visuels, qui nécessite un code HTML solide dans son descriptif. C'est ce genre d'usage qui peut résumer, à lui seul, l'intérêt de séparer HTML et CSS.

<b> et <i> tu peux aussi les personnaliser via du CSS, nan ?

Donc sur ce point précis j'ai un peu de mal à ne pas être d'accord avec Kevin, essentiellement c'est la même chose, sauf qu'il y a plus de branlette intellectuelle derrière (et bon la séparation de la forme et du fond, ça n'a pas que du mauvais, mais c'est jamais parfaitement réalisable à 100% non plus. )
On a tous nos habitudes sur des sites 2.0 très pratiques etc, mais honnêtement, pour plus de la moitié des pages que je consulte, ils en seraient resté au html 1.0 ce serait mieux ! (pas toutes ces merdes d'auto-mises à jour de la page, et divers autres trucs insupportables -- encore que j'utilise ublock origin... ). En terme de bande passante et de consultation sur smartphone aussi, d'ailleurs.

Mais attention, il y a quand-même une différence pratique: <I><I>nested</I></I> affiche "nested" en italic, <EM><EM>nested</EM></EM> affiche "nested" en non-italic (parce que le niveau de EM est pair).

Je crois que je ne vais pas insister après cela. Soit dit sans animosité aucune, plus je réfléchis à mes arguments, plus je comprends que vous ne pouvez pas suivre ce qui s'expose pour moi comme une évidence quand je regarde le web moderne, parce que vous ouvrez un livre d'images en pestant sur toutes les illustrations quand vous ne voyez pas l'intérêt de lire autre chose qu'une encyclopédie.

Je crois que tu refuses d'accepter la critique de fond en reléguant tes contradicteurs à des beaufs qui ne comprennent rien. Je comprends l'intérêt de séparer la contenu du style, et à une époque j'ai même presque cru au web sémantique (qui a fait plouf, essentiellement, notamment à cause du web 2.0 qui "cache" les données ^^ ).

Il n'empêche que, d'esprit mathématique j'aime aller au plus élégant et au plus simple : j'ai du mal à voir l'intérêt de créer de nouveaux tags plutôt que de 'surcharger' simplement les anciens. Est-ce à cause de différences de comportement souhaité comme ./399 l'indique ?

Je sais pas, en maths, quand on a généralisé le théorème de Pythagore aux espaces pré-hilbertiens, on appelle toujours ça théorème de Pythagore, car, même si on l'a "étendu", dans l'esprit c'est la même chose. ça évite de créer 50 théorèmes aux noms distincts pour 50 fois la même chose plus ou moins étendu...
Et 'souligner figurativement' un passage, dans l'esprit, c'est la même chose que de mettre en italique ! Idem entre gras et strong. (d'ailleurs ça signifie presque la même chose... )

Dans d'autres matières, déjà un peu en physique (je ne parle pas des SI etc.), et malheureusement trop aussi en informatique, on passe notre temps à changer de nom les mêmes choses, à rajouter le plus de jargon non-nécessaire possible, voir à ré-inventer la roue (mais elle est 3.0 ou Cloud ou IOT ou DTC ou je ne sais quoi, donc elle tourne mieux! ). Il n'y a besoin ni de nier le passé, ni de s'y opposer, pour faire quelque chose de nouveau. Les maths en sont la meilleur preuve.
Tout ça c'est énormément lié aux problèmes d'égo des "créateurs" en fait.

Kevin Kofler (./399) :
Mais attention, il y a quand-même une différence pratique: <I><I>nested</I></I> affiche "nested" en italic, <EM><EM>nested</EM></EM> affiche "nested" en non-italic (parce que le niveau de EM est pair).

Ce qui est conforme aux règles de typographie (contrairement à la balise <i>) : l'italique d'un texte en italique n'est pas encore plus italique, mais du texte régulier.
D'ailleurs, l'italique en imprimerie ne dépend que très rarement de choix d'apparence, mais sert à se démarquer du texte classique (on ne veut pas mettre en italique, on veut mettre en avant). Le W3C, pour le coup, n'a fait que corriger un défaut de conception.

Je vais schématiser à l'extrême... à quoi cela sert de créer des langages comme Java, C#, ou même C alors que l'ASM marche bien et permet de tout faire ? est-ce qu'on a vraiment besoin de toutes ces fonctionnalités qui, sous prétexte de rendre le code plus lisible, plus simple à écrire, rendent en fait les codeurs fainéants à tout faire à leur place et obtenir de faire du code mal optimisé ?

Si vous avez une réponse à cette question, ne serait-ce que juste pour le plaisir de répondre plutôt que de simplement saisir ma métaphore (et au passage vous gausser à dire "ça n'a rien à voir"), c'est la raison pour laquelle j'ai dit ./400 . Pas parce que je considère les autres comme des "beaufs", seulement parce que j'ai l'impression que mon point de vue ne peut saisir les autres, et inversement, parce que chacun a une politique bien arrêté sur le sujet.

Je pense que on ne se comprends pas très bien, ouais
Justement ma critique c'est que ça n'apporte rien de plus, aucune nouvelle feature par rapport à garder les anciens noms, donc on aurait du garder les mêmes balises (en surchargeant de css personnalisables), comme on l'a fait très bien avec d'autres éléments du html. ( de <p> à <h1> etc )

Maintenant peut-être que certaines différences de comportement (comme ./399 indique, qui est de mon point de vu plus une rectification vers le bon comportement qu'autre chose, bref je Nil...) étaient assez importantes pour ne pas vouloir casser la réto-compatibilité ? Car si on a changé ces deux balises, on a gardé la plupart des anciennes.

Dans ce cas c'est justifié, reste que des tags aussi lourds et longs que <strong> pour un truc aussi simple ça reste peu élégant. ( heureusement qu'ils n'ont pas remplacé h1 par important_visual_priority_line_level1, <p> par ordered_block_of_content etc. etc )

Comme j'ai dit, c'est de la sémantique. Je comprends ce besoin de remplacer <b> par <strong>. C'est un peu comme si, avant l'arrivée des <h1>, on avait eu une balise <big> pour les titres. Ou encore d'ailleurs la balise <center> au comportement aléatoire.
Tout ça pour respecter une simple règle, il ne faut pas aller chercher plus loin : le HTML pour répartir le contenu, le CSS pour changer son apparence. Et <b>, par sa définition, n'avait pas pour but de "mettre un texte en avant" mais simplement "en gras".

<strong> et <em> ont un intérêt à décrire le texte qu'ils englobent. Les seules autres balises de texte concernent le code informatique, elles ne sont quasiment pas utilisées (<code> pour du code, <kbd> pour une touche ou combinaison clavier, <var> pour une variable, <samp> pour un extrait de code).

very (./405) :
heureusement qu'ils n'ont pas remplacé h1 par important_visual_priority_line_level1, <p> par ordered_block_of_content etc. etc

Ces abréviations auraient simplement pu être remplacées par leur nom : <head1>, <paragraph>.
En fait, en période pré-HTML5, <strong> est l'une des balises HTML les plus longues, les autres ayant surtout été raccourcies. De fait, on aurait pu la remplacer par <str> par exemple. Pourtant, <em> a été créé, et non <emphasized>. Mais on a aussi <fieldset> plutôt que <fld>

On a gardé les anciennes balises... on n'a pas eu trop le choix aussi comme le HTM est côté client, la technologie du visiteur peut évoluer indépendamment du site, il ne faudrait pas qu'un vieux site devienne d'un coup illisible.
Pour autant, tous les abandons ne sont pas à mon sens justifié. On a abandonné en cours de route la balise <menu> qui est pourtant de la sémantique, sans remplacement, et attendu le HTML5 pour voir arriver <nav>.

very (./401) :
Dans d'autres matières, déjà un peu en physique (je ne parle pas des SI etc.), et malheureusement trop aussi en informatique, on passe notre temps à changer de nom les mêmes choses, à rajouter le plus de jargon non-nécessaire possible, voir à ré-inventer la roue (mais elle est 3.0 ou Cloud ou IOT ou DTC ou je ne sais quoi, donc elle tourne mieux! ). Il n'y a besoin ni de nier le passé, ni de s'y opposer, pour faire quelque chose de nouveau. Les maths en sont la meilleur preuve.

Il y a aussi du jargon non-nécessaire dans les mathématiques en français: par exemple "colinéaire" pour les vecteurs, les mathématiciens des autres pays disent tout simplement "parallèle" (comme pour leurs droites porteuses).

Nil (./402) :

Kevin Kofler (./399) :
Mais attention, il y a quand-même une différence pratique: <I><I>nested</I></I> affiche "nested" en italic, <EM><EM>nested</EM></EM> affiche "nested" en non-italic (parce que le niveau de EM est pair).

Ce qui est conforme aux règles de typographie (contrairement à la balise <i>) : l'italique d'un texte en italique n'est pas encore plus italique, mais du texte régulier.D'ailleurs, l'italique en imprimerie ne dépend que très rarement de choix d'apparence, mais sert à se démarquer du texte classique (on ne veut pas mettre en italique, on veut mettre en avant). Le W3C, pour le coup, n'a fait que corriger un défaut de conception.

Et donc c'est simple, si je veux ça, j'utilise <EM>, si je veux être sûr que mon texte est en italic, j'utilise <I>, il n'y en a pas un qui remplace l'autre.

Meowcate (./406) :
<strong> et <em> ont un intérêt à décrire le texte qu'ils englobent. Les seules autres balises de texte concernent le code informatique, elles ne sont quasiment pas utilisées (<code> pour du code, <kbd> pour une touche ou combinaison clavier, <var> pour une variable, <samp> pour un extrait de code).

Euh si, <code> est utilisé (par tout le monde sauf les auteurs de ce forum, qui ont inventé leur propre class="fixed").

Kevin Kofler (./407) :
Il y a aussi du jargon non-nécessaire dans les mathématiques en français: par exemple "colinéaire" pour les vecteurs, les mathématiciens des autres pays disent tout simplement "parallèle" (comme pour leurs droites porteuses).

C'est vrai qu'il y a une précision du vocabulaire un peu plus grande qu'en pays anglo-saxons dans les maths françaises, mais je ne trouve pas que ce soit jargonant. Colinéaire par exemple est intuitif et se comprend instantanément pour un étudiant français de niveau correct. C'est peu-être moins évident lorsque le français n'est pas la langue maternelle.

Par contre en physique c'est une plaie.

Meow > je comprends ton point, mais par contre remplacer un mot par un synonyme pour apporter plus de précision sémantique, j'ai un peu de mal à saisir Fin bref fin du débat je crois ^^

Concernant h1... h6, ça reste une aberration. On devrait avoir une balise <h> avec un attribut level.

./392 : arg... et ça ne va pas aller en s'améliorant, avec la multiplication des métiers autour de l'informatique et le fait que tout le monde se mette à développer des trucs. Finalement les seuls métiers qui ont peut-être de l'avenir là-dedans, c'est ceux en rapport avec la sécurité

./411
Ce n'est pas une mauvaise idée. D'un autre côté, je ne vois personne aujourd'hui utiliser la totalité des niveaux de sous-titres.

Zerosquare (./392) :
- un barrage hydroélectrique en France

J'espère que quatre ans après, ils ont fait quelque chose, parce que bon, savoir que la gestion de l'électricité du Lot-et-Garonne peut se faire par n'importe qui depuis Internet fait légèrement peur.

la problème un phrase dernier.

()

Suite au ./392 : http://www.insecam.org/en/bycountry/FR/?page=1

Par chez moi, les caméras servent à surveiller les chiens et le bétail

Comment ça fait mal

oooooooooooold