4 ms·

is this served from politico's servers and how is it different from a stripped down version of their site?

tyingq 7y ago
It's not. It's using "Signed Exchanges", which Chrome supports, but most other browsers do not. It's just AMP with some crypto that lets Google masquerade as your domain.
- buboard 7y ago
  oh wow, Signed Exchanges are worse than AMP! "make sure you are visiting mybanksite.com" is no longer safe.
  - echeese 7y ago
    How is it no longer safe?
    - buboard 7y ago
      Phishing
      - echeese 7y ago
        They can't alter the content - that's where the 'signed' part comes in. Any forms there would still go to the original source.
  - JohnFen 7y ago
    I don't think there's a real phishing risk with them, but I object to Signed Exchanges because they are actively making the browser lie to me about the URL being used.
    - Ajedi32 7y ago
      The URL the browser shows is the one which was cryptographically verified to be correct. I don't see how you can call that a "lie". If I'm offline and I open an offline cached page in my browser, would you call it a lie if the browser displays the URL I originally downloaded that page from in the URL bar instead of saying it came from "your hard drive"?
      - tyingq 7y ago
        It's not just us HN commenters that are concerned. Mozilla, for example, is highly opposed to it in it's current state. "Mozilla has concerns about the shift in the web security model required for handling web-packaged information. Specifically, the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome, as is the removal of a guarantee of confidentiality from the web security model (the host serving the web package has access to plain text). We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases so long as the foregoing concerns could be addressed." Mozilla has the proposal marked as "harmful". Apple/Webkit have concerns as well: https://news.ycombinator.com/item?id=19679621 https://news.ycombinator.com/item?id=19679621
        deleted 7y ago
        [deleted]
        Ajedi32 7y ago
        > We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases[...] That doesn't sound "highly opposed" to me. Anyway, I read the full report from Mozilla back when they first published it, and while they do have some valid concerns (any new feature introduced to the web will necessarily introduce some new attack surfaces) I believe their concerns are already sufficiently well addressed by the standard. The paragraph from Mozilla that you quoted is also rather vague and misleading. In particular: > the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome This is super vague. I see no reason why that should be "worrisome". That sort of thing happens all the time in public key cryptography. When you receive a message signed with the private key of a trusted actor, it's perfectly reasonable to trust that the trusted actor authorized that message regardless of where the message itself came from. TLS itself already does exactly that every time you visit a website over HTTPS (your browser trusts certificates signed by a trusted CA, even though those certificates are being presented by an untrusted website, not the CA itself). > as is the removal of a guarantee of confidentiality from the web security model This concern is completely unfounded, and I'm surprised Mozilla included it in their summary. The use of the signed exchange standard doesn't reveal any information to any party that would not already have access to that information without the standard (a host serving you a link to a static, public page will necessarily already have access to the plaintext content of that page, regardless of whether they serve you that content themselves or not).
  - danans 7y ago
    > oh wow, Signed Exchanges are worse than AMP! > "make sure you are visiting mybanksite.com" is no longer safe. Sounds like you don't trust public key based content signing. This is just broadening public key based signatures beyond the domain to include the domain and the content itself, and using signing to make the authenticity of the content independent of the physical infrastructure that served it. That' what's being used here to verify authenticity of content's source, just like PGP/GPG does for signed emails. That's a far stronger guarantee than "the data is authentic because it came IP address range X purchased by company Y". In fact, without a such signature, there is no guarantee that just because a piece of content came from a particular server/datacenter, that it is authentic. With signed exchanges, the chain of authenticity is pushed all the way back to the website's content creators - it doesn't stop at the web server. Also, this can't be phished unless you break the the content signing algorithms, and if that happens ... we all have bigger problems.
    - buboard 7y ago
      first, it breaks the URL specification, as the "host" is no longer a host. it breaks user's expectation of one of the VERY FEW things that everyday users understand about the internet. one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache, and then use it to phish customers from within the bank's domain. Or just use a stolen key to make thousands of such pages before the bank finds out. I think , contrary to what you say, it's a brand new, major attack surface.
      - Ajedi32 7y ago
        > one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache Only if you have the bank's private key, and the ability to serve arbitrary content from the bank's domain. In which case... yeah, I don't see how the signed exchanges standard makes that problem significantly worse.
        buboard 7y ago
        i don't know what's the max expiration for amp's cache, but i could set a really-long expiration date on the file and remove it from the server without the bank ever knowing it existed. SGX don't even require an upload - one disgruntled employee could do the same with a stolen key. Nobody benefits from this shit than google. Do we really need more attack surfaces?
