domingo, 15 de mayo de 2011

Comportamiento indefinido en C

Comportamiento indefinido en C: "Este ha sido uno de los artículos damnificados por la caída de blogger.com y por eso no lo he puesto aquí antes, pero me gustaría reseñar este What Every C Programmer Should Know About Undefined Behavior 1/3 del blog de LLVM. No solo hace una estupenda introducción al qué y al por qué del comportamiento indefinido en C sino que apunta a una serie de artículos que merece la pena mencionar también: A Guide to Undefined Behavior in C and C++, Part 1, Part 2 y Part 3. Es uno de esos temas que conviene saber (y muy bien) si se pretende hacer código portable. Así que, para leer con detenimiento. Soy un atento seguidor del blog de LLVM, pero esta vez lo he visto en el twitter de TooManySecrets."

Sumando Conocimiento: Buscador Creative Commons y la Biblioteca Virtual Miguel de Cervantes

Sumando Conocimiento: Buscador Creative Commons y la Biblioteca Virtual Miguel de Cervantes: "

“Daría la mitad de lo que sé por la mitad de lo que ignoro.”
-René Descartes

Sumar conocimiento es más que simplemente decir dónde está; o tan siquiera eso es lo que hemos querido hacer aquí en ALT1040 con nuestra sección de Sumando Conocimiento.

Para aquellos que no lo sepan, esta sección es un lugar donde compartimos esos espacios de Internet que nos permiten acceder a herramientas o recursos tanto educativos como informativos, de gran calidad y gratuitamente. Todos estos esfuerzos que hacen de Internet un recurso invaluable y —-sin lugar a dudas— un punto de incidencia en la educación actual.

Esperamos que les guste y les recuerdo que esta sección crece gracias a ustedes; si conocen algúna página que valga la pena recomendar o de las que hayan aprendido algo, no duden en hacérmelo saben en mi cuenta de Twitter (@zapata131) o también puedes dejarlo en los comentarios. Les agradezco de antemano sus colaboraciones.

Buscador Creative Commons

Creative Commons es una licencia muy distinta al conocido Copyright. Todos los contenidos bajo esta licencia están protegidos para que puedan ser copiados, modificados y usados de la manera que más te plazca; siempre dando crédito al autor de la obra. Pero ¿cómo encontrar este tipo de contenido fácilmente?

La solución nos la da la fundación Creative Commons en este práctico buscador que nos permite encontrar contenido en Google, Google Images, Flickr, Jamendo y otros muchos servicios, obviamente toda registrada con licencias de este tipo. Es una manera genial de hacer trabajos y cualquier otro tipo de obra derivada sin infringir ninguna licencia de Copyright, además de que con su uso promueves que el contenido Creative Commons siga creciendo.

Biblioteca Virtual Miguel de Cervantes

Esta biblioteca virtual es uno de los compendios de libros en epañol libres más grandes que podemos encontrar en Internet. Las obras que guarda y a las que podemos acceder en hasta cuatro formatos distintos —video, libro electrónico, HTML o audio— son en su mayoría clásicos de la literatura que forman parte del dominio público, pero también podemos encontrar obras actuales que son verdaderamente interesantes.

Este proyecto nace gracias a la colaboración de muchas otras instituciones que han dado tanto su tiempo como recursos para —abrazando las nuevas tecnologías— sumar conocimiento. Les recomiendo que le den un vistazo a la Biblioteca Americana y a las otras que forman parte de su amplio catáogo.

Sumando Conocimiento: Buscador Creative Commons y la Biblioteca Virtual Miguel de Cervantes escrita en ALT1040 el 15 May, 2011 por zapata131
Enviar a Twitter | Compartir en Facebook





"

domingo, 8 de mayo de 2011

A qué huelen los píxels

A qué huelen los píxels: "

Me encanta el olor a píxels por la mañana ...



Si no lo entiendes quizás no viste Apocalypse Now




"

GNU/Linux y Mac OS, los que más crecieron en 2010

