#permacookie

[illuminarch]

Supercookies monitoram navegação e não podem ser apagados do navegador

A navegação da web vive de publicidade e, para isso, muitas gigantes da tecnologia se empenham em rastrear nossos passos pela rede em busca de direcionar a melhor propaganda e obter um resultado mais efetivo com publicidade. Afinal, estamos falando de dinheiro no bolso de empresas como Google, Facebook e afins. Para um processo mais eficiente neste sentido, existem os chamados cookies. São pequenos arquivos que muitos sites usam para identificar usuários únicos e salvar dados relacionados aos seus hábitos e preferências de navegação, ou simplesmente para manter uma sessão aberta. Conheça os chamados supercookies que monitoram a navegação e praticamente não podem ser apagados do navegador.

E sim, eles também são os culpados de que cada vez que você procura um produto acaba vendo dezenas de anúncios aonde quer que vá, o que costumamos chamar de ‘retargeting‘.

No entanto, nos últimos anos, à medida que os dados se tornaram o negócio emergente da Internet, algumas plataformas estão apostando em um tipo de cookie um pouco diferente, que não podemos nos limitar a excluir da seção ‘Opções’ de nosso navegador.

Mas os chamados supercookies são muito mais difíceis de excluir e bloquear, o que torna quase impossível para os usuários proteger sua privacidade durante a navegação mesmo se recorrermos ao modo privado.

O nome ‘supercookie’ (‘permacookies’ ou ‘zumbi cookies’) foi aplicado a uma ampla gama de sistemas de rastreamento para nossos dados de navegação.

Supercookies monitoram navegação e não podem ser apagados do navegador

Uma das técnicas utilizadas pelos rastreadores supercookie baseia-se no aproveitamento do funcionamento do cache do navegador: normalmente, eles compartilham recursos entre diferentes sites (por exemplo, carregar uma imagem incorporada em um site apenas uma vez se já houver uma exibida anteriormente em outras).

No entanto, isso fez com que os trackers criassem supercookies codificando identificadores em uma imagem, que é capaz de coletar dados em todas as vezes que acessamos de vários sites, permitindo-nos reconstruir nossos hábitos de navegação.

Para evitar isso, a Mozilla anunciou há alguns dias que seu novo navegador Firefox 85 implementará ‘particionamento de cache’. Assim, cada site pode acessar apenas arquivos carregados do mesmo domínio.

Impressões digitais do usuário da Internet

Um segundo método para criar supercookies, amplamente utilizado alguns anos atrás, foi baseado em fazer um uso ‘inventivo’ do sistema HTSTS (HTTP Strict Transport Security). Esta é uma tecnologia que permite ao site instruir o navegador a usar o protocolo HTTPS. HTTP.

Nestes casos, o navegador, ao responder ao referido pedido, envia vários ‘sinalizadores’ (informações sobre o equipamento) que permitem a identificação do utilizador.

Essa técnica já foi bloqueada há alguns anos pelos principais navegadores, embora as novas técnicas de ‘impressão digital’ possam ser consideradas uma evolução das anteriores e, infelizmente, ainda sejam muito atuais.

Outros exemplos

Outro exemplo representativo de supercookies seriam os criados pelos botões ‘Curtir’ do Facebook que podemos encontrar inseridos em várias páginas da web. Eles permitem à rede social coletar informações sobre nossos hábitos de navegação em todas elas.

Pior ainda: em alguns casos, foi detectado que esses supercookies foram criados por operadoras de telecomunicações, que injetam os chamados ‘cabeçalhos de rastreamento’ no nível da rede, para que não possam ser bloqueados pelos usuários.

Genbeta

O post Supercookies monitoram navegação e não podem ser apagados do navegador apareceu primeiro em SempreUpdate.

source https://sempreupdate.com.br/supercookies-monitoram-navegacao-e-nao-podem-ser-apagados-do-navegador/

[attributionlabs-blog]

Why is AT&T [still] Altering My Outgoing Non-SSL HTTP Requests? Should I be Concerned?

Some background

In November of 2014, we did an analysis once news broke about Permacookies, the phenomenon whereby many carriers, including AT&T, Verizon, and Sprint, were altering outgoing non-SSL HTTP traffic and tagging such.

