Los dos grandes problemas al centro de la discusión sobre las gráficas sociales son la privacidad y la propiedad de la información.

Lo que esperamos es pasar la menor cantidad de tiempo registrándonos, configurando nuestros perfiles y diciéndole al sistema lo que queremos. Podemos hacer uso de la gráfica para conectarnos y comunicarnos más efectivamente, pero más importantemente no buscamos sentirnos en control, sino de verdad ESTAR en control de nuestra información personal: elegir no sólo con quién queremos ser amigos, sino decidir cómo va a ser usada nuestra información sobre ellos.

Cuando las redes sociales son apenas startups, parece que lo comprenden muy bien y el incrementar su cantidad de usuarios es el mayor incentivo para compartir información con nosotros, pero a medida que crecen dejan de actuar así. Es por eso que aquí entra en juego la utilización de una API, que tanto continúa beneficiando a la empresa como a los usuarios finales.

La API de la gráfica social

En su artículo, Brad Fitzpatrick explícitamente describía que era necesario una API o un servicio que serviría de “corredor” para la información entre las distintas redes sociales. Él visualiza una base de datos de código abierto que aceptará información de múltiples redes sociales y que la pone a disposición de los usuarios finales a través de una API o una interfaz de usuario. El usuario estaría en capacidad de autorizar a otras redes sociales a hallar esa información.

El primer reto técnico es construir un sistema que pueda crecer según la escala de usuarios crezca de la misma manera. Lo segundo es construir un sistema que sea seguro y una vez cumplamos con estos dos retos, hacer que las compañías utilicen esta API.

El problema tiene que ser abordado no desde el punto de vista de obligar a compañías como Facebook a importar su información a esta nueva base de datos, porque no lo van a hacer, sino que implementen facilidades para que los usuarios puedan exportar su información de forma personal: esto tampoco es la panacea, porque los usuarios estarían restringidos a un proceso manual en el que pueden ocurrir errores.

Un acercamiento más automatizado sería definir una API que todas las redes sociales puedan implementar para que todas las demás redes puedan consultar un subconjunto de la gráfica social. En términos prácticos, esto podría decirse así: “Cuando el usuario se une a una nueva red, esa red puede conectarse a las otras en las que la persona ya está registrada y obtener información sobre sus usuarios en todas ellas”. ¿Muy parecido a la función de importar a tus amigos desde el email? El reto es hacer labor de convencimiento con las redes sociales para que ofrezcan soporte a este tipo de funcionalidad.

Un punto de vista adicional: Tim Berners-Lee

El inventor de la WWW, Berners-Lee, escribió un artículo en donde tomaba por referencia lo que dijo Brad Fitzpatrick y distinguió la “gráfica” como el tercer “nivel” de la computación en red.

Él distingue esos niveles de la siguiente manera:

• La internet: establece nexos entre computadoras.
• La web: establece nexos entre documentos.
• La gráfica: establece nexos entre personas y/o documentos. – “No son los documentos los que important, sino las cosas [y personas] sobre las que son esos documentos”

La gráfica, para Berners-Lee se trata únicamente de conexiones y la reutilización de información. También nota que a medida que subimos de nivel perdemos cada vez más control, pero ganamos cada vez más beneficios. Uno de esos beneficios sería la reutilización de nuestra información personal y sobre nuestros contactos a lo largo y ancho de múltiples redes.

“Dejar tu información conectarse a la de las otras personas se trata un poco de “dejar ir” en ese sentido. Aún no se trata de darles a los demás la información a la que no tienen derecho. Es acerca de hacer posible que ésta se conecte a información de sitios peers, que se una a la información de otras aplicaciones. Esto es acerca de estar emocionado por crear conexiones, más que nerviosos”.

Las implicaciones dentro de la web móvil

Berners-Lee también nos dice que el uso de la gráfica social también tiene grandes implicaciones para la web móvil, que el resume planteándonos un escenario específico:

“Cuando reserve un vuelo es el vuelo lo que me interesa. No la página del vuelo en el sitio de viajes o en el sitio de la aerolínea, sino la URI (provista por las aerolíneas) del mismo vuelo. Eso es lo que yo quiero bookmarkear. Y cualquiera que sea el dispositivo que utilice, éste tendrá acceso a una vista (apropiada a la situación) de una integración de todo lo que necesito saber sobre ese vuelo por parte de diferentes fuentes. La tarea de reservar y tomar el vuelo involucrará varias interacciones. Y a través de todas ellas, esa tarea y el vuelo será lo principal, los sitios web involucrados serán cosas secundarias, y la red y los dispositivos serán terciarias”.

A manera de conclusión

Brad Fitzpatrick inició una discusión acerca de los conceptos básicos implicados en el tema de la gráfica social: ¿Qué es? ¿A quién le pertenece? ¿Cuál es la API?

Todas estas cuestiones deberán moldear la evolución de la web social y aunque las situaciones y retos dan la apariencia de ser relativamente simples, las soluciones llevarán bastante trabajo.

