Las vulnerabilidades y su desconocimiento en las empresas

 

 

Symantec ha publicado un «Libro Blanco de Seguridad» [PDF] en se análiza la relación entre las evaluaciones de vulnerabilidad y el grado de conocimiento sobre la seguridad de un sitio web.

Una empresa que realice evaluaciones de vulnerabilidad con asiduidad sabrá a ciencia cierta si su sitio web es seguro.

Sin embargo, más de la mitad de los encuestados (el 53 %) nunca han hecho una evaluación de este tipo, quizá porque muchos desconocen que el malware constituye un problema cada vez más grave. El 15 % habían llevado a cabo una evaluación de vulnerabilidad en el mes anterior al sondeo; el 16 %, en los últimos seis meses; y el 16 %, en el último año. La mayoría de los que han hecho evaluaciones suelen repetirlas. El 52 % de las empresas encuestadas pertenecientes a este grupo habían hecho varias en los últimos doce meses, y un cuarto las practican con regularidad.

Fuente: Symantec

 

Android, iOS, tiempos de respuestas y por qué nada es gratis en sistemas informáticos

Hace unas pocas horas escribí esta respuesta sobre Por qué iOS es más fluido que Android (con buen criterio, eliminaron la entrada). Obviamente, por cuestiones de longitud y la “respuesta rápida” que requiere un comentario, no me quedó todo lo completo que requiere el tema. Lo que me gustaría explicar daría para muchas horas de charlas. De hecho, enseño estos temas en mi asignatura de Sistemas Operativos (II), dedico al menos unas 12 hs de clase, y aún así no entramos en muchos detalles importantes. Pero intentaré resumirlo en este apunte, fundamentalmente para que se entiendan los problemas de arquitectura, y de cómo toda decisión que se tome en una arquitectura, lenguaje o programa tiene implicaciones positivas y negativas, siempre.

Lo básico

Apple tomó muchas decisiones técnicas con el objetivo de mejorar la “experiencia de usuario”, pero por sí mismas serían inútiles -o más perjudiciales- si no van acompañadas de medidas de control estrictas. Es fundamental el papel de los controles de las aplicaciones en el App Store (¡ojo! no los justifico). Independientemente de otras consideraciones políticas, dado su simplicidad y soluciones ad hoc, el iOS sería muy fácil de “abusar” por los desarrolladores y aplicaciones.

Por el contrario, Android es una plataforma abierta que puede user cualquier fabricante, que permite la instalación de cualquier aplicación. El control de aplicaciones del Market por parte de Google es prácticamente inexistente. Esto hace que no valgan soluciones ad hoc, obliga a implementar en el sistema operativo medidas de seguridad y control “canónicas”, en el sentido que mantenga las condiciones fundamentales de todo sistema operativo de propósito general: eficiencia, equidad (fairness) y seguridad.

Cualquiera que haya estudiado la teoría y arquitectura de sistemas operativos (o que haya leído sobre el tema) entiende perfectamente que la eficiencia, equidad y seguridad son objetivos contradictorios. Mayor equidad o seguridad afectan negativamente a la eficiencia, y viceversa.

Hay otro problema importante. Se desea que los sistemas operativos de teléfonos actúen como sistemas de tiempo real también para las aplicaciones (ya tienen que serlos en otros aspectos, como la “radio” a interacción con protocolos de red de telefonía).  Es decir, con límites precisos de “tiempo de respuesta”: el tiempo que transcurre desde que ocurre un evento (como tocar la pantalla) hasta que se empieza a ejecutar al “gestor” de ese evento (la aplicación).

Los sistemas Unix (como Linux o Darwin) no son de tiempo real, su planificador de procesos (scheduler) es no-determinístico. No lo es por una sencilla razón: si se pretende una buena “multiprogramación” (llamada comunmente “multitarea”) se deben cumplir los objetivos de equidad y otros más complejos, como evitar los tiempos de espera muy largos (starvation). Esos dos objetivos impiden asegurar (formalmente) que el sistema sea de tiempo real. Además, los sistemas de tiempo real exigen que el tiempo de ejecución de cada ráfaga de ejecución de las aplicaciones (CPU bursts) críticas sea lo suficientemente breve para poder asegurar “tiempo real” a las demás aplicaciones (recordad que el scheduler debe ser determinístico, por ende no puede asegurar equidad).

En pocas palabras, si deseas comportamientos próximos al tiempo real necesitas relajar los requerimientos de un sistema de propósito general, y aumentar el control de las aplicaciones que se ejecutan en ese sistema.

¿Se entiende el balance y decisiones contradictorias que hay que tomar? En un sistema de multiprogramación, con el hardware equivalente (los dispositivos iOS y Android lo son), si  se desea disminuir las latencias se deben relajar otras condiciones del planificación de procesador (por lo que se obtiene una “peor multitarea”) y aumentar el control de aplicaciones (lo que genera otros problemas polítics, éticos, sociales y de negocio). Si pretende más apertura y libertad, se debe ser muy estricto con equidad y seguridad, lo que genera efectos negativos sobre el tiempo de respuesta.

Al final el tema de fondo no es [sólo] técnico, sino de otros aspectos más filosóficos: control vs apertura.

