Bienvenue sur PEBKAC.fr, le site qui recense les anecdotes où l’on se moque des utilisateurs ne maîtrisant pas l’outil informatique. PEBKAC est un acronyme signifiant « Problem Exists Between Keyboard And Chair ».
Le problème se situe entre la chaise et le clavier : soumettez vos histoires, donnez votre avis !
Ce site n'est pas le site original pebkac.fr. Je publie ici la liste des PEBKAC que j'ai pu sauvegarder avant que le site original ne soit mis hors ligne.
Dans le lycée d'un ami, il y a des sites Web dont l'accès est interdit (depuis les salles informatiques), en particulier un réseau social de couleur bleue. Jusqu'ici tout va bien, sauf qu'il est possible d'accéder à sa version mobile via l'adresse « m.<domaine.com> ». Du coup, la restriction n'a pas vraiment d'effet.

À quoi sert ce filtre réseau ? À forcer les utilisateurs à se connecter via la version mobile, ou alors c'est un… PEBKAC.
PEBKAC #9790 proposé par Adrien74 le 22/04/2014 | 15 commentaires | 👍🏽 👎🏽 +143
Ils font de la pub pour leur bouton Aime jusque dans les liens !
Commentaire #137984 écrit par Aaargh!!! le 22/04/2014 à 12h35 | 👍🏽 👎🏽
Je serais extrêmement surpris qu'un Pebkac dans le genre n'ait pas encore été publié. Voir plusieurs.
Commentaire #138017 écrit par Kelgarath le 22/04/2014 à 14h00 | 👍🏽 👎🏽
C'est le coup classique de l'URL bloqué, mais pas de l'IP du site.
Très souvent, les organismes publique utilisent une proxy "user friendly" et sans aucune mise a jour.

Je dirais pas PEBKAC, mais plus un manque de moyen.
Commentaire #138022 écrit par ctrl+alt+suppr le 22/04/2014 à 14h06 | 👍🏽 👎🏽
On risque d'avoir une recrudescence de ce type de PEBKAC vers mi-septembre / octobre, date approximative à laquelle les élèves de Seconde découvrent la faille dans le système.
Commentaire #138029 écrit par aDev le 22/04/2014 à 14h20 | 👍🏽 👎🏽
Si tu as un moyen de connaitre toutes les IP d'un réseau social (ou d'un domaine en général) je suis preneur.
Commentaire #138035 écrit par seb le 22/04/2014 à 14h42 | 👍🏽 👎🏽
Il y a déjà eu 2 PEBKAC sur le fait que ce soit bloqué en HTTP et pas en HTTPS mais pas encore en version mobile, ou alors ma mémoire me fait défaut.
Commentaire #138036 écrit par seb le 22/04/2014 à 14h43 | 👍🏽 👎🏽
Ah alors si c'est différent ça va.

Oh wait.
Commentaire #138040 écrit par Kelgarath le 22/04/2014 à 14h55 | 👍🏽 👎🏽
Pourquoi ne pas bloquer directement .visagelivre. ? sur http et https ? Déjà ça limiterait le nombre de connexions. PS, je ne connait pas la syntaxe exate pour le faire, mais je doutes qu'un pare-feu ne comprenne pas d'expression rationnelle.
Commentaire #138047 écrit par ygnobl le 22/04/2014 à 15h37 | 👍🏽 👎🏽
@ygnobl
Oui je suis bien d'accord mais c'était suite à l'argument de ctrl+alt+suppr comme quoi le blocage par IP est mieux que le blocage par URL (enfin, c'est comme ça que je le comprend).

Pour répondre à ta question, le blocage HTTP est très simple à mettre en place, par contre le blocage par HTTPS implique un décryptage (déchiffrage? Je ne sais jamais) des trames et ça c'est plus compliqué et surtout il faut prévenir les utilisateurs. Au passage il me semble que tu n'as pas le droit de décrypter une trame venant d'un site de banque comme tu le ferais pour une trame venant d'un réseau social.
Commentaire #138069 écrit par seb le 22/04/2014 à 16h40 | 👍🏽 👎🏽
@Kelgarath

Effectivement, ça n'a rien a voir, je n'aurais pas pensé aux versions mobiles des sites internet. :)
Commentaire #138070 écrit par seb le 22/04/2014 à 16h42 | 👍🏽 👎🏽
@seb : ça dépend de ce que tu veux dire.

Décryptage : retrouver le code original sans connaître la clé (ce qui n'est pas supposé arriver)
Déchiffrage : retrouver le code original avec la clé de chiffrement (ce que font les clients/serveur HTTPS)

Cela dit ça m'étonne car je crois me souvenir que certaines données, comme l'URL ou au moins le domaine sont transmises en clair, pour la simple et bonne raison que le serveur DNS doit recevoir cette information en clair.

Mais n'étant pas spécialiste je peux me planter.
Commentaire #138077 écrit par aDev le 22/04/2014 à 17h02 | 👍🏽 👎🏽
@seb : Apparemment tu n'es pas le seul ;-)
Commentaire #138089 écrit par aDev le 22/04/2014 à 17h16 | 👍🏽 👎🏽
L'url initiale est envoyée en clair. Heureusement car elle ne saurait être déchiffrée. Mais les url contenues dans le code HTML est lui codé. Par contre, en cliquant, la requête est envoyer en clair -même principe de communication avec les serveurs-.
Commentaire #138109 écrit par H. Finch le 22/04/2014 à 19h22 | 👍🏽 👎🏽
@aDev, il semblerait logique que l'url ne soit pas cryptée pour permettre la résolution DNS, donc qu'un filtrage d'url soit applicable aussi sur https. Pour le filtrage par ip, par contre, je crois me souvenir qu'il y a des problèmes liés à la fois à l'effet de bord si plusieurs sites sont hébergés sur la même ip, et à la relative mobilité des adresses des serveurs (si un serveur ou un pool d'iceux est ajouté, avec une adresse différente)
Commentaire #138111 écrit par ygnobl le 22/04/2014 à 19h25 | 👍🏽 👎🏽
Pour avoir un peu pratiqué un proxy "user friendly" assez courant dans les lycées ce n'est pas vraiment un question de mise à jour mais juste un problème de config :
en mettant http://www.domaine.com dans la liste noire https://www.domaine.com passera sans problème (de même que toto.domaine.com)
Par contre en mettant domaine.com toute adresse contenant domaine.com (donc http, https et sous-domaines) sera bloquée

Du coup le pebkac c'est le mec qui configure les filtres...
Commentaire #138116 écrit par Manu le 22/04/2014 à 19h43 | 👍🏽 👎🏽