ads:
Vivian Cremer Kalempa
Especificando Privacidade em
Ambientes de Computa¸c˜ao Ub´ıqua
Florian´opolis – SC
Fevereiro / 2009
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROGRAMA DE P
´
OS-GRADUAC¸
˜
AO EM
CI
ˆ
ENCIA DA COMPUTAC¸
˜
AO
Vivian Cremer Kalempa
Especificando Privacidade em Ambientes de
Computa¸c˜ao Ub´ıqua
Disserta¸c˜ao submetida `a Universidade Federal de Santa Catarina como
parte dos requisitos para a obten¸c˜ao do grau de Mestre em Ciˆencia da
Computa¸c˜ao
Prof. Dr. Jo˜ao Bosco Mangueira Sobral
Florian´opolis, fevereiro de 2009
ads:
ESPECIFICANDO PRIVACIDADE EM
AMBIENTES DE COMPUTAC¸
˜
AO UB
´
IQUA
Vivian Cremer Kalempa
Esta Disserta¸c˜ao foi julgada adequada para a obten¸c˜ao do t´ıtulo de
Mestre em Ciˆencia da Computa¸c˜ao na
´
Area de Concentra¸c˜ao Sistemas
de Computa¸c˜ao e aprovada em sua forma final pelo Programa de P´os-
Gradua¸c˜ao em Ciˆencia da Computa¸c˜ao.
Prof. Dr. Frank Augusto Siqueira
Coordenador do PPGCC
Banca Examinadora
Prof. Dr. Jo˜ao Bosco Mangueira Sobral
Orientador
Prof. Dr. Guilherme Horta Travassos
Prof. Dr. Antˆonio Augusto Medeiros Fr¨ohlich
Prof. Dr. Carlos Montez
i
Dedico a Deus, que sempre iluminou
meu caminho;
aos meus pais,
Carlos Alberto Cremer e
Romilda Teresinha Cremer,
e ao meu marido,
Saulo Eduardo Kalempa,
que sempre me deram amor,
carinho e palavras de incentivo.
ii
Agradecimentos
Agrade¸co a Deus por ter me dado toda a sabedoria e tudo mais que foi necess´ario
para a minha caminhada e para a realiza¸c˜ao deste trabalho.
Agrade¸co aos meus pais pelo incentivo, carinho e amor espontˆaneos que tanto
me fizeram bem no tempo em que estive longe de casa.
Agrade¸co ao meu marido pela compreens˜ao dos mais de 200 km de distˆancia
para a realiza¸c˜ao deste trabalho e por entender o que significa, para mim, ter um
mestrado. Agrade¸co tamb´em pelo apoio, tanto no momento da mudan¸ca, quanto
nos momentos dif´ıceis que encontrei fora de casa, e que ele sempre com palavras de
incentivo me deu for¸cas para continuar.
Agrade¸co ao professor Jo˜ao Bosco pela orienta¸c˜ao e amizade.
Agrade¸co ao PPGCC - Programa de P´os-Gradua¸c˜ao em Ciˆencia da Computa¸c˜ao
e `a UFSC - Universidade Federal de Santa Catarina por disponibilizarem o curso e
a estrutura para o desenvolvimento do trabalho.
Agrade¸co ao Jeferson e ao Lucas pela amizade e contribui¸c˜oes para o meu tra-
balho. Agrade¸co tamb´em a Pˆamela e a Rebeca pelos momentos em que passamos
juntas na casa amarela.
Agrade¸co a professora Daniela Barreiro Claro pelo apoio, incentivo, e por acre-
ditar na minha capacidade.
Agrade¸co ao Rodrigo Campiolo pelas sugest˜oes e cr´ıticas sobre a minha dis-
serta¸c˜ao, o que contribuiu para o resultado final obtido.
Agrade¸co a aten¸c˜ao dos demais professores do curso, que atrav´es das disciplinas
ministradas, tiveram influˆencia no trabalho realizado.
iii
“Os que esperam no Senhor renovam as suas for¸cas,
sobem com asas como ´aguias,
correm e n˜ao se cansam,
caminham e n˜ao se fatigam.”
Isa´ıas 40:31
iv
Resumo
A computa¸c˜ao ub´ıqua provˆe ambientes com servi¸cos e dispositivos interconec-
tados que promovem a integra¸c˜ao de infra-estrutura digital na vida das pessoas.
Por´em, por haver muitos empecilhos t´ecnicos que impedem que a computa¸c˜ao ub´ıqua
se torne realidade, o foco da pesquisa atual acaba voltando-se, na maioria dos casos,
para os assuntos t´ecnicos como, por exemplo, como conectar novos dispositivos e
construir aplica¸c˜oes ´uteis para melhorar a funcionalidade desses ambientes. Con-
tudo, assuntos como seguran¸ca e privacidade ainda s˜ao pouco tratados. Al´em disso,
nesses ambientes torna-se dif´ıcil a separa¸c˜ao entre a seguran¸ca f´ısica e a seguran¸ca
digital. Assim, fica claro que o paradigma da computa¸c˜ao ub´ıqua introduz novas
vulnerabilidades e exposi¸c˜oes aos usu´arios dos seus ambientes, mostrando que as
tecnologias, pol´ıticas e leis existentes n˜ao est˜ao adequadas para lidar com essas no-
vas situa¸c˜oes. Nesta disserta¸c˜ao, os desafios em garantir privacidade em ambientes
de compu ta¸c˜ao ub´ıqua s˜ao explorados. Al´em disso, um metamodelo que endere¸ca
alguns destes desafios ´e descrito, apresentado e simulado na ferramenta Opnet.
Palavras-chave: Computa¸c˜ao Ub´ıqua. Privacidade. Simula¸c˜ao.
v
Abstract
The ubiquitous computing provides environments with services and devices in-
terconnected that promote integration of digital infrastructure in the people’s life.
However, once there are many technical difficulties that do not allow ubiquitous
computing come true, the focus of the existing researches, in most of the cases, goes
into technical issues, for example, how to connect new devices and to build useful
applications to improve the functionality of those environments. Nevertheless, issues
like security and privacy, are not always approached. Besides, in those environments
the distinction of physical and digital security becomes difficult. Thus, the para-
digm of the ubiquitous computing intro du ces new vulnerabilities and exposures to
the users of its environments, showing that the technologies, policies and existing
laws are not adapted to work with those new situations. In this dissertation, the
challenges on guaranteeing privacy in environments of ubiquitous computing are
explored. In addiction, a metamodel that addresses some of these challenges it is
described, presented and simulated in the Opnet tool.
Keywords: Ubiquitous computing. Privacy. Simulation.
vi
Sum´ario
Lista de Figuras p. x
Lista de Tabelas p. xiii
1 Introdu¸c˜ao p. 1
1.1 Hist´orico da Pesquisa sobre Privacidade em Ambientes Ub´ıquos . p. 3
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 4
1.3 Publica¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 6
1.4 Estrutura da Disserta¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . p. 6
2 Computa¸c˜ao Ub´ıqua p. 7
2.1 Contextualiza¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 7
2.1.1 Defini¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 8
2.1.2 Caracter´ısticas . . . . . . . . . . . . . . . . . . . . . . . . p. 9
2.1.2.1 Invisibilidade . . . . . . . . . . . . . . . . . . . . p. 10
2.1.2.2 Consciˆencia de Contexto . . . . . . . . . . . . . . p. 10
2.1.2.3 Privacidade e Confian¸ca . . . . . . . . . . . . . . p. 10
2.1.3 Desafios . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11
2.1.3.1 O Entendimento do Contexto . . . . . . . . . . . p. 11
2.1.3.2 Intera¸c˜ao com Ambientes . . . . . . . . . . . . . p. 12
2.1.3.3 Privacidade e Confian¸ca . . . . . . . . . . . . . . p. 12
2.1.3.4 Comunica¸c˜oes sem fio . . . . . . . . . . . . . . . p. 12
vii
2.1.3.5 Auto-configura¸c˜ao . . . . . . . . . . . . . . . . . p. 13
2.2 Considera¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13
3 Privacidade p. 14
3.1 Hist´oria da Privacidade . . . . . . . . . . . . . . . . . . . . . . . . p. 14
3.2 Defini¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
3.3 Classifica¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
3.4 Legisla¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
3.5 Privacidade em Computa¸c˜ao Ub´ıqua . . . . . . . . . . . . . . . . p. 20
3.5.1 Servi¸cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
3.5.1.1 Servi¸co de identifica¸c˜ao de produtos . . . . . . . p. 20
3.5.1.2 Servi¸co de alerta de proximidade . . . . . . . . . p. 20
3.5.1.3 Servi¸co de propaganda . . . . . . . . . . . . . . . p. 21
3.5.2 Restri¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
3.5.3 Raz˜oes para invas˜ao de privacidade . . . . . . . . . . . . . p. 22
3.5.4 M´etodos de prote¸c˜ao `a privacidade . . . . . . . . . . . . . p. 23
3.5.5 M´etodos para a regulamenta¸c˜ao de privacidade . . . . . . p. 24
3.5.6 Algumas solu¸c˜oes t´ecnicas para prote¸c˜ao `a privacidade . . p. 25
3.5.6.1 Bancos de dados de Hippocrates . . . . . . . . . p. 26
3.5.6.2 Codifica¸c˜ao da pol´ıtica de privacidade . . . . . . p. 27
3.5.6.3 Anonimato . . . . . . . . . . . . . . . . . . . . . p. 28
3.5.6.4 Minera¸c˜ao de dados com a op¸c˜ao de preservar a
privacidade . . . . . . . . . . . . . . . . . . . . . p. 28
3.5.6.5 Compartilhamento de informa¸c˜oes por reposit´orios
privados . . . . . . . . . . . . . . . . . . . . . . . p. 29
3.5.6.6 Considera¸c˜oes . . . . . . . . . . . . . . . . . . . . p. 29
viii
3.5.7 Implica¸c˜oes sociais da computa¸c˜ao ub´ıqua . . . . . . . . . p. 29
3.6 Considera¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
4 Especificando Privacidade p. 32
4.1 Componentes da Especifica¸c˜ao . . . . . . . . . . . . . . . . . . . . p. 32
4.2 Defini¸c˜oes axiom´aticas, tipos b´asicos e tipos livres . . . . . . . . . p. 34
4.3 Pessoas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36
4.4 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
4.5 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39
4.6 Privacidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40
4.7 Considera¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
5 Prova de Conceito: Cen´ario de um Shopping Center p. 45
5.1 O Cen´ario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45
5.2 Problema espec´ıfico . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
5.3 Modelo e arquitetura do ambiente . . . . . . . . . . . . . . . . . . p. 48
5.4 Modelo da pol´ıtica de privacidade . . . . . . . . . . . . . . . . . . p. 49
5.5 Entendendo os protocolos . . . . . . . . . . . . . . . . . . . . . . p. 51
5.5.1 Entrada de um cliente/usu´ario . . . . . . . . . . . . . . . . p. 51
5.5.2 Detec¸c˜ao de um cliente por um sensor . . . . . . . . . . . p. 52
5.5.3 Cliente finaliza a comunica¸c˜ao com um dispositivo . . . . . p. 52
5.6 Aplicando o modelo a um problema . . . . . . . . . . . . . . . . . p. 52
5.7 Simulando o cen´ario . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
5.7.1 O simulador Opnet . . . . . . . . . . . . . . . . . . . . . . p. 54
5.7.2 O ambiente representado no Opnet . . . . . . . . . . . . . p. 57
5.7.2.1 Pacotes para troca de mensagens . . . . . . . . . p. 58
ix
5.7.2.2 Modelo do n´o sensor E/S . . . . . . . . . . . . . p. 65
5.7.2.3 Modelo do n´o de usu´arios . . . . . . . . . . . . . p. 67
5.7.2.4 Modelo do n´o servidor . . . . . . . . . . . . . . . p. 71
5.7.2.5 Modelo do n´o de sensores das livrarias . . . . . . p. 74
5.7.2.6 Zona de mixagem . . . . . . . . . . . . . . . . . . p. 75
5.7.3 Executando uma simula¸c˜ao . . . . . . . . . . . . . . . . . p. 77
5.7.4 Resultados e an´alise da simula¸c˜ao . . . . . . . . . . . . . . p. 82
5.7.4.1 M´etricas de Anonimato . . . . . . . . . . . . . . p. 82
5.7.4.2 Cen´arios para simula¸c˜ao . . . . . . . . . . . . . . p. 84
5.8 Considera¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 89
6 Conclus˜oes e Trabalhos Futuros p. 90
6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 91
Referˆencias p. 92
Apˆendice A -- Especifica¸c˜ao do Modelo em Object-Z p. 96
Apˆendice B -- Classes de Privacidade p. 112
Apˆendice C -- Aplica¸c˜ao da Especifica¸c˜ao p. 116
x
Lista de Figuras
3.1 Os quatro m´etodos de regulamenta¸c˜ao de um indiv´ıduo I (BERES-
FORD, 2005). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
4.1 Principais componentes da especifica¸c˜ao . . . . . . . . . . . . . . p. 33
4.2 Caracter´ısticas da classe Person . . . . . . . . . . . . . . . . . . . p. 36
4.3 Caracter´ısticas da classe Entity . . . . . . . . . . . . . . . . . . . p. 37
4.4 Caracter´ısticas da classe Sensor . . . . . . . . . . . . . . . . . . . p. 38
4.5 Caracter´ısticas da classe Actuator . . . . . . . . . . . . . . . . . . p. 38
4.6 Caracter´ısticas da classe Device . . . . . . . . . . . . . . . . . . . p. 39
4.7 Caracter´ısticas da classe Environment . . . . . . . . . . . . . . . . p. 40
4.8 Classes da especifica¸c˜ao de privacidade . . . . . . . . . . . . . . . p. 41
4.9 Caracter´ısticas da classe Service . . . . . . . . . . . . . . . . . . . p. 41
4.10 Caracter´ısticas da classe PrivacyPolicy . . . . . . . . . . . . . . . p. 42
4.11 Caracter´ısticas da classe Profile . . . . . . . . . . . . . . . . . . . p. 43
5.1 Ilustra¸c˜ao do cen´ario shopping. Fonte: (CAMPIOLO, 2005) . . . . p. 46
5.2 Perfil A fornecido por Alice . . . . . . . . . . . . . . . . . . . . . p. 47
5.3 Pol´ıtica de privacidade para o servi¸co de propaganda . . . . . . . p. 47
5.4 Perfil B inferido pelo sistema . . . . . . . . . . . . . . . . . . . . . p. 48
5.5 Ilustra¸c˜ao do cen´ario shopping. Fonte: (CAMPIOLO, 2005) . . . . p. 50
5.6 Pol´ıtica de privacidade que d´a permiss˜ao de um servi¸co `a duas lojas,
permitindo que para as lojas desconhecidas o usu´ario seja consultado p. 50
5.7 Pol´ıtica de privacidade que d´a permiss˜ao de um servi¸co `a duas lojas,
mas que n˜ao d´a permiss˜ao `a nenhuma outra . . . . . . . . . . . . p. 51
xi
5.8 Pol´ıtica de privacidade que d´a sempre permiss˜ao de um servi¸co `a
qualquer loja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
5.9 Pol´ıtica de privacidade que n˜ao d´a acesso de nenhum servi¸co `a
nenhuma loja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
5.10 Perfil A fornecido por Alice . . . . . . . . . . . . . . . . . . . . . p. 53
5.11 A estrutura hier´arquica dos modelos no Opnet . . . . . . . . . . . p. 55
5.12 Ciclo de Modelagem e Simula¸c˜ao do Opnet baseada em (CHANG,
1999) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56
5.13 Cen´ario do shopping no Opnet. . . . . . . . . . . . . . . . . . . . p. 57
5.14 Pacote de requisi¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . p. 59
5.15 Pacote de perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 60
5.16 Campo personalProperties do pacote perfil. . . . . . . . . . . . p . 60
5.17 Pacote de pseudˆonimo. . . . . . . . . . . . . . . . . . . . . . . . . p. 62
5.18 Pacote de pseudˆonimo novo. . . . . . . . . . . . . . . . . . . . . . p. 63
5.19 Pacote de mixagem. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63
5.20 Pacote de pol´ıticas de servi¸co do usu´ario. . . . . . . . . . . . . . . p. 64
5.21 Pacote de propaganda. . . . . . . . . . . . . . . . . . . . . . . . . p. 64
5.22 Modelo do n´o sensor E/S. . . . . . . . . . . . . . . . . . . . . . . p. 65
5.23 Modelo de processo do n´o sensor E/S. . . . . . . . . . . . . . . . . p. 66
5.24 Estrutura Address. . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
5.25 Atributos do n´o sensor E/S. . . . . . . . . . . . . . . . . . . . . . p. 67
5.26 Fun¸c˜ao make
and send packet() do processo send do sensor IO. p. 67
5.27 Modelo do n´o de usu´arios. . . . . . . . . . . . . . . . . . . . . . . p. 68
5.28 Modelo de processo do n´o de usu´arios. . . . . . . . . . . . . . . . p. 69
5.29 Header Block do processo de usu´ario, onde s˜ao definidas as condi¸c˜oes
das transi¸c˜oes de estado. . . . . . . . . . . . . . . . . . . . . . . . p. 70
xii
5.30 Defini¸c˜ao da fun¸c˜ao rrcv
1(). . . . . . . . . . . . . . . . . . . . . p. 70
5.31 Defini¸c˜ao da fun¸c˜ao le solicitacao e envia pseudonimo ao sensor(). p. 71
5.32 Modelo do n´o servidor. . . . . . . . . . . . . . . . . . . . . . . . . p. 72
5.33 Header block do n´o servidor, onde ´e definida a sua lista de usu´arios. p. 72
5.34 Modelo de processo do n´o servidor. . . . . . . . . . . . . . . . . . p. 73
5.35 Defini¸c˜ao da fun¸c˜ao cria pseudonimo(). . . . . . . . . . . . . . p. 74
5.36 Modelo do n´o de sensores das livrarias. . . . . . . . . . . . . . . . p. 75
5.37 Modelo de processo do n´o de sensores das livrarias. . . . . . . . . p. 76
5.38 Modelo de n´o do sensor de mixagem. . . . . . . . . . . . . . . . . p. 76
5.39 Modelo de processo do sensor de mixagem. . . . . . . . . . . . . . p. 77
5.40 Cen´ario de simula¸c˜ao com apenas um usu´ario. . . . . . . . . . . . p. 78
5.41 Atributos de Alice. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78
5.42 Atributos do Bookstore L Sensor. . . . . . . . . . . . . . . . . p. 79
5.43 Primeira etapa da simula¸c˜ao. . . . . . . . . . . . . . . . . . . . . p. 80
5.44 Segunda etapa da simula¸c˜ao. . . . . . . . . . . . . . . . . . . . . . p. 80
5.45 Terceira etapa da simula¸c˜ao. . . . . . . . . . . . . . . . . . . . . . p. 81
5.46 Quarta etapa da simula¸c˜ao. . . . . . . . . . . . . . . . . . . . . . p. 81
5.47 Quinta etapa da simula¸c˜ao. . . . . . . . . . . . . . . . . . . . . . p. 82
5.48 Shopping com 50 clientes. . . . . . . . . . . . . . . . . . . . . . . p. 85
5.49 Shopping com 100 clientes. . . . . . . . . . . . . . . . . . . . . . . p. 85
5.50 Shopping com 300 clientes. . . . . . . . . . . . . . . . . . . . . . . p. 86
5.51 Grau de anonimato com N = 50. . . . . . . . . . . . . . . . . . . p. 88
5.52 Grau de anonimato com N = 100. . . . . . . . . . . . . . . . . . . p. 88
5.53 Grau de anonimato com N = 300. . . . . . . . . . . . . . . . . . . p. 88
5.54 Comparativo entre os 3 cen´arios. . . . . . . . . . . . . . . . . . . p. 89
xiii
Lista de Tabelas
5.1 Atributo Personal Properties de Alice . . . . . . . . . . . . . . p. 77
5.2 Atributos do Bookstore L Sensor . . . . . . . . . . . . . . . . . p. 79
5.3 Atributos do Bookstore M Sensor . . . . . . . . . . . . . . . . p. 79
5.4 Situa¸c˜oes para a simula¸c˜ao. . . . . . . . . . . . . . . . . . . . . . p. 86
5.5 Grau de anonimato obtido para os cen´arios . . . . . . . . . . . . . p. 87
1
1 Introdu¸c˜ao
Este trabalho versa sobre modelagem de sistemas na ´area de computa¸c˜ao ub´ıqua.
Mais precisamente, cont´em um estud o sobre a quest˜ao da privacidade, como forma
de estender o trabalho em (CAMPIOLO, 2005), o qual trata da formaliza¸c˜ao de um
metamodelo a ser utilizado como base para a constru¸c˜ao de sistemas ub´ıquos. A ex-
tens˜ao proposta aborda a quest˜ao da privacidade no n´ıvel de usu´ario de um sistema.
A computa¸c˜ao ub´ıqua promete um mundo onde dispositivos computacionais
embutidos no ambiente tˆem a capacidade de conhecer o contexto das atividades
dos usu´arios e prover servi¸cos baseados nesse contexto conhecido (WEISER, 1991).
Contudo, as mesmas caracter´ısticas que fazem os ambientes ub´ıquos convenientes e
poderosos, os fazem tamb´em vulner´aveis para novos tipos de ataque `a seguran¸ca e
privacidade.
Problemas de seguran¸ca n˜ao s˜ao tratados neste trabalho, enquanto quest˜oes de
privacidade, dizem respeito `a coleta de dados nesses ambientes, sobre os usu´arios, e
podem ser compartilhados sem o consentimento do mesmo.
Exemplos de informa¸c˜oes que podem ser consideradas confidenciais s˜ao: idade,
press˜ao sangu´ınea, doen¸ca espec´ıfica ou informa¸c˜ao sobre os interesses, objetivos e
planos do usu´ario, as quais podem ser exploradas por intrusos ou at´e mesmo por
gerenciadores de sistemas interessados em localizar ou espiar eletronicamente deter-
minados usu´arios. Dessa forma, o sistema inteiro se torna um sistema de vigilˆancia
distribu´ıdo que pode capturar muita informa¸c˜ao sobre os usu´arios. Logo, os meca-
nismos de seguran¸ca tradicionais podem n˜ao prover garantias adequadas para lidar
com essas novas situa¸c˜oes.
Alguns requisitos devem ser levados em considera¸c˜ao para que um ambiente
de computa¸c˜ao ub´ıqua seja considerado confi´avel (FAHRMAIR; SITOU; SPANFELNER,
2005):
2
(1) Prote¸c˜ao contra abuso: deve existir uma possibilidade do usu´ario expressar
condi¸c˜oes e restri¸c˜oes para o uso de dados de contexto. Isto inclui a identi-
fica¸c˜ao de servi¸cos;
(2) Identifica¸c˜ao de conjunto de dados clandestinos: se um servi¸co puder evi-
tar a prote¸c˜ao `a privacidade, deve haver uma possibilidade em identificar esse
servi¸co. Este item n˜ao ser´a abordado com mais detalhes nessa disserta¸c˜ao;
(3) Leis: sob certas circunstˆancias as regras podem prover u ma seguran¸ca adicio-
nal;
(4) Facilidade de uso: um sistema de prote¸c˜ao com seguran¸ca m´axima, mas com
uma alta complexidade de controle ´e in´util.
Al´em disso, pode-se associar o sucesso da computa¸c˜ao ub´ıqua `a vontade dos
usu´arios em aceitar e gerenciar o risco de privacidade em compartilhar suas in-
forma¸c˜oes pessoais neste novo mundo digital.
Assim, o gerenciamento de informa¸c˜ao pessoal em ambient es inteligentes se ca-
racteriza como um desafio de pesquisa social e t´ecnico mu ito importante. Os usu´arios
determinam qual informa¸c˜ao eles desejam compartilhar, baseados no contexto atual
e na identidade dos receptores da sua informa¸c˜ao (LEDERER; DEY; MANKOFF, 2002).
Ainda, as tecnologias que protegem a privacidade dos usu´arios devem permitir que
eles controlem efetivamente as suas informa¸c˜oes, sem carreg´a-los com avalia¸c˜oes ex-
cessivas ou muitas intera¸c˜oes com o ambiente, visando esse objetivo. Os usu´arios
tamb´em devem ter a possibilidade de compartilhar o m´ınimo poss´ıvel de informa¸c˜ao
para alcan¸car os seus objetivos, usar pseudˆonimos e ter anonimato sempre que
poss´ıvel (BERENDT; GUNTHER; SPIEKERMANN, 2005).
Por outro lado, permitir que os usu´arios sejam anˆonimos em ambientes inte-
ligentes, melhora a sua privacidade, mas pode tornar os sistemas adapt´aveis ao
usu´ario menos efetivos (KOBSA; SCHRECK, 2003). O uso de pseudˆonimos foi iden-
tificado como um m´etodo de permitir aos usu´arios usar os sistemas adapt´aveis,
mantendo um certo anonimato. Esta id´eia busca permitir aos usu´arios a utiliza¸c˜ao
de pseudˆonimos, que de certa maneira, ir´a proteger a sua privacidade de qualquer
ataque de minera¸c˜ao de dados, e pode ser usada em conjunto com outras formas
de seguran¸ca como, por exemplo, a criptografia e zonas de mixagem (BERESFORD,
2005).
3
1.1 Hist´orico da Pesquisa sobre Privacidade em
Ambientes Ub´ıquos
Essa se¸c˜ao apresenta alguns dos principais trabalhos desenvolvidos na ´area da
computa¸c˜ao ub´ıqua com foco na privacidade desses ambientes. Al´em disso, as prin-
cipais caracter´ısticas e problem´aticas nesses trabalhos s˜ao apresentados.
Em (JIANG; LANDAY, 2002a) ´e apresentado o Modelo de Espa¸co de Informa¸c˜ao,
o qual organiza informa¸c˜oes, recursos e servi¸cos em torno de fatores contextuais,
relevantes `a privacidade do usu´ario. Os espa¸cos de informa¸c˜ao s˜ao delimitados e
possuem respons´aveis que determinam suas permiss˜oes. Dessa forma, os espa¸cos
de informa¸c˜ao fornecem informa¸c˜oes, recursos, servi¸cos e gerenciamento de auto-
riza¸c˜oes em sistemas sens´ıveis ao contexto. Para o controle de privacidade, um
espa¸co de informa¸c˜ao age como um gatilho para for¸car as permiss˜oes definidas pelos
respons´aveis daquele espa¸co a serem cumpridas. Este modelo p rotege a informa¸c˜ao
sens´ıvel por meio do controle d a informa¸c˜ao pelos respons´aveis pelo espa¸co. Por´em,
essa confian¸ca nos respons´aveis pelo espa¸co se torna um ponto de poss´ıvel falha neste
modelo, como tamb´em o componente de software que processa esse mecanismo pode
ser problem´atico para sistemas de grande escala descentralizado.
J´a em (CAMPBELL et al., 2002), o Mist ´e apresentado como uma infra-estrutura
de comunica¸c˜ao que preserva a privacidade em ambientes de computa¸c˜ao ub´ıqua. O
Mist faz a separa¸c˜ao entre localiza¸c˜ao e identidade, permitindo, assim, que as entida-
des autorizadas do sistema tenham acesso aos servi¸cos, protegendo a sua privacidade
de localiza¸c˜ao. O Mist consiste em uma hierarquia de roteadores que formam uma
´unica rede que, dessa forma, fornece uma comunica¸c˜ao privada. Al´em disso, o Mist
utiliza criptografia de chave p´ublica e disp˜oe de um n´ıvel customiz´avel de priva-
cidade. Essa customiza¸c˜ao ´e ´util, por´em, ´e definida pelo usu´ario e se o usu´ario
escolher uma conex˜ao com um roteador em um n´ıvel mais baixo na hierarquia, a
sua privacidade tamb´em estar´a menos protegida.
Em (LANGHEINRICH, 2002), o sistema pawS (Privacy Awareness System) pro-
porciona aos usu´arios ferramentas que os auxiliam a proteger sua pr´opria privacidade
e fazer com que os outros tamb´em a respeitem. Esse sistema ´e baseado em normas
sociais e legais ao inv´es de somente ter a prote¸c˜ao t´ecnica. Em um sistema com pawS,
quando um usu´ario entrar em um ambiente no qual h´a servi¸cos coletando dados, um
4
dispositivo de privacidade anuncia as pol´ıticas de privacidade de cada servi¸co no
ambiente. O proxy de privacidade do usu´ario confere essas pol´ıticas com rela¸c˜ao
`as preferˆencias de privacidade do usu´ario e, se as pol´ıticas estiverem de acordo, os
servi¸cos podem coletar informa¸c˜oes e os usu´arios podem utilizar os servi¸cos. Se as
pol´ıticas n˜ao estiverem de acordo, o sistema notifica o usu´ario que pode optar por
n˜ao utilizar o servi¸co em quest˜ao ou deixar a ´area na qual a coleta de informa¸c˜ao ´e
feita.
Por fim, em (CHENG; ZHANG; TAN, 2005) ´e apresentado o PSIUM (Privacy Sensi-
tive Information Diluting Mechanism) como um modelo que tenta eliminar o excesso
de dados do usu´ario utilizado pelos provedores de servi¸co. Para isso, o modelo re-
duz a utilidade dos dados coletados pelos provedores de servi¸co sem afetar o servi¸co
provido aos usu´arios. Um d ispositivo com o PSIUM habilitado envia m´ultiplas
mensagens de requisi¸c˜ao de servi¸co baseadas em localiza¸c˜ao ao provedor de servi¸co.
Todas, menos uma dessas mensagens cont´em a verdadeira localiza¸c˜ao. No retorno
da informa¸c˜ao de servi¸co o dispositivo sabe utilizar a informa¸c˜ao correta e fazˆe-la
dispon´ıvel ao usu´ario. O PSIUM mant´em falsos dados que parecem verdadeiros, de
forma que se torna dif´ıcil de distingui-los dos verdadeiros. Esses falsos dados s˜ao
criados a partir de localiza¸c˜oes previamente utilizadas pelo usu´ario. Dessa forma,
o PSIUM tem como ponto forte a preven¸c˜ao ao abuso da utiliza¸c˜ao dos dados dos
usu´arios por um provedor de servi¸co, sem reduzir a qualidade do servi¸co. Seu ponto
fraco ´e que aumenta o custo da obten¸c˜ao dos resultados pelo provedor de servi¸co, j´a
que o n´umero de consultas aumenta.
Analisando os trabalhos existentes, voltados para a privacidade em ambientes
de computa¸c˜ao ub´ıqua, pode-se perceber que v´arias abordagens s˜ao utilizadas a fim
de preencher essa lacuna. Por´em, nenhuma dessas abordagens define formalmente
os aspectos dos ambientes ub´ıquos, principalmente o da privacidade. Al´em disso,
algumas t´ecnicas aparentam ser muito complexas ao tentar manter a privacidade
dos usu´arios dos seus ambientes, ou mesmo ineficientes.
1.2 Objetivos
O objetivo geral dessa disserta¸c˜ao ´e na especifica¸c˜ao da privacidade para am-
bientes ub´ıquos. Para isso, o aspecto de privacidade em ambientes de computa¸c˜ao
5
ub´ıqua ´e especificado formalmente, caracterizando a extens˜ao ao trabalho em (CAM-
PIOLO, 2005), usando-se a linguagem do OBJECT Z (DUKE et al., 1991). Al´em disso,
um cen´ario foi modelado com base no metamodelo, o qual foi simulado, suportando
uma m´etrica (DIAZ et al., 2002) para medir o grau de privacidade.
Os objetivos espec´ıficos s˜ao:
• permitir que o metamodelo desenvolvido em (CAMPIOLO, 2005) permane¸ca
gen´erico, por´em estendido com a caracter´ıstica de privacidade;
• permitir a utiliza¸c˜ao desse metamodelo em simula¸c˜oes de ambientes de com-
puta¸c˜ao ub´ıqua;
• desenvolver a especifica¸c˜ao de privacidade com base nos conceitos de ano-
nimato (PFITZMANN; K¨oHNTOPP, 2001), u so de pseudˆonimos (BERESFORD;
STAJANO, 2004), perfil de preferˆencias do usu´ario (LEDERER; DEY; MANKOFF,
2002) e zonas de mixagem (BERESFORD, 2005);
• simular um cen´ario de ambiente ub´ıquo com base na especifica¸c˜ao desenvol-
vida, utilizando-se a ferramenta Opnet
1
;
• utilizar a entropia (DIAZ et al., 2002) como m´etrica para a simula¸c˜ao realizada.
Neste trabalho n˜ao ser´a abordado o problema de seguran¸ca em computa¸c˜ao
ub´ıqua, como t´ecnicas de criptografia ou como evitar ataques.
´
E apresentada uma
abordagem baseada em confian¸ca, com a necessidade de que sejam feitas algumas
extens˜oes abordando seguran¸ca. Ou seja, o objetivo desse trabalho ´e na privacidade
das pessoas, e n˜ao na seguran¸ca dos sistemas que essas pessoas utilizam. Assim, ´e
importante destacar u ma distin¸c˜ao entre seguran¸ca e privacidade feita por Saltzer e
Schroeder (SALTZER; SCHROEDER, 1975), onde a seguran¸ca pode ser entendida como
os mecanismos e t´ecnicas que controlam quem pode usar determinado computador,
ou modificar as informa¸c˜oes armazenadas por ele. E a privacidade ´e tida como a
habilidade de um indiv´ıdu o (ou organiza¸c˜ao) decidir se, quando, e para quem a
informa¸c˜ao pessoal (ou organizacional) pode ser cedida.
1
O Opnet ´e um simulador que permite projetar e estudar redes de comunica¸c˜ao, dispositivos,
protocolos e aplica¸c˜ao.
6
1.3 Publica¸c˜oes
Um trabalho inicial sobre a ´area de computa¸c˜ao ub´ıqua e uma pr´evia desse
metamodelo foi apresentada em (CAMPIOLO; SOBRAL, 2005) e como contribui¸c˜ao
do trabalho em quest˜ao, o artigo “On Modeling for Pervasive Computing Environ-
ments”, foi publicado no The 10th ACM International Symposium on Modeling,
Analysis and Simulation of Wireless and Mobile Systems (MSWIN), em outubro
de 2007. Nesse artigo ´e apresentado o metamodelo para ambientes de computa¸c˜ao
ub´ıqua estendido com a caracter´ıstica de privacidade.
1.4 Estrutura da Disserta¸c˜ao
No que segue, o cap´ıtulo 2 apresenta as principais caracter´ısticas e desafios da
´area de computa¸c˜ao ub´ıqua. No cap´ıtulo 3, s˜ao discutidos os principais aspectos
em torno da privacidade em ambientes ub´ıquos, assim como os principais motivos
para a invas˜ao da privacidade e algumas solu¸c˜oes t´ecnicas para prote¸c˜ao `a priva-
cidade. No cap´ıtulo 4, ´e apresentado o metamodelo d esenvolvido por (CAMPIOLO,
2005), para descrever ambientes ub´ıquos, o qual foi estendido para atender as ca-
racter´ısticas necess´arias para garantir privacidade nesses ambientes. No cap´ıtulo 5
´e apresentado um estudo de caso, que foi desenvolvido utilizando-se o metamodelo
proposto e simulado na ferramenta Opnet. No cap´ıtulo 6, as conclus˜oes e dire¸c˜oes
para trabalhos futuros.
7
2 Computa¸c˜ao Ub´ıqua
Tecnologias, tais como, redes sem fio e dispositivos m´oveis, vem tomando cada
vez espa¸co no dia-a-dia das pessoas, tanto em espa¸cos p´ublicos, empresas, quanto
em suas casas. Seja atrav´es dos handhelds, telefones celulares, ou at´e mesmo das
cˆameras digitais, o fato ´e que as pessoas est˜ao cada vez mais acostumadas com estes
dispositivos para a realiza¸c˜ao das suas tarefas cotidianas. Um ambiente que cont´em
um, ou v´arios destes dispositivos embutidos ou m´oveis, pode ser considerado um
ambiente de computa¸c˜ao ub´ıqua.
O objetivo deste cap´ıtulo ´e apresentar um breve hist´orico sobre a ´area de com-
puta¸c˜ao ub´ıqua; mostrar os principais impactos que esta tecnologia tem na forma
como as pessoas trabalham, aprendem, interagem e se entretem. Al´em disso, este
cap´ıtulo aborda as principais caracter´ısticas de um ambiente de computa¸c˜ao ub´ıqua
e alguns desafios.
2.1 Contextualiza¸c˜ao
A hist´oria da computa¸c˜ao ub´ıqua originou-se em 1987 no Laborat´orio de Eletrˆonica
e Imagem da Xerox, no Centro de Pesquisa em Palo Alto. A id´eia da pesquisa era
distribuir dispositivos ub´ıquos com capacidades de computa¸c˜ao pelo ambiente, mas
de forma invis´ıvel, ou seja, sem que a presen¸ca deles fosse notada. Essa nova abor-
dagem de computa¸c˜ao, denominada Ubiquitous Computing ou, computa¸c˜ao ub´ıqua,
era diferente da forma de computa¸c˜ao existente na ´epoca, que tinha a rela¸c˜ao “uma
pessoa - um computador”(WEISER; GOLD; BROWN, 1999).
A partir disso, em 1988 foi fundado o Programa de Computa¸c˜ao Ub´ıqua no
Laborat´orio de Ciˆencia da Computa¸c˜ao (CSL). O objetivo principal deste programa
era estudar o que estava errado com o computador pessoal: muito complexo e dif´ıcil
8
de ser usado; e isolado de outras pessoas e out ras atividades.
O pr ojeto de computa¸c˜ao ub´ıqua do Centro de Pesquisa em Palo Alto teve como
principal contribui¸c˜ao a cria¸c˜ao de uma nova ´area da computa¸c˜ao: a computa¸c˜ao
ub´ıqua. Al´em disso, resultou em muitos artigos, dentre eles, destaca-se o artigo The
Computer for the 21th Century (WEISER, 1991) de Mark Weiser, onde ele imaginou
um mundo saturado de computa¸c˜ao para auxiliar as pessoas, sem ser intrusiva.
Al´em de todas as contribui¸c˜oes de v´arios pesquisadores, a cria¸c˜ao de eventos
cient´ıficos espec´ıficos, tais como o Ubicomp
1
da ACM, e o surgimento de revistas
espec´ıficas, com destaque a IEEE Pervasive Computing
2
, impulsionaram a evolu¸c˜ao
desta nova ´area da Ciˆencia da Computa¸c˜ao (CAMPIOLO, 2005).
2.1.1 Defini¸c˜oes
Computa¸c˜ao ub´ıqua (tamb´em chamada de pervasive computing (SATYANARAYA-
NAN, 2001)), de acordo com a vis˜ao de Mark Weiser (WEISER, 1991), ´e a computa¸c˜ao
que desaparece, que faz parte da vida cotidiana sem ser percebida.
Ainda, segundo Debashis Saha e Amitava Mukherjee (SAHA; MUKHERJEE, 2003),
computa¸c˜ao ub´ıqua ´e a computa¸c˜ao que torna a vida cotidiana mais simples por meio
de ambientes digitais que s˜ao sens´ıveis, adapt´aveis, e pr´o-ativos `as necessidades dos
humanos. Muito mais que computa¸c˜ao m´ovel, esta tecnologia mudar´a a natureza
da computa¸c˜ao, permitindo que a maioria dos objetos encontrados na vida di´aria
sejam “atentos”, interagindo com usu´arios no mundo f´ısico e virtual.
A computa¸c˜ao ub´ıqua pode ser considerada como um desafio que afeta toda a
ciˆencia da computa¸c˜ao, pois ela faz com que conceitos como sistemas de compu-
tadores e de hardware sejam repensados; faz pensar como criar sistemas ub´ıquos
complexos e como entender ambientes que s˜ao suportados pela computa¸c˜ao ub´ıqua.
H´a muito ainda que ser pesquisado e experimentado nesta ´area da ciˆencia da com-
puta¸c˜ao para que todos os conceitos relacionados a computa¸c˜ao ub´ıqua se tornem
realidade.
Na se¸c˜ao 2.1.2 s˜ao apresentadas as principais caracter´ısticas de um ambiente de
computa¸c˜ao ub´ıqua para melhor entendimento da se¸c˜ao 2.1.3, que apresenta alguns
1
http://ubicomp.org
2
http://www.computer.org/pervasive
9
dos desafios desta ´area da computa¸c˜ao.
2.1.2 Caracter´ısticas
Como visto na se¸c˜ao anterior, o prop´osito da computa¸c˜ao ub´ıqua ´e servir as
pessoas, ou seja, auxili´a-las em suas tarefas, sem que muitas vezes, elas p ercebam.
Por´em, antes da realiza¸c˜ao de um profundo estudo de computa¸c˜ao ub´ıqua, ´e ne-
cess´ario conhecer quais as qualidades que caracterizam um sistema de computa¸c˜ao
ub´ıqua. Conforme (CHALMERS et al., 2006), um sistema de computa¸c˜ao ub´ıqua d eve
demonstrar as seguintes qualidades:
• deve ser fluido, ou seja, sua estrutura varia a curto prazo e evolui a longo
prazo;
• cada entidade n˜ao-humana tem suas a¸c˜oes expressas vagamente ou formal-
mente;
• ´e parcialmente autˆonomo: algumas de suas a¸c˜oes s˜ao determinadas por seu
prop´osito e sua experiˆencia interativa, ao inv´es de por invoca¸c˜ao de uma enti-
dade em um n´ıvel mais alto;
• ´e reflexivo: um subsistema pode relatar sua experiˆencia a um sistema de n´ıvel
mais alto (talvez para uma pessoa), para permitir interven¸c˜ao ou orienta¸c˜ao;
• ´e confi´avel: se comportar´a de uma maneira segura e n˜ao afetar´a adversamente
a informa¸c˜ao, outros componentes do sistema ou as pessoas;
• ´e sustent´avel: seus componentes (hardware e software) s˜ao projetados e cons-
tru´ıdos para ter longa dura¸c˜ao, manu ten¸c˜ao eficiente e efetiva e eventual de-
composi¸c˜ao, enquanto seu impacto no ambiente ´e apropriado mas, m´ınimo;
• ´e eficiente: qualquer atraso em seu desempenho ´e toler´avel;
• ´e escal´avel: seus subsistemas podem ter diferen¸ca em tamanho, contudo, uma
poss´ıvel complexidade intrat´avel ser´a evitada aplicando os mesmos princ´ıpios
de projeto e m´etodos de an´alise a cada n´ıvel.
Obviamente, estas devem ser um pequeno conjunto de qualidades que um sis-
tema de computa¸c˜ao ub´ıqua deve apresentar. Al´em dessas qualidades, caracter´ısticas
10
tais como: invisibilidade, consciˆencia de contexto, privacidade e confian¸ca, tamb´em
se destacam quando o assunto ´e computa¸c˜ao ub´ıqua.
2.1.2.1 Invisibilidade
Um sistema apresenta a caracter´ıstica de invisibilidade quando requer inter-
ven¸c˜ao humana m´ınima. De acordo com (WEISER, 1991), ´e o desaparecimento com-
pleto da tecnologia da consciˆencia de um usu´ario. Ou seja, a distra¸c˜ao m´ınima do
usu´ario.
A interven¸c˜ao humana pode ser necess´aria quando, por exemplo, os ambientes
inteligentes n˜ao satisfizerem automaticamente a sua expectativa. Tal interven¸c˜ao
tamb´em poderia ser parte de um ciclo de aprendizagem cont´ınuo do ambiente (SAHA;
MUKHERJEE, 2003). Por´em, satisfazer continuamente as expectativas do usu´ario
exige do ambiente e dos objetos uma atualiza¸c˜ao sem provocar a distra¸c˜ao dos
usu´arios em um n´ıvel consciente.
2.1.2.2 Consciˆencia de Contexto
Consciˆencia de contexto ´e uma caracter´ıstica intr´ınseca de ambientes inteligen-
tes, que torna um sistema de computa¸c˜ao ub´ıqua invasivo o m´ınimo poss´ıvel. Ou
seja, o sistema ´e capaz de conhecer o estado do usu´ario e do seu ambiente, e alterar
seu comportamento baseado nesta informa¸c˜ao (SATYANARAYANAN, 2001).
O principal desafio ´e como o sistema obt´em as informa¸c˜oes necess´arias para
tornar-se consciente de contexto. As informa¸c˜oes que definem a consciˆencia de con-
texto d evem ser precisas; caso contr´ario, podem confundir ou podem intrometer na
experiˆencia do usu´ario (SAHA; MUKHERJEE, 2003).
2.1.2.3 Privacidade e Confian¸ca
A privacidade ´e um grande problema em sistemas distribu´ıdos e na computa¸c˜ao
m´ovel, e ´e um assunto ainda mais complicado na computa¸c˜ao ub´ıqua. Atrav´es de um
sistema de computa¸c˜ao ub´ıqua ´e poss´ıvel obter informa¸c˜oes sobre os movimentos de
um determinado usu´ario, padr˜oes de comportamento e h´abitos. Estas informa¸c˜oes
s˜ao importantes para que o sistema apresente consciˆencia de contexto, por´em, a
menos que o uso desta informa¸c˜ao seja estritamente controlado, estas informa¸c˜oes
11
podem ser utilizadas para v´arias finalidades, por exemplo, para chantagear o usu´ario
(SATYANARAYANAN, 2001).
Tamb´em ´e um grande desafio estabelecer confian¸ca em um sistema de com-
puta¸c˜ao ub´ıqua, de modo que este n˜ao seja intrusivo, preservando a caracter´ıstica
de invisibilidade. Os problemas s˜ao como garantir e provar que um ambiente n˜ao
est´a monitorando os usu´arios em todos os lugares e obtendo informa¸c˜oes que n˜ao
lhe foram autorizadas (CAMPIOLO, 2005).
2.1.3 Desafios
Para suprir as necessidades que um sistema de computa¸c˜ao ub´ıqua tem para
atender as suas caracter´ısticas e qualidades ideais, como exposto nas se¸c˜oes ante-
riores, ´e necess´ario ainda vencer muitos dos seus desafios, que impedem que esta
´area da computa¸c˜ao seja atendida por completo. Nesta se¸c˜ao s˜ao apresentados os
principais desafios enumerados por (CHALMERS et al., 2006).
2.1.3.1 O Entendimento do Contexto
O entendimento da natureza das atividades humanas ´e um ramo de pesquisa
muito importante para muitas disciplinas, t ais como, psicologia, sociologia, e er-
gonomia. Essa variedade de perspectivas gera v´arios problemas, visto que, cada
disciplina pode explorar t´aticas diferentes para entender as a¸c˜oes humanas. O en-
tendimento destas diferentes disciplinas ´e utilizado na computa¸c˜ao ub´ıqua com a
finalidade de representar atividades humanas, e pode resultar em um desafio de
multidisciplinaridade significante.
A diversidade de abordagens dentro das ciˆencias humanas e sociais aumenta
a complexidade envolvida. A abordagem de computa¸c˜ao ub´ıqua freq¨uentemente
utiliza os conceitos da sociologia. Dessa forma, a riqueza de intera¸c˜ao humana ´e en-
fatizada mas, tamb´em tende a resistir a representa¸c˜oes mais abstratas d e atividades,
que ´e importante aos desenvolvedores de sistemas de computa¸c˜ao ub´ıqua.
12
2.1.3.2 Intera¸c˜ao com Ambientes
Ambientes de computa¸c˜ao ub´ıqua est˜ao cada vez mais se tornando parte da vida
cotidiana das pessoas. Dessa forma, ´e preciso entender como as pessoas interagem
com eles e como os exploraram.
´
E necess´ario entender tamb´em de que forma a
intera¸c˜ao do usu´ario contribui para a forma¸c˜ao destes ambientes.
As pessoas enfrentam desafios ao tentar estabelecer uma intera¸c˜ao ´util ou agrad´a-
vel com tecnologias de computa¸c˜ao ub´ıqua. Esta intera¸c˜ao precisa ser ajustada com o
contexto, interesse e objetivos dessas pessoas. As capacidades de tecnologias digitais
diferentes, configura¸c˜oes de uso e experiˆencias passadas dos indiv´ıduos agem como
recursos e restri¸c˜oes na forma¸c˜ao desta intera¸c˜ao.
Reduzir estas diversas formas de intera¸c˜ao ´e fundamental e central no projeto
de ambientes ub´ıquos. Um desafio importante para computa¸c˜ao ub´ıqua ´e descobrir
como as pessoas chegam a padr˜oes de intera¸c˜ao que s˜ao produtivos ao inv´es de
problem´aticos.
2.1.3.3 Privacidade e Confian¸ca
Privacidade e confian¸ca ´e uma preocup a¸c˜ao tanto para quem cria ambientes
ub´ıquos, quanto para quem os utiliza. Para que o p´ublico em geral possa confiar
em um ambiente com informa¸c˜ao pessoal, primeiro eles tˆem que considerar que este
ambiente ´e confi´avel.
O problema de como descobrir quais as garantias que s˜ao r equeridas pelas pes-
soas e como estas garantias devem ser providas pela infra-estrutura, se pelo uso das
tecnologias pessoais ou at´e mesmo por uma entidade reguladora, ainda n˜ao possui
solu¸c˜ao, sendo necess´ario a realiza¸c˜ao de pesquisas para suprir essas dificuldades em
ambientes ub´ıquos.
2.1.3.4 Comunica¸c˜oes sem fio
O fato de que dispositivos ub´ıquos ser˜ao incorporados em entidades m´oveis como
pessoas e ve´ıculos, como tamb´em ser˜ao conectados milhares de dispositivos a uma
infra-estrutura, significa dizer que a comunica¸c˜ao sem fio ´e essencial. Por´em, comu-
nica¸c˜oes sem fio requerem freq¨uentemente muito mais energia que outras formas de
13
processamento. H´a muitos padr˜oes diferentes de comunica¸c˜ao sem fio sendo utiliza-
dos em v´arios ambientes, tais como: telefones celulares, Bluetooth, Wi-Fi, Wi-Max,
Zigbee etc.; e cada um com suas p r´oprias tarifas. Os usu´arios m´oveis podem pre-
cisar trocar dados com outros dispositivos com tipos diferentes de comunica¸c˜ao,
dependendo dos seus contextos atuais ou gerenciando custos ou preocupa¸c˜oes com
seguran¸ca e privacidade.
2.1.3.5 Auto-configura¸c˜ao
A escala de sistemas de computa¸c˜ao u b´ıqua demanda sistemas autonˆomicos
(auto-organiza¸c˜ao, auto-gerenciamento e auto-recupera¸c˜ao) para simplificar a ins-
tala¸c˜ao e evolu¸c˜ao de dispositivos, servi¸cos e aplica¸c˜oes. N˜ao ser´a poss´ıvel para os
usu´arios n˜ao-t´ecnicos instalarem software e configurarem milhares de dispositivos
em suas casas, carros e empresas. Por outro lado, se um sistema pode se auto-
configurar, surge o seguinte problema: como um agente (humano ou digital) que
est´a migrando pode descobrir os recursos e servi¸cos dos quais precisa em seu novo
local.
Al´em disso, pode acontecer do sistema ter que ser parcialmente autonˆomico
como, por exemplo, necessitar da interven¸c˜ao humana em circunstˆancias excepcio-
nais, ou quando os usu´arios desejarem intervir nas decis˜oes. Um desafio chave de
projeto ´e permitir uma varia¸c˜ao entre graus diferentes de autonomia, baseado em
uma compreen s˜ao de quando e como envolver as pessoas para adaptar o comporta-
mento.
2.2 Considera¸c˜oes
Esse cap´ıtulo apresentou os principais conceitos inerentes `a ´area da computa¸c˜ao
ub´ıqua, dentre eles, um breve hist´orico, principais caracter´ısticas e desafios, dando
assim, uma vis˜ao geral ao assunto.
O pr´oximo cap´ıtulo discorre sobre o assunto de privacidade em computa¸c˜ao
ub´ıqua. Dentre to das as caracter´ısticas e desafios existentes na ´area de ub´ıqua,
vistos nesse cap´ıtulo, a privacidade ´e considerada uma caracter´ıstica n˜ao somente
desejada, mas essencial para ambientes ub´ıquos e, por isso, abordada com mais
detalhes.
14
3 Privacidade
Atualmente, privacidade ´e um direito de qualquer pessoa, e muitas na¸c˜oes tˆem
em suas constitui¸c˜oes leis que garantem ao cidad˜ao o direito de possu´ı-la. Entretanto,
privacidade n˜ao pode ser apenas garantida por leis, principalmente quando se trata
de dados digitais. Este problema vem sendo ab ordado em computa¸c˜ao h´a algum
tempo e a solu¸c˜ao que tem sido utilizada ´e o uso de criptografia. Essa solu¸c˜ao tem
sido satisfat´oria para o paradigma atual, a computa¸c˜ao pessoal.
A computa¸c˜ao ub´ıqua ´e um novo paradigma onde os ambientes possuem dis-
positivos e sensores computacionais com capacidade de computa¸c˜ao e comunica¸c˜ao.
O usu´ario se comunica com esses ambientes atrav´es de seus dispositivos pessoais e
vice-versa. Em comput a¸c˜ao ub´ıqua, a privacidade ganha novas dimens˜oes, as quais
foram muitas vezes idealizadas por livros e filmes, e que nos tempos atuais, est˜ao se
tornando realidade.
Nesse cap´ıtulo s˜ao apresentadas e discutidas as novas dimens˜oes de privacidade,
no contexto da computa¸c˜ao ub´ıqua, assim como as quest˜oes que est˜ao sendo abor-
dadas pela comunidade cient´ıfica.
3.1 Hist´oria da Privacidade
Como ´e mostrado em (LANGHEINRICH, 2001), a privacidade j´a era um assunto
preocupante no s´eculo 19, quando Samuel Warren e Louis Brandeis escreveram o
artigo “The Right to Privacy”(WARREN; BRANDEIS, 1890), motivados em grande
parte pelo advento da fotografia moderna e pelos novos m´etodos de impress˜ao. Os
autores definiram a privacidade como “o direito de poder ficar sozinho”, como uma
forma de criticar os rep´orteres que tiravam fotos das pessoas sem p erm iss˜ao. Ulti-
mamente a privacidade ´e tida mais como “o direito de selecionar quais informa¸c˜oes
15
pessoais podem ser reveladas e quais pessoas ter˜ao permiss˜ao de receber essas re-
vela¸c˜oes”(WESTIN, 1967).
A privacidade se tornou um assunto importante nos anos 60 quando os governos
descobriram o processamento de dados automatizado como um meio efetivo de ca-
talogar seus cidad˜aos. O exemplo da explora¸c˜ao do nazismo feita sobre os registros
p´ublicos detalhados na Segunda Guerra Mundial (o que facilitava a persegui¸c˜ao `a
popula¸c˜ao judia) fez com que muitas na¸c˜oes europ´eias passassem a criar v´arias leis
de prote¸c˜ao aos dados para prevenir qualquer abuso de t al informa¸c˜ao armazenada
(LANGHEINRICH, 2001). Ultimamente, a prote¸c˜ao `a privacidade se destaca como o
uso de informa¸c˜oes pessoais relativas ao sigilo banc´ario, segredos de justi¸ca, dados
da ´area m´edica, mas um assunto preocupante devido ao uso crescente da Internet,
vem sendo as transa¸c˜oes eletrˆonicas, como tamb´em informa¸c˜oes pessoais divulgadas
inadequadamente.
Os objetivos da prote¸c˜ao `a privacidade foram sendo alterados conforme os desen-
volvimentos de novas tecnologias. Podem ser encontrados, na literatura, assuntos
sobre privacidade desde 1361, quando o Justices of the Peace Act na Inglaterra
estabeleceu o arresto quanto ao ato de curiosidades sobre informa¸c˜oes alheias e
intromiss˜oes, estabelecendo assim a primeira no¸c˜ao de privacidade nos meios de
comunica¸c˜ao (MICHAEL, 1994). No s´eculo 18, apareceu a primeira no¸c˜ao de pri-
vacidade territorial (LANGHEINRICH, 2001), onde foi exemplificada uma situa¸c˜ao
que demonstra que, em nenhuma situa¸c˜ao, um cidad˜ao po d e ultrapassar os limites
de uma moradia. Com o uso crescente do sistema telefˆonico nos anos 30, houve
uma grande preocupa¸c˜ao com a legalidade de interceptores de conversas telefˆonicas
utilizados pelo governo dos Estados Unidos (LANGHEINRICH, 2001). A privaci-
dade pessoal foi violada seriamente, e ap´os alguns anos, na d´ecada de 40, quando
a lideran¸ca do nazismo decidiu conduzir a esteriliza¸c˜ao compuls´oria, assim como
experiˆencias m´edicas imorais, o abuso quanto `a privacidade apareceu novamente.
Dos anos 60 em d iante, o uso crescente do processamento de dados eletrˆonicos deu
origem `a privacidade da informa¸c˜ao (LANGHEINRICH, 2001).
Essas categorias de privacidade est˜ao estabelecidas quanto aos seus aspectos
legais em todo o mundo, os quais s˜ao freq¨uentemente definidos como direitos cons-
titucionais. Por´em, ´e a privacidade de informa¸c˜ao que d´a origem `a maioria dos
desafios atualmente (BHASKAR; AHAMED, 2007). Embora as leis de privacidade de
16
informa¸c˜ao tivessem origem h´a mais de 30 anos, o progresso r´apido da tecnologia,
como o sucesso comercial da World Wide Web, d esafia a legisla¸c˜ao que foi inventada
no tempo onde se utilizava mainframes (IBM 360, IBM 370, IBM 3090, IBM 4341,
Burroughs 3700, Burroughs 6700) e cart˜oes perfurados (IBM 029) (LANGHEINRICH,
2001).
3.2 Defini¸c˜ao
Alan F. Westin afirma que “nenhuma defini¸c˜ao de p rivacidade ´e poss´ıvel, porque
assuntos de privacidade s˜ao quest˜oes de valores, interesses e poder”(WESTIN, 1995)
(WESTIN, 1967).
Dessa forma, n˜ao ´e poss´ıvel elaborar uma defini¸c˜ao ´unica para privacidade que
seja capaz de expressar seu significado nas mais diversas situa¸c˜oes em que ´e consi-
derada. Na maioria dos casos em que se discutem aspectos relativos `a privacidade,
as discuss˜oes se encaminham para a vis˜ao relativa da situa¸c˜ao e dos indiv´ıduos en-
volvidos.
A partir dessa afirma¸c˜ao, ´e poss´ıvel isolar duas vari´aveis essenciais para que se
tenha uma quest˜ao de privacidade: o indiv´ıduo e a informa¸c˜ao (SALTZER; SCHRO-
EDER, 1975). Indiv´ıduo ´e a pessoa que se sentiu lesada tendo algo que ´e privado
(particular) tornado p´ublico ou acessado por algu´em sem o seu consentimento. In-
forma¸c˜ao ´e uma abstra¸c˜ao gen´erica para expressar algo que ´e tido como privado
para um indiv´ıduo.
3.3 Classifica¸c˜ao
Conforme j´a introduzida na se¸c˜ao 3.1 e oficializada pela A Global Internet Liberty
Campaign (GILC, 2008), uma organiza¸c˜ao formada por diversas outras organiza¸c˜oes
envolvidas com direitos humanos e de liberdade, s˜ao quatro as grandes categorias
de privacidade:
Privacidade de informa¸c˜ao: refere-se ao gerenciamento da informa¸c˜ao pessoal,
tais como registros m´edicos e in forma¸c˜ao de cr´edito;
17
Privacidade corporal: refere-se `a prote¸c˜ao f´ısica das pessoas contra procedimen-
tos invasivos, tais como testes de drogas;
Privacidade de comunica¸c˜ao: refere-se `a prote¸c˜ao e privacidade dos meios de
comunica¸c˜ao, tais como o correio convencional, o correio eletrˆonico e o telefone;
Privacidade territorial: refere-se `a defini¸c˜ao do limite de intrus˜ao nos ambientes
dom´esticos e no espa¸co p´ublico.
A pr´oxima se¸c˜ao discute algumas legisla¸c˜oes mais influentes de privacidade, e
como elas podem influenciar no projeto d e sistemas de processamento de dados e
sua infra-estrutura.
3.4 Legisla¸c˜ao
A maioria dos pa´ıses reconhecem em suas constitui¸c˜oes algum n´ıvel de privaci-
dade. No m´ınimo, os direitos da inviolabilidade do lar (privacidade territorial) e a
confidencialidade das comunica¸c˜oes est˜ao declaradas (RIGHTS, 2008).
No Brasil, o artigo 5 d a Constitui¸c˜ao declara que s˜ao inviol´aveis a intimidade, a
vida privada, a honra e a imagem das p essoas; o lar ´e inviol´avel e ningu´em pode en-
trar sem o consentimento do morador; a correspondˆencia e a comunica¸c˜ao eletrˆonica
s˜ao sigilosas (CONSTITUICAO, 1988).
A prote¸c˜ao da informa¸c˜ao ´e garantida por declara¸c˜oes e legisla¸c˜oes em diversos
graus, dependendo do pa´ıs. Entretanto, todas concordam que a informa¸c˜ao pessoal
deve ser obtida amigavelmente e dentro da lei; usada somente pelo prop´osito espe-
cificado originalmente; adequada, relevante e n˜ao excessiva ao prop´osito; precisa e
atualizada; destru´ıda depois que seu prop´osito ´e completado.
A constitui¸c˜ao e a legisla¸c˜ao brasileira n˜ao abordam essa quest˜ao com mais
profundidade. Diversas propostas de leis j´a foram submetidas, mas n˜ao foram apro-
vadas ou est˜ao tramitando no Congresso Nacional. Conseq¨uentemente, o Brasil n˜ao
possui leis que protegem os dados e os direitos da privacidade individual. Diferen-
temente, a Argentina possui um ato espec´ıfico e detalhado abordando esta quest˜ao
(ARGENTINA, 2008).
18
Contudo, as mais influentes legisla¸c˜oes de privacidade, mundialmente conheci-
das, s˜ao: US Privacy Act de 1974 (USPRIVACYACT, 1974) e EU Directive 95/46/EC
de 1995 (EUDIRECTIVE1995/46/EC, 1995).
A legisla¸c˜ao US Privacy Act de 1974 influenciou o desenvolvimento de pol´ıticas
de privacidade do mundo inteiro. Essa legisla¸c˜ao define alguns princ´ıpios de privaci-
dade, os quais s˜ao baseados no trabalho de Alan Westin (WESTIN, 1995) (WESTIN,
1967). Esses princ´ıpios s˜ao os seguintes:
Abertura e transparˆencia: nenhum registro deve ser secreto. Isso inclui tanto a
publica¸c˜ao da sua existˆencia como tamb´em o seu conte´udo;
Participa¸c˜ao individual: o assunto de um registro deve ser vis´ıvel e sua corre¸c˜ao
deve ser permitida;
Limita¸c˜ao de cole¸c˜ao: a cole¸c˜ao de dados deve ser proporcional e n˜ao excessiva
ao prop´osito da cole¸c˜ao;
Qualidade dos dados: os dados devem ser relevantes aos p rop´ositos para os quais
s˜ao coletados e devem estar sempre atualizados;
Limita¸c˜ao de uso: os dados devem ser usados para o seu prop´osito espec´ıfico e
por pessoas autorizadas;
Seguran¸ca aceit´avel: prote¸c˜oes de seguran¸ca adequadas devem ser usadas de acordo
com a importˆancia dos dados coletados;
Responsabilidade: os gerenciadores dos registros s˜ao os respons´aveis por assegu-
rar os demais princ´ıpios.
Embora esses princ´ıpios de privacidade estivessem incorporados em v´arias le-
gisla¸c˜oes no mundo inteiro, o US Privacy Act de 1974 n˜ao era um sucesso nos
Estados Unidos (GELLMAN, 1998). Em 1980, a Organization for Economic Co-
operation and Development (OECD) classificou as informa¸c˜oes de privacidade nas
Diretrizes da OECD (OECD, 1980) para evitar uma prolifera¸c˜ao de leis de prote¸c˜ao
`a privacidade que poderiam p rejudicar o crescimento econˆomico atrav´es da cria¸c˜ao
de barreiras comerciais (LANGHEINRICH, 2001).
19
Os pa´ıses eur opeus continuaram a desenvolver e refinar seu s documentos de
prote¸c˜ao `a privacidade abrangendo tanto cole¸c˜ao de d ados governamentais como
privados. No entanto, a legisla¸c˜ao dos Estados Unidos seguiu com a defini¸c˜ao de
documentos mais espec´ıficos, como por exemplo: Fair Credit Reporting Act de 1970,
Video Privacy Protection Act d e 1988, Family Education Rights and Privacy Act de
1994 (LANGHEINRICH, 2001).
Somente em 1995 foi divulgada uma nova legisla¸c˜ao t˜ao influente quanto `a dos
Estados Unidos, s´o que dessa vez na Europa. De acordo com Langheinrich (2001),
a EU Directive 95/46/EC da Uni˜ao Europ´eia sobre a prote¸c˜ao de indiv´ıduos no que
diz respeito ao processamento de dados pessoais e no movimento livre de tais dados
(EUDIRECTIVE1995/46/EC, 1995) ´e a legisla¸c˜ao de privacidade do fim do s´eculo 20.
A EU Directive 95/46/EC apresentou alguns impactos (LANGHEINRICH, 2001).
Em primeiro lugar, seu artigo 25/1 limita transferˆencias de dados a pa´ıses que n˜ao
s˜ao da Uni˜ao Europ´eia, somente se eles tiverem “um n´ıvel adequado de prote¸c˜ao `a
privacidade”. A amea¸ca de ficar fora dos fluxos de dados europeus fez com que mui-
tos pa´ıses revisassem as suas legisla¸c˜oes de privacidade para obedecer `as exigˆencias
da EU Directive 95/46/EC. Em segundo lugar, a EU Directive 95/46/EC n˜ao s´o
providencia e refin a as pr´aticas de privacidade descritas acima, como tamb´em acres-
centa no seu artigo 7, no¸c˜oes de consentimentos expl´ıcitos: dados pessoais somente
podem ser processados se o usu´ario n˜ao apresentar ambig¨uidades nas informa¸c˜oes
fornecidas por ele (podem haver exce¸c˜oes para prop´ositos legais e contratuais). Essa
considera¸c˜ao praticamente repudia todos os tipos de cole¸c˜oes de dados (com exce¸c˜ao
das que s˜ao exigidas por lei) e requer um consentimento expl´ıcito caso a caso con-
forme a importˆancia dos dados.
Como muitos profissionais da computa¸c˜ao podem ignorar assuntos legais no
momento de projetar sistemas computacionais e se concentram somente nas possi-
bilidades t´ecnicas atuais, a EU Directive 95/46/EC criou em 1998 uma referˆencia
importante para a prote¸c˜ao de privacidade, que n˜ao pode ser ignorada. A EU Di-
rective 95/46/EC d estaca tanto a relevˆancia da prote¸c˜ao de privacidade na era de
processamento de dados digitais quanto a importˆancia de coopera¸c˜ao internacional
para alcan¸car essa prote¸c˜ao.
20
3.5 Privacidade em Computa¸c˜ao Ub´ıqua
Em computa¸c˜ao ub´ıqua, a tecnologia est´a muito pr´oxima dos indiv´ıduos e re-
side nos mais diversos cen´arios reais que possam ser considerados. Segundo este
paradigma, a computa¸c˜ao deve ser invis´ıvel, ou seja, causar o m´ınimo poss´ıvel de
distra¸c˜ao ao usu´ario.
Baseado nesta id´eia, n˜ao ´e aceit´avel que os usu´arios sejam interrompidos freq¨uen-
temente com op¸c˜oes e alertas para configurar, aceitar ou rejeitar algum tipo de co-
munica¸c˜ao do amb iente que seja intrusiva. Nesta se¸c˜ao, s˜ao apresentados servi¸cos
que podem ser intrusivos em ambientes de computa¸c˜ao ub´ıqua, as quest˜oes que
devem ser consideradas e as restri¸c˜oes que podem ser impostas a esses servi¸cos.
3.5.1 Servi¸cos
A maioria dos servi¸cos em computa¸c˜ao ub´ıqua ainda n˜ao s˜ao muito difundidos
ou aplicados em ambientes reais (AOYAMA, 2008). A seguir s˜ao descritos alguns
desses servi¸cos e suas respectivas implica¸c˜oes `a privacidade.
3.5.1.1 Servi¸co de identifica¸c˜ao de produtos
Atrav´es desse servi¸co ´e poss´ıvel contabilizar e rastrear os produtos que um con-
sumidor est´a adquirindo. As implica¸c˜oes s˜ao a falta de controle dos tipos e do uso
das informa¸c˜oes que est˜ao sendo coletadas e a possibilidade de uma entidade externa
rastrear o conte ´udo da compra fora da loja.
3.5.1.2 Servi¸co de alerta de proximidade
Este servi¸co informa quando uma pessoa conhecida e cadastrada n o seu dispo-
sitivo est´a pr´oxima de sua localiza¸c˜ao f´ısica ou em um ambiente comum. A pro-
blem´atica ´e que nem sempre as pessoas desejam ser localizadas em determinadas
situa¸c˜oes ou hor´arios.
Al´em disso, t em-se as seguintes quest˜oes: (a) O sistema deve informar a lo-
caliza¸c˜ao exata da pessoa ou apenas emitir um alerta de sua presen¸ca? (b) Como
bloquear a localiza¸c˜ao para determinadas pessoas ou em determinadas situa¸c˜oes sem
21
quebrar a no¸c˜ao de invisibilidade da tecnologia?
3.5.1.3 Servi¸co de propaganda
Este servi¸co envia propagandas e an´uncios de produtos aos dispositivos de
usu´arios quando estes se aproximam de seus estabelecimentos comerciais. Neste
caso, h´a diversas quest˜oes: (a) Como definir as pol´ıticas para restringir as propa-
gandas? (b) Como evitar os protocolos desgastantes para obter estas informa¸c˜oes?
(c) Como mapear os interesses de um cliente? (d) Como definir os limites para
realizar esse mapeamento?
3.5.2 Restri¸c˜oes
Os servi¸cos introduzidos com a computa¸c˜ao ub´ıqua tem o objetivo de facilitar
a execu¸c˜ao de tarefas do usu´ario. Por´em, os servi¸cos precisam respeitar certas
restri¸c˜oes para que n˜ao se tornem intrusivos.
Uma classifica¸c˜ao para estas restri¸c˜oes ´e apresentada a seguir (MYLES; FRIDAY;
DAVIES, 2003):
Temporal: determina per´ıodos de tempo em que o servi¸co est´a dispon´ıvel ou desa-
bilitado. Por exemplo, um usu´ario n˜ao gosta de ser localizado no per´ıodo do
almo¸co;
Localiza¸c˜ao: restringe o acesso `as informa¸c˜oes ou ao dispositivo baseado na loca-
liza¸c˜ao do usu´ario. Por exemplo, em um restaurante o usu´ario pode permitir
a um servi¸co obter seu nome para um atendimento personalizado;
Organiza¸c˜ao: define quem e quando uma entidade pode localizar o usu´ario. Por
exemplo, um trabalhador de uma empresa deseja somente ser localizado en-
quanto estiver nos limites f´ısicos da empresa;
Servi¸co: define quais servi¸cos um dispositivo cliente pode acessar. Por exemplo,
ao entrar em um ambiente com servi¸cos de an´uncios, pode-se restringir quais
tem permiss˜ao para o acesso;
Pedido: define quais informa¸c˜oes podem ser reveladas para um determinado servi¸co.
22
Por exemplo, ao preencher um cadastro o cliente define quais dados s˜ao r ele-
vantes para serem transmitidos do seu dispositivo para o cadastro;
Situa¸c˜ao: define as situa¸c˜oes em que as pol´ıticas definidas para um servi¸co podem
ser sobrepostas. Este tipo de servi¸co requer um n´ıvel de inteligˆencia dos dispo-
sitivos. Por exemplo, um usu´ario n˜ao quer acessar nenhum servi¸co, enquanto
estiver na sala de reuni˜oes com seu chefe;
Grupo: define um grupo comum que pode acessar um conjunto de informa¸c˜oes
do usu´ario. Essa restri¸c˜ao se aplica a dispositivos de outros usu´arios. Por
exemplo, um usu´ario quer compartilhar as informa¸c˜oes de trabalho com todos
que fazem parte do seu setor;
Interesse: define se servi¸cos ou informa¸c˜oes transmitidas para o dispositivo s˜ao de
interesse do usu´ario. Por exemplo, um usu´ario pode desejar receber resultados
de jogos de futebol, logo ele pode definir como interesse esse tipo de informa¸c˜ao.
Na pr´oxima subse¸c˜ao s˜ao apresentadas algumas raz˜oes para a invas˜ao de priva-
cidade, obtidas em (BERESFORD, 2005).
3.5.3 Raz˜oes para invas˜ao de privacidade
As raz˜oes para invas˜ao de privacidade s˜ao muitas e variadas. Os governos
normalmente querem obter informa¸c˜oes dos cidad˜aos, como por exemplo, sal´arios,
padr˜ao familiar, religi˜ao e qualifica¸c˜oes. O objetivo declarado dos dados coletados
´e que favorece o crescimento da sociedade; em muitos casos o benef´ıcio est´a claro
(por exemplo, a regulamenta¸c˜ao de m´edicos), mas em alguns casos os benef´ıcios da
sociedade s˜ao menos ´obvios, por exemplo, o registro de origem racial.
Organiza¸c˜oes comerciais est˜ao relacionadas principalmente aos lucros, e s˜ao
muito mais invasivas que os governos. As propagandas ou os cart˜oes de fidelidade
foram sugeridos como a principal motiva¸c˜ao mas, mais recentemente a discrimina¸c˜ao
de pre¸co
1
foi sugerida como um fator motivador forte. Exemplos de discrimina¸c˜ao
de pre¸co incluem vˆoos, computadores e at´e mesmo DVDs. A automatiza¸c˜ao da
cole¸c˜ao e an´alise de perfis do consumidor (freq¨uentemente chamados de minera¸c˜ao
1
A discrimina¸c˜ao de pre¸co ´e o ato de oferecer aos indiv´ıduos um pre¸co personalizado baseado
na quantia que eles est˜ao dispostos a pagar
23
de dados) fez crescer a habilidade das corpora¸c˜oes em atribuir dinamicamente pre¸cos
aos produtos, conforme o perfil do consumidor. Odlyzko (ODLYZKO, 2003) mostra
atrav´es da teoria econˆomica que a discrimina¸c˜ao de pre¸co combinada com um perfil
eficiente do consumidor resulta em um mercado mais eficiente e como ainda n˜ao
possui regulamento, seu uso ser´a difundido.
A minera¸c˜ao de dados, independente do contexto onde for aplicada, ir´a impactar
diretamente na privacidade do consumidor. Nem todos os usu´arios parecem estar
interessados com a cole¸c˜ao de dados e pol´ıticas de reten¸c˜ao; e, ao contr´ario, a maioria
dos usu´arios est´a satisfeito com tal processo, fazendo com que consumidores menos
satisfeitos sejam for¸cados a participar, ou por falta de escolha ou por ser caro demais
para os indiv´ıduos que optam por ter privacidade.
Exemplos atuais de amea¸cas `a privacidade da informa¸c˜ao s˜ao os sistemas de
identifica¸c˜ao (biometria, cart˜oes de identifica¸c˜ao); a vigilˆancia das comunica¸c˜oes
(Internet, telefone); a vigilˆancia por v´ıdeo, sat´elite ou ´audio; o com´ercio eletrˆonico
(levantamento de perfis, spam, dados coletados); o monitoramento em locais de
trabalho; rastreamento de localiza¸c˜ao, entre outras.
3.5.4 M´etodos de prote¸c˜ao `a privacidade
Lessig (LESSIG, 1999) descreve os quatro m´etodos b´asicos de regular o com-
portamento de indiv´ıduos: arquitetura, costumes sociais, mercado e lei. A figura
3.1 apresenta a intera¸c˜ao entre o indiv´ıduo e os quatro m´etodos b´asicos de regula-
menta¸c˜ao, onde cada m´etodo representa um custo distinto mas interdepen dente n o
indiv´ıduo. As restri¸c˜oes desses m´etodos podem ser complementares ou n˜ao, contud o
podem ser regidas por lei.
A arquitetura e o mercado regulam o comportamento antes que uma a¸c˜ao venha
a acontecer, por exemplo: uma porta fechada previne a entrada n˜ao desejada e o
custo do cigarro intimida o seu consumo. Costumes sociais e leis regulam o compor-
tamento ap´os a execu¸c˜ao de uma a¸c˜ao, por exemplo: os restaurantes podem ignorar
o fato de um cliente fumar durante uma refei¸c˜ao, mas a pol´ıcia pode prendˆe-lo por
ter infringido u ma propriedade privada. A maioria dos indiv´ıduos se sente amea¸cado
pelos costumes sociais ou pelas leis, antes da execu¸c˜ao de uma a¸c˜ao, embora os cos-
tumes sociais ou leis n˜ao possam evitar que ele a pratique, ao contr´ario das for¸cas
24
Figura 3.1: Os quatro m´etodos de regulamenta¸c˜ao de um indiv´ıduo I
(BERESFORD, 2005).
arquiteturais e de mercado (BERESFORD, 2005).
Dessa forma, pode-se dizer que a lei, por si s´o n˜ao ´e suficiente como tamb´em n˜ao
´e o m´etodo mais eficiente para preven¸c˜ao de intrus˜ao n˜ao desejada nas vidas privadas
dos indiv´ıduos porque (BERESFORD, 2005): (1) a privacidade ´e muito subjetiva, ou
seja, o que ´e aceit´avel a uma pessoa ´e inaceit´avel a outra; (2) a aplica¸c˜ao de uma lei
ap´os a execu¸c˜ao de uma a¸c˜ao pode n˜ao ser uma boa solu¸c˜ao, pois a informa¸c˜ao j´a foi
descoberta. Isto n˜ao significa que os legisladores n˜ao provˆeem nenhuma contribui¸c˜ao
`a prote¸c˜ao de privacidade; a lei tem um papel crucial no controle arquitetural, for¸cas
de mercado e costumes sociais.
3.5.5 M´etodos para a regulamenta¸c˜ao de privacidade
T´ecnicas para proteger a pr ivacidade pessoal diferem notadamente pelo mundo
afora. Por´em, quatro abordagens se destacam (BERESFORD, 2005):
Amplo: a Europa, Austr´alia, Nova Zelˆandia e Canad´a tˆem um modelo regulador
amplo com um funcion´ario p´ublico respons´avel por garantir a aplica¸c˜ao da
legisla¸c˜ao de prote¸c˜ao de dados;
Setorial: os Estados Unidos n˜ao definiram uma legisla¸c˜ao de prote¸c˜ao de dados
geral, mas ordenou uma s´erie de leis espec´ıficas ao inv´es de lidar com problemas
conforme o seu surgimento;
25
Auto-regulamenta¸c˜ao: v´arias ind´ustrias tentaram fazer uma auto-regulamenta¸c˜ao
atrav´es de c´odigos de pr´atica, por´em muitos desses n˜ao foram efetivos e tˆem
menos impacto que uma legisla¸c˜ao; al´em disso, consensos industriais n˜ao re-
sultam necessariamente em uma boa privacidade ao consumidor, embora a
amea¸ca de interven¸c˜ao do governo possa ter algum efeito positivo;
Tecnol´ogico: a tecnologia pode prover solu¸c˜oes como tamb´em amea¸cas `a privaci-
dade pessoal. Pretty Good Privacy (PGP) ´e um exemplo bem conhecido de
tecnologia que habilita a privacidade de comunica¸c˜oes, contudo, o governo dos
Estados Unidos proibiu seu uso e a sua distribui¸c˜ao.
3.5.6 Algumas solu¸c˜oes t´ecnicas para prote¸c˜ao `a privacidade
Esta se¸c˜ao descreve algumas solu¸c˜oes t´ecnicas emergentes para prote¸c˜ao `a priva-
cidade de informa¸c˜ao pessoal. O maior problema encontrado em privacidade ´e que
as ferramentas de coleta de informa¸c˜oes n˜ao s˜ao projetadas para prover o direito do
usu´ario `a privacidade (BUENNEMEYER; MARCHANY; TRONT, 2006).
O desenvolvimento de sistemas de coleta de informa¸c˜oes contribui para que dad os
pessoais sejam utilizados de forma abusiva e compartilhados de maneira impr´opria.
Bayardo (BAYARDO; SRIKANT, 2003) afirma que casos de revela¸c˜ao impr´opria e
completamente abusivos de informa¸c˜ao pessoal afetam o comportamento individual
e coletivo. Dessa forma, solu¸c˜oes t´ecnicas devem ser desenvolvidas para ajudar a
proteger a nossa privacidade. O desafio ´e permitir que algumas minera¸c˜oes de dados
melhorem a vida dos usu´arios e, ao mesmo tempo, proteja suas informa¸c˜oes pessoais.
H´a poucas ferramentas para gerenciar a privacidade dos dados pessoais no momento.
Por´em, mais tecnologias de prote¸c˜ao `a privacidade vˆem sendo desenvolvidas.
As tecnologias de prote¸c˜ao de privacidade envolvem basicamente 5 ´areas gerais
(BAYARDO; SRIKANT, 2003): bancos de dados de Hippocrates, codifica¸c˜ao da pol´ıtica
de privacidade, anonimato, minera¸c˜ao de dados com a op¸c˜ao de preservar a priva-
cidade, e compartilhamento de informa¸c˜oes por reposit´orios privados. As pr´oximas
subse¸c˜oes apresentam brevemente cada uma dessas ´areas baseadas em (BAYARDO;
SRIKANT, 2003).
26
3.5.6.1 Bancos de dados de Hippocrates
Os bancos de dados de Hippocrates assumem responsabilidade pela privacidade
dos dados que eles gerenciam como uma premissa essencial por meio do emprego de
10 princ´ıpios de privacidade, conforme citado em (AGRAWAL et al., 2002):
Especifica¸c˜ao do prop´osito: para cada informa¸c˜ao pessoal armazenada no banco
de dados, ser˜ao associados os prop´ositos para os quais a informa¸c˜ao foi cole-
tada;
Consentimento: os prop´ositos associados com a informa¸c˜ao pessoal ter˜ao consen-
timento do propriet´ario da informa¸c˜ao;
Limita¸c˜ao de cole¸c˜ao: s˜ao coletadas o m´ınimo poss´ıvel de informa¸c˜oes pessoais
para realizar os prop´ositos especificados;
Limita¸c˜ao de uso: o banco de dados executar´a somente as consultas que s˜ao con-
sistentes com os prop´ositos para os quais a informa¸c˜ao foi coletada;
Revela¸c˜ao limitada: as informa¸c˜oes pessoais armazenadas no banco de dados n˜ao
ser˜ao reveladas para prop´ositos diferentes dos quais houve consentimento do
propriet´ario da informa¸c˜ao;
Reten¸c˜ao limitada: as informa¸c˜oes pessoais somente permanecer˜ao retidas o tempo
necess´ario para o cumprimento dos prop´ositos para os quais foram coletadas;
Precis˜ao: as informa¸c˜oes pessoais armazenadas no banco de dados ser˜ao precisas
e atualizadas;
Seguran¸ca: as informa¸c˜oes pessoais ser˜ao protegidas por t´ecnicas de seguran¸ca
contra furtos e outros desvios;
Abertura: um propriet´ario poder´a ter acesso a toda a informa¸c˜ao armazenada
sobre ele no banco de dados;
Conformidade: um propriet´ario poder´a verificar a conformidade com os princ´ıpios
anteriores.
De acordo com (BAYARDO; SRIKANT, 2003), esses bancos de dados obrigam
automaticamente a utiliza¸c˜ao dos princ´ıpios de privacidade atrav´es da verifica¸c˜ao
27
de informa¸c˜oes de privacidade relativas `a consulta autorizada de usu´arios, as quais
s˜ao estritamente baseadas em uma pol´ıtica de privacidade. O banco de dados confere
explicitamente se o usu´ario tem ou n˜ao acesso aos campos dos dados, e ent˜ao permite
o acesso aos registros que tˆem os seus atributos autorizados.
3.5.6.2 Codifica¸c˜ao da pol´ıtica de privacidade
Uma pol´ıtica de privacidade pode ser entendida como um conjunto de regras
criado por uma organiza¸c˜ao ou indiv´ıduo para determinar quais entidades ou servi¸cos
podem ter acesso `as suas informa¸c˜oes e, em alguns casos, para determinar tamb´em
em quais contextos as suas informa¸c˜oes podem ser utilizadas (BAYARDO; SRIKANT,
2003).
A codifica¸c˜ao de pol´ıticas de privacidade permite que uma organiza¸c˜ao codifique
sua cole¸c˜ao de dados e pr´aticas usadas em um modelo automatizado. Os usu´arios
podem estabelecer um perfil de privacidade que ´e conferido automaticamente quando
eles entram no ambient e. H´a dois exemplos importantes de codifica¸c˜ao de pol´ıtica de
privacidade: IBM’s Enterprise Privacy Authorization Language (EPAL) e o World
Wide Web Consortium’s (W3C) Platform for Privacy Preferences Project (P3P)
(W3C, 2007). O objetivo da EPAL ´e permitir que os sistemas de privacidade como
o Tivoli Privacy Manager obriguem o uso de pol´ıticas de privacidade em empresas.
J´a a W3C desenvolveu a iniciativa P3P para per mitir a combina¸c˜ao entre pol´ıticas
de privacidade e preferˆencias do usu´ario. Essa iniciativa est´a emergindo como um
padr˜ao de fato para disponibilizar meios simples e automatizados para os usu´arios
ganharem mais controle sobre o uso de suas informa¸c˜oes pessoais que s˜ao coletadas
em sua maior parte em sites Web. O P3P engloba um conjunto padr˜ao de quest˜oes
que cobrem a maioria dos aspectos da pol´ıtica de privacidade de um site Web. A
id´eia ´e que um sistema habilitado possa comparar automaticamente a p ol´ıtica de
privacidade do site Web com o perfil de privacidade do usu´ario. O usu´ario ret´em o
controle da privacidade de suas informa¸c˜oes baseado no seu perfil e, mais importante,
o P3P permite que o sistema notifique o usu´ario em um formato compreens´ıvel e,
dessa forma, ele pode tomar decis˜oes com rela¸c˜ao `a libera¸c˜ao de informa¸c˜oes adicio-
nais. Essa parece ser a primeira tentativa de padronizar e categorizar a privacidade
das informa¸c˜oes pessoais em um formato de interface que ´e compreens´ıvel tanto
pelos usu´arios quanto pelos sistemas.
28
3.5.6.3 Anonimato
Ferramentas que estabelecem o anonimato de um usu´ario s˜ao comuns atual-
mente, mas elas s˜ao ferramentas tipicamente baseadas n a Web. No futuro, essas fer-
ramentas ir˜ao envolver e migrar para os ambientes ub´ıquos. De acordo com Bayardo
(BAYARDO; SRIKANT, 2003), ferramentas de anonimato permitir˜ao aos usu´arios a
possibilidade de impedir que organiza¸c˜oes coletem informa¸c˜oes sobre eles devido ao
fato dessa tecnologia prevenir a coleta de dados p ois esconde a identifica¸c˜ao da in-
forma¸c˜ao. Neste caso, por exemplo, ao entrar em um ambiente ub´ıquo, o usu´ario
poder´a se conectar ao sistema por um proxy de privacidade o qual permitir´a que ele
fa¸ca compras anonimamente sem ter que compartilhar informa¸c˜oes pessoais.
Um exemplo de anonimato s˜ao as zonas de mixagem (mix zones) (BERESFORD;
STAJANO, 2003). Zonas de mixagem s˜ao regi˜oes espaciais conectadas de tamanho
m´aximo definido, onde nenhum dos usu´arios pode ser localizado por servi¸cos. Du-
rante a permanˆencia nessas zonas a identidade do usu´ario ´e “mixada”, ou seja, o
usu´ario recebe um novo pseudˆonimo. Com isso, dispositivos que conheciam sua
identifica¸c˜ao anterior n˜ao saber˜ao mais sua identidade ou localiza¸c˜ao no ambiente.
As zonas de mixagem p ermitem introduzir um grau de anonimato e evitar o
rastreamento do usu´ario por um determinado dispositivo. Elas devem estar locali-
zadas em pontos movimentados, onde grupos de usu´arios se concentrem para que a
mixagem seja mais eficiente.
3.5.6.4 Minera¸c˜ao de dados com a op¸c˜ao de preservar a privacidade
A minera¸c˜ao de dados com a op¸c˜ao de preservar a privacidade combina aspectos
de v´arias ´areas de tecnologias de privacidade emergentes. O anonimato pode impe-
dir que companhias conhe¸cam a base de dados de seus clientes e dessa forma impede
tamb´em que elas se esforcem para melhorar seus produtos e servi¸cos (BAYARDO;
SRIKANT, 2003). A minera¸c˜ao de dados com a caracter´ıstica de privacidade deve-
ria permitir que as opera¸c˜oes comerciais derivassem as informa¸c˜oes necess´arias para
compreender os h´abitos de compra do cliente sem coletar qualquer informa¸c˜ao pes-
soal. Essa abordagem impede a reten¸c˜ao de informa¸c˜oes pessoais significantes sobre
o usu´ario, mas permite que opera¸c˜oes comerciais construam modelos de informa¸c˜oes
do cliente agregadas para melhorar as decis˜oes comerciais.
29
3.5.6.5 Compartilhamento de informa¸c˜oes por reposit´orios privados
O compartilhamento de informa¸c˜oes entre os reposit´orios privados representa
um grande desafio, pois as pol´ıticas de seguran¸ca n˜ao s˜ao perfeitamente alinhadas
entre os diferentes bancos de dados. O fato dos consumidores poderem, em alguns
casos, optar por revelar suas informa¸c˜oes pessoais, n˜ao significa necessariamente que
eles queiram que as suas informa¸c˜oes sejam combinadas para gerar dossiˆes de consu-
midores com um elevado n´ıvel de detalhe. Quando a informa¸c˜ao ´e distribu´ıda entre
esses bancos de dados, o problema ´e como permitir que as companhias desenvolvam
modelos agregados para compartilhar informa¸c˜oes sem ter que revelar os dados de
privacidade individuais (BAYARDO; SRIKANT, 2003). No futuro, frameworks para
compartilhamento de informa¸c˜oes entre banco de dados dever˜ao ser desenvolvidos
para alcan¸car esta possibilidade de compartilhar informa¸c˜oes e ainda proteger a
privacidade pessoal.
3.5.6.6 Considera¸c˜oes
Nessa se¸c˜ao foram descritas algumas tecnologias existentes e que ainda est˜ao
sendo desenvolvidas para permitir o compartilhamento de informa¸c˜oes e ainda para
proteger a privacidade individual. Acredita-se que com os avan¸cos tecnol´ogicos e com
a resolu¸c˜ao dos problemas de ataques `a privacidade ser´a poss´ıvel sup erar o desafio
de proteger a privacidade individual e se beneficiar de um maior compartilhamento
de informa¸c˜oes.
3.5.7 Implica¸c˜oes sociais da computa¸c˜ao ub´ıqua
Para se entender o que faz a computa¸c˜ao ub´ıqua diferente dos outros d om´ınios
de inform´atica, no que diz respeito `a privacidade, e porque os cientistas da com-
puta¸c˜ao nesse dom´ınio particular deveriam se preocupar mais com tais no¸c˜oes vagas
de liberdade e privacidade, ´e preciso conhecer quatro propriedades fundamentais
(LANGHEINRICH, 2001):
Onipresen¸ca: a computa¸c˜ao ub´ıqua est´a em todos os lugares, essa ´e a sua essˆencia,
seu objetivo expl´ıcito. Por conseq¨uˆencia, as decis˜oes feitas nos sistemas de
computa¸c˜ao ub´ıqua ir˜ao afetar grande ou at´e mesmo todas as ´areas de nossas
30
vidas, desde atravessar uma rua at´e se sentar na sala de estar ou entrar em
um edif´ıcio comercial;
Invisibilidade: os computadores n˜ao somente devem estar em todos lugares, como
tamb´em devem ser impercept´ıveis. Com o desenvolvimento de dispositivos de
comunica¸c˜ao e computa¸c˜ao cada vez menores, esse objetivo parece longe de
ser pura fic¸c˜ao cient´ıfica e come¸ca a se tornar realidade;
Sensibilidade: com o aumento do poder de processamento computacional de dis-
positivos cada vez menores, os sensores ganharam em precis˜ao das informa¸c˜oes
obtidas do ambiente onde se encontram. Sensores simples de temperatura, luz
ou som foram os sensores mais completos durante muito tempo. Por´em, novas
gera¸c˜oes de sensores permitir˜ao a obten¸c˜ao de dados de ´audio e v´ıdeo de alta
qualidade a partir de m´aquinas fotogr´aficas e microfones menores que simples
bot˜oes. At´e mesmo os aspectos emocionais de nossas vidas, como estresse,
medo, ou excita¸c˜ao, poderiam ser sentidos por sensores embutidos em nossas
roupas ou em nosso ambiente;
Amplifica¸c˜ao de mem´oria: os avan¸cos no processamento de ´audio e v´ıdeo, com-
binados com os novos equipamentos de sensores fazem perceber a importˆancia
de amplificadores de mem´oria que podem continuamente registrar todas as
nossas a¸c˜oes, express˜oes verbais e os nossos movimentos, alimentando-os em
um sistema sofisticado que usa o processamento de ´audio e v´ıdeo o qual nos
permite pesquisar sobre o nosso passado.
A tecnologia de banco de dados e a Internet j´a deram aos p esquisadores e imple-
mentadores um gosto da responsabilidade social que esses sistemas exigem. Lessig
(LESSIG, 1999) argumenta que as decis˜oes t´ecnicas feitas durante o projeto de qual-
quer sistema computacional constituem em implica¸c˜oes legais do que ´e e o que n˜ao ´e
poss´ıvel de obrigar ou gerenciar em tais sistemas. Com o crescimento e onipresen¸ca
da World Wide Web, as tecnologias computacionais passaram a afetar muito mais
que a elite de acadˆemicos com habilidades t´ecnicas, pois elas atingem tamb´em todos
os demais cidad˜aos.
Conforme (LANGHEINRICH, 2001), a computa¸c˜ao ub´ıqua far´a com que as tecno-
logias computacionais dˆeem um passo a frente. Com um mundo densamente povoado
31
de dispositivos de computa¸c˜ao e comunica¸c˜ao pequenos, inteligentes e invis´ıveis, ne-
nhuma ´unica parte da vida dos seres humanos ir´a escapar da digitaliza¸c˜ao. Tudo o
que se fala, faz ou sente poder´a ser digitalizado, armazenado e pesquisado a qualquer
momento.
S˜ao os cientistas da computa¸c˜ao quem precisam entender o potencial e o perigo
dos avan¸cos tecnol´ogicos e desenvolver conven¸c˜oes seguras e diretrizes de acordo com
princ´ıpios bem estabelecidos que ir˜ao guiar a tecnologia em uma dire¸c˜ao respons´avel
e socialmente aceit´avel (LANGHEINRICH, 2001).
3.6 Considera¸c˜oes
Nesse cap´ıtulo foram apresentados os principais conceitos, tecnologias, preo-
cupa¸c˜oes e desafios relacionados `a privacidade.
O metamodelo apresentado em (CAMPIOLO, 2005) n˜ao permite especificar os
problemas relativos `a privacidade em ambientes ub´ıquos. O pr´oximo cap´ıtulo abor-
dar´a uma esp ecifica¸c˜ao de privacidade com base nos conceitos de (1) anonimato
(PFITZMANN; K¨oHNTOPP, 2001), (2) o uso de pseudˆonimos (BERESFORD; STAJANO,
2004), (3) o perfil de preferˆencias do usu´ario (LEDERER; DEY; MANKOFF, 2002) e
(4) a cria¸c˜ao de zonas de mixagem (BERESFORD, 2005), no caso de necessidade de
existˆencia dessa no ambiente ub´ıquo.
A figura 4.1 mostra todas as classes constru´ıdas em (CAMPIOLO, 2005). E m
destaque (retˆangulo vermelho) s˜ao criadas as trˆes classes apropriadas que especificam
os itens (1), (2), (3) e (4) focalizados nessa disserta¸c˜ao. Uma especifica¸c˜ao formal em
Object-Z foi concebida p ara abordar esses aspectos de privacidade dos itens acima.
32
4 Especificando Privacidade
Esse cap´ıtulo apresenta uma extens˜ao da especifica¸c˜ao de ambientes de com-
puta¸c˜ao ub´ıqua, criada em (CAMPIOLO, 2005), no sentido de se estabelecer os as-
pectos relacionados `a privacidade. Tais aspectos continuam sendo apresentados,
detalhados e discutidos informalmente, atrav´es de senten¸cas explicativas, e formal-
mente, atrav´es do modelo em Object-Z, como feito em (CAMPIOLO, 2005). Al´em
disso, as nota¸c˜oes matem´aticas como as que podem ser utilizadas no Object-Z s˜ao
normalmente adotadas, pois descrevem de forma precisa as propriedades de um
sistema computacional (DUKE et al., 1991).
4.1 Componentes da Especifica¸c˜ao
O desenvolvimento dos componentes da especifica¸c˜ao foram baseados em dois
objetivos: (1) permitir que a especifica¸c˜ao desenvolvida em (CAMPIOLO, 2005) per-
mane¸ca gen´erica, por´em estendida com a caracter´ıstica de privacidade; (2) permitir
a utiliza¸c˜ao dessa especifica¸c˜ao em simula¸c˜oes de ambientes de computa¸c˜ao ub´ıqua,
como apresentado no cap´ıtulo 5.
O diagrama 4.1 apresenta os principais elementos da especifica¸c˜ao classificados
em nove categorias. Para sintetizar o entendimento da especifica¸c˜ao, apenas as
rela¸c˜oes mais importantes em (CAMPIOLO, 2005) s˜ao apresentadas, com o objetivo
de fornecer uma vis˜ao geral da intera¸c˜ao entre esses elementos.
Como se pode observar, foi utilizada a mesma nota¸c˜ao dos diagramas de classe
UML (Unified Modeling Language), com algumas semˆanticas redefinidas. Como
apresentado por (CAMPIOLO, 2005) s˜ao utilizadas as nota¸c˜oes de heran¸ca, asso-
cia¸c˜ao, agrega¸c˜ao e dependˆencia. As caixas representam as classes essenciais da
especifica¸c˜ao, heran¸ca representa a expans˜ao das classes, a associa¸c˜ao representa a
33
Figura 4.1: Principais componentes da especifica¸c˜ao
liga¸c˜ao entre as classes e a dependˆencia indica a participa¸c˜ao direta ou ind ireta sobre
o estado das classes.
Os elementos desse metamodelo tˆem como objetivo permitir a constru¸c˜ao de
modelos que p ossam ser simulados atrav´es de estruturas computacionais. A cate-
goria de privacidade foi acrescentada, com o objetivo de permitir que ambientes
de computa¸c˜ao ub´ıqua sejam simulados com os aspectos de privacidade. As nove
categorias s˜ao detalhadas a seguir (CAMPIOLO, 2005):
Ambiente: se refere aos cen´arios de computa¸c˜ao ub´ıqua. Todos os demais elemen-
tos fazem parte de sua composi¸c˜ao;
Caracter´ısticas comuns: definem as propriedades compartilhadas pelos princi-
pais elementos f´ısicos que comp˜oem o ambiente;
Elementos b´asicos: s˜ao os elementos f´ısicos presentes nos ambientes;
34
Meios de comunica¸c˜ao: especificam as comunica¸c˜oes entre as entidades;
Eventos e sinaliza¸c˜oes: s˜ao respons´aveis por um tipo especial de comunica¸c˜ao e
transporte de informa¸c˜ao entre os elementos;
Controles: s˜ao estruturas para tratar quest˜oes de gerenciamento de energia, loca-
liza¸c˜ao, comunica¸c˜ao, tempo e situa¸c˜oes na especifica¸c˜ao;
Delimitadores espaciais: s˜ao objetos que possuem propriedades para definir a
delimita¸c˜ao dos espa¸cos f´ısicos;
Entidades ub´ıquas: correspondem `as entidades que possuem capacidade de com-
puta¸c˜ao e comunica¸c˜ao
Privacidade: categoria que estende o metamodelo, e que permite aos usu´arios a
cria¸c˜ao de pol´ıticas de privacidade para que os servi¸cos em ambientes ub´ıquos
n˜ao sejam invasivos ou utilizem suas informa¸c˜oes inadequadamente. Tamb´em
permite a cria¸c˜ao de perfis de usu´arios, onde eles especificam as informa¸c˜oes
que podem ser compartilhadas com outros usu´arios/servi¸cos.
As pr´oximas se¸c˜oes apresentam as principais classes da especifica¸c˜ao apresentada
por Campiolo (2005), bem como a especifica¸c˜ao completa das classes da categoria
de privacidade, propostas neste trabalho. Para a especifica¸c˜ao completa feita por
Campiolo (2005), recorra ao apˆendice A.
4.2 Defini¸c˜oes axiom´aticas, tipos b´asicos e tipos
livres
Um tipo b´asico ´e um recurso da linguagem formal Z que n˜ao possui a necessidade
de descrever atrav´es de estruturas matem´aticas ou formais o seu significado. De
acordo com (SPIVEY, 1989), o nome de um tipo b´asico deve ter uma defini¸c˜ao global
´unica e seu escopo se estende da defini¸c˜ao at´e o final da especifica¸c˜ao. A defini¸c˜ao
de tipos livres n˜ao adiciona nenhum poder `a linguagem Z, mas facilita a descri¸c˜ao
de estruturas recursivas tais como as listas e ´arvores. J´a as defini¸c˜oes axiom´aticas
permitem especificar tipos atrav´es de declara¸c˜oes formais e atribuir restri¸c˜oes aos
valores especificados. Esta se¸c˜ao apresenta e descreve os tipos b´asicos e as defini¸c˜oes
axiom´aticas utilizadas na especifica¸c˜ao de privacidade proposto neste trabalho.
35
H´a sete tipos b´asicos definidos, conforme pode ser observado em (CAMPIOLO,
2005):
[TEXT , TIME , DATE , SHAPE , DATA, ACTION , STATE ]
TEXT: representa um conjunto de caracteres para d escrever atrav´es de linguagem
natural algum tipo de propriedade ou caracter´ıstica, ou para ser utilizado como
um identificador;
TIME: corresponde a hora, minutos, segundos e cent´esimos de segundo;
DATE: corresponde a dia, mˆes e ano;
SHAPE: tem por objetivo estabelecer limites para forma de propaga¸c˜ao e alcance
de comunica¸c˜ao, delimita¸c˜ao de acesso, entre outros;
DATA: representa qualquer tipo de informa¸c˜ao digital;
ACTION: representa uma a¸c˜ao que modifica o estado de um objeto f´ısico, ou seja,
representa a execu¸c˜ao de uma tarefa;
STATE: representa os estados que os elementos possuem ou podem assumir.
Foi acrescentado `a especifica¸c˜ao a defini¸c˜ao d o tipo livre MODE, que define um
modo de opera¸c˜ao de um servi¸co em um ambiente ub´ıquo, como sendo um conjunto
definido pelos trˆes valores:
MODE ::= allow | deny | ask
Assim, uma pol´ıtica de privacidade pode ser criada, esp ecificando-se um servi¸co
em um dos modos de permiss˜ao existentes: permitido (allow), negado (deny), ou
em alguns casos, pode ser questionado (ask) se pode ou n˜ao ser executado.
H´a duas defini¸c˜oes axiom´aticas globais:
Properties : TEXT → DATA
Direction : {North, South, East, West, Northeast, Northwest,
Southeast, Southwest}
O tipo Properties, representado por uma fun¸c˜ao parcial, associa um identificador
a uma informa¸c˜ao. Por exemplo, pode-se definir uma fun¸c˜ao f : Properties, que
36
associa nomes com imagens. J´a o tipo Direction ´e um conjunto que define vetores
para orienta¸c˜ao no ambiente. Os vetores definidos s˜ao baseados nos pontos cardeais
(norte, sul, leste e oeste) e nos pontos colaterais (noroeste, nordeste, sudoeste e
sudeste).
4.3 Pessoas
A classe utilizada para especificar pessoas em ambientes ub´ıquos ´e a classe Per-
son. A figura 4.2 apresenta os principais elementos dessa classe. O tipo POSITIO-
NAL representa as posi¸c˜oes das pessoas no ambiente, assim como as caracter´ısticas
que se relacionam com a posi¸c˜ao, tais como velocidade, dire¸c˜ao e orienta¸c˜ao. J´a o
tipo PHYSICAL representa as caracter´ısticas f´ısicas como, por exemplo, sexo, idade,
peso, entre outros. O tipo PSYCHOLOGICAL representa as caracter´ısticas relaci-
onadas ao psicol´ogico, tais como emo¸c˜oes, interesses, temperamento, entre outros.
Person
ModelBase
[POSITIONAL, PHYSICAL, PSYCHOLOGICAL]
Personality : {Extraversion, Agreeableness, Conscientiousness,
EmotionalStability, Openness}
positional : P POSITIONAL
physical : P PHYSICAL
psychological : P PSYCHOLOGICAL
...
hasObject : F Object
hasEntity : F ↓Entity
Figura 4.2: Caracter´ısticas da classe Person
Por fim, as propriedades hasObject e hasEntity representam o relacionamento
das pessoas com os dispositivos e objetos no ambiente.
37
4.4 Entidades
Na especifica¸c˜ao, o termo entidade ´e utilizado para representar os elementos
dos ambientes ub´ıquos que possuem capacidades de computa¸c˜ao e comunica¸c˜ao.
A classe Entity (fi gura 4.3) representa a estrutura base para a especifica¸c˜ao dos
sensores, atuadores e dispositivos.
Entity
ModelBase
[PROCESS, PROTOCOL]
enabled : B
connections : seq ↓Entity
communication : seq PROTOCOL
channel : seq CommunicationChannel
Figura 4.3: Caracter´ısticas da classe Entity
A propriedade enabled define se a entidade est´a ativa ou inativa. As proprieda-
des connections, communication e channel especificam, respectivamente, com quais
entidades s˜ao mantidas conex˜oes, os protocolos e os canais f´ısicos de comunica¸c˜ao.
A classe Sensor (figura 4.4) representa os sensores em ambientes ub´ıquos e herda
todas as caracter´ısticas da classe ModelBase e Entity. A propriedade type especifica
uma identifica¸c˜ao num´erica para tratar sensores que reagem simultaneamente ao
mesmo sinal. As propriedades perceptionShape e perceptionDistance definem, res-
pectivamente, a forma e a distˆancia que um determinado sensor percebe a presen¸ca
de um sinal. A propriedade knownSignal especifica o tipo de sinal reconhecido e as
propriedades internalState e stateTransition gerenciam a mudan¸ca interna de estado
originada pela percep¸c˜ao de um sinal.
Os atuadores do ambiente podem ser representados utilizando a classe Actuator
(figura 4.5). A propriedade object define o conjunto de objetos que o atuador tem
acesso, enquanto a propriedade action define as a¸c˜oes que o atuador pode executar.
Por ´ultimo, a propriedade actuation ´e uma fun¸c˜ao que associa um comando, recebido
por uma conex˜ao, a um objeto e a a¸c˜ao que modifica seu estado.
38
Sensor
Entity
type : N
perceptionShape : SHAPE
perceptionDistance : N
knownSignal : SignalType
internalState : P STATE
stateTransition : Signal → (STATE ↔ STATE)
#knownSignal = 1
Figura 4.4: Caracter´ısticas da classe Sensor
Actuator
Entity
object : P ↓Object
action : P ACTION
actuation : Command → (Object ↔ ACTION )
Figura 4.5: Caracter´ısticas da classe Actuator
A classe Device (figura 4.6) ´e um modelo gen´erico de dispositivo que acomoda
os principais requisitos para a simula¸c˜ao. Os tipos b´asicos INPUT DEVICE e
OUTPUT DEVICE definem os dispositivos que fornecem entradas e sa´ıdas de da-
dos para um dispositivo ub´ıquo. Como os dispositivos podem ter diversas entradas
e sa´ıdas, as propriedades input e output especificam o conjunto de dispositivos de
entradas e sa´ıdas. As propriedades entry e exit definem uma associa¸c˜ao entre os
dispositivos de entrada e sa´ıda com o conjunto de dados. A propriedade aliveProcess
especifica os processos que est˜ao em execu¸c˜ao. A propriedade state define o conjunto
de vari´aveis de estados e a propriedade stateTransition define como as altera¸c˜oes so-
bre essas vari´aveis devem ocorrer. A propriedade event descreve o conjunto de
eventos gerados pelo dispositivo. A propriedade eventMap mapeia os eventos para
os dispositivos interessados. Assim, ´e necess´ario que todo dispositivo que tem inte-
resse em um evento remoto seja registrado ao dispositivo que origina o evento para
ser notificado.
As propriedades e funcionalidades da classe Device s˜ao a base para a defini¸c˜ao
das seguintes classes de dispositivos: embutidos, port´ateis e fixos. A classe Em-
39
Device
Entity
[INPUT DEVICE , OUTPUT DEVICE ]
pid, mid : N
model : TEXT
input : P INPUT DEVICE
output : P OUTPUT DEVICE
entry : INPUT DEVICE → P DATA
exit : OUTPUT DEVICE → P DATA
process : pid → PROCESS
aliveProcess : P(PROCESS)
state : P STATE
stateTransition : Event → (STATE ↔ STATE)
memory : P DATA
addressMemory : mid → DATA
event : P Event
eventMap : Even t → P Device
Figura 4.6: Caracter´ısticas da classe Device
beddedDevice atrav´es da propriedade embeddedIn especifica onde o dispositivo est´a
embutido. A classe PortableDevice atrav´es da propriedade owner especifica o dono
do dispositivo. A classe FixedDevice atrav´es da propriedade space indica o espa¸co
do ambiente no qual a esta¸c˜ao fixa se encontra.
4.5 Ambiente
A classe Environment (figura 4.7) representa o n´ıvel mais alto da hierarquia da
especifica¸c˜ao e ´e respons´avel por agrupar e gerenciar os espa¸cos no modelo.
Um ambiente ´e identificado p ela propriedade name. J´a a propriedade space
permite o agrupamento de todos os espa¸cos que comp˜oem o cen´ario modelado. A
condi¸c˜ao para a cria¸c˜ao de um ambiente, ´e que ele deve ser composto por, no m´ınimo,
um espa¸co. O ambiente utiliza os controladores de tempo, situa¸c˜ao, localiza¸c˜ao e
energia. O controlador de tempo ´e respons´avel por controlar e sincronizar o rel´ogio
de simula¸c˜ao e para definir os eventos dependentes do tempo. O controlador de
40
Environment
name : TEXT
space : F Space
timeController : TimeController
situationalController : SituationalController
locationController : LocationController
energyController : EnergyController
#space > 0
Figura 4.7: Caracter´ısticas da classe Environment
situa¸c˜ao ´e respons´avel por registrar situa¸c˜oes que dependem de eventos de elementos
presentes em espa¸cos comuns ou distintos. Os controladores de localiza¸c˜ao e energia
registram a localiza¸c˜ao e a energia de todas as entidades para prover com eficiˆencia
acesso e controle sobre elas.
4.6 Privacidade
Nesse trabalho, o metamodelo em (CAMPIOLO, 2005) foi estendido e carac-
ter´ısticas relativas `a privacidade da informa¸c˜ao foram incorporadas.
Em ambientes de computa¸c˜ao ub´ıqua fechados
1
, a quest˜ao da privacidade pode
ser garantida internamente por um sistema local. Assim, as viola¸c˜oes de privacidade
e os problemas originados pela comunica¸c˜ao devem ser protegidos, amenizados e
garantidos pelo ambiente.
Partindo desse pressuposto, no presente estudo, s˜ao considerados os problemas
que envolvem o ambiente e o indiv´ıduo dentro dos limites desse ambiente. Logo, a
intera¸c˜ao entre dispositivos de diferentes indiv´ıduos no ambiente n˜ao ´e abordada.
Um dos problemas iniciais se refere `a comunica¸c˜ao do dispositivo do usu´ario
com os dispositivos do ambiente. Al´em disso, toda a comunica¸c˜ao entre dispositivos
consome energia. Logo, ´e necess´ario evitar protocolos desgastantes e tentativas de
comunica¸c˜ao repetitivas.
Levando-se em considera¸c˜ao as restri¸c˜oes apresentadas, foram criadas trˆes novas
1
Ambientes de computa¸c˜ao ub´ıqua fechados s˜ao ambientes que s˜ao delimitados fisicamente e
onde a comunica¸c˜ao e computa¸c˜ao se restringem a esses limites.
41
classes para o metamodelo, as quais s˜ao apresentadas na figura 4.8.
Figura 4.8: Classes da especifica¸c˜ao de privacidade
A classe Service representa os servi¸cos em ambientes ub´ıquos e ´e melhor deta-
lhada na figura 4.9. Esses servi¸cos s˜ao fornecidos por dispositivos e sensores e, como
discutido na se¸c˜ao 3.5.1, podem ser intrusivos e incˆomodos, o que pode representar
s´erias amea¸cas `a privacidade de tais ambientes.
Service
ServiceState
identification : N
description : TEXT
created : TimeStamp
∀ x, y : identification • x = y
CreateService
∆(identification, description, created)
identification? : N
description? : TEXT
created? : TimeStamp
identification
= identification?
description
= description?
created
= created?
Figura 4.9: Caracter´ısticas da classe Service
A propriedade identification identifica de forma ´unica um servi¸co no ambiente.
42
J´a a propriedade description permite fornecer alguma informa¸c˜ao suficiente o bas-
tante para descrever as funcionalidades do servi¸co. Por ´ultimo, a propriedade created
possui o registro da data e hora de cria¸c˜ao do servi¸co.
O que pode amea¸car a privacidade dos indiv´ıduos em ambientes ub´ıquos s˜ao os
servi¸cos abusivos, como por exemplo, o envio de an´uncios e propagandas que n˜ao
s˜ao de interesse do usu´ario, monitoramento da localiza¸c˜ao do usu´ario, coleta de in-
forma¸c˜oes sem permiss˜ao, identifica¸c˜ao n˜ao autorizada, assim como outros exemplos
citados na se¸c˜ao 3.5.3.
Para evitar que qualquer servi¸co tenha acesso `as informa¸c˜oes pessoais das pessoas
de um determinado ambiente ub´ıquo, foi criada a classe PrivacyPolicy (figuras 4.8
e 4.10) para que um indiv´ıduo possa especificar quais servi¸cos podem ter acesso ou
n˜ao `as suas informa¸c˜oes.
PrivacyPolicy
MODE ::= allow | deny | ask
PolicyState
identification : N
service : Service
serviceProvider : P ↓Entity
defaultMode : MODE
unknownMode : MODE
temporalConstraint : seq(TIME × TIME )
Figura 4.10: Caracter´ısticas da classe PrivacyPolicy
A propriedade identification da classe PrivacyPolicy permite especificar unica-
mente uma pol´ıtica de privacidade no modelo. Para informar sobre qual servi¸co se
trata a pol´ıtica de privacidade, foi criada a propriedade service. A propriedade ser-
viceProvider permite informar um conjunto parcial de provedores de servi¸cos. Para
a execu¸c˜ao do servi¸co provido por esses provedores, a propriedade defaultMode deve
ser consultada, sendo que seus respectivos mo dos de opera¸c˜ao podem ser: allow,
deny ou ask (ver se¸c˜ao 4.2). Caso um provedor n˜ao seja relacionado, o modelo per-
mite especificar qual o modo padr˜ao de execu¸c˜ao de servi¸co atrav´es da propriedade
unknownMode. Se o modo for allow, todos os servi¸cos desconhecidos ter˜ao acesso `as
informa¸c˜oes pessoais; se for deny, todos os servi¸cos desconhecidos n˜ao ter˜ao acesso
43
e, por ´ultimo, se for ask, o usu´ario ter´a que ser consultado sobre o novo provedor de
servi¸cos e poder´a determinar se deseja ou n˜ao compartilhar suas informa¸c˜oes. Por
´ultimo, baseado na se¸c˜ao 3.5.2, foi criada a propriedade temporalConstraint, que
permite determinar quais os per´ıodos de tempo em que o servi¸co estar´a dispon´ıvel
ou n˜ao.
Para que o modelo tenha uma especifica¸c˜ao mais completa das informa¸c˜oes pes-
soais dos usu´arios e suas preferˆencias, foi elaborada a classe Profile, figuras 4.8 e
4.11.
Profile
ProfileState
identification : N
pseudonym : TEXT
personalProperties : P(TEXT × F T EXT )
servicePolicies : P PrivacyPolicy
mixingRate : N
∀ x, y : pseudonym • x = y
Figura 4.11: Caracter´ısticas da classe Profile
A propriedade identification da classe Profile identifica de forma ´unica um perfil
de um usu´ario. Utilizando-se do conceito de mixagem, apresentado na se¸c˜ao 3.5.6.3,
a propriedade pseudonym armazena o pseudˆonimo usado para identificar o dispo-
sitivo do usu´ario e permitir a mixagem. A propriedade personalProperties permite
especificar as preferˆencias pessoais, tais como, na categoria de esp ortes: futebol,
vˆolei, basquete, entre outros; e na categoria de filmes: de a¸c˜ao, com´edia, romance,
entre outros. A propriedade servicePolicies relaciona o perfil do usu´ario com as suas
pol´ıticas de privacidade, ou seja, o conjunto de servi¸cos que podem ter ou n˜ao acesso
`as informa¸c˜oes do seu perfil pessoal. Por fim, a propried ade mixingRate define uma
taxa m´ınima de indiv´ıduos que devem estar presentes para que ocorra uma mixagem.
Se a taxa for zero, significa que o u su´ario n˜ao quer participar da mixagem.
Al´em dessas considera¸c˜oes, p ara integrar os asp ectos de privacidade `a especi-
fica¸c˜ao feita por (CAMPIOLO, 2005), foi criada a propriedade profile na classe Per-
son, que permite associar a classe Profile `a uma pessoa; assim como a propriedade
offeredServices na classe Entity, que permite informar quais servi¸cos s˜ao fornecidos
44
por uma determinada entidade.
4.7 Considera¸c˜oes
Esse cap´ıtulo apresentou os principais elementos para representa¸c˜ao de um am-
biente de computa¸c˜ao ub´ıqua, com a preocupa¸c˜ao de preservar a privacidade das
pessoas contidas nesses ambientes. A especifica¸c˜ao de privacidade ´e limitada aos
ambientes de computa¸c˜ao ub´ıqua fechados, mas pode ser estendido para os demais
tipos de ambientes, desde que seja levada em considera¸c˜ao a complexidade do am-
biente que deseja-se estudar.
Com a elabora¸c˜ao da esp ecifica¸c˜ao, os conceitos de privacidade foram melhor
discutidos, esclarecidos e entendidos. Dessa forma, o pr´oximo cap´ıtulo apresenta a
aplica¸c˜ao da especifica¸c˜ao obtida no ambiente de um shopping center.
45
5 Prova de Conceito: Cen´ario
de um Shopping Center
Esse cap´ıtulo apresenta a aplica¸c˜ao do metamodelo apresentado no cap´ıtulo 4
para o cen´ario de um shopping center. A escolha deve-se ao fato de um shopping
center ser um cen´ario complexo, por ser composto por diversos outros cen´arios fe-
chados e abertos (lojas, ´areas de exposi¸c˜ao, sal˜oes, escadas rolantes, etc.), mas que
est˜ao bem delimitados fisicamente pela estrutura do shopping.
O objetivo ´e destacar a importˆancia e aplicabilidade do metamodelo elaborado,
bem como discutir os diversos p roblemas eminentes desse cen´ario, al´em de propor al-
gumas solu¸c˜oes vi´aveis. Apenas as principais classes s˜ao apresentadas nesse cap´ıtulo.
Para obter a aplica¸c˜ao completa, ´e necess´ario consultar o apˆendice C. Al´em disso,
ao final do cap´ıtulo ´e apresentado o cen´ario do shopping modelado na ferramenta
Opnet e uma an´alise d os resultados ´e feita com base na simula¸c˜ao obtida.
5.1 O Cen´ario
Conforme previamente apresentado em (CAMPIOLO, 2005), o shopping center
(figura 5.1) corresponde a um cen´ario composto por uma grande quantidade de pes-
soas com seus dispositivos e por diversos espa¸cos fechados e abertos, bem delimitados
fisicamente pela estrutura do shopping. H´a sensores e dispositivos distribu´ıdos, mo-
nitorando e fornecendo servi¸cos para os indiv´ıduos nos limites internos do ambiente.
Os servi¸cos tˆem como objetivo conquistar e fornecer comodidade aos usu´arios. Para
os servi¸cos n˜ao serem invasivos, isto ´e, n˜ao cometerem abusos, o ambiente disp˜oe de
uma infra-estrutura para proteger a privacidade de seus usu´arios.
Os dispositivos e sensores podem estar localizados no espa¸co de lojas. Eles
podem se comunicar internamente na loja, isto ´e, o dispositivo de um cliente ´e
46
Figura 5.1: Ilustra¸c˜ao do cen´ario shopping. Fonte: (CAMPIOLO, 2005)
detectado dentro dos limites da loja, ou ainda se comunicar a uma determinada
distˆancia externa `a loja. O mesmo princ´ıpio ´e v´alido para os sensores. Al´em disso,
sensores e dispositivos podem ser de propriedade do shopping e estarem distribu´ıdos
em outros pontos, sendo compartilhados por diversas lojas.
5.2 Problema espec´ıfico
O cen´ario a seguir ilustra um problema espec´ıfico de privacidade no ambiente
de estudo. Alice p ossui um perfil que ´e composto de duas partes: um conjunto de
proposi¸c˜oes fornecido por Alice (perfil A) e um conjunto de proposi¸c˜oes inferido pelo
sistema ou por outras entidades (perfil B).
Alice pode determinar de que forma o perfil A pode ser utilizado pelo sistema,
no todo ou para um prop´osito espec´ıfico. J´a sobre o perfil B, seu controle ´e bastante
limitado, pois Alice pode nem saber de sua existˆencia. Por exemplo, considere que
Alice prepara o perfil A indicando que gosta de gin´astica, filmes de a¸c˜ao e livros de
auto-ajuda, conforme mostra a figura 5.2. A estrutura nomeada alice, representa
a especifica¸c˜ao da classe Person que instancia Alice no ambiente. Nesse caso, a
identifica¸c˜ao alice foi utilizada como valor da propriedade pseudonym, p ois Alice
optou p or n˜ao participar de mixagem (propriedade mixingRate ´e zero), ou seja, n˜ao
47
deseja manter seu anonimato. Esse assunto volta a ser discutido na se¸c˜ao 5.6.
Profile : profile A
identification = 14
pseudonym = alice
personalProperties = {sports, {gymnastics}}, {films, {action movies}},
{books, {self help}}
servicePolicies = marketing policy
mixingRate = 0
Figura 5.2: Perfil A fornecido por Alice
A figura 5.3 apresenta a pol´ıtica de privacidade de Alice, onde ela determina que
suas informa¸c˜oes utilizadas pelo servi¸co de propaganda (marketing service), n˜ao
devem ser repassados a terceiros, apenas para as livrarias L e M. Al´em disso, atrav´es
da propriedade temporalConstraint, Alice definiu uma restri¸c˜ao temporal alegando
que deseja ser abordada por esses servi¸cos somente no hor´ario das 8h `as 18h.
PrivacyPolicy : marketing policy
identification = 16
service = marketing service
serviceProvider = sen bookstore L, sen bookstore M
defaultMode = allow
unknownMode = deny
temporalConstraint : (8h00m00s, 18h00m00s)
Figura 5.3: Pol´ıtica de privacidade para o servi¸co de propaganda
Agora, sup onh a que Alice realize algumas compras de livros sobre viagens na
livraria L, uma ou mais vezes por mˆes num per´ıodo de seis meses. Pode-se supor
que esses livros s˜ao para ela mesma, pois ´e dif´ıcil que sejam pr esentes (a n˜ao ser
que Alice conhe¸ca v´arios amigos que gostem de viajar e fa¸cam anivers´ario dentro
deste p er´ıodo). Assim, esta livraria tem condi¸c˜oes de criar um segundo perfil para
Alice, o perfil B da figura 5.4, que ´e uma c´opia do perfil A fornecido por ela, com
um valor a mais na pr opriedade personalProperties, dizendo que ela gosta de livros
de viagens, fato que ela n˜ao revelou pessoalmente.
´
E importante considerar que esta informa¸c˜ao ´e produzida sem o conhecimento
48
Profile : profile B
identification = 15
pseudonym = alice
personalProperties = {sports, {gymnastics}}, {films, {action movies}},
{books, {self help, traveling}}
servicePolicies = marketing policy
mixingRate = 0
Figura 5.4: Perfil B inferido pelo sistema
de Alice, n˜ao se enquadra na restri¸c˜ao de n˜ao ser fornecida a terceiros e constitui
um perfil B ainda mais preciso do que o per fil A fornecido pessoalmente por ela.
Agora, suponha que Alice vai ao shopping portando u m handheld (estrutura
handheld) com a sua identifica¸c˜ao n˜ao amb´ıgua e seu perfil A armazenado. J´a na
entrada, Alice ´e identificada, o perfil A ´e lido e o perfil B ´e resgatado pelo sistema.
Ao passar pr´oxima `a livraria M, Alice recebe uma mensagem informando de
algumas promo¸c˜oes de livros de viagens. Isso pode ser abordado de v´arios pontos
de vista. Alice n˜ao colocou a informa¸c˜ao de que gosta de livros de viagens no perfil
A, porque prefere pesquisar pessoalmente quando tem uma necessidade espec´ıfica.
Suponha que ela viaje muito a trabalho, mas n˜ao pode determinar seu destino
com antecedˆen cia. Neste caso, n˜ao adianta receber avisos de promo¸c˜oes. Alice
sabe que as informa¸c˜oes colocadas em seu perfil A s˜ao utilizadas para que diversas
empresas possam fazer ofertas personalizadas. Por outro lado, essas ofertas podem
ser interessantes para Alice, pois podem ser mais de acordo com seus interesses,
al´em de proporcionar uma boa economia em alguns casos.
De qualquer modo, o objetivo das empresas ´e vender, o que necessariamente n˜ao
significa satisfazer Alice completamente, nem respeitar sua vontade.
5.3 Modelo e arquitetura do ambiente
A estrutura f´ısica do ambiente permanece idˆentica a apresentada na figura 5.1.
S˜ao adicionados apenas novos sensores e dispositivos em algumas ´areas do ambiente.
Nas entradas e sa´ıdas do ambiente, encontram-se os sensores respons´aveis por
49
coletar as pol´ıticas de privacidade do usu´ario. Estes sensores s˜ao chamados de
sensores E/S. Um exemplo desse tipo de sensor na especifica¸c˜ao ´e o senIO. Somente
os sensores E/S recolhem as pol´ıticas de privacidade. Logo, necessita-se de uma
entidade para armazenar essas pol´ıticas.
A entidade respons´avel por armazenar as p ol´ıticas de seguran¸ca ´e o servidor
central server. Este servidor recebe dos sensores E/S as informa¸c˜oes coletadas
do dispositivo do usu´ario. Para simplificar o entendimento, essas informa¸c˜oes s˜ao
representadas na propriedade memory. Os sensores e dispositivos locais acessam
as pol´ıticas de privacidade de um cliente atrav´es de uma conex˜ao com o servidor
central. Assim, os protocolos de comunica¸c˜ao com os dispositivos tornam- se me-
nos desgastantes e economizam a bateria do dispositivo do cliente. Os sensores
sen
bookstore L e sen bookstore M s˜ao os sensores locais das livrarias L e M,
respectivamente, que possuem essa responsabilidade.
O mesmo efeito ´e alcan¸cado com a coleta do arquivo de pol´ıticas de privacidade
na entrada. A coleta ´e realizada por comunica¸c˜ao sem fio (r´adio). A distˆancia entre
o dispositivo coletor e o d ispositivo do cliente ´e pequena. Logo, a energia despendida
e a perda de pacotes s˜ao bem menores.
Os sensores E/S devem ser isolados e ter um alcance de extens˜ao, ou seja, n˜ao
devem permitir um sensor externo recuperar ou atrapalhar a coleta das pol´ıticas
de privacidade e devem garantir que o dispositivo do cliente permane¸ca na faixa de
transmiss˜ao at´e o t´ermino do protocolo.
O ´ultimo elemento de arquitetura adicionado s˜ao as zonas de mixagem (se¸c˜ao
3.5.6.3), onde nenhum dos usu´arios pode ser localizado por servi¸cos. No ambiente
estudado, as zonas de mixagem encontram-se na regi˜ao central e nos ambientes
de exposi¸c˜ao do shopping (figura 5.5), pois, nesses locais, h´a uma constante movi-
menta¸c˜ao de pessoas.
5.4 Modelo da pol´ıtica de privacidade
Neste modelo, o foco s˜ao os servi¸cos disponib ilizados. Cada servi¸co ´e represen-
tado por uma marca no arquivo e cont´em as a¸c˜oes padr˜oes, negar ou permitir o
servi¸co, para os estabelecimentos comerciais listados, al´em de uma a¸c˜ao para lojas
n˜ao listadas.
50
Figura 5.5: Ilustra¸c˜ao do cen´ario shopping. Fonte: (CAMPIOLO, 2005)
Um exemplo de um servi¸co que ´e permitido a duas lojas ´e apresentado na figura
5.6. Caso alguma outra tente fornecer o servi¸co, o usu´ario poder´a ser consultado se
deseja ou n˜ao, tal servi¸co. No segundo servi¸co (figura 5.7), o usu´ario j´a configurou
que o servi¸co seja negado para qualquer outra loja n˜ao listada.
A figura 5.8 apresenta a situa¸c˜ao onde o usu´ario deseja sempre receber um
servi¸co. J´a, para o caso contr´ario, a figura 5.9 apresenta a situa¸c˜ao onde o usu´ario
nunca deseja receber um determinado servi¸co.
A pr´oxima se¸c˜ao apresenta o funcionamento dos protocolos de comunica¸c˜ao uti-
lizados no ambiente de estudo.
PrivacyPolicy : Example1
identification = 1
service = service 1
serviceProvider = store 1, store 2
defaultMode = allow
unknownMode = ask
Figura 5.6: Pol´ıtica de privacidade que d´a permiss˜ao de um servi¸co `a duas lojas,
permitindo que para as lojas desconhecidas o usu´ario seja consultado
51
PrivacyPolicy : Example2
identification = 2
service = service 2
serviceProvider = store 1, store 2
defaultMode = allow
unknownMode = deny
Figura 5.7: Pol´ıtica de privacidade que d´a permiss˜ao de um servi¸co `a duas lojas,
mas que n˜ao d´a permiss˜ao `a nenhuma outra
PrivacyPolicy : Example3
identification = 3
service = service 3
unknownMode = allow
Figura 5.8: Pol´ıtica de privacidade que d´a sempre permiss˜ao de um servi¸co `a
qualquer loja
PrivacyPolicy : Example4
identification = 4
service = service 4
unknownMode = deny
Figura 5.9: Pol´ıtica de privacidade que n˜ao d´a acesso de nenhum servi¸co `a
nenhuma loja
5.5 Entendendo os protocolos
Para facilitar a compreens˜ao, as implica¸c˜oes e o funcionament o dos protocolos,
estes s˜ao descritos baseados nas poss´ıveis situa¸c˜oes que um cliente encontra ao entrar
em um ambiente de computa¸c˜ao ub´ıqua fechado.
5.5.1 Entrada de um cliente/usu´ario
Um cliente, ao entrar no ambiente portando seu dispositivo de computa¸c˜ao
ub´ıqua, inicia a comunica¸c˜ao com os sensores E/S. O arquivo de pol´ıtica de privaci-
dade e a identifica¸c˜ao do cliente s˜ao transmitidos. O servidor gera um pseudˆonimo
52
para o registro do cliente, o qual funciona como uma chave para recupera¸c˜ao das
pol´ıticas. O disp ositivo do cliente recebe essa identifica¸c˜ao ´unica e a armazena no
campo correspondente. A comunica¸c˜ao ´e encerrada.
5.5.2 Detec¸c˜ao de um cliente por um sensor
Ao detectarem a presen¸ca de um dispositivo, os sensores do ambiente ou es-
tabelecimento, atrav´es de um protocolo simples, obtˆem o seu pseudˆonimo. Ap´os
isso, consultam o servidor central para determinar as pol´ıticas de privacidade do
usu´ario portador do dispositivo. Se estiver registrado o interesse do usu´ario por
algum servi¸co fornecido, inicia-se um protocolo para atendˆe-lo.
5.5.3 Cliente finaliza a comunica¸c˜ao com um dispositivo
Um cliente, ao sair de u m estabelecimento ou do alcance de um sensor ou dispo-
sitivo, finaliza seus v´ınculos e a marca de mixagem ´e redefinida. Logo, ao transitar
por uma zona de mixagem, este dispositivo receber´a um novo pseudˆonimo e sua
marca de mixagem ser´a novamente redefinida.
5.6 Aplicando o modelo a um problema
Nesta se¸c˜ao, o problema da Alice (se¸c˜ao 5.2) ´e retomado e as situa¸c˜oes descritas
no problema s˜ao aplicadas ao modelo proposto. A gera¸c˜ao do perfil B, em que ´e
registrado o interesse de Alice por livros de viagens, ´e inevit´avel, uma vez que para a
realiza¸c˜ao das compras, Alice se identifica, seja por meio do cr´edito, ou outro qual-
quer, tal como a lembran¸ca do vendedor ou at´e mesmo sistemas de reconhecimento
facial usado nas cˆameras de seguran¸ca da loja.
Dada a inevitabilidade da gera¸c˜ao de um perfil B, a solu¸c˜ao para se manter
a privacidade de Alice ´e dissoci´a-la de seu perfil B. Isto pode ser feito atribuindo
a Alice um pseudˆonimo que ser´a usado para identific´a-la. Assim, ao passar pelos
sensores da loja, Alice n˜ao ser´a identificada e, conseq¨uentemente, n˜ao ligada ao seu
perfil B. Partindo da id´eia de que Alice deseja ter anonimato, o novo perfil A de
Alice com o seu novo pseudˆonimo gerado automaticamente pelo servidor central ´e
apresentado na figura 5.10.
53
Profile : profile A
identification = 14
pseudonym = 4fasd452
personalProperties = {sports, {gymnastics}}, {films, {action movies}},
{books, {self help}}
servicePolicies = marketing policy
mixingRate = 1
Figura 5.10: Perfil A fornecido por Alice
Entretanto, h´a situa¸c˜oes em que Alice dever´a se identificar, como por exemplo,
ao realizar um pagamento com cart˜ao de cr´edito. Neste momento, os sistemas podem
localizar Alice, uma vez que ela foi relacionada com o pseudˆonimo usado. A solu¸c˜ao
´e trocar o seu pseudˆonimo novamente.
Obrigar um usu´ario a sair e entrar novamente no ambiente visando a mudan¸ca
do pseudˆonimo n˜ao ´e algo plaus´ıvel. Para isso, existem as zonas de mixagem, em
que Alice pode literalment e se misturar a multid˜ao, emergindo desta zona com um
novo pseudˆonimo n˜ao rastre´avel pelos estabelecimentos comerciais.
Assim, mesmo nos casos em que a identidade de Alice possa ser inferida pelos
seus h´abitos (h´abitos como a visita espec´ıfica a determinadas lojas numa ordem em
um determinado hor´ario), basta que Alice passe por uma zona de mixagem para o
seu anonimato permanecer.
No caso do shopping, as zonas de mixagem s˜ao pontos centrais em que o usu´ario
sempre transita, seja para mudar de n´ıvel, seja para ver outras lojas. Assim, as
chances de rastreamento e identifica¸c˜ao passam a ser muito baixas, salvo nas ocasi˜oes
em que as taxas de mixagem forem muito baixas.
5.7 Simulando o cen´ario
O modelo elaborado para tratar das quest˜oes de privacidade em ambientes
de computa¸c˜ao ub´ıqua fechados apresenta uma solu¸c˜ao, baseada em restri¸c˜oes de
servi¸co atrav´es de pol´ıticas de privacidade definidas pelo usu´ario, satisfat´oria para
solucionar os problemas de invas˜ao da privacidade causados por servi¸cos oferecidos
em tais ambientes.
54
O modelo da arquitetura e de dados desenvolvido atendeu aos requisitos, evi-
tando tr´afego de pacotes desnecess´arios e desperd´ıcio de bateria dos dispositivos do
cliente.
A discuss˜ao das quest˜oes de privacidade permitiu uma reflex˜ao sobre quais as
futuras preocupa¸c˜oes e preven¸c˜oes que os usu´arios e as aplica¸c˜oes devem considerar
para a utiliza¸c˜ao de dispositivos e ambientes de computa¸c˜ao ub´ıqua.
Essa se¸c˜ao apresenta uma simula¸c˜ao realizada p ara esse cen´ario de estudo, com-
provando a efic´acia da solu¸c˜ao apresentada.
5.7.1 O simulador Opnet
O Opnet (Optimized Network Engineering Tool) Modeler, ou simplesmente Op-
net, foi introduzido em 1986 pelo MIT e permite projetar e estudar redes de comu-
nica¸c˜ao, dispositivos, protocolos e aplica¸c˜ao.
Os modelos no Opnet s˜ao hier´arquicos. Como mostra a figura 5.11, no n´ıvel
mais baixo, o comportamento de um algoritmo ou protocolo ´e codificado por um
diagrama de estados finitos com c´odigo embutido baseado na linguagem C/C++. No
n´ıvel intermedi´ario, fun¸c˜oes discretas como processamento, transmiss˜ao e recep¸c˜ao
de pacotes de dados s˜ao executados por objetos separados, os quais se comportam
como definido no seu modelo de processo. Esses objetos, chamados m´odulos, s˜ao
conectados para formar o modelo da rede, que na h ierarquia, ´e o modelo de mais
alto n´ıvel. Esse modelo, por fim, ´e o que d efine o escopo de uma simula¸c˜ao.
Todos os componentes s˜ao modelados utilizando a abordagem orientada a objeto,
o que facilita o mapeamento para os sistemas reais. Tamb´em possui um a plataforma
flex´ıvel para testar novas solu¸c˜oes de redes e com baixo custo.
A ferramenta Opnet, se comparada com outras como NS2, se destaca pela faci-
lidade de uso, qualidade da documenta¸c˜ao e pelas plataformas de simula¸c˜ao. Al´em
disso, o Opnet possui maior sup orte `as tecnologias de redes sem fio, o que satisfaz
as necessidades para a simula¸c˜ao do ambiente do shopping.
O Opnet ´e bem aceito no meio acadˆemico devido `a confian¸ca nos resultados
que oferece aos seus usu´arios e tamb´em porque permite uma an´alise real´ıstica de
m´etricas de desempenho (RAZAK; ZHOU; LANG, 2002).
55
Figura 5.11: A estrutura hier´arquica dos modelos no Opnet
Uma das caracter´ısticas mais importantes do Opnet ´e o fato de utilizar mode-
los que s˜ao especificados em termos de objetos, os quais possuem um conjunto de
atributos configur´aveis permitindo assim, a defini¸c˜ao de novos objetos com carac-
ter´ısticas program´aveis e f´acil extens˜ao. Essa caracter´ıstica foi fundamental para a
cria¸c˜ao dos objetos utilizados no cen´ario do shopping. Al´em disso, permite que o
pr´oprio usu´ario defina qualquer tipo de formato de pacote para que seja usado em
novos protocolos. Assim, foi poss´ıvel criar os pacotes do cen´ario do shopping e os
protocolos de comunica¸c˜ao.
As principais caracter´ısticas do Opnet podem ser resumidas em (CHANG, 1999):
Ciclo de Modelagem e Simula¸c˜ao: o Opnet provˆe ferramentas para ajudar o
usu´ario a construir modelos, executar a simula¸c˜ao e analisar os resultados,
conforme mostra a figura 5.12;
56
Modelagem hier´arquica: o Opnet emprega uma estrutura hier´arquica para mo-
delagem. Cada n´ıvel da hierarquia descreve os diferentes aspectos do modelo
completo a ser simulado;
Especializado em redes de comunica¸c˜ao: modelos de bibliotecas detalhadas pro-
vˆeem o suporte para protocolos existentes e permitem aos usu´arios e desen-
volvedores modificar estes modelos existentes ou desenvolver novos modelos;
Gera¸c˜ao de simula¸c˜ao autom´atica: os modelos do Opnet podem ser compila-
dos em c´odigo execut´avel. O n´ucleo do Opnet consiste em c´odigos C/C++,
permitindo que uma simula¸c˜ao de evento discreto possa ser depurada ou sim-
plesmente executada, gerando dados para serem analisados.
Figura 5.12: Ciclo de Modelagem e Simula¸c˜ao do Opnet baseada em (CHANG,
1999)
Por fim, ´e importante destacar que o Opnet n˜ao ´e um software de c´odigo aberto,
por´em, permite que muitos parˆametros de simula¸c˜ao sejam alterados, tendo um
efeito significante na simula¸c˜ao. O Opnet Modeler ´e apenas uma das muitas ferra-
mentas do conjunto de tecnologias Opnet e a vers˜ao utilizada nessa disserta¸c˜ao ´e a
11.5.
57
5.7.2 O ambiente representado no Opnet
Para a simula¸c˜ao foi considerado um ambiente simplificado do shopping descrito
na se¸c˜ao 5.1. No ambiente simulado h ´a duas livrarias, representadas pelos sensores
Bookstore L Sensor e Bookstore M Sensor; 3 cen´arios: o primeiro com 50
usu´arios, o segundo com 100 usu´arios e o terceiro com 300 usu´arios os quais s˜ao
representados pelos seus dispositivos m´oveis; o servidor central ou Server; uma
zona de mixagem representada pelo Mix Sensor e um sensor E/S que ´e o IO
Sensor. Esses elementos s˜ao apresentados no modelo de rede do Opnet, na figura
5.13.
Figura 5.13: Cen´ario do shopping no Opnet.
58
A seguir ´e descrita a forma da troca de mensagens bem como os m´odulos dos
elementos do shopping.
5.7.2.1 Pacotes para troca de mensagens
Para a troca de mensagens entre os elementos do shopping foram desenvolvidos
os seguintes pacotes:
• shopping
sensor requests pck ou pacote de requisi¸c˜ao;
• shopping profile pck ou pacote de perfil;
• shopping pseudonym pck ou pacote de pseudˆonimo;
• shopping new pseudonym pck ou pacote de pseudˆonimo novo, criado pelo sen-
sor de mixagem e ´util apenas para os usu´arios que desejarem participar da
mixagem;
• shopping
service policies of user pck ou pacote de pol´ıticas de servi¸co do usu´ario;
• shopping
mixing pck ou pacote de mixagem;
• shopping marketing pck ou pacote de propaganda.
A seguir, cada um desses pacotes e seus campos s˜ao apresentados e melhor
detalhados.
Pacote de requisi¸c˜ao
O pacote de requisi¸c˜ao ´e utilizado pelos sensores d as livrarias, pelo sensor de
mixagem e pelo sensor E/S para fazer as solicita¸c˜oes ao usu´ario. Como mostra a
figura 5.14, esse pacote possui trˆes campos: description, IP source e text.
O campo description poder´a ter um dos seguintes valores:
• Profile: quando a requisi¸c˜ao for feita pelo sensor E/S, indicando a solicita¸c˜ao
do perfil do usu´ario;
• Pseudonym: quando a requisi¸c˜ao for feita pelo sensor de alguma livraria, in-
dicando a solicita¸c˜ao do pseudˆonimo do usu´ario;
59
Figura 5.14: Pacote de requisi¸c˜ao
• Mix : quando a requisi¸c˜ao for feita pelo sensor de mixagem, indicando a soli-
cita¸c˜ao da indica¸c˜ao do usu´ario sobre participar ou n˜ao da mixagem;
• New Pseudonym: quando a requisi¸c˜ao for feita pelo sensor de mixagem ao
servidor, indicando a solicita¸c˜ao da gera¸c˜ao de um novo pseudˆonimo. Nesse
caso, no campo Text ´e enviado o pseudˆonimo atual do usu´ario.
J´a o campo IP source serve para armazenar o IP que originou a requisi¸c˜ao para
que o usu´ario ou o servidor possam enviar a resposta.
Pacote de p erfil
Quando o usu´ario recebe um pacote d e requisi¸c˜ao do tipo Profile, envia imedi-
atamente ao sensor E/S um pacote com o seu p erfi l. Esse pacote ´e ent˜ao recebido
pelo sensor E/S e encaminhado ao servidor, que o armazena para futuras consultas
pelos sensores das livrarias.
De acordo com a figura 5.15, o pacote perfil possui os seguintes campos: IP
user, pseudonym, personalProperties, servicePolicies, mixingRate, name,
lastName, IP source e IP destination.
Os campos IP user e pseudonym possuem os valores do IP do disp ositivo
do usu´ario e o seu pseudˆonimo, respectivamente. O campo p ersonalProperties,
figura 5.16, ´e uma lista, onde cada elemento possui os campos type e value list. O
campo type indica a categoria da propriedade pessoal como, por exemplo: esp ortes,
filmes e livros. J´a o campo value list ´e um camp o complementar ao campo type
60
Figura 5.15: Pacote de perfil
e possui os valores daquela categoria. Por exemplo, na categoria esportes pode-se
ter: gin´astica, vˆolei e futebol.
Figura 5.16: Campo personalProperties do pacote perfil.
O campo servicePolicies do pacote perfil possui as pol´ıticas de acesso dos
servi¸cos de interesse do usu´ario ou pol´ıticas de privacidade. Assim como o campo
personalProperties, esse tamb´em ´e uma lista. Cada elemento dessa lista pos-
sui os seguintes atributos: identification, service, service
provider list,
61
default
mode, unknown mode, hour ini, min ini, hour end e min end. O
campo identification serve para identificar unicamente a pol´ıtica de p rivacidade.
O campo service ´e uma descri¸c˜ao para o servi¸co oferecido pela loja como, por exem-
plo, o servi¸co de propaganda. J´a service provider list ´e uma lista que identifica
quais os provedores do servi¸co que tˆem permiss˜ao para o usu´ario em quest˜ao. Os
campos default mode e unknown mode definem qual a permiss˜ao padr˜ao e qual
o n´ıvel de acesso permitido para provedores desconhecidos, respectivamente. Para
esses dois campos os valores poss´ıveis s˜ao: allow, deny e ask, conforme apresentado
na se¸c˜ao 4.6. Al´em disso, os campos hour
ini, min ini, hour end e min end
permitem que o usu´ario determine em qual hor´ario ele deseja ser ab ord ado pelo
provedor de servi¸co. Por exemplo, no hor´ario comercial seria das 8h `as 18h.
O campo mixingRate permite que o usu´ario determine se deseja ou n˜ao par-
ticipar da mixagem ao entrar em uma zona de mixagem. Caso este campo esteja
como zero, significa que ele n˜ao deseja fazer parte da mixagem.
Por fim, os campos name, lastName, IP source e I P destination identificam
o nome e sobrenome do usu´ario, IP origem e destino do pacote perfil que ser´a enviado.
Pacote de pseudˆonimo
Ao entrar no shopping o dispositivo do usu´ario ´e abordado pelo sensor E/S, o
qual solicita o seu perfil. Recebendo esse perfil, o sensor envia ao servidor o perfil do
usu´ario para que seja armazenado em sua lista interna de usu´arios. Nesse momento,
o servidor gera um pseudˆonimo para o usu´ario que ´e enviado ao sensor E/S e o
pr´oprio sensor se encarrega de encaminhar o pseudˆonimo ao usu´ario.
Ao passar pr´oximo `a uma livraria, o sensor dessa livraria inicia uma comu-
nica¸c˜ao com o usu´ario para obter o seu pseudˆonimo. Ap´os recebido o pacote com o
pseudˆonimo do usu´ario, o sensor envia-o ao servidor que o encaminha as pol´ıticas de
privacidade do usu´ario. Se for verificado que o sensor possui permiss˜ao para enviar
propagandas ao usu´ario, esse servi¸co ´e executado.
Conforme apresenta a figura 5.17, o pacote de pseudˆonimo possui o campo pseu-
donym, que identifica o pseudˆonimo do usu´ario; o campo IP user, que indica sem-
pre o IP do usu´ario, u tilizado apenas pelo servidor, quando este gera o pseudˆonimo
do usu´ario e envia ao sensor E/S; e os campos IP source e IP destination, que s˜ao,
62
respectivamente, o IP de origem e destino do pacote. O dispositivo do cliente nunca
preenche o campo IP source, apenas os campos pseudonym e IP destination.
Figura 5.17: Pacote de pseudˆonimo.
Pacote de pseudˆonimo novo
O pacote de pseudˆonimo novo, figura 5.18, ´e utilizado pelo servidor e pelo sen-
sor de mixagem. Ao passar pr´oximo ao sensor de mixagem, o usu´ario ´e questionado
sobre o seu interesse em participar ou n˜ao da mixagem. Caso essa verifica¸c˜ao seja
positiva, o sensor de mixagem solicita ao servidor um novo pseudˆonimo para o cli-
ente. O servidor ent˜ao gera um novo pseudˆonimo, atualiza-o na sua lista de usu´arios
para o usu´ario em quest˜ao e envia o novo pseudˆonimo gerado ao sensor de mixa-
gem. O sensor de mixagem ent˜ao encaminha o novo pseudˆonimo ao client e, campo
new pseudonym, que ´e identificado pelo pseudˆonimo antigo, campo pseudonym.
Al´em disso, possui o campo IP source para identificar quem enviou o pacote.
Pacote de mixagem
Quando o sensor de mixagem detecta um usu´ario novo, esse faz uma requisi¸c˜ao
ao usu´ario para que envie o pacote de mixagem, apresentado na figura 5.19. Esse
pacote ter´a o valor da taxa de mixagem, indicando se o usu´ario deseja ou n˜ao
participar da mixagem. Se o campo mixing for zero, indica que o u su´ario n˜ao
deseja participar da zona de mixagem. Caso tenha o valor 1, indica que o usu´ario
deseja ter o seu pseudˆonimo alterado, ao entrar em uma zona de mixagem.
63
Figura 5.18: Pacote de pseudˆonimo novo.
Figura 5.19: Pacote de mixagem.
O campo pseudonym indica o pseudˆonimo do usu´ario e o campo IP destina-
tion indica o IP d estino do pacote.
Pacote de p ol´ıticas de servi¸co do usu´ario
O pacote de pol´ıticas de servi¸co do usu´ario, apresentado na figura 5.20, ´e o
pacote que ´e enviado do servidor ao sensor de uma livraria, p ara que este possa
identificar quais as preferˆencias pessoais do usu´ario com o objetivo de prestar um
servi¸co mais personalizado a ele, de acordo com os seus interesses. Vale destacar
que, este pacote s´o ´e enviado ao sensor, caso o servidor verifique nas pol´ıticas de
privacidade d o usu´ario que o sensor possui permiss˜ao para prestar servi¸cos para
aquele usu´ario.
O campo pseudonym identifica o pseudˆonimo do usu´ario. Os campos servi-
cePolicies e personalProperties tˆem a mesma estrutura apresentada para esses
64
Figura 5.20: Pacote de pol´ıticas de servi¸co do usu´ario.
mesmos campos no pacote perfil. Por fim, o campo IP destination indica para
qual sensor o pacote ser´a enviado.
Pacote de propaganda
Ap´os verificada as preferˆencias pessoais do usu´ario, o pacote de propaganda,
figura 5.21, ´e enviado com as propagandas que s˜ao do interesse do usu´ario. O
usu´ario ´e identificado pelo campo pseudonym e a lista de produtos pelo campo
productList.
Figura 5.21: Pacote de propaganda.
O campo productList ´e uma lista com os campos name e price, que identifi-
cam respectivamente, o nome e o pre¸co do produto.
65
5.7.2.2 Modelo do n´o sensor E/S
Como apresentado na figura 5.11, cada n´o de rede representado no Opnet consta
de um modelo de n´o e de um modelo de processo. O modelo do n´o sensor E/S
´e apresentado na figura 5.22. Como pode-se perceber h´a dois fluxos de entrada
(stream 0 e stream 1) e um fluxo de sa´ıda.
Figura 5.22: Modelo do n´o sensor E/S.
O n´o sensor ´e o respons´avel por capturar as informa¸c˜oes dos usu´arios e en -
caminh´a-las ao servidor, e vice-versa. O n´o sensor envia periodicamente paco-
tes de requisi¸c˜ao ou shopping sensor requests pck do tipo Profile aos novos
usu´arios do shopping para dar in´ıcio `a troca de mensagens. Caso algum usu´ario
responda `a essas requisi¸c˜oes, ´e pelo fluxo 0 que o sensor ir´a receber os pacotes do
tipo shopping profile pck do usu´ario e os enviar´a pelo fluxo de sa´ıda ao ser vidor.
O servidor ent˜ao gerar´a um pseudˆonimo para esse usu´ario, e enviar´a ao sensor E/S.
´
E pelo fluxo 1 que o sensor receber´a os pacotes do tipo shopping
pseudonym pck
do servidor e os enviar´a pelo fluxo de sa´ıda ao usu´ario.
A figura 5.23 apresenta o modelo de processo do sensor E/S. H´a quatro estados:
start, send, wait e end. O estado start carrega a vari´avel de estrutura Address
66
(figura 5.24) com os valores IP informados na interface do n´o, exibida na figura 5.25.
Como pode-se observar, o n´o sensor E/S, assim como tod os os outros sensores do
ambiente, trabalha com duas BSS: 0 e 1. A BSS 1 ´e para comunica¸c˜ao com o usu´ario
e a BSS 0 ´e para a comunica¸c˜ao entre os sensores e o servidor.
Figura 5.23: Modelo de processo do n´o sensor E/S.
Figura 5.24: Estrutura Address.
O estado send ´e o que envia pacotes de requisi¸c˜ao aos n ovos usu´arios do shop-
ping, que s˜ao os pacotes shopping sensor requests pck do tipo Profile, como
pode ser visto na figura 5.26.
Ap´os enviar essa requisi¸c˜ao, a m´aquina de estados assume o estado wait. Nesse
estado o sensor aguarda pacotes do usu´ario (fluxo 0) ou do servidor (fluxo 1).
Esse estado tamb´em pode voltar ao estado send para o envio de novas solicita¸c˜oes
(transi¸c˜ao LOOP MSG) ou ir para o estado final end com a transi¸c˜ao END LOOP.
67
Figura 5.25: Atributos do n´o sensor E/S.
Figura 5.26: Fun¸c˜ao make and send packet() do processo send do sensor IO.
5.7.2.3 Modelo do n´o de usu´arios
O modelo de n´o de usu´arios ´e o modelo mais importante do cen´ario de estudo,
pois representa o elemento chave da disserta¸c˜ao, que ´e o usu´ario e como manter a
sua privacidade. Como mostra a figur a 5.27, o dispositivo do usu´ario tem seis fluxos
de entrada (stream 0, stream 1, stream 2, stream 3, stream 4 e stream 5) e
68
um fluxo de sa´ıda.
Figura 5.27: Modelo do n´o de usu´arios.
Pelos fluxos 0, 1 e 4, o usu´ario recebe pacotes de r equisi¸c˜ao, que s˜ao os pacotes
do tipo shopping sensor requests pck, do sensor E/S, sensor de livraria e sensor
de mixagem, respectivamente. Ap´os receber o pacote de requisi¸c˜ao do sensor E/S,
o usu´ario envia o pacote com seu perfil shopping profile pck ao sensor, para que
possa receber um pseudˆonimo. Como j´a explicado na se¸c˜ao 5.7.2.2, o sensor envia
esse pacote ao servidor, que gera um pseudˆonimo para o usu´ario, e que ´e enviado
pelo sensor E/S. O pseudˆonimo ´e recebido pelo usu´ario por meio do fluxo 2. Ao
receber o pseudˆonimo, o dispositivo do usu´ario grava em sua mem´oria interna o
valor para que possa ser utilizado em outras comunica¸c˜oes durante sua estadia no
shopping.
Ao receber o pseudˆonimo, o usu´ario fica apto a responder as solicita¸c˜oes dos
69
sensores das livrarias, que s˜ao as solicita¸c˜oes feitas pelo fluxo 1. Feito isso, o sensor
da livraria ir´a consultar o servidor para verificar se tem permiss˜ao para enviar pro-
pagandas ao usu´ario e para saber quais as preferˆencias do usu´ario. Se for poss´ıvel
o envio de propagandas, o usu´ario as receber´a pelo fluxo 3, e se houver alguma
promo¸c˜ao que seja do seu interesse, com certeza ir´a at´e a livraria.
Caso o usu´ario caminhe pr´oximo `a uma zona de mixagem, ele receber´a pelo
fluxo 4 uma requisi¸c˜ao sobre a sua taxa de mixagem para que o sensor da zona de
mixagem determine se o usu´ario deseja participar ou n˜ao da mixagem. O valor da
sua taxa de mixagem ´e enviado no pacote shopping
mixing pck. Caso o valor
da taxa de mixagem seja 1, o sensor ir´a solicitar ao servidor um novo pseudˆonimo
que ´e ent˜ao enviado ao usu´ario. Esse novo pseudˆonimo ´e recebido pelo fluxo 5 no
pacote shopping new pseudonym pck. Isso faz com que qualquer perfil paralelo
gerado pelas lojas seja perdido e apenas o perfil gerado pelo usu´ario seja respeitado,
mantendo a sua privacidade.
Al´em do modelo de n´o do usu´ario, h´a tamb´em o modelo de processo, mostrado
na figura 5.28. Como pode-se observar, h ´a apenas dois estados: start e wait. O
estado start ´e o que carrega internamente o endere¸co IP do usu´ario e o estado wait
´e o estado que aguarda as comunica¸c˜oes em todos os fluxos descritos acima.
Figura 5.28: Modelo de processo do n´o de usu´arios.
Para exemplificar, caso seja cumprida a condi¸c˜ao RRCV 1 ARRVL, que ´e
defina no header block como mostra a figura 5.29, a fun¸c˜ao rrcv
1() ´e executada.
70
Como explicado acima, nesse fluxo ´e solicitado ao usu´ario o seu pseudˆonimo. A
figura 5.30 apresenta o c´odigo da fun¸c˜ao rrcv
1().
Figura 5.29: Header Block do processo de u su´ario, onde s˜ao definidas as condi¸c˜oes
das transi¸c˜oes de estado.
Figura 5.30: Defini¸c˜ao da fun¸c˜ao rrcv 1().
Na linha 322, o usu´ario verifica se a requisi¸c˜ao do pacote ´e do tipo Pseudonym e
71
se for, a fun¸c˜ao le
solicitacao e envia pseudonimo ao sensor() (figura 5.31) ´e
chamada. Nessa fun¸c˜ao, na linha 351 ´e criado o pacote shopping pseudonym pck
que ´e carregado com o valor do pseudˆonimo do usu´ario e com o IP destino do pacote,
por meio da fun¸c˜ao op pk nfd set do Opnet. Ap´os isso, na linh a 360, o pacote ´e
enviado com o comando op pk send delayed.
Figura 5.31: Defini¸c˜ao da fun¸c˜ao
le solicitacao e envia pseudonimo ao sensor().
5.7.2.4 Modelo do n´o servidor
O n´o servidor ´e o respons´avel por armazenar o perfil do usu´ario e p or gerar
um pseudˆonimo para esse usu´ario, assim que ele entra no shopping. A figura 5.32
apresenta o modelo do n´o servidor, que consta de trˆes fluxos de entrada (stream 0,
stream 1, e stream 2) e um de sa´ıda.
Pelo fluxo 0, o servidor recebe do sensor E/S o perfil do usu´ario no pacote
shopping profile pck e o armazena em sua lista de usu´arios, a qual ´e apresentada
na figura 5.33.
Ap´os o armazenamento do usu´ario, o servidor gera o seu pseudˆonimo, armazena-
o no registro do usu´ario e envia-o ao usu´ario por meio do sensor E/S no pacote
shopping pseudonym pck.
72
Figura 5.32: Modelo do n´o servidor.
Figura 5.33: Header b lock do n´o servidor, onde ´e definida a sua lista de usu´arios.
O fluxo 1 ´e para as comunica¸c˜oes entre os sen sores das livrarias com o servidor
central. O sensor da livraria envia para o servidor o pseudˆonimo do usu´ario, para
que ele localize as suas preferˆencias pessoais, pol´ıticas de privacidade e verifique se o
sensor tem permiss˜ao de enviar propagandas ao usu´ario. Caso ele tenha permiss˜ao de
enviar propagandas ao usu´ario, o servidor envia as preferˆencias pessoais e as pol´ıticas
de privacidade do usu´ario no pacote shopping service policies of user pck.
73
J´a o fluxo 2 serve para o servidor receb er as requisi¸c˜oes do sensor de mixagem
para gera¸c˜ao de novos pseudˆonimos para os clientes do shopping que desejam partici-
par da mixagem. Nesse caso, o pacote recebido ´e o shopping
sensor requests pck
do tipo New Pseudonym, e o servidor envia o novo pseudˆonimo ao sensor de mi-
xagem no pacote shopping new pseudonym pck.
O modelo de processo do n´o servidor ´e mostrado na figura 5.34. Assim como o
processo do usu´ario, o processo do servidor possui dois estados: start e wait. No
estado start a vari´avel de IP do servidor ´e carregada e no estado wait o servidor
aguarda por pacotes para estabelecer uma comunica¸c˜ao com os sensores.
Figura 5.34: Modelo de processo do n´o servidor.
A transi¸c˜ao com condi¸c˜ao RRCV 0 ARRVL verifica se chegou algum pacote
para o fluxo 0. Nesse caso, a fun¸c˜ao rrcv 0() ´e acionada. Essa fun¸c˜ao se encarrega
de fazer a leitura do perfil do usu´ario e armazen´a-la na lista de usu´arios do servidor.
Feito isso, o pseudˆonimo do usu´ario ´e gerado. A fun¸c˜ao cria pseudonimo() ´e
respons´avel pela cria¸c˜ao do pseudˆonimo e ´e apresentada na figura 5.35.
A fun¸c˜ao cria pseudonimo(), cria um novo pseudˆonimo a partir da conca-
tena¸c˜ao do retorno da fun¸c˜ao gera string randomica() com o retorno da fun¸c˜ao
gera numero randomico(). A fun¸c˜ao gera string randomica() retorna uma
string com at´e 3 caracteres e a fun¸c˜ao gera numero randomico() retorna um
double, todos gerados randomicamente. Ap´os isso, ´e verificado se esse pseudˆonimo
j´a existe para algum dos usu´arios que est˜ao no shopping. Essa verifica¸c˜ao ´e feita
por meio da fun¸c˜ao pseudonimo ja existe(). Se for um pseudˆonimo j´a existente,
74
Figura 5.35: Defini¸c˜ao da fun¸c˜ao cria pseudonimo().
um novo pseudˆonimo ´e gerado at´e que n˜ao haja repeti¸c˜ao. Ao final, o pseudˆonimo
gerado ´e retornado ao sensor, para que possa encaminhar ao u su´ario.
A fun¸c˜ao cria pseudonimo() ´e utilizada tamb´em na fun¸c˜ao rrcv 2(), que ´e
acionada quando o servidor recebe solicita¸c˜oes do sensor de mixagem para gerar um
novo pseudˆonimo ao usu´ario.
5.7.2.5 Modelo do n´o de sensores das livrarias
O n´o sensor da livraria ´e interessado em obter as informa¸c˜oes pessoais do usu´ario
com o objetivo de enviar servi¸cos de propaganda. O seu modelo de n´o ´e apresentado
na figura 5.36, onde ´e poss´ıvel notar dois fluxos de entrada (stream 0 e stream 1)
e um fluxo de sa´ıda.
O n´o sensor envia periodicamente mensagens de requisi¸c˜ao de pseudˆonimo,
que s˜ao os pacotes shopping sensor requests pck, aos usu´arios que est˜ao nas
suas proximidades. A resposta a essa requisi¸c˜ao ´e recebida no fluxo 0, no pacote
shopping pseudonym pck. Esse pseudˆonimo ´e ent˜ao enviado ao servidor, para
que o sensor possa obter as preferˆencias e as pol´ıticas de servi¸co fornecidos pelo
usu´ario. Essas informa¸c˜oes s˜ao ent˜ao recebidas por meio do fluxo 1, no pacote
shopping service policies of user pck. Ao receb er esse pacote, o sensor veri-
fica quais as propagandas que ele possui que possam interessar ao usu´ario e as envia
75
Figura 5.36: Modelo do n´o de sensores das livrarias.
no pacote shopping marketing pck.
O modelo de pro cesso do n´o sensor da livraria ´e apresentado na figura 5.37.
Como pode-se perceber, ele possu i quatro estados: start, send, wait e end, si-
milares aos quatro estados do n´o sensor E/S. O estado start carrega o endere¸co
IP do sensor internamente. O estado send envia pacotes de requisi¸c˜ao, que s˜ao os
pacotes do tip o shopping sensor requests pck, e aguarda as respostas `a essas
requisi¸c˜oes no estado wait. Por fim, o estado end finaliza o processamento.
5.7.2.6 Zona de mixagem
A zona de mixagem ´e representada no amb iente pelo sensor de mixagem. A
fun¸c˜ao do sensor de mixagem ´e verificar quais usu´arios est˜ao interessados em trocar
o seu pseudˆonimo, evitando assim que ele seja associado `a qualquer perfil secund´ario
criado pelas lojas, como explicado na se¸c˜ao 5.6.
A figura 5.38 apresenta o modelo do n´o sen sor de mixagem. O sensor de mi-
xagem envia periodicamente pacotes do tipo shopping sensor requests pck do
tipo Mix aos usu´arios pr´oximos `a sua localidade, para que respondam com a sua
taxa de mixagem. O pacote shopping
mixing pck ´e ent˜ao recebido pelo fluxo de
76
Figura 5.37: Modelo de processo do n´o de sensores das livrarias.
entrada e processado. Caso a taxa de mixagem seja 1, o sensor de mixagem envia o
pseudˆonimo do usu´ario ao servidor, para que seja criado um novo pseudˆonimo. Essa
solicita¸c˜ao ´e feita por meio do envio do pacote shopping sensor requests pck
do tipo New Pseudonym ao servidor. Ao receber o novo pseudˆonimo gerado
pelo servidor no fluxo 1, no pacote shopping new pseudonym pck, o sensor o
encaminha ao usu´ario que deseja participar da mixagem.
Figura 5.38: Modelo de n´o do sensor de mixagem.
77
Na figura 5.39 ´e apresentado o modelo de processo do n´o sensor d e mixagem,
o qual possui quatro estados: start, send, wait e end. O estado start carrega a
vari´avel interna do sensor com o seu IP. O estado send envia pacotes de requisi¸c˜ao
shopping
sensor requests pck aos usu´arios e aguarda as respostas no estado
wait. O estado end ´e o que finaliza o processamento do sensor de mixagem.
Figura 5.39: Modelo de processo do sensor de mixagem.
5.7.3 Executando uma simula¸c˜ao
Nessa se¸c˜ao ´e apresentada uma simula¸c˜ao para exemplificar o funcionamento e a
intera¸c˜ao dos elementos descritos na se¸c˜ao 5.7.2. O cen´ario exemplo ´e o apresentado
na figura 5.40, onde tem-se somente um cliente que, nesse caso, ´e a Alice.
Como atributos, Alice possui os que s˜ao apresentados na figura 5.41. Para
simplifica¸c˜ao, os valores do atributo Personal Properties s˜ao detalhados na tabela
5.1.
Tabela 5.1: Atributo Personal Properties de Alice
Atributo Valor
Films action movies
Books self help
Sports gymnastics
O sen sor Bookstore L Sensor, possui propagandas dispon´ıveis nas categorias
de films, books e sports, conforme apresenta a figura 5.42.
78
Figura 5.40: Cen´ario de simula¸c˜ao com apenas um usu´ario.
Figura 5.41: Atributos de Alice.
Para simplificar, em cada categoria do Bookstore L Sensor, h´a os produtos
apresentados na tabela 5.2. J´a o Bookstore M Sensor possui propagandas para
os produtos e categorias apresentados na tabela 5.3.
O que ´e esperado nessa simula¸c˜ao ´e que Alice receba propagandas dos produtos
79
Figura 5.42: Atributos do Bookstore L Sensor.
Tabela 5.2: Atributos do Bookstore L Sensor
Classe Categoria Produto Valor
Films action movies Velozes e Furiosos 20,00
Books self help Como melhorar a auto-estima 50,00
traveling Tudo sobre Joinville 65,00
Sports gymnastics Nado sincronizado (Livro) 27,00
volleyball Aprenda as principais regras do vˆolei (Livro) 14,00
soccer O Rei Pel´e (Livro) 70,00
Tabela 5.3: Atributos do Bookstore M Sensor
Classe Categoria Produ to Valor
Films romance Romeu e Julieta 45,00
Books self help Uma luz no fim do t´unel 57,00
Velozes e Furiosos, Como melhorar a auto-estima e Nado sincronizado, do Books-
tore L Sensor, e o produto Uma luz no fim do t´unel do Bookstore M Sensor, j´a
que esses produ tos se enquadram nas categorias de interesse de Alice. Al´em disso,
as livrarias n˜ao poder˜ao criar u m segundo perfil de Alice, pois Alice optou por par-
ticipar de mixagem ao passar por zonas de mixagem no shopping, atributo Mixing
Rate como 1.
Para a simula¸c˜ao foi considerado o tempo d e 600 segundos, com Alice cami-
nhando na velocidade de 2 m/s. A figura 5.43 apresenta o in´ıcio da simula¸c˜ao.
Nessa etapa os objetos IO Sensor, Alice, Mix Sensor, Bookstore L Sensor
e Bookstore M Sensor s˜ao inicializados, e os seus IPs s˜ao apresentados. Logo
80
ap´os iniciar o IO Sensor, este envia pacotes de requisi¸c˜ao de perfil ao usu´ario. Em
destaque na figura 5.43, est´a a resposta de Alice `a essa solicita¸c˜ao.
Figura 5.43: Primeira etapa da simula¸c˜ao.
No in´ıcio da figura 5.44, ´e poss´ıvel perceber que o IO Sensor recebeu o perfil de
Alice e o encaminhou ao Server. Nesse momento o Server ´e inicializado e o seu IP
´e apresentado. Ap´os isso, o Server recebe o perfil de Alice enviado pelo IO Sensor
e gera um pseudˆonimo para ela, que ´e apresentado em tela como wyw237126223.
Em seguida, esse pseudˆonimo ´e enviado ao IO Sensor, que o envia `a Alice. No
final dessa figura, a ´ultima comunica¸c˜ao realizada foi a resposta de Alice a uma
solicita¸c˜ao de pseudˆonimo feita pelo Bookstore M Sensor.
Figura 5.44: Segunda etapa da simula¸c˜ao.
Na figura 5.45, o Bookstore M Sensor envia esse pseudˆonimo ao Server,
a fim de verificar se ele possui permiss˜ao para prestar servi¸cos `a Alice. O Server
ent˜ao recebe esse pseudˆonimo, verifica as permiss˜oes do sensor e envia as preferˆencias
pessoais de Alice. O Bookstore M Sensor verifica quais os produtos que ele possui
que podem ser do interesse de Alice e os envia. Alice recebe em seu dispositivo a
propaganda de um ´unico produto Uma luz no fim do t´unel com p re¸co de 57 reais,
81
como previsto. Ao final dessa terceira etapa da simula¸c˜ao, Alice, ao passar pr´oximo
ao Bookstore L Sensor, recebe uma requisi¸c˜ao de seu pseudˆonimo, o qual ´e, ent˜ao,
enviado.
Figura 5.45: Terceira etapa da simula¸c˜ao.
A figura 5.46 apresenta o momento em que o Bookstore L Sensor envia o
pseudˆonimo do usu´ario ao Server, para que esse verifique as suas permiss˜oes. Ap´os
a valida¸c˜ao das permiss˜oes do Bookstore L Sensor, o Server envia as preferˆencias
pessoais de Alice, para que ele possa enviar propagandas. Os produtos que o
Bookstore L Sensor possui e que s˜ao do interesse de Alice s˜ao: Velozes e Furiosos,
Como melhorar a auto-estima e Nado sincronizado, como pr evisto. Esses produtos
s˜ao ent˜ao recebidos pelo dispositivo de Alice e exibidos em tela.
Figura 5.46: Quarta etapa da simula¸c˜ao.
Por fim, a figura 5.47 apresenta o momento em que Alice entra em uma zona
de mixagem e ´e abordad a pelo Mix Sensor, que solicita `a ela o seu interesse em
participar ou n˜ao da mixagem. Alice ent˜ao envia um pacote ao Mix Sensor
indicando que tem interesse em participar, campo mixing igual a 1. Dessa forma,
o Mix Sensor solicita ao Server um novo pseudˆonimo para Alice, a qual ele
82
conhece por wyw237126223. O Server gera um novo pseudˆonimo, atualiza-o no
seu cadastro interno para Alice e envia-o para o Mix Sensor. Como pode-se
perceber, o novo pseudˆonimo gerado foi o ywy339169902. O Mix Sensor envia
esse novo pseudˆonimo ao usu´ario. Nesse momento, a simula¸c˜ao ´e finalizada.
Figura 5.47: Quinta etapa da simula¸c˜ao.
Esse cen´ario de simula¸c˜ao foi escolhido apenas para exemplificar a intera¸c˜ao
entre os elementos do shopping. Apesar de Alice desejar participar da mixagem,
sua identidade, nesse caso, poderia ser facilmente associada ao seu perfil, pois ´e a
´unica cliente que est´a no shopping e, como ser´a mostrado na se¸c˜ao 5.7.4.1, nesse
caso, n˜ao h´a garantias de anonimato.
5.7.4 Resultados e an´alise da simula¸c˜ao
Essa se¸c˜ao apresenta como ´e calculado o grau de anonimato de um ambiente
com base na literatura e a an´alise do grau de anonimato oferecido pelo shopping
apresentado na se¸c˜ao 5.7.2.
5.7.4.1 M´etricas de Anonimato
O anonimato ´e o estado de n˜ao ser identific´avel quando se faz parte de um
conjunto de usu´arios, que ´e o conjunto de anonimato (PFITZMANN; K¨oHNTOPP,
2001). Para o exemplo do shopping, a defini¸c˜ao dada por (NUSSBAUMER, 2007)
esclarece melhor o que ´e o conjunto de anonimato: ´e o conjunto de pessoas visitando
uma zona de mixagem durante o mesmo per´ıodo. Quanto maior for o conjunto,
maior ser´a o grau de anonimato oferecido. Quando o conjunto se reduz para um
elemento, o usu´ario fica completamente exposto e perde todo o seu anonimato.
83
Por´em, o usu´ario pode negar a informa¸c˜ao de sua localiza¸c˜ao para uma aplica¸c˜ao at´e
que a zona de mixagem ofere¸ca um n´ıvel m´ınimo de anonimato. Esse procedimento
n˜ao foi implementado no cen´ario do shopping.
De acordo com (TOTH; HORNAK; VAJDA, 2004), as primeiras publica¸c˜oes ti-
nham como objetivo quantificar o n´ıvel de anonimato provido pelo sistema estudado
como sendo o tamanho do conjunto de anonimato como, por exemplo, a publica¸c˜ao
(BERTHOLD; FEDERRATH; KPSELL, 2000). Por´em, essa n˜ao ´e uma boa medida de
anonimato, considerando que as probabilidades poderiam n˜ao ser distribu´ıdas uni-
formemente.
Com a necessidade de medir o grau de anonimato, Serjantov e Danezis (SER-
JANTOV; DANEZIS, 2002) introduziram o conceito de entropia apropriado como uma
medida de anonimato. A defini¸c˜ao 1 intr oduz os elementos necess´arios para o en-
tendimento do conceito de entropia.
Defini¸c˜ao 1: Dado um modelo de ataque e um conjunto finito de todos os usu´arios
Ψ, seja r ∈ R um papel para um usu´ario (R = {remetente, destinat´ario}) com
rela¸c˜ao `a uma mensagem M. Seja U a probabilidade do usu´ario u ∈ Ψ ser
atacado tendo o papel r com rela¸c˜ao `a M.
Com essa defini¸c˜ao, a medida de anonimato tanto do remetente, quanto do
destinat´ario pode ser definida como:
Defini¸c˜ao 2: O tamanho S de uma distribui¸c˜ao de probabilidade U do anonimato
r ´e igual `a entropia da distribui¸c˜ao. Em outras palavras:
S = -
Ψ
u=1
p
u
log
2
p
u
(5.1)
onde p
u
= U (u, r).
Esse tipo de entropia ´e conhecida como entropia simples (TOTH; HORNAK; VAJDA,
2004).
Em (DIAZ et al., 2002) foi seguida uma ab ord agem diferente, onde se considera
somente o anonimato do remetente. Seja A representando o conjunto de anonimato
84
de uma certa mensagem M, ou seja, A = { u | (u ∈ Ψ) ∧ (p
u
> 0) }. Al´em disso,
seja N o tamanho do conjunto de anonimato, ou seja, N = |A |.
Defini¸c˜ao 3: O grau de anonimato p rovido pelo sistema ´e definido por:
d =
H (X )
H
M
(5.2)
Onde H (X ) = S e H
M
= log
2
N . Para o caso particular de um usu´ario, d ´e
assumido como sendo zero.
Essa m´etrica ´e conhecida como entropia normalizada. Em ambos os casos, zero
significa nenhum anonimato, ou seja, o atacante conhece 100% o remetente da men-
sagem. No caso da entropia simples, o caso m´aximo de anonimato ´e alcan¸cado quando
S = log
2
N e na normalizada quando d = 1 (TOTH; HORNAK; VAJDA, 2004).
Nessa disserta¸c˜ao ser´a utilizada a m´etrica da entropia normalizada, visto que o in-
teresse maior ´e no anonimato do remetente, ou seja, do usu´ario do shopping e n˜ao dos
demais elementos. O c´alculo da m´etrica utilizada foi introduzido com uma programa¸c˜ao
`a parte para o simulador Opnet.
5.7.4.2 Cen´arios para simula¸c˜ao
Para a obten¸c˜ao do grau de anonimato do shopping foram considerados 3 cen´arios: um
com 50 clientes (figura 5.48), outro com 100 clientes (figura 5.49) e, por fim, um cen´ario
com 300 clientes (figura 5.50). Esse ´e o n´umero de usu´arios que podem estar presentes na
zona de mixagem, mas n˜ao necessariamente desejam participar da mixagem. Para cada
cen´ario, foram simuladas algumas situa¸c˜oes, variando o n´umero de usu´arios que desejam
participar da mixagem, como mostra a tabela 5.4.
O modelo de ataque para esses cen´arios ´e similar ao apresentado por (DIAZ et al.,
2002), para o caso da Onion Routing. Nesse modelo, N ´e o tamanho do conjunto de
anonimato, e a entropia m´axima para esses N usu´arios ´e:
H
M
= log
2
N
(5.3)
85
Figura 5.48: Shopping com 50 clientes.
Figura 5.49: Shopping com 100 clientes.
86
Figura 5.50: Shopping com 300 clientes.
Tabela 5.4: Situa¸c˜oes para a simula¸c˜ao.
Usu´arios na zona de mixagem Usu´arios que participam da mixagem
1
2
50 10
25
40
50
1
2
100 20
50
80
100
1
2
300 60
150
240
300
No caso do shopping, N ´e o n´umero de usu´arios que est˜ao na zona de mixagem do
shopping independente de desejarem ou n˜ao participar da mixagem. Nesse caso, o ataque
se caracteriza como um dos sensores das lojas tentando associar a identidade de um cliente
com um perfil secund´ario criado por eles mesmos.
87
O conjunto que cont´em apenas os usu´arios interessados em participar da mixagem ´e
chamado de conjunto A, onde 1 ≤ A ≤ N. Nesse caso, a distribui¸c˜ao de probabilidades
para os A usu´arios ´e uniforme:
p
i
=
1
A
, 1 ≤ i ≤ A; p
i
= 0, A + 1 ≤ i ≤ N
(5.4)
Dessa forma, a entropia e o grau de anonimato s˜ao definidos como:
H (X ) = log
2
A, d =
H (X )
H
M
=
log
2
A
log
2
N
(5.5)
Para aplicar esse modelo de ataque aos cen´arios apresentados nas figuras 5.48, 5.49
e 5.50, foram considerados v´arios tamanhos para o conjunto A, como previamente apre-
sentado na tabela 5.4. O grau de anonimato obtido para cada cen´ario ´e apresentado na
tabela 5.5.
Tabela 5.5: Grau de anonimato obtido para os cen´arios
Conjunto N Conjunto A p
i
log
2
N log
2
A d
1 1,0000 5,6439 0,0000 0,0000
2 0,5000 5,6439 1,0000 0,1772
50 10 0,1000 5,6439 3,3219 0,5886
25 0,0400 5,6439 4,6439 0,8228
40 0,0250 5,6439 5,3219 0,9430
50 0,0200 5,6439 5,6439 1,0000
1 1,0000 6,6439 0,0000 0,0000
2 0,5000 6,6439 1,0000 0,1505
100 20 0,0500 6,6439 4,3219 0,6505
50 0,0200 6,6439 5,6439 0,8495
80 0,0125 6,6439 6,3219 0,9515
100 0,0100 6,6439 6,6439 1,0000
1 1,0000 8,2288 0,0000 0,0000
2 0,5000 8,2288 1,0000 0,1215
300 60 0,0167 8,2288 5,9069 0,7178
150 0,0067 8,2288 7,2288 0,8785
240 0,0042 8,2288 7,9069 0,9609
300 0,0033 8,2288 8,2288 1,0000
As figuras 5.51, 5.52 e 5.53 apresentam graficamente o grau de anonimato d obtido
para cada situa¸c˜ao do conjunto A. Como pode-se perceber, em todas as situa¸c˜oes onde
h´a somente 1 clie nte, n˜ao h´a anonimato garantido para esse cliente. Mesmo com dois
usu´arios, o grau de anonimato obtido ´e muito baixo. Em (DIAZ et al., 2002) ´e sugerido um
88
valor intuitivo para o grau m´ınimo de anonimato para que um sistema forne¸ca anonimato
adequadamente. Esse valor ´e d ≥ 0,8 obtido empiricamente.
Figura 5.51: Grau de anonimato com N = 50.
Figura 5.52: Grau de anonimato com N = 100.
Figura 5.53: Grau de anonimato com N = 300.
As situa¸c˜oes simuladas, como mostradas nas figuras 5.51, 5.52 e 5.53, para as amostras
dos conjuntos A em quest˜ao, mostram que o grau de anonimato ≥ 0,8 (DIAZ et al., 2002)
s˜ao as situa¸c˜oes onde A ≥ 25, para o cen´ario onde tem-se N = 50 usu´arios, A ≥ 50, para
N = 100 usu´arios e A ≥ 150, quando N = 300 usu´arios. Al´em disso, o grau de anonimato
m´aximo obtido ´e quando N = A.
89
Os resultados apresentados nos gr´aficos das figuras 5.51, 5.52 e 5.53, foram comparados
no gr´afico da figura 5.54. Pode-se dizer que o grau de anonimato de um ambiente aumenta,
conforme o n´umero de elementos do conjunto A aumenta. Ou seja, quanto mais usu´arios
desejarem participar da mixagem, mais dif´ıcil ser´a de um atacante descobrir a identidade
de um usu´ario.
Figura 5.54: Comparativo entre os 3 cen´arios.
5.8 Considera¸c˜oes
Um problema encontrado na m´etrica do c´alculo do grau de anonimato ´e que, ao
considerar um ambiente onde N = 2 e A = 2, tem-se d = 1. O que significa que foi obtido
o grau de anonimato m´aximo para esse ambiente, considerando-se p
i
= 0, 5. Por´em, na
pr´atica, sabe-se que N = 2 n˜ao garante o anonimato desses dois usu´arios, mesmo com
A = 2. Por esse motivo, ´e importante sempre considerar valores maiores para N e A.
Uma alternativa seria estipular um valor m´ınimo para o tamanho de A, e o usu´ario aceitar
participar da mixagem somente quando esse n´umero m´ınimo de usu´arios para o conjunto
A for atingido.
Al´em disso, uma das limita¸c ˜oes desse trabalho ´e que ele n˜ao aborda t´ecnicas de segu-
ran¸ca. Dessa forma, ´e importante ressaltar que as zonas de mixagem foram consideradas
confi´aveis.
90
6 Conclus˜oes e Trabalhos
Futuros
Esse trabalho apresentou o metamodelo de (CAMPIOLO, 2005) evolu´ıdo com a ca-
racter´ıstica de privacidade. As classes da categoria de privacidade foram desenvolvidas
com base nos conceitos de zonas de mixagem, pseudˆonimos e perfis c om as preferˆencias
pessoais dos usu´arios. Para a valida¸c˜ao do metamodelo foi dada continuidade ao cen´ario
do shopping center apresentado em (CAMPIOLO, 2005) o qual passou a abordar tamb´em
a caracter´ıstica de privacidade. Havia dois caminhos a serem seguidos: desenvolver um
simulador com base no metamodelo ou optar por um simulador j´a existente que permi-
tisse a inclus˜ao dos conceitos do metamodelo. A segunda op¸c˜ao foi a escolhida, devido `a
restri¸c˜ao temporal para a conclus˜ao do presente estudo. Optou-se ent˜ao pelo simulador
Opnet
1
, por ele ter uma vasta documenta¸c˜ao, por sua flexibilidade na ex tens˜ao dos seus
objetos existentes e tamb´em na permiss˜ao da cria¸c˜ao de n ovos objetos, por seu suporte `a
comunica¸c˜ao sem fio e f´acil utiliza¸c˜ao.
O resultado obtido com a adapta¸c˜ao do metamodelo ao simulador Opnet foi apre-
sentado no cap´ıtulo 5. Como limita¸c˜ao na simula¸c˜ao foi que o Opnet n˜ao permite co-
munica¸c˜oes s´ıncronas e ntre as entidades, o que tornou mais trabalhosa a elabora¸c˜ao do
cen´ario. Outra caracter´ıstica do Opnet ´e que ele exige mem´oria do computador, fazendo
com que o c´odigo fonte seja feito de maneira a se otimizar ao m´aximo o uso de vari´aveis,
como tamb´em, que sejam utilizados re cursos do pr´oprio Opnet para desalo car mem´oria
assim que o objeto deixa de ser utilizado e o tamanho dos campos dos pacotes utilizados
seja o m´ınimo poss´ıvel para o funcionamento dos protocolos de comunica¸c˜ao.
Por meio do uso de pseudˆonimos os usu´arios tornaram-se anˆonimos e para garantir
que a identidade de um usu´ario n˜ao fosse associada a um segundo perfil, foram criadas
as zonas de mix agem, que s˜ao r egi˜oes onde os usu´arios se misturam `a multid˜ao, trocando
seus pseudˆonimos por novos pseudˆonimos, melhorando assim, a sua privacidade.
1
www.opnet.com
91
Por fim, utilizou-se a m´etrica de (DIAZ et al., 2002) para medir o grau de anonimato
do ambiente do shopping center. Um modelo de ataque foi elaborado e apresentado no
cap´ıtulo 5. Trˆes cen´arios foram escolhidos para o c´alculo do grau de anonimato, vari-
ando para cada um deles o tamanho do conjunto de clientes que desejavam participar da
mixagem, ao entrar em uma zona de mixagem. Resumidamente, os resultados obtidos
mostraram que, quanto mais usu´arios estiverem presentes na zona de mixagem, mais alto
ser´a o grau de anonimato oferecido pelo ambiente.
6.1 Trabalhos Fu turos
Esse trabalho teve como principal objetivo, o estudo da caracter´ı stica de privacidade
em ambientes de computa¸c˜ao ub´ıqua. Contudo, sabe-se que a ´area de computa¸c˜ao ub´ıqua
´e uma ´area em constante crescimento e tamb´em uma ´area que demanda muita pesquisa
ainda a ser realizada. A seguir, algumas sugest˜oes de trabalhos futuros s˜ao feitas:
• Abordar seguran¸ca no metamodelo seria interessante como, por exemplo, utilizar
criptografia nos pacotes desenvol vidos nessa disserta¸c˜ao. Seria um mecanismo a
mais para prote¸c˜ao da comunica¸c˜ao entre as entidades do ambiente;
• Permitir, na mo delagem desenvolvida, que o usu´ario determine qual o n´umero
m´ınimo de usu´arios devem estar presentes na zona de mixagem para que ele aceite
participar da mixagem;
• Simular outros cen´arios, como uma casa inteligente, uma faculdade, um escrit´orio,
entre outros, para verificar a aplica¸c˜ao do modelo e o grau de anonimato obtido.
• Investigar a possibilidade de se desenvolver um simulador com base no metamodelo
apresentado.
92
Referˆencias
AGRAWAL, R. et al. Hippocratic databases. In: 28th Int’l Conf. on Very
Large Databases (VLDB), Hong Kong . [s.n.], 2002. p. 143–154. Dispon´ıvel em:
<citeseer.ist.psu.edu/agrawal02hippocratic.html>.
AOYAMA, T. A new generation network - beyond ngn. Innovations in NGN: Future
Network and Services. First ITU-T Kaleidoscope Academic Conference, Geneva, p. 3–10,
May 2008.
ARGENTINA. Personal data protection act. May 2008. Di spon´ıvel em:
<http://www.privacyinternational.org/countries/argentina/argentine-dpa.html>.
BAYARDO, R. J.; SRIKANT, R. Technologies: Technological solutions for protecting
privacy. j-COMPUTER, v . 36, n. 9, p. 115–118, September 2003. ISSN 0018-
9162. Dispon´ıvel em: <http://csdl.computer.org/dl/mags/co/2003/09/r9115.htm;
http://csdl.computer.org/dl/mags/co/2003/09/r9115.pdf>.
BERENDT, B.; GUNTHER, O.; SPIEKERMANN, S. Privacy in ecommerce: State
preferences vs. actual behavior. Communications of the ACM, v. 48, n. 4, p. 101–106,
2005.
BERESFORD, A. R. Location privacy in ubiquitous computing. [S.l.], January 2005.
BERESFORD, A. R.; STAJANO, F. Location privacy in pervasive computing. IEEE
Pervasive Computing, v. 2, n. 2, p. 46–55, April-June 2003.
BERESFORD, A. R.; STAJANO, F. Mix zones: User privacy in location-aware services.
Pervasive Computing and Communications Workshops, IEEE International Conference
on, IEEE Computer Society, Los Alamitos, CA, USA, v. 0, p. 127–131, 2004.
BERTHOLD, O.; FEDERRATH, H.; KPSELL, S. Web mixes: A system for anonymous
and unobservable internet access. In: Designing Privacy Enhancing Technologies. [S.l.]:
Springer-Verlag, 2000. p. 115–129.
BHASKAR, P.; AHAMED, S. I. Privacy in pervasive computing and op en issues. In:
ARES ’07: Proceedings of the The Second International Conference on Availability,
Reliability and Security. Washington, DC, USA: IEEE Computer Society, 2007. p.
147–154. ISBN 0-7695-2775-2.
BUENNEMEYER, T.; MARCHANY, R.; TRONT, J. G. Ubiquitous security: Privacy
versus protection. In: ARABNIA, H. R. (Ed.). PSC. [S.l.]: CSREA Press, 2006. p. 71–77.
ISBN 1-60132-018-3.
CAMPBELL, R. et al. Towards security and privacy for pervasive computing. In: In
Proceedings of International Symposium on Software Security. Tokyo, Japan: [s.n.], 2002.
p. 1–15.
93
CAMPIOLO, R. Aspectos de Modelagem d e Ambientes de Computa¸c˜ao Ub´ıqua.
Disserta¸c˜ao (Mestrado) — Universidade Federal de Santa Catarina, Junho 2005.
CAMPIOLO, R.; SOBRAL, J. B. M. Modelagem e simula¸c˜ao em ambientes de
computa¸c˜ao ub´ıqua. Florian´opolis, 2005. In: I2TS’2005 - International Information and
Telecommunication Technologies Symposium.
CHALMERS, D. et al. Manifesto for the ubiquitous computing grand challenge:
Experience, design and science. Version 4. UK-UbiNet. February 2006. Dispon´ıvel em:
<http://www-dse.doc.ic.ac .uk/Projects/UbiNet/GC/manifesto.html>.
CHANG, X. Network simulations with opnet. In: WSC ’99: Proceedings of the 31st
conference on Winter simulatio n. New York, NY, USA: ACM Press, 1999. p. 307–314.
ISBN 0780357809. Dispon´ıvel em: <http://dx.doi.org/10.1145/324138.324232>.
CHENG, H. S.; ZHANG, D.; TAN, J. G. Protection of privacy in pervasive computing
environments. In: ITCC ’05: Proceedings of the International Conference on Information
Technology: Coding and Computing (ITCC’05). Washington, DC, USA: IEEE Computer
Society, 2005. v. 2, p. 242–247. ISBN 0-7695-2315-3.
CONSTITUICAO. Constitui¸c˜ao da rep ´ublica federativa do brasil. artigo 5. Par´agrafos X,
XI e XII. 1988.
CULLER, D. E.; HONG, W. Wireless sensor networks. Communications of the ACM,
v. 47, n. 6, p. 30–33, June 2004.
DIAZ, C. et al. Towards measuring anonymity. In: DINGLEDINE, R.; SYVERSON,
P. (Ed.). Proceedings of Privacy Enhancing Technologies Workshop (PET 2002). [S.l.]:
Springer-Verlag, LNCS 2482, 2002. p. 54–68.
DUKE, R. et al. The Object-Z Specification Language: Verson 1. [S.l.], 1991.
EUDIRECTIVE1995/46/EC. Directive 95/46/ec of the europ ean parliament and of
the council of 24 october 1995 on the protection of individuals with regard to the
processing of personal data and on the free movement of such data. An unofficial text:
http://www.datenschutz-berlin.de/gesetze/europa/den.htm. For the authoritative text
of the Directive, reference should be made to the Official Journal of the European
Communities of 23 November 1995 No L. 281 p. 31. November 1995.
FAHRMAIR, M.; SITOU, W.; SPANFELNER, B. Security and privacy rights
management for mobile and ubiquitous computing. Tokyo, Japan, September 2005.
Workshop on UbiComp Privacy: Privacy in Context.
FILHO, P. J. de F. Introdu¸c˜ao `a Modelagem e Simula¸c˜ao de Sistemas. [S.l.]: Visual
Books, 2001.
GELLMAN, R. Does privacy law work? In: Technology and Privacy: The New
Landscape, ed. Philip E. Agre and Marc Rotenberg. [S.l.: s.n.], 1998. p. 193–218. MIT
Press, Cambridge, Massachusetts.
GILC. Privacy and human rights: An international survay of privacy laws and practice.
May 2008. Dispon´ıvel em: <http://www.gilc.org/privacy/survey/>.
HANSMANN, U. et al. Pervasive Computing. 2. ed. [S.l.]: Springer, 2003.
94
JIANG, X.; LANDAY, J. A. Modeling privac y control in context-aware systems. IEEE
Pervasive Computing, IEEE Computer Society, Los Alamitos, CA, USA, v. 1, n. 3, p.
59–63, 2002. ISSN 1536-1268.
JIANG, X.; LANDAY, J. A. Modeling privac y control in context-aware systems. IEEE
Pervasive Computing, v. 1, n. 3, p. 59–63, July-September 2002.
KOBSA, A.; SCHRECK, J. Privacy through pseudonymity in user-adaptive systems.
ACM Transactions on Internet Technology, v. 3, n. 2, p. 149–183, 2003.
LANDAY, J. A.; DAVIS, R. C. Making sharing pervasive: Ubiquitous computing for
shared note taking. IBM Systems Journal, v. 38, n. 4, p. 531–550, 1999.
LANGHEINRICH, M. Privacy by design — principles of privacy-aware ubiquitous
systems. j-LECT-NOTES-COMP-SCI, v. 2201, p. 273–??, 2001. ISSN 0302-9743.
LANGHEINRICH, M. A privacy awareness system for ubiquitous computing
environments. In: Ubicomp, Lec ture Notes in Computer Science. [S.l.]: Springer-Verlag,
2002. v. 2498, p. 237–245.
LEDERER, S.; DEY, A. K.; MANKOFF, J. A Conceptual Model and a Metaphor of
Everyday Privacy in Ubiq uit ou s Computing Environments. [S.l.], June 2002. Dispon´ıvel
em: <http://www.eecs.berkeley.edu/Pubs/TechRpts/2002/5464.html>.
LESSIG, L. Code and Other Laws of Cybers pace. New York, NY: Basic Books, 1999. 31,
33, 34 p.
MICHAEL, J. Privacy and human rights: An international and comparative study,
with special reference to developments in information technology. Dartmouth Pub Co. /
UNESCO. 1994.
MYLES, G.; FRIDAY, A.; DAVIES, N. Preserving Privacy in Environments with
Location-Based Applications. IEEE Pervasive Computing, v. 2, n. 1, p. 56–64, 2003.
NUSSBAUMER, M. Location privacy. July 2007. Dispon´ıvel em: <www.sec.informatik.tu-
darmstadt.de/pages/lehre/SS07/sem
misc/papers/nussbaumer.pdf>.
ODLYZKO, A. Privacy, economics, and price discrimination on the internet. In:
ICEC’03: Proceedings of the 5th international conference on Electronic commerce. New
York, NY, USA: ACM Press, 2003. p. 355–366. ISBN 1-58113-788-5.
OECD. Recommendation of the council concerning guidelines governing the
protection of privacy and transborder flows of personal data. Organisation for
Economic Co-operation and Development (OECD). September 1980. Dispon´ıvel em:
<http://we bdomino1.oecd.org/horizontal/oecdacts.nsf/linkto/C(80)58>.
PFITZMANN, A.; K¨oHNTOPP, M. Anonymity, unobservability, and pseudonymity - a
proposal for terminology. In: Designing Privacy Enhancing Technologies. Springer-Verlag,
2001. p. 1–9. Dispon´ıvel em: <http://dx.doi.org/10.1007/3-540-44702-4 1>.
RAZAK, S.; ZHOU, M.; LANG, S. Networ k Intrusion Simulation Using OPNET. In:
OPNETWORK2002 conference. [S.l.: s.n.], 2002.
RIGHTS. Privacy & human rights. May 2008. Dispon´ıvel em:
<http://www.privacyinternational.org/survey/>.
95
SAHA, D.; MUKHERJEE, A. Pervasive computing: A paradigm for the 21st century.
IEEE Computer, v. 36, n. 3, p. 25–31, March 2003.
SALTZER, J. H.; SCHROEDER, M. D. The protection of information in computer
systems. Proceedi ngs of the IEEE, v. 63, n. 9, p. 1278–1308, September 1975.
SATYANARAYANAN, M. Pervasive computing: Vision and challenges. IEEE Personal
Communications, v. 8, n. 4, p. 10–17, August 2001.
SERJANTOV, A.; DANEZIS, G. Towards an information theoretic metric for anonymity.
In: Proceed ings of Privacy Enhancing Technologies (PET2002). [S.l. ]: Springer-Verlag,
2002. p. 41–53.
SPIVEY, J. M. The Z Notation : A Reference Manual. [S.l.]: Prentice Hall, 1989.
STAJANO, F. Security for Ubiquitous Computing. 1. ed. [S.l.]: John Wiley & Sons, 2002.
STAJANO, F. Security for whom? the shifting security assumptions of pervasive
computing. In: International Sec urity Symposium. [S.l.]: Springer-Verlag GmbH, 2002.
(Lectures Notes in Computer Science, v. 2609), p. 16–27.
TOTH, G.; HORNAK, Z.; VAJDA, F. Measuring anonymity revisited. In:
LIIMATAINEN, S.; VIRTANEN, T. (Ed.). Proceedings of th e Ninth Nord ic Workshop on
Secure IT Systems. Espoo, Finland: [s.n.], 2004. p. 85–90.
USPRIVACYACT. Us privacy act of 1974. 1974. Dispon´ıvel em:
<http://www.usdoj.gov/foia/privstat.htm>.
W3C. Platform for privacy preferences project. W.W.W. Consortium. May 2007.
Dispon´ıvel em: <http://www.w3.org/P3P/>.
WARREN, S. D.; BRANDEIS, L. D. The right to privacy. Har-
vard Law Review, v. 4, n. 5, p. 193–220, 1890. Dispon´ıve l em:
<http://www.lawrence. edu/fast/boardmaw/Privacy
brand warr2.html>.
WEISER, M. The computer for the twenty-first century. Scientific American, p. 94–104,
Septemb er 1991.
WEISER, M. Hot topics: Ubiquitous computing. IEEE Computer, v. 26, n. 10, p. 71–72,
October 1993.
WEISER, M. Some computer science issues in ubiquitous computing. Communications
of the ACM, v. 36, n. 7, p. 75–84, July 1993.
WEISER, M. The world is not a desktop. ACM Interactions, v. 1, n. 1, p. 7–8, January
1994.
WEISER, M.; GOLD, R.; BROWN, J. S. The origins of ubiquitous computing research
at parc in the late 1980s. IBM Systems Journal, v. 38, n. 4, p. 693–696, 1999.
WESTIN, A. F. Privacy and freedom. Atheneum, New York NY. 1967.
WESTIN, A. F. Privacy in america: an historical and sociopolitical analysis. In:
Proceedings of the national privacy and public policy symposium. [S.l.: s.n.], 1995.
Hartford, Connecticut.
96
AP
ˆ
ENDICE A -- Especifica¸c˜ao do Modelo em Object-Z
Esse apˆendice apresenta a especifica¸c˜ao do modelo em Object-Z apresentado por
(CAMPIOLO, 2005). As classes especificam as caracter´ısticas e r estri¸c˜oes dos elemen-
tos para modelar e simular ambientes de computa¸c˜ao ub´ıqua, al´em de algumas fun¸c˜oes
b´asicas para gerenciar seus atributos e suas associa¸c˜oes. H´a classes que n˜ao apresentam
os m´etodos b´asicos, como por exemplo, m´etodos de adi¸c˜ao, acesso e remo¸c˜ao, para n˜ao
tornar a especifica¸c˜ao extensa e excessivamente carregada de fun¸c˜oes n˜ao t˜ao relevantes
(CAMPIOLO, 2005).
[TEXT , DATA, SHAPE , TIME , DATE , ACTION , STATE ]
Properties : TEXT → DATA
Direction : {North, South, East, West, Northeast, Northwest,
Southeast, Southwest}
97
ModelBase
ClassType : {Person, Object, Entity, Space}
identification : N
class : ClassType
description : TEXT
position : N × N × N
mass : R
1
width : N
height : N
shape : P(R × R × R)
emittedSignal : F Signal
location : Location
created : TimeStamp
∀ x , y : identification • x = y
∀ x , y : identification; p1, p2 : position | x = y • p1 = p2
SetPosition
∆(position)
p? : N × N × N
∃
1
s : Space | s ∈ Environment.space • p? ∈ s.shape
position
= p?
98
Person
ModelBase
[POSITIONAL, PHYSICAL, PSYCHOLOGICAL]
Personality : {Extraversion, Agreeableness, Conscientiousness,
EmotionalStability, Openness}
profile : Profile
positional : P POSITIONAL
physical : P PHYSICAL
psychological : P PSYCHOLOGICAL
speed : R
direction : Direction
orientation : Direction
gender : {male, female}
age : N
personality : Personality → N
hasObject : F ↓Object
hasEntity : F ↓Entity
speed ∈ positional
direction ∈ positional
orientation ∈ positional
gender ∈ physical
age ∈ physical
personality ∈ psychological
ran personality ≤ 100
INIT
class = Person
ΦSelectEntity
∆(hasEntity)
e?, e
: ↓Entity
e? ∈ hasEntity ⇒ e
= e?
ΦSelectObject
∆(hasObject)
o?, o
: ↓Object
o? ∈ hasObject ⇒ o
= o?
99
TakeObject
∆(hasObject)
o? : ↓Object
hasObject
= hasObject ∪ {o?}
TakeEntity
∆(hasEntity)
e? : ↓Entity
hasEntity
= hasEntity ∪ {e?}
PutObject
∆(hasObject)
o? : ↓Object
o? ∈ hasObject
hasObject
= hasObject \ {o?}
o?.SetPosition
PutEntity
∆(hasEntity)
e? : ↓Entity
e? ∈ hasEntity
hasEntity
= hasEntity \ {e?}
e?.SetPosition
Move
∆(speed, direction)
s? : R
d? : Direction
d? = direction ⇒ direction
= d?
s? = speed ⇒ speed
= s?
speed
= 0 ⇒ SetPosition
100
Object
ModelBase
initialState : P STATE
possibleState : P STATE
changeState : ACTION → (STATE ↔ STATE )
associations : F ↓ModelBase
initialState ⊆ possibleState
INIT
class = Object
AddAssociation
∆(associations)
m? : ↓ModelBase
associations
= associations ∪ {m?}
RemoveAssociation
∆(associations)
m? : ↓ModelBase
associations
= associations \ {m?}
ReceiveAction
∆(initialState)
a? : ACTION
a? ∈ dom changeState ⇒
initialState
= ( initialState\
{first(changeState(a?))} )
∪{second(changeState(a?))}
101
Entity
ModelBase
[Process, Protocol]
enabled : B
connections : seq ↓Entity
communication : seq Protocol
channel : seq CommunicationChannel
offeredServices : P Service
#connections = #communication = #channel
∃ f : ran connections × ran communication × ran channel
| ∀ i : 1..#f •
f (i) = (connections(i), communication(i), channel(i))
INIT
class = Entity
TurnOn
∆(enabled)
enabled
= true
TurnOff
∆(enabled)
enabled
= false
AddConnection
∆(connections, communication, channel)
e? : ↓Entity
p? : Protocol
c? : CommunicationChannel
connections
= connections
< e? >
communication
= communication
< p? >
channel
= channel
< c? >
RemoveConnection
∆(connections, communication, channel)
index? : N
connections
= squash({index?}
−
connections)
communication
= squash({index?}
−
communication)
channel
= squash({index?}
−
channel)
102
SendNotify
t! : ↓Trigger
connections =
ReceiveNotify
t? : ↓Trigger
AddOfferedServices
offeredService? : Service
offeredServices
= offeredServices ∪ {offeredService?}
RemoveOfferedServices
offeredService? : Service
offeredServices
= offeredServices \ {offeredService?}
Sensor
Entity
type : N
perceptionShape : SHAPE
perceptionDistance : N
knownSignal : SignalType
internalState : P STATE
stateTransition : Signal → (STATE ↔ STATE )
#knownSignal = 1
dom ran stateTransition ⊂ internalState
ran ran stateTransiction ⊂ internalState
PerceiveSignal
∆(internalState)
s? : Signal
knownSignal = s?.knownSignal ⇒
internalState
= ( internalState\
{first(stateTransition(s?))} )
∪{second(stateTransition(s? ))}
SendNotify
e? : Event
c? : Command
∀ d : Device | d ∈ ran connections • t! = e?
∀ a : Actua tor | a ∈ ran connections • t! = c?
103
Actuator
Entity
object : P ↓Object
action : P ACTION
actuation : Command → (Object ↔ ACTION )
dom ran actuation ⊆ object
ran ran actuation ⊆ action
ReceiveNotify
c! : Command
c! = t?
SendAction
c? : Command
a! : ACTION
o! : Object
o! = first(actuation(c?))
a! = second(actuation(c?))
Trigger
identification : N
contents : P Properties
∀ x , y : identification • x = y
Disparate
[abstract operation to run a event]
Stop
[abstract operation to cancel a event]
SignalType
identification : N
description : TEXT
EventType
identification : N
description : TEXT
104
Signal
Trigger
[SignalConstraints]
type : SignalType
source : ↓ModelBase
target : P Sensor
propagation : SHAPE
range : N
constraints : SignalConstraints
Event
Trigger
type : EventType
source : ↓Device
target : P ↓Device
Command
Trigger
source : ↓Entity
target : P Actuator
sintaxe : DATA
parameters : P DATA
sintaxe ∈ ran contents
parameters ⊂ ran contents
105
Device
Entity
[InputDevice, OutputDevice]
pid, mid : N
model : TEXT
input : P InputDevice
output : P OutputDevice
entry : InputDevice → P DATA
exit : OutputDevice → P DATA
process : pid → Process
aliveProcess : P(Process)
state : P STATE
stateTransition : Event → (STATE ↔ STATE )
memory : P DATA
addressMemory : mid → DATA
event : P Event
eventMap : Event → P Device
input = dom entry
output = dom exit
aliveProcess = ran process
dom ran stateTransition ⊆ state
ran ran stateTransition ⊆ state
memory = ran add ressMemory
event = dom eventMap
Register
∆(eventMap)
e? : Event
d? : Device
e? ∈ Event
eventMap
(e?) = eventMap(e?) ∪ {d?}
Unregister
∆(eventMap)
e? : Event
d? : Device
e? ∈ Event
eventMap
(e?) = eventMap(e?) \ {d?}
106
ΦSelectInput
∆(input)
i?, i
: InputDevice
i? ∈ InputDevice ⇒ i
= i?
ΦSelectOutput
∆(output)
o?, o
: OutputDevice
o? ∈ OutputDevice ⇒ o
= o?
SendNotify
e! : Event
e! ∈ event
ReceiveNotify
e? : Event
e? = t?
[event implications]
EmbeddedDevice
Device
embeddedIn : Object
PortableDevice
Device
owner : Person
INIT
owner = ∅
FixedDevice
Device
space : Space
107
Location
symLocation : SymbolicLocation
relLocation : seq RelativeLocation
SymbolicLocation
place : Space
point : N × N × N
RelativeLocation
toObject : ↓ModelBase
orientation : Direction
distance : N
Wall
Object
visible : B
opaque : B
#shape = 2
Window
Object
stateOpened : B
opaque : B
stateOpened ∈ possibleState
Door
Object
alwaysOpened : B
stateOpened : B
opaque : B
stateOpened ∈ possibleState
#shape = 2
108
Space
ModelBase
name : TEXT
delimiters : F ↓Object
persons : F Person
objects : F Object
entities : F ↓Entity
INIT
class = Space
∀ d : ↓Object | d ∈ delimiters • d.INIT
∀ p : Persons | p ∈ perso ns • p.INIT
∀ o : Objects | o ∈ objects • o.INIT
∀ e : Entity | e ∈ entities • e.INIT
ΦSelectPerson
∆(persons)
p?, p
: Person
p? ∈ persons ⇒ p
= p?
ΦSelectObject
∆(objects)
o?, o
: Object
o? ∈ objects ⇒ o
= o?
ΦSelectEntity
∆(entities)
e?, e
: ↓Entity
e? ∈ entities ⇒ e
= e?
ΦSelectDelimiter
∆(delimiters)
d?, d
: ↓Object
d? ∈ delimiters ⇒ d
= d?
109
Environment
name : TEXT
space : F Space
timeController : TimeController
situationalController : SituationalController
locationController : LocationController
energyController : EnergyController
communicationController : CommunicationController
#space > 0
INIT
∀ s : Space | s ∈ space • s.INIT
locationController.INIT
energyController.INIT
communicationController.INIT
situationalController.INIT
timeController.INIT
ΦSelectSpace
∆(space)
s?, s
: Space
s? ∈ space ⇒ s
= s?
CommunicationChannel
CommunicationConstraints : {Interference, Delay, Obstruction,
Noise, DataLost, Synchronization, DeniedAccess, ...}
physicalChannel : {infra red, radio, opticalfiber , satellite, ...}
source : P ↓Entity
target : P ↓Entity
propagation : SHAPE
range : N
transmissionRate : R
1
frequency : R
1
constraints : P CommunicationConstraints
110
TimeStamp
date : DATE
time : TIME
SetTime
∆(date, time)
time? : TIME
date? : DATE
time
= time?
date
= date?
TimeController
clock : TimeStamp
scheduler : TimeStamp ↔ ↓Trigger
duration : TimeStamp ↔ ↓Trigger
frequency : TimeStamp ↔ ↓Trigger
∀ t : TimeStamp | (t ∈ dom scheduler ∧ t = clock) •
scheduler(t).Disparate
∀ event : ↓Trigger | event ∈ ran duration •
∃ t : TimeStamp |
(t ∈ dom scheduler ∧ scheduler(t) = event) •
clock = (t + duration
∼
(event)) ⇒ event.Stop
∀ event : ↓Trigger | event ∈ ran frequency •
∃
1
t : TimeStamp |
(t ∈ dom scheduler ∧ scheduler(t) = event) •
∀ i : N
1
•
clock = (t + i ∗ frequency
∼
(event)) ⇒ event.Disparate
INIT
[add events]
clock.SetTime
SituationalController
situation : F STATE → ↓Trigger
y : F STATE | y ∈ dom situation •
(∀ x : STATE | (x ∈ y) ∧ (x = true) • situation(y).Disparate)
INIT
[add situations]
111
LocationController
registeredElement : P ↓ModelBase
location : ↓ModelBase → Location
registeredElement = dom location
INIT
[add elements and locations]
EnergyController
device : P ↓Entity
energy : ↓Entity → R
device = dom energy
∀ x : ↓Entity | x ∈ device ∧ energy(x ) = 0 • x .TurnOff
INIT
[add monitored devices]
CommunicationController
activeEntities : P ↓Entity
activeChannels : P CommunicationChannel
connections : CommunicationChannel × ↓Entity
area : P SHAPE
restrictArea : SHAPE → CommunicationChannel .Constraints
activeEntities = ran connections
activeChannels = dom connections
area = dom restrictArea
INIT
activeEntities = ∅
activeChannels = ∅
connections = ∅
[add restrict areas]
112
AP
ˆ
ENDICE B -- Classes de Privacidade
Nesse apˆendice s˜ao apresentadas as trˆes classes de privacidade que foram acrescentadas ao
modelo apresentado no apˆendice A. Assim como em (CAMPIOLO, 2005), h´a classes que n˜ao apre-
sentam os m´etodos b´asicos, como por exemplo, m´etodos de adi¸c˜ao, acess o e remo¸c˜ao.
Service
ServiceState
identification : N
description : TEXT
created : TimeStamp
∀ x , y : identification • x = y
CreateService
∆(identification, description, created)
identification? : N
description? : TEXT
created? : TimeStamp
identification
= identification?
description
= description?
created
= created?
113
PrivacyPolicy
MODE ::= allow | deny | ask
PolicyState
identification : N
service : Service
serviceProvider : P ↓Entity
defaultMode : MODE
unknownMode : MODE
temporalConstraint : seq(TIME × TIME)
SetService
∆(service)
service? : Service
service
= service?
SetProvider
∆(serviceProvider )
provider? : ↓Entity
mode? : MODE
serviceProvider
= serviceProvider ∪ {provider? }
AlreadyKnownProvider
Ξ(mode)
provider? : P ↓Entity
mode! : MODE
provider ∈ serviceProvider
mode! = defaultMode
AllowModeProvider
Ξ(mode)
mode! : MODE
unknownMode = allow
mode! = allow
DenyModeProvider
Ξ(mode)
mode! : MODE
unknownMode = deny
mode! = deny
AskUser
Ξ(mode)
provider? : P ↓Entity
mode! : MODE
provider ∈ serviceProvider
mode! = allow ∨ mode! = deny
114
AskModeProvider
Ξ(mode)
mode! : MODE
unknownMode = ask
mode! = askUser
AskModeProvider = AlreadyKnownProvider ∨
AllowModeProvider ∨ DenyModeProvider ∨
AskModeProvider
115
Profile
ProfileState
identification : N
pseudonym : TEXT
personalProperties : P(TEXT × F TEXT )
servicePolicies : P PrivacyPolicy
mixingRate : N
∀ x , y : pseudonym • x = y
SetPseudonym
∆(pseudonym)
pseudonym? : TEXT
mixingRate > 0
pseudonym
= pseudonym?
GetPseudonym
Ξ(pseudonym)
pseudonym! : TEXT
pseudonym! = pseudonym
SetPersonalProperties
∆(Profile)
GetPersonalProperties
Ξ(Profile)
SetServicePolicies
∆(servicePolicies)
servicePolicy? : PrivacyPolicy
servicePolicies
= servicePolicies ∪ {servicePolicy?}
GetServicePolicies
Ξ(servicePolicies)
servicePolicies! : P PrivacyPolicy
servicePolicies! = servicePolicies
116
AP
ˆ
ENDICE C -- Aplica¸c˜ao da Especifica¸c˜ao
Neste apˆendice, a esp ecifica¸c˜ao do modelo apresentada no apˆendice A e no
apˆendice B ´e aplicada ao cen´ario de um shopping center, descrito no cap´ıtulo 5.
Assim como em (CAMPIOLO, 2005), algumas nota¸c˜oes foram adotadas:
• Em determinados pontos a linguagem textual ´e empregada para descrever
propriedades complexas, como por exemplo, a propriedade shape.
• Propriedades compostas por muitos elementos s˜ao resumidas com a nota¸c˜ao
reticˆencia (...).
• Alguns objetos s˜ao apresentados resumidos, explicitando somente as proprie-
dades relevantes para discuss˜ao.
• Alguns objetos n˜ao foram especificados (ex.: eventos), ap esar da existˆencia
de referˆencia.
117
Person : alice
identification = 1
profile = profile A
class = Person
description = client
position = (65, 85, 0)
mass = 57Kg
width = 47cm
height = 176cm
shape = cylinder
emittedSignal = {sig1}
positional = {position, speed, direction, orientation}
physical = {gender, age}
psychological = {personality}
speed = 2m/s
direction = West
orientation = West
gender = female
age = 23
personality = {(1, 95), (2, 80), (3, 80), (4, 70), (5, 70)}
hasObject = {}
hasEntity = {handheld }
Sensor : senIO
identification = 2
class = Entity
description = presence detector sensor
position = (100, 40, 16)
enabled = true
connections = server
communication = prot1
channel = com1
type = 5
perceptionShape = circle
perceptionDistance = 2m
knownSignal = presence
internalState = {detect[false]}
stateTransition = {sig1 → (detect[false], detect[true])}
118
Sensor : sen bookstore L
identification = 3
class = Entity
description = presence detector sensor
position = (68, 60, 16)
enabled = true
connections = server, handheld
communication = prot2, prot3
channel = com1, com2
offeredServices = {marketing service, ...}
type = 5
perceptionShape = circle
perceptionDistance = 2m
knownSignal = presence
internalState = {detect[false]}
stateTransition = {sig1 → (detect[false], detect[true])}
Sensor : sen bookstore M
identification = 4
class = Entity
description = presence detector sensor
position = (75, 25, 16)
enabled = true
connections = server
communication = prot2
channel = com1
offeredServices = {marketing service, ...}
type = 5
perceptionShape = circle
perceptionDistance = 2m
knownSignal = presence
internalState = {detect[false]}
stateTransition = {sig1 → (detect[false], detect[true])}
SignalType : presence
identification = 5
description = presence signal of a person
119
Signal : sig1
identification = 6
contents = {(presence, true)}
type = presence
source = {}
target = {senIO, sen bookstore L, sen bookstore M }
propagation = circle
range = 3m
constraints = {}
PortableDevice : handheld
identification = 7
class = Entity
description = handheld
position = (65, 75, 10)
mass = 0.10Kg
width = 10cm
height = 6cm
enabled = true
connections = sen bookstore L
communication = prot3
channel = com2
model = Palm Zire 21
input = {datebook button, addressbook button, power button,
up button, down button, display}
output = {display}
...
owner = alice
120
FixedDevice : server
identification = 8
class = Entity
description = computer to register privacy policy data
position = (45, 85, 10)
mass = 5Kg
width = 30cm
height = 40cm
shape = cube
enabled = true
connections = senIO, sen bookstore L, sen bookstore M
communication = prot1, prot2
channel = com1
model = Dell Dimension
input = {keyboard, network}
output = {monitor}
entry = ...
exit = ...
process = {(1, register policy1), (2, identify person), ...}
aliveProcess = {register policy1}
state = {}
stateTransition = {}
memory = {person info, privacy policy info...}
addressMemory = {(1A, person info), (6E , privacy policy info)}
event = {}
eventMap = {}
space = serverRoom
Object : shelf
identification = 9
class = Object
description = furniture
position = (60, 70, 0)
mass = 9Kg
width = 120cm
height = 200cm
shape = parallelogram
emittedSignal = {}
Location : alice location
symLocation = alice symbolic
relLocation = alice relative
121
SymbolicLocation : alice symbolic
place = bookstore L
point = (65, 85, 0)
RelativeLocation : alice relative
toObject = shelf
orientation = West
distance = 25
LocationController : location controller
registeredElement = {alice}
location = {(alice, alice loca tion)}
EnergyController : energy controller
device = {handheld}
energy = {(handheld, 95)}
TimeController : time controller
clock = 2h23m30s40 − 02/06/2007
scheduler = {(2h24m05s − 02/06/2007, e[1]),
(2h24m10s − 02/06/2007, e[2]),
(2h50m00s − 02/06/2007, f [1]),
(3h00m00s − 02/06/2007, d[1]), ...}
duration = {(10m − 0h0m0s, d[1]), ...}
frequency = {(50m − 0h0m0s, f [1]), ...}
SituationalController : situational controller
situation = {({shelf .stateOpened[true]}, s[1]), ...}
CommunicationController : communication controller
activeEntities = {handheld}
activeChannels = {com1, com2}
connections = {(com1, senIO), (com1, server), (com2, sen bookstore L),
(com2, handheld), ...}
area : {SquareArea[(50, 80)(60, 90)]}
restrictArea : {(SquareArea[(50, 80)(60, 90)], Interference)}
122
CommunicationChannel : com1
physicalChannel = cabe
source = {senIO, sen bookstore L, sen bookstore M }
target = {server}
propagation =
range =
transmissionRate = 10Mbps
frequency = 350MHz
constraints = {}
CommunicationChannel : com2
physicalChannel = wireless
source = {sen bookstore L}
target = {handheld}
propagation = line
range = 5m
transmissionRate = 100kbps
frequency =
constraints = {object obstruction, signal lost}
Door : door
identification = 10
class = Object
description = main door
position = (100, 50, 0)
width = 10
height = 2
shape = rectangle
initialState = {stateOpened.false}
possibleState = {stateOpened.false, stateOpened.true}
changeState = {(open, (stateOpened.false, stateOpened.true)),
(close, (stateOpened.true, stateOpened.false))}
opaque = true
alwaysOpened = false
stateOpened = false
123
Space : server room
identification = 11
class = Space
description = server room
position = (40, 80, 0)
width = 10
height = 3
shape = rectangle
name = server room
entities = {server}
Space : bookstore L
identification = 12
class = Space
description = Bookstore L
position = (68, 60, 0)
width = 20
height = 3
shape = rectangle
name = bookstore L
persons = {alice, ...}
objects = {shelf , ...}
entities = {handheld, sen bookstore L, ...}
Space : bookstore M
identification = 13
class = Space
description = Bookstore M
position = (75, 25, 0)
width = 25
height = 3
shape = rectangle
name = bookstore M
entities = {sen bookstore M , ...}
124
Environment : shopping
name = shopping
space = {server room, bookstore L, bookstore M }
timeController = time controller
situationalController = situational controller
locationController = location controller
energyController = energy controller
communicationController = communication controller
Profile : profile A
identification = 14
pseudonym = 4fasd452
personalProperties = {sports, {gymnastics}}, {films, {action movies}},
{books, {self − help}}
servicePolicies = marketing policy
mixingRate = 1
Profile : profile B
identification = 15
pseudonym = alice
personalProperties = {sports, {gymnastics}}, {films, {action movies}},
{books, {self − help, traveling}}
servicePolicies = marketing policy
mixingRate = 0
PrivacyPolicy : marketing policy
identification = 16
service = marketing service
serviceProvider = sen bookstore L, sen bookstore M
defaultMode = allow
unknownMode = deny
temporalConstraint : (8h00m00s, 18h00m00s)
Service : marketing service
identification = 17
description = MarketingService
created = 0h24m05s − 01/01/2007
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