Creo que ya expliqué la base del problema técnico-filosófico, ya puedes dejar de leer si te agobian los detalles técnicos. Pero si te interesan, intentaré resumirlos en las cuatro partes que tienen más responsabilidad en los “tiempos de respuesta” de un sistema: las aplicaciones, el lenguaje y plataforma, la gestión de memoria, y el scheduler.

Las aplicaciones

El tipo de programación para móviles es esencialmente “dirigida por eventos” . Cuando el usuario toca la pantalla se llama la función que debe responder a ese evento (en Android se llaman “actividades”). La recomendación es que la aplicación no necesite mucha CPU ni tiempo para generar la respuesta, especialmente en los menús principales. Por supuesto, a este nivel, todo depende de los programadores de la aplicación, y supongo que estos son los mayores culpables de la “reacción lenta” de los menús cuando se interactúa con una aplicación.

Las aplicaciones también pueden tener otros malos comportamientos, por ejemplo consumir mucha CPU (aún cuando están en background o como servicio), no sólo molesta a todos los demás procesos, también aumenta el consumo de batería y la temperatura.

¿Cómo solucionar este problema? O se hace un control estricto de cada aplicación, o se implanta un scheduler más sofisticado y genérico que puede tener algunas aristas.

Ya sabéis qué decisión se tomó en Apple, y cuál en Google.

El lenguaje y plataforma

iOS y Android difieren mucho en este aspecto.iOS usa el mismo lenguaje estándar del Mac OS X, el Objective-C. Los programas se compilan directamente en código ejecutable para el procesador. En cambio Android optó por usar Java, que se convierte a un lenguaje intermedio ejecutado por una máquina virtual optimizada (similar la máquina virtual de Java, pero es diferente), Dalvik.

Obviamente el rendimiento entre ambas es muy diferente, el código ejecutable siempre será más eficiente que otro se que no se ejecuta directamente en el procesador. Pero esto no significa que los diseñadores de Android sean unos imbéciles, de nuevo, fueron decisiones estratégicas que están muy por encima de temas técnicos, aunque terminan afectando dramáticamente a este último.

Si el sistema operativo se va a ejecutar siempre sobre una única arquitectura, como hizo históricamente Apple (aunque tuvo dos migraciones importantes, exitosas pero dolorosas y muy molestas para los desarrolladores), la opción natural es generar directamente el ejecutable. Además, Apple licenció el diseño de ARM [*] y compró una empresa de diseño de chips (Intrinsity) para que se encargue del diseño de sus procesadores y no depender ni de fabricantes externos (antes lo hacía Samsung).

Por otro lado, la intención de Android era entrar a competir en el mercado con un sistema libre/abierto y multiplataforma (después de varios intentos fallidos, como OpenMoko), por  lo que era preferible un sistema que no obligase a compilar una aplicación para cada tipo de procesador. Si no, estaría condenada al fracaso. Para solucionar el problema de la eficiencia diseñaron desde cero el Dalvik, que al usar el lenguaje Java ya tenía a su disposición muchas herramientas (como Eclipse), librerías de desarrollo (como las clases estándar de Java), y una comunidad enorme de progamadores (me abstengo de opinar sobre Java, pero afortunadamente Android lo ha mejorado muchísimo con su API y framework  de programación).

Aunque Java ya está preparado para multithreading, por cuestiones de seguridad los diseñadores de Android prefirieron, muy acertadamente, ejecutar cada aplicación como un proceso diferente y completamente aislado. Dejaron esta parte de la gestión de procesos al núcleo Linux, que es muy eficiente y está más que probado.  Con esta arquitectura de máquinas virtuales replicadas en procesos independientes, se generan otras infeficiencias: cada proceso debe cargar su máquina virtual, y éste debe cargar después todas las clases estándar de Java que hacen falta para la aplicación. Esto haría que el tiempo de arranque de cada programa fuese inaceptable, y han recurrido a un truco muy guapo para solucionarlo (por eso digo que la arquitectura de Android es una obra impresionante de ingeniería informática): el zygote.

El kernel Linux implementa un mecanismo llamado copy-on-write ( COW) que permite que los procesos hijos (creados con el fork()) compartan memoria con el padre (por eso la creación de procesos es muy rápida de Linux). Cuando un proceso crea un hijo, éste reusa la misma memoria y tablas de páginas del padre, pero todas las páginas se marcan como “sólo lectura”. El hijo puede comenzar a ejecutarse muy rápidamente. Cuando uno de los procesos intenta escribir sobre una página compartida, se genera una interrupción de error (trap), el sistema operativo coge el control, verifica que se trata de memoria COW, asigna una nueva página, copia el contenido de la página afectada, modifica la tabla de páginas de uno de los procesos para apuntar a esta nueva, y permite la continuación de ambos procesos. Además de la rapidez con que puede crear y ejecutar procesos, se ahorra mucha memoria RAM, por ejemplo, el código ejecutable y las librerías comunes siempre se comparten (nunca se modifican).

¿Cómo aprovecha Android este mecanismo? Crea un proceso inicial, el zygote, que carga la máquina virtual y las librerías estándares de Java y del API de Android. Cada nueva aplicación que se arranca es hija de este zygote, et voilà, ya ganaron eficiencia y se ahorra muchísima memoria (Chrome y Chromium usan la misma técnica para abrir pestañas y ventanas rápidamente).

¿Es o no es una obra maestra de ingeniería? Claro que sí, se han tomado todo ese trabajo para compensar el problema de eficiencia y seguridad de una máquina virtual. Por eso, cuando pienso que por debajo hay una máquina vrtual ejecutando el código, me maravillo con la velocidad de ejecución de las aplicaciones en Android.