- Ajedi32 7y ago
  Correction: It lets anyone cache your page, not just Google. And no "masquerading"; that's what the crypto is designed to prevent. Also it's not specific to AMP; you can use signed exchanges with any data served over HTTPS.
  - tyingq 7y ago
    It's effectively just Google since it's not widely supported by browsers other than Chrome. There's also only one CA provider that can create the right certificate for SXG. Or maybe you have some notable examples of SXG being used in a production non-AMP scenario?
    - Ajedi32 7y ago
      The standard is brand new, and AMP was the motivating factor for its creation, so obviously the majority of existing use cases are AMP-related. That doesn't mean you couldn't go and implement a non-AMP use case in your own production site today.
      - dane-pgp 7y ago
        One interesting use case for SXG is to allow decentralised and offline websites, since the site's data can be tied to a key/certificate/domain without having to be downloaded from a specific server. As an example, the IPFS project is already trialling the technology: https://github.com/ipfs/in-web-browsers/issues/121 https://github.com/ipfs/in-web-browsers/issues/121
        buboard 7y ago
        tying it to a domain name (which is the typical use of the URL) breaks the web though. i could understand if the key is used to show that the origin is a twitter account handle or something, but breaking the semantics of the domain by signing the content doesn't make any functional sense. Other than putting lipstick on a pig (AMP) of course
v7p1Qbt1im 7y ago
I believe it‘s done with via signed exchange. You are free to host it where ever i think. https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/ https://amp.dev/documentation/guides-and-tutorials/optimize-...

It's not. It's using "Signed Exchanges", which Chrome supports, but most other browsers do not. It's just AMP with some crypto that lets Google masquerade as your domain.

buboard 7y ago
oh wow, Signed Exchanges are worse than AMP! "make sure you are visiting mybanksite.com" is no longer safe.
- echeese 7y ago
  How is it no longer safe?
  - buboard 7y ago
    Phishing
    - echeese 7y ago
      They can't alter the content - that's where the 'signed' part comes in. Any forms there would still go to the original source.
- JohnFen 7y ago
  I don't think there's a real phishing risk with them, but I object to Signed Exchanges because they are actively making the browser lie to me about the URL being used.
  - Ajedi32 7y ago
    The URL the browser shows is the one which was cryptographically verified to be correct. I don't see how you can call that a "lie". If I'm offline and I open an offline cached page in my browser, would you call it a lie if the browser displays the URL I originally downloaded that page from in the URL bar instead of saying it came from "your hard drive"?
    - tyingq 7y ago
      It's not just us HN commenters that are concerned. Mozilla, for example, is highly opposed to it in it's current state. "Mozilla has concerns about the shift in the web security model required for handling web-packaged information. Specifically, the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome, as is the removal of a guarantee of confidentiality from the web security model (the host serving the web package has access to plain text). We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases so long as the foregoing concerns could be addressed." Mozilla has the proposal marked as "harmful". Apple/Webkit have concerns as well: https://news.ycombinator.com/item?id=19679621 https://news.ycombinator.com/item?id=19679621
      - deleted 7y ago
        [deleted]
      - Ajedi32 7y ago
        > We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases[...] That doesn't sound "highly opposed" to me. Anyway, I read the full report from Mozilla back when they first published it, and while they do have some valid concerns (any new feature introduced to the web will necessarily introduce some new attack surfaces) I believe their concerns are already sufficiently well addressed by the standard. The paragraph from Mozilla that you quoted is also rather vague and misleading. In particular: > the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome This is super vague. I see no reason why that should be "worrisome". That sort of thing happens all the time in public key cryptography. When you receive a message signed with the private key of a trusted actor, it's perfectly reasonable to trust that the trusted actor authorized that message regardless of where the message itself came from. TLS itself already does exactly that every time you visit a website over HTTPS (your browser trusts certificates signed by a trusted CA, even though those certificates are being presented by an untrusted website, not the CA itself). > as is the removal of a guarantee of confidentiality from the web security model This concern is completely unfounded, and I'm surprised Mozilla included it in their summary. The use of the signed exchange standard doesn't reveal any information to any party that would not already have access to that information without the standard (a host serving you a link to a static, public page will necessarily already have access to the plaintext content of that page, regardless of whether they serve you that content themselves or not).
