Manifeste v3 et bloqueurs de publicité dans Chromium : 150 000 règles pour Declarative Net Request

Manifeste v3 et bloqueurs de publicité dans Chromium : 150 000 règles pour Declarative Net Request

Désolé, ceci n'est pas un titre clickbait

66

Manifeste v3 et bloqueurs de publicité dans Chromium : 150 000 règles pour Declarative Net Request

« Google veut mettre à mort les bloqueurs de publicité ». Un discours qui n'a rien de nouveau, mais qui prend plus d'ampleur ces derniers mois à travers le travail autour de la v3 du manifeste des extensions et l'évolution de certaines API. Face aux critiques, Google évolue et détaille à nouveau sa position.

L'équipe de Chromium travaille à la v3 du manifeste de ses extensions et la modification profonde de certaines API depuis des mois. Fin 2018, un point a été mis en lumière concernant l'évolution de Web Request et sa capacité à bloquer des requêtes. Les développeurs du navigateur estiment que son impact sur les performances est néfaste, en plus de poser des problèmes de sécurité et la vie privée pour l'utilisateur.

Faire évoluer un écosystème, c'est compliqué

Elle doit donc être remplacée par Declarative Net Request, aux possibilités moins nombreuses. Mais voilà, cela pose souci à certains concepteurs d'extensions qui voient dans cette API une limitation de leurs possibilités plus qu'une évolution intéressante. C'est notamment le cas des bloqueurs de publicités. La suite était prévisible.

Rapidement, Google a été accusé de vouloir compliquer la vie de ces derniers, voire de signer leur arrêt de mort. Il y a quelques jours, les choses ont repris de plus belle suite à de nouvelles déclarations et l'annonce d'une exception limitée à la version Entreprise de Chrome. Les développeurs d'autres navigateurs basés sur Chromium, interrogés par ZDNet, ont déclaré qu'ils ne suivraient pas cette modification, de quoi initier la création d'un « fork ».

Google ne pouvait donc plus rester dans l'ombre et a décidé de communiquer.

Les risques de Web Request, l'évolution nécessaire de Declarative Net Request

Dans un long billet de blog, l'équipe de développement revient sur le fonctionnement des deux API, ses choix et ses motivations, évoquant « de la confusion et des malentendus » dans cette affaire, notamment par les objectifs visés. Elle y rappelle que, « historiquement, lorsque les développeurs ont eu à faire le choix entre les capacités de leurs extensions et la vie privée, c'est le premier point qui l'a emporté ».

Google ajoute de son côté une couche via son blog dédié à la sécurité. Il faut dire que la société ne veut sans doute pas finir par être accusée de laxisme lorsqu'un scandale éclatera parce que des milliers d'utilisateurs s'apercevront avoir été espionnés en détail par une extension qui utilisait discrètement Web Request.

La position des équipes de Chromium ne change donc pas sur un point : Declarative Net Request prendra le relais à terme,  à la manière des choix d'Apple en la matière, le travail sur le manifeste v3 étant de toute façon loin d'être terminé. Mais des évolutions ont déjà été intégrées ou vont l'être pour répondre aux demandes des développeurs.

  • L'évolution du fonctionnement des API à travers Manifest v3 (l'exemple est intéressé)
  • Le fonctionnement de Web Request
  • Le fonctionnement de Declarative Net Request

Manifest v3 : la négociation continue, des changements prévus

Des éléments de pistages peuvent ainsi être retirés des requêtes (referer, cookies), des règles peuvent être ajoutées ou supprimées de manière dynamique, ces dernières devraient d'ailleurs pouvoir être plus complexes à l'avenir.

Surtout, leur nombre maximal va passer de 30 000 à 150 000 pour s'assurer que des logiciels comme les bloqueurs peuvent continuer de fonctionner. Les extensions devront néanmoins évoluer pour s'adapter à ce changement, dont la mise en place est encore lointaine. Les développeurs d'extensions ne manqueront sans doute pas de réagir à cette déclaration dans les jours qui viennent, il faudra suivre attentivement leur réaction.