Por supuesto, esta arquitectura con memoria virtual tiene otros efectos negativos a la hora de medir los tiempos de respuesta: en la gestión de memoria y cache, que trato más adelante.

[*] En la biografía de Steve Jobs cuentan como despuésde evaluar usar Intel para los iPad, Jobs le dijo muy cabreado a los ejecutivos de Intel algo así como: “son muy buenos para procesadores de alto rendimiento, pero sois unos inútiles para procesadores de bajo consumo”.

La gestión de memoria del núcleo

Los procesadores que usan iOS y Android son similares en cuanto a su gestión de memoria (también similares a los ordenadores que usáis). Ambos gestionan memoria virtual conpaginación. Los procesos no generan direcciones físicas de RAM, sino direcciones lógicas que son convertidas a direcciones físicas en cada ejecución por el módulo conocido como Memory Manager Unit (MMU). Cada proceso tiene sus propias tablas de página que mantienen la relación de número de página del proceso (es el índice a la tabla) a ubicación en la memoria RAM. Los procesadores ARM permiten páginas de 4KB a 64KB (lo usual son 4KB), así que cada aplicación tiene miles de páginas, y por lo tanto tablas de miles de entradas (en ARM hay tablas de dos niveles, en la arquitectura Intel o AMD, cuatro niveles).

Cada entrada de la tabla almacena propiedades de la página: lectura (r), escritura (w), ejecución (x), accedida (a, o acces bit), modificada (d, o dirty bit), cargada en memoria (p, present bit), etc. Por esta razón las tablas se mantienen en la memoria RAM, lo que genera otro problema ¿cómo hace el MMU para no tener que acceder dos veces a la memoria -primero a la tablas de página y luego a la dirección que se pretende acceder-? Sin un mecanismo que lo solucione, el tiempo efectivo de acceso a la memoria sería al menos el doble de lo que permite la memoria RAM (o sea, una patata de lento).

Para solucionar este problema se usan sistemas de cache que almacenan en registros del procesador un conjunto de entradas de las tablas: el translation-lookaside-buffer (TLB). El TLB de los ARM suelen tener 128 entradas, cada una de ellas es una copia idéntica de la entrada de la tabla de páginas. Se intenta tener en el TLB las entradas más usadas, así, cada vez que el MMU encuentra la entrada en el TLB puede acceder directamente a la memoria (hit), si no, tiene que descartar una entrada y cargar la que hace falta (fault). El hit ratio es una indicación de la velocidad de acceso efectivo a memoria, viene dado por el procesador y el algoritmo de sustitución que se use, a mayor número de entradas en el TLB, el hit ratio sube.

Cada vez que el scheduler selecciona otra aplicación para ejecutar se produce un cambio de contexto, entre otras cosas significa que las entradas del TLB deben ser invalidadas (ya no sirven para el nuevo proceso, por seguridad tampoco debe poder usar esos datos), además las entradas que han sido modificadas por el procesador (por ejemplo, que una una página fue accedida o modificada) deben ser copiadas a la tabla original en memoria (flush). Por eso se dice que los cambios de contexto son “caros”, y es muy importante las decisiones que toma el scheduler para minimizar los cambios de contexto “inútiles” (¡pobre el scheduler!, las cosas que tiene que tener en cuenta para que lo usuarios no se quejen porque el audio pega saltos).

Un proceso con máquina virtual como Android mete mucha más presión al TLB (y por ende baja el hit ratio) que un proceso que ejecuta código nativo. Para ejecutar una función equivalente en máquina virtual se necesita más memoria, la del código del intérprete, la memoria usado por éste, más el código en lenguaje intermedio y la memoria que necesita el programa. No sólo eso, prácticamente cada ejecución del código intermedio implica cambios en las variables del propio programa, también en las de la máquina virtual, forzando a que en cada cambio de contexto sean más las entradas del TLB que deben ser copiadas a la RAM. O sea, los cambios de contexto son también más caros.

Lo mismo que pasa con el TLB (recordemos que es un tipo específico de cache), pasa con la memoria de cache de RAM en el procesador, la máquina virtual mete más presión, por lo que también bajan sus hit ratios.

De nuevo, una decisión de negocio (y política y filosófica), genera muchas complicaciones técnicas que hay que resolver. Si uno las tiene en cuenta, empieza a dejar de pensar en términos de fanboy y se cuestiona muchas cosas. Entre otras, lo eficiente que tiene que ser Linux para gestionar esta complejidad adicional sin que se note demasiado la diferencia.

El scheduler

Se llama scheduler al módulo del sistema operativo que selecciona cuál será el siguiente proceso a ejecutar. A cada proceso se le le asigna un tiempo máximo de ejecución: el cuanto (o quantum). Si al proceso se le acaba el cuanto, el sistema operativo se apropia de la CPU (por eso se llaman apropiativos o preemptive), y llama al scheduler para seleccionar el siguiente de la lista de procesos que esperan para ejecutar (este mecanismo se denominaround robin). El scheduler de Linux (como la gran mayoría) no son determinísticos, significa que a priori no se puede conocer la secuencia de ejecución de procesos, por lo que no se puede asegurar analítica o formalmente que los procesos se ejecuten en un tiempo máximo predeterminado (si éste es suficientemente pequeño).

