3 ms·

Is it more of an ugly hack than forcing arbitrary sites to https based on a list that's partially hard-coded, partially user-specified, and partially added thro

Is it more of an ugly hack than forcing arbitrary sites to https based on a list that's partially hard-coded, partially user-specified, and partially added through an HSTS header in which case the entry also has a limited lifespan? Ugly hacks to make the web even marginally more safe by encouraging or forcing use of https (in places it isn't explicitly specified) may be worthwhile. The thread's chrome hack alone reduces the usability of https, to the point of (I would guess) encouraging sites to use http and disable https so that visitors can actually see embedded content. Average web users know nothing of https, but if they happen across a site using https and embedded content doesn't show up, they'll blame the site. Certainly _that_ is not good. If this google hack is truly worth the pain, and even a small fraction of embedded content works with the uri changed from http to https, that's a benefit because it makes https more usable. Would you think the same about simply changing the HSTS header so that sites could tell a browser to force loading all embedded http:// http:// content through https:// https://? It seems to me like Google's long-term goal is to encourage tls everywhere. If all sites that have user accounts (thus logins) are using https, and all content embedded on those sites has to be referenced over https (or another secure protocol), that's probably the bulk of the web. So the long term costs (in the far future) are an irrelevant cruft of a hack that ends up doing nothing because there are no http:// http:// resource links anywhere. A hack which could, at that point, be removed with no impact whatsoever.

gst 15y ago
HSTS (even with the embedded list) only works if the website operator opts-in. Just one example where your suggestion might break sites: Let's assume a site hosts non-SSL content on www.example.com and SSL content on example.com. Now the site want's to default to SSL by changing most of the links and by automatically redirecting every non-SSL www.example.com request to a SSL secure.example.com. For "traditional" browsers this approach would work fine: Even if non-SSL resources are linked users are redirected to the right place. With the new Chrome approach chrome might block some of the content, but makes it clear why this was done. Users can also override this block (at least for now). With your suggestion this page will break as the browser tries to access the SSL version at www.example.com, which might not exist, or which might not have a correct certificate. Granted, this is just one example, and there are other cases where this approach might work fine. But the Web is just too complex to predict how such hacks will work out. I cannot think of a single such hack that did not create long term problems eventually.

gst 15y ago

HSTS (even with the embedded list) only works if the website operator opts-in. Just one example where your suggestion might break sites: Let's assume a site hosts non-SSL content on www.example.com and SSL content on example.com. Now the site want's to default to SSL by changing most of the links and by automatically redirecting every non-SSL www.example.com request to a SSL secure.example.com. For "traditional" browsers this approach would work fine: Even if non-SSL resources are linked users are redirected to the right place. With the new Chrome approach chrome might block some of the content, but makes it clear why this was done. Users can also override this block (at least for now). With your suggestion this page will break as the browser tries to access the SSL version at www.example.com, which might not exist, or which might not have a correct certificate. Granted, this is just one example, and there are other cases where this approach might work fine. But the Web is just too complex to predict how such hacks will work out. I cannot think of a single such hack that did not create long term problems eventually.