GNU/Linux y Mac OS, los que más crecieron en 2010: "

Los sistemas basados en Linux y Mac OS fueron los sistemas operativos que más aumentaron su cuota de mercado en 2010, que sigue dominado por Windows, sistema que acapara un 78,6% de los dispositivos. Hablamos de un mercado que, el año pasado, movió unos 20.700 millones de euros, un 7,8% más que en 2009. En lo referente a los SOs basados en Linux, Red Hat sigue siendo el dominador.



Microsoft sigue dominando el mercado de los sistemas operativos, con ese 78,6%. Este porcentaje se ha visto aumentado con la llegada de Windows 7, tras el no muy popular Windows Vista.


Otra de las compañías relevantes en el mundo Linux, Oracle, ha visto disminuidos sus ingresos de Solaris en un 3,2% que, por otro lado, se ha visto compensado debido a Unbreakable Linux.


Visto en channelinsider.

"

Wakfu: Nuevo Mmorpg con cliente para Linux

Wakfu: Nuevo Mmorpg con cliente para Linux: "

Gracias a @turf3nix me hago eco de Wakfu, un nuevo Mmorpg que, como bien me comenta (y cuyo comentario además me ha hecho sonreir):


Comunicarte sobre una noticia muy agradable como es la salida de un nuevo mmorpg con cliente nativo para linux y con muy buena pinta….es WAKFU cuya serie se estreno en boing este fin de semana y que conocí gracias a mi hijo.

te dejo el enlace ….http://www.wakfu.com/es/mmorpg para que lo hagas que lo difundas como tu sabes a todos tus cachorros (entre los que me incluyo).


Pues muchas gracias @turf3nix, la verdad si que tiene buena pinta (lastima que yo no tenga tiempo ni para jugar, pero bueno, aqui lo dejo que alguien si podra y te lo agradecera tambien).



"

Acceso a un servidor ssh en tu LAN

Acceso a un servidor ssh en tu LAN: "

Si trabajáis en red, lo más probable es que, tarde o temprano, utilicéis varias terminales con sistemas GNU/Linux, si es que no lo habéis hecho ya… Éstas pueden ser destinadas a numerosas tareas, aparte de terminal de escritorio. A saber: servidor de datos, backups, proxy cache, firewall, fax, etc. En estos casos, no es necesario tener montado todo lo que acompaña a un PC (teclado, mouse y monitor) ya que podremos acceder, por ejemplo, vía escritorio remoto (si tenéis X en el equipo) o ssh. A continuación, encontraréis las instrucciones para esto último, utilizando Debian como distro servidor.



(*) Apuntes previos: no me ocuparé aquí de describir el protocolo ssh. Tenéis a vuestra disposición una enorme cantidad de información en la Red. En el equipo que hace de servidor ssh, se ha instalado previamente Debian y se ha configurado el acceso a Internet. Los comandos que requieren ser root, aparece la expresión [root] sobre ellos.


Primero, vamos a instalar openssh:


[root]


apt-get install openssh-server


Tras esto, tan sólo tendríamos que abrir el puerto 22 de nuestro router para la IP del servidor para poder acceder a él vía ssh. Sin embargo, es conveniente asegurarlo un poco más.


Con un editor de texto, editaremos el archivo sshd_config. En mi caso, utilizaré mousepad.


[root]


mousepad /etc/ssh/sshd_config


Añadiremos los usuarios a los que deseamos permitir acceso, escribiendo lo siguiente:


AllowUsers nombre_del_usuario1 nombre_del_usuario2


Es conveniente no utilizar el puerto por defecto de ssh, el 22. Veréis una línea , cerca del inicio del texto, donde aparece “Port 22″. Cambiad el 22 por el puerto que prefiráis. En mi caso, el 9999.


También por precaución es conveniente cambiar denegar el acceso de root por defecto. Esto se logra cambiando “PermitRootLogin yes” por “PermitRootLogin no”.


Otras medidas de precaución:


Editar el archivo hosts.deny:


[root]


mousepad /etc/hosts.deny