Notamment leurs propos concernant des points de blocage qui pourraient encore exister dans la v3 du manifeste. Il faut également s'attendre à ce que certains en profitent pour continuer de pousser les navigateurs tiers à faire scission avec le code de base de Chromium. Alors que Microsoft s'apprête à sortir son nouvel Edge, sa position est attendue.

Commentaires (66)


Actuellement, mon uBlock Origin est réglé ainsi :

« 128 222 filtre(s) réseau et 101 438 filtre(s) esthétique(s) sont actuellement en vigueur » (soit 229 660 cumulés)



Est-ce que, dans ces conditions, ça suffira (quitte à virer les filtres esthétiques) ?


Vive Firefox


C’est l’objectif ;) 

 





SunneX a écrit :



Vive Firefox





Firefox, comme tout navigateur récent avec des extensions, fait face aux mêmes problème d’équilibre entre les possibilités données aux développeurs et la protection des informations de l’utilisateur ou la question de la performance. WebRequest y existe, ils devront aussi se positionner sur le sujet car ils prennent les mêmes risques que Chromium. Des commentaires peu constructifs n’y changeront rien ;)



Il serait bon aussi d’encadrer plus durement la publicité en ligne, de mettre en place des standards, etc …

En l’état c’est une jungle ou l’utilisateur est constamment agressé ! l’ARPD se sert absolument à rien …



Les traceurs, les cookies, les informations collectés, pour le moment tout reste flou, nous ne savons toujours pas ce qui est réellement fait en la matière et ce malgré les avancés de la RGPD …


Si je comprends bien, les extensions devront faire confiance à chrome pour appliquer les filtres voulus donc potentiellement google peut mettre en place une liste blanche (à la adblock plus)?



       

> Il faut dire que la société ne veut sans doute pas finir par être accusée de laxisme lorsqu'un scandale éclatera parce que des milliers d'utilisateurs s'apercevront avoir été espionnés en détail par une extension qui utilisait discrètement Web Request.

 [ironie on] On explique au millier d'utilisateurs qu'ils sont déjà espionnés :mdr2:[ironie off]



 


Le principe de la délégation du filtrage afin que l’extension ne voient pas les données est une bonne intention et peut s’avérer judicieux si c’est bien fait. Ce qui parait idiot, c’est de fixer une limite sur la quantité de filtres utilisables. Qu’apporte t’elle de plus ? Rien du point de vue de la protection de la vie privée en tout cas.



C’est cette limite le problème, pas le principe.


Il y a déjà des standards dans la publicité en ligne, même plein de label. Cela n’empêche rien. Comme toute industrie, elle abuse des possibilités à sa disposition. Et comme les instances en charge tardent à réellement taper du poing sur la table, ça continue. 



 





stratic a écrit :



Le principe de la délégation du filtrage afin que l’extension ne voient pas les données est une bonne intention et peut s’avérer judicieux si c’est bien fait. Ce qui parait idiot, c’est de fixer une limite sur la quantité de filtres utilisables. Qu’apporte t’elle de plus ? Rien du point de vue de la protection de la vie privée en tout cas.



C’est cette limite le problème, pas le principe.





Au hasard pour éviter d’avoir des chargement dynamique de 2 millions de règles qui vont tout faire planter ? <img data-src=" /> Que des limites existent, ça peut être normal. Qu’elles soient bien proportionnées, c’est une autre affaire, le sweet spot pouvant être dur à trouver. Avec les 30 000 c’était clairement un souci, là on est à 150k + 5k en dynamique de mémoire (si ça n’évolue pas), ça laisse de la marge ;)



Pourquoi ne pas simplement avertir l’utilisateur que l’extension demande à utiliser webrequest ?

Le nombre d’applications doit être relativement limité, non ?








David_L a écrit :



Il y a déjà des standards dans la publicité en ligne, même plein de label. Cela n’empêche rien. Comme toute industrie, elle abuse des possibilités à sa disposition. Et comme les instances en charge tardent à réellement taper du poing sur la table, ça continue.







Le problème étant qu’il ne s’agit là que de charte, pas de règle, alors ne parlons même pas de loi !

Yep, il y a du boulot à revendre sur le sujet, et Google ne semble pas aller dans le bon sens, en même temps, la publicité s’élève à combien en pourcentage sur leur chiffre d’affaire ? Une belle somme à n’en point douter.