No todos los procesos tienen los mismos requerimientos, aquellos interactivos, o de reproducción multimedia necesitan menores tiempo de respuesta que un servicio enbackground, o que consume mucha CPU. Para eso se usan las prioridades, cada proceso tiene una prioridad inicial (por ejemplo “multimedia”, “normal”, “de fondo”, etc.), luego el scheduler la ajusta dinámicamente (prioridad dinámica) dependiendo del comportamiento del proceso y las necesidades de los otros. Por eso, el comportamiento de un sistema que use prioridades depende del comportamiento global de todos los procesos, estos no se pueden predecir, y de allí que sea no determinístico, y que se generen tiempos de respuesta variables.

El scheduler  además tiene que tomar en cuenta muchos factores adicionales (p.e., minimizar los cambios de contexto), y evitar que se produzcan esperas muy largas (starvation) que se pueden producir porque procesos con mayor prioridad están cogiendo siempre la CPU y no dejan ejecutar a otros de menor prioridad. Imaginaros que tenéis el reproducto de música de fondo, y que estáis por sacar una foto. La aplicación de foto podría estar consumiendo el 100% de CPU para actualizar la imagen, por lo que produciría cortes en la música, insoportablemente molesto ¿no? Pues es el pobre scheduler el que tiene que evitar estos problemas, tomando decisiones muy rápidas, cientos de veces por segundo.

Para evitar estas esperas tan largas en los casos extremos (corner cases) como el que acabo de decir, el scheduler mantiene dos colas, la activa y la inactiva. Siempre asigna procesos desde la cola activa. A cada proceso se le asigna un tiempo máximo (además del cuanto) que puede estar en la cola activa (el timeslice, por ejemplo 500 mseg), cuando consume todo su tiempo se le mueve a la cola inactiva. Cuando ya no queda nadie en la cola activa, el scheduler cambia, la activa pasa a ser la inactiva, y viceversa. Esto aumenta aún más el efecto “no determinístico” del scheduler, y puede producir saltos o latencias elevadas si el procesador está temporalmente sobrecargado.

Para evitar estas latencias que molestan a la interactividad del usuario se pueden tomar varias medidas ad hoc, por ejemplo subir la prioridad al máximo a la aplicación que está activa (así hacía Windows), pero esto genera otros problemas: ¿si la aplicación activa abusa y no deja de usar la CPU? (un truco obvio de programador para que su aplicación parezca que es más rápida y eficiente ¿no?) ¿y si hay procesos en background que necesitan la CPU  -por ejemplo un SMS, o responderá la red antes que pase el timeout- y esperan demasiado tiempo?

Pues es muy complicado, y cualquier “truco” que se ponga al scheduler deja la puerta abierta para que los programadores abusen… salvo que hagas un control exhaustivo de cada aplicación que se vaya instalar en el teléfono. ¿Se entiende por qué Apple puede recurrir a trucos ad hoc y evitar al mismo tiempo el abuso de las aplicaciones?

Si por el contrario renuncias a hacer ese control, no queda más remedio que el scheduler haga su trabajo, como en cualquier sistema operativo de uso genérico. Y que la solución adoptada sea lo suficientemente buena, simple, genérica y segura. ¿Se entiende por qué la solución en el Linux de Android es más difícil de encontrar? ¿o por qué le llamé una “solución canónica?

¿Como puede Android mejorar los tiempos de respuesta?

Evidentemente hay dos caminos obvios.

Por un lado, mejorar paulatinamente el scheduler (si es que allí reside el problema). No es una cuestión de un día, ni un año, en Linux se tardó años en encontrar un planificador que funcione tan bien como la actual para sistemas interactivos (el scheduler CFQ).

La otra parte, la gestión de memoria, depende en gran medida del apoyo del hardware. Un procesador con más capacidad de cache y TLB mejoraría mucho, pero también tiene su coste: más transistores, más consumo, más temperatura, mayor tamaño. A medida que se mejore el proceso de fabricación (más transistores en el mismo chip), seguramente incluirán TLB y cache con más capacidad. Lo mismo ocurre con el aumento de la potencia bruta y el aumento de cores (aunque  creo que afectan en mejnor medida a los tiempos de respuesta de la interfaz).

Tampoco me extrañaría que el código de los drivers de la pantalla sea de baja calidad (como suelen ser todos los drives, comparados con el núcleo del sistema operativo, se hacen bajo presión, y la prioridad es el hardware, no el SO) y encuentren big locks que no tocan.

De todas formas, los tiempos irán mejorando paulatinamente hasta que no podamos detectar diferencias en las latencias de la interactividad. Al mismo tiempo, iOS tendrá que ir incluyendo mejores capacidad de “multitarea” (como ya pasó desde que salió la primera versión de iOS, y seguramente irá reduciendo los controles de calidad que hace a cada aplicación).

Supongo que os dáis cuenta de la complejidad técnica de estos “cacharritos”, y que las decisiones de negocio imponen muchas restricciones y problemas al desarrollo del software, lo que obliga a los ingenieros a aplicarse a fondo. No es que los ingenieros de iOS son unos genios, y los de Android unos inútiles, los requerimientos y grados de libertad son diferentes.

Ley informática: optar por la apertura tiene costes técnicos iniciales, optar por el software libre tiene costes técnicos iniciales, pero producir una plataforma totalmente bajo control también tiene costes (sociales), y a más largo plazo.

 