Los retos son conceptuales, técnicos, políticos, empresariales y educacionales. Tomará la convergencia de muchas personas (y sus mentes, claro) para que la utilización de las gráficas sociales como la plantea Brad pueda suceder. Tradicionalmente, la industria de la tecnología ha logrado satisfacer a los usuarios y así salir adelante, así que esperaremos que vuelva a suceder lo mismo en este caso.

Tim Berners-Lee ha hecho una gran contribución utilizando el término de la “gráfica social” y mezclándolo con su propia visión de la web semántica. Lo que él describe en su artículo es más amplio que lo que concierne a cualquiera de las redes sociales vigentes: es acerca de cómo interactuamos y compartimos nuestra información en la web (a través de cualquiera que sea el medio) y las conexiones de las que podemos tomar ventaja para utilizar la red de mejor manera: las aplicaciones semánticas.

Luis Eduardo Barrueto para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

A stitch in time saves nine. I couldn’t sew my way out of a bag, but it’s true advice for bloggers as well — a little bit of work on an upgrade now saves a lot of work fixing something later.

Right now there is a worm making its way around old, unpatched versions of WordPress. This particular worm, like many before it, is clever: it registers a user, uses a security bug (fixed earlier in the year) to allow evaluated code to be executed through the permalink structure, makes itself an admin, then uses JavaScript to hide itself when you look at users page, attempts to clean up after itself, then goes quiet so you never notice while it inserts hidden spam and malware into your old posts.

The tactics are new, but the strategy is not. Where this particular worm messes up is in the “clean up” phase: it doesn’t hide itself well and the blogger notices that all his links are broken, which causes him to dig deeper and notice the extent of the damage. Where worms of old would do childish things like defacing your site, the new ones are silent and invisible, so you only notice them when they screw up (as this one did) or your site gets removed from Google for having spam and malware on it.

I’m talking about this not to scare you, but to highlight that this is something that has happened before, and that will more than likely happen again.

A stitch in time saves nine. Upgrading is a known quantity of work, and one that the WordPress community has tried its darndest to make as easy as possible with one-click upgrades. Fixing a hacked blog, on the other hand, is quite hard. Upgrading is taking your vitamins; fixing a hack is open heart surgery. (This is true of cost, as well.)

2.8.4, the current version of WordPress, is immune to this worm. (So was the release before this one.) If you’ve been thinking about upgrading but haven’t gotten around to it yet, now would be a really good time. If you’ve already upgraded your blogs, maybe check out the blogs of your friends or that you read and see if they need any help. A stitch in time saves nine.

Whenever a worm makes the rounds, everyone becomes a security expert and peddles one of three types of advice: snake oil, Club solutions, or real solutions. Snake oil you’ll be able to spot right away because it’s easy. Hide the WordPress version, they say, and you’ll be fine. Uh, duh, the worm writers thought of that. Where their 1.0 might have checked for version numbers, 2.0 just tests capabilities, version number be damned.

The second type of advice is Club solutions; to illustrate, I’ll quote from Mark Pilgrim’s excellent essay on spam 7 years ago, before WordPress even existed:

The really interesting thing about these approaches, from a game theory perspective, is that they are all Club solutions, not Lojack solutions. There are two basic approaches to protecting your car from theft: The Club (or The Shield, or a car alarm, or something similar), and Lojack. The Club isn’t much protection against a thief who is determined to steal your car (it’s easy enough to drill the lock, or just cut the steering wheel and slide The Club off). But it is effective protection against a thief who wants to steal a car (not necessarily your car), because thieves are generally in a hurry and will go for the easiest target, the low-hanging fruit. The Club works as long as not everyone has it, since if everyone had it, thieves would have an equally difficult time stealing any car, their choice will be based on other factors, and your car is back to being as vulnerable as anyone else’s. The Club doesn’t deter theft, it only deflects it.

Club blog security solutions can be simple (like an .htaccess file) or incredibly complex (like two-factor authentication), and they can work, especially for known exploits. Club solutions can be useful, like using a strong or complex password for your login — no one would recommend against that. (Another club solution is switching to less-used software on the assumption or more like the software’s claim that it’s perfect and more secure. This is why BeOS is more secure than Linux, ahem.)

In the car world, if someone figured out how to teleport entire cars to chop shops, The Club wouldn’t be so useful anymore. Luckily for manufacturers of The Club, this hasn’t happened. Online and in the software world, though, the equivalent happens almost daily. There is only one real solution. The only thing that I can promise will keep your blog secure today and in the future is upgrading.

WordPress is a community of hundreds of people that read the code every day, audit it, update it, and care enough about keeping your blog safe that we do things like release updates weeks apart from each other even though it makes us look bad, because updating is going to keep your blog safe from the bad guys. I’m not clairvoyant and I can’t predict what schemes spammers, hackers, crackers, and tricksters will come up with with in the future to harm your blog, but I do know for certain that as long as WordPress is around we’ll do everything in our power to make sure the software is safe. We’ve already made upgrading core and plugins a one-click procedure. If we find something broken, we’ll release a fix. Please upgrade, it’s the only way we can help each other.