Du coup la pratique est pas prête de changer



Sinon vous avez le fichier hosts. Comme ça à vous de voir quel site essaye de vous entourlouper par d’autres moyens sophistiqués.





Google ajoute de son côté une couche via son blog dédié à la sécurité. Il faut dire que la société ne veut sans doute pas finir par être accusée de laxisme lorsqu’un scandale éclatera parce que des milliers d’utilisateurs s’apercevront avoir été espionnés en détail par une extension qui utilisait discrètement Web Request.





J’avais cru comprendre que ces méthodes de voyous étaient normales depuis que modifier les paramètres de localisation sur Android ne changeait rien. Cohérence quand tu nous tiens. <img data-src=" />








v1nce a écrit :



Pourquoi ne pas simplement avertir l’utilisateur que l’extension demande à utiliser webrequest ?

Le nombre d’applications doit être relativement limité, non ?





C’est déjà le cas à l’installation, et Chromium va renforcer les alertes sur les prochaines versions (si pas déjà fait, je ne sais plus trop où ils en sont). Mais ça ne change rien au fait que le fonctionnement même de l’API pose souci puisqu’elle envoie tout, et ensuite l’extension fait le filtre et décide ce qu’elle en fait.&nbsp;



Prend l’exemple de Kimetrak : pour savoir quels sont les pisteurs chargés sur une page on intercepte toutes les requêtes, donc tout leur contenu en intégralité, juste pour récupérer le domaine. L’utilisateur doit forcément accepter l’activation sur tous les domaines pour que ça fonctionne. L’usage est légitime mais les abus possibles infinis. Qu’on puisse préciser dès le départ ce que l’on veut serait une bonne chose.



C’est notamment pour ça qu’Apple a plutôt misé sur les bloqueurs de contenus avec des usages spécifiques et un environnement cadré via des règles à appliquer.&nbsp;



Le fichier host n’applique pas de règles CSS








Idiogène a écrit :



Sinon vous avez le fichier hosts. Comme ça à vous de voir quel site essaye de vous entourlouper par d’autres moyens sophistiqués.&nbsp;



J’ai essayé une fois le fichier Hosts avec une liste anti-pub de 20 kio : Windows voulait même plus redémarrer, et j’ai été obligé de rétablir le Hosts d’origine (toujours garder une sauvegarde des fichiers système modifiés !) avec un Live-DVD Ubuntu pour lui permettre de simplement redémarrer ! Et sur un autre PC, j’avais dû redémarrer en mode sans échec (mais c’était hyper lent !!!) pour faire de même.



Depuis, je veux plus trop entendre parler de ce genre de solutions, tu vois…



C’est un problème connu lorsque le fichier hosts devient trop “gros”. Il faut impérativement désactiver le service “Client DNS” (en réalité, un cache DNS) qui est responsable de cette instabilité. Plus d’infos ici.


Ça alors !

Histoire de s’habituer au DDI plutôt qu’au DPI !


Un petit&nbsp;pi-hole&nbsp;&nbsp;et c’est réglé








Tradjincal a écrit :



Un petit&nbsp;pi-hole&nbsp;&nbsp;et c’est réglé





pi-hole est un serveur DNS, ça ne règle en pratique rien du tout sur le long terme. Les publicitaires sont des emmerdeurs mais pas des imbéciles, si tout le monde installe une interception DNS chez lui, les serveurs de publicité vont bien finir par faire la résolution de nom eux-même et leur envoyer l’adresse IP (même si effectivement ça ne marchera pas pour les serveurs mutualisés qui se partagent une même IP)



Oui mais il n’y a pas que la publicité qui est visée… et là au moins l’information est on ne peut plus claire.

Avec les statistiques le quidam peut comprendre de quoi il s’agit, je pense notamment à ceux ayant un accès limité en Mo ou Go, par exemple. (oui je sais en France c’est dépassé sur une connexion ADSL mais pas dans tous les pays)


Je vais également installer un pihole mais en étant conscient qu’aucun système n’est infaillible.

Si les publicitaires ne peuvent passer par devant ils tenteront par derrière !

À ce moment-là nous trouverons une autre solution également.


