Tweaking Opera for safer Web browsing

Sometimes I deeply hate the Opera browser, as with its RAM consumption behavior, but most of the times I just love it.

One of the reasons I do is because it allows me to pretty easily tweak my browsing safety.

There are several aspects to browsing safety. When working on your own computer the most important one after having an updated browser is JavaScript.

JavaScript is really useful, as it allows you to make websites interactive, but it can be easily misused to do all kinds of bad stuff, from personal tracking to attacking IRC networks, passing through personal information stealing, cross-site scripting, clickjacking, etc., even if you use Linux, Mac OS or any other non-Windows operating system. Although not strictly necessary, most of the new browser-related attack vectors require JavaScript to work or be useful.

Sigue leyendo

OpenCharla, en iTunes

Les comparto que OpenCharla ya aparece en los listados de iTunes.

Para ingresar el feed de OpenCharla a otro directorio de podcasts o a algún agregador, estas son las direcciones:

MP3 feed RSS: http://opencharla.gultij.org/mp3/feed.xml
MP3 sitio: http://opencharla.gultij.org/mp3/

Ogg feed RSS: http://opencharla.gultij.org/ogg/feed.xml
Ogg sitio: http://opencharla.gultij.org/ogg/

Mientras tanto, los dejo con el episodio 2×01 de OpenCharla, donde hablamos un poquito de IPv6, SOPA/PIPA, Plone, WPS, FileZilla y HTTPS.

Calibración del Touchpad en Linux y GNOME3

Ya comprendí a mi hermana cuando le instalé Debian. Utilizar un Touchpad en una laptop con Linux es una de las peores experiencias que he tenido con este sistema operativo.

El problema: estando escribiendo, cualquier rozón —a veces ni siquiera se necesita un rozón— provoca que el ratón se considere presionado en una ubicación diferente a la del cursor. Esto nos mueve súbitamente el cursor a la ubicación del puntero y quienes mecanografiamos debemos detener nuestra escritura para reubicar el cursor y continuar frustradamente (no sin antes corregir las consecuencias de lo ocurrido: salida de foco, tecleo en un lugar incorrecto, etc.).

Estoy usando una laptop Samsung NP-R540-JA09US. Naturalmente, tan pronto como la recibí, le instalé Debian. A diferencia de la IBM ThinkPad T42 la Samsung no tiene TrackPoint. Mi hermana tenía instalado Debian 6.0 en una laptop HP Pavilion dv6700. Lo menciono porque, al ser diferente hardware, me resulta más fácil echarle la culpa al software. Yo estoy usando Debian Sid; no Wheezy, sino Sid: dos versiones adelante de la estable. Lo que no puedo creer es que nadie más haya experimentado el mismo problema en todo este tiempo.

La mayoría de los linuxeros acostumbramos resolver nuestros propios problemas, así que a veces los desarrolladores no se enteran de la problemática que envuelve a los usuarios novatos y no-técnicos. Llamada de atención para los desarrolladores de GNOME.

Al menos por default, en GNOME, las interfaces para ajustar los parámetros del Touchpad son muy pobres. El afán de hacer las interfaces amigables a veces llevan a los desarrolladores a la falacia de eliminar cosas que realmente son útiles, como los valores numéricos que resultan de un control tipo «slider» (de esos que son como para controlar el volumen, pero rectos). Esto hace que sea difícil tener valores de referencia para calibrar algo tan importante como el equivalente del ratón.

Por ejemplo, para la «detección de palma» tienen un slider cuyos extremos dicen algo así como «leve» y «fuerte». Es un control que no tiene retroalimentación inmediata o visual, con valores sin sentido y sin disponer de una referencia comparativa.

Al usar Debian Sid, actualizar a una versión más reciente de software no es una opción, a menos que quiera arriesgar mi laptop con software experimental y con baja probabilidad de que el problema esté realmente resuelto.