- danans 7y ago
  > oh wow, Signed Exchanges are worse than AMP! > "make sure you are visiting mybanksite.com" is no longer safe. Sounds like you don't trust public key based content signing. This is just broadening public key based signatures beyond the domain to include the domain and the content itself, and using signing to make the authenticity of the content independent of the physical infrastructure that served it. That' what's being used here to verify authenticity of content's source, just like PGP/GPG does for signed emails. That's a far stronger guarantee than "the data is authentic because it came IP address range X purchased by company Y". In fact, without a such signature, there is no guarantee that just because a piece of content came from a particular server/datacenter, that it is authentic. With signed exchanges, the chain of authenticity is pushed all the way back to the website's content creators - it doesn't stop at the web server. Also, this can't be phished unless you break the the content signing algorithms, and if that happens ... we all have bigger problems.
  - buboard 7y ago
    first, it breaks the URL specification, as the "host" is no longer a host. it breaks user's expectation of one of the VERY FEW things that everyday users understand about the internet. one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache, and then use it to phish customers from within the bank's domain. Or just use a stolen key to make thousands of such pages before the bank finds out. I think , contrary to what you say, it's a brand new, major attack surface.
    - Ajedi32 7y ago
      > one may manage to upload an html file to the bank's server and serve a -signed- page that google amp will cache Only if you have the bank's private key, and the ability to serve arbitrary content from the bank's domain. In which case... yeah, I don't see how the signed exchanges standard makes that problem significantly worse.
      - buboard 7y ago
        i don't know what's the max expiration for amp's cache, but i could set a really-long expiration date on the file and remove it from the server without the bank ever knowing it existed. SGX don't even require an upload - one disgruntled employee could do the same with a stolen key. Nobody benefits from this shit than google. Do we really need more attack surfaces?
Ajedi32 7y ago
Correction: It lets anyone cache your page, not just Google. And no "masquerading"; that's what the crypto is designed to prevent. Also it's not specific to AMP; you can use signed exchanges with any data served over HTTPS.
- tyingq 7y ago
  It's effectively just Google since it's not widely supported by browsers other than Chrome. There's also only one CA provider that can create the right certificate for SXG. Or maybe you have some notable examples of SXG being used in a production non-AMP scenario?
  - Ajedi32 7y ago
    The standard is brand new, and AMP was the motivating factor for its creation, so obviously the majority of existing use cases are AMP-related. That doesn't mean you couldn't go and implement a non-AMP use case in your own production site today.
    - dane-pgp 7y ago
      One interesting use case for SXG is to allow decentralised and offline websites, since the site's data can be tied to a key/certificate/domain without having to be downloaded from a specific server. As an example, the IPFS project is already trialling the technology: https://github.com/ipfs/in-web-browsers/issues/121 https://github.com/ipfs/in-web-browsers/issues/121
      - buboard 7y ago
        tying it to a domain name (which is the typical use of the URL) breaks the web though. i could understand if the key is used to show that the origin is a twitter account handle or something, but breaking the semantics of the domain by signing the content doesn't make any functional sense. Other than putting lipstick on a pig (AMP) of course

v7p1Qbt1im 7y ago

I believe it‘s done with via signed exchange. You are free to host it where ever i think. https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/ https://amp.dev/documentation/guides-and-tutorials/optimize-...