Vía: gallir.wordpress.com

Apps.co mostró nueve de sus mejores prototipos

Seis meses después de que el Ministerio TIC anunció el lanzamiento de Apps.co, los primeros frutos del programa empiezan a aparecer en el mercado. El Ministerio mostró nueve de los mejores prototipos que terminaron la convocatoria de ideación, la segunda etapa del programa que busca que los participantes creen un prototipo funcional y consigan clientes potenciales.

Hay gran variedad en los emprendimientos seleccionados. Desde aplicaciones para encontrar parqueadero hasta herramientas para facilitar la construcción de presupuestos de construcción, pasando por servicios para saber cómo está un sitio antes de salir o herramientas de gestión para empresas agropecuarias. También hay emprendedores de varias regiones del país, como Antioquia, los Santanderes, la Costa y Cali.

Estos fueron los emprendimientos seleccionados:

• Alestra Geo: Es una aplicación que permite administrar procesos logísticos de las empresas en tiempo real. Según Andrés Becerra, uno de los emprendedores, “cuando llegamos a Apps.co solo teníamos una idea muy sencilla de georreferenciación“. Hoy, ofrecen servicios de información sobre clientes, proveedores, transacciones y aliados en tiempo real, y han hecho contactos con 25 empresas de distribución en Santander y alianzas con cuatro compañías, de donde son originarios.
• Parkiando: Una aplicación que sirve para encontrar y reservar parqueadero en Bogotá. Según contó Benjamín Rodríguez, desarrollador del proyecto, la idea nació con una situación que, seguro, muchos usuarios han experimentado: “¿Quién no ha tenido problemas buscando parqueadero? Íbamos a los eventos y no encontrábamos dónde parquear“. Hoy han tenido 347 descargas y 213 usuarios y lograron una alianza con las dos principales cadenas de parqueaderos del país.
• Viga: Esta herramienta les permite a los constructores elaborar los presupuestos de los materiales que necesitan para sus proyectos sin necesidad de acudir directamente con los proveedores. “En Apps.co deberíamos caminar hacia un aliado para encontrar nuestros clientes“, contó Henry Gualdrón, líder del proyecto. Hoy tienen una alianza con la Sociedad Colombiana de Arquitectos.
• Abogapp: Según dijo Paola Rodríguez, del equipo de la app, los abogados usan el 60% de su tiempo obteniendo información de los procesos, lo que hace que se venzan los términos. Así pues, la app “busca reducir el vencimiento de términos de los procesos judiciales en Colombia“. ¿Cómo hacerlo? Permitiendo que los abogados los puedan seguir automáticamente y no tengan que consultar las bases de datos de la Rama Judicial. Cinco profesionales del derecho se comprometieron a comprar la aplicación.
• Campo deportivo: Esta empresa desarrolló apps web y móviles para quienes participan en eventos deportivos y otra para quienes los organizan. La primera les permite recibir información sobre horarios y equipos, y la segunda permite gestionar la información sobre inscripciones, planillas, sanciones y tablas de puntos. “Cuando llegamos a Apps.co teníamos un simple prototipo, pero ahora tenemos una idea de negocio“, dijo Laura Pérez, emprendedora.
• AVA (Administración Vehicular Automatizada): Es una app que envía alertas a sus usuarios sobre las fechas y eventos clave para el mantenimiento de sus vehículos, como la del vencimiento del seguro obligatorio, la revisión técnico-mecánica o el cambio de aceite, entre otros. Consiguió que el servicio de taxis más importante de Santa Marta invirtiera en su desarrollo.
• Kanpo: Es un servicio de gestión de información y calidad para empresas agropecuarias. Busca solucionar un déficit de mediciones de calidad en ese sector, pues los 500.000 agricultores deben certificarse en Buenas Prácticas Agrícolas en 2012 pero no saben cómo hacerlo. En concreto, se trata de una aplicación que ofrece capacitación, monitoreo de actividades y gestión de información para los dueños de la finca.
• Squadrapp:  La idea original, según Ed Baez –miembro del equipo–, era “organizar eventos deportivos y de videojuegos“. Luego, se convirtió en una especie de red social en la que los jugadores pueden ver lo que Baez llama “la identidad deportiva de la persona“: de acuerdo con los reportes de compañeros de equipo, el servicio muestra si una persona –por ejemplo– es hábil, juega limpio o tiene algún talento especial.
• Mirolo: Es un servicio que les permite a los usuarios ver una webcam en tiempo real de un sitio al que quieran ir. A los locales, les provee una plataforma de publicidad y una forma de promocionar su negocio. La idea nació porque su creador, Alejandro Domínguez, necesita usar bastón, y –dice– “me gustaría tener certeza antes del lugar antes de ir“. Hoy, según Domínguez, “estamos en el proceso de adaptación: debemos terminar 30 sitios, terminar con Bogotá, costa Caribe y Valle del Cauca y comenzar una campaña de promoción“.

Si pudiera, “estaría aquí haciendo negocios“: MinTIC

Da la impresión de que Apps.co es uno de los programas favoritos del Ministro TIC, Diego Molano Vega. “Si no fuera Ministro, si no estuviera inhabilitado, estaría aquí haciendo negocios“, dijo en el evento.

