User tracking through web sessions

Faculdade de Engenharia da Universidade do Porto

User Tracking Through Web Sessions

Rui André Castanheira Polónia

Dissertação realizada no âmbito do

Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Major Telecomunicações

Orientador: Professor Doutor João Correia Lopes

Co-orientador: Mestre Pedro Fortuna

iii

Resumo

A Web é, sem dúvida, a auto-estrada da informação, onde os utilizadores podem aceder a todo o tipo de dados e serviços de forma rápida e eficiente. No entanto, a Web é também um ambiente hostil e pouco seguro para os utilizadores, em que a privacidade é, muitas vezes, impossível de assegurar. Existem utilizadores que, sabendo isto, se dedicam a navegar a Web de forma anónima e que procuram esconder toda a informação que os possa identificar. Este comportamento pode também ser motivados por razões mais obscuras, como por exemplo a protecção de identidade para a execução de crimes electrónicos.

Neste trabalho foi efectuado um pequeno levantamento sobre o e-marketing e o problema da Click Fraud. Este problema serviu como motivação para o desenvolvimento de um sistema que permitisse identificar utilizadores Web, num contexto em que se assumia que os utilizadores empregavam diversas técnicas para não serem identificados. Não se procurava obter a identidade dos utilizadores nem qualquer tipo de informação privada ou confidencial. O objectivo do sistema é correlacionar visitas de utilizadores anónimos no sentido de perceber se é um único utilizador, mesmo que utilize técnicas de dissimulação. A privacidade e o direito de anonimato dos utilizadores foram respeitados em todos os instantes.

Após um levantamento das técnicas que permitem executar user tracking e do trabalho relacionado foi proposto um sistema inovador, combinando várias técnicas diferentes. A solução desenvolvida foi implementada integrando a plataforma de auditoria de tráfego Web da AuditMark e baseia-se na utilização de endereços IP, Cookies HTTP e de aplicação, e num método de geração de assinatura digital criada a partir de vários parâmetros capturados da máquina do utilizador. Foi também necessário desenvolver uma plataforma para simular visitas de utilizadores com diferentes características, que dificultassem a identificação, e uma ferramenta para análise e avaliação dos resultados obtidos.

O sistema apresentou um desempenho muito bom, alcançando os objectivos propostos. O problema abordado é complexo e pode-se concluir que este trabalho contribuiu para a sua resolução, possibilitando um novo método de correlacionar utilizadores ao longo de várias sessões Web, identificando todas as visitas de cada um deles.

v

Abstract

The Web is, undoubtedly, the information highway, where users can access all kinds of data and services quickly and efficiently. However, the Web is also a hostile and unsafe environment for users, where privacy is often impossible to assure. There are users that dedicate themselves to browse the Web anonymously and that seek to hide any information that can identify them. These users may also be motivated by more obscure reasons, such as protecting their identity to perpetrate electronic crimes.

In this document, a small survey on e-marketing and the Problem of Click Fraud is presented. It served as a motivation for the development of a system that enabled the identification of Web users, in a context in which was assumed that users employ camouflage and concealment techniques as methods to prevent identification. The purpose was not to determine the identity of the users or to obtain any kind of private or confidential information. The main goal of the system is to correlate multiple visits of anonymous users to understand whether it is a single user using cover up techniques. The fundamental user’s rights for privacy and anonymity were respected in all instances.

Subsequently to a survey of user tracking techniques and related work, a novelty system was proposed, combining several different techniques. Integrating AuditMark’s Web traffic auditing service, the developed solution is based on IP addresses, both HTTP and application cookies, and on a method for generating digital signatures from a variety of parameters captured from the users machine. It was also necessary to develop a system to simulate Web traffic from users with different characteristics, which would hinder the identification, and a tool for results analysis and evaluation.

The system had a very good performance, achieving its objectives. The problem addressed is complex and one can conclude that this work contributed to its resolution, enabling a new method that allows the identification of users through their Web sessions, seeking to identify the requests generated by each one.

vii

Agradecimentos

Gostaria de agradecer aos orientadores deste trabalho, Professor Doutor João Correia Lopes e Mestre Pedro Fortuna, todo o apoio que me prestaram durante todo este período, desde o inicio da pesquisa, até às últimas revisões do relatório. Muito obrigado pelas sugestões e concelhos que me apontaram sempre na melhor direcção.

A todos os meus colegas na AuditMark agradeço o bom ambiente de trabalho e toda a ajuda que me prestaram ao longo do projecto. Foram, sem dúvida, um grande auxílio e fonte de conhecimento e aprendizagem para mim.

Desejo ainda lembrar todos os amigos e colegas que me perguntaram, e se dispuseram a ouvir, sobre o progresso deste trabalho. Por terem partilhado dos desafios e obstáculos a superar e muitas vezes até tentado contribuir, oferecendo algumas ideias. A todos o meu muito obrigado.

À Rita, agradeço todo o apoio, conforto e carinho que só ela me pode dar.

Finalmente, e mais importante, quero agradecer a Deus pela oportunidade e por me ter concedido as capacidades e meios para conseguir completar este trabalho.

ix

Ao ilustre cidadão e, por acaso, meu querido avô, Júlio Castanheira. Como tenho saudades tuas!

xi

Índice

Capítulo 1 - Introdução ...

1

Capítulo 2 - Publicidade na Web ...

5

2.1 - Publicidade na Web ... 7H5

2.2 - Modelos de Negócio ... 8H6

2.2.1 – Cost per Mille(CPM) ... 9H7

2.2.2 – Cost per Click (CPC) ... 10H7

2.2.3 – Cost per Action (CPA) ... 11H7

2.3 – Click Fraud ... 12H8

2.4 – AuditService ... 13H9

2.4.1 – Camada de recolha de dados ... 14H10

2.4.3 – Camada de processamento de dados ... 15H12

Capítulo 3 - User Tracking ...

13

3.1 – Introdução ... 17H13

3.2 – Identificação do Utilizador ... 18H13

3.3 – Identificação do Browser ... 19H14

3.4 – Identificação da Máquina ... 20H21

3.5 – Identificação da Sessão ... 21H24

3.6 – Resumo das Técnicas ... 22H26

Capítulo 4 - Trabalho Relacionado...

29

4.1 – Web Activity Tracking (WAT) System ... 24H29

4.2 – T-Prox ... 25H31

4.3 – Técnicas de estimação de desvio de relógio ... 26H34

4.4 – Conclusão ... 27H37

Capítulo 5 - Especificação e Implementação da Solução ...

39

5.1 – Requisitos do Sistema ... 29H39

5.2 – Arquitectura da Solução ... 30H40

5.2.1 – Recolha dos dados ... 31H40

5.2.2 – Processamento dos dados ... 32H43

5.3 – Resumo ... 33H47

Capítulo 6 - Metodologia de Teste ...

49

6.1 – Introdução ... 35H49

6.2 – Abordagens Possíveis ... 36H49

6.2.2 – Testes utilizando dados obtidos de tráfego simulado ... 38H51

6.3 – Simulação de Utilizadores ... 39H52

6.3.1 – Definição dos perfis de utilizadores a simular ... 40H52

6.3.2 – Arquitectura do sistema de simulações ... 41H54

6.4 –Visualização dos Resultados ... 42H57

6.5 – Resumo ... 43H60

Capítulo 7 - Testes e Resultados ...

63

7.1 – Introdução ... 45H63

7.2 – Simulações Individuais ... 46H64

7.2.1 – Simulação de um utilizador do perfil Padrão ... 47H64

7.2.2 – Simulação de um utilizador do perfil Segurança (3)... 48H66

