Web Share API : limites des permissions et replis sûrs

Web Share est un transfert médié par l’utilisateur. Une page propose un titre, un texte, une URL ou des fichiers pris en charge, et le navigateur peut ouvrir une interface système après l’activation d’un contrôle visible. La page ne choisit pas le destinataire, n’inspecte pas sa liste et ne reçoit pas la preuve qu’une autre application a terminé la livraison. BotBrowser peut valider l’interface de partage et ses replis dans des contextes contrôlés, mais il ne peut pas sélectionner la cible de l’utilisateur, contrôler la feuille système ni contourner la médiation du navigateur.

TL;DR

• Détectez Web Share et gardez un repli utile de copie, téléchargement ou lien normal.
• Appelez navigator.share() uniquement depuis une action délibérée avec activation transitoire.
• Validez avec navigator.canShare() lorsqu’il existe, sans le considérer comme une preuve de livraison.
• Gérez l’annulation et l’échec sans effacer la tâche.
• Web Share n’énumère pas les destinataires, n’accorde pas de permission et n’établit pas d’identité.

Sommaire

• Capacité et activation
• Validation des données et confidentialité
• Annulation et repli accessible
• Tests avec BotBrowser
• Permissions Policy et contextes intégrés
• Questions fréquentes
• Conclusion

Capacité et activation

La spécification W3C Web Share et le guide MDN Web Share API décrivent une capacité conditionnelle. Le contexte sécurisé, la politique du navigateur, le document courant et l’intégration au système influencent la disponibilité. Testez navigator.share au moment de l’utilisation : une méthode présente au chargement peut être rejetée plus tard si le contexte, les données ou l’activation ne conviennent plus.

L’activation transitoire est brève. Placez l’appel dans le gestionnaire de clic ou de clavier du bouton ; ne le différez pas par minuteur, requête réseau indépendante ou chargement de page. Une action visible indique le résultat attendu et fournit une chaîne d’activation valide. Préparez les données sûres avant le clic et limitez le gestionnaire à une validation synchrone et bornée.

La limite d’activation n’est pas une permission. Une promesse résolue indique seulement le transfert local exposé à la page : elle ne prouve ni l’ouverture d’une feuille native, ni le choix d’un destinataire, ni la livraison. L’annulation est normale ; gardez page, titre, formulaire et contrôle initiateur intacts. Les tests doivent décrire l’état du produit, jamais l’identité du navigateur ou de l’appareil.

Validation des données et confidentialité

Les données peuvent inclure title, text, url et des fichiers lorsque le navigateur les prend en charge. Construisez-les depuis l’objet visible, sans jetons d’accès, paramètres privés, identifiants ou métadonnées cachées. MDN Navigator.share() documente la méthode ; lorsque cette fonction est disponible, navigator.canShare() vérifie l’acceptation du jeu courant.

canShare() vérifie une capacité, pas un destinataire : il ne révèle ni applications installées, ni contact, ni issue du transfert. Les membres inconnus sont ignorés ; un champ supplémentaire ne prouve pas le rejet de l’objet. N’utilisez pas les variations de canShare() comme empreinte : fichiers, taille, politique et plateforme peuvent expliquer la différence.

Séparez autorisation et partage. Un document privé ne devient pas public parce qu’un bouton existe. Revérifiez l’accès avant de construire URL ou export et expliquez l’expiration avant le transfert. Le service récepteur authentifie chaque requête indépendamment ; la feuille de partage n’est jamais un signal d’autorisation serveur.

Pour l’analytique, retenez seulement un résultat borné comme share-request-resolved, share-cancelled, share-rejected, copy-success ou download-started. Ne journalisez ni texte brut, URL privées, fichiers ni destinataires. Déclarez finalité et durée de suppression ; les principes de confidentialité du W3C soutiennent cette minimisation.

Annulation et repli accessible

AbortError signifie annulation ou absence de cible utilisable : revenez à la tâche courante, sans l’interpréter comme une décision. Les autres erreurs peuvent signaler données invalides, fichier non pris en charge, politique ou panne de plateforme. Affichez un état bref et gardez copie, téléchargement et lien normal ; ne rechargez pas, n’effacez pas le brouillon et ne réessayez pas en boucle.

Le repli préserve l’intention : copiez une URL choisie, téléchargez une représentation autorisée ou exposez un lien dans le document. Chaque action a un libellé visible et un parcours clavier. Si le presse-papiers échoue, laissez l’URL sélectionnable ; si la génération attend, indiquez progression, réessai et annulation. L’absence de feuille ne doit jamais masquer un contenu essentiel.

Utilisez noms accessibles, ordre de focus et texte d’état. Rendez le focus au contrôle après annulation, sauf déplacement volontaire. Annoncez « Partage annulé » ou « Lien prêt à être copié », jamais exception brute ou URL privée. Le repli doit fonctionner avec zoom, grands caractères, contraste élevé, clavier et lecteur d’écran ; une icône seule reçoit un nom accessible et une infobulle.