Google qui nous explique qu’un bloqueur de pub est plus dangereux pour notre vie privé que… les publicitaires qui sont payés pour voler de la vie privée et manipuler les gens <img data-src=" />


Déjà dit, mais ils ne disent pas que le souci vient des bloqueurs de pub, Web Request ne concerne pas que les bloqueurs de pub, le problème des limites de DNR non plus… et le problème soulevé par les dévs de Chromium est réel. Après on peut juste troller, mais ça ne fait pas avancer le débat.&nbsp;








Tradjincal a écrit :



Un petit&nbsp;pi-hole&nbsp;&nbsp;et c’est réglé





Je ne connaissais pas, merci <img data-src=" />



Dans ce cas nous sommes en droit d’attendre un article sur les projets de Ronald Minnich. <img data-src=" />


Quel rapport ?



De plus, tu n’es en droit d’attendre rien du tout.


@David_L, et pourquoi pas implement mettre leur 30.000 règles et autorisé certaine extension (genre ublock et adblock au pure hasard) a monté a 130.000, et si l’extension autorisée a besoin de plus demandé a l’utilisateur, en lui expliquant ce qu’il risque en acceptant.


pourquoi n’aurait-il pas le droit d’attendre ? Il peux, si il veut, personne ne va l’en empêcher <img data-src=" />


Ne pas confondre “être en droit de” et “avoir le droit de”. Et, oui, il peut toujours attendre. <img data-src=" />


Je suis plutôt d’accord avec @stratic pour le coup. La limitation devrait être simplement la RAM. Certes, une extension mal codée fera planter le PC, mais n’importe quelle application mal codée fera planter le PC. C’est souvent ça qui va faire que les utilisateurs ne vont plus l’utiliser au final.



Aussi, il n’y avait pas de limitation avant (à ce que je sache), et les extensions ne se sentaient pas obligées de prendre toute la RAM pour autant.



Je comprends le principe de vie privée, et effectivement Firefox va devoir rentrer dans la danse à un moment ou&nbsp; à un autre. Mais la limitation du nombre de règles n’a pas de rapport avec la protection de la vie privée.


Ce monsieur travaille chez Google dont les parcs de serveurs reposent sur des micro-logiciels propriétaires et lui et d’autres souhaitent sécuriser par l’ouverture ce qui peut l’être, à juste titre.

C’est exactement la même idée que les développeurs de chrome avec Net Request.



J’attends seulement un peu de cohérence, et accessoirement une information payée de qualité… mais comme les cerveaux de certains qui font des “rapports” ne s’achètent pas. <img data-src=" />


On parle des USA là… Ce genre de message fonctionnerait en Europe, mais pas dans une nation où même le fait d’être un admin ne suffit pas à te donner le droit de tout faire (cf Windows, etc.) simplement parce qu’ils ont peur d’éventuels procès.








Creak a écrit :



Aussi, il n’y avait pas de limitation avant (à ce que je sache), et les extensions ne se sentaient pas obligées de prendre toute la RAM pour autant.





&lt;my life&gt; La dernière fois que je me suis demandé pourquoi mon Chrome ramait, Ghostery avait avalé 1.7GiO à lui tout seul. Je pense que si je l’avais laissé faire, il ne se serait pas arrêté en si bon chemin. &lt;/my life&gt;



Enfin la preuve que les fantômes ont une existence matérielle, bonne nouvelle. <img data-src=" />


Merci d’avoir confirmé que tu mélanges tout.



Google et sécurité ne suffit pas pour établir un rapport entre les 2 sujets.



Quant aux cerveaux, j’ai peur que tu te sois fait avoir sur la qualité du tien pour faire des rapports entre des sujets.



Et le fait de payer ne donne pas tous les droits, surtout pas celui de faire le cuistre et de réclamer quelque chose parce que tu payes.








Idiogène a écrit :



Sinon vous avez le fichier hosts. Comme ça à vous de voir quel site essaye de vous entourlouper par d’autres moyens sophistiqués.







commehttps://someonewhocares.org/hosts/ Mais ça oblige à scripter ou faire la mise à la main.



“mes droits”… j’avais pris soin de déclarer “nous” dans mon premier message, mais là encore l’individualisme règne, c’est intéressant de noter que certains l’exploitent contre rémunération et que d’autres sont obligés de subir. <img data-src=" />



