Publié le 19 novembre 2024
Lors de la conférence Google I/O 2024, nous avons présenté quelques premières conceptions des modifications à venir apportées au menu des extensions, qui permettront aux utilisateurs de mieux contrôler les sites auxquels les extensions peuvent accéder. Nous allons bientôt commencer à tester ces modifications auprès d'un petit pourcentage d'utilisateurs dans Canary, et espérons les déployer plus largement à l'avenir.
Lorsque nous avons discuté de ce changement avec les développeurs par le passé, nous avons souvent entendu des inquiétudes concernant l'impact de la modification de la façon dont les extensions peuvent demander des autorisations d'hôte au moment de l'installation. Le nouveau menu n'a aucune incidence sur le comportement par défaut. Les extensions continueront d'avoir accès à tous les hôtes demandés au moment de l'installation. L'objectif de ces modifications est de permettre aux utilisateurs de découvrir plus facilement les commandes déjà disponibles.
Cet article présente ce à quoi vous devez vous attendre et comment préparer vos extensions avec une nouvelle API pour gérer les cas où l'accès à une page a été refusé par l'utilisateur.
Ce qui change
Pour donner aux utilisateurs plus de contrôle, nous allons lancer un nouveau menu d'extensions. Les extensions continueront d'avoir accès à tous les hôtes demandés au moment de l'installation, mais les utilisateurs pourront désormais contrôler plus facilement l'accès par extension.
Le nouveau menu (illustré avec la conception actuelle, qui peut changer) indique plus clairement les extensions pouvant s'exécuter sur une page et permet aux utilisateurs de modifier l'accès s'ils le souhaitent. Un utilisateur peut également empêcher l'exécution de toutes les extensions sur un site spécifique. Comme indiqué, aucun des paramètres disponibles ni des paramètres par défaut ne change. Notre objectif est de faciliter la découverte de ce que nous proposons déjà.
Ajouter une demande d'accès à un site
Nous avons conçu une nouvelle API pour compléter ces modifications, avec l'aide d'autres navigateurs et développeurs du groupe de la communauté WebExtensions.
Si un utilisateur a refusé l'accès à une page, les extensions peuvent désormais demander l'accès à l'aide de la nouvelle API permissions.addSiteAccessRequest. Lorsqu'une extension agit de la sorte, un message "Autoriser" s'affiche à côté de la pièce du puzzle de l'extension dans la barre d'outils. Voici une conception que nous explorons:
Lorsqu'un utilisateur clique sur "Autoriser" dans le menu des extensions, l'extension se voit accorder un accès permanent à l'hôte. L'utilisateur peut à nouveau le refuser à l'avenir en accédant au menu des extensions ou à la page chrome://extensions. Cliquez sur "Autoriser 1 ?" dans la barre d'outils pour accorder un accès immédiat plus rapidement.
Les extensions peuvent appeler permissions.addSiteAccessRequest avec un tabId pour afficher une demande d'autorisation pour cet onglet. Vous pouvez utiliser la détection de fonctionnalités dès aujourd'hui dans votre extension. L'API n'a aucun effet pour les utilisateurs qui n'ont pas accès au nouveau menu, mais elle sera utile pour ceux qui y ont accès à mesure qu'il sera déployé progressivement.
chrome.tabs.onUpdated.addListener(async (tabId, changes) => {
if (typeof changes.url !== 'string') return;
const url = new URL(changes.url);
// If we are on the /checkout page of example.com.
if (url.origin === 'https://example.com' && url.pathname === '/checkout') {
const hasPermission = await chrome.permissions.contains({
origins: ['https://example.com/*']
});
// We already have host permissions.
if (hasPermission) {
return;
}
// Add a site access request if the API is available.
if (chrome.permissions.addSiteAccessRequest) {
chrome.permissions.addSiteAccessRequest({ tabId });
}
}
});
Dans cet exemple, nous n'ajoutons une requête que si l'utilisateur se trouve sur la page /checkout. Vous pouvez consulter le code complet dans notre dépôt chrome-extensions-samples.
Les extensions doivent faire preuve de prudence lorsqu'elles demandent aux utilisateurs l'accès. Les utilisateurs sont plus susceptibles d'ignorer les requêtes bruyantes, et Chrome peut limiter les requêtes excessives. Un utilisateur peut également choisir de désactiver la possibilité pour une extension d'afficher des requêtes. Par conséquent, vous ne devez demander l'accès que dans des situations spécifiques, lorsque vous êtes sûr que l'utilisateur souhaite interagir avec votre extension.
Les requêtes sont associées à un onglet spécifique et sont automatiquement effacées lorsqu'un utilisateur accède à une autre origine. Une méthode removeSiteAccessRequest correspondante est disponible pour effacer une requête de manière explicite (par exemple, si une requête est liée à un chemin d'accès particulier).
Étant donné que cette API est associée au nouveau menu des extensions, les appels seront ignorés si le nouveau menu n'est pas activé. Toutefois, nous vous encourageons à essayer l'API dès aujourd'hui et à envisager de l'adopter dans votre extension. Vous offrirez une expérience utilisateur optimale à mesure que les modifications du nouveau menu s'appliqueront progressivement à davantage d'utilisateurs.
Pour en savoir plus sur l'utilisation des autorisations facultatives, consultez la documentation sur les autorisations.
Essayer
L'API est activée par défaut dans Chrome 133.0.6838.0 et versions ultérieures (actuellement dans Chrome Canary). Pour activer le nouveau menu, accédez à chrome://flags et activez le flag "Extensions Menu Access Control" (Contrôle de l'accès au menu des extensions).
Pour rappel, cette fonctionnalité est toujours en cours de développement et peut continuer à évoluer. Nous vous recommandons de procéder à des tests dans Chrome Canary pour profiter de l'expérience la plus récente.
Vous pouvez nous faire part de vos commentaires sur la nouvelle conception dans la liste de diffusion chromium-extensions. Nous les tiendrons compte au fur et à mesure que nous travaillerons sur le nouveau menu.