| 01:44 | <Domenic> | devsnek: what do you mean by "deferred navigation"? |
| 01:45 | <devsnek> | Domenic: tell the UA you *might* navigate somewhere |
| 01:45 | <Domenic> | Who tells the UA that? |
| 01:45 | <devsnek> | the website |
| 01:45 | <devsnek> | like how amp preloads stuff |
| 01:45 | <devsnek> | it would let the UA preload the sites |
| 01:46 | <Domenic> | The problem with preloading in general is that the website then gets all your data |
| 01:46 | <devsnek> | well the browser is in a position to not run the js and etc |
| 01:46 | <Domenic> | Not running the JS isn't enough |
| 01:46 | <Domenic> | Simply making a HTTP request gives you a lot |
| 01:46 | <devsnek> | hmm |
| 01:46 | <devsnek> | maybe it just shouldn't exist then |
| 01:47 | <Domenic> | Thus, SXG |
| 01:47 | <devsnek> | cuz signed exchanges are kinda sketchy |
| 01:47 | <Domenic> | Can you explain what you mean? |
| 01:47 | <Domenic> | In particular, how they are more or less sketchy than CDNs? |
| 01:48 | <Domenic> | You may find https://developers.google.com/web/updates/2018/11/signed-exchanges helpful in how it explains both privacy-preserving prefetching and how SXGs are generally better than giving your signing keys to a CDN. |
| 01:48 | <devsnek> | they remove control from the origin and potentially bypass stuff like pi-hole |
| 01:49 | <devsnek> | I'd be very surprised if companies that serve amp don't take advantage of that |
| 01:49 | <Domenic> | Can you explain how they remove control from the origin? They do not bypass pi-hole as far as I know, assuming pi-hole looks at URLs. |
| 01:49 | <devsnek> | pi-hole blocks dns of advertisers and trackers and stuff |
| 01:49 | <Domenic> | My understanding is it also applied URL-based filtering. |
| 01:50 | <Domenic> | Otherwise it would be trivial to bypass by putting your ads on a different CDN. |
| 01:50 | <devsnek> | it can, but they always change URLs and stuff |
| 01:50 | <devsnek> | blocking IP ranges is more effective |
| 01:50 | <Domenic> | Well, there's nothing new in SXGs that makes that harder |
| 01:51 | <devsnek> | you'd have to block the person who serves the sxg |
| 01:51 | <Domenic> | Yes, similar to blocking the person that serves the ad. |
| 01:51 | <Domenic> | If your argument is that pi-hole is vulnerable to people locating ads on servers that people might not want to block, that applies regardless of SXG. |
| 01:52 | <Domenic> | But my understanding is pi-hole is not that dumb. |
| 01:52 | <devsnek> | I'm not saying it changes the game substantially |
| 01:52 | <devsnek> | its just another point |
| 01:52 | <Domenic> | I don't think it is. |
| 01:54 | <devsnek> | i also dislike that I'll still be on Google even though the URL bar might say something else |
| 01:54 | <Domenic> | Do you dislike it that currently the sites are on Cloudflare despite the URL bar saying something else? |
| 01:55 | <devsnek> | that's just using cloudflare as your host |
| 01:55 | <Domenic> | As your CDN |
| 01:55 | <devsnek> | yeah |
| 01:55 | <Domenic> | Alternate question, would you not-dislike it if people gave their private keys to Google, like they do to Cloudflare, in order to allow Google to sign their HTTPS certs and host their content like Cloudflare does? |
| 01:56 | <devsnek> | but with signed exchanges isn't Google still loaded on my client |
| 01:56 | <Domenic> | What do you mean by "Google still loaded". THe content you loaded is created entirely by the publisher. (And cryptographically signed to attest that.) |
| 01:57 | <Domenic> | The bytes physically come from Google (or wherever). But they are signed as created by the URL-bar URL. It's CDNs but using extra fancy crypto stuff instead of just giving the host/CDN your private key. |
| 01:58 | <Domenic> | I.e. with the current CDN setup you just give all control to your host/CDN, including the ability to sign HTTPS certs as example.com, so that the browser displays example.com in the address bar even though the content is ultimately from the CDN servers. |
| 01:58 | <devsnek> | isn't the site that loads a sxg still in control |
| 01:58 | <Domenic> | Nope |
| 01:58 | <devsnek> | hmm |
| 01:58 | <Domenic> | It would break the S part of SXG |
| 01:58 | <Domenic> | If you change the content |
| 01:59 | <devsnek> | I don't mean change the content |
| 01:59 | <Domenic> | What type of control are you thinking of, then? |
| 01:59 | <devsnek> | Google doesn't modify amp pages |
| 01:59 | <devsnek> | but it surrounds them in a frame |
| 01:59 | <devsnek> | that kind of thing |
| 01:59 | <Domenic> | SXG is a network protocol. It doesn't have some carvout where you can modify the content by surrounding it in an iframe. |
| 02:00 | <devsnek> | so if Google used signed exchanges they wouldn't be able to do that anymore |
| 02:00 | <Domenic> | I mean they can still load content in an iframe. (But, it will show the Google URL in the URL bar.) |
| 02:01 | <devsnek> | so they'd have to actually navigate away from google |
| 02:01 | <Domenic> | That's what they currently do with AMP |
| 02:01 | <Domenic> | Well, not really |
| 02:01 | <devsnek> | no, they wrap it in a frame |
| 02:01 | <Domenic> | They navigate to the publisher's content, hosted on Google |
| 02:01 | <devsnek> | and override input gestures |
| 02:01 | <devsnek> | it's horribly annoying |
| 02:01 | <Domenic> | I mean there might still be iframes |
| 02:01 | <devsnek> | but then it won't show the url |
| 02:02 | <Domenic> | The difference is that now we have a cryptographic guarantee that the content of the iframes is from the publisher, not just the promise that Google won't modify the contents of the iframes despite them being hosted on Google servers. |
| 02:03 | <devsnek> | so the thing I brought up before was trying to prevent Google's thing where navigating to a site is hijacked and I still remain on Google's property |
| 02:03 | <devsnek> | but now I understand that the interests are different |
| 02:03 | <Domenic> | Happy to help. |