Añadimos lo siguiente:


sshd: ALL


De este modo, todo aquél que no tenga permitido el acceso en hosts.allow, no podrá entrar. Para habilitar acceso a determinadas IP de nuestra LAN, editaremos ese archivo.


[root]


mousepad etc/hosts.allow


Añadimos la o las IP que deseamos que tengan acceso. Por ejemplo:


sshd: 192.168.0.2


Tras guardar todos los cambios, reiniciaremos el servicio:


[root]


/etc/init.d/ssh restart


El acceso desde terminales con GNU/Linux puede realizarse mediante openssh-client, presente en los repositorios de numerosas distros. Tras instalarlo, tan sólo tenemos que ejecutar lo siguiente:


ssh -p 9999 nombre_del_usuario1@IP_del_servidor_ssh


Si tenéis que acceder desde terminales Windows podéis utilizar Putty, por ejemplo.


Estas medidas de precaución son, más o menos, las que podríamos calificar de “estándar”. Para otras opciones, podéis consultar aquí los consejos de nuestros compañeros de redeszone.

"

miércoles, 4 de mayo de 2011

Varios desarrolladores de Spotify ganan un concurso de programación

Varios desarrolladores de Spotify ganan un concurso de programación: "

Hace unos días en el blog de Spotify se podía leer una noticia sobre la participación de varios de sus miembros del equipo de desarrollo en un concurso de programación llamado Challenge 24, organizado en Hungría por la Universidad de Tecnología y Económicas de Budapest, y que consistía en un maratón de programación durante 24 horas.

Durante ese tiempo los equipos participantes debían someterse al desafío de resolver varios problemas técnicos mediante el uso de algoritmos, y llegados a la final, cuyo contenido es secreto, poner a prueba un amplio rango de conocmientos y habilidades de programación, según la propia página del concurso.

Pues bien, parece ser que los dos equipos de programadores de Spotify han ganado el concurso, quedando en primer y segundo puesto, como cuentan en su blog.

Las pruebas a las que finalmente tuvieron que someterse y que no se supieron hasta la final consistían en desarrollar diversas tareas, desde programar una CPU de 4-bits mediante tarjetas perforadas —todo un clásico— hasta diseñar una galaxia para realizar navegaciones celestiales.

Aparte del galardón que se llevan los integrantes del equipo, por el que les felicitamos, Spotify también lleva varios días anunciando un concurso de programación organizado por ellos mismos, que llevará el original nombre de Spotify Programming Challenge, y cuyas fechas y contenidos se anunciarán previsiblemente en los próximos días.

Varios desarrolladores de Spotify ganan un concurso de programación escrita en Bitelia el 3 May, 2011 por Randal
Enviar a Twitter | Compartir en Facebook





"

JSON como formato de intercambio para la web

JSON como formato de intercambio para la web: "

Hace años que hablaba de YAML, como formato de intercambio alternativo a XML, que nunca me ha convencido (tentador... pero no voy a explicar otra vez porqué no me gusta :P).


No sé porqué por aquel entonces YAML me resultaba tan atractivo, pero igual es porque en Perl resulta muy fácil trabajar con YAML (mucho más que pelearnos con XML y sus módulos para Perl).


Por ejemplo, la configuración de Nautilus Flickr Uploader la guardo en formato YAML:


---
family: no
friends: no
privacy: public
resize: yes
size: 2048
token: XXXXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXX
username: reidrac

Se entiende perfectamente y no hay problemas para editar a mano si es necesario, ¿verdad?


No obstante, desde que trabajo con Python me he pasado completamente a JSON, quizás porque está muy bien soportado en el lenguaje para serializar casi cualquier objeto (con simplejson, hasta que en Python 2.6 se incluyó un módulo json en los módulos base).


JSON (de JavaScript Object Notation) más o menos es igual de legible que YAML, y resulta muy fácil de manipular no solo en Python, que es el lenguaje que uso en el servidor, sino también en Javascript, que es el lenguaje del cliente. Basicamente porque JSON es Javascript ;).