7.2.3 – Simulação de um utilizador do perfil Malicioso (2) ... 49H69

7.3 – Simulações por Perfil ... 50H70

7.3.1 – Simulação de todos os utilizadores com perfil Padrão ... 51H71

7.3.2 – Simulação de todos os utilizadores com perfil Segurança (1) ... 52H72

7.3.3 – Simulação de todos os utilizadores com perfil Segurança (2) ... 53H73

7.3.4 – Simulação de todos os utilizadores com perfil Segurança (3) ... 54H77

7.3.5 – Simulação de todos os utilizadores com perfil Malicioso (1) ... 55H78

7.3.6 – Simulação de todos os utilizadores com perfil Malicioso (2) ... 56H80

7.3.7 – Simulação do perfil Malicioso (3) ... 57H82

7.4 – Testes com utilizadores reais ... 58H82

7.4.1 – Resultados com apenas um utilizador ... 59H83

7.4.2 – Resultados com todos os utilizadores ... 60H84

7.5 – Conclusões ... 61H86

Capítulo 8 - Conclusões e Trabalho Futuro ...

89

8.1 – Conclusões ... 63H89

8.2 – Trabalho Futuro ... 64H90

Referências ...

93

Anexo A – Dados Recolhidos pelo JIC v1.0 ...

97

Anexo B – Dados Recolhidos pelo JIC v2.0 ...

99

Anexo C – Diagrama Relacional da Base de Dados Simplificado ...

103

xiii

Lista de Figuras

Figura 2.1 - Arquitectura do AuditService ... 70H10

Figura 3.1 - Método de redireccionar utilizador ... 71H18

Figura 4.1 - Esquema do método proposto por Renáta Iváncsy e Sándor Juhász ... 72H30

Figura 4.2 - Captura de dados através do uso de proxies ... 73H32

Figura 4.3 - Grafo representando a navegação de um utilizador... 74H33

Figura 5.1 - Arquitectura final do JIC ... 75H42

Figura 6.1 - Arquitectura do Selenium RC ... 76H55

Figura 6.2 - Arquitectura de Simulação com WebScarab ... 77H56

Figura 6.3 - Exemplo de cenário de operação do sistema de simulação de utilizadores ... 78H57

Figura 7.1 - Simulação de utilizador Padrão (SDC.00003): Sessões reconstruídas ... 79H64

Figura 7.2 - Simulação de utilizador Padrão (SDC.00003): Resultados de User Tracking ... 80H66

Figura 7.3 - Simulação de utilizador Segurança (3) (SDC.00024): Sessões reconstruídas ... 81H66

Figura 7.4 - Simulação de utilizador Segurança (3) (SDC.00024): Resultados de User

Tracking ... 82H68

Figura 7.5 – Simulação de utilizador Malicioso (2) (SDC.00041): Sessões reconstruídas ... 83H69

Figura 7.6 - Simulações de utilizadores Padrão (SDC.00003-00009): Sessões reconstruídas ... 84H71

Figura 7.7 - Simulações de utilizadores Padrão (SDC.00003-00009): Resultados de User

Tracking para Combined Similarity ... 85H71

Figura 7.8 - Simulações de utilizadores Segurança (1) (SDC.00010-00016): Sessões

reconstruídas ... 86H72

Figura 7.9 - Simulações de utilizadores Segurança (1) (SDC.00010-00016): Resultados de User Tracking para Combined Similarity ... 87H73

Figura 7.10 - Simulações de utilizadores Segurança (2) (SDC.00017-00023): Sessões

Figura 7.11 - Simulações de utilizadores Segurança (2) (SDC.00017-00023): Resultados de User Tracking para Flash Cookie Similarity ... 89H74

Figura 7.12 - Simulações de utilizadores Segurança (2) com sistema operativo Windows (SDC.00017-00021): Sessões reconstruídas ... 90H76

Figura 7.13 - Simulações de utilizadores Segurança (2) com sistema operativo Ubuntu

(SDC.00022-00023): Sessões reconstruídas ... 91H77

Figura 7.14 - Simulações de utilizadores Segurança (3) (SDC.00024-00030): Sessões

reconstruídas ... 92H78

Figura 7.15 - Simulações de utilizadores Malicioso (1) (SDC.00031-00037): Sessões

reconstruídas ... 93H79

Figura 7.16 - Simulações de utilizadores Malicioso (1) (SDC.00031-00037): Resultados de User Tracking para Combined Similarity ... 94H79

Figura 7.17 - Simulações de utilizadores Malicioso (2) (SDC.00038-00044): Sessões

reconstruídas ... 95H80

Figura 7.18 - Simulações de utilizadores Malicioso (2) (SDC.00038-00044): Resultados de User Tracking para Flash Cookie Similarity ... 96H80

Figura 7.19 - Utilizador Real (SDC.1001): Sessões reconstruídas ... 97H83

Figura 7.20 - Utilizadores Reais (SDC.1000-1007): Sessões reconstruídas ... 98H85

xv

Lista de Tabelas

Tabela 3.1 - Técnicas de User Tracking ...100H27

Tabela 3.2 - Combinações de Técnicas ...101H28

Tabela 6.1 - Perfis de utilizadores para simulação ...102H53

Tabela 7.1 - Configurações de Software nas máquinas de simulação ...103H64

Tabela 7.2 - Simulação de utilizador Padrão (SDC.00003): Sessões reconstruídas ...104H65

Tabela 7.3 - Simulação de utilizador Segurança (3) (SDC.00024): Sessões reconstruídas ...105H67

Tabela 7.4 - Simulação de utilizador Malicioso (2) (SDC.00041): Sessões reconstruídas ...106H70

Tabela 7.5 - Simulações de utilizadores Segurança (2) (SDC.00017-00023): Sessões

reconstruídas por assinatura ...107H75

Tabela 7.6 - Simulações de utilizadores Malicioso (2) (SDC.00038-00044): Sessões

reconstruídas por assinatura ...108H81

Tabela 7.7 - Registo dos logs obtidos de utilizadores reais ...109H83

Tabela 7.8 - Utilizador Real (SDC.1001): Sessões reconstruídas ...110H84

Tabela 7.9 - Utilizadores Reais (SDC.1001-1007): Sessões reconstruídas ...111H86

Tabela A.1 - JIC v1.0 – Dados recolhidos via JavaScript ...112H97

Tabela A.2 - JIC v1.0 – Dados recolhidos via Flash ...113H97

Tabela B.1 - JIC v2.0 – Dados recolhidos via JavaScript ...114H99

Tabela B.2 - JIC v2.0 – Dados recolhidos via Flash ... 115H101

Tabela B.3 - JIC v2.0 – Dados recolhidos via Java ... 116H101

Lista de Código

Código 3.1 - Exemplo de código JavaScript embebido em HTML... 118H15

xvii

Abreviaturas e Símbolos

Lista de abreviaturas

CSS Cascading Style Sheets

DCI

Data-Collection Interface

DDBA

DHCP

DNS Domain Name System

DOM Document Object Model

DP

DPO

DPP

FEUP Faculdade de Engenharia da Universidade do Porto HTML HyperText Mark-up Language

HTTP HyperText Transport Protocol HTTPS HyperText Transfer Protocol Secure ICMP Internet Control Message Protocol

IP Internet Protocol

ISP Internet Service Provider JIC JavaScript Interaction Code PHP Hypertext Pre-processor RMI Remote Method Invocation SDC Server Data-Collector

TCP Transmission Control Protocol URL Uniform Resource Locator

Web World Wide Web

1

Capítulo 1

5B

Introdução

