5 ms·

The original version where the content was served from Google's cache without any cryptographic verification but displayed as if it came from the original site

The original version where the content was served from Google's cache without any cryptographic verification but displayed as if it came from the original site was… misguided at best. It meant that you were trusting Google's servers to only cache the content and not modify it. 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.

jabbany 4y ago
Google modifying the content is not really the threat model most people care that much about though (similar concerns exist with other caches/cdns)... Google redirecting traffic to servers they control to mine interaction and interest data on the other hand...
- nybble41 4y ago
  That was Mozilla's objection to the Signed Exchange standard: you lose some privacy because the cache server can see the page data in the clear, even if they can't modify it. But IMHO resisting Signed Exchange doesn't help here at all, since you gave up that data to Google when you followed the link (which is not obfuscated). It makes no difference at that point what is shown in the address bar, as the page has already been served. Also, since Signed Exchange means you don't have to trust the cache, it implies that Google's cache could be replaced with a different (but still not fully trusted) server behind the scenes without changing the result.
  - thomasahle 4y ago
    > you gave up that data to Google when you followed the link 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?
    - nybble41 4y ago
      > 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? 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.
  - jabbany 4y ago
    > It makes no difference at that point what is shown in the address bar, as the page has already been served. 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!
    - nybble41 4y ago
      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.
  - 37 4y ago
    >It makes no difference at that point what is shown in the address bar This is ridiculous. Of course it makes a difference. The address bar is how basically 100% of users know what site they are on.
    - dmw_ng 4y ago
      This hasn't been true since the first third-party JS script was published. In reality a giant proportion of web users today are 'on Google' or 'on CloudFlare' or 'on CloudFront' even if they aren't aware of it. The address bar has been broken in this regard for at least a decade
      - magicalist 4y ago
        It's not even just the address bar. It's how DNS works.
    - nybble41 4y ago
      It makes no difference for privacy in that you already told Google which page you were going to by following the link. If they implemented AMP as a more traditional redirect instead of a cache then they would get the same information and you would still see the non-Google site in the address bar at the end.
    - magicalist 4y ago
      I feel like this conversation comes up in every signed exchange thread, and it's also always pointed out that this is how CNAME records and CDNs already work, except now the response is signed by the author.
    - notatoad 4y ago
      you drastically overestimate how many users understand the address bar. i'd say probably 50% of users couldn't tell you the difference between the address bar and the google search box.
      - gleenn 4y ago
  - taneq 4y ago
    It's interesting to see Mozilla's public stance on privacy and their responses to this kind of thing, and at the same time see which settings in Firefox get mysteriously reset to default each update. The latest update re-checked "search engines" in the address bar suggestions settings. You know, the one option that sends everything you type into the address bar to the default search engine? I wonder how much they were paid to re-enable that one.
  - autoexec 4y ago
    > But IMHO resisting Signed Exchange doesn't help here at all, since you gave up that data to Google when you followed the link (which is not obfuscated 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.
    - nybble41 4y ago
      > 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. 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.
- autoexec 4y ago
  > Google modifying the content is not really the threat model most people care that much about 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.

jabbany 4y ago

Google modifying the content is not really the threat model most people care that much about though (similar concerns exist with other caches/cdns)... Google redirecting traffic to servers they control to mine interaction and interest data on the other hand...

nybble41 4y ago
That was Mozilla's objection to the Signed Exchange standard: you lose some privacy because the cache server can see the page data in the clear, even if they can't modify it. But IMHO resisting Signed Exchange doesn't help here at all, since you gave up that data to Google when you followed the link (which is not obfuscated). It makes no difference at that point what is shown in the address bar, as the page has already been served. Also, since Signed Exchange means you don't have to trust the cache, it implies that Google's cache could be replaced with a different (but still not fully trusted) server behind the scenes without changing the result.
- thomasahle 4y ago
  > you gave up that data to Google when you followed the link 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?
  - nybble41 4y ago
    > 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? 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.
- jabbany 4y ago
  > It makes no difference at that point what is shown in the address bar, as the page has already been served. 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!
  - nybble41 4y ago
    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.
- 37 4y ago
  >It makes no difference at that point what is shown in the address bar This is ridiculous. Of course it makes a difference. The address bar is how basically 100% of users know what site they are on.
  - dmw_ng 4y ago
    This hasn't been true since the first third-party JS script was published. In reality a giant proportion of web users today are 'on Google' or 'on CloudFlare' or 'on CloudFront' even if they aren't aware of it. The address bar has been broken in this regard for at least a decade
    - magicalist 4y ago
      It's not even just the address bar. It's how DNS works.
  - nybble41 4y ago
    It makes no difference for privacy in that you already told Google which page you were going to by following the link. If they implemented AMP as a more traditional redirect instead of a cache then they would get the same information and you would still see the non-Google site in the address bar at the end.
  - magicalist 4y ago
    I feel like this conversation comes up in every signed exchange thread, and it's also always pointed out that this is how CNAME records and CDNs already work, except now the response is signed by the author.
  - notatoad 4y ago
    you drastically overestimate how many users understand the address bar. i'd say probably 50% of users couldn't tell you the difference between the address bar and the google search box.
    - gleenn 4y ago
- taneq 4y ago
  It's interesting to see Mozilla's public stance on privacy and their responses to this kind of thing, and at the same time see which settings in Firefox get mysteriously reset to default each update. The latest update re-checked "search engines" in the address bar suggestions settings. You know, the one option that sends everything you type into the address bar to the default search engine? I wonder how much they were paid to re-enable that one.
- autoexec 4y ago
  > But IMHO resisting Signed Exchange doesn't help here at all, since you gave up that data to Google when you followed the link (which is not obfuscated 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.
  - nybble41 4y ago
    > 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. 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.
autoexec 4y ago
> Google modifying the content is not really the threat model most people care that much about 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.