La configuración de Nautilus Flickr Uploader quedaría como sigue en JSON (usando json.dumps(conf, indent=1); sin el indent los objetos complejos pueden ser un poco ilegibles :P):


{
'username': 'reidrac',
'token': 'XXXXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXX',
'family': 'no',
'privacy': 'public',
'friends': 'no',
'resize': 'yes',
'size': 2048
}

En realidad no hay mucha diferencia, y sigue siendo mejor que XML, pero donde realmente veo la ventaja es cuando intercambiamos datos entre Python y Javascript.


Siguiendo con nuestro ejemplo:


>>> import json
>>> conf = {
... "username": "reidrac",
... "token": "XXXXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXX",
... "family": "no",
... "privacy": "public",
... "friends": "no",
... "resize": "yes",
... "size": 2048
... }
>>> print "var conf = %s;" % json.dumps(conf)
var conf = {"username": "reidrac", "family": "no", "privacy": "public", "token": "XXXXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXX", "friends": "no", "resize": "yes", "size": 2048};
>>>

Tan sencillo ha sido generar código Javascript. Podemos probar con un navegador cualquiera:


var conf = {"username": "reidrac", "family": "no", "privacy": "public", "token": "XXXXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXX", "friends": "no", "resize": "yes", "size": 2048};

/* recorremos el objeto que hemos generado desde Python */
for (key in conf) {
document.write("<p>La propiedad " + key + " contiene " + conf[key]);
}

Bueno, es más bien un ejemplo tonto (hasta el diccionario en Python es idéntico a la representación en JSON), pero creo que vale para mostrar lo sencillo que es pasar datos a nuestro código Javascript al generar la vista HTML desde nuestro framework Python favorito.

"

martes, 3 de mayo de 2011

Android+Skype – All your data are belong to us

Android+Skype – All your data are belong to us: "

El pasado viernes la conocida empresa Skype confirmaba en su blog los rumores sobre la posibilidad de tener acceso a los datos de carácter privado almacenados por la aplicación en dispositivos Android.


El problema aún se agrava más si tenemos en cuenta que estos datos no están cifrados, por lo que cualquier podría utilizarlos sin mayor problema para fines delictivos.


Nuevamente volvemos a encontrarnos ante el problema de infectar aplicaciones de terceros en las que incluir el código malicioso para robar los datos.

Introducción

El objetivo de esta entrada es analizar cómo está desarrollado el exploit para vulnerar la privacidad de los usuarios y hacer un pequeño repaso al tema de análisis forenses a dispositivos android para dejar entrever algunas de sus deficiencias.


Como requisitos previos será necesario disponer de acceso root al teléfono, para ello podemos guiarnos de la aplicación SuperOneClick y tener instalado el SDK para hacer uso del Android Debug Bridge (ADB).

Skypwned

Cuando instalamos Skype y establecemos conexión por primera vez con nuestra cuenta, en la jerarquía de carpetas de la instalación se crea una nueva con nuestro nombre de usuario, y se almacenan ahí todos los ficheros como contactos, perfil, logs de las conversaciones mantenidas y bases de datos sqlite3


El problema viene con la forma de otorgar los permisos, donde hacen posible la lectura y escritura de todos los ficheros para cualquier usuario. De esta forma es relativamente sencillo conseguir acceso remoto a través de cualquier aplicación a las carpetas deseadas, hacer una copia y enviarlas a otro lugar donde tratar la información más detenidamente.


# ls -l /data/data/com.skype.raider/files/arriba_laesteban
-rw-rw-rw- app_62 app_62 331776 2011-04-16 00:08 main.db
-rw-rw-rw- app_62 app_62 119528 2011-04-16 00:08 main.db-journal
-rw-rw-rw- app_62 app_62 40960 2011-04-14 14:05 keyval.db
-rw-rw-rw- app_62 app_62 3522 2011-04-15 23:39 config.xml
drwxrwxrwx app_62 app_62 2011-04-14 14:05 voicemail
-rw-rw-rw- app_62 app_62 0 2011-04-14 14:05 config.lck
-rw-rw-rw- app_62 app_62 61440 2011-04-15 00:08 bistats.db
drwxrwxrwx app_62 app_62 2011-04-14 21:49 chatsync
-rw-rw-rw- app_62 app_62 12824 2011-04-14 14:05 keyval.db-journal
-rw-rw-rw- app_62 app_62 33344 2011-04-14 00:08 bistats.db-journal


