jonathanmayer

From a very quick skim of the repositories, this appears to be quite limited transparency. The documentation gives a decent high-level overview of how Tweet recommendation works—no surprises—and the code tracks that roadmap. Those are meaningful positive steps. But the underlying policies and models are almost entirely missing (there are a couple valuable components in [1]). Without those, we can't evaluate the behavior and possible effects of "the algorithm."

Several comments suggest systematically comparing FCC data to what ISP websites say about availability. My research group did this! Here's the paper:

* This could be a Federal Trade Commission problem. T-Mobile, like all major ISPs, has made public representations about upholding net neutrality principles [1]. These voluntary commitments were part of the Trump-era FCC's rationale for repealing net neutrality rules. Breaching the commitments could constitute a deceptive business practice under Section 5 of the Federal Trade Commission Act.

* This could also be a Federal Communications Commission problem. When repealing the Obama-era net neutrality rules, the Trump-era FCC left in place a set of transparency requirements [2]. Making an inaccurate statement about network management practices can be actionable under that remaining component of the FCC's net neutrality rules.

I haven't seen a comment from T-Mobile, so to be clear, that's just based on the report.

In 2017, the FCC determined that T-Mobile had violated federal law in a data breach involving customer credit information [1]. There was reportedly no fine because Congress has imposed a strict one-year statute of limitations on FCC enforcement actions.

In 2020, the FCC charged T-Mobile with again violating federal law in failing to protect customer location information [2]. The FCC proposed a $91.6M fine, widely criticized as insufficient at the time [3-4]. I don't believe the FCC has finalized or collected that penalty.

There have been several other incidents, including in 2018 [5], 2019 [6], early 2020 [7], and late 2020 [8].

I hope there has not been a new data breach. But if there has been, this is the latest in a pattern, and the incentives have to change.

There's much more than that, including: privacy and security review before a study launches, a data minimization requirement, a sandboxed data analysis environment with strict access controls, and IRB oversight for academic studies.

> IMO this seems to provide worse privacy than even Google and Micro$oft's telemetry, which at least use differential privacy to make sure that each individual's privacy is somewhat protected (the data you send is randomised so even if the aggregator is compromised by a malicious third party (e.g. NSA) individuals have some degree of plausible deniability).

The vast majority of Google and Microsoft telemetry does not involve local differential privacy. Google, in fact, has almost entirely removed local differential privacy (RAPPOR) from Chrome telemetry [1].

We've been examining the feasibility of local differential privacy for Rally. The challenge for us—and why local differential privacy has limited deployment—is that the level of noise makes answering most (often all) research questions impossible.