Hacker News Reader

Comment by TechBro8615 | Hacker News Reader

How does anyone think this is a good idea? It should be clear which news site I am reading when I'm reading an article. Otherwise, how do I know which bias to apply? On iOS, the title bar says "google.com" whether I'm reading an article from CNN.com or WashingtonExaminer.com.

Of all the anti-competitive actions google has taken around search results, AMP is by far the worst. I hope they get smacked down for it in the upcoming anti-trust lawsuit. And kudos to Apple for refusing to change the URL bar like Google does on Android.

View on HN

I couldn't agree more that AMP is terrible. I do everything I can to avoid it. Using DuckDuckGo certainly helps, but I will still occasionally stumble on an AMP site. I've created a hosts block list to help me avoid AMP as much as possible. It currently has 3,569 unique domains (works great with a PiHole!). I'm really concerned about Chrome's 'signed exchanges' where they can fake the URL completely. I hope Firefox will never support it.

https://www.github.developerdan.com/hosts/

We don't need any other website except Google /fear

Google scraped and stole all the traffic for covid19 since 3 months just like it did for other topics

Just wanted to say thanks for maintaining your block lists! I use a few with NextDNS. I try to be privacy conscious but I don’t really have the technical background to know the best way to make that happen so I very much appreciate that you share your work and make it easy for those of us who aren’t experts. I’ve never been quite sure that I’ve configured things right but your NOT BLOCKING image doesn’t show up for me so that’s quite a relief!

I'm glad you like it! If you have any issues with it, I encourage people to come open a ticket explaining what is wrong. Sometimes I screw up and block things that shouldn't be - other times I have reasons why I blocked something and the ticket provides a good place to have a that discussion. Feedback from the community is great help to me in improving the lists.

> I'm really concerned about Chrome's 'signed exchanges' where they can fake the URL completely.

They're not faking the URL; a signed exchange contains data that can only have come from the original site. It's a secure way of handling caching/CDNs/etc, and it'll be a net improvement for security that allows sites to put less trust in third-party servers and scripts.

Its deeply misleading to pretend stuff like signed exchanges and portals are purely about content distribution and security, and not control over said content being shifted to Google, and away from authors and other sites.

Its a similar vein to how many of the objections to AMP were being white-washed with "its open source, if you have a problem with it why aren't you submitting a pull request??"

I'll bite: how does signed exchanges provide control to Google?

Because its cover to allow them to subsume content and serve it solely from google.com, and deny the originating page any traffic or recognition, or swap it out transparently when they feel like it.

This is literally already happening with the info sidebar, the reason signed exchanges matter is so they can throw up the smokescreen about how its cryptographically verified to come from the original page, so why are people upset.

Any site that objects and refuses to implement this stuff will just disappear from the first page which is reserved only for Accelerated By Google sites. (Which is already happening for AMP links on mobile searches).

As I understood signed exchanges, a correct implementation makes it impossible for the intermediary to inject, alter, replace, or otherwise swap out any part of the page without failing verification. This would mean the original server gets to do all the branding and get all the recognition and integrity in transit that its controllers might wish.

I've clearly missed something. Can you help me?

AMP already heavily restricts what the original page is allowed to put inside, including things like ads, javascript and branding. You can be certain anything google implements around this proposal will have similar very tight restrictions.

That's definitely a scary thought! Can you share any details of what must be public plans to strip everything non-Google of branding? Surely there must be something out there beyond the IETF docs for the protocol, where I don't see any evil plans to Googlify everything in. If anything, it looks like a design intended to allow relaxing the restrictions imposed by AMP.

Perhaps I need to read them more closely.

If you want an honest discussion try toning down the smarmy bullshit.

Yes, as you say, Integrity is preserved. However, Confidentiality is also another important aspect of Information Security. Making a 3rd party appear as a 1st party, is a privacy and confidentiality violation, which is why I do not like AMP and signed exchanges.

Yeah, as near as I can tell signed exchanges are essentially a caching proxy. With integrity checks, so that you don't have to trust the proxy all that much and its agency is much reduced. I'm reminded of apt.

The calculation appears to be that given the chance, some website controllers will choose to trade confidentiality of public pages for better load times. In business terms, this seems a pretty straightfoward win in many cases, so I can see why some would sign up.

The publishers are not mentioning to the visitor they are adding one more third party looking at your data; one that maintains an ad exchange and will be an intermediary on every resource request.

A publisher is free to switch to AMP, but choice needs to be given to the user to agree or leave the site the same way it happens with cookies. I wouldn’t opt in and now I cannot block Google tracking at the DNS level thanks to this.

Publishers can, and should, always make visitors aware of how many third parties are positioned to see all visitor data.

We are, unfortunately, a long way from this being normal. Even as third parties doing things like running CDNs or doing TLS termination for other reasons has been pretty thoroughly normalized. Though offering it as a Firefox extension could be an interesting exercise.

I think publishers view AMP as a question of their sovereignty and choice. Since it's their website that's being potentially served by Google, it's their choice to make. There's absolutely a lot of room to dispute if this is the morally correct stance, but I also think it's not wildly out of line with other questions publishers weigh in choosing what they serve and how.

> I wouldn’t opt in and now I cannot block Google tracking at the DNS level thanks to this.

How do signed exchanges break blocking Google tracking at the DNS level? You already need to have google.com unblocked in order to get a results page that serves an exchange from Google.

> swap it out transparently

> cryptographically verified to come from the original page

Elaborate.

The page results will be a tightly restricted iframe-esque window inside of google results (This is what the Chome "Portals" proposal is about).

There will be no obvious distinction between a search result and google's own website, even though the "portals" will be showing cryptographically signed content (which will almost certainly be in a super restricted AMP-esque format that denies sites much control besides what the text says)

If google swaps one result for another, 95% of users wont even notice.

> If google swaps one result for another, 95% of users wont even notice.

Right so exactly the same way the search results page works today?

> The page results will be a tightly restricted iframe-esque window inside of google results

This is completely independent of AMP. Portals work for non-AMP content too.

> which will almost certainly be in a super restricted AMP-esque format that denies sites much control besides what the text says

So you're suggesting that Google will create a new, even more restricted than AMP protocol to be viewed on the search page?

Isn't that what those meta tags are for so google can quickly show scores, reviews and stuff?

Does it behave different in different countries?

Will Google allow for example, Taiwan content in mainland China?

Is it like VPN/Proxy or has more knobs?

> Will Google allow for example, Taiwan content in mainland China?

Google doesn't run in mainland china, so this is a bit of a strange question. But let's assume that Google did. How would AMP or signed exchanges change the accessibility of Taiwan related content on Google in mainland china? Are you saying that the current Google results page would show Taiwan related content, but signed exchanges wouldn't, or what?

> Is it like VPN/Proxy or has more knobs?

Neither. It's literally a way to say "a site had this html, css, and js, and cryptographically signed the blob so that we can re-host it and you can be certain that the person re-hosting hasn't modified it in any way."

> Are you saying that the current Google results page would show Taiwan related content, but signed exchanges wouldn't, or what?

My question is will signed exchanges serve content but where google search results are censored.

Google can choose today which site (original or AMP cache) to show in their search results. Today, as an end user, I know, via the URL, when I land on a Google AMP site.

