CAPÍTULO I ENQUADRAMENTO TECNOLÓGICO
2. Os testemunhos de conexão
2.1. Da Especificação Original da Netscape ao RFC 6265 da IETF
Com o intuito de capitalizar60 as potencialidades emergentes da jovem
Web, Marc Andreessen e Jim Clark fundaram a Mosaic Communications Corporation, a 4 de Abril de 1994, que, ainda no ano da sua fundação, foi
rebatizada de Netscape Communications Corporation (Netscape).
A ideia de negócio passava por uma aposta articulada no comércio, segurança e performance de navegadores e servidores web, que seria capaz de atrair aqueles que se iam mostrando interessados em ganhar dinheiro através da internet.
Os testemunhos de conexão são uma das tecnologias desenvolvidas no seio da Netscape e surgem da necessidade de ultrapassar o problema da falta de estado das ligações HTTP.
20
Lou Montulli trabalhava ao serviço da Netscape quando, em 1994, desenvolveu a ideia dos testemunhos de conexão, adaptando uma tecnologia
conhecida por magic cookie61, usada nas plataformas Unix, às necessidades
de comunicação entre o computador de um utilizador e um site web visitado por aquele, de modo a melhorar a funcionalidade do chamado “cesto de
compras”, suprindo o problema da falta de estado das ligaç es HTTP62
. O “cesto de compras”, para ser eficaz precisava de informaç es de estado de modo a ser capaz de distinguir entre os diferentes compradores ao longo de toda a interação tendente à compra e conseguir registar e agregar os produtos selecionados de modo a serem processados num único momento de compra, no final. Os testemunhos de conexão permitiam ultrapassar o problema da falta de estado das ligações HTTP, possibilitando a implementação eficaz do mecanismo dos “cestos de compra”.
A primeira utilização dos testemunhos de conexão foi promovida no próprio site da Netscape e tinha por finalidade determinar se os visitantes do seu site web estavam a aceder-lhe pela primeira vez ou não.
Montulli escreveu, naquele ano de 1994, com o seu colega John Giannandrea, aquela que foi a especificação original dos testemunhos de
conexão: “Persistent Client State HTTP Cookies”63
.
Conforme explicava a especificação, na sequência da receção de um pedido HTTP, o servidor pode incluir na sua resposta uma informação de estado que vai ser armazenada pelo cliente. Fá-lo através da introdução de
um cabeçalho set-cookie na sua resposta HTTP. Esse “objeto de estado”,
enviado pelo servidor, compreende a descrição dos URLs para os quais é válido. Numa próxima ligação (ao mesmo site web ou a um URLs para o qual aquela informação de estado seja válida) o cliente vai reenviar essa informação, inalterada, ao servidor, através da introdução de um cabeçalho
cookie. Foi a essa informação – “objeto de estado” – enviado pelo servidor ao
61 “Something passed between routines or programs that enables the receiver to perform some operation; a
capability ticket or opaque identifier.”, magic cookie, “The Free On-line Dictionary of Computing”, disponível em
http://foldoc.org/magic+cookie, última consulta em 28 de março de 2013.
62
Até então, os mecanismos de cestos de compras implicavam o armazenamento de informação, por exemplo, no URL. Mas este mecanismo levanta muitos problemas, como vimos na inrodução do Título 2. deste Capítulo I.
21 cliente, armazenado e reenviado àquele por este que Montulli chamou
cookie64 – testemunhos de conexão.
A especificação conferia uma certa confiança ao mecanismo. Os testemunhos apenas podiam ser enviados de e para as páginas que o utilizador visitava – só estas os podiam escrever e ler. Um site não poderia ler ou alterar um testemunho de conexão enviado por outro site.
Esta especificação preliminar dos testemunhos de conexão era um documento informal, de apenas quatro páginas, pouco detalhado.
No entanto, a sua simplicidade permitiu que permanecesse como o
documento de referência por muito tempo – mais do que, como veremos,
seria de esperar.
Em Setembro de 1994, a Netscape incorporou o mecanismo dos testemunhos de conexão na versão 0.9 beta do seu navegador Mosaic
Netscape, que veio a dar origem ao Netscape Navigator 1.0, lançado a 15 de
Dezembro de 1994.
O Netscape Navigator permitia os testemunhos de conexão por defeito. Os testemunhos podiam, então, ser armazenados pelo navegador e reenviados aos servidores visitados sem que o utilizador tivesse conhecimento disso.
A discussão no seio da comunidade científica acerca dos mecanismos de gestão de estado nas ligações HTTP teve início em Abril de 1995, na
mailing list www-talk da W3C.
64 “The state object is called a cookie, for no compelling reason.”, MONTULLI, Lou e GIANNANDREA, John,
Persistent Client State ... , cit..
“According to an article written by Paul Bonner for Builder.Com on 11/18/1997: "Lou Montulli, currently the protocols manager in Netscape's client product division, wrote the cookies specification for Navigator 1.0, the first browser to use the technology. Montulli says there's nothing particularly amusing about the origin of the name: 'A cookie is a well-known computer science term that is used when describing an opaque piece of data held by an intermediary. The term fits the usage precisely; it's just not a well-known term outside of computer science circles.'" WHALEN,
David, The Unofficial Cookie Faq, Cookie Central, disponível em http://www.cookiecentral.com/faq/, última consulta
em 7 de fevereiro de 2013.
A versão portuguesa da Diretiva 2002/58/CE do Parlamento Europeu e do Conselho de 12 de julho de 2002, relativa ao tratamento de dados pessoais e à proteção da privacidade no sector das comunicações eletrónicas (Diretiva relativa à privacidade e às comunicações eletrónicas), adota, segundo apuramos, pela primeira vez a terminologia “testemunhos de conexão” para se referir aos cookies. Em França, em março de 1999, foi introduzida oficialmente a expressão “témoin de connexion”. O Office de la langue française du Québec já havia proposto, em setembro de 1996, o termo “témoin” como equivalente a cookie. Cf. informação disponível no site oficial do Office de la langue
22
Em 25 de Agosto de 1995, no Grupo de Trabalho do HTTP da IETF,
surgiu uma primeira proposta65 que visava introduzir estado no HTTP,
através da introdução de um novo cabeçalho de pedido e resposta que permitiria que informações de estado fossem transmitidas entre o servidor e o cliente.
Consciente de que um histórico das ações dos utilizadores era útil ou
essencial para certas aplicações web66, Kristol propôs uma tecnologia que
permitia informação de estado que persistiria unicamente durante cada sessão. Este era um modelo diferente do que vinha a ser adotado e que estava previsto na especificação da Netscape.
Larry Masinter presidia, então, ao Grupo de Trabalho do HTTP da IETF e considerou pertinente criar um subgrupo para discutir a questão e chegar a uma abordagem consensual sobre o tema a ser apresentada aos
restantes participantes do Grupo de Trabalho67. Lui Montulli, autor da
especificação original da Netscape, foi uma das oito pessoas que constituíram o subgrupo, formado em Dezembro de 1995.
Como explica David M. Kristol68, a especificação original da Netscape
foi, então, adotada como modelo para o trabalho que veio a ser desenvolvido pelo subgrupo.
Em Fevereiro de 1996, o subgrupo considerou a possibilidade de, em teoria, os navegador poderem receber, armazenar e reenviar testemunhos de conexão de e para sites que o utilizador não visitasse diretamente. Eram as
chamadas “transaç es não verificáveis” 69 ou, como vieram a ficar
conhecidas, os testemunhos de terceiros.
Apesar de, desde a especificação da Netscape, a tecnologia vedar que um site diferente daquele que criou o testemunho para ser armazenado no
65
KRISTOL, David M., Proposed HTTP State-Info ..., cit..
66
KRISTOL, David M., Proposed HTTP State-Info ..., cit..
67
KRISTOL, David M., HTTP Cookies: Standards,... , cit., pp. 10 a 12.
68
KRISTOL, David M., HTTP Cookies: Standards,... , cit., pp. 10-12.
23 terminal do utilizador o lesse, era possível que componentes de terceira parte do site visitado enviassem os seus próprios testemunhos.
As preocupações do subgrupo focaram-se, então, no facto de que, se por um lado é expectável que o utilizador possa contar com testemunhos dos
sites web que deliberadamente visita, por outro não tem porque esperar
receber testemunhos de um site que não visita deliberadamente, mas a que, por exemplo, o seu navegador acede porque o site web que o utilizador deliberadamente visitou carrega uma imagem de um outro site que lhe vai enviar um testemunho.
A especificação foi publicada como RFC 2109 – “HTTP State
Management” – sob a autoria de D. Kristol e L. Montulli, em Fevereiro de
199770.
Mas continuavam a registar-se problemas de compatibilidade. Os navegadores Netscape Navigator e Internet Explorer comportavam-se de
modo diferente perante atributos que não lhes fossem familiares71.
O RFC 2109 tentou promover alterações que não foram bem
sucedidas72.
No que respeitava às “transaç es não verificáveis”, a especificação determinava a proibição de os navegadores web aceitarem testemunhos de terceiro ou só, em alternativa, permitia que os aceitassem com a condição de estes poderem ser controlados pelo utilizador através de uma opção que, por defeito, os rejeitaria.
Muitos modelos de negócio assentavam, já, nos testemunhos de terceira parte e as críticas à especificação não se fizeram esperar.
70
KRISTOL, D. e MONTULLI, L., HTTP State Management Mechanism, RFC 2109, The Internet Engineering Task
Force (IETF), fevereiro de 1997, disponível em http://www.ietf.org/rfc/rfc2109.txt, última consulta em 10 de dezembro
de 2012.
71
Cf. KRISTOL, David M., HTTP Cookies: Standards,... , op. cit. pp. 12 e 13.
72 Neste sentido ZALEWSKI, Michael, HTTP cookies, or how not to design protocols, em “lcamtuf's blog”, 28 de
outubro de 2010, disponível em http://lcamtuf.blogspot.pt/2010/10/http-cookies-or-how-not-to-design.html, última
24
A discussão para a revisão do RFC foi longa.
Conforme explica Kristol, a discussão em torno de questões relacionadas com as “transaç es não verificáveis” fez com que o trabalho tendente à revisão da especificação entrasse num impasse e, de modo a conseguir progredir nos trabalhos, foi decidido afastar a parte respeitante às “transaç es não verificáveis” até à obtenção de um consenso na parte
tecnológica73.
Obtido o ambicionado consenso e reintroduzida a questão das “transaç es não verificáveis” não surgiram mais comentários sobre o
anteriormente tão debatido tema e o novo RFC 296574, publicado em outubro
de 2000, não viria a diferir materialmente do seu antecessor neste tocante75.
De modo a superar as incompatibilidades verificadas, a especificação descrevia três cabeçalhos: o cabeçalho cookie, o cabeçalho set-cookie2 e o cabeçalho cookie2.
As especificações dos testemunhos de conexão eram documentos que
não refletiam a realidade da implementação da tecnologia do mecanismo76.
O RFC 2965, irrealista no seu esforço de tentar redesenhar o
mecanismo dos testemunhos de conexão, foi considerado um falhanço77.
Com especificações desadequadas, as compatibilidades com os diferentes navegadores tinha de ser atestada por tentativas.
73 A discussão levantada em torno dos testemunhos de terceira parte levou à proposta de “testemunhos
certificados”, apresentada Dan Jaye. A ideia, pressupunha a existência de uma entidade certificadora independente que atestaria e auditaria o nível de confiança dos sites, atendendo às suas politicas de privacidade, permitindo aos utilizadores optar por permitir ou não os testemunhos de acordo com a sua utilização. O cabeçalho http Set-Cookie- Certifiers permitiria o envio do certificado juntamente com o testemunho, que serviria para o navegador aferir da compatibilidade das finalidades de uso dos testemunhos em causa com as definições do navegador por que o utilizador teria optado.
“The intent is to provide a mechanism that allows user agents to determine the privacy policies of a server and to accept or reject cookies based on that policy. Allowing the user to decide whether to accept cookies based on how the server uses them provides far better control over privacy than just distinguishing between servers the users directly accesses (verified transactions) and those to which the user agent was redirected (unverified transaction.)”, JAYE, Dan, HTTP State Management Proposal foi Certified Cookies, 30 de março de 1997, disponível em
http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997JanApr/0742.html, última consulta em 20 de novembro de 2012.
74
KRISTOL, D. e MONTULLI, L., HTTP State Management Mechanism, RFC 2965, The Internet Engineering Task
Force (IETF), outubro de 2000, disponível em http://www.ietf.org/rfc/rfc2965.txt última consulta em 10 de dezembro
de 2012.
75
Para uma descrição mais pormenorizada sobre a história dos RFC 2109 e RFC 2965, ver KRISTOL, David M., HTTP Cookies: Standards,... , cit., pp. 24 e ss..
76
Sendo o RFC 2956 o que mais se afastava da implementação real do mecanismo.
25 A descrição realista da implementação deste mecanismo só veio a ser
feita no RFC 6265 – “HTTP State Management Mechanism”78
, publicado em Abril de 2011, da autoria de A. Barth.
Em inícios de 2009, a IETF iniciou uma mailinglist para discutir os problemas relacionados com os testemunhos de conexão, que culminou com a criação, em dezembro daquele ano, do Grupo de Trabalho HTTP State
Management Mechanism, que teve por presidente Jeff Hodges.
O Grupo de Trabalho tinha por objetivo especificar aquilo que eram as implementações comuns do mecanismo e documentar as variações existentes procurando um consenso dentro destas.
Assim, ficou desde logo assente79, que o Grupo de Trabalho não
criaria nada de novo.
O Grupo propôs-se, tão-somente, a descrever como implementar os testemunhos e conexão de modo a que interagissem eficazmente com as infraestruturas existentes.
O RFC 6265 especifica os cabeçalhos set-cookie e cookie como eles são realmente usados na Internet.