Classificar phishing al navegador sense enviar la URL a cap servidor

Els navegadors fa anys que protegeixen contra el phishing amb llistes de reputació. Funciona bé i té un cost que quasi mai s'esmenta: per saber si un lloc és perillós, algú s'ha d'assabentar que vas a visitar-lo. Les implementacions serioses fan servir trucs per reduir-ho, però la forma del problema no canvia.

NorthGate Browser és un projecte en desenvolupament primerenc on estic explorant l'altra direcció: en lloc d'enviar la URL al model, enviar el model al navegador.

Què es pot saber només amb la URL

Abans de descarregar res, la mateixa cadena ja diu bastant. Els senyals que faig servir surten tots d'aquí:

• Longitud i profunditat del domini i de la ruta.
• Nombre de subdominis. banco.seguro.login.ejemplo.tk té una forma característica.
• Entropia dels caràcters, que delata dominis generats per algorisme.
• Presència de punycode, la via clàssica de l'atac homògraf.
• Marca coneguda al subdomini però no al domini registrable. Aquest és el senyal més fort que he trobat, i també el més fàcil d'explicar: paypal.com.verificacion-cuenta.xyz no és PayPal.
• Proporció de dígits i guions, i el TLD.

Res d'això és concloent per separat. Junts, i amb prou exemples, se separen raonablement bé.

Per què ONNX

Entrenar és còmode en Python i executar dins d'un navegador no ho és. ONNX resol exactament aquest forat: s'entrena amb les eines de sempre, s'exporta a un format intermedi i s'executa des del runtime natiu, sense arrossegar Python al producte final.

En un navegador això importa per tres motius molt concrets:

• La mida es paga a cada instal·lació. Un model de desenes de megues no és viable dins d'un binari que la gent descarrega.
• El pressupost de latència és minúscul. Això s'ha de resoldre abans que la pàgina pinti. Parlem d'un grapat de mil·lisegons, no de centenars.
• No pot dependre de la xarxa. Si necessités connexió per decidir, hauríem tornat al punt de partida.

La integració va en Rust, que és el llenguatge del nucli sobre el qual treballo, i encaixa bé: sense recol·lector d'escombraries, sense pauses imprevisibles en una ruta que s'executa a cada navegació.

El llindar és la decisió difícil

La part que més temps m'està portant no és el model, és on posar el tall. I és perquè els dos errors no costen el mateix:

• Un fals negatiu deixa passar una pàgina de phishing. Dolent, però és l'estat actual sense cap protecció.
• Un fals positiu marca el banc real de l'usuari com a fraudulent. Això és pitjor del que sembla: ensenya la gent a ignorar l'avís. I un avís que s'ignora no protegeix de res, només dona sensació que sí.

Per això el llindar està deliberadament conservador i el senyal es planteja com a advertència, no com a bloqueig. Prefereixo cobrir menys i que l'avís conservi el seu significat.

Estat

Està en desenvolupament primerenc i ho dic sense adorns: hi ha un pipeline d'extracció de característiques, un model que es comporta de manera raonable en validació i una integració que encara no consideraria llesta. El que té d'interessant el projecte, de moment, és la restricció de partida: si la URL no surt de l'equip, hi ha una categoria sencera de fuites que simplement no pot passar. Dissenyar amb aquesta limitació des del principi obliga a decisions força més honestes que afegir privadesa al final.

Relacionat: vaig mesurar després si el desacord entre diversos classificadors ajuda a prioritzar quin correu revisar — la resposta no va ser l'esperada.