This seems insane and malicious as hell and I can't believe it's being sold as a feature. It's essentially just lying to users about which website they are currently visiting, or maybe I'm missing something.
The new system adds verification that the content is exactly what was intended by the original site, despite being served through a cache, so the user agent is no longer lying about which website the user is visiting. Sure, the data was fetched from Google, but that's not the important part. It's been verified to have originated from the server shown in the address bar.
Google redirecting traffic to servers they control to mine interaction and interest data on the other hand...
This is ridiculous. Of course it makes a difference. The address bar is how basically 100% of users know what site they are on.
i'd say probably 50% of users couldn't tell you the difference between the address bar and the google search box.
If this were truly the case (that it didn't matter), the argument can be made that there is no reason to change the host -- just show it as google.com like it does now. The only reason that you'd want the address bar to show a different domain (i.e. the "author" rather than "publisher") is exactly because it _does matter_ to the user!
Given Signed Exchanges are entirely opt-in by the publisher/website operator, what's the difference between this and a CDN? Isn't that "lying" about what site you're on? It's not theverge.com - it's Cloudflare!
> There has been discussion of allowing a publisher to restrict the set of distributors that can host its signed content. If that's added, then the privacy situation becomes more similar to the situation with CDNs, where a publisher chooses a CDN to serve their content, and the CDN learns about all requests for that content. Here the publisher would choose one or more distributors, and the distributor(s) would learn about requests for the content.
Basically a signed exchange .sxg as it is right now allows anyone to be a distributor. It authenticates only that the content has not changed, but not who is distributing it was allowed to distribute it.
Imagine I use SXG to sign "myBlog.com/some-post/" as "some-post.sxg" and serve it via "myCdn.com/myBlog.com/some-post.sxg" on "myBlog.com/index", like I would with a CDN. EvilSearchEngine (now being both the source that sends a results page and a distributor CDN) can crawl this index, nab the .sxg and then when it serves results, serve it via "EvilSearchEngineCDN.com/myBlog.com/some-post.sxg" instead. The client browser checks the sxg, finding it is validly signed and thus shows it as "myBlog.com/some-post/".
However, (1) the EvilSearchEngine has now gained tracking data on visits to "myBlog.com/some-post/" (which it may or may not already have), but more importantly (2) I've now lost the ability to do first-party tracking of visits to "myBlog.com/some-post/" since EvilSearchEngine users never hit my server and I must now beg EvilSearchEngine to give me their tracking data for my content.
Maybe they'll introduce "allowing a publisher to restrict the set of distributors", maybe they won't. But until they do, it behaves nothing like a real CDN.
See, this is one of the good things about the SE proposal. The source page already has all the tracking data; that's a given. But if the content is served via SE it reduces the number of other sites that get tracking data, which is very much a win for privacy.
> Maybe they'll introduce "allowing a publisher to restrict the set of distributors", maybe they won't.
It would make no sense for user agents to enforce such a restriction, since a valid signature shows that the content is authentic regardless of the identity of the distributor.
This is a lie. The source page does not have any access to referral data. Without things like JS supporting it, it does not and cannot know that a user has clicked on any of its links.
> if the content is served via SE it reduces the number of other sites that get tracking data
This is also a lie. It does not _reduce_ the number of sites that gets tracking data. Rather it takes the ability to control who gets to track away from a publisher (who you'd reasonably expect to be able to track your visits to _their own site!_ ), and puts it into the hands of an aggregator (like Google, who you would _not_ expect to be able to track views on third party content).
In this sense it is exactly like AMP, it is a shift of who holds power over data. Users do not gain anything (privacy could be argued to be no worse, but it is certainly no better than before) but publishers have everything to lose.
AMP was never a battle between users (readers) and Google. It was a battle between _content publishers_ and Google. Nothing has changed when it comes to SE. It's the same old formula just in a new bottle.
Unless SE ultimately allows specification of a list of allowed distributors as part of the bundle, framing SE as "just like using a CDN" and that "Google/aggregating site doesn't benefit more from this" is at best a bit ignorant about the power struggles between publishers and aggregators.
The source page determines the target of the link and can add whatever tracking data they want to it. You can see from the link target that it's going back to the same site. That is all they need to get the referral data.
> It does not _reduce_ the number of sites that gets tracking data.
It does, as the source page has the tracking data either way but the publisher's page does not if SE is used.
Frankly I'd rather trust Google with that data—they have access to it anyway, through several different channels—than a bunch of publishers I have no other relationship with.
> Unless SE ultimately allows specification of a list of allowed distributors as part of the bundle, …
It won't matter if the bundle contains a list of "allowed distributors" if user agents don't enforce that restriction. And why would they? They know the content is correct regardless of where it came from due to the signature. Refusing the data won't improve privacy at all, as the server already knows that the link was followed. The only one seeing any benefit here is the publisher, who would get tracking data at the expense of the user's privacy. The user agent doesn't represent the publisher, it represents the user.
There is only a single way that the source[+] can guarantee[*] knowledge of a click through: Linking to their own domain with a unique identifying tag[**] and subsequently redirecting to the real target.
Without SE, this kind of tracking behavior is readily apparent to the user:
- The link goes to the source's own site [***] - The link contains elements of entropy relevant to tracking - The browser must briefly flash the source's domain being loaded before the redirect comes in. An obvious behavioral difference.
With SE, however, this behavior is no longer apparent:
- The link can visibly go to the publisher directly yet still actually hit the distributor (likely just also the source) even with scripts and referers disabled. Unless browsers offer a way to disable SE specifically, there is no way to prevent it. - The browser has no observable behavior differences from a site not using SE. The only way to distinguish a site using SE (besides the browser making this explicitly visible in the UI) is by capturing connections at a layer below the browser (i.e. sniffing packets at the OS or upstream network level) .
Like with most tech, it is certainly possible to implement SE in a privacy preserving way on the client side, but it also seems to be solving a problem that only the likes of Google will care about.
[+] I'm going to use the terminology in the proposal where: - source = the thing hosting the link (i.e. Google) - publisher = the thing producing the content (i.e. YourBlog.com) that is linked to - distributor = the thing re-distributing a copy of the content (i.e. also Google) in lieu of the publisher
[*] While other methods like JavaScript and 'Referer's may also leak this information, they depend on a cooperative client voluntarily disclosing such info. It is quite trivial for a privacy conscious client to disable both sources of leaking click through information.
[**] This must also be part of the URL, as using cookies or the such can be foiled by loading the link in a clean/fresh alternative sandbox environment (no identifiable info), and then sending back the address it resolved to. A lot of URL "un-shorteners" do this already.
[***] This can be hidden by JavaScript (and Google has done exactly that right now by replacing href= URLs on click), but again, a privacy conscious user would have disabled such a script.
I really think you overestimate how likely users are to notice a redirect URL appearing in the address bar for a fraction of a second. Regardless, even with SE the distributor's URL will appear for a short time until the content has been downloaded and the signature can be validated, just as it would with a redirect. Anyone who actually cares to see which connections are made (which covers much more than what you can infer from the address bar alone) can open up the browser's developer tools and inspect the network traffic. Or you can fire up Wireshark if you're paranoid, but there is nothing in the proposals about hiding the true endpoints of the connections from the developer tools—just main URL shown in the address bar.
If you want to avoid giving the data to Google in the first place there is no substitute for checking the URL before clicking on the link, which will show the distributor's domain regardless of SE.
Anecdotally, it's how I learned how Google tracked click-throughs. I used to (when I was very young) live in a jurisdiction that had no Google datacenters. All requests to Google came with a 100ms+ latency hit. It was painfully apparent the day they started doing the redirects (I even wrote an extension to undo that redirect-- not for privacy reasons, but just because it was _that annoying_.)
As for the rest of the argument, again, I'm not claiming the design of SE itself is somehow broken or even that most users would gain privacy/be tracked less if we didn't have SE. Rather the argument is similar to that against AMP or FLoC, it solves a problem that only Google (and similar) has, not one that users have. SE does not benefit publishers (it actually hurts them), it does not benefit users, it only benefits the middle-man. That is reason enough to not care about supporting it.
Google would know that you clicked on the link, and the URL you visited but that doesn't necessarily mean they know what the content on the page you requested was. In practice, most of the time it would, but since a site could serve very different pages to different users it wouldn't always be the case.
> It makes no difference at that point what is shown in the address bar, as the page has already been served.
Some things should be kept sacred to protect users and the address bar is one of those things. It should always display where content is coming from. browsers have been degrading the address bar for ages (turning it into a search box/advertising platform, or hiding parts of the URL from the user) but this really is a step too far.
At this point we really need a separate browser feature that shows us what server we're actually communicating with (host, cache, CDN, etc). The address bar itself is pretty much useless now.
SE is only supposed to be used for public pages ("Cache-Control: public") which will be the same for every user. If they have the URL they can just request the page themselves to see the content.
> It should always display where content is coming from.
And with SE it does show where the content came from. Not the cache, which is irrelevant, but the original source. Or do you want it to show all the routers and CDN platforms which were involved in getting the data from the publisher's server to your PC?
> At this point we really need a separate browser feature that shows us what server we're actually communicating with (host, cache, CDN, etc).
We have that; it's called developer tools. As there can be many resources from many different sources making up a single page the results are too complex to reduce to a single line in the address bar, but they are available for those who are interested.
I gave up information on what site I was visiting, but if I enter any information on the page, won't that still go to Google? It's going to look like I have an https end-to-end channel with the site I'm visiting, but really Google is Man-In-The-Middleing the whole thing?
So far as I can tell the user agent uses the original (non-Google) URL for the purpose of same-origin tests when it's returned from Google's cache using the Signed Exchanges standard, so the risk is effectively the same as if the page were served from the original server and Google were not involved. The page could send anything you enter to Google, but it would need to be coded that way to begin with. It wouldn't do so just because it was served through their cache.
You're right that's not the concern held by the people accessing the content, but the target here seems to be the websites who partner with Google. If I publish something on the web and another company wants to host my content (including caches and CDNs) and I expect many of my readers will access my content without ever touching my servers directly, I would absolutely be concerned about my content being modified where it's outside of my control.
Seems it'd be a lot of trouble to track down and verify that it were happening at all since google could change content any number of ways or not at all depending on the individual making the request.
I am pretty skeptical, however, given the way Google will (ab)use this.