Les composants intégrés et pages hors ligne gardent le même contrat : lien normal ou téléchargement si le document supérieur échappe au composant ; préparation locale expliquée. Testez titres longs, écritures non latines, texte bidirectionnel et statuts traduits. L’objet doit rester visible et intact après annulation, quelle que soit la feuille affichée par le système.

Tests avec BotBrowser

BotBrowser valide l’interface et les replis dans des contextes contrôlés, mais ne sélectionne ni cible ni destinataire et ne prouve pas la livraison. Une fixture peut supprimer navigator.share, produire AbortError ou une autre erreur, varier canShare() et vérifier copie/téléchargement. Utilisez données synthétiques et consignez navigateur, contexte, sécurité, activation, classe de données, promesse, repli et révision, sans comptes, URL privées, exports ni destinataires.

Interprétez un succès étroitement : le contexte a accepté la demande et la page a conservé son repli. Cela ne prouve ni l’existence d’une cible, ni une future feuille identique, ni le transfert terminé. Répétez après changement de navigateur, système ou données et séparez surveillance de production et preuve de compatibilité.

Contrat de décision pratique. Définissez objet, champs, règle d’autorisation et repli avant le bouton. Une page publique partage son URL canonique ; un espace privé peut exiger lien court contrôlé ou export confirmé. Le navigateur ne rend pas ces choix sûrs automatiquement.

Un seul propriétaire prépare la représentation, indique quand elle est prête, si elle reste locale et comment elle est supprimée après annulation. En cas d’échec, laissez la tâche lisible et exposez un réessai : un bouton désactivé sans explication n’est pas un repli. « Préparer le téléchargement » et « Copier le lien » offrent une alternative explicite.

Séparez état du contrôle (available, unavailable, preparing, busy) et état du résultat (cancelled, rejected, copied, downloaded, awaiting). Une promesse résolue ne signifie jamais « livré » ; une annulation remet le contrôle à l’état disponible.

Employez un parcours borné par classe : URL vérifiée immédiatement, fichier vérifié par canShare() et téléchargeable, texte soumis à revue de longueur et de confidentialité. Ne modifiez pas répétitivement des données rejetées ; montrez le repli et laissez décider entre copier, télécharger ou continuer sans partage.

« Inviter » est une requête serveur avec autorisation, confirmation et audit distincts ; « Copier le lien » reste local ; « Télécharger » crée un fichier local ; « Partager » ouvre un transfert choisi par l’utilisateur. Leurs limites et significations de succès diffèrent.

Avant sortie, retirez jetons, routes internes et données d’autrui ; affichez expiration et audience des URL temporaires. Le récepteur pouvant conserver ou transférer le lien, le service valide chaque requête. Web Share ne remplace pas le contrôle d’accès.

Le statut doit rester factuel et réversible : résolution ne prouve pas « feuille ouverte ». « Partage annulé » laisse la page inchangée ; « Copie indisponible » doit être suivi d’un lien sélectionnable ou téléchargement. Ne supposez ni cible, ni contact choisi, ni acceptation par une autre application.

Traitez les variations de navigateur comme normales : URL sans fichiers, activation plus stricte ou frame sans feuille. Gardez la même tâche essentielle et testez les contrôles visibles, pas une disposition fournisseur.

La revue d’accessibilité couvre activation et annulation : clavier, retour au contrôle, repli sans pointeur, statut sans contenu privé, titre localisé qui se renvoie à la ligne, couleurs forcées et zoom qui préservent les choix.

La revue de confidentialité demande ce que l’application apprend : clic délibéré et résultat local borné, jamais inventaire de destinataires, graphe de contacts, profil système ou confirmation. N’ajoutez aucun champ analytique sans décision concrète à améliorer ; supprimez les diagnostics après le support.

Une fixture interne couvre méthode absente, appel hors clic, données valides, annulation, fichier incompatible et erreur. Chaque cas préserve le document et indique l’action suivante. Rejouez-la après ajout de fichiers, changement d’URL, intégration ou politique ; un ancien succès ne prouve pas le nouveau contexte.

Vérifiez type et taille avant l’action principale ; expliquez le dépassement et gardez un repli de copie. Les fichiers temporaires ont une durée de vie gérée par l’application, sont libérés après annulation ou achèvement et régénérables. Ne téléversez jamais silencieusement pour contourner une taille ou changer l’audience.

Confrontez capacité et contexte sécurisé : HTTP, iframe restrictive et HTTPS supérieur peuvent diverger. Présentez le même repli et décrivez un problème de document ou navigateur, non une permission choisie par l’utilisateur.

Testez l’annulation avant préparation, après ouverture système et après disponibilité du repli. Aucun contrôle ne doit rester désactivé, aucun téléchargement être dupliqué et aucun champ perdu ; une seconde activation lance une tentative unique avec validation fraîche.

