4 ms·
They mention it has been a complex undertaking and not complete yet - does anyone know why they can't just sit a traffic manager in front of everything with SSL
by mtkd 10y ago
They mention it has been a complex undertaking and not complete yet - does anyone know why they can't just sit a traffic manager in front of everything with SSL offloading?
Also does anyone know what the new personalisation features are that they mention being able to offer now HTTPS in place?
- hannob 10y agoThird party content. You have ad providers that won't agree to you delivering their content. They want to keep control over that (which is by the way a huge security risk on its own, but that's the state of things).
- kaspm 10y agoThis is likely an organizational, rather than a technical problem. Having worked for large media organizations, often different parts of the site are different deployable applications that share only a hardware device or small nginx or haproxy layer if they're on the same subdomain. It may be that in order to enable SSL on all parts of nytimes.com you need to affect ssl termination at a higher layer on a number of different servers/deploy locations which requires time and testing. It's also possible that terminating the SSL and then passing through unsecured traffic lower in the stack is not ideal due to where the different parts of the site are hosted - e.g. passing traffic unsecured back and forth between private DC and public cloud. Note: All speculation based on having implemented SSL migrations at large media companies.
- Ajedi32 10y ago> Also does anyone know what the new personalisation features are that they mention being able to offer now HTTPS in place? Not sure what features the NYT is referencing specifically, but Chrome has certain features [like the Geolocation API][1] disabled for pages loaded over HTTP. See [Deprecating Powerful Features on Insecure Origins][2]. [1]: https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only https://developers.google.com/web/updates/2016/04/geolocatio... [2]: https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins https://www.chromium.org/Home/chromium-security/deprecating-...
- yvan 10y agoFor our media website, it took us one year before we could move to HTTPS, mainly because of the AdServers which wasn't ready. We had to talk to each ad provider in order to ask them to upgrade to HTTPS. Unfortunately as media companies have most of their revenue from ads you just can't switch like that. Also, features that are now available once the HTTPS by default on a website, is the AMP, Notifications, HTTP2 (faster loading) and, of course, the little advantage that Google gives to the HTTPS websites.
- _ak 10y agoGoogle started the process of enforcing HTTPS on AdX about 2.5 years ago. Not implementing HTTPS in that large timeframe is rather inexcusable. It's just technical debt that you need to acknowledge, and then get rid of it.
- yvan 10y agoNowadays an Ad Server can call another one and so one, due to programmatic. So you might have one Ad server enforcing and serving their tags in HTTPS, but in the end the little local Ad Server which is part of a bigger network doesn't have the HTTPS and so his material isn't delivered.
- whorleater 10y agoAccording to WaPo's move to HTTPS blog post: >Ask any developer at a major media organization what the biggest hurdle to HTTPS adoption is, and the answer is always going to be advertising. However, unless you understand the ins-and-outs of how digital advertising is implemented, it’s difficult to see why this presents a challenge. from https://developer.washingtonpost.com/pb/blog/post/2015/12/10/moving-the-washington-post-to-https/ https://developer.washingtonpost.com/pb/blog/post/2015/12/10...
- _ak 10y agoFortunately, even that is changing. Google forced advertisers who want to buy inventory through AdX to switch their creatives to HTTPS in 2015 already. In my experience, any non-compliance to that comes from shitty agencies that haven't gotten the memo that you're better off just switching everything to HTTPS these days.
- justinph 10y agoAt any large media organization, there are tremendous amounts of content no longer connected to any CMS that may have hard-coded insecure links/resources in them. Some of them may live on obscure servers or domains. Or the developers/journalists who worked on them and have knowledge of their construction are long gone. These pages are very laborious to find and update. If you don't mind 404ing or breaking a ton of your old content, it's probably not too difficult. But if you're the newspaper of record, it's a big deal that URLs live on and continue to work as expected.
- kelnos 10y agoYou also mention "insecure resources", wich I think is a big deal too. I'd imagine there'd be the oddA hard-coded http link to an image that serves an important purpose to an article... that suddenly going missing because a browser refuses to load it would be bad. But I think you hit the nail on the head -- being the "newspaper of record" means you want to ensure that all your content displays like it did the day it was published.
- fjdlwlv 10y agoHTTP URLs redirect to HTTPS
- yvan 10y agoWell, in our case that was the easiest thing to pick, thanks to the Report-Only option on the CSP header, we enabled it and in about a week, we got all our insecure links and resources. We could also set a header forcing the browser to upgrade to secure when the resources are in the same domain.
- fjdlwlv 10y agoHTTP URLs redirect to HTTPS, done. That's a basic step of turning on HTTPS