Hacker News new | past | comments | ask | show | jobs | submit login

My point is that even if you look at the URL bar currently and it says company.com, you don't know what you're connecting to. Probably you're connecting to CloudFlare/CloudFront/Akamai/Fastly/any other CDN which is set up with good-enough certs to impersonate the domain. Therefore you're not trusting a particular server, you're trusting a relationship that the domain owner built with her's service providers.

The proposed scheme is just another way to extend this kind of relationship that the publisher builds, a new mechanism if you will. There is nothing in there that requires more or less trust from your part than before.

You're complaining that need URLs to reflect what is requested - in fact, I argue that you want the URL to tell you what is being served. But this is not what's currently happening.

URLs are already lying to you.

I doubt that you WHOIS-lookup all DNS resolved-IPs to verify that the IP presenting a cert is assigned to the organisational entity that you want to connect to, and have a whitelist of those entities that you actually allow your browser to connect to. Because that's what currently required to make sure you don't go through CDNs and other intermediaries between you and the publisher.




Using a CDN currently means the company use trusted mechanisms like DNS to delegate certain traffic to other providers (like with Cloudflare). And it does so for everyone.

In which case the URL serves what was requested.

What AMP does is provide google.com content and lie to the user and says it comes from company.com.

Which isn’t true, and it only does so for users coming from google.com. Where I’m sure google will be happy for the additional tracking data.

This is NOT the url the user was lead to believe he requested. This is not what everyone else is served.

This is malware.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: