Omgaan met schendingen van de op afstand gehoste code

Op afstand gehoste code, ofwel RHC, is de term die de Chrome Web Store gebruikt voor alles wat door de browser wordt uitgevoerd en dat afkomstig is van een andere locatie dan de eigen bestanden van de extensie. Denk hierbij aan JavaScript en WASM. Data of zaken zoals JSON of CSS vallen hier niet onder.

Waarom is RHC niet langer toegestaan?

Met Manifest V3 moeten extensies nu alle code die ze gebruiken in de extensie zelf bundelen. In het verleden kon je scripttags dynamisch injecteren vanuit elke URL op het web.

Mij ​​werd verteld dat mijn extensie RHC heeft. Wat is er aan de hand?

Als uw extensie tijdens de beoordeling is afgewezen met een Blue Argon- fout, dan denken onze beoordelaars dat uw extensie gebruikmaakt van code die op een externe locatie wordt gehost. Dit komt meestal doordat een extensie probeert een scripttag toe te voegen met een externe bron (bijvoorbeeld van het open web, in plaats van de bestanden die in de extensie zijn opgenomen), of doordat een bron direct wordt opgehaald om uit te voeren.

Hoe herken je RHC?

Het opsporen van RHC-fouten is niet bijzonder moeilijk als je eenmaal weet waar je op moet letten. Controleer eerst of de strings "http://" of "https://" in je project voorkomen. Als er een RHC-schending is, kun je die waarschijnlijk vinden door daarnaar te zoeken. Als je een volledig buildsysteem gebruikt of afhankelijkheden van npm of andere externe bronnen, zorg er dan voor dat je de gecompileerde versie van de code doorzoekt, aangezien die door de store wordt geëvalueerd. Als je het probleem nog steeds niet kunt vinden, neem dan contact op met One Stop Support . Zij kunnen de specifieke schendingen beschrijven en aangeven wat er nodig is om de extensie zo snel mogelijk te publiceren.

Wat te doen als een bibliotheek om de code vraagt?

Ongeacht de herkomst van de code, is het niet toegestaan ​​om RHC te gebruiken. Dit geldt ook voor code die je niet zelf hebt geschreven, maar die je toevallig als afhankelijkheid in je project gebruikt. Sommige ontwikkelaars die Firebase gebruikten, ondervonden dit probleem toen externe code werd opgenomen voor gebruik in Firebase Auth . Hoewel dit een officiële bibliotheek van Google was, wordt er geen uitzondering gemaakt voor RHC. Je moet de code zo configureren dat de RHC wordt verwijderd of je project bijwerken zodat de code helemaal niet meer wordt opgenomen. Als je een probleem tegenkomt waarbij niet jouw code, maar een bibliotheek die je gebruikt RHC laadt, kun je het beste contact opnemen met de auteur van de bibliotheek. Laat hen weten dat dit gebeurt en vraag om een ​​tijdelijke oplossing of code-updates om het probleem op te lossen.

Wat als je niet kunt wachten op een bibliotheekupdate?

Sommige bibliotheken sturen vrijwel direct een update uit nadat ze op de hoogte zijn gesteld, maar andere worden mogelijk genegeerd of hebben meer tijd nodig om het probleem op te lossen. Afhankelijk van de aard van de specifieke overtreding hoeft u mogelijk niet te wachten tot de blokkering is opgeheven en de beoordeling succesvol is afgerond. Er zijn verschillende opties beschikbaar om snel weer aan de slag te gaan.

Controleer de code

Weet je zeker dat de code die het verzoek veroorzaakt nodig is? Als deze code gewoon verwijderd kan worden, of als de bibliotheek die het verzoek veroorzaakt verwijderd kan worden, verwijder dan die code en het probleem is opgelost.

Is er misschien een andere bibliotheek die dezelfde functionaliteit biedt? Kijk eens op npmjs.com , GitHub of andere websites voor alternatieven die aan dezelfde eisen voldoen.

Boom schudden

