3 ms·

It makes no difference for privacy in that you already told Google which page you were going to by following the link. Naturally the address shown in the URL ba

It makes no difference for privacy in that you already told Google which page you were going to by following the link. Naturally the address shown in the URL bar matters to the user or we wouldn't be discussing this at all. With Signed Exchanges it can correctly reflect the origin of the content rather than being cluttered with irrelevant details about the cache server.

jabbany 4y ago
This is not true though? It is immensely different for privacy. 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.
- nybble41 4y ago
  > The browser must briefly flash the source's domain being loaded before the redirect comes in. 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.
  - jabbany 4y ago
    > 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. 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.

jabbany 4y ago

This is not true though? It is immensely different for privacy. 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.

nybble41 4y ago
> The browser must briefly flash the source's domain being loaded before the redirect comes in. 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.
- jabbany 4y ago
  > 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. 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.