Molano explicó por qué el Gobierno decidió apoyar a los emprendimientos privados de los colombianos, algo que en otros países se miraría con desconfianza por parte de los empresarios digitales: “El principal rol del Gobierno es generar demanda. Que ustedes tengan más clientes potenciales“, les dijo a los emprendedores.

El ministro también aconsejó a los empresarios que se fijen primero en el mercado local, en lugar de salir a intentar tener éxito en otros mercados. “La demanda interna es gigante. Tenemos mas de seis millones de conexiones a internet y ahí no hay aplicaciones. En los mercados internacionales hay bastante competencia, aquí la competencia es menor y eso se puede aprovechar“, dijo.

La iniciativa Apps.co acaba de cerrar una nueva convocatoria de ideación y tiene presupuesto asegurado para todo 2013. El año pasado benefició a 15.000 personas con conocimientos de programación e impulsó el desarrollo de más de 170 empresas en diferentes etapas de desarrollo.

Vía : Enter.co

Fallo de iOS 6.1 lo puede dejar sin saldo y sin contactos

Al igual que con iOS 5, el nuevo iOS 6.1 tiene un fallo que permite, con una sencilla operación, hacer llamadas cuando el terminal tiene el bloqueo por código activado.

Aunque la forma de explotar el fallo es diferente, las consecuencias son las mismas: permite realizar llamadas con el teléfono cuando este está bloqueado por código. Esta vulnerabilidad hace que cualquiera, sin conocer la clave del teléfono, pueda llamar a cualquier persona.

El método es muy sencillo. Una vez se rompe la seguridad, se abre la aplicación de las funciones del teléfono. Y ahí, quien irrumpa en el iPhone puede hacer lo que quiera con la aplicación de teléfono, que es la que sirve para hacer llamadas. Es cierto que se acceden a pocas opciones y todas están relacionadas con las llamadas, pero este fallo permite que cualquier ‘chistoso’ –por no llamarlo diferente-–no solo haga llamadas fraudulentas, sino también acceda y modifique el historial de las mismas, y copie o borre contactos de la agenda.

Para resumir, aquel que se sepa estos sencillos pasos puede: vaciar su saldo en minutos, y además husmear o borrar la agenda de contactos. Es un fallo por parte de la manzana que no es nada agradable para aquellos que usan iPhone en sus ultimas versiones (3GS, 4, 4S y 5).

Hasta el momento, Apple no se ha pronunciado al respecto ni ha proporcionado una solución para la vulnerabilidad. Por ahora, el mejor consejo que les podemos dar es que no pierdan de vista su iPhone, si es que quieren que sus secretos no estén a la vista de nadie.

 

Para complementar la noticia, acá se muestra como se explota la vulnerabilidad,

http://www.theverge.com/2013/2/14/3987830/ios-6-1-security-flaw-lets-anyone-make-calls-from-your-iphone

¿Comprar con un simple tweet? Pronto será posible con la alianza entre Twitter y American Express

El e-commerce hace tiempo que dejó de ser una tendencia para confirmarse como una de las grandes opciones de compra en la actualidad, pero ¿ocurrirá lo mismo con el s-commerce o comercio social? Twitter parece creer que sí a la vista del nuevo acuerdo de colaboración que han firmado con American Express.

La idea es que los usuarios con una tarjeta American Express puedan asociarla a su cuenta de Twitter y utilizar su perfil como una nueva forma de pago en la red. Al publicar un determinado tweet a través de su usuario, éste realizará la compra de un determinado producto (de momento se habla de vales descuento, Kindles y joyas). Tan simple como esto.

Por ahora no ha trascendido las cantidades económicas asociadas a este acuerdo, aunque desde Twitter reconocen que en parte han tomado esta decisión para animar a más anunciantes a probar las soluciones publicitarias que ofrece su plataforma. Eso sí, todo comenzará como parte de un programa piloto dentro de Estados Unidos, así que aún queda para que podamos verlo en acción en nuestro país.

Tampoco es el primer acuerdo al que Twitter llega con Amex. Hace ya casi un año, ambas compañías firmaron para que algunos usuarios pudieran asociar sus tarjetas de crédito y reclamar descuentos a través de Twitter para futuras compras. Esta oferta no ha hecho demasiado ruido y no parece que haya tenido demasiado éxito, aunque ninguna de las dos empresas han publicado cifras concretas.

¿Tiene futuro la compra por tweet?

Personalmente tengo mis dudas sobre si una alianza como esta tiene sentido y, más importante, futuro. El F-commerce (comercio a través de Facebook) no ha terminado de despegar y ya han sido muchas las marcas que han cerrado sus tiendas dentro de esta red social. ¿De verdad habría gente dispuesta a comprar con un simple tweet?

En la actualidad ya he visto iniciativas similares, que proponen que el usuario publique un tweet a cambio de acceder a un determinado producto. La diferencia con el caso del que estamos hablando es clara: mientras que hasta ahora en algunos sitios animaban a publicar un estado como única moneda de pago (sin que implicara nada más) lo que proponen Twitter y American Express es que el usuario pague con dinero real a través de Twitter.

¿El gran problema de este sistema? Que Twitter actualmente no tiene aspecto de ser muy robusto. No sólo por la falta de protección adicional como la esperadísima verificación en dos pasos, sino porque suele ser habitual ver cuentas comprometidas o noticias de fallos que afectan a grandes grupos de usuarios. ¿Confiarías ahora mismo tu número de tarjeta de crédito a Twitter? Porque yo la respuesta la tengo muy clara, y por ahora es un “no” rotundo.

