Herramientas del lado del cliente y privacidad de datos: dónde va realmente su pasta

Años de hacer soporte de complementos de WordPress me enseñaron un mal hábito. Un cliente le envía un blob de opciones serializadas rotas, necesita leerlo hoy día, entonces lo pegas en el primer no serializador en línea que te ofrece Google. Hice esto durante mucho tiempo sin pensar en ello, hasta el día en que miré lo que acabo de pegar. Era un cliente's wp_options exportación. Contenía su contraseña SMTP, una clave API de MailChimp y una clave de licencia. Todo se acababa de publicar en un servidor de quien no sabía nada, dirigido por alguien que no podría nombrar, en un país que no podría adivinar.

Hasta donde yo sé, no pasó nada malo. Eso' es la parte inquietante - no tengo forma de saberlo. Allí' no hay notificación para "tu pasta se registró." Los datos se encontraban en los registros de acceso de alguien's o no 't, y yo ' Nunca sabré cuál.

Ese incidente es una gran parte de por qué Toolz.dev funciona como lo hace. Cada una de las 50 herramientas del sitio procesa su entrada en su navegador. No " prometemos que lo eliminaremos después del procesamiento " - nunca se transmite en primer lugar. Esta guía explica la diferencia entre esas dos arquitecturas, por qué es más importante para los desarrolladores que para casi cualquier otra persona, y cómo verificar una herramienta 's se reclama en unos 30 segundos. Y, dado que finalmente pegué esa masa de cliente en algún lugar seguro, el Unserializador de PHP Eso reemplazó mi mal hábito.

TL;Dr: Las herramientas del lado del servidor transmiten su entrada a otra persona's máquina, donde se puede registrar, retener, violar o compartir - y usted puede't verificar cualquiera de ellas. Las herramientas del lado del cliente le envían el código y procesan todo localmente; La verificación requiere una verificación de la pestaña Red DevTools. Para cualquier cosa que contenga credenciales - JWT, wp-config valores, cadenas de conexión, respuestas API: utilice herramientas del lado del cliente como Formateador JSON, Decodificador JWT, Formateador SQLy Validador YAM. todo en Toolz.dev se ejecuta en el navegador.

¿Qué sucede realmente cuando pegas en una herramienta en línea?

Hay exactamente dos arquitecturas, y cada herramienta en línea utiliza una de ellas.

Lado del servidor: Su entrada viaja desde su navegador hasta el servidor de la herramienta, se procesa allí y el resultado regresa. Cinco pasos, y sus datos existen sobre la infraestructura de otra persona durante tres de ellos.

Your browser → network → their server → network → your browser
   (input)     (transit)  (processing,    (transit)   (result)
                           logging?,
                           retention?)

Lado del cliente: su navegador descarga la herramienta 's JavaScript una vez, y luego todo (entrada, procesamiento, salida) ocurre en una pestaña de su máquina. Lo único que cruzó la red fue el código.

Their server → your browser
   (code)       (input + processing + result, all local)

La distinción suena académica hasta que enumera lo que puede suceder con los datos en un servidor que usted realiza 't control. Puede aterrizar en registros de acceso y registros de aplicaciones. Puede ser capturado por rastreadores de errores como Sentry, cuyo contexto de solicitud de instantáneas cuando algo se lanza. Puede conservarse en copias de seguridad mucho después del operador "eliminado" él. Puede ser leído por cualquier empleado con acceso al registro. Puede ser barrido en una brecha. Y con varios "herramienta y quot gratuitos; operadores, puede ser el producto real, monetizado mediante análisis o vendido como datos de entrenamiento.

Ninguno de estos requiere malicia. Las configuraciones de registro predeterminadas por sí solas harán la mayor parte. El operador de ese unserializador que usé probablemente nunca miró la contraseña de SMTP de mi cliente. Pero "probablemente" no es una postura de seguridad.

¿Por qué es esto un negocio más grande para los desarrolladores que para cualquier otro?

Por lo que pegamos. Un usuario promedio pega un párrafo de texto en un contador de palabras. Un desarrollador pega:

Respuestas de API con tokens en vivo. You'Estás depurando una integración, copias la respuesta completa (encabezados incluidos) y la formateas para leerla. Eso Authorization: Bearer ... El encabezado simplemente fue a donde vive el formateador. GitGuardian'S Extensión de estado de secretos la investigación encontró alrededor de 12,8 millones de secretos expuestos en compromisos públicos de GitHub solo en 2023. Nadie publica números equivalentes para herramientas en línea, porque a diferencia de GitHub, los operadores de herramientas ' los registros son ' no se pueden escanear públicamente. Eso ' No es tranquilizador, significa que la superficie de la fuga es invisible.

JWT. Un token web JSON está codificado en base64url, no cifrado RFC 7519 es explícito al respecto. La carga útil de cada token que pega en un decodificador del lado del servidor entrega el ID, el correo electrónico, las funciones y la caducidad del usuario. Si el token sigue siendo válido, potencialmente ha entregado una credencial de sesión de trabajo. decodificarlos localmente con el Decodificador JWT en cambio.

SQL con datos reales. La consulta que está formateando tiene un WHERE email = '[email protected]' cláusula en ella, y los nombres de la tabla dibujan todo su esquema. los Formateador SQL lo mantiene en su pestaña.

archivos de configuración. wp-config.php valores, .env contenidos, kubernetes manifiestos, database.yml- la configuración es donde viven las credenciales. I' He validado archivos YAML que contenían todos los secretos que tenía mi aplicación Laravel. Eso' es una pasta que desea revisar del lado del cliente Validador YAM, no es una publicación de formulario.

Datos de WordPress serializados. Mi perdición personal, según la introducción. WordPress almacena opciones y metadatos como cadenas serializadas por PHP, y depurarlas significa desserializarlas: el Unserializador de PHP ¿Lo hace sin que los datos de su cliente salgan de su máquina?

Una pasta descuidada de cualquiera de estas categorías es un incidente de seguridad que nadie detectará, informará o limpiará.

¿Cómo verifica que una herramienta esté realmente del lado del cliente?

Esta es la parte que más me gusta de la arquitectura del lado del cliente: No tienes que confiar en la política de privacidad de nadie. La reclamación es mecánicamente verificable.

1. Abra la página de la herramienta.
2. Abrir DevTools (F12) → hacer redde Pestaña Consultar registro "Preserve Log"
3. Pegue algunos datos de prueba reconocibles - MY-SECRET-TEST-12345 funciona y ejecuta la herramienta.
4. Mire la lista de solicitudes.

Si la herramienta está en el lado del cliente, verá la carga inicial de la página y los activos estáticos, y luego cero cuando procesas. Si una solicitud se activa cuando presiona el botón convertir/formato/proceso, filtre las solicitudes e inspeccione las cargas útiles para su cadena de prueba. ¿Lo encontró? Lado del servidor. Hecho, eso tomó medio minuto, y ahora sabe más sobre esa herramienta de lo que su política de privacidad le diría.

Dos notas de honestidad sobre Toolz.dev, porque esto corta en ambos sentidos. Primero, el sitio carga análisis para contar con recuentos de vista de página y realiza un seguimiento aquello se utilizó una herramienta, para los límites de uso, pero nunca que lo pones. Ejecute la verificación de red usted mismo; la entrada nunca aparece en ninguna solicitud. En segundo lugar, el lado del cliente tiene una limitación real: su navegador hace el trabajo, por lo que una transcodificación de video de 4 GB es ' no ocurre en una pestaña. Sin embargo, para la categoría de herramientas de formateador/convertidor/codificador, JavaScript moderno es lo suficientemente rápido, generalmente más rápido que el lado del servidor, porque no hay carga de ida y vuelta.

El lado del servidor frente al lado del cliente: la comparación directa

¿Qué dice el RGPD sobre esto?

I' Soy un desarrollador, no un abogado, así que trate esto como un contexto de ingeniería en lugar de asesoramiento legal, pero el esquema es importante para cualquiera que maneje datos de usuarios de la UE.