That said, Google already has control of every AMP page because the spec REQUIRES you to load a piece of Google controlled/hosted JS onto your page. That JS can change at any time without "signed exchanges" being aware.

> Google can choose today which site (original or AMP cache) to show in their search results. Today, as an end user, I know, via the URL, when I land on a Google AMP site.

Ok why is this an issue? Note that HN is a bad place for this kind of socratic method discussion, we'll both quickly run out of the ability to post replies. Assume I'm someone who doesn't share whatever values you share about the purity of the url bar or whatever. Why is you being unable to know whether or not the content came from Google's IP or mysite's IP relevant to anyone as long as it's the same content (which signed exchanges ensure)?

Centralised collection of metadata, without the users having any way of knowing it's going on.

Combined with that second thing I mentioned (required Google hosted JS), it is total control by Google with no straightforward way for me to detect it, block it or go around it, as I can today.

So if I understand correctly, your threat model is "Google will inject unwanted JS into a JS blob they host (like the amp.js from Google's CDN) and this will do nefarious (for some definition of nefarious) things to me without me knowing."

How is this different than today, where many sites use js from google, either as a cdn or part of the ads infrastructure? I guess you can block some of those, but blocking the jquery provided by google's CDN isn't going to work too well.

(And further, what kind of nefarious thing do you fear Google will do? How likely is it that they will do so, in your opinion?)

>>what kind of nefarious thing do you fear Google will do

Well, the headline is one good example. That google controlled JS is EXACTLY how they removed access to the original URL...on somebody else's page that isn't theirs. "Signed exchanges" doesn't fix that either. It's also how they hijack the back button and swipe events for carousel navigated pages.

> That google controlled JS is EXACTLY how they removed access to the original URL...on somebody else's page that isn't theirs.

No, the Google AMP cache adds the header bar. That isn't added by the Google controlled AMP js. Let me repeat this: The AMP js didn't change. Google's AMP cache implementation changed. (if you disagree with this, please post the diff of the AMP js that removed the url bar, the js is opensource at [0])

> "Signed exchanges" doesn't fix that either.

Yes it does, in two ways:

1. It would prevent Google from mucking with the embedded page at all, like they do now.

2. It would remove the need for me to have the url redirect, since the url bar would point to the original site.

[0]: https://github.com/ampproject/amphtml/commits/master

Apologies, you're right in that they aren't using it that way. They could, and the examples of the top bar, swipes, and back button hijacking seem to indicate they aren't averse to it. Those things caused me to lose trust in AMP. That they chose to do it via a "proxy" instead of their hosted javascript doesn't make me trust them more.

> How is this different than today, where many sites use js from google, either as a cdn or part of the ads infrastructure?

It's different because it's a requirement. nytimes.com is moving to phase out all third-party advertising data, so presumably they could design their page such that it only accesses their resources.

With a signed exchange, that would allow them to nicely compartmentalize and contain privacy to their site, if they aren't required to load and run some Google supplied JavaScript. The argument that Google already knows that someone visited the page so it's no big deal is not compelling, since there is a big different in knowing someone clicked to visit a page, and having carte blanche over loading your own code on the page in question.

Can you include the AMP rquiers JS inline such that it implement an AMP spec version, or do you need to load it externally? If you can supply it inline, that's great, and what people would want (as long as it doesn't load additional third party resources). If you can't then you're providing Google with an extra level of control that's not really needed, and that's what people are against.

> (And further, what kind of nefarious thing do you fear Google will do? How likely is it that they will do so, in your opinion?)

If we go forth only considering what we think people will do, and not limiting what they can do, we're destined to be upset with the outcome. If not from Google itself, then in twenty years when someone buys Google, or Google sells off a division that houses information, or there's a breach and it's exposed, or some other company rides on Google's coattails and uses the same precedence to get data but is less trustworthy.

The point is that some people don't want to share this information, and would choose not to do so if there was an easy way to tell when it was being gathered. Fighting against new methods that seek to make it implicit instead of explicit is the only real way to do that.

1: https://www.axios.com/new-york-times-advertising-792b3cd6-4b...

> With a signed exchange, that would allow them to nicely compartmentalize and contain privacy to their site, if they aren't required to load and run some Google supplied JavaScript.

Then I'd direct you to Gregable's comment (who is a person who actually works on AMP) that

> the AMP project is actively working to move the origin (control/host) of the AMP Javascript to the publisher's own domain, as well as allow a version served on an origin owned by the OpenJS Foundation, rather than Google.

So while this isn't supported yet, the people working on it do ant that.

> If we go forth only considering what we think people will do, and not limiting what they can do, we're destined to be upset with the outcome. If not from Google itself, then in twenty years when someone buys Google, or Google sells off a division that houses information, or there's a breach and it's exposed, or some other company rides on Google's coattails and uses the same precedence to get data but is less trustworthy.

I'm unconvinced by such slippery slope arguments, given that the pushback were Google to do something like inject nefarious js would be swift. They've had the ability to do so for, well, 20 years now. They haven't yet.

> They've had the ability to do so for, well, 20 years now. They haven't yet.

as we don’t have proof that google did not do nefarious things, we don’t have proof that they haven’t. with such monopoly and power distrust is useful thing.

> as we don’t have proof that google did not do nefarious things

We do have proof that they don't do the specific nefarious things being discussed here: injecting nefarious js into otherwise useful things. That's easy to determine.

I'm not convinced by your argument that since nothing evil has happened in the last 20 years, we are safe in the future.

It's about power dynamics. If you get a consolidation of power, that's going to be open to abuse. Maybe not now, maybe in the future, who knows. Democratic systems have checks and balances in the public domain. Google doesn't have this.

> So while this isn't supported yet, the people working on it do ant that.

Good! For what it's worth, I'm slightly pro AMP based on the idea, I'm just not entirely happy with the current implementation. Fixing it to be less dependent on a Google resource is a good change, IMO.

I use copious Google services, such as Gmail and Drive, and Hangouts (or whatever it's called this week), and Android, but I'm leery of becoming more dependent on Google. It's to everyone's benefit if there's healthy competition between all parties, and to my personal benefit if I don't find that someone's gotten access to my google account and literally everything is open to them (which is why I always use a username/password combination for sites I create accounts for instead of linking my Google account... even if I know my email is @gmail.com so it's of limited use, for now. Baby steps).

> I'm unconvinced by such slippery slope arguments, given that the pushback were Google to do something like inject nefarious js would be swift. They've had the ability to do so for, well, 20 years now. They haven't yet.

First, it doesn't have to be nefarious. The bar for Google deciding they deserve analytics for content they "serve" is much lower than the bar for actually doing something illegal. I prefer not to place options to do what I consider the wrong thing for business gain in front of companies when it can be helped. Hope for the best, plan for the worst, and all that.

Second, that was a single one of the scenarios I listed. The others notably did nt rely on Google doing or not doing the right thing, because the decision is no longer in their hands. If Google is no longer the authority deciding (because they are gone, or have a new parent, or the data was taken), what Google would choose to do is irrelevant. That's why it's important to some people to reduce the information being collected. It's impossible to know what it will eventually be used for in the long term, so the prudent thing is to limit it, and/or compartmentalize it (that is, maybe I'm happy with nytimes.com knowing where else I clicked in their article, but I would prefer Google only know I loaded that first article).

