
Recently in Internet Category

Interesante video con el que me encontré a través del blog de J.C. Camus, sobre el estado de Internet:
Nota: recuerden que los norteamericanos, a diferencia del resto del mundo civilizado, tienen la mala costumbre de llamar billón a los mil millones, y trillón al billón, sí, es un lio, pero si el video fuera en notación científica no creo que se simplifique más la cosa, en fin. Igual son cifras muy impresionantes, y nadie es capaz de imaginaras adecuadamente, así que impresiónense:
El manejo de la identidad en la red es un tema que he abordado en este espacio, pero que me parece necesario y urgente retomar, dada ciertas coyunturas que se están dando. Es por esto que voy a iniciar una serie de artículos sobre el problema del manejo de la identidad, y parto con este artículo reciclado de julio de 2007.
"Internet fue construida sin una manera de saber quien se conecta y a que se conecta."
Dado que la capacidad de identificar a las personas no está construida en la internet todo aquel que ofrece un servicio en internet tiene que resolver el problema del manejo de la identidad e alguna manera. A medida que la web crece la necesidad de identificar se hace más necesaria, y siempre nos topamos con distintos tipos de verificación de identidad, cada uno creado y adaptado a distintas necesidades. Millones de personas han aprendido a aceptar que cualquier cosa que un sitio web les pida es la "forma normal" de conducir los negocios en línea. Han sido entrenados para ingresar sus nombres, claves secretas e información de identificación personal en cuanto formulario de entrada que se les presenta en pantalla.

Como resultado el estado actual de la identidad digital en internet es un conjunto de soluciones adhoc que lleva a que las personas tengan diversas experiencias de usuario en cada sitios web. Todo esto hace que el sistema como una totalidad se vuelva frágil y no permite la realización de la promesa del comercio electrónico (vease las leyes de identidad)
Un meta-sistema de identidad
Dado que la adopción universal de un único sistema de identidad digital o tecnología es improbable, para tener una solución de uso amplio en la internet requerimos una aproximación distinta. Una que permita conectar los sistemas existente y futuros de identidad en lo que denominaremos un meta sistema de identidad. Este meta sistema, o sistema de sistemas permite fortalecer a los sistemas de identidad que lo constituyen. Permite la interoperabilidad entre estos, y habilita la creación de una interfaz de usuario consistente para todos. (ver: La Visión de Microsoft para un Meta Sistema de Identidad).
La adopción de estos meta sistemas pueden hacer de internet un lugar más seguro e impulsar el comercio electrónico, combatir el phishing y resolver otros problemas asociados al manejo de la identidad.
En el mundo off line, la gente lleva consigo distintas formas de identificación en sus billeteras, como por ejemplo, su cédula de identida, licencia de conducir, tarjetas de crédito, tarjetas de fidelización o asociación a un club, tarjetas de viajero frecuente. La gente controla cual tarjeta usar y cuanta información revelera en cada situación.

