spanicker / ip-blindness Goto Github PK

Law, insurance, and best practice demand ubiquitous post-intrusion forensic data in almost all large organisations.

Alleged privacy introduced by ip-blindness will either destroy their audit efficacy (if, against their policies, they disabled their logging), or it would only be temporary and would be reversible after-the-fact.

Services that are embedded in a third-party context will now see distinct IPs for each top-level domain that the user is visiting. This negatively impacts the ability to count the number of distinct users across a set of sites, and makes it easier to inflate impressions and ad clicks by having these same users engage on multiple sites.

Some attributes, such as GeoIP, may allow sites to validate observed regional distributions against what is expected.
We are keen to discuss any suggestions that could improve defensibility within our privacy objective of preventing scaled cross-site tracking.

Hey, it's not really clear how the proposal will solve the following issues:

1. Performance - It will add a minimum of 1 extra hop, and additionally it could create issues on the routing level. If the extra hop privacy proxy doesn't peer with the CDN and the user's ISP the latency would suffer
2. Trust - The NAT will have too much power to monitor, filter and censor traffic that flows through it

It would be nice to try and consider these issues

,🧠👣🦻✊

Hi @bslassey,

Thank you for sharing details about this proposal in today's W3C meeting. I have a follow-up question and want additional clarification regarding the question about site operators/1st party owners/1st party sets. As a publisher/site owner of somesite.com, will I see the original IP of users visiting somesite.com or will their IPs be proxied/masked for me as well?

thanks

Keselamatan paling penting bagi saya sebagai seorang yang di bagi tahu berkenaan laman web..sebab tu saya mengambil berat tentang perkara ini

https://support.google.com/accounts?p=a-sc-area

In addition to the targeting use cases described in #20, IP Geolocation may also be used for regulatory and contractual requirements. Will the Geo granularity described create any anticipated difficulties in meeting regulatory needs?

I agree we need to provide some form of general non-exact Geolocation to sites in order to allow this proposal, but country-level is insufficient to handle privacy compliance properly, we have to be able to resolve at least down to the US State level right now, as we have different compliance regimes rising in a number of states, with one known in CA, but more likely to come.

IETF RFC 8805 allows for country, ‘region’ (state in US), and city level mappings to be advertised. While the IP Protection proposal will not retain all state/city level granularity, we would like to retain enough to keep inferred geographic content relevant to users, and GeoIP based performance optimizations functioning.

To achieve this, Chrome is considering mapping many unique cities/regions to groups of combined cities/regions. We call these Geos. We are considering using a threshold of 1 million estimated human population for each created geo. This geo will then be shared in the public IP Geolocation feed.

Which use cases of yours would 1 million people sufficiently cover and which use cases would not be sufficiently covered?

At some point, a service may have confidence that a given request is associated with an abusive client. Perhaps the request is willfully causing quality of service issues, demonstrates intent to harm another user, or otherwise violates a site’s terms of use.

Historically, services would ban a user by their IP address. This has become less common with the rise of the mobile internet, but IP is still a surprisingly common tool in scaled abuse scenarios.

We would like to provide websites with the ability to request that the proxy no longer send traffic from the user of the proxy that issued the given request. We need to do this without re-introducing the cross-site tracking risk that the proxy is designed to counter.

