Re:The Guardian has moved to HTTPS
by simmons on Tuesday November 29, 2016 @11:20AM
(#13063970)
It's always good to see more web sites switching to HTTPS. I can't help thinking about something I read on Twitter a couple of years ago, and I wonder if they are mitigating the risk:
Re:The Guardian has moved to HTTPS
by sihil on Tuesday November 29, 2016 @12:31PM
(#13064507)
An interesting attack and something that we'll consider. HTTP/2 should add a significant amount of noise to this, but ultimately adding random padding to every response or padding that compresses to a consistent length would be the best solution.
Re:The Guardian has moved to HTTPS
by zigzigzag on Tuesday November 29, 2016 @04:57PM
(#13066588)
The important thing to hide on news sites is not so much what you're reading (who cares, it's public news and clicking through a link means nothing), but rather hiding your username for the comments section.
Re:The Guardian has moved to HTTPS
by andy_ppp on Tuesday November 29, 2016 @11:01AM
(#13063830)
I am slightly worried that a lot of public Wifi seems to be unable to redirect you to the login page (think Starbucks) if you visit https:// sites. The Guardian was my go-to for such situation so that I could login and get online.
I'm not sure how these redirects work (DNS? Inserting JS into the page?) but it seems to be a common problem.
Re:The Guardian has moved to HTTPS
by Ajedi32 on Tuesday November 29, 2016 @11:10AM
(#13063911)
They usually work by MITMing your connection to whatever site you're trying to visit and serving an HTTP redirect (maybe 307?) to the captive portal page.
Re:The Guardian has moved to HTTPS
by robin_reala on Tuesday November 29, 2016 @11:25AM
(#13064011)
I’d be surprised if example.com goes https-only. Regardless, if all sites go https only then free wifi providers will have to come up with some other way of redirecting you to their signup page.
Re:The Guardian has moved to HTTPS
by wildmusings on Tuesday November 29, 2016 @11:28AM
(#13064024)
There seems to be some protocol by which operating systems automatically launch the login page upon connecting to the WiFi network. Unfortunately, it seems to fail pretty often and probably doesn't work for bridged connections.
Re:The Guardian has moved to HTTPS
by JimDabell on Tuesday November 29, 2016 @11:43AM
(#13064140)
There's no standard protocol in widespread use. Typically operating systems attempt to fetch a known resource when connecting to a new Wi-Fi network, and if it redirects, then they treat the destination as the captive portal sign-in page and display it with special chrome / modally. The URL each platform attempts to load varies by vendor and version.
Re:The Guardian has moved to HTTPS
by ethagnawl on Tuesday November 29, 2016 @12:02PM
(#13064291)
Do you have any links to resources or know what name(s) people use when talking about this strategy? I'd be interested to know which URL Debian attempts to fetch, but I'm not sure how I'd even begin to search for the answer.
Re:The Guardian has moved to HTTPS
by brainfire on Tuesday November 29, 2016 @11:49AM
(#13064188)
My understanding is that this is just the OS trying to fetch a known page over HTTP and, if redirected, assuming it got a login portal and presenting it to the user.
I assume this can continue "working" (with your noted caveat that it doesn't even always work today) forever, as the process that checks doesn't need to understand HSTS or to ever try HTTPS, regardless of what actual web browsers start doing.
Re:The Guardian has moved to HTTPS
by rcthompson on Tuesday November 29, 2016 @11:51AM
(#13064202)
Basically, they try to phone home and if it redirects, they assume it's a captive portal login page. It's a sort of controversial practice, because it means that the OS vendor now always knows where and when you're accessing the internet.
Re:The Guardian has moved to HTTPS
by libeclipse on Tuesday November 29, 2016 @11:41AM
(#13064120)
On Nougat it seems to work flawlessly most of the time. I wonder what the protocol is. Maybe a request to the access point's DNS server to see what IP is returned and then connect to that?
Re:The Guardian has moved to HTTPS
by epmatsw on Tuesday November 29, 2016 @11:19AM
(#13063963)
Ran into this with Southwest's wifi this week. HSTS preloading makes it worse too. No dice with Google, Facebook, my website, etc. Just lots of error pages until I figured out what was going wrong.
Re:The Guardian has moved to HTTPS
by moreira on Tuesday November 29, 2016 @10:07AM
(#13063435)
The more websites on HTTPS the merrier. It's interesting that they mention being able to use new HTML/JS features that are now only available over HTTPS. That's one way to push more people for HTTPS even if they don't care about the privacy/security reasons.
Re:The Guardian has moved to HTTPS
by LeoPanthera on Tuesday November 29, 2016 @10:11AM
(#13063465)
So what's involved in compromising a site using HTTPS? Off the top of my head, you would have to have control over a trusted CA, and the ability to MITM a connection to the site. Probably not plausible for bedroom hackers, but seems trivial for state actors.
Do browsers offer any kind of certificate pinning for arbitrary sites? It seems strange that this is a default feature in ssh but not https.
Re:The Guardian has moved to HTTPS
by dogma1138 on Tuesday November 29, 2016 @10:13AM
(#13063477)
HTTPS doesn't provide any protection to the website, it can hinder MITM attacks against modern browsers and aware users, but it doesn't reduce the attack surface on the website (in fact it actually increases it).
As for certificate pinning, some browser do e.g. I'm pretty sure that Chrome has certificate pinning for at least some google services.
Also HSTS with HPKP (HTTP Public Key Pinning) can be used to further increase the resilience of HTTPS services against MITM attacks (both local and network adjacent).
That said if an adversary is capable of doing even basic network adjacent attacks they can still do a redirection via DNS which is why it's important to not have HTTP support only or have a fully enforced redirect which will likely to get the target stuck on a redirect loop.
For DNS redirection attacks all they need to do is to be faster than the DNS responder or poison the local DNS cache.
Re:The Guardian has moved to HTTPS
by sihil on Tuesday November 29, 2016 @12:48PM
(#13064656)
At some (hopefully in about a year) we hope to list theguardian.com in the preloaded HSTS list that ships with the browsers. This would prevent many of these attacks. Unfortunately this is some time away as there are a handful of other subdomains on theguardian.com that are not yet HTTPS (you can only preload a domain along with all of its subdomains).
We'll also continue to look at key pinning, although that's also some time away due to the increased burden of certificate management (essentially we'd need to have at least two valid certificates, one kept offline, at all times to mitigate against another heartbleed or similar attack).
Re:The Guardian has moved to HTTPS
by pimterry on Tuesday November 29, 2016 @11:09AM
(#13063906)
> HTTPS stops MITM except for nation-state attackers.
Technically yes, but in practice no.
Sure, you can't MITM a running HTTPS connection. But in HTTPS without HSTS it's easy to transparently stop users getting to HTTPS in the first place, and unless they reliably check the URL bar and verify they have a cert and exactly the right domain then that gives you almost as much damage as a MITM, super easily. We can all agree that users are terrible at constant vigilance, and attacks like this are surprisingly practical.
MITMing HTTPS sites that you browse to directly:
* You type "site-without-hsts.com" into your URL bar.
* Your browser makes an initial plain HTTP request to site-without-hsts.com, and instead of getting an HTTPS redirect I MITM you, and just proxy the plain HTTP to the real HTTPS-only site.
* I see and/or change everything on your 'secure' site. Game over.
301's sort-of protect you here, but a) you don't want to user security to depend on browser caching, b) that doesn't work for the first load of a site, and c) if I'm running a wifi hotspot, it's reasonably easy to get people to clear their caches before you let them log in, since it's a fairly standard technical fix now.
Alternatively, MITMing HTTPS sites reached through some other page:
* You load any plain HTTP page while browsing, on route to a secure site.
* I MITM the plain HTTP, replace 'https' with 'http' in all links in the page, and MITM every subsequent page as above, proxying through to real HTTPS sites where required.
* I see and/or change everything on your 'secure' site. Game over.
Functionally, if you have any insecure step in your browser session, I can stop you reaching the secure step, and if you're not carefully paying attention you won't notice. Sometimes, sure, you might, but most of the time you won't, and 99.9999% of the time your average computer user won't ever check. HTTPS coverage is getting better, but I suspect the vast majority of browsing sessions still go through an insecure step somewhere along the pipeline.
HTTPS doesn't fully protect your users from MITMs. Add HSTS though (so the browser will refuse to ever make a plain HTTP request to your HTTPS site), and you get substantially closer.
Re:The Guardian has moved to HTTPS
by dogma1138 on Tuesday November 29, 2016 @10:21AM
(#13063537)
On the website?
An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys).
All and all you now have a greater attack surface as an entity, it doesn't mean that you shouldn't use HTTPS, but as far as risk management goes things change.
You as a user aren't affected unless you erroneously implicitly trust encrypted traffic considerably more than unencrypted one.
HTTPS also doesn't stops MITM attacks from non-state actors.
People trust untrusted certificates, the certificate supply chain can be easily poisoned as time and time again we've seen that everyone and their mother managed to make CA's issue certificates under false pretences or otherwise erroneously and DNS / packet racing attacks still can work unless the website implements HTTPS strictly.
Re:The Guardian has moved to HTTPS
by zeta0134 on Tuesday November 29, 2016 @10:38AM
(#13063657)
I don't buy that unencrypted traffic is equally trustworthy.
Encrypted traffic cannot easily be snooped by a man in the middle. It's arguably the entire point of HTTPS. With HTTP, I have no hints, much less guarantees, that the website I'm talking to is actually who it says it is. There is no mechanism whatsoever to establish trust, and my traffic is up for easy analysis.
HTTPS may not fix that problem completely (CAs are the biggest weak point) but it does wonders to solve MITM type snooping of my traffic (a boon to me, as a user) and has the mechanisms in place for me to inspect the certificate chain if I need to be sure of the server I'm communicating with. I agree with a great many of your criticisms against the standard and feel like CAs in particular need to be re-thought, but don't dismiss the entire technology because you assume that the "user" is too stupid to know how to use it.
Re:The Guardian has moved to HTTPS
by dogma1138 on Tuesday November 29, 2016 @10:39AM
(#13063662)
>I don't buy that unencrypted traffic is equally trustworthy.
Neither do I, which is why I never made any such claims. Encrypted traffic even in ideal circumstances can and is equally untrustworthy especially under certain threat models ;)
Re:The Guardian has moved to HTTPS
by witty_username on Tuesday November 29, 2016 @10:32AM
(#13063615)
> An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys).
If these things are attacked, your security is not worse than HTTP.
Re:The Guardian has moved to HTTPS
by dogma1138 on Tuesday November 29, 2016 @10:35AM
(#13063638)
Again you are talking about 2 different attack vectors here, the GP was talking about compromising the website, an attack against the traffic between the website and the client does not compromises the website in any case.
And no if these things are attacked, at least as far as the library goes things aren't no worse than HTTP because it's a completely different threat scenario which can actually compromise the website/host rather than just poison a single client session.
For example https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6309 which poentially allows for RCE if you use a vulnerable version of OpenSSL exposes your website to completely different threats than if you would only use HTTP, not worse, not better just an additional and quite different threat.
This is why when you implement HTTPS or any other additional service you need to understand how it changes the attack surface of your service from both a technical and operational perspective.
Re:The Guardian has moved to HTTPS
by pmoriarty on Tuesday November 29, 2016 @11:06AM
(#13063882)
"what's involved in compromising a site using HTTPS?"
It just takes the user clicking through some scary prompts, which they'll do if they're unconcerned or desperate enough to get to whatever website they're trying to reach.
Re:The Guardian has moved to HTTPS
by pimterry on Tuesday November 29, 2016 @11:19AM
(#13063964)
> It just takes the user clicking through some scary prompts
If you turn on HSTS, you actually stop this completely. Chrome and Firefox will not allow you to click through the prompt for an HSTS site - you're just blocked.
Re:The Guardian has moved to HTTPS
by sihil on Tuesday November 29, 2016 @12:43PM
(#13064593)
Our HSTS header is set with an expiry of a year. Provided you've visited the Guardian in the last year then you will not be able to click through an invalid certificate, nor can an attacker intercept an HTTP connection as none will be made.
At some stage we hope to list theguardian.com in the preloaded HSTS list that ships with the browsers, but unfortunately this is some time away as there are a handful of other subdomains on theguardian.com that are not yet HTTPS (you can only preload a domain along with all of its subdomains).
Re:The Guardian has moved to HTTPS
by thinkMOAR on Tuesday November 29, 2016 @10:26AM
(#13063574)
"The reasons for our move"
If they wrote this 5+ years ago, kudos. Now, today... seems a bit like a very bad (and very late) ad campaign or excuse.. And in all fairness, it could have summarized, as 'we cared more about money then serving https to our readers'
Re:The Guardian has moved to HTTPS
by mgbmtl on Tuesday November 29, 2016 @11:03AM
(#13063848)
As far as I know, they are one of the few big media outlets to support https. So yes, this should have been done earlier, but kudos to them for pioneering this in their field and for publishing a short instruction manual for whoever else is planning this.
I'm not surprised that they are worried about the financial impact of https on their (very modest) revenue. It's a big investment for an industry struggling financially.
Re:The Guardian has moved to HTTPS
by thinkMOAR on Wednesday November 30, 2016 @03:55AM
(#13069354)
I don't consider a SSL certificate as a big investment? There is no ROI on ssl usage. Nor do they break the bank; There is a 'not running away because you don't' return, which in the end hurt more. NY times SSL capable since 2014, also late, but already 2 years earlier then this website.
Re:The Guardian has moved to HTTPS
by 0xmohit on Tuesday November 29, 2016 @10:42AM
(#13063680)
The primary reason is SEO:
It also gives us other benefits such as a potential increase in
search results. For the reasons mentioned above Google has
announced that it will favour https content. It is also helping
us decipher traffic from secure and ‘unknown’ referrers.
Re:The Guardian has moved to HTTPS
by devy on Tuesday November 29, 2016 @12:04PM
(#13064307)
The Guardian uses Fastly CDN as a result the TLS certificate is Fastly's SAN certificate, which also has over 150+ DNS entries to cover. Just thought it's interesting to point out.
Re:The Guardian has moved to HTTPS
by noir-york on Wednesday November 30, 2016 @06:07PM
(#13075529)
Interesting that you believe that they've moved right. I sorta think they've (particularly the opinion pages) moved left, especially with regards to social issues.
> I guess that probably says something about our politics too
I was gonna agree with you and then I thought that in fact, it should be possible to place someone's politics on a scale that is independent of the observer. Keynesian is to the left of supply-side economics for instance. Social issues are on their own scale.
"I'm all in favor of news sites using HTTPS, but I assume they're also going to pad all their articles to a uniform length?" -- https://twitter.com/matthew_d_green/status/53504312624809574...
I'm not sure how these redirects work (DNS? Inserting JS into the page?) but it seems to be a common problem.
As a substitute for The Guardian, maybe try http://example.com?
And here's your answer: http://network-test.debian.org/nm
I assume this can continue "working" (with your noted caveat that it doesn't even always work today) forever, as the process that checks doesn't need to understand HSTS or to ever try HTTPS, regardless of what actual web browsers start doing.
Do browsers offer any kind of certificate pinning for arbitrary sites? It seems strange that this is a default feature in ssh but not https.
As for certificate pinning, some browser do e.g. I'm pretty sure that Chrome has certificate pinning for at least some google services.
Also HSTS with HPKP (HTTP Public Key Pinning) can be used to further increase the resilience of HTTPS services against MITM attacks (both local and network adjacent).
That said if an adversary is capable of doing even basic network adjacent attacks they can still do a redirection via DNS which is why it's important to not have HTTP support only or have a fully enforced redirect which will likely to get the target stuck on a redirect loop.
For DNS redirection attacks all they need to do is to be faster than the DNS responder or poison the local DNS cache.
We'll also continue to look at key pinning, although that's also some time away due to the increased burden of certificate management (essentially we'd need to have at least two valid certificates, one kept offline, at all times to mitigate against another heartbleed or similar attack).
How does it increase the attack surface?
Technically yes, but in practice no.
Sure, you can't MITM a running HTTPS connection. But in HTTPS without HSTS it's easy to transparently stop users getting to HTTPS in the first place, and unless they reliably check the URL bar and verify they have a cert and exactly the right domain then that gives you almost as much damage as a MITM, super easily. We can all agree that users are terrible at constant vigilance, and attacks like this are surprisingly practical.
MITMing HTTPS sites that you browse to directly:
* You type "site-without-hsts.com" into your URL bar. * Your browser makes an initial plain HTTP request to site-without-hsts.com, and instead of getting an HTTPS redirect I MITM you, and just proxy the plain HTTP to the real HTTPS-only site. * I see and/or change everything on your 'secure' site. Game over.
301's sort-of protect you here, but a) you don't want to user security to depend on browser caching, b) that doesn't work for the first load of a site, and c) if I'm running a wifi hotspot, it's reasonably easy to get people to clear their caches before you let them log in, since it's a fairly standard technical fix now.
Alternatively, MITMing HTTPS sites reached through some other page:
* You load any plain HTTP page while browsing, on route to a secure site. * I MITM the plain HTTP, replace 'https' with 'http' in all links in the page, and MITM every subsequent page as above, proxying through to real HTTPS sites where required. * I see and/or change everything on your 'secure' site. Game over.
Functionally, if you have any insecure step in your browser session, I can stop you reaching the secure step, and if you're not carefully paying attention you won't notice. Sometimes, sure, you might, but most of the time you won't, and 99.9999% of the time your average computer user won't ever check. HTTPS coverage is getting better, but I suspect the vast majority of browsing sessions still go through an insecure step somewhere along the pipeline.
HTTPS doesn't fully protect your users from MITMs. Add HSTS though (so the browser will refuse to ever make a plain HTTP request to your HTTPS site), and you get substantially closer.
I agree with you.
An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys).
All and all you now have a greater attack surface as an entity, it doesn't mean that you shouldn't use HTTPS, but as far as risk management goes things change.
You as a user aren't affected unless you erroneously implicitly trust encrypted traffic considerably more than unencrypted one.
HTTPS also doesn't stops MITM attacks from non-state actors. People trust untrusted certificates, the certificate supply chain can be easily poisoned as time and time again we've seen that everyone and their mother managed to make CA's issue certificates under false pretences or otherwise erroneously and DNS / packet racing attacks still can work unless the website implements HTTPS strictly.
Encrypted traffic cannot easily be snooped by a man in the middle. It's arguably the entire point of HTTPS. With HTTP, I have no hints, much less guarantees, that the website I'm talking to is actually who it says it is. There is no mechanism whatsoever to establish trust, and my traffic is up for easy analysis.
HTTPS may not fix that problem completely (CAs are the biggest weak point) but it does wonders to solve MITM type snooping of my traffic (a boon to me, as a user) and has the mechanisms in place for me to inspect the certificate chain if I need to be sure of the server I'm communicating with. I agree with a great many of your criticisms against the standard and feel like CAs in particular need to be re-thought, but don't dismiss the entire technology because you assume that the "user" is too stupid to know how to use it.
Neither do I, which is why I never made any such claims. Encrypted traffic even in ideal circumstances can and is equally untrustworthy especially under certain threat models ;)
If these things are attacked, your security is not worse than HTTP.
HPKP and HSTS fix the problems you've described.
And no if these things are attacked, at least as far as the library goes things aren't no worse than HTTP because it's a completely different threat scenario which can actually compromise the website/host rather than just poison a single client session.
For example https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6309 which poentially allows for RCE if you use a vulnerable version of OpenSSL exposes your website to completely different threats than if you would only use HTTP, not worse, not better just an additional and quite different threat.
This is why when you implement HTTPS or any other additional service you need to understand how it changes the attack surface of your service from both a technical and operational perspective.
It just takes the user clicking through some scary prompts, which they'll do if they're unconcerned or desperate enough to get to whatever website they're trying to reach.
If you turn on HSTS, you actually stop this completely. Chrome and Firefox will not allow you to click through the prompt for an HSTS site - you're just blocked.
At some stage we hope to list theguardian.com in the preloaded HSTS list that ships with the browsers, but unfortunately this is some time away as there are a handful of other subdomains on theguardian.com that are not yet HTTPS (you can only preload a domain along with all of its subdomains).
This is actually an enormous percentage of users. Google's research on real live Chrome users suggests up to 70% of those big full page HTTPS security warnings are being clicked through: http://static.googleusercontent.com/media/research.google.co...
Ivan puts it better than me: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-ke...
Still getting a 50/100... somehow that's a "C" on the Mozilla curve.
If they wrote this 5+ years ago, kudos. Now, today... seems a bit like a very bad (and very late) ad campaign or excuse.. And in all fairness, it could have summarized, as 'we cared more about money then serving https to our readers'
I'm not surprised that they are worried about the financial impact of https on their (very modest) revenue. It's a big investment for an industry struggling financially.
http://www.bbc.co.uk/blogs/internet/entries/f6f50d1f-a879-49...
> I'm not surprised that they are worried about the financial impact of https on their (very modest) revenue.
I don't see anything to that effect in the article.
$ openssl s_client -connect theguardian.com:443 | openssl x509 -noout -text | grep 'DNS:' | tr ', ' '\n' depth=1 /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 verify error:num=20:unable to get local issuer certificate verify return:0 DNS:i.ssl.fastly.net DNS:.am-autoparts.com DNS:.am-autopartsqa.com DNS:.i.ssl.fastly.net DNS:.s.tmol.io DNS:4ormat.com DNS:.4ormat.com DNS:500px.net DNS:.500px.net DNS:500px.org DNS:.500px.org DNS:abtasty.com DNS:.abtasty.com DNS:api.yerdle.com DNS:biomedcentral.com DNS:.biomedcentral.com DNS:bliyoo.bruna.nl DNS:cdn.mmgcache.net DNS:cleverbot.io DNS:.cleverbot.io DNS:collective-media.net DNS:.collective-media.net DNS:decalgirl.com DNS:.decalgirl.com DNS:engagesciences.com DNS:.engagesciences.com DNS:famous.co DNS:.famous.co DNS:fitbit.com DNS:.fitbit.com DNS:format.com DNS:.format.com DNS:github.app.secretcdn.net DNS:.github.app.secretcdn.net DNS:global-pop.tumblr.com DNS:.global-pop.tumblr.com DNS:goodeggs.com DNS:.goodeggs.com DNS:grindr.com DNS:.grindr.com DNS:guim.co.uk DNS:.guim.co.uk DNS:hackster.io DNS:.hackster.io DNS:harveynichols.com DNS:.harveynichols.com DNS:help.optimizely.com DNS:huevosbuenos.com DNS:.huevosbuenos.com DNS:img.society6.com DNS:.img.society6.com DNS:inverse.com DNS:.inverse.com DNS:kilmer.io DNS:.kilmer.io DNS:kindsnacks.com DNS:.kindsnacks.com DNS:learn.optimizely.com DNS:live.cf.public.springer.com DNS:.live.cf.public.springer.com DNS:logoscdn.com DNS:.logoscdn.com DNS:m.au.vjukebox.com DNS:m.ca.vjukebox.com DNS:m.uk.vjukebox.com DNS:m.us.vjukebox.com DNS:maps.tmol.co DNS:mapsapi.tmol.co DNS:mapsapi.tmol.io DNS:mapsint.tmol.co DNS:mapsintqa.tmol.co DNS:mapsqa.tmol.co DNS:meerkatapp.co DNS:.meerkatapp.co DNS:modafinilcat.com DNS:my.ticketmaster.ca DNS:offerpop.com DNS:.offerpop.com DNS:ogol.io DNS:.ogol.io DNS:optimizely.com DNS:performance.service.gov.uk DNS:.performance.service.gov.uk DNS:preview.performance.service.gov.uk DNS:.preview.performance.service.gov.uk DNS:production.performance.service.gov.uk DNS:.production.performance.service.gov.uk DNS:q-static.com DNS:.q-static.com DNS:qa.cashstar.com DNS:.qa.cashstar.com DNS:reissdev.com DNS:.reissdev.com DNS:s.sellocdn.com DNS:.s.sellocdn.com DNS:s2.tmol.co DNS:s2.tmol.io DNS:scanscout2.com DNS:.scanscout2.com DNS:screenshot.click DNS:.screenshot.click DNS:skedge.me DNS:.skedge.me DNS:snapshot.raintank.io DNS:spotfront.mathtag.com DNS:springer.com DNS:.springer.com DNS:squarecdn.com DNS:.squarecdn.com DNS:staging.performance.service.gov.uk DNS:.staging.performance.service.gov.uk DNS:static.awesomeom.com DNS:subscribe.theguardian.com DNS:teamtreehouse.com DNS:.teamtreehouse.com DNS:theguardian.com DNS:.theguardian.com DNS:timeout.cat DNS:.timeout.cat DNS:timeout.com DNS:.timeout.com DNS:timeout.es DNS:.timeout.es DNS:timeout.fr DNS:.timeout.fr DNS:timeoutkorea.kr DNS:.timeoutkorea.kr DNS:timeoutmexico.mx DNS:.timeoutmexico.mx DNS:u.sellocdn.com DNS:.u.sellocdn.com DNS:venue.tmol.co DNS:venue.tmol.io DNS:venueint.tmol.co DNS:venueqa.tmol.co DNS:vjukebox.com DNS:.vjukebox.com DNS:www.alarmgrid.com DNS:www.edgee.com DNS:www.freshbooks.com DNS:www.graspwise.com DNS:www.modafinilcat.com DNS:www.msdayofgiving.org DNS:www.neste.com DNS:www.optimizely.com DNS:www.optimizelystaging.com DNS:www.reiss.com DNS:www1.ticketmaster.ca DNS:www1.ticketmaster.com DNS:xkcd.com DNS:*.xkcd.com ^C
We're in the process of switching to a dedicated certificate that only contains Guardian properties.
Their news coverage is good (SportsDirect being a case in point). Its the opinion pages which makes me wonder.
I guess that probably says something about our politics too :-)
> I guess that probably says something about our politics too
I was gonna agree with you and then I thought that in fact, it should be possible to place someone's politics on a scale that is independent of the observer. Keynesian is to the left of supply-side economics for instance. Social issues are on their own scale.