Neste primeiro capítulo é apresentado o tema do trabalho a desenvolver, focando o enquadramento em que foi desenvolvido e o contexto científico actual que abrange as áreas abordadas, para que se possam apreender as motivações para este trabalho. São ainda introduzidas, de forma resumida, a definição do problema e os objectivos a alcançar.

1.1 - Enquadramento

Não se sabe ao certo quando a publicidade foi inventada. Há evidências de inúmeras formas de publicidade no mundo antigo, desde escrita em papiros no antigo Egipto a imagens pintadas em paredes ou rochas na Índia. Estas formas de comunicação primitivas, criadas com o objectivo de alcançar o maior número possível de pessoas e em última análise trazer benefícios ao anunciante, antecedem invenções como a imprensa, o rádio e a televisão. Com o aparecimento dos meios de comunicação para massas a publicidade passou a poder alcançar milhões e milhões de pessoas facilmente e tornou-se a sua principal fonte de receitas.

Também a Web, cujo número de utilizadores aumentou tremendamente ao longo dos anos, passou a ser vista como um mercado cheio de potencial para publicidade. Utilizando todo o tipo de meios multimédia suportados na Web, surgiram novas formas de surpreender e captar a atenção dos utilizadores: desde mensagens de correio electrónico, muitas vezes utilizadas de forma abusiva, até pop-ups, banners, advergames1_{, vídeos publicitários que são}

reproduzidos antes do conteúdo pretendido, etc. Surgiram também empresas especializadas no marketing electrónico, o e-marketing, podendo operar de perspectivas diferentes.

1 Fusão dos termos em Inglês: advertise (propaganda) e game (jogo). Como o nome indica é uma estratégia que utiliza pequenos jogos embutidos nas páginas como ferramentas de marketing.

2 5BIntrodução

Este projecto foi proposto pela AuditMark2_{, uma empresa que realiza actividades de}

Investigação e Desenvolvimento em duas áreas específicas relacionadas com o e-marketing: auditoria de campanhas publicitárias na Web e análise de tráfego Web. Estas são áreas que se encontram em grande expansão para responder à crescente procura de soluções de monitorização das transacções publicitárias na Web que se deve em grande parte à tentativa de detecção de fraudes, como é o caso da Click Fraud3_{. De forma a possibilitar uma melhor}

compreensão destes temas a publicidade na Internet e o problema da Click Fraud serão abordados de uma forma mais detalhada no capítulo 2.

1.2 - Contexto

Para que a detecção de Click Fraud seja possível é necessário determinar se um utilizador terá utilizado abusivamente um determinado link publicitário. Daqui surge a necessidade de perceber quais são os padrões normais de navegação de utilizadores e quais são os padrões desviantes, e a necessidade de identificar se um dado utilizador é o mesmo utilizador que já visitou previamente o website ou que regressará no futuro, mesmo que este tente aparentar ser outro utilizador. A investigação e a procura de tecnologias que permitam seguir utilizadores na Web (Web User Tracking) não é novidade, mas, embora já se tenha escrito sobre este tema e algumas propostas tenham sido feitas, ainda é um problema sem soluções definitivas e que continua a interessar muitos investigadores. O problema de identificar um utilizador num dado momento para que mais tarde se possa afirmar se é o mesmo ou não é bastante complexo e, até agora, não se conseguiu nenhuma abordagem ou método que fosse inteiramente fiável. Este cenário agrava-se ainda mais quando se considera um contexto em que o utilizador não oferece qualquer cooperação ou, ainda pior, quando o utilizador se opõe activamente procurando evitar e frustrar todas as tentativas de o identificar. É necessário assumir que entidades ou utilizadores que cometem Click Fraud e outros crimes electrónicos estão a par das tecnologias e inovações no campo de user tracking e procuram usar esse conhecimento para esconder os seus crimes. Este é o cenário que se deve considerar quando se deseja identificar utilizadores que praticam Click Fraud.

Muitas das soluções propostas para seguir utilizadores Web baseiam-se na escolha e registo de um ou vários valores que consideram suficientes para identificar um utilizador univocamente. São muitas vezes escolhidos campos específicos dos cabeçalhos dos protocolos de comunicação utilizados entre o software de navegação Web (browser) do utilizador e os servidores Web, como por exemplo o TCP [1] ou o HTTP [2], mas podem também ser obtidos de outras formas, recorrendo por exemplo a código JavaScript que corre no browser do

2 Website disponível em http://www.auditmark.com. 3 Este conceito será abordado e bem definido no Capítulo 2

3

utilizador e pode fornecer muita informação. Podem ainda ser escolhidos valores identificadores de outras naturezas, obtidos após processamento dos valores capturados, como é o caso dos clock-skews [1,3,4,5] que são desvios dos relógios electrónicos, presentes em cada máquina. Quaisquer que sejam, estes valores devem ser únicos e imutáveis ou pelo menos constantes durante um certo período de tempo, isto é, várias visitas ou sessões Web ao website que está a ser monitorizado. Durante este período permanecerão válidos mas ainda assim surgirá a dificuldade de interligar os dados de dois períodos diferentes em que os valores foram alterados. As soluções mais comuns são as que recorrem ao endereço IP da máquina do utilizador [6] ou ao uso de Cookies HTTP [7,8,9,10]. Existem ainda casos em que estes dois métodos foram utilizados de forma complementar [11]. No entanto, no cenário considerado de detecção de Click Fraud, estas abordagens só por si não bastam uma vez que um utilizador pode facilmente utilizar proxies para esconder o seu endereço IP e rejeitar Cookies ou apagá-los antes de efectuar nova visita, desta forma parecendo sempre um utilizador diferente. Começa a definir-se desta forma o problema que será abordado neste trabalho.

1.3 - Definição do Problema

O principal objectivo deste projecto foi o de projectar e implementar um sistema capaz de recolher informação online de forma a obter um registo das sessões Web de todos os utilizadores de um determinado website para que possa identificar sessões que tenham sido geradas pelo mesmo utilizador, mesmo que a identificação seja não trivial. Por não trivial são entendidas situações em que os dados obtidos de forma convencional ou por análises utilizando os identificadores mais comuns não indicam tratar-se do mesmo utilizador. Esta identificação de sessões diferentes deveria ser efectuada com recurso a várias técnicas de user tracking assumindo sempre um cenário em que o utilizador está activamente empenhado em opor-se a qualquer acção que tenha como objectivo a sua identificação. O funcionamento do sistema neste cenário implica também a identificação dos utilizadores comuns que não desenvolvem medidas para dissimular a sua identidade.

Todo o processo implementado deveria ser executado sem que fosse perceptível para os utilizadores. Empresas de auditoria Web geralmente não são autorizadas a alterar o código e a estrutura das páginas das entidades a ser auditadas e isto implicava que as soluções encontradas tivessem que contornar este problema e minimizassem as alterações a essas páginas e aos seus servidores. Soluções baseadas na arquitectura dos próprios domínios Web não eram aplicáveis uma vez que acatariam alterações de grandes proporções aos websites auditados.

Importa ainda clarificar que o conceito de identificar utilizadores, como foi aplicado neste trabalho, não é o de procurar obter a identidade do utilizador em si nem qualquer tipo de dados pessoais. Deste modo não se levanta a questão de quebra de privacidade dos

4 5BIntrodução

utilizadores e dos seus direitos de anonimato. O objectivo era, pelo contrário, seguir os utilizadores para que se pudesse determinar que sessões Web foram originadas por um único utilizador, mantendo o seu anonimato.

1.4 - Objectivos do Projecto