Today, many (most) sites do not use js from Google or hosted by Google. Google is pushing them to use Google infrastructure by way of AMP and that's the wrong direction.

Because now every asset you download from the web is a Google tracking resource. Is it really unclear what’s going on? When you perform a GET request for these assets you are being monitored. These requests end up being part of the profile built for you which is used for advertisement targeting and content recommendation.

PS: You work for Google. Do you work on this project?

> When you perform a GET request for these assets you are being monitored.

You'll only ever retrieve Google AMP cache results from the Google search page, where they were already able to track if you made such a request, since the link you clicked has trackers in it.

So from that perspective, nothing changes.

> PS: You work for Google. Do you work on this project?

No, I work on mostly internal infrastructure. My interest in AMP is simply that I don't dislike the AMP "experience", it's fine. But more importantly, I legitimately don't get the HN hysteria around AMP. Returning to your concern, literally nothing changes with AMP vs non-AMP.

I don't get it. The most compelling concern I've heard is that it's annoying to have to couple parts of your infra to AMP-standard stuff. And I sort of understand that. But even that isn't different than previous SEO/ranking changes that required changes to the page.

> You'll only ever retrieve Google AMP cache results from the Google search page, where they were already able to track if you made such a request, since the link you clicked has trackers in it. So from that perspective, nothing changes.

I am not affected, I don’t use Google search. The problem is for individuals who use Google search and now don’t have an option to avoid in deep tracking. The difference between regular pixel trackers and multiple data points associated with every resource a site serves is immense. I work in ad-tech, not particularly in the identification side, but I started multiple projects in that end. From experience, a regular tracker can be fooled, but you cannot fool every resource request. One of the things I did to identify ad fraud bots was actually drive them to a site in which I controlled every resource. The resource request fingerprint for bots was easily distinguishable from real people. Moreover, some humans exhibited navigation patterns that were distinguishable from other humans. I remember I caught a QA person doing a shoddy job of testing the front end once due to it. That is the kind of power that Google is acquiring as more and more sites choose to use AMPs. It is scary to think that a single identity has that power.

Nothing beyond the initial page load is served by the AMP cache. If you request additional dynamic resources or navigate to other pages, you'll go to the originating site.

I'm confused.

In the example I saw, you could go through a mini site experience; you can “visit” the site without leaving the AMP. I don’t believe this one change, serving images from the AMP cache, is the issue. My concern is with the proliferation of AMPs. A lot of individuals will browse AMPs thinking their browsing is between them and the site publisher without realizing Google is in the middle. Honestly, Google has an okay track record of respecting people’s data. In their AdExchange, they are one of the few that obfuscates the IP address. However it is still concerning that a single entity continues amassing all those browsing patterns from billions of individuals. It can be abused easily, with intent or not.

@DevKoala, do you have an example where you encountered the "mini-site" experience? I haven't seen it, but it could be a bug that would be worth fixing.

Would you bat an eye at Google acquiring CloudFlare?

What they're pushing with Amp and the related technologies grants them a near-unavoidable man-in-the-middle position.

(FWIW I am careful to avoid Google properties at a pretty high cost.)

> Would you bat an eye at Google acquiring CloudFlare?

Not anymore than I already do bat an eye at cloudflare.

(It's probably worth noting here specifically that I do work at Google, so my risk profile is probably different than yours, for me personally and speaking solely from a trust perspective, I'd probably prefer it if Google acquired CloudFlare since I would get a net increase in transparency, but I can understand why that isn't a general position, and there are other reasons I don't think Google acquiring cloudflare would be good).

Thank you for taking the time to engage. Google is a scary beast at the end of the day, and I firmly believe it's an organism that should not remotely resemble what it is right now. Splitting it has potential to go a long way thinking about it.

I share these fears to a lesser degree with Microsoft and of course Facebook. Apple seems to do a great job of safeguarding, but they could become sour if they don't remain careful. Stuff like Clearview crosses the line into directly-dangerous. CloudFlare is currently innocent in my eyes, but they've managed to centralize a lot more channels than I'd like to think about.

> You'll only ever retrieve Google AMP cache results from the Google search page