con arreglo a Reglamento (UE) 2016/679 (GDPR), si toma datos personales (un cliente 's admite la exportación, una respuesta API con registros de usuario) y los envía a través de un tercero 's servidor, ese tercero está procesando datos personales en su nombre. El artículo 28 dice que requiere un acuerdo de procesamiento de datos. Pregúntese cuántos formateadores en línea gratuitos ofrecen un DPA. Nunca he visto uno.

Las herramientas del lado del cliente eluden toda la cuestión, no a través de una redacción legal inteligente sino a través de la arquitectura: ningún dato llega al proveedor, por lo que no hay ningún procesamiento de terceros para el tratamiento. La minimización de datos (Artículo 5 (1) (c)) se satisface de la manera más literal posible: la cantidad de datos que recopila el proveedor es cero. La misma lógica ayuda con HIPAA (los datos de salud nunca llegan a un servidor que no cumpla con las normas), auditorías SOC 2 (no hay subprocesador no examinado en la ruta de datos) y PCI DSS.

Para ser claros: el uso de herramientas del lado del cliente no hace tu producto Cumple con el RGPD. Elimina una fuga específica y sorprendentemente común en su flujo de trabajo de desarrollo: aquella en la que un desarrollador, tratando de ser útil en un ticket de soporte, pega datos personales en un sitio web aleatorio.

¿Qué tareas nunca deben tocar un servidor?

Mi triaje personal, ordenado por cuánto dolería una fuga:

Nunca del lado del servidor: contiene o implica credenciales:

• Formatear las respuestas y cargas de la API: Formateador JSON
• Fichas de decodificación: Decodificador JWT, Convertidor Base64
• Consultas de formato: Formateador SQL
• Validar configuraciones: Validador YAM
• Depuración de datos de WordPress: Unserializador de PHP
• Valores de hash y comparación: generador de hachas
• Generando credenciales: generador de contraseñas, generador de UUID

Prefiero firmemente el lado del cliente: propietario pero no secreto:

• Diferencia de código interno o contratos: Diferencia de texto, Diferencia de JSON
• Prueba de expresión regular contra líneas de registro de producción: Probador de expresión regular
• Conversión de marcas de tiempo de registros y tokens: Convertidor de marca de tiempo
• Compresión de capturas de pantalla internas: compresor de imagen

Apuestas bajas, pero el lado del cliente sigue siendo más rápido:

• Recuentos de palabras: Contador de palabras
• Texto de marcador de posición: Generador de Lorem Ipsum
• Colores y degradados: selector de colores, Generador de gradiente

Hay un recorrido más largo de la caja de herramientas completa en el Guía de herramientas de productividad para desarrolladores y el Guía de herramientas de codificación.

Si realmente necesita una herramienta del lado del servidor (una conversión intensa sin alternativa local), desinfecte primero. Intercambie claves reales por YOUR_API_KEY, correos electrónicos reales para [email protected]. Son 60 segundos de búsqueda y reemplazo que convierten un incidente potencial en un no evento.

¿Por qué la mayoría de las herramientas en línea están del lado del servidor de todos modos?

En parte historia, en parte incentivos. En 2010, los navegadores estaban a la altura del trabajo; tenía que realizarse un procesamiento intenso en un servidor. Esa restricción desapareció: los motores JavaScript modernos y WebAssembly manejan el formato, la conversión, el hash y la compresión de imágenes a velocidades indistinguibles de las nativas, y las API del navegador (archivo, lienzo, criptomonedas web) cubren la E/S.

Los incentivos son el problema más complicado. El procesamiento del lado del servidor permite al operador ver el uso en detalle, imponer límites con precisión, mantener la lógica de procesamiento como propiedad y, en el peor de los casos, tratar los datos en sí como ingresos. Una herramienta que nunca recibe sus datos puede 't monetizar sus datos, razón por la cual algunos operadores no 't quieren la arquitectura aunque ' Ahora es técnicamente fácil.

Cuando construí las herramientas para Toolz.dev, el lado del cliente era en realidad el más fácil Elección de ingeniería, no solo la más privada: no hay servidores de procesamiento para escalar, no hay cargas para asegurar, no hay una política de retención para escribir, y cada herramienta funciona de manera idéntica en la aplicación web y la aplicación de escritorio porque la lógica es una escritura gráfica independiente de la plataforma. La historia de privacidad y la historia de ingeniería apuntan en la misma dirección. Es raro cuando eso sucede; toma la victoria.

Preguntas frecuentes

¿Qué significa realmente "procesamiento del lado del cliente"?

Todo el cálculo ocurre en su navegador, en JavaScript (o WebAssembly), en su dispositivo. El único rol del servidor es entregar el código de la herramienta cuando se carga la página. Su entrada nunca aparece en ninguna solicitud de red, que puede confirmar en la pestaña Red DevTools.

¿Cómo verifico si una herramienta está del lado del cliente?

Abra DevTools (F12) → pestaña Red, habilite " Conservar registro," pegue datos de prueba reconocibles en la herramienta y proceselos. Si no hay ninguna solicitud que contenga su cadena de prueba, la herramienta está en el lado del cliente. En Chrome también puede cambiar DevTools a " Sin conexión y quot; después de la carga de la página, una verdadera herramienta del lado del cliente sigue funcionando.

¿Son las herramientas del lado del cliente más lentas que las del lado del servidor?

Para tareas típicas de desarrollador, ellos' son más rápidos - allí's sin carga, sin cola, sin descarga. Procesar un archivo JSON de 2 MB localmente es casi instantáneo, mientras que un servidor de ida y vuelta agrega latencia en cada paso. La excepción son los cálculos pesados (grandes transcodificaciones de vídeo, archivos a escala de gigabytes), donde un servidor potente supera la pestaña del navegador.

¿Toolz.dev recopila algo?

Análisis de vista de página y recuentos anónimos de uso por herramienta (utilizados para límites de velocidad), pero nunca el contenido que procesa. Los archivos de entrada, salida y carga permanecen en su navegador. Esto se puede verificar con la verificación de la pestaña Red en lugar de algo que deba asumir con fe.

¿Es realmente arriesgado pegar un JWT en un decodificador en línea?

Sí, más de lo que suponen la mayoría de los desarrolladores. Según RFC 7519, las cargas útiles de JWT están codificadas, no cifradas: cualquiera que tenga el token puede leer las afirmaciones y, si el token tiene 't caducado, puede usarse como credencial activa. Pasar uno a un decodificador del lado del servidor transmite un token de sesión posiblemente válido a un tercero desconocido. Utilice un decodificador del lado del cliente.

¿El uso de herramientas del lado del cliente me hace compatible con GDPR?

Ninguna opción de herramienta única lo hace compatible. Lo que eliminan las herramientas del lado del cliente es un riesgo específico: los datos personales de sus sistemas llegan a un procesador externo no veteado (lo que requeriría un acuerdo de procesamiento de datos del artículo 28 que es casi seguro que no tiene con un sitio de herramientas gratuito). Las obligaciones de su propio producto no se ven afectadas.

¿Puede mi empleador ver lo que procedo en las herramientas del lado del cliente?

El monitoreo de red ve qué sitios visita, no qué escribe en una herramienta del lado del cliente - allí' no hay ninguna solicitud que lleve su entrada para observar. El monitoreo de terminales instalado en el propio dispositivo (captura de pantalla, registradores de teclas) ve todo independientemente de la arquitectura de la herramienta, por lo que la respuesta honesta es: no a través de la red, posiblemente a través del punto final.

¿Qué pasa si no hay una alternativa del lado del cliente para mi tarea?

Desinfectar antes de pegar: reemplace las credenciales con marcadores de posición (YOUR_API_KEY), Cambie datos personales reales por valores ficticios, nombres de host y URL internas. Luego, consulte la política de privacidad de la herramienta para el lenguaje de registro y retención, prefiera las herramientas de código abierto que pueda inspeccionar y tratar "libre de código cerrado, del lado del servidor" como la combinación de mayor riesgo.

¿Cuál es la diferencia entre las herramientas del lado del cliente y del lado del servidor?

Las herramientas del lado del cliente envían código a su navegador y lo ejecutan allí; Las herramientas del lado del servidor envían sus datos a una máquina que usted no controla y ejecuta allí. Funcionalmente, la salida puede ser idéntica: la diferencia es enteramente sobre quién termina reteniendo su entrada. Con una herramienta del lado del servidor, sus datos existen, aunque sea brevemente, en el disco de otra persona 's, en sus registros y en sus copias de seguridad.

¿Son seguros de usar los formateadores y embellecedores JSON en línea?

Depende de la implementación, no de la categoría. Formatear JSON es trivial en JavaScript, por lo que un formateador del lado del cliente no tiene motivos para transmitir nada, y la verificación de la pestaña Red lo establece en diez segundos. Tenga más cuidado de lo habitual aquí, porque los desarrolladores de JSON pegan en formateadores respuestas API desproporcionadamente que contienen tokens, direcciones de correo electrónico e ID internos.