Del mismo modo el metasistema de identidad permite facilitar a los usuarios asegurarse y controlar el aceso a sus recursos en la internet. Permite que los usuarios seleccionen entre distintos portafolios sus identidades digitales y las usan en los servicios de internet de su preferencia donde son aceptados.
El metasistema permite que las identidades provistas por una tecnología o sistema de identidad sea usada en ambientes con tecnologías diferentes, siempre que exista un intermediario que entienda ambas tecnologías y en el cual se confíe para que haga las traducciones necesarias.
Las identidades dependen del contexto
Las identidades de una persona en el mundo offline varían de las signicativas, como un certficado de nacimiento, pasaporte, o la licencia de conducir, a las más triviales, como las tarjetas de negocios o las de un club de lectores. Las persoans usan sus distintas formas de identificación en contextos diferentes donde son aceptadas. Las identidades pueden estar fuera de contexto, pero no generan el resultado esperado. Por ejemplo, tratar de usar la tarjeta del club de lectores para cruzar una frontera claramente está fuera de contexto. Por otro lado, usar una tarjeta bancaria en un cajero autmático, o un Pasaporte .Net en una cuenta hotmail es algo que claramente está en su contexto adecuado.
Muchas veces sin embargo la distición no es tan clara. Por ejemplo, en Chile el RUT, un número entregado por el gobierno, es usado como identificador para ser consultado en los sitios web bancarios.
Esto trae una serie de problemas, sobre todo porque abre las puertas para cometer varios delitos.
En este sentido el uso del RUT en nuestros sitios web bancarios es mala.
Por otro lado, aunque el Passport de Microsoft puede ser usado en cualquier sitio, e incluso es simple de usar si uno usa la plataforma .Net, su uso en otros sitios normalmente está deshabilitado, porque se considera que está fuera de contexto.
De hecho, los investigadores de Microsoft, estudiando la experiencia de Passport y otros sistemas similares que irrumpieron en los primero años de la web, en conjunto con otros expertos de la industria establecieron una serie de principios que deben guiar a todos los sistemas de manejo de la identidad. Estos principios fueron compilados en las llamadas Leyes de la Identidad, expuestas por Kim Cameron.
Las leyes de la identidad
Las leyes de la identidad son los fundamentos para los meta sistemas de identidad.
Las 7 leyes de la identidad son:
1. Control y consentimiento del usuario. Los sistemas de identidad sólo deben revelar la información identificando a un usuario con el consentimiento del usuario.
2. Acceso Mínimo para un Uso Limitado. Un sistema de identidad debe revelar la mínima información posible.
3. Justificación de las Partes. Los sistemas de identidad deben ser diseñados de modo que la información revelada esté limitada a las partes que tenga un lugar necesario y justificado en una relación de identidad.
4. Identidad Dirigida. Un sistema de de identidad universal debe soportar ambos, identificadores omnidireccionales para uso de las entidades públicas e identificadores unidireccionales para uso de las entidades privadas, facilitando el descubrimiento junto con prevenir las correlaciones innecesarias entre los identificadores.
5. Pluralidad de Operadores y Tecnologías. Una identidad universal debe utilizar y habilitar la interoperación de distintas tecnologías de identidad provistas por multiples proveedores de identidad.
6. Integración Humana. Los sistemas de identidad deben definir al usuario humano como una componente del sistema distribuido, integradod a trave´s de un mecanismo de comunicación humano máquina que no sea ambiguo y que ofrezca mecanismos de protección en contra de ataques en contra de la identidad.
7. Experiencia Consistente entre Contextos. El metasistema que unifica la identidad garantiza a sus usuarios una experiencia simple, consistente mientras permite la separación de los contextos entre distintos operadores y tecnologías.
¿Que significa todo esto?
Cuando la identidad se lleva al mundo digital esta parece estar más en peligro que en el mundo real. La gente desconfía de los servicios que piden información de identidad. Muchos negocios no se realizan porque existe el temor de perder el acceso a las cuentas bancarias, o tarjetas de crédito.
El aumento del phishing y otros mecanismos de fraude hacen que muchas personas desconfíen de los sistemas de identificación en la red.
En realidad muchos de los problemas se resuelven considerando que la identidad en linea no es distinta de la identidad en el mundo fuera de linea. Es cosa de darnos cuenta de que los mismos mecanismos que operan en el mundo offline son los que deben ser posibilitados en la internet.
Al igual que en el mundo real, uno sólo entrega su licencia de conducir a la autoridad y en una forma controlada y consentida. En el mundo digital uno debe entregar su identidad digital con las credenciales adecuadas en el contexto apropiado, pero de una manera controlada y consentida.
Por eso es que cuando entregamos nuestros datos a una institución no queremos que estos datos sean entregados sin nuestro consentimiento, y tampoco queremos que sean usados en formas no autorizadas.
Estos principios han sido expuestos claramente por investigadores de punta, y existen muchos trabajos en este sentido para asegurar que las leyes de la identidad sean entendidas no sólo por los usuarios, sino por los implementadores de sistemas que manejan información sensible.
Para los que desarrollamos sistemas que deben manejar datos personales, el trabajo de Kim Cameron y su equipo en Microsoft son una excelente guía para no perdernos en como proteger la identidad de nuestros usuarios y clientes.
Curiosamente hace poco en una lista en que participo pedí que usaran TinyUrl, olvidando lo que escribí hace un tiempo sobre lo problemas de este servicio, un tema que ha resurgido en estos días, y que se puede constituir en un problema de seguridad serio. Aca vá, reciclado, y con alguna mejoras, mi post del 27 de diciembre de 2007:
El problema de tinyurl y otros servicios similares
Este post estaba en borrador, y ahora lo completé como respuesta a una pregunta de FT via twitter,
Si algún día TinyURL o Dev.cl dejan de prestar servicio... ¿mueren todas las URLs cortas creadas?
La respuesta corta es Sí.
Incidentalmente, cuando traté de acortar la url de este post dev.cl me devolvio la url http://dev.cl/.
Ahora la respuesta entretenida:
Aunque las urls cortas tienen varias aplicaciones y ventajas, incluso sirven para comprimir imágenes ;) la verdad es que hay varios problemas:
Jeff Atwood resume varios de estos problemas:
- Si el servicio desaparece, las urls quedan rotas para siempre. Tal como teme FT.
- El otro problema es la calidad del servicio, efectivamente un servicio de este tipo que funcione esporádicamente (con "apagones") puede ser una situación aún peor.
- Se pierde la cualquier pista sobre el contenido de la url, al ser todas esta homogéneas, y estar resumidas en un codigo críptico. Esto es malo para la experiencia usuario del que está haciendo click en el enlace (y para la seguridad), porque la url no te da pista de adonde llegarás.
- Hay servicios de redireccionamiento de urls que han sido usados en formas cuestionables, por ejemplo spammers (fue el caso de lnk.to).
Otros problemas que Atwood no identifica son:
- La redirección introduce latencia.
- Una url reducida puede ser usada para hacer phishing.
- Se convierte en una capa por sobre el DNS.
- Es una brecha de seguridad, puede ser usada para inyectar un XSS, por ejemplo.
- No es bueno usar esto para cosas como ajax, o web services.
- Si tu firewall o proxy reverso bloquea el servicio lo hace inutilizable
- El servicio puede estar lleno de basura, como urls que ya no estan vigentes, al perder la pista no te enteras hasta que haces el click.
- Si una url falla no sabes si es el servicio de compresion el que falló o si la url original la que tiene problemas.
- Tinyurl no maneja bien algunas "urls extrañas" con caracteres como la coma (',').
A pesar de esto, las urls cortas son útiles en diversos contextos, como lo demuestra su uso en twitter, o para enviarlas en emails, o en mensajes SMS.
¿Por qué Google no provee este servicio?
Esa es una buena pregunta, y como dice Atwood, probablemente esto le daría mayor seguridad al servicio.
A lo mejor han analizado el problema y no ven el negocio para este servicio, o no quieren complicarse con el problema de los spammers.
Aunque sospecho que no quieren ponerse en una situación tan incomodamente hegemónica.
Una alternativa sería descentralizar el servicio, una especie de P2P de urls cortas, una idea que no he explorado, pero puede ser interesante.
(Lo que sí he explorado es la idea de eliminar el DNS, pero eso quedará para otro post.)
Quizás un análisis interesante sería ver que pasa con estos servicios y el principio de que las urls cools no cambian (expuesto por Tim Berners Lee).
En primera instancia uno pensaría que al agregar un nivel de indirección esto servicios pueden ayudar a preservar este principio, pero si observamos con mayor detención, en realidad complican más el problema.
Efectivamente, si la url inicial cambia, además hay que propagar ese cambio a todas las urls cortas de todos los servicios de este tipo.
Ahora bien, el problema de la persistencia de las URLs es más complejo aún, y la caida de servicios tipo tinyurl es sólo una clase de los problemas asociados a la persistencia de las URLs.
¿Cómo implementar un servicio como este?
Ahora, para finalizar, déjenme criticar la propuesta de Atwood de usar hash como mecanismo para generar URLs cortas.
Aunque a primera vista parece bueno (algoritmo O(1)), no parece la forma más práctica para implementar este servicio. Los hashes que muestra generan strings mucho más largos que los que observamos en estos servicios.
Mejor optar por un algoritmo O(N log (N)) como el siguiente:
- Existe una tabla URL, indexado por ID y URL_LARGA
- Se recibe una url y se busca por URL_LARGA obteniendo ID o NULL.
- Si se obtiene NULL se inserta un nuevo elemento en la tabla y la URL corta sera la raiz del sitio mas el ID expresado en base 64.
Que nos permite generar urls bastante cortas, y es facil de implementar.
No creo que sea fácil encontrar una función hash que genere strings más cortos que los que genera este algoritmo.
Como Tip adicional, en vez de realizar la redirección usando PHP, o Python, yo optaría por escribir un modulo apache en C, o en PERL, esto aceleraría en al menos un orden de magnitud el servicio (si es que no más). O quizás creando mi propio servidor web. Y por último, trataría de mantener la tabla en memoria, o al menos un caché de las URLs más visitadas.
Visiten el sitio web de Skittles www.skittles.com, esta famosa marca de dulces ha retirado su propio contenido de su sitio web y coloca el contenido generado por sus consumidores en internet, generado en Youtube, Facebook, Twitter, Flickr y Wikipedia.
Si van a la descripción de productos verán que se muestra el contenido de Wikipedia! (es una copia, no una redirección).
En palabras de David Berkowitz
Este es el mensaje que Skittles está enviando: Lo que dicen los consumidores sobre la marca es más importante que lo que la marca le tenga que decir a los consumidores.