Uh, I keep seeing Google AMP URLs shared on social media, emails, etc etc. Which is quite annoying :(

The AMP team doesn't prefer these URLs shared either:

If you click the browser share icon, or trigger the browser native share intent, the origin URL will be shared, not the AMP Cache URL. Only if you explicitly copy the URL bar will the AMP Cache URL be shared.

The Signed Exchange spec that AMP has offered sites for a year now allows them to have their own URLs displayed in browsers that support it. In that case, the google.com URL will never be displayed and thus can't be accidentally shared.

All AMP documents on the AMP Cache contain `<link rel=canonical href={origin url}>` and Google recommends that social media prefers the canonical URL. This is useful outside of AMP as there are often multiple URL variants for any article. The sharer and sharee may not ideally get the same version. As an example, a mobile vs. desktop article.

Exactly this. As a feature, social media platforms should automatically look up the canonical URL for a linked page.

I’m sure IRC v3 will get right on that. /s

If someone wants to detect whether a website is using amp, what would be a good way to do it?

It's more of a question of if a specific document is using AMP, the site can be a mix. Just like a site using jquery as an example.

An AMP page can be identified by examining only the first few bytes of the HTML. The `<html>` tag will contain either the `amp` or lighting-bolt emoji attribute, ie: `<html amp>`.

Technically an AMP document must pass AMP Validation to be truly AMP, so there are documents that match the above condition which aren't valid AMP. There are multiple ways to validate. A starting place is https://validator.amp.dev/

If you turn off Javascript the site won’t render for 8 seconds if it’s an AMP.

That's really quite useless. I rarely share links by clicking weird "share link" buttons. I usually have half a message already composed in mail/messages/slack, and I just want to cmd-L cmd-C in the browser and cmd-V in the message I'm writing.

Also, "the google.com URL will never be displayed" is a world with an internet I don't want to be a part of.

Google never displays AMP documents on desktop (sans mobile emulation), this won't be an issue.

The workflow I described goes for mobile and tablets just as much as desktop; for the cases where a keyboard is not connected please mentally replace "cmd-l cmd-c" with "tap in address bar to select, tap copy".

Also, others might share an amp link from their mobile devices, which I then end up clicking in a desktop slack/mail/messages app, and there we go again with the amp virus even on desktops.

>You'll only ever retrieve Google AMP cache results from the Google search page

I see quite a few AMP cache results being shared on twitter (for example).

>where they were already able to track if you made such a request..

It's still possible to get raw Google results (with the right extensions/browsers), though I wonder for how long.

Assume every website would use AMP. Like on mobile. How often do you get redirected to AMP already when you just click a random link? I sure do!

From then on, every asset it loaded via Google servers. Google now controls the entire internet. Google does this so it can serve its ads and track all users. It's as if I would only use Google for my internet surfing.

I don't use Google because I strongly believe it is an evil company, but if websites use AMP, then I am forced to hand over my data to Google even though I don't want to. Right now, I can block Google servers entirely. But if the entire web is served via AMP, I can't do it. And that's the whole reason AMP exists. So everything I do (or at least as much as possible) goes through Google servers.

You really do not see our concern? Really?

AMP also offers traffic after the load, so this is in no way comparable to a click tracker (which is also none of their business, btw). This will also offer in-band ad obfuscation eventually.

I’m curious, what do you value about the services you consume? I like transactions where I know what I am giving to the service provider. Do you really want to push away from this reality for the benefit of a few MS load time leaving a search page? That’s essentially what you’re arguing for.

DevKoala,

I don't think you may realize how much of your online activity is already tracked by google / facebook / instagram.

Google's javascript is everywhere, including explicit tracking with analytics, and lots of CDN loads for endless lists of things (js libraries, fonts etc).

Their properties also track you, google search, youtube, email. They also make software you might use (chome / android / google maps / google play store).

If you think something about signed exchanges let's google track you, and they can't now... please examine these assumptions.

Folks who come up with these super complex schemes (google will use javascript loaded into AMP to take over and track you) ignore that google ALREADY tracks them.

And folks who say they don't use any google products (no android / google maps/ play services / chrome etc etc) are often either lying or don't understand how many third parties load google analytics into websites, or load recaptcha bot protection etc.

I work in ad tech, with years of experience doing identification and targeting. I understand exactly what is happening.

I wrote a reply to joshuamorton were I expressed my concerns.

Just realize that AWS / GCP / Azure have already gobbled up vast swaths of website hosting in all forms and are growing along with some free CDN and DNS providers.

If google said, we want to track people, and brings android, chrome, dns resolvers, network infrastructure, google cloud compute, AI systems, google analytics which these media sites voluntarily, google play services etc to target and track you - they probably could.

EVERY single person (including you) who claim they don't use google, if you dig down, they often are lying and do. And if you don't, some of the people you email or interact with do, so indirect profiles can be built.

AMP solved a need for a lot of users, which is the janky, slow ad filled websites that media sites in particular had become. So there is an actual end user reason people like AMP - it's a better user experience in many cases. This is where AMP is ruining the web gets hard to support. For most folks they don't perceive they are giving up a lot more in terms of privacy, and they are getting a lot.

> If google said, we want to track people, and brings android, chrome, dns resolvers, network infrastructure, google cloud compute, AI systems, google analytics which these media sites voluntarily, google play services etc to target and track you - they probably could.

Their data governance team wouldn’t allow it. You are basically describing a system they could only introduce with the permission of the government. I don’t care if the government is tracking me honestly, I can’t fight that. I just don’t want Google tracking me for the purpose of influencing my spending habits, emotional state, or perception of the world. That is my main beef with their advertising capabilities.

You asked how and he answered. Whether it's an issue or not is a separate matter that none of us are going to agree on.

This concern, Google controlled/hosted JS, is independent from Signed Exchanges and specific to AMP.

At the same time, the AMP project is actively working to move the origin (control/host) of the AMP Javascript to the publisher's own domain, as well as allow a version served on an origin owned by the OpenJS Foundation, rather than Google.

Will this mean that sites will be able to finally lock in a version of AMP? The idea that there is one place right now that is required for all AMP sites that can dynamically update the behavior of all such pages is, in fact, terrifying to me; like, I went into reading this discussion thinking AMP wasn't making anything worse and being super unhappy that anyone even thought to denigrate signed exchanges (as I want those deployed everywhere in order to provide censorship resistant web caching) and then I got convinced by kbenson that this is actually a bit of a dystopia scenario for the web once you involve AMP... I even managed to find an issue about solving this problem with subresource integrity (one you were involved in) that apparently got closed with prejudice (not by you) under an insistence that this javascript injection be an "evergreen" codebase lest somehow everything becomes super insecure, which to me just indicates a fundamental architectural flaw in the security model of AMP :/.

https://github.com/ampproject/amphtml/issues/534

Yes and No, mostly yes:

On publisher origin, the plan-of-record does not involve any validation of the contents of the AMP javascript files. When an AMP Cache (eg: Google) crawls one of these AMP documents, the same is true - the contents of the javascript files will not be relevant to the decision of whether or not the document is considered valid AMP. The files will likely not even be crawled by the Cache.

However, when the AMP Cache serves one of these files, it will rewrite them to the latest* version for serving to users. This is necessary since the javascript runs in a somewhat privileged context in search results.

https://github.com/ampproject/amphtml/issues/25873

* There is also a mechanism for publishers to opt-in documents to a "Long-Term Stable" release, rather than the latest evergreen version: https://amp.dev/documentation/guides-and-tutorials/learn/spe...

Lastly, and there is still some discussion around this, it is likely that Signed Exchanges may be able to load the publisher's own version of the javascript in the future, even in search results. This is because the execution context of the javascript is different for Signed Exchanges.

> a net improvement for security that allows sites to put less trust in third-party servers and scripts.

Third parties like Google, right?

Yes.

Signed Exchanges mean the publisher signs the content using their private key. A third party can provide delivery like a CDN, but they cannot modify the content, or the signature would no longer match. The useragent (browser) enforces this. This gives the secure control of the content back to the publisher, unlike the trust model of CDNs or the AMP Cache.

> The useragent (browser) enforces this.

This assumes the user agent is actually an agent of the user, and not the AMP provider, which is demonstrably [1] not the case.

[1] https://github.com/w3ctag/design-reviews/issues/467#issuecom...

Chrome does enforce the matching signature. Browsers without Signed Exchange support will not likely ever get a signed exchange as they do not advertise support for it in the `Accept` request header.

Chrome enforces that the signature being served by google is the same signature as the one being served by google. It's a useless verification. If Google were so inclined, they could very well just change the <link> tag too.

@freeone3000, that's incorrect, in the case of Signed Exchanges. Chrome will verify the document's signature against the publisher's public certificate. This will be `nytimes.com` for example. It is not using Google's certificate for this verification, and Google does not possess the private key required to modify the content and update the signature.

The actual mechanism by which a signed exchange is implemented is prone to man in the middle attacks by removing the Signature field wholesale. You are not requesting info from nytimes.com, you're requesting info from amp.google.com and trusting that the backing data is accurate. There's no need for a certificate to be presented at ALL! Unless it can be determined that such a header should exist, there's no way to verify its absence.

All this means is that any server can choose to present any bytes, even with TLS, as a response to any request. This isn't a novel observation.

If a signed exchange includes a URL, that URL must be signed for the browser to respect the field.

Right, but this means proposing signed exchanges as a solution to AMP's strategies is kind of nonsense, since it's a semantic problem whether a page is acting as a proxy for another, and a technological solution doesn't work here.

I think we are talking about different things here. You, as an AMP engineer are talking about how Chrome implemented this [1], but I'm talking about how Chrome is not a user agent, because it demonstrably acts as Google's agent, not the user's.

[1] Which is unverifiable, we just have to take your word for it.

Isn't chrome open source? Can't you verify it?

Chromium is Open Source, Google Chrome isn't.

The last time I checked, the only closed source parts were some profile sync keys and some media codecs.

Oh well please keep checking for us, since all of us do not have access to Google Chrome source code. Thank you for taking on this responsibility, sure hope you don't get hit by a bus.

>A third party can provide delivery like a CDN, but they cannot modify the content, or the signature would no longer match.

To make sure I understand, does this mean that in principle a third party other than Google can deliver the AMP pages? Is google working to facilitate that AMP hosting is open to everyone and calibrating their searches point to any and all alternative AMP hosters?

When you search for a term on Google.com, should that load request HTTP assets from multiple potentially-untrusted third parties?

If that best matches my query, then yes.

If a result matches your query, you would like the publisher to know even if the user never clicks on the result? Reread GP's comment.

How is this reconciled with lern_to_spel's reply to my comment, where they claim this is already implemented and there already are such third parties? Are Google searches right now that use AMP exposing users to risks because they are currently requesting assets from potentially untrustworthy third parties?

AMP hosting is already open to everyone, and multiple third parties other than Google deliver AMP pages.

Interesting. Are there examples I can search for right now? For instance, are there searches I could do for a news article, that will show an AMP for a CNN article that's on a non-google url? Do you have a ballpark estimate of what percentage of total amps are delivered by non Google domains?

Also how would you reconcile your comment with that of madeofpalk who appears to be treating that possibility as a hypothetical idea that hasn't happened, and which would be unpraticable due to needing to trust third parties?

> an AMP for a CNN article that's on a non-google url?

All AMP pages exist at non-Google URLs. They are just cached by the link aggregator (typically a search engine), so the link aggregator can prerender them without deanonymizing the user to the publisher until the user clicks the link.

AMP served by CNN: https://amp.cnn.com/cnn/2020/05/27/world/france-shooting-sai...

The same page served out of Bing's AMP cache: https://www.bing.com/amp/s/amp.cnn.com/cnn/2020/05/27/world/...

> Do you have a ballpark estimate of what percentage of total amps are delivered by non Google domains?

All of them (100%) are delivered by non-Google domains to Google, Bing, and other caches.

> Also how would you reconcile your comment with that of madeofpalk who appears to be treating that possibility as a hypothetical idea that hasn't happened, and which would be unpraticable due to needing to trust third parties?

madeofpalk's comment makes perfect sense if you understood what I wrote above. Why should CNN or Bing be told that you have searched for a particular news article on Google before you have clicked it? The page has to be served from the link aggregator the user is browsing to maintain the user's privacy when prerendering results.

You appear to have reinterpreted my questions and translated them into terms that were different than I intended, so I guess I have to take care to go back to the start and restate my original question in a way that uses the appropriate magic words correctly.

I don't intend to ask whether AMPs (hard to resist calling them 'AMP pages') exist somewhere on non Google servers. Obviously third party content that Google is presenting exists somewhere off Google. And obviously it has to be formatted in a way that's compatible with AMP, and it makes sense that that is going to be done off Google domains. I at least knew the gist of that already, and I regard the detour into that explanation to have been a non sequitur. The point is that Google presents AMPs and it serves it's cached version of them from Google servers, on a Google domain. The beginning, middle, and end of the experience of searching for finding and consuming that news never has to involve leaving a Google domain. It's not open in the sense of involving interaction between servers that aren't controlled by Google, until you make that extra click to go from a cached Google version of an AMP to the version that sits on the domain controlled by a third party, at which point going to the third party has been rendered optional and largely unnecessary from the point of view of the user.

This next part is super important: the fact that I'm asking about openness and interoperability, or the lack thereof, in this sense doesn't mean that I'm failing understand the technical advantages with caching and optimization. I regard those as derails that don't wrestle with the issue of openness that's being raised. The point is that the connection between consumers of content who start on Google, and the third party content provider, increasingly depends on Google in a way that shifts nearly the entire experience of consuming content onto Google's infrastructure.

>All of them (100%) are delivered by non-Google domains to Google, Bing, and other caches.

This is the starkest example of a question not being answered but replaced with a different question. I asked 'what percentage of total amps are delivered by non Google domains' and you replied by answering a different question, what percent of non-Google amps were delivered TO Google and other caches, noting that it was 100%. Which of course it is, but that's because that's a tautology.

By contrast, it is helpful to note that there are caches other than Google, like Bing and 'others', which, in contrast to much of the rest of your comment, I feel actually is a pertinent and fair response to the question I'm actually asking. But those aren't content providers, so unless Bing or Google are content creators that were delivering content to themselves, it's tautologically true that 100% of that is going to be delivered to them by third parties, which has absolutely nothing to do with openness. If I'm using magic words correctly, I guess what I want to ask is what percentage of AMP traffic to cached pages is served to users by Bing and others that aren't Google.

An AMP is a page (expand the acronym). I answered your question very precisely, and your response shows that you still don't understand it.

> If I'm using magic words correctly, I guess what I want to ask is what percentage of AMP traffic to cached pages is served to users by Bing and others that aren't Google.

If I search on Bing, the results will be prerendered from Bing's AMP cache. Reread the GP comment, and see if you can understand why that is so.

I want to break down this question slightly.

> Can a third-party other than Google deliver an AMP page?

Yes. Examples: Bing runs their own AMP cache and also delivers AMP pages. LinkedIn and Twitter also link to AMP pages, but they don't currently run a cache. IIRC, Twitter links to the Google AMP cache and LinkedIn links directly to the AMP variant on the publisher origin. They could run an AMP Cache. Cloudflare ran one for some time, but shut theirs down recently.

The AMP Project maintains a list of known AMP Caches here: https://github.com/ampproject/amphtml/blob/master/build-syst...

And provides some guidelines for running one here: https://github.com/ampproject/amphtml/blob/master/spec/amp-c...

It's non-trivial, but absolutely supported.

> Can a third-party other than Google deliver a Signed-Exchange?

Yes. Cloudflare generates them for their customers who opt-in via their "AMP Real URL" product. "Generates" in this context implies delivering them. To date, I'm unaware of any large scale implementation that is delivering Signed Exchanges for third-party origins other than the Google Cache though this may change. The tech stack absolutely supports this.

This is changing the semantics of fetching a URL to be agnostic how it gets resolved. That’s disturbing and downright deceitful to the end user.

Fifteen years ago, if you asked me how google search would look, I would have responded “mostly the same, maybe they’ll have cool features like asking me which meaning of ‘converse’ i wanted: the shoe brand or the logical relation.”

Instead, they’ve only subtracted functionality from the query engine (no more domain blocking), discouraged you from clicking through to sites by automatically scraping and rehosting them as “semantic” results, and now they’re trying to actively acquire 100% of the outbound traffic. Fuck google.

I don't think its deceitful - end-to-end, the site you're displaying was loaded somehow from domaina.com and it'll show domaina.com in the address bar.

But it’s not loaded from their servers when I request it. So it shouldn’t show as such in the address bar.

It blows my mind that anyone thinks that’s an acceptable idea.

If a site is cached locally, it isn’t loaded from ‘their’ servers when you request it. Or maybe it’ll come from a CDN rather than origin.

What’s shown in the URL bar has long been divorced from the HTTP request(s) that are made.

> It blows my mind that anyone thinks that’s an acceptable idea

It blows your mind that different people have difference opinions and values than you?

What is stored in your cache was loaded from their servers when you originally visited. Also, you can clear your cache at any time you choose to re-fetch the original content from the provider.

Also, a provider uses a CDN at their discretion. Giving them the ability to invalidate or update cached records at times of their choosing. Or remove the CDN entirely if they choose to.

This is Google using their weight to be anti-competitive and fall further down the anti-trust rabbit hole.

A provider uses a CDN at their discretion, but it's totally legitimate to have a client-site cache as well. If I've got 20 users going through a squid proxy to get to the internet, that's something the provider has to live with. Not to diminish your core point, which I think is correct, but there are limits on what providers should be able to expect.

I sort of agree with you, but robots.txt is a thing.

I know it seems impossible but nobody has to use Google.

Are there any copyright implications of amp? They're essentially republishing your property.

Does the original publisher get their ad revenue?

> It blows your mind that different people have difference opinions and values than you?

Given context and full knowledge of the issues involved? Yes, absolutely. For this particular issue anyway.

> Or maybe it’ll come from a CDN rather than origin.

That’s not a problem, since the URL and where it points to is still decided by the content owners.

The snippet isn't loaded from their servers when you request it either. Do you think that's a bad idea as well?

yes.

Can you explain? Every time you search, do you want all of the publishers who appear on the results page to know that you were searching? Or is it that you don't want snippets to appear in the search results and just want a list of links without any evidence for why they might be good matches for your query?

This is a good example of the contradictions within AMP that limit it's usability as a technology. Unless AMP was really intended as a privacy tool this whole time and I just didn't know it, publishers probably "should" know the same amount they would get to know if you visited one of their actual pages, if you are visiting an AMP for the purpose of consuming their content rather than merely searching for it. But if that disrupts the smooth functioning of AMP, well, now we're just exhibiting an architectural shortcoming that's baked into AMPs philosophy of how to serve content.

>Or is it that you don't want snippets to appear in the search results and just want a list of links without any evidence for why they might be good matches for your query?

Is that how you feel about regular search results?

Your comment does not make any sense to me. Are we talking about the same thing? A snippet is a summary of the page served by the search engine. The publisher currently does not have any idea that a particular user has seen a snippet, so publishers do "know the same amount" as they did before with AMP, which is nothing.

> Is that how you feel about regular search results?

Regular search results have snippets.

I'm sorry that you were having difficulty interpreting my comment. It may help if you go back and note that I was making a distinction between using AMP to consume content vs search for it. Publishers normally know when their content is being consumed. Let me know if that makes sense to you.

>Regular search results have snippets.

Right, and I was asking about the search results, not the snippets that accompany them. That is to say, the part with the blue title, green link, and the few lines in black displayed from the page that are displayed ten at a time, not the snippets that accompany them at the top of the page. Unless you were just using 'snippets' as a general term to mean the same thing that I mean by search results, in which case you were just repeating the content of my own question back to me.

> Publishers normally know when their content is being consumed.

They still know when their content is being consumed. They just don't know when their content is being searched for until the user clicks their link, exactly like a snippet. Does that make sense now? My point was that search engines already show cached portions of the page. Read the parent comment of my first "snippet" comment to understand why I was making that point.

I don’t follow. When I search I see google.com in the address bar, so logically that is where the snippets come from.

If I click one of the links, then yes, I absolutely expect the publisher to know I did.

Agreed. SXG is better than AMP for providing permalink.

Even better than blocking AMP is just redirecting to the proper page[0].

[0]: https://addons.mozilla.org/en-US/firefox/addon/amp2html/

Does that extension break with this most recent change though?

This most recent change is just a bug in Image Search, at least based on the tweets I read. The extension seems to inspect the AMP article's URL and HTML, both of which are outside the scope of Image Search: https://github.com/da2x/amp2html

Yessss. Any chrome equivalent

Aside from installing Firefox (best option), there is this:

https://chrome.google.com/webstore/detail/redirect-amp-to-ht...

It’s also available for Edge. https://microsoftedge.microsoft.com/addons/detail/abjhjmfkmd...

Yes, that is even better! Unfortunately it doesn’t work on iOS, or I would have never created my list. Literally the only thing I miss about Android was being able to use browser extensions like uBlock Origin with Firefox on Android. Safari has its built-in content filters but it’s not the same.

Sadly, Ublock Origin is literally the only Firefox extension available on Android atm.

Not quite literal: It's recently up to 6 addons -- the others are https everywhere, privacy badger, noscript, dark reader, and search by image.

Note to others: this is about the upcoming rewrite, available as Firefox Preview and Firefox Beta.

Firefox for Android?

I got:

Don't f* with paste, Disable WebRTC, Dark Mode, a couple of image savers, NoScript, AdBlock Plus, Privacy Badger.

I recommend https://filterlists.com/ if you use any blockers, it's an easy way to subscribe to lists.

I have the beta, and only have uBlock origin. If I go to the addons site it tells me that, for example, privacy badger is not available on Firefox for Android.

Firefox Beta and Firefox Preview are a bit different. Preview and Focus are both currently a bit more experimental, they're stable but they're not guaranteed to be kept alive. Firefox Beta and Nightly are both the current latest versions of what will be merged into the stable.

There's a big rewrite being done and the current stable Firefox for Android which supports basically all addons that the desktop version does, will be deprecated soon-ish. Preview has a broader support.

Beta and Nightly only support uBlock Origin, literally.

Preview supports six addons in all, but Preview isn't a promise of whats to come as they consider it a pilot.

Huh, I stand corrected. I assumed that since the geckoview / the new UI had come to beta, that it supported the same addons as preview.

Why not redrect to the blazing fast AMP page in the original domain (without the Google CDN), instead of often bloated full HTML page? E.g. https://example-com.cdn.ampproject.org/c/s/example.com/amp_d... => https://example.com/amp_document.html

Duck duck go is a lighthouse in the storm. We are all saved. If Jesus came back ask yourself this, ‘would he be google or duck duck go’

Exactly. Search your hearts and use the net with your values as though they’ve become a force to be feared by the swill that is invading our liberties (google).

If you're using DuckDuckGo, presumably a site that doesnt do the "AMP Cache" iFraming that Google Search does, then what are you left with, apart from a website that will almost definitely load faster than the 'original'?

Ah, so that's why Google has added site speed to their ranking factors? Another brick to hit them with then in the anti-trust lawsuits.

> How does anyone think this is a good idea?

A while back on one of the AMP discussions here, someone from Google weighed in. They said the data was clear: users not only accept it, they love AMP.

I asked how they knew that, because if it was, say, just tracking how many people tried the 2-3 tap process to get to the original URL compared to how many people just engaged whatever you showed them, then the data might be showing you something else (and in fact, I wasn't clear how you'd get from accept to love in any other way than a focus group or survey).

No response. Not clear if that's because revealing data would run afoul of internal confidential disclosure, or because this basically hadn't been thought through.

> Apple for refusing to change the URL bar like Google does on Android.

Apple has its own problems with the URL bar -- they keep the domain but drop the rest of the URL. Not as bad as replacing the domain, but not great.

Companies with shitty UI often make unfounded claims that "users prefer it." Adobe is another prime offender here.

If anyone's word should NOT be taken as gospel for UI or branding, it's Google's.

Adobe users do prefer the UI to GIMP, for example.

Reminds me of the Office 2013 ribbon bar - users preferred it apparently! They couldn't find any of the options they'd used for 20+ years but somehow preferred it!

Thank goodness menus for Office still existed on the Mac.

> Apple has its own problems with the URL bar -- they keep the domain but drop the rest of the URL. Not as bad as replacing the domain, but not great.

You can view the full URL in safari for iOS by tapping the URL bar. In Safari for Mac, you can modify your preferences to always show the full URL. Definitely not ideal, but also not anticompetitive in the same vein as AMP

> users not only accept it, they love AMP.

As a user, I will absolutely say I love AMP. AMP pages load incredibly fast with much less bullshit.

The real problem is that AMP isn't necessary. Google created AMP and is encouraging (nearly forcing it) it in a very hamfisted way because web developers couldn't figure out how to make responsive, fast-loading web pages without a huge company like Google spelling it out for them with a framework.

Now, obviously to power users like the typical HN user, AMP is evil because it's just Google taking over more of the web.

But understand that to your typical mobile user, AMP is a godsend because of how fast it is. They don't care that the URL shows Google instead of whatever page they think they're on.

Often, it's not the developers that are at fault. Middle managers, cross-functional people, etc. ask developers to cram garbage into otherwise would-be lean pages. Developers often have no authority to push back, and stakeholders often don't fully understand "why" the garbage they're asking developers to insert into pages is detrimental to the user experience.

With AMP, the little badge (the verification), serves as a constraint for developers, but mostly for business stakeholders. The conversation of "I can't do that, because it's simply not compatible with AMP" is way easier than "I can't do that, because it will make the page slow".

Makes sense. Middle managers love their analytics and dashboards.

I am also a user who loves AMP, the same way I loved RSS. The reason I love AMP is one of the same reasons I loved RSS. RSS aggregators allowed instant loading of content across multiple sites. AMP enables the same thing but with a richer experience. It doesn't simply spell out how to make web pages fast. It makes them instant, which is impossible without something like AMP or RSS that allows safe prerendering with publisher opt in.

>Of all the anti-competitive actions google has taken around search results, AMP is by far the worst. I hope they get smacked down for it in the upcoming anti-trust lawsuit.

This reminds me of the EU Internet Explorer lawsuit, which was peanuts compared to what Google is doing right now. Between Google Search, Chrome, Android, Youtube, Gmail, Google Maps, Google Docs, AMP and likely 5 more things I forgot, they've stealth-grabbed so much of the internet, it's not even funny. At least force them to split off their ad/datahoarding businesses.

Their ad business is more or less their only business. Everything else is paid for by that.

which is why it should be segregated from the products people find useful

Exactly; this would - if done correctly - result in Google collapsing pretty much immediately, as they should have done a decade ago.

> How does anyone think this is a good idea?

They don't.

> Just heard from the Image Search team that this is an oversight and they'll add the feature! Sorry about that and thanks for the report!

https://twitter.com/cramforce/status/1265688067706245120

So how long until AMP is exploited in a wide range phishing campaign? I know that it is getting harder and harder to distinguish phishing emails from non-phishing emails, but this move is not helping at all. It clearly helps google though.

The annoying thing is, average user will not notice and/or care.

All it would require is an AMP website that mimics the Google login page. It already says "google.com" at the top of the browser, and we've told users to trust that, so...

I’m surprised this is not widespread yet. Is there anything in AMP to detect and block phishing attempts?

The google.com domain would also probably trigger autofill recommendations from some password managers, which would make things even more convincing and seamless.

Maybe they are trying to push their signed exchanges / "AMP real URL"[1]? Last I understood, Firefox says they won't support it, ever. Apple is less vocal about it, but doesn't appear to be working it.

[1] https://webmasters.googleblog.com/2019/04/instant-loading-am...

> Firefox says they won't support it, ever.

That's a bit of an exaggeration. Mozilla's position statement on web packaging[1] says:

> As a whole, and for origin substitution in particular, until more information is available on the effect on the web ecosystem, Mozilla concludes that it would not be good for the web to deploy web packaging.

Personally I'd like to see web packaging adopted without the origin substitution capability (at least to start with), as it would still allow sites to offer web apps comprised of a fixed bundle of code (signed with an offline key), rather than potentially different code each time you visited. That would reduce some of the concerns around serving "secure" apps on the web, as long as browsers had a way of preventing the server from silently updating the web package (perhaps using short-lived unique subdomains/certs).

[1] https://docs.google.com/document/d/1ha00dSGKmjoEh2mRiG8FIA5s...

> I hope they get smacked down for it in the upcoming anti-trust lawsuit.

People have been saying this for years, and it never happens.

https://en.wikipedia.org/wiki/European_Union_vs._Google - Things take time, but Google did get fined in the past and there's a good chance they get fined again (and forced to change things).

Fined ≠ "smacked." To Google, EU fines are just a cost of doing business. Like FedEx eating parking tickets.

Until Google is fined to a degree that it impacts its share price, nothing will change.

All of the 3 big antitrust cases with fines the parent linked to resulted in Google changing their practices.

So IMHO "nothing will change" does not seem right.

If Google had truly changed, this topic wouldn't come up over and over again.

My concern is they lose the ability to counterbalance the other four of the Big Five, if they are uniquely targeted by an anti-trust lawsuit.

Which is to say, I don't disagree with the momentum toward anti-trust measures being brought against Google, but I want them systematically brought against the entire Big Five, or else the effects may just be further consolidation.

This amp nonsense has long annoyed everyone and I'm puzzled why it's still around.

It makes everything harder and confuses deeplinking, sharing, identifying sites and general navigation between pages.

When you say everyone you mean a tiny minority of developers. The actual users don't care or even know what it is. If anything they like it because it loads the page faster.

I don't know if it is just my experience but amp sites load slower than hn does. Slower than my own websites. Slower than the websites I usually read on.

Sure, amp sites from the feed appear to "work" instantly but they fetch all the content in the background so that's not fair (on chrome at least).

I disagree that amp doesn't bother normal users. It is easily noticeable when you click on a search result and go to a page that says amp.google.com?blah=blahhhh and all that. When, as a normal user, you try to copy that link, you'll end up finding this junk and no straightforward way to see the original link. When you click on a link on the AMP page, it forces a full browser refresh. Sites which force people to use apps don't even work with AMP, because these links confuse the deep linking big time. I haven't even seen AMP pages to be any faster than the actual website itself.

It's because your internet speed is too good to notice. AMP pages are definitely much faster, which you can ask anyone in a country with lousy internet connections about. I'm not saying that AMP is good but claiming it's not faster is just wrong. I also don't see why it wouldn't be. If the restrictions on the stuff you can put on AMP pages together with Google's edge caches wouldn't make it faster it would be strange.

>I hope they get smacked down for it in the upcoming anti-trust lawsuit.

I wonder if the outcome of the lawsuit will be a grab bag of concessions, such as abandoning AMP, and, say, adding the ability to fully delete Google Apps from Android rather than doing a mere factory reset, making opt-out of interest based ads easier, and things of that nature.

This news is talking about amp image search and you talking about amp post. First visit this URL https://twitter.com/zenexer/status/1265633022709301249 and understand what this post want to tell us.

> How does anyone think this is a good idea?

Isn't Malte Ubl one of the developer/architect behind it? I could be wrong about this but I remember reading his notes/thoughts on AMP last year.

Malte tweeted about this 8 hours ago actually: "Just heard from the Image Search team that this is an oversight and they'll add the feature! Sorry about that and thanks for the report!" https://twitter.com/cramforce/status/1265688067706245120

The already proclaimed their desire to get rid of the URL. I don't think this is in the interest of the user and more in the interest of market dominance and information filtering.

I wrote an extension to "unamp" the website of a popular Italian newspaper and as soon it reached a thousand users Google banned it and forced Firefox to do the same (shame on you Firefox)

So I guess worse is better we are supposed to accept it or else they'll police us into accepting it.

Can you share more details?

The extension was very simple, it just displayed the content for pages protected by a paywall by changing the display attribute.

To be clear, they use amp to serve pages in the protected area, but the protected content is served in the body of the page, inside an AMP-APP tag, but simply hidden.

The code is few lines long, it could have been one line, but it has to unwrap the shadow dom.

I made it for myself, but then friends started asking for it so I published it on Firefox's extension store and later on on the Chrome's one.

It's been there for a couple of years, nobody complained, I even emailed the newspaper several times to warn them about the "bug" but they never replied back.

It has never been very popular, especially outside Italy, it had around a thousand of installations and about 900 daily users, but on March this year I received a copyright infringement notice from Google, even though Google has no rights on the newspaper's content.

They removed the extension right away and banned me from re-uploading it.

I tried to reach their support many times, never heard back from them.

A few days later Firefox removed the extension as well saying Google contacted them about the copyright infringement.

As of today after at least a dozen emails I haven't been able to speak to a human being.

I don't mind much, I still use it on my systems and it still works even on Firefox mobile (for now)

I tried to upload it under a different name, but apparently I'm forbidden from publishing it again.

Weird detail: the day after Firefox removed it I've been contacted on the email I used to register on Firefox dev website asking me if I wanted to sell the extension.

The newspaper website is https://www.repubblica.it

I'd like to know details.

Maybe read the actual page you are on? Clearly you have identified the Examiner and CNN despite a google url.

I am no fan of AMP, but this criticism is not particularly valid.

What about the URL bar?

For average non techie users, the URL bar isn't particularly helpful. They use page content. And AMP pages do show the original page domain name.

The URL bar is helpful to fighting phishing attacks. It's one of the things everyone at my company, including the non-technical people, is askedt to check before entering information.

Also techie and non-techie people have been using the same browsers for how many decades now? Aren't the majority of people in many countries on the internet? It seems like the average non-techie users succeeded in figuring things out so far.

> The URL bar is helpful to fighting phishing attacks

It would have been nice if client side TLS certificates were more popular. Then your browser could warn you that you're not using your client cert when connecting to a certain website and not allow you to complete the connection. That would be a better solution as opposed to relying on users to manually check the URL.

while we're wishing for things that just won't ever happen, can I have a pony?

How does a client-side cert help with authenticating the server? Why wouldn’t a phishing site also ask for the client-side cert if the real site does?

~~It wouldn't work because the phishing site would lack the private key needed to validate your client-side certificate and the TLS connection would not be established. This is assuming that the legitimate website itself signed your certificate signing request (CSR) to create the client-side certificate.~~

Edit:

What I posted above is not correct. What I should have said was that the server would validate the client certificate by checking a certificate authority (either managed by the server itself or a 3rd party).

>It wouldn't work because the phishing site would lack the private key needed to validate your client-side certificate and the TLS connection would not be established.

That is not how TLS works. A server can trust a client based on the certificate the client presents. A client can't distrust a server based on the certificate the client presents.

"The phishing site would lack the private key needed to validate your client-side certificate" is nonsense. Neither the real site nor the phishing site have the private key used to generate the CSR; only the client that sent the CSR has that, and validating a cert does not involve the private key in any way. If you're thinking of a new protocol where the server itself generates an arbitrary asymmetric keypair and shares it with the client, then a) that's not TLS, b) that could just as well be done with a symmetric key (since this is just pre-shared key auth) where the server presents a nonce to the client to sign and verifies the client signed it, and c) a fake server can just not do that.

