jonathanmayer

Context: I teach at Princeton and study social media and recommendation systems.

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."

[1] https://github.com/twitter/the-algorithm-ml

Context: I teach at Princeton and used to work at the FCC.

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

https://dl.acm.org/doi/10.1145/3419394.3423652

And here's a followup project by investigative journalists at The Markup:

https://themarkup.org/still-loading/2022/10/19/dollars-to-me...

I previously served as CTO of the FCC Enforcement Bureau. A couple thoughts on the regulatory dimensions of this report.

* 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.

[1] https://www.t-mobile.com/responsibility/consumer-info/polici...

[2] https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A...

Hi, I previously served as CTO of the FCC's Enforcement Bureau, where I worked on then-Chairman Wheeler's Robocall Strike Force. I'd like to offer a few observations that might be of interest.

* T-Mobile, like the other carriers, is offering a numerator and not a denominator. These call filtering services are plainly valuable, but it's difficult to evaluate how effective they are based on current public evidence.

* It isn't a coincidence that the top robocall destinations include locations that are popular for retirement. These scams disproportionately target and take advantage of older customers.

* Call authentication (STIR/SHAKEN) is helping, and will continue to become more effective. The FCC did not push carriers to rapidly adopt call authentication during the last administration; Congress eventually stepped in with the TRACED Act, and the FCC has since made STIR/SHAKEN a top priority.

T-Mobile has had recurring data security deficiencies. I know because I served as CTO of the FCC's Enforcement Bureau, before returning to academia.

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.

[1] https://www.nexttv.com/news/fcc-admonishes-t-mobile-breach-1...

[2] https://www.fcc.gov/document/fcc-proposes-916m-fine-against-...

[3] https://docs.fcc.gov/public/attachments/FCC-20-27A4.pdf

[4] https://docs.fcc.gov/public/attachments/FCC-20-27A5.pdf

[5] https://www.theverge.com/2018/8/24/17776836/tmobile-hack-dat...

[6] https://www.bleepingcomputer.com/news/security/t-mobile-disc...

[7] https://www.bleepingcomputer.com/news/security/t-mobile-data...

[8] https://www.bleepingcomputer.com/news/security/t-mobile-data...