Vía | The Wall Street Journal

Bill Gates: «los robots y la computación ubicua cambiarán el modo en que interactuamos con ordenadores»

El fundador y otrora presidente ejecutivo de Microsoft, Bill Gates, ha realizado un AMA en Reddit, y en sus respuestas ha reflexionado sobre aspectos tremendamente interesantes relacionados con las nuevas tecnologías.

¿Cuál será la próxima gran revolución informática?

Bill Gates considera que los próximos grandes hitos de la tecnología irán relacionados con la robóticay, sobre todo, con la computación ubicua y con la interacción persona-ordenador usando lenguaje natural y hablado. La tendencia actual, obviamente, es esa, y ya hemos empezado a vivir esa revolución teniendo un smartphone en el bolsillo de cada uno, y empezando a ver relojes inteligentes que se conecten con ellos.

Recuerdo, de hecho, haber visto un vídeo en una charla de Microsoft hace tres años, en la universidad, donde precisamente se ilustra este futuro que menciona Bill Gates, con conceptos que me encantaría ver algún día en funcionamiento (como el tarjetero) y con conceptos que ya podemos llegar a ver; quizá un poco distintos en la forma, pero idénticos en el fondo.

El producto jamás lanzado que más le gustaba a Gates

El expresidente de Microsoft, al preguntarle por el producto nonato que más le gustaría haber lanzado al mercado, habla de una base de datos que era parte de una versión de Windows que iba a ser lanzada por delante de su momento. Obviamente se trata de WinFS, aquel sistema de archivos orientado a objetos que iba a revolucionar la manera de organizar y visualizar nuestros datos y que en principio debía haber aparecido en Windows Vista, antes del cambio de rumbo de su desarrollo.

Comenta, de hecho, que WinFS acabará volviendo a la vida tarde o temprano. Sinceramente opino que no tardaremos en verlo; considero necesario cambiar el paradigma de archivos organizados en directorios por prácticamente obsoleto. ¿Por qué tener un montón de archivos en lugar de disponer de un sistema que entienda nuestra información (ya procesada) y podamos consultarla según distintos criterios? No quiero un montón de archivos con los bytes de mis documentos, sino su información, mostrada convenientemente según quiera.

“Bing es el mejor producto hoy en día”

No faltaban preguntas acerca de su buscador. Recientemente destronado por Yandex, buscador localizado en un único (aunque enorme mercado), hay quien ha preguntado si en Microsoft de veras usan Bing. Y la respuesta es contundente: “Bing es el mejor producto hoy en día. Intenta el desafío. El trabajo que se ha hecho para mejorar Bing es impresionante”.

Y no dudo que en Estados Unidos sea un producto excelente. Pero tiene un problema grave fuera de ese país: si lo utilizas desde fuera de allí, parece una beta perpetua, con muchas funciones que no están disponibles en otros lugares. Sinceramente espero que en Microsoft se den cuenta de ello y empiecen a expandir Bing como se merece.

Por supuesto, no se ha limitado a contestar sobre estos dos aspectos, sino que ha contestado bastantes más preguntas propuestas por la comunidad de Reddit, también relacionadas con su labor filantrópica y su fundación. Os recomiendo leer el hilo completo; confieso que me ha parecido bastante interesante. Y es de agradecer que personalidades de la relevancia de Bill Gates accedan a ser preguntados por la gente que, en muchas ocasiones, le ha admirado o como poco le ha mirado con interés. Y también que tengan sentido del humor.

Sitio oficial | Gates Foundation

Dropbox mejora su consola de administración

En el espacio de almacenamiento en la nube hay dos compañías que están liderando actualmente el mercado. Dropbox es la solución más popular para los consumidores, mientras que Box es una de las soluciones preferidas por los administradores de TI de las empresas. La diferencia entre Dropbox y Box son las herramientas que tiene el segundo para poder administrar varios usuarios y tener más control sobre la solución. Al no tener acceso directo a los datos, el departamento de TI necesita tener las herramientas necesarias para poder garantizar la seguridad de la información.

Dropbox no quiere quedarse sin un pedazo de ese jugoso ponqué y acabó de anunciar que implementó un panel de control para gerenciar las cuentas empresariales del servicio. Anteriormente, Dropbox tenía Dropbox for Teams, pero este se quedaba corto en funciones. Por eso, el equipo de ingeniería, liderado por Thomas ‘Tino’ Carreiro, actualizó el producto e implementó varias herramientas para verificar lo que estaban haciendo los usuarios en Dropbox y tener más control sobre lo que se puede compartir y lo que no, según CITEWorld.

Especificamente, ahora será posible ver detalladamente la actividad de los usuarios: la dirección IP, el dispositivo desde donde ingresan, y las aplicaciones que están ligadas al servicio. Por medio de la consola también es posible revisar y restringir las carpetas y los archivos que actualmente están compartiendo los usuarios. Esto permite tener una visión global del servicio y ver los movimientos y la actividad de los usuarios. En adición, es posible ‘obligar’ a todos los usuarios activar la verificación de dos pasos y restringir los usuarios que no lo hagan. 

De esta forma se puede mantener un grado de seguridad y control que anteriormente no existía. Esto era una de las quejas de los administradores de TI en contra del servicio. Simplemente no tenían una forma de verificar la actividad de los usuarios.

 