Este trabalho teve como objectivos o levantamento das técnicas conhecidas que permitem efectuar user tracking e a proposta e implementação de um sistema que regista sessões Web, recolhendo informação sobre os utilizadores, e que através da sua análise conclua, com um certo grau de certeza, quantos utilizadores diferentes foram encontrados. Foram ainda efectuados testes e uma análise crítica dos resultados obtidos de forma a perceber a sua fiabilidade e quais os contributos do sistema para esta área de investigação.

O sistema foi desenhado tendo em perspectiva a possibilidade de vir a ser integrado em sites corporativos e, desta forma, foram tomadas medidas para que esta integração possa ocorrer com relativa facilidade e sem a necessidade de grandes alterações no código das páginas auditadas. O trabalho foi desenvolvido sobre o serviço de auditoria da AuditMark e executado na forma de um plug-in. Foi ainda um objectivo deste trabalho que o sistema desenvolvido permitisse que no futuro se possam empregar as técnicas usadas em conjugação com outros sistemas semelhantes para que se possam complementar.

1.5 - Estrutura do Documento

Este documento está organizado em oito capítulos. Após o primeiro capítulo, em que foi feita a introdução aos temas a abordar e ao projecto, é apresentado, no capítulo 2, um apanhado geral dos modos de funcionamento da publicidade na Web actualmente, da forma como o problema da Click Fraud prejudica as partes envolvidas e é apresentada a arquitectura da plataforma de auditoria da AuditMark, a ferramenta em que este trabalho se integra e que visa a avaliação da qualidade do tráfego de campanhas publicitárias. No terceiro capítulo são introduzidas as técnicas que podem ser usadas para realizar User Tracking, mencionando-se as suas contribuições e importância para este trabalho. O levantamento do trabalho relacionado, que tem vindo a ser desenvolvido usando as técnicas apresentadas, é apresentado no capítulo 4. O quinto capítulo deste documento é ocupado com a especificação do trabalho realizado, descrição da sua arquitectura e implementação. As técnicas desenvolvidas e utilizadas para a avaliação do trabalho desenvolvido são apresentadas no capítulo 6 e no capítulo 7 são apresentados os resultados obtidos e efectuada a sua análise crítica. No último capítulo é apresentada a conclusão do trabalho e propostas de trabalho futuro.

5

Capítulo 2

6B

Publicidade na Web

De forma a clarificar os conceitos que estão na base das motivações para este trabalho, e para que o contexto no qual ele se insere fique bem definido, este capítulo apresenta um breve resumo do modo de funcionamento da publicidade online, da forma como o problema da Click Fraud a afecta e uma visão geral da arquitectura do AuditService, a plataforma que a AuditMark tem vindo a desenvolver para auditar o tráfego gerado em campanhas de publicidade online e na qual o sistema desenvolvido neste trabalho ficou integrado.

2.1 - Publicidade na Web

A Internet evoluiu muito rapidamente, ao longo de apenas algumas décadas, de uma rede restrita, que exigia dos seus utilizadores grandes conhecimentos técnicos pouco difundidos na época, para tornar-se numa rede global amplamente divulgada e facilmente acessível a qualquer pessoa. Este desenvolvimento deveu-se principalmente à invenção da World Wide Web (WWW ou simplesmente Web) e de protocolos como o HTTP [12] e tecnologias como o XML [13] que permitiram a partilha e transferência de documentos, contendo não só texto e imagens, como outros conteúdos multimédia como áudio e vídeo. A simplificação das formas de interacção com os recursos disponíveis atraiu muitos utilizadores e, em última análise, tornou a Internet no meio de comunicação de massas que é actualmente. À medida que a Web foi crescendo também se foi tornando evidente o seu potencial para o marketing e publicidade. Desde o enorme leque de grupos alvo atingíveis através da Web até às diversas formas como as mensagens publicitárias podem ser apresentadas, passando pelo facto de não existirem qualquer tipo de fronteiras geográficas ou de os conteúdos estarem disponíveis a qualquer momento, a Internet veio provar-se um veículo completo para campanhas publicitárias.

6 Publicidade na Web

2.2 - Modelos de Negócio

As diferenças entre a Internet e os outros meios de comunicação habitualmente utilizados para expor publicidade forçaram a criação de novos modelos de negócio, diferentes dos modelos existentes para a publicidade tradicional. No entanto, há factores que permanecem inalterados, como o objectivo geral da publicidade ou os intervenientes no processo: os anunciantes e os expositores. Contudo, estes termos podem ser melhor adequados e particularizados para o caso de publicidade na Web. Como anunciantes são entendidas as entidades que pretendem expor as mensagens publicitárias. No contexto Web, podem ser por exemplo empresas que desejam publicitar os seus produtos, podendo também procurar atrair mais visitantes para os seus websites. Geralmente os anunciantes não possuem os recursos necessários para a publicação das suas mensagens publicitárias e desta forma optam por recorrer aos expositores. Expositores são aqueles que se responsabilizam pela disponibilização dos conteúdos publicitários aos seus destinatários, neste caso, os utilizadores Web. Estas são as entidades que publicam ou exibem os anúncios e desta forma devem garantir a qualidade do serviço. Os expositores são geralmente Websites escolhidos por terem um elevado número de visitantes diários ou por atingirem um determinado grupo que é o alvo da publicidade. Existem ainda agências publicitárias que podem ser utilizadas como intermediárias entre anunciantes e expositores passando a gerir as campanhas publicitárias dos seus clientes anunciantes e fornecendo conteúdos aos expositores.

Uma das diferenças entre os modelos tradicionais de publicidade e os adoptados para publicidade na Web é a forma como a sua eficácia é medida. Como já foi referido, são os expositores que devem garantir a qualidade do serviço que é definido segundo um acordo entre as partes. A informação sobre a qualidade de serviço é habitualmente disponibilizada sob a forma de estatísticas que medem a eficácia que a publicidade está a ter, segundo determinados parâmetros. As duas formas mais comuns para realizar estas medições são:

Click-Through Rate — Geralmente expresso em percentagem, é a razão entre o número de utilizadores que clicaram numa publicidade e o número total de utilizadores que visualizaram a página Web que expôs o anúncio.

Conversion Rate — É definida como a razão entre o número de utilizadores que numa determinada página Web executaram uma determinada acção, ou, em linguagem de marketing, conversão, e o número total de utilizadores que visitou essa página. Exemplos típicos de acções de conversão são o registo do utilizador na página ou a compra de um produto.

No primeiro caso é impossível inferir as motivações que levaram cada utilizador a clicar na publicidade e, desta forma, é impossível separar os utilizadores que estão interessados no

7

produto dos que seguiram o link com outras intenções. Facilmente se percebe que a segunda forma de medição é mais exigente e reflecte com mais precisão os utilizados que estão de facto interessados no produto que foi anunciado uma vez que implica uma acção da parte dos utilizadores, que pode ser também entendido como um custo.

Outra grande diferença entre os modelos de publicidade tradicionais e os modelos de publicidade na Web prende-se sobretudo com as múltiplas opções de pagamento possíveis no segundo caso. Estes modelos de pagamento resultam directamente da grande diversidade de formas de fazer publicidade na Web que não são possíveis em outros meios de comunicação e da possibilidade de interacção directa com os destinatários da publicidade. As três metodologias de pagamento mais habituais são descritas nas Secções seguintes.

13B2.2.1 – Cost per Mille

4_(CPM)

Também referido como Cost per Impression, este modelo de pagamento é o mais semelhante ao da publicidade tradicional: por definição o anunciante paga ao expositor por cada mil exibições do anúncio [14]. Neste modelo apenas conta o número de vezes que o anúncio foi carregado e disponibilizado a utilizadores da página em que o anúncio está a ser exposto, não havendo qualquer tipo de retorno de informação nem nenhuma garantia para o anunciante.