Je mélange quoi au juste ? [question tout à fait sérieuse]


Oui et je reprécise que c’était bien l’idée de dégager les noms de domaine pourris pour voir qui fait quoi ensuite sur navigateur.


Je pense que tout le problème est de savoir à qui (quel codeur/programme/extension) chacun accorde sa confiance

J’attend de voir ce que ça va donner en pratique … dans quelques temps (attendons le premier sois-disant-bug=scandale). Je vais donc mettre un Vivaldi, un Iridium et un Chromium dans une VM et archiver le tout pour faire le comparatif quand l’heure sera venue :)



Et sinon, Palemoon, c’est pas mal du tout (pour faire ce qu’on veut), et j’ai même monté mon propre serveur de synchro (FsyncMS) pour ne même plus dépendre de Mozilla <img data-src=" />


Cet article de blog est remplit de bullshit, c’est impressionnant.

J’ai suivi de près la discussion dans les Google Groups, et tous les arguments avancés par Google ont été démontés.&nbsp;

Perfs, sécurité, contrôle. Tout a été démonté.








Gortix Lab a écrit :



Le problème étant qu’il ne s’agit là que de charte, pas de règle, alors ne parlons même pas de loi !

Yep, il y a du boulot à revendre sur le sujet, et Google ne semble pas aller dans le bon sens, en même temps, la publicité s’élève à combien en pourcentage sur leur chiffre d’affaire ? Une belle somme à n’en point douter.

Du coup la pratique est pas prête de changer





Le detail des comptes de google :https://www.sec.gov/Archives/edgar/data/1652044/000165204419000004/goog10-kq4201…

Voir a la page 26 : Revenus en millions de $

Google advertising revenues : 116318

Google other revenues : 19906

Other Bets revenues : 595

Google = Ads, Android, Chrome, Google Cloud, Google Maps, Google Play, Hardware (including Nest), Search, and YouTube

Other Bets = Access, Calico, CapitalG, GV, Verily, Waymo, and X



A la louche, la pub represente 85% des revenus de google.









Cqoicebordel a écrit :



Cet article de blog est remplit de bullshit, c’est impressionnant.

J’ai suivi de près la discussion dans les Google Groups, et tous les arguments avancés par Google ont été démontés.&nbsp;

Perfs, sécurité, contrôle. Tout a été démonté.





En effet, personnellement je vois ca plus un moyen de prendre le controle de ce que fait l’extension pour mieux laissé passé ses propre pub (ou ralentir l’affichage des extensions pour poussé l’utilisateur a la désinstaller)

&nbsp;



Faudrait voir ce que wireshark en pense pour trancher. <img data-src=" />








Idiogène a écrit :



Sinon vous avez le fichier hosts. Comme ça à vous de voir quel site essaye de vous entourlouper par d’autres moyens sophistiqués.






