-- Leo's gemini proxy
-- Connecting to circadian.gemlog.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
Continuing the topic: how much privacy can we expect on Gemini, and could capsules ever track users and serve ads?
Rob wrote:
> [S]ervers can choose to share user certificates with each other, or with a user “directory” service that stores cert data and builds profiles based on servers that request information about that data. [...] Only the good will of capsule operators holds back the surveillance machine infecting the modern Web.
Fortunately, things are not as bad as that! The reasons are a little subtle; the details about how online ads work are complex and important, which is why I wrote this post:
The part of that post that is relevant here is that there are four parties to an online ad being served: the user, the content provider, the advertiser and the ad infra owner.
The critical thing about this setup is who trusts whom, and for that, we have to look at the flow of money.
Money flows from the advertiser to the ad infra owner to the content provider.
That means mistrust flows the same way: the advertiser does not trust the ad infra owner to deliver ads that work. That has to be proved through reputation and data.
And the ad infra owner does not trust the content provider. Because the ad infra owner must deal with many content providers, this can’t be solved by reputation; it has to be solved by technical means.
For Gemini, that means: capsules are not trusted by ad servers.
This can be demonstrated by a simple example.
One of the “big money” identities in online advertising is a person who is actively looking for a mortgage. If a capsule can figure out via tracking that some particular user is in the market for a mortgage—wow. Just one click from such a person can be worth ten dollars. The reason is obvious—the eventual deal is worth many thousands to the bank that closes it. So the bank is perfectly happy to pay ten dollars, or more, for a promising lead.
Suppose I put ads on my capsule. Then, my capsule server talks to the ad server to get an ad to show to the user. It has to—there are no third party requests in Gemini, so this is the only way to include an ad in the page. My server sends a request to the ad server: “I have a user who’s trying to buy a mortgage, do you have a suitable ad?"
Does the ad server send me an ad for mortgages, and ten dollars for any click that results? Nuh-uh. Certainly not. I’m the one who gets the money—so my capsule server can’t be trusted, at all, to make claims about its users.
The same goes for passing on user IP addresses, client certificate sha1s, or even non-identifying data like number of page views.
Capsule servers simply cannot be trusted by ad servers to honestly pass on data about their users. The capsule server can trivially get more money by lying. And it’s not just the ad infra owner who needs to be convinced—the advertiser is the one who ultimately has to be convinced that the right user saw their ad. The capsule server cannot pass anything to the ad infra owner that will help to convince.
There is no business model here, because there is no way to establish trust that would support money changing hands. Capsule servers cannot do tracking on behalf of ad servers.
Online advertising on the web works because the user’s browser is instructed to talk directly to the ad server, bypassing the content provider. It sends cookies, identifying itself—even across sites. This means the ad server gets the information it needs directly, with no opportunity for the content provider to cheat. Gemini does not support this mechanism at all.
In the discussion around identity that I started, there is an interesting point:
> Skyjake [...] raised a second concern I hadn’t thought of: servers can forge information such as hashes or randomart.
Yes! This is very interesting. Gemini capsule servers can’t prove who their users are.
And this is what turns out to break Gemini for online ads. Because the capsule can’t prove anything about its users, it can’t pass on anything that the ad server can trust.
Suppose that the Gemini protocol was extended so that a Gemini server can ask the client to sign something; it can say, “Please sign this text with your private key." Then, this would solve the Gemini-wide identity question that I raised in a fully secure, end to end encrypted, way: capsules could published signed statements from their users, positively identifying them in a way that cannot be forged. Unfortunately, it would also “solve” the ad server problem: Gemini capsules could pass on the client certificate identities of their users in a way that could not be forged. This, we obviously do not want.
I’ve said already that I think that trusting Gemini capsules is the right think to do. Tying the concept of identity back to the question of tracking for online ads, I’m now more convinced. By asking users to “just trust” capsule servers, we make it impossible for capsule servers to work with ad servers.
Users are able to interact with capsule servers based on reputation and trust; and I would argue that this is a necessary part of using a capsule server anyway. It’s okay for users to trust capsules to not lie about the identities of their users. Skyjake called this a “gentlemen’s agreement”, and I think that is appropriate for the relationship between users and capsules.
But ad servers can’t trust capsule servers in this way, nor could any business with anything critical on the line.
I believe that this is exactly the right amount of uncertainty.
We’re not completely done with the possibility of ads, or the possibility of tracking.
For example: an ad server can return a link with an ad that, if clicked, causes the user to hit the ad server before they are redirected to the eventual target. This gives the ad server an opportunity to log a trusted click action and user information. But, it doesn’t work very well: for example, because it’s a different server, client certificates don’t naturally connect with any other certificate use.
Another trick would be to have the capsule server simply forward packets to the ad server, without terminating the TLS connection. The ad server would then serve the capsule—and ping the capsule server for any dynamic content. Effectively, this would move all Gemini hosting onto ad servers. This is such a big change that I think it’s equivalent to inventing a new protocol from scratch—and if you did that with advertising in mind, you wouldn’t build it like Gemini at all.
A third trick that I hadn’t thought of was suggested by Rob in an older post:
> We must assume that companies and monied interests would create their own Gemini browsers [...]
But this, I think, is a non-starter—it could never happen.
Exactly why not is a post I will leave for another day, because it’s an entirely different look at the same problem.
From a technical point of view, Gemini is very well guarded against tracking for ads. The mechanisms that work on the web don’t work at all, nor do the most obvious workarounds. Some possibilities do remain. Fortunately, there are also non-technical reasons that I think make ads for Gemini a non-issue. I’ll post about those another day.
Rob was not talking about ads, though, he was talking about the more general issue of privacy.
Here, I think the situation is this:
There are known things that will happen on capsules, such as their posting what you write in a way that is associated with you; you can understand these, and choose whether they are okay for you in terms of privacy.
And there are unknown things that can happen, such as capsules sharing your IP address or client certificate behind the scenes. Here you must simply trust—as is the case with any other information you send out into the Internet. I think awareness of the issues, the reputation of capsule owners, and the judgment of the community is a sufficient mechanism here. It’s worth noting, though, that these are not the only mechanisms: in some parts of the world, laws like the GDPR make it actually illegal (by my non-lawyer understanding!) for servers to behave in this way without your express permission.
I’d say the situation for Gemini here looks pretty good—everything works today exactly as it should, and I don’t see any problems on the horizon.
I think I may have commented on some thread or other that it would be nice if Gemini supported a way to extend cryptographically-guaranteed identity beyond the user to capsule TLS link; I’m going to take this back, I now think it would give too much information to those hypothetical ad servers without enough benefit to users.
Thanks to Rob and to everyone else who has commented in this discussion! I hope this post was likewise interesting reading for you.
So far today, 2024-05-13, feedback has been received 2 times. Of these, 0 were likely from bots, and 2 might have been from real people. Thank you, maybe-real people!
———
/ \ i a
| C a \ D n |
irc \ /
———
-- Response ended
-- Page fetched on Mon May 13 14:09:11 2024