Are there existing protocols or limitations relevant to your service that we should be mindful of? Would it be acceptable if embedded services would have to ban a user once for each top-level context (e.g. a.com on example1.com and a.com on example2.com would need to ban the user separately

The marketing division of our company is considering implementing website personalisation. The solution uses a visitors IP address to identify the businesses that are visiting our website. They provide us with the name of the business and further details such as industry, revenue etc. Using this data, we can then dynamically tailor the content of our website to show our visitors the most relevant information.

The solution never identifies individuals and only identifies businesses that have 10 or more employees. Our vendor has also confirmed that they only capture the IP address of the visitor and no other points of entropy that would allow an individual to be fingerprinted.

Will the proposed solution stop the website personalisation tool from being able to access the IP address and therefore stop it from working? If so, is there token or something similar that could be issued to allow the tool to access the IP address?

IP addresses serve a variety of use cases beyond anti-fraud. IP can be used for analytics, measurement, regional preferences, tracking paid subscribers, and many more. As Chrome seeks to mask IP addresses, we are working to ensure that valid use cases are preserved while also improving privacy on the web.

How does blocking IP challenge your different use cases? What other ways could actors achieve these use cases without IP addresses used for fingerprinting? What potential replacement signals could we extract from an IP address and pass as a new, standalone (and possibly attested?) signal?

Movement for an Open Web (“MOW”) is an action group founded to advocate for a competitive, open internet. Many members were involved in the Competition and Markets Authority (CMA) Online Platforms and Digital Advertising inquiry in 2020. MOW is the chief complainant in Google’s Privacy Sandbox case, and we initially applied to the CMA for interim measures to prevent Google’s proposed changes to the browser. Whistle-blower protections are recognised in law the world over and play a vital role in helping the authorities gather necessary evidence from key witnesses, whose identity must be protected to reduce the likelihood of retaliation. We note that the CMA’s Privacy Sandbox case team have agreed to protect the identity of our members.

We are submitting the following issue in the W3C forum at the request of the CMA and Google’s recommended procedure for filing issues with their Privacy Sandbox, according to section 12 of Google’s Commitments.

Google’s Gnatcatcher Proposal is designed to restrict from others the IP addresses Google’s Ad Systems will continue to benefit from.

Most recently, Google has extended this proposal to the Pixel 7 Android phone. [1]

There is also a substantive issue for rivals on how they can continue to access IP addresses for the business-facing functions of fraud prevention and content filtering. IP addresses can also be used to tailor advertisements to business customers, where multiple employees of the same organisation share the same business IP address. The IP Protection proposal on GitHub acknowledges IP address’s critical functional role in the web and states that they ‘will continue to be instrumental in routing traffic, preventing fraud and abuse, and performing other important functions for network operators and domains’. Our question is how will this work in practice?

In our view, Google's proposal without modification would self-preference its own business solutions, and hence it would be helpful to explore other options that allow for the innocuous and helpful data handling processes. One such method would be requesting ISPs to change IP consumer household addresses more often than business IP addresses by using a DHCP lease time configuration. Another would be the use Network Address Translation to combine more connections from an ISP under the same IP address thus reducing the IP addresses utility.

If Google does proceed with its Gnatcatcher proposal, we recommend a robust choice mechanism for consumers to be properly informed of the impact of their decision and ideally alternative choices available to them, rather than have such an option bundled into the browser/operating system by default. It would be helpful for Google to also address how the design they envisage will continue to enable a competitive market of business-facing solution providers to address the specific threats to businesses listed by the W3C Antifraud Community Group (https://github.com/antifraudcg/use-cases/blob/main/USE-CASES.md).

We also welcome responses from @spanicker, @JensenPaul, @bslassey, @miketaylr, or any other Google representatives in this forum.

The 2-hop proxy lacks the ability to detect or act on reports of abuse, and remediation of this limitation may come at some cost of complexity or privacy.

Generally, 2-hop proxy improves privacy over 1-hop by ensuring that neither proxy can see both the client IP address and the destination. However our initial scope is a pre-determined set of 3P trackers, so it's not equivalent to the larger privacy concern of a user's browsing history.

IP addresses are a poor authentication method, and GeoIP databases are a poor authorization method. Mobile roaming typically performs home routing so that a person in CA and subject to CA laws, would actually be accidentally circumventing compliance systems if using a SIM card from Europe, for example. If we're looking at a metric for privacy, the population of an area and the number of Internet users in that area might be correlated differently for the US vs other countries.

Services want geolocation for different reasons, regulatory compliance and localisation I guess would be the main reasons. Allowing for services to select finer-grained or coarser-grained geolocation that allows them to achieve their goal while not allowing reduction of the anonymity set beyond that which is required would benefit user privacy.

Under GDPR or CCPA, it is possible to remove yourself from GeoIP databases, so if you were using a GeoIP database for compliance then this can be circumvented by removing your IP from the database. This could have interesting consequences for compliance.

There is also a deanonymisation vector that can be used if you can influence (or more slowly, only observe) the database. You could cause a user's IP to be reported differently as the database updates, to narrow down to a subnet. The best mitigation for this would be to only update infrequently, but at the cost of accuracy.

Originally posted by @irl in #1 (comment)

near_path_nat.md says:

For HTTP/3 traffic the browser assembled UDP packets are sent via MASQUE to the IPPS and then the IPPS sends the UDP packets to the target server, essentially just adding the IP header. The IPPS forwards data received from the target server back to the browser via the same MASQUE streams that the outgoing data traversed.

Is there an analysis somewhere of how much the ability of a group of servers to directly observe packet loss (because forwarding happens at the UDP level) allows them to correlate connections? (The same question obviously also exists for connections that either drop entirely or strongly change their latency because the user switched between wifi and mobile networks, but I guess that's less avoidable.)