14B2.2.2 – Cost per Click (CPC)

Este modelo de pagamento, conhecido também como Pay per Click (PPC), surgiu mais tarde que o CPM e veio substituí-lo como modelo de pagamento predominante para publicidade na Web. Se for este o método de pagamento adoptado, o anunciante paga por cada click no anúncio colocado no website do expositor, ou seja, por cada vez que um utilizador carrega na publicidade. Desta forma o anunciante apenas paga quando um utilizador demonstra interesse na publicidade exposta e assim este modelo oferece mais garantias aos anunciantes do que o CPM.

15B2.2.3 – Cost per Action (CPA)

Este é o modelo de pagamento que oferece melhores garantias ao anunciante uma vez que é ele que escolhe uma determinada acção que o utilizador deverá executar para que a transacção seja válida, ou seja, o anunciante apenas paga ao expositor quando um utilizador, depois de clicar na publicidade, efectua uma determinada acção no website do anunciante. Esta acção poderá ser uma compra, um registo de utilizador, o preenchimento de um formulário, etc. Do ponto de vista do anunciante este método garante o melhor retorno do investimento, uma vez que só paga quando foi atingido o objectivo que definiu. Pelo

8 Publicidade na Web

contrário, para o expositor e para uma eventual agência publicitária que possa estar envolvida, este é um modelo arriscado uma vez que o obriga a tomar o encargo de manter o anúncio disponível no seu website obtendo apenas retorno financeiro quando um utilizador efectua a acção definida no contracto e não quando o anúncio é visualizado ou mesmo quando utilizadores clicam na publicidade. Dentro deste modelo de pagamento podemos encontrar variantes como o Cost per Conversion e o Cost per Engagement.

2.3 – Click Fraud

Actualmente o modelo de pagamento CPC é largamente oferecido por agências de publicidade tais como a Google e a Yahoo!. Estas empresas lideram o mercado [15] e oferecem opções de CPC baseadas em palavras-chave ou em conteúdos [14], tomando partido da sua condição de motores de busca para apresentar os resultados dos seus clientes em primeiro lugar nas respostas às buscas efectuadas. Embora este modelo de pagamento seja muito popular apresenta a fragilidade de apenas poder ser avaliado recorrendo ao Click-Through Rate. Como já foi apontado anteriormente este método de avaliação apenas contabiliza o número de utilizadores que clicaram num anúncio e, desta forma, não permite obter informação sobre se o utilizador irá ou não comprar o produto anunciado. Por outras palavras, uma vez que o esforço do utilizador é mínimo não se pode concluir que exista em todos os casos um verdadeiro interesse no produto. A Click Fraud advém desta falta de capacidade para diferenciar os cliques de utilizadores que estão interessados no produto, que são cliques válidos e que deverão ser pagos pelo anunciante, dos cliquem gerados por utilizadores que não estão interessados no produto anunciado, cliques inválidos que não são uma resposta à publicidade nem trazem nenhum tipo de lucro ao anunciante e por isso não deverão ser pagos.

Click Fraud é a geração de cliques, de utilizadores reais ou artificialmente gerados empregando meios tecnológicos como scripts ou outro software, que abusam do modelo de pagamento de publicidade CPC uma vez que têm o propósito de aumentar a contagem de cliques e os correspondentes custos para o anunciante, sem qualquer interesse no produto publicitado, o que é considerado crime. A interligação entre a motivação com que os cliques são feitos e a detecção de Click Fraud é muito forte. Se em alguns casos é fácil perceber que um clique é válido, quando por exemplo origina uma compra ou registo, em outros casos torna-se muito difícil ou até mesmo impossível determinar com que intenção foi efectuado através dos meios disponíveis [14]. Deve-se salientar ainda a existência de várias formas de gerar cliques fraudulentos. De facto são os cliques gerados através de programas de computador, como os Botnets, ou scripts que causam maior preocupação e prejuízo no mercado uma vez que podem facilmente ser utilizados para gerar um grande número de cliques. Um utilizador humano está muito mais limitado e apenas consegue produzir um número bastante reduzido de cliques num dado intervalo de tempo. No entanto, existem

9

ainda outras abordagens para a geração de cliques como as Click Farms, grupos de utilizadores que se organizam com a intenção de gerar cliques fraudulentos em determinadas publicidades, ou ainda os chamados Affiliate Programs, websites que pagam aos seus membros para fazer cliques em anúncios pré-escolhidos.

Para evitar a detecção, os utilizadores que praticam Click Fraud alteram o maior número possível de parâmetros nos seus sistemas operativos, browsers, etc, que sabem ser possível analisar no lado dos servidores. Deste modo, torna-se manifesta a vantagem que um sistema de identificação de utilizadores que possibilite o seu reconhecimento ao longo do tempo, mesmo em situações não triviais, traz para a identificação de cliques fraudulentos.

2.4 – AuditService

Como já foi indicado anteriormente, o trabalho descrito neste documento foi realizado segundo proposta da AuditMark e, deste modo, a solução do problema abordado teve que ser desenvolvida de forma a ficar integrada no serviço de auditoria que a empresa vinha a desenvolver. O AuditService é a plataforma de auditoria de tráfego Web da AuditMark, através da qual se procura medir a qualidade do tráfego auditado. Embora este serviço ainda estivesse em desenvolvimento, a sua arquitectura encontrava-se já bem definida. Ao longo deste trabalho, procurou-se sempre minimizar as alterações no AuditService e aproveitar ao máximo os componentes já implementados. Para que se compreenda a arquitectura da solução é necessário perceber primeiro todo o serviço que a rodeia e onde ela tinha que ficar integrada. No entanto, uma vez que as tecnologias utilizadas e arquitectura do serviço são confidenciais, procurou-se manter a apresentação da arquitectura do AuditService o mais simples possível, evitando-se deliberadamente todos os detalhes e componentes não relacionados com o trabalho. O objectivo desta secção é que o leitor consiga compreender o fluxo dos dados através do serviço e as principais funcionalidades de cada componente no seu percurso.

A auditoria de tráfego Web envolve o manuseamento e processamento de grandes quantidades de informação. Esta foi uma das principais preocupações que influenciaram o desenvolvimento do AuditService. Para que se conseguisse uma plataforma escalável, que não estivesse sujeita a quebras de desempenho quando submetida a grandes quantidades de dados, foi desenhado um sistema modular e distribuído. Os vários componentes que formam o AuditService podem ser executados em máquinas diferentes e podem ser utilizadas múltiplas instâncias de cada componente obtendo-se desta forma um sistema muito flexível.

O AuditService está dividido em três módulos principais: a camada de recolha de dados, a camada Audit-PI e a camada de processamento de dados. A arquitectura da plataforma pode ser observada na 12 0HFigura 2.1, onde são representadas as várias camadas e os seus principais

10 Publicidade na Web

Figura 2.1 - Arquitectura do AuditService

16B2.4.1 – Camada de recolha de dados

Nesta camada, chamada Data-Collection Layer, encontram-se todos os componentes responsáveis por recolher a informação de tráfego Web que será posteriormente auditada.