Para demostrar el impacto, AndroidPolice desarrolló un pequeño POC llamado Skypwned. El APK (e788c146fbeaf4152d57c12711c4bdbd ) presenta la siguiente estructura una vez desempacado y pasado dex2jar y JAD:


sebas@Helios:~/Android/research/Source_Code_JAD$ tree .
.
|-- a.jad
|-- b.jad
|-- c.jad
|-- d.jad
|-- e.jad
|-- f.jad
`-- Main.jad

0 directories, 7 files


El trozo de código qué aprovecha este fallo podéis verlo aquí. Básicamente busca ficheros específicos y reserva memoria para varios strings donde se forman las consultas para lanzarlas a la base de datos y sacar así los datos que nos interesan : información de los contactos, perfiles, logs, y demás. El fallo, está presente en varias compilaciones de la aplicación también, aquí si las cosas se hacen mal, que sean desde el principio...


El problema viene ante la posibilidad de un vector de ataque en el que se utilicen aplicaciones de terceros para inyectar ese trozo de código, empacar el APK de nuevo y lanzarlo al market. Provocando así una infección masiva que revele los datos privados de cientos de usuarios. Incluido el número de la tarjeta de crédito en caso de que se tenga asociada a la cuenta de Skype así como los logs de las conversaciones.


Supongamos que por un casual fuese Google el que tiene este fallo, y es su aplicación de Google Talk la que tiene este problema y deja expuestos los de sus usuarios, números de teléfono y agenda de contactos. Sería un desastre ¿verdad?.


El POC en funcionamiento podéis verlo en este vídeo realizado por AndroidPolice:














¿Dónde está el problema?



Analizando más detenidamente el núcleo del error, nos damos cuenta de que se han producido tres fallos esenciales de cierto calibre:
  • No se han aplicado correctamente las políticas de los permisos, dejando datos de importancia a la vista de los más curiosos. La solución a esto es bastante clara, otorgar las restricciones pertinentes.

  • Los datos son almacenados sin aplicarse ningún esquema de cifrado, de forma que el usuario que tenga acceso a ellos se lleva el premio gordo. Esto sigue siendo uno de los principales problemas desde mi punto de vista, se hace necesaria una capa de protección que cifre el contenido importante del teléfono.

  • Toda aplicación antes de ser lanzada, ha de pasar por unos mínimos de calidad. Estos problemas se hubieran evitado si se hubiera realizado un análisis exhaustivo de la misma antes de hacerla pública. Un mal ejemplo que deja en evidencia una empresa importante como Skype.



Evidentemente todo esto podría haberse evitado, ¿pero es un error que sólo comete Skype?


A mí las cosas me gustan claras



Podríamos pensar que esto es un hecho aislado y que está todo bajo control, pero si nos aventuramos a realizar un forense al teléfono podemos llevarnos más de una sorpresa. ¿Están nuestros datos protegidos?.


Para llevar a cabo nuestro análisis vamos a utilizar el SDK de Android que trae consigo la herramienta ADB. Otra opción es también montar un servidor SSH en el teléfono con la aplicación QuickSSHd y conectarnos en remoto desde un equipo, pero las transferencias al realizar movimientos de ficheros son más lentas.


Para ver los dispositivos conectados utilizamos:


sebas@Helios:~/Android/sdk/platform-tools$ ./adb devices
List of devices attached
emulator-5554 device
HT07DP800223 device


En este caso estoy corriendo un Nexus One con id HT07DP800223 y un emulador para las pruebas. Vamos a centrarnos en el primero.


Estructura interna

Cuando levantamos una shell a nuestro teléfono y solicitamos un listado del directorio raíz observamos:


sebas@Helios:~/Android/sdk/platform-tools$ ./adb -s HT07DP800223 shell
$ ls
config
cache
sdcard
acct
mnt
d
etc
system
sys
sbin
proc
init.rc
init.mahimahi.rc
init.goldfish.rc
init
default.prop
data
root
dev


Si echamos un vistazo a cómo está montado el sistema de ficheros:


$ mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0
/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev,relatime 0 0
/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:1 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0


Podemos observar que existen varios puntos de montaje en distintos mtdblocks para cada directorio importante en nuestro teléfono. Así tenemos:
  • /system en /dev/block/mtdblock3

  • /cache en /dev/block/mtdblock4

  • /data en /dev/block/mtdblock5

En caso de tener una tarjeta SD externa vemos como esta es montada en /sdcard.


Este subsistema de ficheros es conocido como Memory Technology Devices (MTD) y se caracteriza por embeber y dividir el sistema en un medio flash a diferencia de dispositivos de bloque tradicionales como podemos encontrar en cualquier equipo corriente. Llegados a este punto observamos que la nomenclatura utilizada es muy tradicional a los discos IDE o SATA, siendo en este caso utilizada /dev/mtd*


Si queremos obtener más información podemos consultar el /dev y obtenemos:


$ ls /dev/mtd*
mtd5ro
mtd5
mtd4ro
mtd4
mtd3ro
mtd3
mtd2ro
mtd2
mtd1ro
mtd1
mtd0ro
mtd0


Podemos distinguir para cada dispositivo que tiene asociado un ro (Read Only) Por lo que si deseamos hacer una correlación y traernos al equipo el punto de montaje a analizar tendrá que ser aquel que no sea de lectura sólo, para ello utilizaremos el comando dd:


# dd if=/dev/mtd/mtd5 of=/sdcard/data/mtd5.img bs=2048
100480+0 records in
100480+0 records out
205783040 bytes transferred in 108.504 secs (1896547 bytes/sec)




Nos traemos el fichero a nuestro entorno de trabajo con el comando pull:


sebas@Helios:~/Android/sdk/platform-tools$ sudo ./adb pull /sdcard/data/mtd5.img /home/sebas/Android/research/mtd5.img
1799 KB/s (205783040 bytes in 111.650s)


Ahora podemos comenzar la investigación buscando strings que nos revelen información como claves, base de datos o nombres de usuarios:


sebas@Helios:~/Android/research$ strings -a ./mtd5.img | grep databases | more

...
/data/data/com.android.providers.contacts/databases/contacts2.db-journal
/data/data/com.google.android.gsf/databases/talk.db-journal
/data/data/com.google.android.gsf/databases/talk.db-mj157DA2E7
...


Sabemos que en el directorio /data/data vamos a tener todas aplicaciones instaladas con sus respectivas bases de datos. Será más fácil para trabajar traernos todo el directorio al completo a local.






Facebook, Tuenti, Youtube, Google Apps, MMS, contactos, Tweetdeck. Toda la información de acceso se encuentra en sus respectivas bases de datos, aunque algunas están vacías porque nunca he acabado usando la aplicación. ¿Qué pasaría si perdiésemos nuestro teléfono?



Por ejemplo Tuenti:




A pesar de que nuestro password está cifrado utilizando MD5, sería relativamente cuestión de tiempo y GPU realizar un ataque de fuerza bruta o combinado con diccionarios para romper la clave.


Más ejemplos así podemos encontrarlos en Facebook:






Otras veces no es ni necesario consultar a la base de datos, podemos encontrar en shared_prefs un fichero XML en el que se incluye información interesante.


Por ejemplo este caso de la aplicación Delicious:




Si piensas que únicamente sucede con las aplicaciones, miremos los SMS a ver cómo se muestran:







Conclusiones

Cada vez es más habitual que los usuarios de smartphones lleven su vida digital sincronizada a su teléfono con el considerable volumen de información que ello conlleva.


Emails, redes sociales, agendas, contactos, calendarios, son expuestos automáticamente en caso de perder el dispositivo. Alguien con bajos conocimientos puede perfectamente extraer todos los datos que le interesen y utilizarlos como mejor le convenga.


El problema no viene evidentemente del usuario, sino de los propios desarrolladores que permiten utilizar sus aplicaciones sin forzar el uso de cifrado y contraseñas.


Diversos motivos son los que mantienen enfrentados a detractores y defensores, ¿Es necesario realmente proteger nuestros datos?, ¿A qué coste?, ¿Cifrado completo o parcial de los datos?, ¿Compensa tener más cercana nuestra vida digital sabiendo el peligro que corremos?


De soluciones se ha hablado mucho, utilizar sqlitecrypt, cifrar los datos que se almacenan en la BD y utilizar una clave maestra para descifrarlos cuando se sirvan a terceros, lvm-crypt. Pero nunca se llega a un acuerdo entre eficiencia y rendimiento.


En lo personal, creo que a día de hoy, nuestros teléfonos son los sustitutivos de nuestros equipos personales cuando no nos encontramos en casa, el trabajo o dónde sea. Y cada vez el flujo de datos e información que es manejado es mayor, aumentando así la responsabilidad en la protección y cuidado de los mismos. Un claro ejemplo podemos citarlo con Blackberry cuyas comunicaciones van cifradas. ¿Cuánto tiempo pasará hasta que se sucedan los típicos leaks?




---------
Contribución por Sebastián Guerrero
"

lunes, 2 de mayo de 2011

Google podría estar probando el reconocimiento de voz en el buscador

Google podría estar probando el reconocimiento de voz en el buscador: "

El miércoles pasado llegó la nueva versión del navegador de Google, Chrome 11, y una de sus novedades era el reconocimiento de voz, implementado con HTML5 y que estaba orientado, en principio, a Google Translate. La idea no distaba mucho de la aplicación de Google Translate para iOS, es decir, la capacidad de dictar a la aplicación para, posteriormente, traducir lo que se había dictado, trasladando la experiencia al navegador de escritorio (aunque sólo esta disponible en Inglés). Lógicamente, esta capacidad para reconocer la voz puede ser trasladada a otros ámbitos y, según parece, Google estaría probando el reconocimiento vocal en su buscador, de manera que los usuarios puedan dictar los términos de búsqueda.

google-speak-now-1304341200

En principio, no deja de ser un rumor y algunas fuentes han cuestionado la información porque, básicamente, se puede lograr ese mismo efecto instalando en Chrome la extensión de Voice Search, sin embargo, el usuario que dado la voz de alerta afirma que no estaba usando extensión alguna, de hecho, algún que otro usuario ha reportado algo similar a través de Twitter por lo que, algunos sí que estarían dando el rumor como cierto puesto que este tipo de capacidades también se han probado en dispositivos móviles.

¿Todo un alarde tecnológico o una función útil? Yo diría que ambas cosas. Por un lado, Google nos estaría demostrando, de ser cierto este rumor, que dominaría, con cierta solvencia, el reconocimiento de voz (al menos en la lengua de Shakespeare) y que es capaz de implementarlas en HTML5, lo cual deja bastante claro su dominio de este lenguaje. Por otro lado, al igual que nos demostró con el Google Translate de iOS, poder manejar aplicaciones y dispositivos con la voz, evitando usar el teclado, además de abrir todo un mundo de aplicaciones y posibilidades, desde el punto de vista de la accesibidad es todo un salto cuantitativo.

Google podría estar probando el reconocimiento de voz en el buscador escrita en Bitelia el 2 May, 2011 por jjvelasco
Enviar a Twitter | Compartir en Facebook





"

Café vs Té (Infografía)

Café vs Té (Infografía): "

coffee.v.tea-1.jpg


Fuente

Entradas relacionadas:



  • No se encontraron entradas relacionadas

"