No trates a la ligera la tecnología de pegar
(github.com/aaronraimist)- DontFuckWithPaste es una extensión de Google Chrome que elimina el comportamiento de las aplicaciones web que bloquean copiar y pegar en los campos de entrada
- El proyecto considera que obligar a escribir manualmente valores como una dirección de correo electrónico o datos de herramientas como 1Password en realidad aumenta la posibilidad de errores de entrada
- El usuario puede pulsar el icono de la extensión para agregar un sitio a la lista negra, modificar el patrón generado automáticamente si hace falta y luego guardarlo
- Cuando la extensión está activa en la pestaña actual, el icono se vuelve azul, lo que permite comprobar el estado de activación o desactivación por pestaña
- La Version 2 usa el permiso
tabspara que la extensión se ejecute solo en los sitios problemáticos, y la descripción de permisos de Chrome puede parecer más amplia y alarmante que su funcionamiento real
Extensión de Chrome que elimina el bloqueo de copiar y pegar
- DontFuckWithPaste es una extensión de Google Chrome que elimina el comportamiento de las aplicaciones web que bloquean copiar y pegar de los usuarios
- La responsabilidad de pegar mal una dirección de correo electrónico recae en el usuario, y copiar y pegar valores desde herramientas como 1Password puede generar menos errores que escribir cada carácter manualmente
- El objetivo de la extensión es eliminar de forma simple las restricciones de los sitios web que bloquean los eventos de copiar y pegar
Cómo se usa
- La forma más fácil de agregar un sitio a la lista negra es hacer clic en el icono de la extensión
- Después, se puede modificar el patrón generado automáticamente si es necesario y pulsar
"Save" - Tras guardarlo, si el icono de la extensión aparece en azul, significa que está activa en la pestaña actual
Cambios y permisos en Version 2
- Version 2 es una actualización importante de la extensión y facilita que se ejecute solo en los sitios que gestionan mal los eventos de copiar y pegar
- También ofrece visibilidad para comprobar si la extensión está activa o inactiva en cada pestaña
- Se necesita el permiso
tabspara saber cuándo cambia la pestaña activa- Chrome describe este permiso como
"can read and change all your data on websites you visit" - El README aclara que esta descripción suena alarmante, pero que la extensión no funciona realmente de esa manera
- Chrome describe este permiso como
- Como es un proyecto de código abierto, los usuarios pueden leer el código y comprobar cómo funciona la extensión y qué cosas no hace con los datos del usuario
- Se puede consultar más información sobre la actualización a Version 2 en la wiki page
1 comentarios
Opiniones de Hacker News
Bloquear la entrada del usuario en realidad empeora la seguridad de la aplicación. Si no se puede copiar una contraseña, incluso los usuarios que al principio usaban buenas contraseñas terminan cambiándolas por otras menos complejas por la molestia de tener que escribirlas
Si obligas a usar entradas complejas y luego no permites que el usuario pegue un valor que generó correctamente, también arruinas la experiencia de usuario
Los sistemas que obligan a usar ciertos caracteres también son un problema. En vez de reglas como “debe incluir mayúsculas, números y caracteres especiales”, prefiero generar una contraseña más larga aunque use solo caracteres comunes. Es más fácil para las veces en que haya que escribirla a mano
Peor aún es cuando limitan incluso qué caracteres especiales se permiten. Terminas teniendo que volver a editar una contraseña ya generada solo para quitar ciertos caracteres
Me pregunto si de verdad es tan difícil mostrar la fortaleza de la contraseña y orientar con algo como “usa más caracteres; por ejemplo, puedes usar cuatro palabras”
Es muy probable que el usuario no recuerde las reglas especiales de esa interfaz porque no las usa con frecuencia y, al final, primero intentará copiar al portapapeles
En general estoy de acuerdo con que hay que dejar que el usuario use las funciones a las que está acostumbrado, pero si tiene el hábito de copiar y pegar credenciales, se vuelve más vulnerable al phishing
Los gestores de contraseñas integrados de Firefox y Chrome no ingresan credenciales por error en sitios parecidos, pero un usuario perfectamente podría hacerlo
El problema es que no existe un modelo alternativo de permisos para hacer esto. He usado varias extensiones y, en muchos casos, no pueden hacer nada sin acceso total de lectura/escritura a todas las páginas
Por ejemplo, hay una extensión que permite hacer clic derecho en una imagen y rotarla -90/+90/180 grados. Lo único que se quiere es que el navegador avise cuando hay una etiqueta de imagen, pero esa opción no existe
Al final hay que incrustar en el código una lista de permitidos por página, hacer que el usuario cree una lista de permitidos para cada página, o pedir permisos completos de lectura/escritura sobre todas las páginas web que visita el usuario
El autor está siendo lo más transparente posible sobre qué permisos necesita y por qué, y además el motivo se debe a factores que no controla; la reacción me parece demasiado cínica
Técnicamente es correcto. Más adelante podría hacer cualquier cosa
Aun así, esa actitud merece reconocimiento más que crítica
No sé por qué el artículo original enlazó un fork en lugar del original. El original tiene una versión bookmarklet que puede usarse como alternativa
https://github.com/jswanner/DontF-WithPaste?tab=readme-ov-fi...
Puedes evitar ese problema descargando el código fuente de la extensión y usando “cargar extensión descomprimida” en el modo de desarrollador de extensiones de Chrome. Así puedes estar seguro de que la extensión no cambia a escondidas
Eso sí, a esta extensión no le doy permisos para todos los sitios; la activo solo sitio por sitio
Por eso uso un gestor de paquetes del sistema para instalar y actualizar extensiones del navegador
Si el repositorio de paquetes no tiene la extensión de navegador que necesito, contribuyo el paquete yo mismo y asumo la responsabilidad de la verificación continua y el mantenimiento
Para esquivar este problema, en Mac normalmente pego el texto en algún lugar como el campo de URL y luego lo hago con arrastrar y soltar
Pero bloquear el pegado en nombre de la seguridad es una de las estupideces más grandes, casi al nivel de poner límites de tiempo excesivamente cortos en todas partes
Ojalá pudiera conocer en persona a quienes toman este tipo de decisiones
Una vez me obligaron a implementar un cierre de sesión automático a los 30 minutos en un sitio web que difícilmente podía considerarse que tuviera datos sensibles. Fue porque una empresa externa de pruebas de penetración marcó como problema que no hubiera un límite de tiempo corto
Para mostrarle al cliente un resultado aprobado de la prueba de penetración, no quedó más que cumplir con todos los hallazgos. Todos sabían que era una exigencia tonta, pero la dirección no dio otra opción que implementarla
Hace poco viví un flujo absurdo en login.gov. El gestor de contraseñas tenía un inicio de sesión guardado; yo no lo recordaba, pero funcionó. Después el sitio pidió un código de una app de autenticación, pero ninguna de mis apps de autenticación tenía una entrada de login.gov
Presioné el botón “iniciar sesión de otra forma” y esa otra forma también era usar una app de autenticación. Al presionar “¿no puedes recibir un código?”, decía que tenía que eliminar la cuenta
Al presionar eliminar cuenta, enviaron un correo, y el correo decía que esperara 24 horas para recibir otro correo de eliminación de cuenta. Tras 24 horas recibí el correo que permitía eliminar la cuenta
No sé qué había en esa cuenta. Por el uso que se le da al inicio de sesión, parece que podría ser sensible, pero si es tan sensible e importante, ¿por qué se permite la eliminación de cuenta, que es lo más destructivo? ¿Por qué se puede eliminar solo con el correo, pero no recibir un código de autenticación?
Ni siquiera MS Remote Desktop permite pegar
¿Para qué creen que existen los gestores de contraseñas?
En Mac uso Hammerspoon y configuré el atajo Cmd+Shift+V para que escriba los caracteres reales en vez de pegar. Siempre funciona cuando alguien hace este tipo de cosas
hs.hotkey.bind({"cmd", "shift"}, "V", function() hs.eventtap.keyStrokes(hs.pasteboard.getContents()) end)Keyboard Maestro también es una excelente app para este tipo de tareas, y agrega un retraso adecuado entre pulsaciones para evitar comportamientos extraños. Es de alrededor de 0.05 segundos.
En Windows hago lo mismo con AHK y uso el mismo atajo. Solo que agrego un pequeño retraso de unos 10 a 50 ms entre cada pulsación. Si no, a veces la entrada puede corromperse.
Yo también lo agregué, pero Cmd+Shift+V, según recuerdo, es “pegar sin formato”, así que uso option en lugar de shift.
-- https://news.ycombinator.com/item?id=39640745hs.hotkey.bind({"cmd", "alt"}, "V", function()hs.eventtap.keyStrokes(hs.pasteboard.getContents())end)Este método también soluciona la excesiva intercepción de entrada de Google Sheets.
No debería ser necesario confiar en un add-on para esto; debería poder configurarse en el navegador.
En Firefox se puede alternar
dom.event.clipboardevents.enabled.Sería bueno poder desactivar selectivamente solo el evento de “pegar”. En las herramientas de trabajo, botones como “haz clic para copiar este valor” son muy útiles, y es una lástima perder esa función cada vez que desactivo los eventos del portapapeles para evitar sitios maliciosos.
En mi experiencia, esta configuración rompe la función de pegar en algunas aplicaciones web. Por ejemplo, ciertos emuladores de terminal o editores de texto.
Si mantienes presionada Shift al hacer clic derecho, también puedes forzar la apertura del menú.
Antes, esta configuración rompía copiar/pegar en Google Docs. No lo he probado en un tiempo, así que quizá ya lo arreglaron.
A mí también me molesta que los sitios bloqueen pegar, así que esta extensión me cae bien. Especialmente en lugares como confirmaciones de números de cuenta, números de ruta bancaria o direcciones de correo, y también rompe los gestores de contraseñas. Implementar reglas complejas de contraseña para impedir contraseñas débiles y encima bloquear pegar es, por supuesto, irritante.
Pero también he implementado directamente este tipo de medidas de seguridad en aplicaciones web. Me llegó como requisito, lo implementé, y le pregunté al cliente por qué había que hacerlo si “todos” saben que esto es malo para la experiencia de usuario y además bastante contraproducente para la seguridad.
La respuesta fue compliance. Era para pasar auditorías de seguridad y demostrar a clientes grandes o aseguradoras que contaban con medidas de seguridad estándar de la industria.
Lamentablemente, a los bancos no les importa el 2% que usa gestores de contraseñas. El resto todavía memoriza contraseñas, las olvida y lo toma a broma como si fuera 2003.
Dicen “hay que hacerlo por compliance”, pero ¿realmente es así?
No recuerdo haber visto requisitos de compliance que no pudieran refutarse de forma razonable. Es solo el resultado de consultores de compliance demasiado entusiastas cruzados con equipos a los que no les importan mucho los usuarios. La gente no cuestiona nada como corresponde.
Nuestra auditoría de compliance PCI nos señaló que no habíamos desactivado el autocompletado en los campos del formulario de inicio de sesión. No es lo mismo que desactivar pegar, pero va en esa dirección.
Personalmente, si un sitio me impide usar un gestor de contraseñas (Bitwarden), simplemente lo abandono.
Si las formas de saltarse el bloqueo de pegar se vuelven demasiado populares, esos mismos sitios terminarán implementando teclados virtuales.
Si eso resulta demasiado fácil para usuarios con pantalla táctil, quizá lo siguiente sea un mouse virtual que haga clic en el teclado virtual. Para distinguir humanos de computadoras, hasta podrían aleatorizar la aceleración del mouse.
Una alternativa de bookmarklet que se publicó aquí antes.
[1]: https://bookmarkl.ink/ashtonmeuser/6e3869d8e468e016f22a4b4de...
Cuando no se puede pegar, normalmente hago clic derecho → inspeccionar elemento y luego escribo
$0.value="value from clipboard"en la consola. Funciona casi en cualquier lugar.Manipular el pegado es parecido a desactivar el autocompletado, y el estándar HTML5 es bastante claro sobre cuándo debería desactivarse: “cuando sea un valor especialmente sensible (por ejemplo, un código de activación de armas nucleares) o un valor que nunca se reutilizará (por ejemplo, una clave de un solo uso para iniciar sesión en un banco)”.
Lo único que se me ocurre es el caso en que malware cambie el valor del portapapeles y engañe al usuario para que pegue un valor incorrecto. Pero si abres ese escenario, el malware también tiene mil formas de manipular campos de entrada manual.
Interceptar Ctrl-F está al mismo nivel.
Muchas veces un atajo tiene un significado en el navegador y uno totalmente distinto en otras aplicaciones. A medida que esas aplicaciones se vuelven aplicaciones web, pueden aparecer conflictos de atajos.
Tomemos Google Docs como ejemplo: cuando presionas Ctrl-F en un documento o una hoja de cálculo, ¿quieres la búsqueda del navegador o la búsqueda propia de la app? La mayoría de los usuarios quiere la búsqueda de la app. Al leer un sitio de noticias, la mayoría esperará la búsqueda del navegador.
Esto significa que siempre hay excepciones a las reglas estrictas. Pero el problema de copiar/pegar del texto original no tiene excepción: no manipulen mi portapapeles con tonterías de marketing o rastreo.
También hay casos medio legítimos que pueden justificarse. Por ejemplo, al ver una base de datos de Notion, el Ctrl-F estándar es casi inútil; la búsqueda del documento debe traer resultados mediante la API de Notion y a veces también encontrar resultados relacionados con los elementos visibles en pantalla.
Digo “medio” porque, en realidad, preferiría que lo mapearan a otro atajo. Aun así, entiendo el argumento de que el usuario podría querer remapearlo.
Al final, todo viene de la decisión inicial de procesar documentos de esa manera. En la frontera entre aplicaciones en línea y páginas web, se vuelve un debate complicado.
Hace poco descubrí que, después de ser interceptado, si presionas Ctrl-F una vez más aparece el cuadro de búsqueda del navegador.
No recuerdo qué sitio era, pero había un tooltip en el cuadro de búsqueda interceptado que informaba de esto. Me dio curiosidad si también funcionaría en la búsqueda de Redocly, lo probé y, aunque no había tooltip, funcionó.
No estoy seguro de si esto funciona de forma universal o si es una función no documentada de la interfaz de Redocly y no funciona donde los desarrolladores no tuvieron esa consideración especial.
El entorno era Chrome + OSX o Windows.
No entiendo por qué los navegadores permiten que los sitios web sobrescriban sus propios atajos de teclado. Para que funcionara bien, más bien habría hecho falta código adicional.
Por ejemplo, Linear intercepta Cmd+F y, en vez de la búsqueda integrada del navegador que funciona igual en todas partes, ofrece algo pésimo. Sí, ese mismo Linear que parece pensar que no puedes no querer edición Markdown WYSIWYG.
Me cuesta creer que en 2024 todavía no se pueda simplemente hacer grep en la documentación.
¿Alguien más notó que el autor del post compartió un fork sin mejoras significativas respecto del repositorio original y aun así recibió 399 upvotes?
El autor del repositorio original rechazó el PR para soporte de Firefox, así que el dueño del fork lo hizo para agregar 6 líneas al manifiesto.
https://github.com/jswanner/DontF-WithPaste/pull/29
Eso sí, reconozco que el cambio no relacionado en
.gitignoreno tenía por qué estar en el PR original.Esto es para Firefox y lo otro es para Chrome, así que quizá sí sea una mejora bastante significativa.
Creo que los upvotes los recibió más por algo como “sí, yo también odio esas cosas” que por “gracias por la herramienta útil”.
El fork es para soportar Firefox y, para quienes de entrada no usamos Chrome, me parece una mejora significativa. El repositorio original es fácil de ver, pero encontrar un fork específico en GitHub es bastante más molesto.
Si eso te resulta tan desagradable, la próxima vez me lo guardo para mí. No veo por qué tendría que avisarles a los demás en HN sobre algo que podría interesarles.
Cierto. Comparado con el repositorio padre, solo cambiaron 3 archivos, y los cambios son
.gitignorey URLs actualizadas al repositorio del fork.