JavaScript Interaction Code (JIC) — O JIC é um mecanismo de recolha de dados de navegação Web para fins de auditoria. Todos os dados que a AuditMark utiliza nas suas auditorias, necessários para cada técnica e funcionalidade implementada, é extraído através do JIC. Tem este nome uma vez que se trata efectivamente de uma interacção entre os browsers dos utilizadores Web que visitam os websites auditados e o sistema de auditoria, coordenada por código JavaScript. O código está repartido em vários ficheiros, sendo executado em várias rondas, cada uma retornando a informação recolhida até ao momento e que pode ser utilizada nas rondas posteriores. Para aplicar este mecanismo a qualquer website é apenas necessário incluir nas páginas auditadas uma chamada ao ficheiro Javascript que contém a primeira ronda do JIC que se encontra armazenado num servidor da AuditMark. O resto do processo ocorre dinamicamente, com o código JavaScript de cada ronda a ser gerada por PHP5_{, utilizando a informação recolhida nas rondas anteriores.}

Uma vez que é executado no browser do cliente o código fica exposto. Este problema de segurança foi solucionado com o desenvolvimento de uma ferramenta de ofuscação de código JavaScript, proprietária da AuditMark, que visa ocultar o JIC e dificultar a aplicação de técnicas de reverse-engineering [17]. Procurou-se que todo o processo de recolha de dados seja imperceptível para os utilizadores das páginas auditadas.

5 PHP: Hypertext Preprocessor [16], é uma linguagem de scripting amplamente divulgada que foi criada especialmente para desenvolvimento de aplicações Web, podendo ser embebida em HTML.

11

As técnicas usadas para recolher os dados e transmiti-los para o AuditService são apresentadas juntamente com o levantamento de técnicas utilizadas para User Tracking. Uma análise mais detalhada da arquitectura do JIC é apresentada na Secção 5.2.1, uma vez que parte da solução implementada neste trabalho a reaproveitou e expandiu.

Server Data-Collector (SDC) — A única funcionalidade do SDC é recolher todos os dados que o JIC extrai e armazená-los em ficheiros binários. Estes ficheiros, os logs SDC, contêm toda a informação necessária à auditoria do tráfego Web, podendo ser considerados como a matéria-prima do AuditService. Este componente foi implementado entre o JIC e os servidores Web que tratam dos pedidos de acesso ao código do JIC, originados nas páginas auditadas. Na verdade, o SDC foi desenvolvido como um módulo de filtragem para esses servidores, ficando quer os servidores, quer o filtro, implementados com o Nginx [18].

Data Packager (DP) — O DP é um componente, implementado em Java, responsável por consumir os ficheiros binários que o SDC produz. Os dados armazenados nos logs SDC são lidos e encapsulados em objectos Java que são depois transmitidos, através de ligações Java RMI, à camada seguinte do AuditService.

2.4.2 – Camada Audit-PI

Constituindo o core do serviço, a Audit-PI Layer, engloba funções de acesso ao sistema de bases de dados distribuídas, orquestração de processos, sistemas de filas, escalonador de eventos, etc. Aqui é realizada a gestão do processamento de dados e do data-flow entre os restantes componentes. Apenas alguns dos componentes desta camada são brevemente descritos uma vez que a lógica de gestão do serviço não se encontra relacionada com o trabalho aqui descrito.

Data-Collection Interface (DCI) — Este componente recebe os dados provenientes da camada de recolha de dados, enviados pelo DP, e tem como sua principal função inseri-los no sistema de base de dados e alertar os restantes componentes do AuditService da chegada de dados novos. Para proceder à inserção dos dados o DCI recorre a um conjunto de stored procedures desenhadas para o efeito e que integram a Data-Access API.

Data Processing Orchestrator (DPO) — Como o nome indica, este componente assume a tarefa de orquestrar todo o processo de processamento dos dados para auditar. O DPO interpreta ficheiros XML, com a descrição das tarefas que devem ser executadas e da ordem de execução, e, quando alertado pelo DCI da chegada de novos dados, desencadeia o processamento dos dados instanciando cada um dos métodos necessários ordenadamente.

12 Publicidade na Web

Distributed Database Abstraction Interface (DDBA) — A arquitectura do sistema de bases de dados utilizada pela AuditMark na sua plataforma de serviço de auditoria não é muito detalhada neste trabalho. Este componente tem como objectivo isolar os restantes componentes do AuditService do modelo de arquitectura adoptado. A abordagem tomada foi a implementação de um proxy de ligações a bases de dados PostGreSQL [19], utilizando PL/Proxy, e realizar a abstracção ao nível das stored procedures. Desta forma, ao nível aplicacional, é necessário apenas proceder à invocação das stored procedures, não se reflectindo no código a arquitectura empregada.

Data Access API — Este componente procura esconder a arquitectura do sistema de base de dados do AuditService. Os restantes componentes que necessitam comunicar com as bases de dados, invocam as stored procedures que constituem a Data Access API e apenas têm a percepção da abstracção do sistema, não sabem qual a base de dados física onde os dados estão a ser armazenados ou de onde estão a ser lidos. Grande parte da lógica de segmentação dos dados está aqui implementada, sem que isso seja perceptível para os programadores das aplicações.

17B2.4.3 – Camada de processamento de dados

Esta camada contém todos os métodos de processamento dos dados auditados e outras tarefas relacionadas com o serviço, tais como a facturação.

Data Processing Plugins (DPPs) — Cada uma das tarefas, ou métodos, de processamento dos dados auditados encontra-se implementada na forma de um DPP. São estes plugins que o DPO instancia segundo a informação contida nos ficheiros descritores (Job.xml). Cada DPP é responsável pelo acesso aos dados a auditar, pelo seu processamento e pelo armazenamento dos resultados no sistema de base de dados. Esta comunicação com as bases de dados, específica de cada DPP, é incluída na Data Access API.

Percebe-se desde já que a solução deste trabalho é transversal ao AuditService, desde a extracção da informação de cada utilizador que visita as páginas auditada até ao processamento dos dados recolhidos, passando ainda pela sua segmentação e comunicação com o sistema de base de dados.

13

Capítulo 3

7B

User Tracking

Neste capítulo são introduzidas técnicas que permitem recolher informação sobre os utilizadores e que pode depois ser usada, directamente ou depois de submetida a tratamento, com o objectivo de identificar cada utilizador.

3.1 – Introdução

Para realizar user tracking existem muitos tipos de técnicas diferentes, cada uma utilizando métodos distintos e explorando diferentes abordagens. Dependendo da técnica, as informações obtidas podem contribuir para a identificação de diferentes parâmetros, isto é, embora sejam pertinentes para o trabalho a realizar, nem todas as técnicas permitem identificar o utilizador directamente. Algumas técnicas possibilitam a recolha de informações sobre a máquina do utilizador ou sobre o browser. Desta forma, enumeramos as técnicas de acordo com o parâmetro que podem identificar.

3.2 – Identificação do Utilizador

As técnicas descritas nesta secção procuram identificar directamente cada utilizador, independentemente da máquina ou do browser utilizado.

Autenticação — O método mais fiável para determinar univocamente a identidade de um

utilizador é a autenticação. Para muitos serviços, como por exemplo o de e-mail, sites de compra e venda ou leilões online, sites de redes sociais e fóruns, é necessário que cada utilizador se autentique para aceder à sua conta, geralmente através de um nome de utilizador e uma palavra-passe. Do lado do servidor é possível a identificação do utilizador juntando o seu nome de utilizador único ao registo de todos os pedidos recebidos [9,10,20].

14 User Tracking

No entanto, e no contexto do projecto desenvolvido, é muito penoso para o utilizador o registo na primeira visita e a autenticação a cada nova visita, principalmente tendo em conta que, no contexto deste trabalho, são abrangidos sites que procuram atrair novos clientes através de publicidade online. Se o registo no website for obrigatório isso pode ser visto pelo utilizador como um custo e a probabilidade de voltar atrás e procurar resposta em sites semelhantes na concorrência, que não façam a mesma exigência, é muito grande [8]. Ainda assim, a autenticação não garante a identificação do utilizador uma vez que é possível que os utilizadores efectuem múltiplos registos, criando a percepção de um número maior de utilizadores.