> That is not how TLS works. A server can trust a client based on the certificate the client presents. A client can't distrust a server based on the certificate the client presents.

You're correct; I posted inaccurate information.

> validating a cert does not involve the private key in any way.

What I should have said was that the server would validate the client cert by checking whether the certificate is valid according to the authority that signed it (which could be the server serving as a CA itself or a third party CA).

As for the original question, I guess it's possible for a phishing website to not bother validating the client certificate presented at all and allow the TLS negotiation to succeed.

If there was something that could instruct a browser to only send a given client certificate if it only receives a certain server certificate, then it would be much harder for a phishing website to work, because the browser would not send the client certificate to the wrong server.

Not to pile on, but I think you're imagining some kind of TLS framework that simply doesn't exist currently. It's not clear if you're misunderstanding what exists now, or you're alluding to a different possibility without clearly articulating it.

> I guess it's possible for a phishing website to not bother validating the client certificate presented at all

Why would a phishing site do anything to discourage a connection from a potential victim? Of course a phishing site would accept an invalid or missing certificate! Even if the site was impersonating something like amazon.com, Amazon hasn't issued client certificates to all of its users so the whole point is moot.

> I think you're imagining some kind of TLS framework that simply doesn't exist currently. It's not clear if you're misunderstanding what exists now, or you're alluding to a different possibility without clearly articulating it.