Le statut final reste local : région dynamique, libellé ou ligne d’état, jamais état de compte ni enregistrement « livré ». Une invitation serveur est une opération confirmée séparée avec réponse et audit propres.

Permissions Policy et contextes intégrés

La disponibilité diffère entre document supérieur et iframe. La liste par défaut est self; une iframe de même origine peut ne pas exiger de délégation. Une origine différente nécessite une délégation autorisée ; un embed minimal peut déclarer allow="web-share". Cela ne choisit pas de destinataire et n’accorde aucune permission.

<iframe src="https://share.example.test/panel" title="Panneau de partage" allow="web-share"></iframe>

En-tête, attribut, contexte sécurisé et implémentation comptent. Permissions-Policy: web-share=() désactive la fonction et ne peut être rouvert par allow. NotAllowedError peut refléter politique, activation ou fichier bloqué, non un refus utilisateur. Inspectez le contexte et gardez le repli ; testez séparément iframe déléguée et non déléguée.

Une machine d’états de partage copiable

Gardez explicites capacité, activation, annulation et concurrence. Cette machine appartenant à la page ne simule pas de feuille native et ne promet pas la livraison.

const shareState = { value: 'idle' };
async function runShare(data, render, fallback) {
  if (shareState.value === 'sharing') return;
  if (!window.isSecureContext || typeof navigator.share !== 'function') return fallback('unavailable');
  if (navigator.canShare && !navigator.canShare(data)) return fallback('unsupported-data');
  shareState.value = 'sharing';
  render(shareState.value);
  try {
    await navigator.share(data);
    shareState.value = 'complete';
  } catch (error) {
    shareState.value = error?.name === 'AbortError' ? 'cancelled' : 'failed';
    fallback(shareState.value);
  }
  render(shareState.value);
}

Le garde-fou contre une seconde demande est un état applicatif. InvalidStateError concerne une demande active ou invalide ; NotAllowedError reflète généralement politique, activation ou fichier bloqué. Restaurez le contrôle et le repli. Les timings et surfaces varient ; rapportez seulement le résultat local, jamais « livré » universellement.

Tableau de décision et résultats attendus

Condition	Décision de la page	Résultat visible attendu
HTTPS supérieur, méthode présente, URL valide, clic récent	Appeler share() une fois	Occupé puis terminé ou annulé ; repli disponible
HTTP ou contexte intégré restreint	Ne pas appeler	Expliquer l’indisponibilité, montrer copie/téléchargement
Iframe sans politique déléguée	Capacité indisponible	Même repli accessible, sans invites répétées
Champs connus invalides ou non pris en charge	Garder les données	Proposer lien ou téléchargement
NotAllowedError	Classer politique, activation ou fichier bloqué	Restaurer contrôle et statut de repli
InvalidStateError ou concurrence	Garder un propriétaire	État occupé/réessai sans doublon
Annulé ou aucune cible (AbortError)	État local cancelled	Préserver la tâche, repli, puis idle

Ce tableau est un contrat produit, pas une promesse de feuille système. Gardez la tâche essentielle dans chaque ligne ; pour une ressource privée, répétez l’autorisation avant l’URL ; pour un fichier, vérifiez type et taille et conservez le téléchargement. Les membres inconnus sont ignorés ; un champ connu invalide ramène au repli sans modifier la tâche.

Questions fréquentes

allow="web-share" accorde-t-il une permission de partage ?

Non. Il délègue une fonction contrôlée par politique lorsque la politique environnante l’autorise. Activation, contexte sécurisé, données, navigateur et choix système restent nécessaires.

Une promesse navigator.share() résolue prouve-t-elle la livraison ?

Non. Elle établit uniquement le résultat exposé à la page. La plateforme peut accepter le transfert sans révéler destinataire ni achèvement ; gardez état factuel et repli.

Pourquoi deux boutons valides peuvent-ils produire NotAllowedError ?

Activation, politique de frame, contexte sécurisé ou fichier bloqué peuvent différer. Une demande active ou invalide relève plutôt de InvalidStateError. Consignez le contexte et restaurez le repli, sans traiter ces erreurs comme preuve d’identité ou permission.

Conclusion

Web Share est un transfert initié par l’utilisateur, à capacité conditionnelle et sans garantie de destinataire ou de livraison. Vérifiez à l’usage, préservez l’activation, validez, traitez l’annulation normalement et gardez copie, téléchargement ou lien au premier plan. BotBrowser rend les contrôles répétables ; cible, médiation, autorisation et confidentialité restent aux systèmes propriétaires.

À lire aussi

• Web Share API et partage initié par l’utilisateur
• Empreinte des permissions du navigateur
• Prise en charge des fonctions par le navigateur et qualité des fonctions

Sources

• W3C Web Share
• W3C Permissions Policy
• MDN Web Share API
• MDN Navigator.share()
• Principes de confidentialité du W3C
• Fonctionnalités avancées de BotBrowser