Publicités YouTube dans Safari : elles y restent ou quoi ? Voyons voir.
Nous avons reçu un nombre croissant de plaintes ces derniers temps concernant les publicités YouTube sur iOS qui ont réussi a éviter nos filtres. C'est à noter que ces plaintes concernaient spécifiquement le visionnage de YouTube dans le navigateur Safari. Il s'est avéré que YT a employé un nouvel algorithme pour montrer les publicités aux utilisateurs autorisés, et cela a eu un effet négatif sur la qualité générale du blocage des publicités. De facto, à l'heure actuelle, YouTube charge les clips publicitaires presque de la même manière que les vidéos ordinaires.
Nous avons trouvé une solution qui fonctionne pour Safari sur iOS, mais elle laisse beaucoup à désirer par rapport aux autres plateformes et navigateurs. Pour faire simple, nous bloquons les vidéos courtes (99,99 % d'entre elles sont des publicités).
Mais avec une telle approche, l'expérience de l'utilisateur en prend un coup - soit il y a un retard notable avant le chargement de la vidéo, soit il y a un espace vide à la place de la publicité :
Version brève
Il y a quelques mois, YouTube a commencé à utiliser la même méthode pour montrer des publicités vidéo aux utilisateurs de Chrome, mais nous avons pu gérer ça sans trop de problèmes. Quelle est la particularité de Safari ? Malheureusement, le blocage de contenu dans Safari est très limité par rapport aux logiciels bloqueurs de contenu des autres navigateurs. Il n'y a pas eu beaucoup de changements dans l'API de blocage de contenu de Safari depuis son introduction en 2015.
En fonction de votre système d'exploitation, voici à quoi vous pouvez vous attendre :
- iOS/iPadOS: la solution actuelle est la meilleure solution possible dans ces circonstances. Nous devrons nous y accommoder, à moins qu'Apple ne fasse des changements radicaux (nous y reviendrons plus tard).
- Sur macOS:
- Si vous utilisez le logiciel autonome AdGuard pour Mac, ce problème ne vous regarde pas. Très probablement, vous n'avez même pas remarqué les publicités infiltrées en question.
- Si vous utilisez AdGuard pour Safari, assurez-vous que l'extension "Blocage avancé" est activée. Cette extension prend en charge une partie des fonctionnalités dont Safari Content Blocking manque. Malheureusement, cette solution ne peut pas être extrapolée sur iOS/iPadOS.
Si Safari souhaite rester pertinent en termes de blocage de contenu, certaines choses doivent être améliorées. Nous sommes prêts à aider et à fournir toute l'expertise nécessaire. En fait, nous avons soumis de nombreux rapports de bogue et demandes de fonctionnalités au cours des dernières années.
Si vous souhaitez savoir ce qui ne va pas avec le blocage du contenu de Safari, lisez la suite. Vous aurez peut-être besoin de quelques connaissances techniques. Si vous ne vous sentez pas assez expert(e), n'hésitez pas à faire défiler la page jusqu'au dernier chapitre.
Comment le blocage de la pub fonctionne-t'il dans Safari
Avant de parler des limites de Safari et de la façon dont AdGuard les compense, il serait préférable d'apprendre d'abord comment fonctionne le blocage de contenu dans Safari.
Le Bloqueur de contenus est essentiellement une extension de votre application qui s'exécute dans un processus séparé, et le seul but de cette extension est de servir un fichier JSON avec la liste des règles de blocage de contenu. Ces règles sont ensuite utilisées par Safari pour effectuer la partie du travail dite "blocage" .
Ce diagramme illustre le fonctionnement des bloqueurs de contenu dans Safari
Chaque règle de blocage de contenu est un objet JSON qui se compose de 2 parties : " déclencheur " et " action ".
La partie " déclencheur " définit les demandes auxquelles la règle doit être appliquée. Et la partie "action", comme son nom l'indique, définit ce qui sera fait à la requête correspondante.
À quoi ressemble une règle de blocage dans Safari
Il y a aussi des règles cosmetiques cachant des éléments de la page correspondant au sélécteur CSS spécifié :
Règle cosmétique de Safari
Nous n'avons étudié que deux types d'actions : "bloquer une requête" ou "masquer un élément", mais il en existe quelques autres :
- Une qui permet de désactiver d'autres règles correspondantes
- Une action pour bloquer les cookies
- Une autre pour mettre à niveau la connexion vers HTTPS.
Maintenant que nous savons ce qu'est le blocage de contenu Safari et comment il fonctionne, parlons de ses limites.
Les limites dans Safari
Voici une courte liste des limitations qui nous dérangent le plus (nous - la communauté de bloqueurs de publicité). Certaines d'entre elles peuvent être compensées dans une certaine mesure, mais il s'agit toujours de solutions de contournement et non de solutions définitives.
- Pas d'outils de débogage
- Syntaxe différente (peut être partiellement résolue)
- Compilation lente
- Limite de 50 000 règles par bloqueur de contenu (très pénible, mais nous avons appris à vivre avec).
- Support limité des expressions régulières
- Le blocage de contenu n'est pas une priorité pour l'équipe Safari.
Analysons chacun de ces problèmes.
Pas d'outils de débogage
Nous allons commencer par quelque chose qui est simple mais qui n'a pas de solution. Pour créer des règles de filtrage efficaces, les développeurs doivent les déboguer, ce qui nécessite des outils de débogage. Or, le blocage de contenu dans Safari n'est accompagné d'aucun outil de débogage. Le seul outil utile aux responsables des filtres est la console du navigateur, qui permet de voir quelles requêtes ont été bloquées. Il est donc impossible de comprendre quelle règle bloque telle ou telle requête et le processus de recherche peut s'avérer très pénible. Il n'existe pas non plus de moyen approprié pour déboguer les règles cosmétiques.
Console de navigateur dans Safari
Cela rend le développement de filtres pour Safari très inefficace, et de nombreux responsables de filtres donnent la priorité aux autres navigateurs plutôt qu'à Safari lorsque cela est possible quand il s'agit de créer une règle de filtrage. Cela entraîne à son tour une mauvaise qualité des listes de filtres Safari par rapport aux autres navigateurs.
Different syntax
Les filtres AdGuard, EasyList et uBlock sont tous basés sur la syntaxe de noyau originelle d'Adblock Plus. Il a été élaboré, mais sa partie " noyau " est la même pour tous les bloqueurs de contenu populaires.
Anatomie commune des règles de filtrage
Et comme vous l'avez vu sur les illustrations précédentes, les règles de blocage de Safari n'ont rien en commun avec cette syntaxe. C'est un problème parce que nous ne souhaitons pas créer de listes de filtres spéciales "réservées à Safari". Et c'est pas une question de nos développeurs qui sont fainéants (ils ne le sont pas) : Safari ne fournit tout simplement pas d'outils suffisants pour développer ce genre de listes.
Ce que nous souhaitons, c'est de pouvoir utiliser les bonnes vieilles listes de filtres traditionnelles comme les filtres AdGuard et EasyList.
Notre solution
La solution : convertir nos règles en règles de blocage de contenu de Safari automatiquement. C'est ce que fait AdGuard en temps réél sur votre propre appareil.
Solution possible pour les problèmes de syntaxe de Safari
Vous pouvez facilement voir que tout travail supplémentaire ne rencd pas les bloqueurs plus effectifs.
Une compilation lente
Safari compile chaque bloqueur de contenu JSON en un "arbre de préfixes", ce qui accélère les requêtes.
Mais la compilation de cet arbre de préfixes est lente. Par exemple , is slow. For example, vous pouvez voir la performance du profileur, il ne prend pas plus de deux secondes sur un nouveau MacBook Pro pour compiler un JSON contenant un peu plus de 30000 règles (une taille très réaliste pour un filtre).
Les temps de la compilation dans Safari
Et c'est lent. Comparez avec les bloqueurs de contenu sur d'autres plateformes : l'application AdGuard pour Android a besoin de moins d'une seconde pour analyser et compiler une liste de plus de 100 000 règles. La différence évidente, cependant, est que notre application Android utilise une syntaxe différente qui n'est pas aussi compliquée que les expressions régulières, peut-être pas aussi flexible, mais elle est optimisée spécifiquement pour faire correspondre les URL.
Les utilisateurs ne voient rien de tout cela et ne sont pas concernés directement , mais cet aspect est en fait assez important car il constitue le point de blocage qui entraîne d'autres limitations.
La limite de 50 000 règles
Maintenant que nous savons que la compilation est assez lente, il devient plus facile de comprendre la prochaine limitation. Un seul bloqueur de contenu ne peut contenir plus de 50 000 règles, et il s'agit d'une limite codée en dur pour Safari. Les développeurs d'Apple ont confirmé que la raison principale de cette limitation est la lenteur de la compilation. Il se peut qu'ils augmentent un peu la limite parce que les nouveaux appareils sont plus rapides, mais cela ne résoudra pas tous les problèmes comme par magie.
Il n'y a pas de place pour une amélioration substantielle tant que les règles sont basées sur l'utilisation d'expressions régulières. Et ne vous laissez pas tromper par un chiffre apparemment élevé : par exemple, le filtre de base AdGuard + EasyList comportent 100 000 règles au total, et il ne s'agit que de deux filtres. Il n'est pas rare que les utilisateurs d'autres plateformes disposent de 5 à 10 filtres simultanément, voire plus.
Notre solution
En fait, il existe un assortiment de solutions à ce problème. Malheureusement, même combinées, elles ne donnent pas le résultat désiré. Cependant, elles ne sont pas sans intérêt.
Optimisation des filtres
En tant que développeurs de filtres, nous faisons un effort pour les optimiser de suite pour Safari. L'une des choses que nous faisons alors c'est la compilation des règles similaires qui cachent les éléments en une seule règle majeure. Comme vous povez voir dans cet exemple, cinq règles ont été combinées en deux :
Optimization des filtres dans Safari
Ces mesures aident beaucoup, mais ce n'est pas assez, hélas.
Élimination des règles obsolètes
Une autre chose que nous faisons c'est la suppression les règles obsolètes et rarement utilisées de ces versions optimisées des filtres. Grâce aux utilisateurs de l'extension pour navigateur AdGuard qui se portent volontaires pour partager des statistiques anonymes sur l'utilisation des filtres (cette option est désactivée par défaut), nous savons quelles règles sont moins utilisées que les autres. Nous construisons des versions spéciales des listes populaires (comme le filtre de Base AdGuard) sans les règles obsolètes et rarement utilisées.
Les responsables des filtres peuvent utiliser des "conseils" spéciaux pour contrôler quelles règles doivent être conservées malgré le processus d'"optimisation"
Oui, les filtres sont plus petits, mais au final, la qualité du blocage des publicités en est affectée. De plus, cette méthode n'est pas infaillible : certaines règles ne sont pas prises en compte dans les statistiques parce qu'elles ne sont pas utilisées dans l'extension du navigateur, certains développeurs de filtres n'ajoutent pas de telles indications à côté de leurs règles, etc.
Bloqueurs de contenus multiples
Une autre solution à laquelle presque tous les développeurs de bloqueurs de publicité Safari ont recours consiste à diviser le bloqueur de publicité en plusieurs bloqueurs de contenu indépendants.
AdGuard pour iOS consiste de 6 bloqueurs de contenu
Techniquement, chacun d'entre eux dispose de moins de 50000 règles, mais au total ils en exercent beaucoup plus. Mais dans le domaine du blocage des publicités, 50 000 fois 6 ne font pas 300 km pour plusieurs raisons :
- Il n'est pas rare qu'un filtre adresse les règles d'un autre filtre. Mais avec cette approche, les différents bloqueurs de contenu Safari sont complètement indépendants, et les règles qu'ils contiennent ne peuvent pas s'influencer mutuellement.
- Si un filtre comporte plus de 50 000 règles, vous ne pourrez plus l'ajouter du tout.
Nous continuerons toujours à découper AdGuard en morceaux pour l'adapter aux limitations de Safari, mais vous pouvez maintenant voir pourquoi ce n'est pas amusant.
Basse priorité de développement
Nous avons gardé ce moment-ci pour la fin, car c'est assez illustratif. Voici le journal des modifications apportées à l'API de blocage de contenu de Safari au cours des six dernières années :
2015 - Le blocage du contenu de Safari est implémenté
2016 - Ajout d'une nouvelle fonctionnalité (make-https) et correction de quelques bogues majeurs.
2017 - Ajout d'une autre nouvelle fonctionnalité (if-top-url) - qui est presque inutilisable - et ajout de bloqueurs de contenu à WKWebView, correction de quelques bogues.
2018 - Correction de quelques bogues, remaniement du code.
2019 - Correction de quelques bogues
2020 - Pas de changements importants
Il est clair qu'à ce rythme, il est impossible de rattraper les dernières technologies d'insertion publicitaire. Quelque chose doit changer. Nous espérons que les priorités des développeurs de Safari s'orienteront vers la résolution de ces problèmes, et nous sommes prêts à fournir toute l'aide nécessaire.
Que faire
La communauté des bloqueurs de publicité tire la sonnette d'alarme depuis des années. Voici quelques exemples de demandes de fonctionnalités qui ont été déposées :
Celle-ci est particulièrement intéressante car elle permettrait de résoudre le problème des publicités YouTube.
- Retour d'information sur les questions les plus pressantes pour les développeurs d'outils de blocage de contenu
- Demande de fonctionnalité pour permettre le blocage par CNAMEs
- Une demande de fonctionnalité pour augmenter la limite des règles à 300k
- Une demande pour un meilleur outil de débogage
Il y en a bien d'autres, mais ce n'est qu'une petite partie des problèmes les plus urgents. Faisant partie de cette communauté, nous pensons avoir fait plus qu'assez pour attirer l'attention d'Apple sur ce problème. Si vous avez besoin d'aide supplémentaire, quelle qu'elle soit, nous serons heureux de vous assister.
Nous en sommes au point où des changements doivent absolument intervenir. Sinon, tout le monde sera perdant - sauf les fournisseurs de publicité.
UPD: il semble que les choses changent en 2021. Par exemple, la limite de 50k a été élevée jusqu'à 150k, et ce n'est pas tout.