Als de code die de RHC-schending veroorzaakt niet daadwerkelijk wordt gebruikt, kan deze mogelijk automatisch worden verwijderd door de tooling. Moderne buildtools zoals webpack , Rollup en Vite (om er maar een paar te noemen) hebben een functie genaamd tree-shaking . Zodra deze functie is ingeschakeld in je buildsysteem, zou tree-shaking alle ongebruikte codepaden moeten verwijderen. Dit kan betekenen dat je niet alleen een meer conforme versie van je code hebt, maar ook een slankere en snellere versie! Het is belangrijk om te weten dat niet alle libraries geschikt zijn voor tree-shaking, maar veel wel. Sommige tools, zoals Rollup en Vite, hebben tree-shaking standaard ingeschakeld. Voor webpack moet deze functie worden geconfigureerd . Als je geen buildsysteem gebruikt als onderdeel van je extensie, maar wel codebibliotheken, dan is het sterk aan te raden om te onderzoeken of je een buildtool aan je workflow kunt toevoegen. Buildtools helpen je bij het schrijven van veiligere, betrouwbaardere en beter onderhoudbare projecten.

De precieze implementatie van treeshaking hangt af van je project. Maar om een ​​eenvoudig voorbeeld met Rollup te nemen: je kunt treeshaking toevoegen door simpelweg je projectcode te compileren. Stel dat je een bestand hebt dat alleen inlogt bij Firebase Auth, genaamd main.js:

import { GoogleAuthProvider, initializeAuth } from "firebase/auth";

chrome.identity.getAuthToken({ 'interactive': true }, async (token) => {
  const credential = GoogleAuthProvider.credential(null, token);
  try {
    const app = initializeApp({ ... });
    const auth = initializeAuth(app, { popupRedirectResolver: undefined, persistence: indexDBLocalPersistence });
    const { user } = await auth.signInWithCredential(credential)
    console.log(user)
  } catch (e) {
    console.error(error);
  }
});

Dan hoeft u Rollup alleen nog maar het invoerbestand, een plugin die nodig is om node-bestanden te laden (@rollup/plugin-node-resolve ) en de naam van het uitvoerbestand dat wordt gegenereerd, door te geven.

npx rollup --input main.js --plugin '@rollup/plugin-node-resolve' --file compiled.js

Als je dat commando in een terminalvenster uitvoert, krijg je een gegenereerde versie van ons main.js bestand, gecompileerd tot één bestand met de naam compiled.js .

Rollup is eenvoudig, maar ook zeer configureerbaar. Je kunt allerlei complexe logica en configuraties toevoegen; raadpleeg hiervoor de documentatie . Het toevoegen van dergelijke buildtools resulteert in kleinere, efficiëntere code en lost in dit geval ons probleem met de extern gehoste code op.

Bestanden automatisch bewerken

Een steeds vaker voorkomende manier waarop code van externe bronnen in je codebase terechtkomt, is als een subafhankelijkheid van een bibliotheek die je zelf gebruikt. Als bibliotheek X bibliotheek Y van een CDN wil import , moet je deze nog steeds aanpassen zodat de import vanuit een lokale bron plaatsvindt. Met moderne buildsystemen kun je eenvoudig plugins maken om een ​​externe verwijzing te extraheren en deze direct in je code op te nemen.

Dat zou betekenen dat gegeven code die er als volgt uitziet:

import moment from "https://unpkg.com/moment@2.29.4/moment.js"
console.log(moment())

Je zou een kleine Rollup-plugin kunnen maken.

import { existsSync } from 'fs';
import fetch from 'node-fetch';

export default {
  plugins: [{
    load: async function transform(id, options, outputOptions) {
      // this code runs over all of out javascript, so we check every import
      // to see if it resolves as a local file, if that fails, we grab it from
      // the network using fetch, and return the contents of that file directly inline
      if (!existsSync(id)) {
        const response = await fetch(id);
        const code = await response.text();

        return code
      }
      return null
    }
  }]
};

Zodra je de build uitvoert met de nieuwe plugin, wordt elke URL voor externe import gedetecteerd, ongeacht of het onze code, een subafhankelijkheid, een subsubafhankelijkheid of ergens anders betreft.

npx rollup --input main.js --config ./rollup.config.mjs --file compiled.js

Handmatig bestanden bewerken

De eenvoudigste optie is om de code die de RHC (Right Head Confidence) veroorzaakt te verwijderen. Open het bestand in je favoriete teksteditor en verwijder de betreffende regels. Dit is over het algemeen echter niet aan te raden, omdat het een kwetsbare oplossing is en je het gemakkelijk kunt vergeten. Het maakt het onderhoud van je project lastiger als een bestand met de naam "library.min.js" in werkelijkheid geen library.min.js is. In plaats van de bestanden zelf te bewerken, is een iets beter onderhoudbare optie het gebruik van een tool zoals patch-package . Dit is een zeer krachtige tool waarmee je wijzigingen in een bestand kunt opslaan, in plaats van het bestand zelf. Het is gebaseerd op patchbestanden , hetzelfde principe dat ook gebruikt wordt in versiebeheersystemen zoals Git of Subversion . Je hoeft alleen de betreffende code handmatig aan te passen, het diff-bestand op te slaan en patch-package te configureren met de wijzigingen die je wilt toepassen. Je kunt een volledige handleiding vinden in de readme van het project . Als je een project patcht, raden we je ten zeerste aan om contact op te nemen met het project om te vragen of de wijzigingen ook upstream kunnen worden doorgevoerd. Hoewel patch-package het beheren van patches een stuk eenvoudiger maakt, is het nog beter als er helemaal niets te patchen valt.