The implications then included the ability for sites to track users in the internet and thus the ability to get information on a user if a site was a partner.

After lots of reporting and mild internet outrage, they ceased this practice.

All HTTP headers aren’t created equal

An added “Via” HTTP header isn’t the same as what they were adding previously.

In the quest to deliver fast content to our network speed challenged devices, it appears AT&T is using some proxies, which is normal, trying to see if content is available on cached servers, and when not, the data is grabbed fresh, but... the proxy via which the request was made tags and forwards the request on to the content server, and thus in this case gives away some identifying information, ... which could be exploited for some sort of tracking.

The destination server could also identify a user as a possible AT&T customer by looking up their IP address in one of many IP Geo-location Services

What is our expectation of our Internet Service Providers (ISP)?

When we use the internet as provided by an ISP, at home or on the go, do we just expect a connection to the internet, or are we OK with the ISP breaking down and thus inspecting our data to try and optimize content delivery?

Who to have issue with?

Initially I was holding the ISP to the flame, not happy to see my traffic tagged. However, I am coming around to faulting the content provider. If all content providers provided their content encrypted, such would not be open for this specific inspection and modification. The content of an HTTPS request is only visible to the destination server and is delivered over and encrypted SSL tunnel.

Back then (we are pretty sure) they weren’t adding this tag

Looking back at our old Permacookie research with AT&T, we did not previously see this in the data.  It could be new, or as caching is subjective and open to other factors, it could have existed previously but we didn’t catch it.

Things to ponder

This is not the same as the Permacookie, but one’s data is still being modified and tagged, even if in this case it is innocuous.

It is something perhaps we take for granted, that when we make requests on the internet, they don’t go straight from device to destination.

In the process of routing and delivery, the various pieces of a seemingly simple web request are in fact a many things/sub-requests (including DNS, page content, page resources, etc) and are inspected and delegated to/by many hands.

Thus, I guess this is a reminder that each party can glean and in some cases alter the traffic as it passes through their gateways.

Other carriers

As of this week, in limited testing, Verizon and Sprint were not adding these headers to this specific request.

How to test for oneself?

Disconnect from WIFI

Go to our header echo page: http://attributionlabs.com/Home/Echo

Connect to WIFI

Go to our header echo page: http://attributionlabs.com/Home/Echo

Compare the headers you see

Some of our data points

[attributionlabs-blog]

An Alternate Approach to Subverting the Permacookie

Purpose:

Mobile Internet Service Providers (ISPs) are violating their customer's privacy by tagging all unencrypted outgoing HTTP traffic one sends through them, which in turn becomes a tracking ID in multiple ways. Mitigation steps exist to combat this, to include use of VPNs to encrypt data from being read or altered by the ISP. However, we sought to explore other non-obvious approaches.

Approach/Hypothesis:

We explored ways to subvert his behavior by attempting to invalidate the data sent along by the ISP, or to halt the sending of such data/headers at all.

Briefly, our respective approaches were to send packets that already had the HTTP header populated with the appropriate name but with alternate values (i.e. adding a random but valid tracking ID to each packet, thus making the traffic inaccurate and unusable), as well as explored ways to get the ISP technologies to stop providing any tracking header at all.

Summary Finding:

Though not an exhaustive effort, in the end, we were unsuccessful to both ends. In the first case ISPs ignored the spoofed headers we provided, and in the latter experiments, we were unable to introduce any additional or altered header that caused the ISP to not include the tracking header. What we learned aided in our understanding of what is in place, and we think the sharing of the approach and knowledge gained could aid the respective public dialog. Thus we have published details of this research.

Background:

Many US mobile carriers are adding a tracking header to all outgoing unencrypted HTTP requests. They have different respective header names, but it is the same pattern and likely use of the same underlying technology.

It has been dubbed "permacookie" as it has a familial behavior to browser cookies. Client browser cookies are HTTP headers managed at the client machine-level and use a particular HTTP name. Permacookies are managed at the mobile ISP level, and have different HTTP header names depending on the cell carrier.

Risk & exposure:

Carriers are modifying all your unencrypted web activity by tagging all unencrypted HTTP requests with a unique custom header. This includes requests made by apps.

