| Well thanks for your reply , i still think sxg breaks semantics. > Browsers "pretend" exactly this every time they download a page via HTTPS. yeah and the big scary warnings are for the connection, not the content. currently browsers tie url host to DNS so the semantics are different, so the cert certifies the distributor. I also think this is only true for certs that don't have an organization name, at least i think that , for extended-validation SSL they still show this: https://upload.wikimedia.org/wikipedia/commons/6/63/Firefox_... > and they appear to attribute an app to the creator, not Apple, Inc. indeed , i meant that they attribute the app to Apple Inc as the creator, but not their domain, which is again, different semantics. (although i suppose apple is somehow involved in ensuring that the correct binary is distributed for every developer) > Why should only the 3-4 big corporates i m obviously not saying they should , but that it's not analogous situation, with their walled gardens and all. the web is nobody's a walled garden and a large part of the content is public domain which doesnt need any signing. that s why app store logic doesnt apply. > reduces single points of failure that 's what software hosts already do with providing hashes for binaries. and it's great that sxg can verify content through the browser. but it shows where the content was created, not where it was distributed , thats why i think it's wrong to change the URL there is also a laundry list of dangers that they introduce that seem pretty serious for something that is being pushed forward for basically cosmetic reasons: https://blog.intelx.io/2019/04/15/a-new-type-of-http-client-... |