Análise Comportamental — Outra técnica possível para a caracterização de utilizadores é

a análise comportamental. Este método procura identificar padrões de utilização, particularidades na forma de navegação e interesses do utilizador. Utilizam geralmente técnicas de data mining, nomeadamente machine learning e clustering, para agrupar os utilizadores segundo grupos com características semelhantes [21,22]. Esta técnica é sobretudo utilizada para adaptação dinâmica de conteúdos em sites de acordo com os interesses dos utilizadores, mas o tipo de dados recolhidos não permite identificar cada utilizador univocamente. As características comportamentais dos utilizadores são instáveis e sofrem alterações ao longo do tempo, como seria de esperar. Esta técnica não contribui para o objectivo pretendido neste trabalho, não permitindo obter informação única e constante para cada utilizador.

3.3 – Identificação do Browser

Nesta secção são introduzidas as técnicas que permitem extrair informação do browser do utilizador. Muitas delas utilizam formas de armazenar informação ou correr código localmente no lado do utilizador ou exploram falhas de segurança dos Web browsers. A informação que estas técnicas permitem obter varia consoante o browser, o que não permite a identificação de um utilizador se este mudar de browser nem permite distinguir entre vários utilizadores que partilhem o mesmo browser. Este último caso não se refere a vários utilizadores que partilhem a mesma máquina utilizando, para isso, um sistema de contas de utilizadores, uma vez que, neste caso, o próprio browser teria contas separadas para cada um dos utilizadores. A referência é feita no sentido de evocar uma situação em que vários utilizadores utilizem a mesma conta e o mesmo browser, como será o caso de alguns computadores pessoais em redes familiares ou espaços de aluguer de computadores com acesso à Internet.

Cabeçalho HTTP — É possível obter muita informação sobre o utilizador e sobre as

configurações do seu browser simplesmente registando o conteúdo dos campos presentes nos cabeçalhos dos pacotes HTTP trocados entre o cliente, browser, e o servidor. Nestes campos

15

encontra-se informação geral, como a versão e o tipo de ligação HTTP, mas também informação mais detalhada, como por exemplo o campo de user-agent que define o software usado, a versão e língua, campos que indicam o endereço IP, porto utilizado, informação de cache, etc. Outro campo que é importante mencionar é o referer que indica o URL da página anterior, ou seja, da página onde o utilizador se encontrava antes de clicar no link que o levou até à página actual. Toda esta informação pode ajudar a identificar o browser mais tarde e até permitir o uso de técnicas de identificação mais complexas, por exemplo as baseadas nos tempos de cache ou na estimação de desvios de relógio. O JIC captura todos os dados encapsulados nos pedidos HTTP através da sua filtragem no SDC, ver Secção 2.4.1. Algo importante e que deve ser salientado é que a falsificação dos campos presentes no cabeçalho HTTP não é difícil e deve ser considerada no contexto deste trabalho.

JavaScript — O JavaScript é uma linguagem de programação e não uma técnica de user

tracking. No entanto, pelas suas características e pela forma como pode ser utilizado é muitas vezes utilizado para implementar diversas técnicas e daí a sua importância para este trabalho. O JavaScript tem propriedades bastante peculiares: é uma linguagem interpretada, isto é, o código não necessita ser compilado, é apenas lido pelo interpretador e as operações são executadas. O código JavaScript pode ser embebido directamente no código HTML das páginas, como podemos observar no exemplo de 121HCódigo 3.1. Desta forma, quando um

utilizador descarrega do servidor o código da página, descarrega juntamente com ele o código JavaScript embebido.

Código 3.1 - Exemplo de código JavaScript embebido em HTML

Quando o browser interpreta o HTML de uma determinada página Web, para permitir que o utilizador a visualize, também interpreta o código JavaScript e executa-o. Isto permite correr código directamente no browser do cliente. Algumas aplicações Web, como por exemplo o Gmail6_{, tiram partido desta característica para tornar as interacções com o utilizador mais}

rápidas, conseguindo um tempo de resposta mais curto, processando tudo localmente e enviando apenas os pedidos necessários ao servidor. Outra característica do JavaScript é que

6 Serviço de correio electrónico gratuito que pertence à Google. Website disponível em http://mail.google.com.

<html>

<head><title>simple page</title></head>

<body>

<script type=”text/javascript”>

document.write(‘Hello World!’);

</script>

</body>

</html>

16 User Tracking

permite interacção directa com o DOM, Document Object Model. O DOM é uma forma convencionada de representar objectos, usado em HTML bem como em outras linguagens. Usando JavaScript é possível aceder a toda a informação que nele está armazenada (vários campos com definições do browser e da máquina), detectar eventos (movimentos e cliques do rato, input do teclado) e ainda despoletar eventos (através da detecção de outros eventos que os despoletam ou recorrendo a timers). Esta é uma ferramenta muito poderosa mas não deve ser o único meio utilizado para capturar informação sobre o utilizador uma vez que este pode optar por desligar o JavaScript, isto é, definir no seu browser que o código JavaScript embebido nas páginas HTML não deve ser interpretado. Muitas páginas e serviços disponíveis actualmente na Web funcionam utilizando esta tecnologia e não correm devidamente se o JavaScript for desligado, mesmo assim, o cenário que foi proposto para este trabalho indica claramente que um utilizador que pretenda cometer Click Fraud fará os possíveis para não ser identificado e assim é esperado que, não necessitando de JavaScript para cometer a fraude, o desligue. No entanto, muitos dos serviços de publicidade online actualmente utilizam JavaSript e, nestes casos, para que sejam geradas transacções o JavaScript tem que estar ligado. Uma vez que para a visualização da maior parte da publicidade online é necessário permitir a execução de JavaScript esta foi a linguagem adoptada para programar a ferramenta de extracção de dados da AuditMark, o JIC.

Flash — A abreviatura Flash é utilizada como referência ao Flash Player da Adobe que é

um software que permite criar e reproduzir animações e vídeos. Utilizado juntamente com Web browsers permite correr animações e vídeos em páginas Web. Actualmente o software de reprodução pode já vir incluído em alguns browsers ou está disponibilizado como uma extensão ou plug-in. O Flash suporta uma linguagem de scripting chamada ActionScript que se assemelha ao JavaScript em termos de capacidades. Ambas as linguagens descendem de uma outra linguagem a que se deu o nome de ECMAScript. Tal como o JavaScript, o Flash corre no browser do utilizador. Usando o Flash tem-se acesso a algumas configurações da máquina do cliente, sobretudo relacionadas com definições necessárias para serviços multimédia como existência de camera ou microfone, capacidades de reprodução de vídeo e áudio, etc. Estes dados são capturado pelo JIC através da utilização de uma ronda que inclui um objecto Flash. O Flash tem ainda, por omissão, permissões de escrita no disco de ficheiros de pequeno tamanho: os Local Shared Objects (LSO). Este mecanismo pode ser aproveitado para implementar cookies Flash.

Cookies — Desde a sua invenção os cookies estiveram sempre envolvidos em grande polémica e controvérsia. Muitas vezes a discussão gerada em torno desta técnica era baseada em conceitos errados; acreditava-se que através de cookies se podia aceder remotamente a informação privada, introduzir vírus e código malicioso nas máquinas, etc. Cookies são

17

