5 ms·

I didn't even know about "HTTP Exchanges", and I'm more interested than ~98% of the population about this kind of stuff. Showing the name of the "signer" in th

by sandov 8y ago

I didn't even know about "HTTP Exchanges", and I'm more interested than ~98% of the population about this kind of stuff. Showing the name of the "signer" in the address bar, instead of the server where the content is actually hosted goes against decades of browser UI design. Good on Mozilla for marking it as harmful.

jedberg 8y ago
> Showing the name of the "signer" in the address bar, instead of the server where the content is actually hosted goes against decades of browser UI design Does it though? If you use Cloudflare or Akamai or Cloudfront or Netlify or etc. etc. then what shows up in the URL bar is not the server where the content is actually hosted. Well, it is the server where it is hosted, it's just one of the many domains hosted by that server.
- luckylion 8y ago
  That has never been different. Cloudflare & co are reverse proxies, for all intents and purposes from a user agent view, they are where the content is coming from. They are the ones pointed to in DNS, and they have valid SSL certs.
  - jedberg 8y ago
    And how is this all that much different? In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package. If anything, I'd have more faith in this changing my URL than a proxy via DNS. Just because Google invented it doesn't make it bad.
    - luckylion 8y ago
      > And how is this all that much different? It changes the meaning of the address bar from "this is who I'm talking to" to "this is who (at some point in time) signed this content".
      - jedberg 8y ago
        But when there is a CDN there, "who I'm talking to" is really just an intermediary who pretends to be you, and may have in fact modified the content. With this, it is still an intermediary pretending to be you, but at least now the package is signed and can be verified.
        luckylion 8y ago
        The CDN is you, for all intents and purposes. It's your agent in the back and forth, as much as your hosting provider would be. A third-party cache isn't. I don't mind that you can sign and verify content, that's fine and useful. I'm just not a fan of changing the address bar's meaning.
        jedberg 8y ago
        But what I'm saying is that the meaning that you ascribe to the address bar is incorrect -- it already only tells you who published the content, not who you are actually connected to. What I'm saying is that this does not change the meaning of what's in the URL bar. It's the same as before. It tells you who published the content originally.
        luckylion 8y ago
        > it already only tells you who published the content No, it tells you the origin of the document. If you are the creator, and you choose to put your content on server X it will tell you "I've got this from server X". Whether that server is a reverse proxy or a shared webhost or a dedicated server in a DC or a raspberry pi running on your desk doesn't matter - it's the designated original that you, the owner of example.org chose. That's what it always meant, and it changes when you do a redirect, and it shows you the current URL even if there is a canonical header of http-equiv. I can put a reverse proxy on my host and proxy example.com to example.org - the address bar tells you that you're reading example.com, not example.org, as it should, because you're connected to me, not to example.org.
    - lol768 8y ago
      > In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package How is it more secure? If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package".
      - jefftk 8y ago
        > If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package". Spoofing DNS to clients is much easier than spoofing DNS to certificate authorities. Otherwise domain-validated HTTPS certs wouldn't mean much.
dwild 8y ago
This is just semantic. Do a trace route on any domain and you'll see that the server isn't the one that give you the answer, but some intermediary. Sure in that case when you did the request, the content is fresh and the server answered RIGHT NOW, but that cache still get the content from the server, it's just a bit older.

by sandov 8y ago

jedberg 8y ago

> Showing the name of the "signer" in the address bar, instead of the server where the content is actually hosted goes against decades of browser UI design Does it though? If you use Cloudflare or Akamai or Cloudfront or Netlify or etc. etc. then what shows up in the URL bar is not the server where the content is actually hosted. Well, it is the server where it is hosted, it's just one of the many domains hosted by that server.

luckylion 8y ago
That has never been different. Cloudflare & co are reverse proxies, for all intents and purposes from a user agent view, they are where the content is coming from. They are the ones pointed to in DNS, and they have valid SSL certs.
- jedberg 8y ago
  And how is this all that much different? In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package. If anything, I'd have more faith in this changing my URL than a proxy via DNS. Just because Google invented it doesn't make it bad.
  - luckylion 8y ago
    > And how is this all that much different? It changes the meaning of the address bar from "this is who I'm talking to" to "this is who (at some point in time) signed this content".
    - jedberg 8y ago
      But when there is a CDN there, "who I'm talking to" is really just an intermediary who pretends to be you, and may have in fact modified the content. With this, it is still an intermediary pretending to be you, but at least now the package is signed and can be verified.
      - luckylion 8y ago
        The CDN is you, for all intents and purposes. It's your agent in the back and forth, as much as your hosting provider would be. A third-party cache isn't. I don't mind that you can sign and verify content, that's fine and useful. I'm just not a fan of changing the address bar's meaning.
        jedberg 8y ago
        But what I'm saying is that the meaning that you ascribe to the address bar is incorrect -- it already only tells you who published the content, not who you are actually connected to. What I'm saying is that this does not change the meaning of what's in the URL bar. It's the same as before. It tells you who published the content originally.
        luckylion 8y ago
        > it already only tells you who published the content No, it tells you the origin of the document. If you are the creator, and you choose to put your content on server X it will tell you "I've got this from server X". Whether that server is a reverse proxy or a shared webhost or a dedicated server in a DC or a raspberry pi running on your desk doesn't matter - it's the designated original that you, the owner of example.org chose. That's what it always meant, and it changes when you do a redirect, and it shows you the current URL even if there is a canonical header of http-equiv. I can put a reverse proxy on my host and proxy example.com to example.org - the address bar tells you that you're reading example.com, not example.org, as it should, because you're connected to me, not to example.org.
  - lol768 8y ago
    > In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package How is it more secure? If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package".
    - jefftk 8y ago
      > If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package". Spoofing DNS to clients is much easier than spoofing DNS to certificate authorities. Otherwise domain-validated HTTPS certs wouldn't mean much.

dwild 8y ago

This is just semantic. Do a trace route on any domain and you'll see that the server isn't the one that give you the answer, but some intermediary. Sure in that case when you did the request, the content is fresh and the server answered RIGHT NOW, but that cache still get the content from the server, it's just a bit older.