Vía: Enter.co

Llega Mailbox a la App Store, un nuevo cliente de correo que pretende revolucionar nuestra bandeja de entrada

Hace escasas horas se ha anunciado el lanzamiento oficial de Mailbox en la App Store, un cliente de correo que analizamos hace pocas semanas y que propone e introduce una forma diferente y más productiva de controlar nuestros correos, como si de una lista de tareas se tratase. Después de meses de espera, Mailbox ya está disponible para iPhone e iPod Touch aunque, por el momento, no podremos hacer uso de la aplicación.

¿Y por qué digo esto? Por lo siguiente. Mailbox está obteniendo una acogida espectacular y, para evitar colapsos y controlar la gran masa de usuarios, han decidido activar la aplicación de manera progresiva a través de invitaciones. Una vez iniciada la aplicación por primera vez nos mostrará el número asignado para la cola de invitaciones. Así es, podremos descargar la app desde la App Store pero no podremos probarla hasta pasada varias semanas.

Mailbox está destinado principalmente para aquellos usuarios que controlan, responden y gestionan decenas de correos al día. Permite marca los correos como completado, pendiente de resolver (deslizar levemente hacia la izquierda), eliminarlo (deslizar más rápido hacia la derecha) o archivarlo (deslizar suavemente hacia la derecha) con solo un simple gesto. La gestión de nuestra bandeja se reduce a unos pocos movimientos de dedo.

Ojo, por el momento Mailbox solo es compatible con cuentas de correo de Gmail y no está adapatado para iPad. Desde hoy puedes descargar gratuitamente la aplicación desde la App Store para dispositivos iPhone e iPod Touch de la manzana, pero ten en cuenta que no podrás usarla hasta dentro de semanas o hasta que se normalice el servicio.

 

Sitio oficial | Mailbox
Descarga | Mailbox (App Store)

Ubuntu se convertirá en el quinto competidor del mercado móvil a partir de octubre

Al final hasta se adelantarán y todo: Canonical va a poner su Ubuntu para móviles a disposición de los desarrolladores a finales de este mismo mes con intenciones de lanzarlo en “dos mercados geográficamente grandes” durante octubre. Los primeros pasos, con la compañía buscando apoyo de la comunidad de programadores, ya está dado.

No podían haber elegido un mejor año para adentrarse en el mercado de los móviles y las tabletas: el mercado sigue dominado por Google y Apple, pero tenemos a Windows Phone 8 y a BlackBerry 10 dispuestos a diversificar un poco más esta competencia. Ubuntu se convertiría en el quinto frente, y sería el segundo sistema operativo de código abierto que intenta colocarse como un rival serio después de Android.

Ubuntu es una de las distribuciones Linux más populares, y su entrada en los móviles podría calar. Pero una cosa es ofrecer la instalación de Linux en los ordenadores, donde un usuario puede decidir instalarlo en cualquier momento; y otra muy diferente es ofrecerla en el mercado móvil mayoritariamente controlado por las operadoras.

La esperanza recae en los móviles con Android capaces de modificar su arranque. El mercado móviles que ejecutan este sistema es el más grande ahora mismo, con lo que Canonical tiene oportunidades. Faltará, como siempre, que los usuarios se animen a probar algo nuevo. Mark Shuttleworth lo tiene claro, declarando que Ubuntu estará presente como un sistema único en todas las plataformas.

Vía | Wall Street Journal

Apps.co, a punto de cerrar convocatoria para recibir idea innovadoras

Apps.co sigue madurando.

Apps.co va por buen camino. Según Claudia Obando, líder del proyecto en el Ministerio TIC, se recibieron aproximadamente cerca de 15.000 inscripciones a ellos. De los registrados, 4.000 están aprendiendo en Codecademy, y cerca de 6.000 personas desarrollando y aprendiendo tecnologías Microsoft. De los últimos, 1.500 van a tener la oportunidad de postularse para certificarse en tecnología.

 

La segunda etapa de la convocatoria de Apps.co ya se está llevando a cabo. En esta las personas que tengan buenas ideas de proyectos o aplicaciones, pueden registrarse para participar en el proyecto que lidera el Ministerio TIC. Quienes se inscriban recibirán entrenamiento enfocado en enseñar a hacer crecer esas ideas, y convertirlas en proyectos que tengan demanda en el mercado. La convocatoria se vence mañana viernes.

Los requisitos para entrar en esta convocatoria no son tan altos, solo tener una idea y un plan para convertirla en un producto, como ya nos había dicho Obando. La idea es que la aplicación o proyecto en el que estén trabajando llegue a tener buena demanda (si es una aplicación gratuita) o a tener un buen comprador asegurado.

“Estamos esperando recibir 500 propuestas”, aseguró Obando, “y tenemos 280 cupos en todo el país”. Cuando terminen el ciclo, todos los beneficiarios “se pueden postular a la siguiente etapa para recibir todo el apoyo de consolidación”. Además, “a los 20 mejores que salgan de ideación les vamos a hacer un reportaje desde el Ministerio, para moverlo en todos nuestros canales y en televisión y darlos a conocer.” 

El proceso de entrenamiento durará 8 semanas. Luego de este empezaría la tercera etapa de Apps.co. Este ya es dirigido a startups que ya tengan una validación en el mercado y quieran consolidar y escalar  su negocio.