pequenos ficheiros de texto, únicos, criados por servidores Web e que são enviados e armazenados localmente nos discos dos clientes [23]. Quando um utilizador visita pela primeira vez um website, envia um pedido ao servidor respectivo. Na resposta ao pedido, o servidor pode incluir o cookie que ficará então armazenado na máquina do utilizador. Enquanto o cookie não expirar ou for apagado, o browser do utilizador enviará uma cópia em cada novo pedido a ser feito aquele servidor.

Existem diversas funcionalidades que podem ser implementadas recorrendo a cookies. A utilização mais simples é a de identificação de um browser ao longo de várias visitas, podendo-se contar quantas visitas foram efectuadas e quando, a partir da data nos registos do servidor Web. Salienta-se o facto de que apenas é possível identificar o browser. Mesmo que seja utilizado na mesma máquina, outro browser irá armazenar noutro local os seus próprios cookies para cada website visitado que os implemente. Uma outra aplicação consiste em usar cookies para armazenar informação sobre as preferências do utilizador naquele site, ou armazenar itens vistos ou adicionados num carrinho de compras em sites de vendas online. De qualquer forma, toda a informação armazenada nos cookies provém do servidor ou foi cedida pelo utilizador, ou seja, a única forma de conterem informação privada do utilizador é se este a fornecer [24].

Os cookies tradicionalmente são implementados em HTTP, passando a ser incluidos no cabeçalho HTTP de todos os pedidos que sejam feitos ao servidor que os originou. Existe a opção em cada browser para não os aceitar e, de facto, sabe-se que muitos utilizadores rejeitam ou apagam regularmente os seus cookies [6,11,23,24,25]. De facto, devemos considerar que a aplicação de cookies, para ter sucesso, exige a cooperação da parte do utilizador [9]. No entanto, existe a também possibilidade de criar mecanismos semelhantes recorrendo a outras técnicas como o JavaScript ou mesmo o Flash, utilizando os LSO como já foi mencionado anteriormente. A este tipo de cookie dá-se o nome de cookies de aplicação e, desta forma, mesmo que o utilizador não aceite os cookies HTTP, poderá descarregar e guardar ficheiros semelhantes se tiver permitido o uso de scripts. Os cookies de aplicação apresentam algumas vantagens, em termos de potencial para user-tracking, relativamente aos cookies HTTP originais: permitem geralmente mais espaço de armazenamento em disco, são mais difíceis de apagar e, uma vez que são menos conhecidos para os utilizadores, a percentagem de utilizadores que os elimina frequentemente é menor. Uma outra vantagem advém da forma como os browsers correm estas aplicações: geralmente são instalados plugins para cada browser que fazem a ligação com a aplicação que é partilhada por todos os browsers. Desta forma, para um dado domínio, o mesmo cookie de aplicação pode ser acedido, mesmo que o utilizador mude de browser.

18 User Tracking

Cada website apenas tem acesso aos cookies enviados pelo seu próprio servidor, segundo a política da mesma origem7_{. No entanto, existe ainda uma abordagem diferente que utiliza}

cookies para seguir utilizadores não apenas nas visitas a um único site mas um conjunto de sites: cookies de terceiros. Traduzido do termo em Inglês third party cookies, este método tira partido da forma como as páginas são construídas em HTML, utilizando Web bugs para redireccionar o utilizador, colocando-o, sem que ele se aperceba, a enviar um pedido a outro servidor diferente. Este método será explicado com mais detalhe na próxima secção. Este tipo de cookies é bem conhecido e existe a possibilidade de os desligar independentemente dos cookies normais, gerados pelos servidores da própria página. Esta é uma opção que um grande número de utilizadores toma [10].

Web bugs — Quando o browser de um utilizador descarrega uma página para visualização

são feitos um conjunto de pedidos ao servidor, um para cada elemento da página. No HTML é definido a localização de cada elemento. Através da introdução de algumas linhas de código numa página Web é possível levar o utilizador a fazer um pedido para outro servidor.

Este método é muito relevante para este trabalho uma vez que permite, com a introdução de pouco código nos servidores de uma empresa auditada, obrigar todos os utilizadores que visitem as suas páginas a fazerem pelo menos um pedido por cada página, a um servidor controlado pela empresa auditora. A 122HFigura 3.1 representa um esquema do método em que

se pode ver o conteúdo HTML a ser pedido ao servidor do domínio e um outro conteúdo embebido no HTML a ser pedido ao servidor de monitorização.

Figura 3.1 - Método de redireccionar utilizador

Geralmente, um Web bug é implementado como uma imagem transparente ou da cor do fundo da página, de tamanho 1x1 pixel, de forma a não ser visível para o utilizador. Um exemplo desta implementação pode ser observado no exemplo de 123HCódigo 3.2. Embora fora do

contexto deste trabalho, é importante referir que os Web bugs podem ser utilizados da

7 A Política da mesma origem exige que apenas o website que armazena informação no browser pode mais tarde ler ou modificar essa informação [7].

19

mesma forma em mensagens de correio electrónico e até em documentos do Microsoft Office [23]. Outro facto importante é que é possível utilizar o mesmo método descrito para os Web bugs implementados com imagens para outros tipos de elementos, que podem estar presentes em páginas Web. Por exemplo, pode ser chamado código JavaScript que se encontra em outro servidor que não o servidor que controla as páginas que estamos a visitar. Existem ainda outros métodos que permitem redireccionar o utilizador para que ele faça pedidos a outros servidores; por exemplo, através de JavaSript é possível abrir uma janela pop-up para uma página guardada noutro servidor e fechar a janela imediatamente, sem que seja perceptível para o utilizador [7].

Código 3.2 - Exemplo de um Web Bug em HTML

Como já foi mencionado anteriormente, é exequível a utilização conjunta de Web bugs e cookies. O método é simples mas bastante eficaz: o website visitado pode estar a implementar cookies, o que atribui ao utilizador um identificador único para aquele domínio. Quando o Web bug redirecciona o utilizador para fazer um pedido ao servidor de monitorização também este pode retornar um cookie na resposta que será guardado de forma independente, uma vez que o domínio é diferente. Assim são distribuídos os chamados third party cookies. Os Web bugs permitem ainda centralizar o esforço de identificação de utilizadores. Imaginando um cenário em que se quer monitorizar todos os utilizadores que visualizam páginas num conjunto de websites, podemos colocar Web bugs em cada uma das páginas de cada servidor direccionado para o mesmo servidor de monitorização. Este método permite a manutenção do cookie do servidor de monitorização uma vez que o domínio é sempre o mesmo. Assim, todas as ligações para este servidor levarão acopladas este cookie, permitindo a identificação de um utilizador único em todos os domínios monitorizados. Poderão ainda ser implementadas relações entre os cookies dos servidores das páginas e o cookie do servidor de monitorização para que se, alguns deles forem apagados, se consiga continuar a identificar o mesmo utilizador e repor os valores dos cookies já definidos para ele [9,10].

Parâmetros passados por URL — Existe ainda outra técnica que pode tornar o uso de Web

bugs mais eficaz em termos de capacidade de identificação de utilizadores: pode ser passada informação para o servidor de monitorização no próprio URL [23]. No exemplo de Código 3.2, é visível a inclusão no URL de um campo de origem (src=mysite), possivelmente para que o

servidor de monitorização possa registar em que website o utilizador está, um campo com um identificador único (id=123) e ainda um campo com a hora actual (time=<Time>). Mais, uma

vez que estes parâmetros são incluídos pelo código do domínio do site que o utilizador está a <img src=”http://www.tracking.com/src=mysite;id=123;time=<Time>” width=”1” heigth=”1” border=”0”>