As carriers are embedding your unique ID, which can be used to query for demographic, geographic, and behavioral info, to every unencrypted HTTP request, sites can thus identify you immediately, over time, and across properties. Such can be used inclusively for filtering content, and customizing advertisements. (At the moment, less is known publicly on how it is being utilized by sites.)

In the news:

A few year back it was reported that "Routers from Juniper Networks will soon include Feeva's zipcode tracking software, assuming ISPs want it."

Weeks ago it broke that "Verizon Wireless was injecting identifiers that link its users to Web requests" and perverting users' privacy. Later others disclosed that Verizon was not alone.

As of this week, AT&T is claiming to cease use of it, for now, but no word from other carriers.

Are you tracked?

To see such for yourself, visit the sites below, first when on your carrier network, and then later via WIFI. Best approach is to turn off WIFI when executing the carrier test.

Lessonslearned.org's informative page identifies the carrier specific headers (See "Broadcast UID")

Our echo page shows all headers included in any request. If using a cell phone, tablet, or hot-spot for internet, the respective permacookie header will be present if such has been added.

Note: not all towers for the guilty carriers are active, but was for all used in our tests.

Techniques to combat:

Obvious: Encrypt the data so that the carrier router does not have chance to inject HTTP header (Method: SSL sites and VPNs)

Non-obvious: Trick ISP routers by altering requests so they see such as already accurately tagged or not requiring tagging (we discuss such below)

"Obvious" techniques to get around tracking:

Only use SSL sites and resources. Problem with this approach is that not all sites are SSL and even requests inside these sites might not be all SSL.

Use of trusted local anonymous HTTPS proxy. Problems with this approach: hard for lay-users, and who has a trusted local (ie before you hit the internet provider) proxy at their disposal? (Removed after some distance and clarity, as this did not solve the problem, though would allow one to modify outgoing traffic if indeed there was a way to trick the ISP into not tagging via pre-tagging.)

Use of a trusted anonymous HTTPS proxy that strips these headers. Problem with this approach: requires special proxy tuned to remove these headers, and the ISP is still tracking your use, though destination sites would be prevented from seeing such

Use of trusted VPN. This is the best approach as you gain an all ports all protocols tunnel from you to VPN node, while the ISP is in the dark and prevented from seeing/modifying any requests. Problem with this approach: such requires constant connection to a VPN from your mobile device.

Note: proxies are a primitive tool requiring semi-sophisticated technical background, thus not best approach for lay-users. "Non-obvious" approach explained:

We did some light research and development to see if we could attack this from another angle. Specifically, we explored adding fake tracking headers to HTTP requests and seeing if the ISP routers would then not add their own tracking headers, thinking such were already accurately tagged. Following, user X might not be tracked or exposed, and we could poison the well of tracking and exposing users to sites. We also tried modifying and adding other headers (ie DNT) to see if such had any effect.

Unfortunately, we were initially unsuccessful in this hypothesis, as AT&T always added their own HTTP header, even when they saw our fake ones. We could re-open this effort in the future, but... as AT&T has claimed they will stop using the permacookie we decided to temporarily close the case and seek other attribution endeavors.

"Non-obvious" approach deep-dive:

We built a simple echo web page that outputted all headers for an incoming web request

We built a web page that itself made AJAX requests from one's local browser, via HTTP, to the above echo server

On the above page, there were 3 requests: one on page load, one via AJAX unaltered, and one AJAX with variations of AT&T's header added

The goal was to see if AT&T would not add it's own header if it saw an appropriately formed HTTP header already existing

To test, one need run the page above on their mobile device while not on WIFI

As noted above, this approach was unsuccessful in our quest to prevent the ISP router from adding a header attributed to us

We also observed that carriers ignored the Do Not Track (DNT) header when we included such

If we were successful in spoofing the header, we then planned to see if we could get different advertisements served to us, though we would have been required to locate a partner of AT&T that was consuming the header

Last words:

Our quest to subvert carrier unencrypted HTTP request tagging via spoofing was unsuccessful. We seek to contribute to the public dialog by sharing our approach and results. We will update this post if we continue this research in the future.