Hecho el berrinche correspondiente, incluyo los pasos que seguí para reducir mi estrés con el uso del Touchpad.

Habilitar de manera personalizada la desactivación del Touchpad mientras escribo

Esta parte la hice bajo GNOME 3. Aunque GNOME Control Center trae una opción llamada «Deshabilitar el Touchpad mientras se escribe», la realidad es que los parámetros de esta opción son extremadamente conservadores.

Lo que esta opción hace es cargar un programa llamado syndaemon, que monitoriza los eventos de teclado y desactiva el Touchpad mientras se detecta que el usuario está escribiendo. GNOME Control Center, en su versión 3.2.2, al menos en Debian Sid, deshabilita el Touchpad durante 2 segundos después del último teclazo, con el inconveniente de que ni siquiera permite el movimiento del puntero.

Para resolver esto, deshabilité dicha función, dejando que el touchpad siempre estuviera habilitado por default, pero yo cargué manualmente syndaemon desde un «Startup Application» (gnome-session-properties) con los siguientes parámetros:

syndaemon -i 0.8 -K -t -R -d

-i 0.8, que deshabilita el Touchpad por sólo 0.8 segundos después del último teclazo.
-K, que no deshabilita el Touchpad si se usan combinaciones de teclas (como Ctrl+W). Esta opción ya la incluye GNOME.
-t, que sólo deshabilita los taps y los scrolls. El puntero se sigue moviendo.
-R, porque ya la incluía GNOME (usa XRecord).
-d, porque ya la incluía GNOME (carga como demonio).

Con esto, espero menos de la mitad del tiempo para poder hacer un tap (y siempre dispongo de los botones de todos modos) y mientras puedo ir moviendo el puntero. Esto hace que el uso de la computadora sea mucho más fluido.

Calibración de la detección de palma

Esto lo hice a nivel X.org. A falta de parámetros reales para calibrar la palma, opté por usar el siguiente comando fuera de X11:

sudo evtest /dev/input/event6 | egrep 'WIDTH|PRESSURE'

Esta instrucción (cambiando event6 por el valor que corresponda en tu laptop) permite ver los eventos que ocurren con el Touchpad, relevantes a la presión y el ancho del toque.

Después de comparar con algunos taps comunes, toques accidentales, mi palma, etc., decidí que después de una anchura de 7 y una presión de 70, se considere palma. Así, creé el archivo /etc/X11/xorg.conf.d/synaptics con las siguientes líneas:

Section "InputClass"
	Identifier "Touchpad" #Requerido
	MatchIsTouchpad "yes" #Requerido
	Driver "synaptics" #Requerido

	Option	"PalmDetect"	"1"
	Option	"PalmMinWidth"	"5" 
	Option	"PalmMinZ"	"70" 
EndSection

Para ver los valores que actualmente tiene su driver de Synaptics (el Touchpad), se usa:

synclient

stail-notify.bash

El siguiente script hace que cada línea nueva que aparezca en un archivo remoto, salte en mi pantalla como notificación.

Con pocas modificaciones se puede hacer lo mismo para un archivo local.

Se puede colocar el comando en el arranque de sesión, pero se va a bloquear para pedir la contraseña. Se recomienda tener acceso al servidor remoto por medio de claves públicas para que el agente de SSH automáticamente pida la contrafrase en pantalla.

Puesto que tail -f nunca debería salirse, tal vez sería conveniente agregar una línea después del SSH que mande una alerta de que concluyó el tail -f o de que falló la conexión con el servidor. Tal vez se pueda hacer revisando el código de retorno, pero hay que ver qué ruido le provoca el tubo.

Se puede modificar para que también el icono y la severidad de la notificación sean distintas, pero en mi caso no es necesario.

El comando podría fallar si la cadena a mostrar contiene comillas.

#!/bin/bash

# stail-notify.bash
# Escrito por Octavio Alvarez.
# Licencia: WTFPL

