<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>37</author><text>&amp;gt;It makes no difference at that point what is shown in the address bar&lt;p&gt;This is ridiculous. Of course it makes a difference. The address bar is how basically 100% of users know what site they are on.</text><parent_chain><item><author>nybble41</author><text>That was Mozilla&amp;#x27;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&amp;#x27;t modify it. But IMHO resisting Signed Exchange doesn&amp;#x27;t help here at all, since you gave up that data to Google when you followed the link (which is &lt;i&gt;not&lt;/i&gt; 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&amp;#x27;t have to trust the cache, it implies that Google&amp;#x27;s cache could be replaced with a different (but still not fully trusted) server behind the scenes without changing the result.</text></item><item><author>jabbany</author><text>Google modifying the content is not really the threat model most people care that much about though (similar concerns exist with other caches&amp;#x2F;cdns)...&lt;p&gt;Google redirecting traffic to servers they control to mine interaction and interest data on the other hand...</text></item><item><author>nybble41</author><text>The original version where the content was served from Google&amp;#x27;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&amp;#x27;s servers to only cache the content and not modify it.&lt;p&gt;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&amp;#x27;s not the important part. It&amp;#x27;s been verified to have originated from the server shown in the address bar.</text></item><item><author>37</author><text>This seems insane and malicious as hell and I can&amp;#x27;t believe it&amp;#x27;s being sold as a feature. It&amp;#x27;s essentially just lying to users about which website they are currently visiting, or maybe I&amp;#x27;m missing something.</text></item><item><author>tentacleuno</author><text>&amp;gt; Second, AMP is bad for security. By design, AMP confuses users about what site they’re interacting with. Users think they’re interacting with the publisher, when in actuality the user is still within Google’s control. User-respecting browsers defend the site as the security and privacy boundary on the web, and systems like AMP intentionally confuse this boundary.&lt;p&gt;They&amp;#x27;ve actually been pushing to confuse that boundary even more since 2019, with their Signed Exchanges specification[0][1]. In essence, when you (unintentionally) visit an AMP page from Google Search, the URL typically starts with google.com&amp;#x2F;amp&amp;#x2F;websiteyouwantedtogoto.com. Signed Exchanges is essentially a way to drop the &amp;quot;google.com&amp;#x2F;amp&amp;#x2F;&amp;quot; bit, as demonstrated by one of the animations on [0].&lt;p&gt;Even Cloudflare supported this and rolled it out on their free tier[2].&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;developers.google.com&amp;#x2F;search&amp;#x2F;blog&amp;#x2F;2019&amp;#x2F;04&amp;#x2F;instant-loading-amp-pages-from-your-own&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;developers.google.com&amp;#x2F;search&amp;#x2F;blog&amp;#x2F;2019&amp;#x2F;04&amp;#x2F;instant-lo...&lt;/a&gt;&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.theverge.com&amp;#x2F;2019&amp;#x2F;4&amp;#x2F;16&amp;#x2F;18402628&amp;#x2F;google-amp-url-problem-signed-exchange-original-chrome-cloudflare&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.theverge.com&amp;#x2F;2019&amp;#x2F;4&amp;#x2F;16&amp;#x2F;18402628&amp;#x2F;google-amp-url-p...&lt;/a&gt;&lt;p&gt;[2]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;announcing-amp-real-url&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;announcing-amp-real-url&amp;#x2F;&lt;/a&gt;</text></item></parent_chain></comment><story><title>De-AMP: Cutting out Google and enhancing privacy</title><url>https://brave.com/privacy-updates/18-de-amp/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>jabbany</author><text>&amp;gt; It makes no difference at that point what is shown in the address bar, as the page has already been served.&lt;p&gt;If this were truly the case (that it didn&amp;#x27;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&amp;#x27;d want the address bar to show a different domain (i.e. the &amp;quot;author&amp;quot; rather than &amp;quot;publisher&amp;quot;) is exactly because it _does matter_ to the user!</text><parent_chain><item><author>nybble41</author><text>That was Mozilla&amp;#x27;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&amp;#x27;t modify it. But IMHO resisting Signed Exchange doesn&amp;#x27;t help here at all, since you gave up that data to Google when you followed the link (which is &lt;i&gt;not&lt;/i&gt; 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&amp;#x27;t have to trust the cache, it implies that Google&amp;#x27;s cache could be replaced with a different (but still not fully trusted) server behind the scenes without changing the result.</text></item><item><author>jabbany</author><text>Google modifying the content is not really the threat model most people care that much about though (similar concerns exist with other caches&amp;#x2F;cdns)...&lt;p&gt;Google redirecting traffic to servers they control to mine interaction and interest data on the other hand...</text></item><item><author>nybble41</author><text>The original version where the content was served from Google&amp;#x27;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&amp;#x27;s servers to only cache the content and not modify it.&lt;p&gt;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&amp;#x27;s not the important part. It&amp;#x27;s been verified to have originated from the server shown in the address bar.</text></item><item><author>37</author><text>This seems insane and malicious as hell and I can&amp;#x27;t believe it&amp;#x27;s being sold as a feature. It&amp;#x27;s essentially just lying to users about which website they are currently visiting, or maybe I&amp;#x27;m missing something.</text></item><item><author>tentacleuno</author><text>&amp;gt; Second, AMP is bad for security. By design, AMP confuses users about what site they’re interacting with. Users think they’re interacting with the publisher, when in actuality the user is still within Google’s control. User-respecting browsers defend the site as the security and privacy boundary on the web, and systems like AMP intentionally confuse this boundary.&lt;p&gt;They&amp;#x27;ve actually been pushing to confuse that boundary even more since 2019, with their Signed Exchanges specification[0][1]. In essence, when you (unintentionally) visit an AMP page from Google Search, the URL typically starts with google.com&amp;#x2F;amp&amp;#x2F;websiteyouwantedtogoto.com. Signed Exchanges is essentially a way to drop the &amp;quot;google.com&amp;#x2F;amp&amp;#x2F;&amp;quot; bit, as demonstrated by one of the animations on [0].&lt;p&gt;Even Cloudflare supported this and rolled it out on their free tier[2].&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;developers.google.com&amp;#x2F;search&amp;#x2F;blog&amp;#x2F;2019&amp;#x2F;04&amp;#x2F;instant-loading-amp-pages-from-your-own&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;developers.google.com&amp;#x2F;search&amp;#x2F;blog&amp;#x2F;2019&amp;#x2F;04&amp;#x2F;instant-lo...&lt;/a&gt;&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.theverge.com&amp;#x2F;2019&amp;#x2F;4&amp;#x2F;16&amp;#x2F;18402628&amp;#x2F;google-amp-url-problem-signed-exchange-original-chrome-cloudflare&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.theverge.com&amp;#x2F;2019&amp;#x2F;4&amp;#x2F;16&amp;#x2F;18402628&amp;#x2F;google-amp-url-p...&lt;/a&gt;&lt;p&gt;[2]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;announcing-amp-real-url&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.cloudflare.com&amp;#x2F;announcing-amp-real-url&amp;#x2F;&lt;/a&gt;</text></item></parent_chain></comment><story><title>De-AMP: Cutting out Google and enhancing privacy</title><url>https://brave.com/privacy-updates/18-de-amp/</url></story>