Yo lo encuentro sorprendente, no sé que opinan ustedes
"crowd marketing"?
Hay un detalle interesante, el sitio web de Skittles tiene un promedio de 15.000 visitas al mes, pero su página en Facebook tiene sobre 600.000 fans.
"No sé lo que quiero, ¡pero lo quiero ya!"
-- Luca Prodan, fallecido vocalista y lider de Sumo
"Los problemas de Ancho de banda se curan con dinero. Los problemas de Latencia son más difíciles, porque la velocidad de la luz es fija. (No le puedes robar a Dios)"
-- Anónimo [1]
Cuando medimos el desempeño de una aplicación Web, el aspecto técnico que más afecta a la percepción de usuario es la Latencia.
Aplicando lo dicho por el gran Luca Prodan, el usuario no sabe lo que quiere, pero quiere que se le entregue con prontitud.
Para entender los conceptos de evaluación de desempeño vamo a definir las siguientes variables, en términos sencillos:
- Ancho de Banda: Cantidad de datos que pueden ser enviados por la red en un segundo.
- Rendimiento (Throughput): Cantidad de trabajo que puede realizar el servidor en un periodo de tiempo.
- Contención: Competencia por los recursos, se da cuando tenemos más de 1 cliente accediendo al servidor.
- Latencia: tiempo para realizar una operación simple asumiendo que no hay contención [1]. Tiempo de respuesta efectivo medido por parte del cliente.
La latencia es función del ancho de banda, y el throughput, sin considerar la contención:
Latencia = F (Ancho Banda, Througput)
El ancho de banda se mide en bits por segundo (bps).
Normalmente se considera un 80% de uso del canal.
Ejemplo 1: Si tenemos un ancho de banda de 256 (Kbps), es decir, 32 KiloBytes por segundo (KB/s), entonces el límite teórico considerando el 80% de eficiencia, es de 25.6 KB/s (32*0,8). Por lo tanto, una página de 40 KB, será descargada en 1,56 segundos.
Si el rendimiento del servidor es de 100 páginas por segundo (p/s), entonces, en generar una página se demorará 1/100 segundos. Luego la Latencia para la página de 40 Kbps es de 1,56 + 0,01, o sea, 1,57 segundos por página.
Una función práctica para medir la latencia está dada por la siguiente ecuación:
L = (1/T)+{P/W)
Donde:
- T : Throughput (rendimiento) expresado en Paginas por Segundo
- P: Tamaño de la página en Kilobytes/Pagina
- W: Ancho banda efectivo en Kilobytes por segundo (se puede calcular rápidamente dividiendo el ancho de banda en Kbps por 10).
Ejemplo 2: La contención tiene un efecto sobre el throughput: supongamos que tenemos 1.000 usuarios, queriendo acceder a una página al mismo tiempo, ésta debe realizar una consulta a la base de datos y entregar un resultado, que corresponde a 40 kilobytes de datos (incluyendo el código html). Asumamos que tenemos un pool de 10 conexiones a la base de datos, y que la consulta toma unos 250ms en ejecutarse. De acuerdo a la Teoría de Colas, el tiempo promedio de espera para usar la conexión es de 12,375 ms, luego, el tiempo promedio para generar la página es de 12,625 ms, o sea, el throughput en este caso es de 0,08 p/s (1000/12,625). Si el ancho de banda es 256 Kbps, tendremos que la latencia teórica es de: L = 1/0.08 [seg/pag] + 40/25.6 [kb/pag]/[kb/seg] = 14.06 [seg/pag]
Li = P / W
Los problemas de latencia son los más difíciles de abordar, el artículo de David A. Patterson de la CACM [1], sugiere 3 técnicas típicas para afrontar los problemas de latencia:
1. Caching: Originalmente nació porque el acceso al almacenamiento secundario siempre es más lento, en este caso, tenemos ejemplos donde aplica el caching, guardar los objetos precalculados, guardar tablas con parámetros, etc.
2. Replicación: Esto es más costoso, pero uno podría tener réplicas de los sitios en varios servidores (Server farm) balanceando la carga entre ellos.
3. Predicción: Tratar de adivinar que se va a necesitar, por ejemplo, si la tabla de ciudades se va a usar siempre, en vez de leerla 1 vez, puedo tener un objeto de aplicación que lea la tabla de ciudades y se mantiene una copia compartida por todas las sesiones.
Hay más técnicas, como aplicar patrones de diseño, introducir una capa de negocios intermedia, etc.
Todas estas decisiones deben tomarse con cuidado y con la asesoría adecuada.
[1] Latency Lags BandWidth, David A. Patterson, Comunications of the ACM Magazine (CACM), Oct, 2004
Por Peter Deusch
Esencialmente todos, cuando construyen su primera aplicación distribuida, hacen estas ocho suposiciones. En el largo plazo todas resultan ser falsas y todas causan grandes problemas y penosas experiencias de apredizaje.
1. La red es confiable
2. La latencia es cero
3. El ancho de banda es infinito
4. La red es segura
5. La topología no cambia
6. Hay un administrador
7. El costo de transporte es cero
8. La red es homogenea
El World Privacy Forum, cuyo reporte les presenté anteriormente, publica una serie de consejos sobre cómo usar los servicios en la nube, tanto para los consumidores, como para el gobierno y los negocios.
Consejos para los consumidores de servicios en la nube
- Lea los Términos de Servicio antes de colocar cualquier información en la nube. Si no entiende Los Términos de Servicio, considere usar un proveedor de servicios diferente.
- No ponga nada en la nube que no quiera que sea visto por el gobierno o algún litigante privado.
- Ponga atención si el proveedor de la nube se reserva los derechos a usar, difundir, o hacer pública su información.
- Lea la política de privacidad antes de colocar su información en la nube. Si no entiende la política, considere usar un proveedor diferente.
- Cuando usted remueve sus datos del proveedor de nube, ¿éste sigue reteniendo derechos sobre su información? Si es así, considere si esto es importante para usted.
- ¿El proveedor de servicios le da avisos anticipados sobre cualquier cambio de los términos de servicio o la política de privacidad?
También hay consejos para las empresas y el gobierno sobre los servicios en la nube, pero no los vamos a traducir acá, que trabajen los burócratas ;)
Les dejo este reciente reporte (23 de febrero), sobre los riesgos a la privacidad y confidencialidad debido al cloud computing.
El reporte, publicado por el World Privacy Forum, identifica una serie de asuntos a considerar en el contexto de los servicios en la nube.
Como por ejemplo, que en ciertos casos podría ser ilegal entregar datos a un proveedor de servicios en la nube (en Estados Unidos), o puede pasar que al colocar cierta información en la nube se reducen las barreras legales que tendrían las autoridades para acceder a información personal confidencial.
Interesante, porque el WPF está preocupados en la manera en que la nube podría poner en peligro la privacida, y podría romper la simetría de la confidencialidad de información, en favor del Estado, perjudicando al ciudadano.
Mientras hojeaba este informe, no pude dejar de pensar en los servicios en la nube que provee el Estado de Chile. Por ejemplo, el Servicio de Impuestos Internos, provee servicios en la nube desde hace bastante tiempo (que cómodo es emitir tu boleta de servicios usando el sistema provisto por ellos).
Bueno, hace rato que hemos dejado que nuestro estado, y otras instituciones públicas, o semi pública, manejen mucha información sobre nosotros, lo malo es que muchas veces esta información no está asegurada.
Sería interesante hacer un contraste de lo expuesto por el WPF y la realidad chilena, en el contexto de los servicios en nubes que está implementando el gobierno chileno.
En su estudio sobre la economía de la nube los investigadores de Berkeley no olvidan de mencionar a Richard Stallman, quien considera la computación en la nube como una trampa para el usuario:
It's stupidity. It's worse than stupidity: it's a marketing hype campaign. Somebody is saying this is inevitable -- and whenever you hear somebody saying that, it's very likely to be a set of businesses campaigning to make it true.
Es estupidez. Es pero que la estupidez: una inflada campaña de marketing. Alguién está diciedo que esto es inevitable -- y cuando escuchas a alguien decir estto, es muy probable que se esté montando una campaña de negocios para que se vuelva una realidad. [1]
¿Acaso los incidentes del último tiempo, como el cambio en los términos de servicio de Facebook, y la reciente falla de GMail, no indican que Richard Stallman tiene razón, y que todo esto del cloud computing es una estupidez?
Stupid is as stupid does .... [2]
La queja sobre lo de Facebook es entendible, pero lo que muchos no se dan cuenta, es que los actuales términos de uso de Facebook también son malos.
Los usuarios no leen los términos de uso de los servicios. Muchos aceptan esto porque, al fin y al cabo, no están pagando por ellos, es gratis. Eso es una trampa, porque sí estás pagando por estos servicios, estás pagando con tu perfilamiento, con tus acciones, al permitirles analizarlas. No hay nada gratis en este mundo.
En el caso del GMail, no existe todavía un sistema inmune a las fallas.Esta no es la primera vez que falla Google, esto ha pasado antes, y volverá a pasar. No hay que alarmarse por esto.
Debería haber un nivel de servicio, lo que pasa es que no lo tenemos claro (yo no lo he encontrado en los términos de servicio de Google).
Es bueno que estas cosas pasen, para que nos demos cuenta de hasta que punto estamos dependiendo de los servicios en la nube, pero no debemos caer en el alarmismo fácil, o darle la razón al pesado de Stallinman.
Es una estupidez, si tu haces cosas estúpidas. Infórmate sobre que te permite hacer el servicio en la nube, averigua que hacen con la información que dejas en sus servidores. ¿Cuales son los mecanismos para abandonar el servicio? ¿cómo recuperas tu información?
En resumen, ¿cuál es el SLA ? ¿Hay algún mecanismo de respaldo, o de mantener la información off line, cuando el servicio esté abajo?
Si tu negocio depende de estos servicios gratuitos en la nube, y no tienes claro esto, estás en serios problemas.
Yo no sé si el cloud computing es inevitable, si es seguro de que es evitable, pero tiene un costo. Hay un modelo propuesto por Berkeley, para calcular el momento en que le conviene a la empresa usar cloud computing, vale la pena revisarlo.
En cuanto a las personas... Ahí yo creo que Macleod algo de razón tiene, hay un efecto de red, que está empujando a que las personas usen más y más servicios en la nube, y ahí si que se convierte en algo casi inevitable, es lo que está pasando con Facebook. A la gente no le importa si Facebook es usado por la CIA, porque están valorando otras cosas, que superan toda paranoia.
O se trata de un efecto manada, o es un efecto red, como sea, la gente está usando más la nube, y se está volviendo casi inevitable. Al final, o las mismas personas logran que esto se regule para su beneficio, o la sociedad intervendrá. Así, que tampoco me preocuparía tanto.
Yo sé que hay periodistas, mandados por sus editores, que ahora están buscando sangre, o la clásica nota de que "la tecnología nos va a llevar al desastre", o "internet es mala, no la usen". No sé, ¿or qué hacen eso? Es una lástima, espero que no sobre simplifiquen el tema, esto que está pasando es normal, sólo son los sintomas de un cambio.
Si es para mejor, no lo sé, yo no creo en el progreso, lo que sí me queda claro es que debemos evolucionar, y evolucionar es adaptarse al cambio, y esto es lo que está pasando, hay un cambio, inevitable en ciertos aspectos, pero no por culpa de alguna sucia conspiración de vendedores de datacenters, es por otras razones, bastante entendibles, si se las analiza bien.
[1] Richard Stallman
[2] Forrest Gump
