thesis: add architecture image & add direct citation to Iwaya article
Pedro Lucas Porcellis porcellis@eletrotupi.com · 1 month ago
bb846a6707c530021b78ab3a062a8b4dc7fc099b Browse filesParents
e5e48b6Changed files
4
Additions
+59
Deletions
-24
monografia/chapters/development.tex
1 1
\chapter{Desenvolvimento}
2 2
3 +
Como delineado as tecnologias no capítulo anterior, aqui se apresenta a
4 +
arquitetura, demonstrando como todas as tecnologias apresentadas acima se
5 +
conectam e conversam entre si.
6 +
7 +
\begin{figure}[h]
8 +
\centering
9 +
\caption{Arquitetura e elementos do Sistema}
10 +
\label{fig:arch}
11 +
\includegraphics[width=0.9\linewidth]{arch.png}
12 +
\source{O autor}
13 +
\end{figure}
14 +
15 +
3 16
Este capítulo detalha o funcionamento de algumas funcionalidades
4 17
desenvolvidas durante o projeto. Apenas algumas funcionalidades mais
5 18
chaves são abordadas neste capítulo, como o registro de humor, vinculo
6 19
de um gatilho, indicadores, e o registro de atividades.
7 20
12 25
email e senha. Existe aqui um elemento proposital: uma forma de
13 26
garantir um certo nível de anonimato, em que o usuário não precisa se
14 27
identificar com um nome ou número de telefone, tampouco ativar a conta
15 28
através de uma plataforma de terceiro, como Google ou Facebook.
16 29
17 -
Isso se dá, em especial, por dois motivos. Primeiro, o uso de OAuth
18 -
exigiria uma conexão com plataformas de terceiro, que poderiam então
19 -
rastrear quais usuários têm acesso a qual aplicativo — algo que é
20 -
fartamente documentado na literatura sobre os mecanismos usados por
21 -
tais plataformas para rastrear e monitorar o acesso a dados de
22 -
usuários, com o fim de vender e monetizar essas informações.
30 +
Isso se dá, em especial, por dois motivos. Primeiro, o uso de uma tecnologia de
31 +
autenticação, como por exemplo, \textit{OAuth} \cite{Hardt:2012} exigiria uma
32 +
conexão com plataformas de terceiro, que poderiam então rastrear quais usuários
33 +
têm acesso a qual aplicativo -- algo que é fartamente documentado na literatura
34 +
sobre os mecanismos usados por tais plataformas para rastrear e monitorar o
35 +
acesso a dados de usuários, com o fim de vender e monetizar essas informações.
23 36
24 -
Essa preocupação não é hipotética: um estudo que interceptou o tráfego de rede de
25 -
36 dos aplicativos mais populares de saúde mental (depressão e cessação de
26 -
tabagismo) encontrou transmissão de dados a pelo menos um terceiro em 92\% deles,
27 -
sendo que 81\% enviavam dados especificamente a serviços operados por Google ou
28 -
Facebook — e apenas 59\% desses casos declaravam esse compartilhamento em política
29 -
de privacidade \cite{Huckvale2019}.
37 +
Essa preocupação não é hipotética: um estudo que interceptou o tráfego de rede
38 +
de 36 dos aplicativos mais populares de saúde mental (depressão e cessação de
39 +
tabagismo) encontrou transmissão de dados a pelo menos um terceiro em 92\%
40 +
deles, sendo que 81\% enviavam dados especificamente a serviços operados por
41 +
Google ou Facebook -- e apenas 59\% desses casos declaravam esse
42 +
compartilhamento em política de privacidade \cite{Huckvale2019}.
30 43
31 44
Um estudo posterior, focado exclusivamente em 27 aplicativos de saúde
32 45
mental mais populares da Google Play Store, confirmou o mesmo padrão e
33 -
o caracterizou formalmente como uma ameaça de \textit{linkability}
34 -
(vinculabilidade) e \textit{identifiability} (identificabilidade): mesmo quando os
35 -
identificadores enviados a terceiros são pseudônimos (como \textit{advertising IDs}
36 -
ou hashes), eles ainda permitem que provedores de publicidade associem o
37 -
comportamento de um usuário através de diferentes aplicativos e serviços
38 -
\cite{Iwaya:22}. Como os próprios autores resumem, a mera vinculação de um
39 -
usuário a um aplicativo de saúde mental já pode revelar que essa pessoa possui
40 -
uma condição psicológica — seja ansiedade, depressão, ou, no caso de um
41 -
aplicativo como o Nexo, Transtorno Afetivo Bipolar —, tornando usuários desses
42 -
aplicativos particularmente vulneráveis a esse tipo de exposição
43 -
\cite{Iwaya:22}.
46 +
o caracterizou formalmente como uma ameaça:
47 +
48 +
\begin{quote}
49 +
A maioria dos aplicativos representa ameaças relacionadas à rastreabilidade,
50 +
à identificação e à detecção. Isso constitui um risco, pois alguns terceiros
51 +
podem rastrear, reidentificar e detectar as ações e os dados dos usuários. A
52 +
falta de conscientização também está relacionada a essas ameaças, uma vez que
53 +
os aplicativos não explicam (por exemplo, na política de privacidade) os
54 +
riscos que a publicidade direcionada representa para pessoas com problemas
55 +
mentais, bem como o risco de reidentificação e divulgação de condições de
56 +
saúde mental (por exemplo, ansiedade, depressão).
57 +
\cite[p.~3, tradução nossa]{Iwaya:22}
58 +
\end{quote}
59 +
60 +
Como os próprios autores resumem, a mera vinculação de um usuário a um
61 +
aplicativo de saúde mental já pode revelar que essa pessoa possui uma condição
62 +
psicológica -- seja ansiedade, depressão, ou, no caso de um aplicativo como o
63 +
Nexo, Transtorno Afetivo Bipolar --, tornando usuários desses aplicativos
64 +
particularmente vulneráveis a esse tipo de exposição \cite{Iwaya:22}.
44 65
45 66
No caso do Nexo, essa cadeia de inferência é especialmente
46 67
sensível: a presença do aplicativo na lista de apps instalados de um usuário,
47 68
associada ao seu identificador publicitário, permitiria a uma plataforma como a
48 69
Meta inferir uma possível condição de saúde mental do usuário para fins de
317 338
registro de humor, destaca a dimensão mais relevante daquele registro
318 339
(como ``Ansiedade alta'' na figura \ref{fig:screenshot-history}); para um
319 340
gatilho, indica sua categoria, e assim por diante.
320 341
321 342
\FloatBarrier
monografia/chapters/tech.tex
1 1
\chapter{Tecnologias}
2 2
3 3
Este capítulo apresenta as principais tecnologias empregadas no desenvolvimento
4 4
do aplicativo, organizadas de acordo com a camada da arquitetura em que atuam:
5 5
\textit{front-end}, \textit{back-end} e infraestrutura/persistência de dados.
9 9
O termo \textit{frontend} refere-se à camada de um sistema responsável pela
10 10
interação direta com o usuário: a interface visual, a lógica de apresentação e
11 11
o processamento que ocorre no dispositivo do próprio usuário, seja um navegador
12 12
ou, como no caso do Nexo, um aplicativo móvel, conforme
13 13
~\citet{sommerville:2010}. É o frontend que renderiza telas, captura entradas
14 -
do usuário (como toques e formulários) e comunica-se com o \texit{backend}
14 +
do usuário (como toques e formulários) e comunica-se com o \textit{backend}
15 15
através de requisições de rede, geralmente utilizando APIs. No caso do Nexo,
16 16
essa camada é implementada com \textit{React Native} e Expo, permitindo que a
17 17
mesma base de código seja compilada tanto para Android utilizando bibliotecas
18 18
em \textit{TypeScript}.
19 19
284 284
ao documentar e automatizar o processo de provisionamento, o projeto
285 285
favorece um modelo mais alinhado aos princípios de privacidade e de
286 286
autonomia sobre os dados dos usuários, permitindo que instituições ou
287 287
indivíduos preocupados com a confidencialidade de dados sensíveis de
288 288
saúde mental hospedem e controlem sua própria instância da aplicação.
/dev/null → monografia/images/arch.png
Binary file
monografia/monografia.bib
1 1
@article{Iwaya:22,
2 2
title={On the privacy of mental health apps},
3 3
volume={28},
4 4
DOI={10.1007/s10664-022-10236-0},
5 5
number={1},
468 468
ISBN={9780321601919},
469 469
publisher={Addison-Wesley},
470 470
author={Humble, Jez and Farley, David G.},
471 471
year={2011},
472 472
collection={A Martin Fowler Signature Book}
473 +
},
474 +
475 +
@book{
476 +
Hardt:2012,
477 +
type={Request for Comments},
478 +
title={The OAuth 2.0 Authorization Framework},
479 +
url={https://datatracker.ietf.org/doc/rfc6749/},
480 +
DOI={10.17487/RFC6749},
481 +
abstractNote={The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]},
482 +
number={RFC 6749},
483 +
institution={Internet Engineering Task Force},
484 +
author={Hardt, D.},
485 +
year={2012},
486 +
month=oct
473 487
}