(Context: I teach computer security at Princeton and have a paper at this week's Usenix Security Symposium describing and analyzing a protocol that is similar to Apple's: https://www.usenix.org/conference/usenixsecurity21/presentat....)

The proposed attack on Apple's protocol doesn't work. The user's device adds randomness when generating an outer encryption key for the voucher. Even if an adversary obtains both the hash set and the blinding key, they're just in the same position as Apple—only able to decrypt if there's a hash match. The paper could do a better job explaining how the ECC blinding scheme works.

Have you thought about using central/global differential privacy (which tends to have much less noise) on the "high level aggregates" or "aggregated datasets" that persist after the research study ends?

Yes. Central differential privacy is a very promising direction for datasets that result from studies on Rally.

It's a little worrying to think that this disclosure process might be done with no formal privacy protection. See the Netflix competition, AOL search dataset, Public Transportation in Victoria, etc. case studies of how non-formal attempts at anonymization can fail users.

I've done a little re-identification research, and my faculty neighbor at Princeton CITP wrote the seminal Netflix paper, so we take this quite seriously.

Our team looked closely at the Google, Microsoft, and Apple local differential privacy implementations when building Rally. It helped that we have friends who worked on RAPPOR.

I am not aware of any public announcement or explanation. Which is... probably intentional, since Google is removing a headline privacy feature from Chrome.

Would appropriately rigorous independent scholarship be considered as a trustworthy source within your sphere?

Definitely. Academia doesn't have a monopoly on excellent technology and society research. The Markup's data-driven investigative journalism, for example, is outstanding.

1. Do you expect the opt-in nature of these studies to impact their findings?

The Rally participant population is not representative of the U.S. population—these are users who run Firefox (other browsers coming soon), choose to join Rally, and choose to join a study. In research jargon, there's significant sampling bias.

For some studies, that's OK, because the research doesn't depend on a representative sample. For other studies, researchers can approximate U.S. population demographics. When a user joins Rally, they can optionally provide demographic information. Researchers can then use the demographics with reweighting, matching, subsampling, and similar methods to approximate a representative population. Those methods already appear throughout social science; whether they're sufficient also depends on the study.

2. To compensate for the voluntary nature of the studies, do you think researchers in general will still be incentivized to find data sources that are less respectful of people's privacy and don't require an opt-in to the study?

Rally is designed to provide a new research capability that didn't exist before. I don't expect a substitution effect like that.

with the only privacy guarantees being that the data is encrypted during transport, and a "promise" that they will run internal audits to make sure private data isn't released from their servers.

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.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=101690...

Common research methods have significant limitations. Web crawls, for instance, usually don't realistically simulate user activity and experiences. Lab studies often involve simplified systems that don't generalize to the real world. Surveys yield self-reported data, which can be very unreliable.

Rally studies, by contrast, reflect real-world user activity and experiences. In science jargon, Rally enables field studies and intervention experiments with excellent ecological validity.

This is a luxury many researchers that work outside of these big tech companies don't have, which creates a scientific power imbalance.

The power imbalance goes far beyond science. Independent research is foundational for platform accountability. An example: when I was working on the Senate staff, before I started teaching at Princeton, a recurring challenge was the lack of rigorous independent research on platform problems. We were mostly compelled to rely on anecdotes, which made oversight and building a factual record for legislation difficult.

Presumably, the users will be well-endowed and tax-advantaged institutions who could have just bought the information from data-aggregators anyway.

Nope. This is an important point: the type of crowdsourced science that Rally enables is something that researchers couldn't do before. (With the exception of a very small number of teams who made massive investments in building single-purpose crowdsourcing infrastructure from the ground up.)

Princeton research collaborator here. Glad to answer questions about Rally.

What "data"? Browsing history? Identity? Something else?

That depends on the Rally study, since research questions differ and studies are required to practice data minimization. Each study is opt in, with both short-form and long-form explanations. Academic studies also involve IRB-approved informed consent. Take a look at our launch study for an example [1].

Why? What's in it for them? Since when was giving our data to third parties a good idea? There is literally no motivation presented here.

The motivation is enabling crowdsourced scientific research that benefits society. Think Apple Research [2], NYU Ad Observatory [3], or The Markup's Citizen Browser [4]. There are many research questions at the intersection of technology and society where conventional methods like web crawls, surveys, and social media feeds aren't sufficient. That's especially true for platform accountability research; the major platforms have generally refused to facilitate independent research that might identify problems, and platform problems often involve targeting and personalization that other methods can't meaningfully examine.

[1] https://rally.mozilla.org/current-studies/political-and-covi... [2] https://www.apple.com/ios/research-app/ [3] https://adobservatory.org/ [4] https://themarkup.org/citizen-browser

Princeton University Center for Information Technology Policy | Princeton, NJ | Full Time

Princeton CITP is a leading research center at the intersection of technology and public policy. We've conducted groundbreaking work on consumer privacy, government surveillance, net neutrality, algorithmic fairness, and other high-profile topics.

We're hiring two new team members, who will collaborate with our world-class faculty, fellows, and students on interdisciplinary research projects and policy impact. If you live in New York City or New Jersey, are passionate about technology policy, and have an impressive resume in data science (broadly conceived), we want to hear from you.

https://puwebp.princeton.edu/AcadHire/apply/application.xhtm...

My experience was that the major carriers had little economic incentive to invest in improving telephone service, which they viewed as a legacy line of business. They were focused on selling data plans, building their networks, and entering new markets (especially online services and advertising).

I worked on countering phone scams and robocalls at the Federal Communications Commission for over a year. This operation was a big win and an impressive international collaboration.

That said, the robocall problem is getting worse, not better. Robocall volume is at an all-time high: https://robocallindex.com/

In many respects, the problem of telephone spam today is similar to the problem of email spam in the early 2000s. Litigating against spammers had limited efficacy, so the community developed blacklists, better filtering, and stronger authentication (SPF, DKIM, and DMARC).

Until the major carriers get serious about similar steps, especially filtering and authentication (i.e. SHAKEN and STIR), these fraudulent calls won't stop. And, in the interim, vulnerable populations will continue to be disproportionately victimized.

(Background: I'm a computer security lawyer at Stanford. This ain't legal advice.)

This is a misunderstanding. The FCC has not tried to ban Wi-Fi device modding. What it might be requiring is locked-down radios. And only radios.

The phrasing of the recent guidance is unfortunately ambiguous, and calls out DD-WRT by name. But the original rules are clear [1], and staff guidance cannot trump Commission rules.

What's more, an attempt to ban third-party software would be inconsistent with the FCC's previous policy. The agency fined Verizon, for instance, when it tried to block third-party tethering apps [2].

[1] https://apps.fcc.gov/edocs_public/attachmatch/FCC-14-30A1.pd...

  The software must prevent the user from operating the transmitter
  with operating frequencies, output power, modulation types or
  other radio frequency parameters outside those that were approved
  for the device.

(Background: I'm a computer security researcher and lawyer at Stanford.)

When a security researcher gets threatened, there's a tendency to lambast the lawyers. I think that's unfortunate.

It is, very often, the client that demands an aggressive response. A lawyer should counsel against, since nastygrams to researchers tend to summon negative attention. Not being a jerk is also a plus.

That said, if a client insists--and they often do--the lawyers have little choice. Professional ethics generally require following the client's direction, and there isn't sufficient time to withdraw as counsel.

So, for the most part: Don't blame the lawyers, blame the DMCA. It's the law that's broken.

Background: I was quoted in the Wired piece. I made sure to emphasize that us outsiders can't say, with any certainty, whether this server was more or less secure than the State Department infrastructure. Matt Blaze, faculty at Penn, made the same point. But, alas, non-expert sensational spin won the day.[1]

With that out of the way, I suspect some HN readers might have an interest in the attribution process.

1) Find the mail servers for clintonemail.com, using DNS MX records. These days, they're run through McAfee. Back in 2010, though, the records pointed to mail.clintonemail.com. (There are a handful of services that keep those historical records, e.g. dnshistory.org.)

2) Find the IP address for mail.clintonemail.com, using DNS A records. Today, it's 64.94.172.146.[2] Back in 2010, it was 24.187.234.187.

3) Run an ARIN WHOIS on the old IP address. It's a static IP range through Optimum Online, allocated to "Eric Hoteham" at the Clinton home in Chappaqua. The surrounding IP ranges map to small businesses in the area.[3]

So, there is some nontrivial technical evidence that the email server was at the Clinton residence. But it's hardly definitive. It's possible, for instance, that the registered address is merely for billing purposes.

[1] There's even a glaring a factual error in the story. It was a web hosting service offered by Network Solutions that was hacked in 2010, not their DNS service. That would've been a much bigger deal.

[2] There's still a live server at mail.clintonemail.com. It's running Windows Server 2008 R2 with a valid SSL certificate. And it appears to be colo'd at Internap. Between that and the MXLogic protection, hardly a slapdash setup.

[3] Quite a few of these records have odd contractions or typos, suggesting the misspelled name wasn't intentional.