L'ennui majeur du fichier hosts, c'est que ce n'est pas aisément désactivable si le site l'oblige (pour y accéder ou si l'anti-pub en fait trop, cf leboncoin où le module anti-pub de Kaspersky remplaçait tout par un about:blank le mois dernier), car il faut rebooter à chaque manipulation. Son entretien est aussi plus pénible.      






Installer un serveur DNS pour Windows avec des enregistrements "spéciaux" serait plus pratique.      






&nbsp;      






Pour la news, j'attend de voir. Si Google fait vraiment cela pour pouvoir nuire aux anti-publicités ou s'assurer l'ajout d'une whitelist, c'est qu'ils ont confiance dans l'extrème inertie de l'utilisateur et donc son incapacité à changer. Je peux pourtant dire d'expérience que quand un Lambda se retrouve sans antipub fonctionnel, il le voit... et il appele au secours :D (Firefox durant le problème de certificat).      






Du coup s'ils en font trop, ça sera un argument convaincant pour motiver des Lambda à switcher sur Firefox :D « L'antipub risque de ne pas fonctionner » :roll:


Oui à l’usage sur le long terme c’est très chiant. Surtout depuis quelques mois. :/

Mais pour faire un test ça reste l’option la plus rapide, avec wireshark en prime tu comprends déjà mieux ce qu’il se passe plutôt que le brouillard.

Après y’a pihole…


Pas convaincu.



Même si les règles d’interception sont suffisamment souples pour exprimer les conditions d’interception et de remplacement de contenu il y aura sans doute des usages qui vont devenir impossibles :



Comment changer le user-agent ?

Ignorer le CORS ?

Injecter du contenu dans une page qui tourne sur sharepoint ?


J’ai parlé de serveur DNS sous Windows car Pihole n’est pas une solution satisfaisante pour tout à chacun, déjà que sous Windows ce serait très limite…



Pihole, c’est très cher (il faut paier l’équipement), c’est coûteux en énergie (équipement online en permanence) et de fait l’est financièrement (EDF) et donc écologiquement (sauf si on a d’autres fonctions à lui ajouter pour justifier sa raison d’être). A la limite ce serait tolérable dans le cadre d’une action groupée, mais seul des groupes de geeks mettront ça en place.


Le coût électrique est dérisoire si branché à une box qui pourrait très bien faire serveur dns si les opérateurs s’y décidaient. Le seul coût c’est l’achat d’un PI et le temps passé à paramétrer. C’est un effort mental pas un effort financier.

A croire que dans l’inertie que tu évoques il y a aussi la peur de s’auto-gérer. <img data-src=" />


Les box consomment déjà trop d’énergie, pas la peine d’en rajouter. La pire bouffe 45 €/an à elle-seule de mémoire. Multiplié par des millions d’unités, c’est un gâchi énorme.




 Concernant l'auto-gestion, ça ne va pas dans l'air du temps écologique qui inclut aussi la maximisation des ressources disponibles. Est-ce que Lambda a besoin d'un Pihole qu'il aura en plus le plus grand mal à mettre en service/à entretenir et qui ne servira QU'A ÇA, alors qu'une seule unité pourrait faire ce travail pour un petit nombre de gens ?       






 Une petite association de 10/15 voisins avec un Pihole unique sera bien plus optimal, et la probabilité que l'un d'eux ait les connaissances requises augmente.       






 L'avenir n'est pas à la décentralisation -à l'excès- d'Internet contrairement à ce que des Bayard peuvent dire. Il est à la constitution de multitudes de petits groupes qui seront plus à même de partager leurs ressources pour monter et exploiter des services de ce type, mais à taille humaine.      






 Cela peut être rapporté à plein d'autres domaines : tout le monde n'a  pas besoin d'une imprimante 3D, etc. mais ce n'est pas pour autant que  ces personnes n'en aurait pas besoin. Sauf qu'ils ne vont pas en acheter une juste pour fabriquer un ou deux objets par an et se casser la tête à la faire fonctionner...

Je suis tout à fait d’accord mais le seul ennui c’est que la mutualisation est en pratique très limitée là où elle pourrait être utile et faire mal.

Par exemple de plus en plus de syndics qui sont complètement à l’ouest et imposent sans même y penser les accès individuels en fibre alors qu’il n’y a qu’un opérateur de dispo dans l’immeuble… et le problème n’est pas technique : c’est l’imposition d’un gestionnaire ayant trop d’immeubles à gérer qui rend possible ce type de bêtise. Donc ce n’est pas que technique ou écologique, c’est un problème de communication voir d’étanchéité entre publics et fonctions.

Défendre la forme associative c’est bien, mais lui donner un sens économique c’est hélas mieux. Là il y a une boite à monter pour diviser les coûts des abonnements par exemple, d’une pierre deux coups…



Je maintiens tout de même que la consommation individuelle d’un pi est négligeable et masquée par celle des box déjà là. Les objets connectés à tout va par contre ça c’est une catastrophe, sans parler du coût global des imprimantes 3D oui.


C’est clairement l’ère du temps. La brève sur le CERN plus haut le confirme aussi.



Mais je peux comprendre le syndic qui préfère individualiser, car sinon il faudrait gérer la question du partage de la BP alors que c’est un service essentiel à chacun, et parfois plus à certains qu’à d’autres <img data-src=" />



On devrait déjà mutualiser ce qui relève de l’optionnel, de l’obligatoire à usage trop irrégulier/rare, ou ce qui est facile à réaliser. Les Pihole et similaires, jusqu’à peut-être des services e-mails/blogs/autres, en passant par de vrais outils comme les tondeuses à gazon que l’on doit avoir alors que l’on s’en sert rarement…



Et je suis d’accord, la mise en place et l’organisation de l’entité qui gérera le tout sera le plus dur à faire.


Il y a syndics et syndics tu sais. Les syndics sont praticables humainement car la proximité culturelle le permet, ou pas. Dans beaucoup de cas aujourd’hui c’est l’aculturation par un non contrat douteux peu engageant pour les copropriétaires et c’est ce modèle d’individualisation de tous les tuyaux qui déconne.



Combien de locataires se soucient des charges communes ? Il n’y a pas d’offre payante de services informatiques proposant l’installation et la gestion d’un réseau commun et géré à chaque immeuble : les opérateurs gèrent donc tout sans dire que le coût est dérisoire pour eux. Faut pas espérer réussir à faire un réseau propre sans argument de coût.



Si tu démontres à un syndic qu’une fibre suffit à relier 20 logements et que sa gestion mutualisée est possible tout en permettant des usages en plus type DNS, hébergement des délibérations du syndic, partage de fichiers entre locataires bref, et est moins onéreuse qu’un des 4 gros du marché tu gagnes un contrat sur 10 ans d’entretien.



Les BP ne changent rien. D’ailleurs elles sont souvent dans le même meuble pour info comme quoi ! Tu peux évidemment faire des services webs individualisés mais sans demande les gros ne feront rien.


Ni le syndic de copropriété, ni le gestionnaire n’imposent quoique ce soit concernant l’accès fibre individuelle.

C’est la loi qui l’impose, et c’est un droit accordé à chacun de pouvoir demander un raccordement à la fibre.



Le syndic ne fait que mettre en oeuvre une convention de fibrage par un opérateur lorsque l’AG le vote.



Et d’ordre générale, le syndic de copropriété ne peut rien imposer sans validation en AG. Sinon cela signifie que vos copropriétaires et votre conseil syndical laissent la copro se gérer en pilote automatique.

Pour résumer : une catastrophe.








TheKillerOfComputer a écrit :



Les box consomment déjà trop d’énergie, pas la peine d’en rajouter. La pire bouffe 45 €/an à elle-seule de mémoire. Multiplié par des millions d’unités, c’est un gâchi énorme.









Ce n’est certainement pas moi qui vais empêcher des économies d’énergie, mais je pense que sur le pi-hole ce n’a pas grand sens. La consommation d’un Pi (qui ne servira pas qu’à ça, chez moi c’est hébergé sur le même que la domotique) ça doit bien faire 2 ou 3 kWh par an réels.



Des chiffres de la surconsommation que la pub (ou que le travail des extensions) engendre sur chaque équipement de la famille, je n’en ai pas, mais la réalité du coût énergétique est anecdotique par rapport au confort apporté. Chaque octet que le pi-hole aura bloqué constitue une également une économie d’énergie.





Les boxes sont aussi efficientes énergétiquement qu’elles sont performantes en terme de télécom ou d’équipement multimedia. La révolution en est un bel exemple: le player de ce machin c’est 12W en veille (12W à ne strictement rien faire, même pas afficher l’heure). Pour des perfs et fonctionnalités qui font rigoler toutes les boxes chinoises à 30€. Pour info la consommation maxi d’une Shield TV c’est 15W.



A tout hasard… Qu’est-ce qui interdirait à un propriétaire de demander un accès fibre dans sa cave et de se déclarer à l’Arcep ?

La suite c’est assez simple, mais cela doit être une décision de l’AG de déployer du RJ45 (ou de la fibre ahah) dans les parties communes.



Regarde shadow, c’est rentable car tout le monde certes sollicite leurs machines 2424 mais pas au même moment. Un immeuble avec une grosse fibre fera la même chose. Et au prix de la fibre l’idée est loin d’être économiquement non viable pour une copro.








Idiogène a écrit :



A tout hasard… Qu’est-ce qui interdirait à un propriétaire de demander un accès fibre dans sa cave et de se déclarer à l’Arcep ?

La suite c’est assez simple, mais cela doit être une décision de l’AG de déployer du RJ45 (ou de la fibre ahah) dans les parties communes.



Regarde shadow, c’est rentable car tout le monde certes sollicite leurs machines 2424 mais pas au même moment. Un immeuble avec une grosse fibre fera la même chose. Et au prix de la fibre l’idée est loin d’être économiquement non viable pour une copro.



La différence étant qu’avec la fibre, ce qui coûte c’est le gros oeuvre, pas la fibre elle-même. Que tu en places 1 ou 10, la différence de coût est minime.



Je ne faisais que repositionner le contexte et les droits de chacun. C’est surtout l’expression “le syndic impose” qui m’a fait tiquer.

Je pense qu’il n’y a rien qui puisse empêcher légalement que la copropriété propose ce service (et en cherchant un peu, il existe déjà des opérateurs proposant un wifi partagé).



La seule incompatibilité que j’y verrais, c’est qu’elle ne peut empêcher un copropriétaire ou un locataire de faire valoir son droit à la FTTH.


Le coût du gros œuvre est assuré par les opérateurs pour les copropriétés. (de mémoire)

Pour un particulier non.


Il impose sans même y penser car son représentant est rarement issu des copropriétaires de nos jours !

Faut voir ce que les grosses agences font.



Oui. Le modèle du wifi partagé peut fonctionner en cablé. (avec moins de coupures, pas de problèmes d’ondes, pas de multiplication des boitiers et tout le bazar que cela peut générer).



Oui mais ce locataire pourrait aussi voir qu’entre une fibre à 40€ et un RJ45 à 2€ il a de la chance d’avoir un propriétaire pas trop con…








Idiogène a écrit :



Le coût du gros œuvre est assuré par les opérateurs pour les copropriétés. (de mémoire)

Pour un particulier non.



Ce qui ne change rien au final : tant qu’à faire, autant mettre une fibre pour chacun.



Dans mon hypothèse un opérateur pourra toujours installer des fibres si il le souhaite.

Je dis seulement que le coût d’accès à internet est divisible par le nombre de copropriétaires.

Donc peut être réduit drastiquement sans pour autant en affecter le débit. La fibre, c’est surfait.


Je le redis, le syndic ne peut rien imposer aux copropriétaires en dehors des obligations légales inhérentes au droit des copropriétés.

Si le gestionnaire impose des choses, c’est que votre conseil syndical ne fait pas son travail. (et ne pas oublier que les membres du CS peuvent voir engagé leur responsabilité civile… D’où le fait qu’une assurance est recommandée)



Et je parle en connaissance de cause, je suis un emmerdeur fini pour Foncia en tant que membre et président du conseil syndical de notre copropriété. <img data-src=" />

Et en AG je vote contre le quitus, apportant à chaque fois la liste des manquements du gestionnaire motivant cette décision. Car accorder le quitus au syndic signifie lever tout recours possible quant à l’éventuelle négligence de sa gestion.

Et nous faisons joindre en annexe à chaque convocation d’AG la liste de tous les litiges et défauts de gestion constatés sur l’exercice.



C’est sûr que quand on laisse le syndic piloter en automatique, c’est plus simple pour lui… Mais faut juste aimer se faire tondre.








Idiogène a écrit :



Dans mon hypothèse un opérateur pourra toujours installer des fibres si il le souhaite.

Je dis seulement que le coût d’accès à internet est divisible par le nombre de copropriétaires.

Donc peut être réduit drastiquement sans pour autant en affecter le débit. La fibre, c’est surfait.



Dratisquement? Heu… Non. Dans le meilleur des cas (et je dis bien le meilleur), ca sera 7 ou 8% de moins. Pas plus. Et encore, seulement sur la mise en place de la fibre. Ensuite, il faut des équipements actifs qui gèrent plus de faisceaux laser simultanés (et ce à la fois côté NRO et côté immeuble), et ca, c’est très, très loin d’être gratuit.



existant:

rue -&gt; partie commune -&gt; gaine -&gt; logements

Je dis juste :

rue -&gt; partie commune | Local privé | -&gt; gaine -&gt; logements



La fibre est bien plus chère oui. Mais en RJ45 pas tellement. <img data-src=" />


Fermer