Scaricare i siti web che utilizzano Sentry

Informazioni su Sentry

Un sistema di tracciamento degli errori è una delle poche cose presenti in una pagina che descrivono il team dietro un sito più che il sito stesso. La piattaforma Sentry, classificata nella categoria Issue trackers, è uscita per la prima volta nel 2010, è stata scritta in origine in Python ed è pubblicata da Functional Software Inc. con licenza BSD. Ogni rilevamento corrisponde a un SDK client che uno sviluppatore ha aggiunto deliberatamente, collegato a un progetto, a un ambiente e di solito al sistema di allerta di qualcuno.

Nessuno aggiunge il tracciamento degli errori a una pagina vetrina. La presenza dell’SDK implica un’applicazione con sessioni utente reali, un processo di rilascio e una persona il cui lavoro comprende leggere uno stack trace il lunedì mattina. Per chi vende ai team di ingegneria, questa deduzione qualifica un’azienda in modo più preciso delle stime sul numero di dipendenti o sul traffico, perché separa le aziende che gestiscono software da quelle che hanno semplicemente un sito web.

A ottobre 2026 rileviamo l’SDK su 413.495 siti, di cui 296.842 negli Stati Uniti, e .com è l’estensione con il blocco più consistente. La concentrazione per paese è in parte reale e in parte un artefatto del luogo in cui le aziende di software registrano i propri domini pubblici, un’avvertenza che vale per quasi tutte le tecnologie rivolte agli sviluppatori e per questa in particolare.

È nei dati di versione che l’elenco diventa operativo. Registriamo 454 versioni distinte dell’SDK, e la stringa che compare più spesso è 5.4.3. La dispersione delle versioni in un SDK per browser è di per sé un segnale di maturità, perché il bundle cambia soltanto quando qualcuno ricompila e ridistribuisce il front-end. Un sito che usa un SDK indietro di diverse versioni principali rispetto al rilascio attuale indica che la sua pipeline front-end è ferma da molto tempo, un’informazione utile a un fornitore che propone un sostituto, a un ricercatore che studia la deriva delle dipendenze e a un team di sicurezza che mappa il codice lato client obsoleto.

Vale la pena dichiarare apertamente i limiti del rilevamento, perché qui sono ampi. Possiamo osservare soltanto il lato client. Le integrazioni backend, dove si concentra gran parte dell’utilizzo reale, non lasciano nessuna traccia nella risposta di una pagina, quindi la popolazione reale di clienti è sensibilmente più ampia di questo conteggio. Le installazioni self-hosted che instradano gli eventi attraverso il dominio del sito stesso sono altrettanto invisibili, e tendono ad appartenere proprio alle aziende attente alla sicurezza che un ricercatore vorrebbe identificare più di tutte. Il dato va trattato come una stima per difetto dell’adozione e come un campione affidabile dei siti strumentati lato client, non come una stima della quota di mercato.

Una verifica per singolo dominio dice se un sito è strumentato, il che va nella direzione sbagliata per la maggior parte delle ricerche. L’esportazione ribalta la prospettiva: una riga per ogni sito rilevato, con il dominio, il paese, l’estensione, la versione dell’SDK quando è esposta e la data dell’ultimo rilevamento. Partendo da quel file è possibile segmentare per versione prima di contattare i siti per questioni di sicurezza, stimare le dimensioni di un mercato prima di sviluppare un prodotto concorrente, oppure misurare quanto rapidamente una nuova linea dell’SDK si diffonde nelle installazioni reali anziché nei conteggi dei download.