[ $# -lt 3 ] && {
	echo "usage: "`basename $0`" <user@host> <file-to-tail> <alert-title>"
	exit
}

ssh $1 "tail -n 0 -f "$2 | while read M D T ELSE; do notify-send -t 5000 -i dialog-warning -u critical "$3" "$ELSE"; done

Para usarlo, lo ejecutan así:

stail-notify.bash alvarezp@192.168.2.100 /var/log/messages "Alerta de Syslog"

Dando la bienvenida a los usuarios de IRC con X-Chat 2.

Algunos usuarios, cuando entran a algún canal de charla (como el del Gultij) por IRC, saludan y preguntan si pueden ser ayudados. La gente que tiene más experiencia ya sabe lo que va a ocurrir:

  1. USUARIO_NUEVO entra al canal de charla y, después de no percatarse de lo que dice el topic, dice «tengo una pregunta» o «¿alguien me puede aydar?»
  2. VOLUNTARIO_1 dice «¿cuál es tu pregunta?»
  3. USUARIO_NUEVO le hace la pregunta específicamente a VOLUNTARIO_1.
  4. Si VOLUNTARIO_1 no contesta en menos de 2 minutos USUARIO_NUEVO se siente ignorado y repite la pregunta. Además de que no es obligación del resto del mundo estar atento de sus reclamos, es posible que VOLUNTARIO_1 no sepa, pero sí VOLUNTARIO_2, VOLUNTARIO_3 o VOLUNTARIO_N, que no están en el canal en ese momento.
  5. En ocasiones, cuando USUARIO_NUEVO no recibe respuesta, adopta una actitud donde VOLUNTARIO_1 está obligado a contestarle, como si fuera un servicio pagado de soporte.

Por eso, en los canales de charla, el protocolo es simplemente entrar, hacer la pregunta y ser paciente, muy paciente.

Obviamente, no todos saben esto y no es su culpa. Siempre entrará gente pidiendo ayuda y, claro, hay que darles la bienvenida. Esto toma tiempo, desde 1) estar al pendiente del canal hasta 2) escribir el mensaje de guía a cada usuario para que escriba su pregunta, dando a entender que yo sólo le doy al bienvenida. Para reducir la parte 2, algunos canales tienen un bot al que se le da la instrucción de darle la bienvenida al «usuario nuevo». Yo creo que esto sale contraproducente porque la automatización se revela al usuario.

Para facilitar la parte 2, he configurado en mi X-Chat 2 los siguientes comandos para que la gente reciba un mensaje de mi parte.

/adelante $nick
say %2: adelante, qué pregunta tienes? Tal vez alguien sepa.
/paciencia $nick
say %2, sugiero que esperes un rato. Si alguien te puede ayudar, puede ser que esté ocupado o haya salido un momento.

y sus equivalentes en inglés:

/goahead $nick
say %2, what question do you have? Go ahead and ask; someone around might know.
/patience $nick
say %2, I suggest you wait for a while. If someone can help you, he may be busy or out for a moment.

El de /patience es para cuando el usuario haya repetido su pregunta a escasos minutos.

Aún falta pulir los mensajes para que se vean más naturales pero que, a su vez, abarquen más casos.

De esta manera me facilito el guiar a un usuario nuevo cuyo saludo, con un poco de suerte, yo vea. Creo que sólo siendo amigables con los usuarios nuevos, es como percibirán un valor real en la famosa «comunidad». Para aumentar la probabilidad de detectar un saludo, es posible hacer cosas como configurar el realzado de palabras como «buenas» u «hola», pero esto es harina de otro costal (X-Chat está muy limitado en este aspecto, pero se pueden escribir plug-ins).

Obviamente, si alguien va a tomar esta sugerencia, ponga su propio mensaje a su propio estilo. Realmente sería feo entrar a un canal y ver que 5 usuarios diferentes me contesten exactamente con el mismo mensaje.