Wat te doen als de code niet wordt gebruikt?

Naarmate codebases groeien, kunnen afhankelijkheden (of afhankelijkheden van afhankelijkheden, of afhankelijkheden van…) codefragmenten bevatten die niet langer worden gebruikt. Als een van die gedeelten code bevat om RHC te laden of uit te voeren, moet deze worden verwijderd. Het maakt niet uit of de code niet meer nodig is of niet. Als de code niet wordt gebruikt, moet deze worden verwijderd, hetzij door middel van treeshaking, hetzij door de bibliotheek te patchen om de code te verwijderen.

Is er een alternatieve oplossing?

Over het algemeen is het antwoord nee. Rechterhartkatheterisatie (RHC) is niet toegestaan. Er zijn echter enkele gevallen waarin het wel is toegestaan. Dit betreft vrijwel altijd situaties waarin geen andere optie mogelijk is.

API voor gebruikersscripts

Gebruikersscripts zijn kleine codefragmenten die meestal door de gebruiker worden aangeleverd en bedoeld zijn voor gebruikersscriptmanagers zoals TamperMonkey en Violentmonkey . Deze managers kunnen geen door gebruikers geschreven code bundelen, dus biedt de User Script API een manier om door de gebruiker aangeleverde code uit te voeren. Dit is geen vervanging voor chrome.scripting.executeScript of andere code-uitvoeringsomgevingen. Gebruikers moeten de ontwikkelaarsmodus inschakelen om code uit te voeren. Als het beoordelingsteam van de Chrome Web Store van mening is dat dit op een andere manier wordt gebruikt dan waarvoor het bedoeld is (d.w.z. code aangeleverd door de gebruiker), kan het worden afgewezen of kan de vermelding ervan uit de store worden verwijderd.

chrome.debugger

De chrome.debugger API geeft extensies de mogelijkheid om te communiceren met het Chrome Devtools Protocol . Dit is hetzelfde protocol dat wordt gebruikt voor Chrome's Devtools en een enorm aantal andere tools . Hiermee kan een extensie code op afstand opvragen en uitvoeren. Net als gebruikersscripts is het geen vervanging voor chrome.scripting en biedt het een veel betere gebruikerservaring. Tijdens het gebruik ziet de gebruiker een waarschuwingsbalk bovenaan het venster. Als deze balk wordt gesloten of weggeklikt, wordt de debugsessie beëindigd.

Sandboxed iframes

Als je een tekenreeks als code moet evalueren en je bevindt je in een DOM-omgeving (bijvoorbeeld een content script, in tegenstelling tot een extension service worker), dan is een andere optie het gebruik van een gesandboxte iframe . Extensies ondersteunen standaard geen functies zoals eval() als veiligheidsmaatregel. Kwaadwillende code kan de veiligheid van gebruikers in gevaar brengen. Maar wanneer de code alleen wordt uitgevoerd in een bekende veilige omgeving, zoals een iframe dat is afgeschermd van de rest van het web, dan worden die risico's aanzienlijk verminderd. In deze context kan het Content Security Policy (CSP) dat het gebruik van `eval` blokkeert, worden opgeheven, waardoor je elke geldige JavaScript-code kunt uitvoeren.

Als je een gebruiksscenario hebt dat hier niet wordt behandeld, neem dan gerust contact op met het team via de chromium-extensions mailinglijst om feedback te vragen, of open een nieuw ticket om hulp te vragen bij One Stop Support.

Wat te doen als u het niet eens bent met een uitspraak?

Het handhaven van beleid kan complex zijn en de beoordeling vereist handmatige invoer. Dit betekent dat het Chrome Web Store-team soms een beoordelingsbeslissing kan herzien. Als u van mening bent dat er een fout is gemaakt tijdens de beoordeling, kunt u bezwaar maken tegen de afwijzing via One Stop Support.