It's possible that I am misunderstanding it, but it appears that the point of contention is what the server will do when it receives a certificate from the client.

Ideally, it would check if it's valid by checking it against a CA. So, if someone who manages the server signed the CSR, then the server can validate the certificate with a CA that it manages. If it uses a 3rd party CA, then it would validate it using that.

What I'm not sure about is whether a browser can map a particular client side certificate to present to a server based on the server side certificate presented to the client. If it could, then it would be easy to determine whether one has connected to the correct server since the browser wouldnt' try to present the client side TLS cert to the wrong server.

> Even if the site was impersonating something like amazon.com, Amazon hasn't issued client certificates to all of its users so the whole point is moot.

Which was the point of my original post. If we had worked in making the process of generating and using client side certificates more user friendly, then companies would have done so as part of the account creation process (meaning poeople would use their client cert in addition to their username and password as part of the authentication process).

What we have now is major companies like Amazon using SMS based 2FA that would easily be compromised by re-routing the verification code message to another device since that factor is not under my control, but at the mercy of the phone company.

A private key is not required to validate certs (private keys are for generating certs). A cert chain back to a trusted root cert is required for validation. A phishing site would just trust all certs.

I realize that now. One way to mitigate it would be to have the browser somehow tie a given client certificate with a particular website. That is, the client cert for news.ycombinator.com, would only be presented if I try to connect with that server and nothing else.

That way, if I go to a phishing website that pretended to be Hacker News, my client certificate would not be sent and my browser could warn me by saying that the connection is not using a client certificate. Right now, if we only rely on server side certificates, there's nothing stopping a phishing website from using Let's Encrypt to show the secure connection icon in the URL bar and tricking me into thinking it's a legitimate server.

It doesn't. The way client certs are useful is that a website that only uses client certs for authenticating clients removes the ability for the client's credentials to be leaked.

Even if the user uses the client cert with a phishing site, the phishing site doesn't have the ability to impersonate the user against the real site because the private key is still on the client's device.

In addition, if a browser is configured to automatically use a client cert for all requests to a particular domain, then even that leak doesn't happen because the browser would automatically not use the cert with the phishing domain.

Reply on news.ycombinator.com