Google Says 64 Percent of Chrome Traffic On Android Now Protected With HTTPS, 75 Percent On Mac, 66 Percent On Windows (techcrunch.com) 90
An anonymous reader quotes a report from TechCrunch: Google's push to make the web more secure by flagging sites using insecure HTTP connections appears to be working. The company announced today that 64 percent of Chrome traffic on Android is now protected, up 42 percent from a year ago. In addition, over 75 percent of Chrome traffic on both ChromeOS and Mac is now protected, up from 60 percent on Mac and 67 percent on ChromeOS a year ago. Windows traffic is up to 66 percent from 51 percent. Google also notes that 71 of the top 100 websites now use HTTPS by default, up from 37 percent a year ago. In the U.S., HTTPS usage in Chrome is up from 59 percent to 73 percent. Combined, these metrics paint a picture of fairly rapid progress in the switchover to HTTPS. This is something that Google has been heavily pushing by flagging and pressuring sites that hadn't yet adopted HTTPS.
Re: (Score:2)
Considering how expensive a Galaxy or other high-end Android device is, I doubt anyone using such a thing is using one because they can't afford a "real phone" (by which I assume you mean Apple)
Re: Surprised (Score:1)
Are you sure you're not somebody trying to make iPhone users seem like shitheads?
Well done! (Score:3)
Despite Google's other not so nice activities, I gotta give them a thumbs-up here. Getting the web to transition away from HTTP to HTTPS is fantastic. There's no reason for skimping on your web server anymore, encryption is easy and even crappy virutal machines can serve up HTTPS without issue. Good job Google.
As a side effect, this action they've promoted and encouraged mitigates the new WPA2 insecurity quite nicely. Not such a big deal if WPA2 is broken into, only to expose lots of HTTPS and/or VPN tunneling, and you're back to the drawing board. You just can't have enough security and layers of encryption.
Re: Well done! (Score:2, Insightful)
Yeah, its not like letsencrypt offering automated certificates for free had anything to do with it.
It was google showing a message about http being insecure.
Re: (Score:2)
Yeah, its not like letsencrypt offering automated certificates for free had anything to do with it.
It was google showing a message about http being insecure.
We might not like to admit that, but that is the truth of it. Sure Let's Encrypt is great, use it myself. But you can bet your wallet Let's Encrypt had little to do with this shift. People don't like being branded 'insecure.' It looks bad. It looks inferior. It looks... uhh.. Insecure. Google pushing that had a huge effect. A visible indication your site is a security risk. That is the motivator right there, not freebie certs, though they didn't hurt.
Re: (Score:2)
Google Scroogle (Score:1)
Yes, let's all thank Google for raising the energy and operations costs of servers and lowering the battery life of our devices.
This was a huge fuck-up by a big company who decided to double-down on trying to control the web. They only got away with it because Firefox was onboard with this screwing everyone.
Ever wonder why the advertised 12 hour battery life of your mobile device has dropped to 8 or 6 hours? This is why.
Re: (Score:2)
I have an old smartphone with no SIM card or Wi-Fi connection. Battery life is about 10 days. With Wi-Fi or network SIM card, it's a day.
Re: Google Scroogle (Score:1)
What do you do for ten days on an old smartphone with no simcard or wifi?
I have a favorite Solitaire app. I suppose I could play Angry Birds. Otherwise, if I had a smartphone with no connection to the outside world, I'd rather just use my old Palm III instead.
Re: (Score:2)
Uses it as a phone?
Re: (Score:2)
Ever wonder why the advertised 12 hour battery life of your mobile device has dropped to 8 or 6 hours? This is why.
On which device, and with which websites, have you benchmarked a battery life difference of this magnitude between cleartext HTTP and HTTPS? Because otherwise, I'm more inclined to blame the growth in both lithium dendrites and ad display script complexity for reduced battery capacity.
Re:Well done! (Score:5, Insightful)
Despite Google's other not so nice activities, I gotta give them a thumbs-up here. Getting the web to transition away from HTTP to HTTPS is fantastic. There's no reason for skimping on your web server anymore, encryption is easy and even crappy virutal machines can serve up HTTPS without issue. Good job Google.
You're too quick go give them credit. Follow the money trail. HTTPS and SPDY makes it far easier to ensure that ads are transmitted, and to whom. That HTTPS largely defeats anonymous proxy caching and other techniques that makes counting ad impressions harder is why Google pursues it; security is how they sell it, despite it being slower, to a high degree defeats bandwidth saving techniques, and requires extra resources on both server and client endpoints.
There's little reason why publicly available non-controversial information should be encrypted, and that makes up the majority of the web. Snooping traffic generally doesn't happen mid-transfer, but at the end point, by companies like Google and their partners. HTTPS does nothing to prevent that.
ISP ad injection (Score:2)
There's little reason why publicly available non-controversial information should be encrypted
For one thing, what you find non-controversial a third party may find controversial. For another, home ISPs such as Comcast can and do inject their own ads and other malware into cleartext HTTP connections.
Re: (Score:2)
yes they specifically inject adverts and show that your stream is not secure at all from MITM, the only way is to get rid of the Certificate Authorities who compromise everything...
Re: (Score:2)
I'm less worried about the interception of data in transit and more worried about the security of my data in many, many disparate databases at the far end. Nobody has yet addressed that to my satisfaction.
Re: (Score:2)
There's little reason why publicly available non-controversial information should be encrypted
We live in a world where the consumption of publicly available information is criminal. This isn't even limited to shithole dictator regimes, but now we are starting to see it in the west too.
The only person who can decide if it is important for the information to be encrypted is the person who stands to be persecuted for consuming it.
Re: (Score:2)
You're too quick go give them credit. Follow the money trail. HTTPS and SPDY makes it far easier to ensure that ads are transmitted, and to whom. That HTTPS largely defeats anonymous proxy caching and other techniques that makes counting ad impressions harder is why Google pursues it; security is how they sell it, despite it being slower, to a high degree defeats bandwidth saving techniques, and requires extra resources on both server and client endpoints.
I'm ok with this. Computing power is cheap and only getting cheap and better. Also don't like having third-party intermediaries caching my stuff. Bandwidth is cheap too. Who cares? Besides you.
There's little reason why publicly available non-controversial information should be encrypted, and that makes up the majority of the web.
You don't get it? Privacy. I really don't give a flying f if I'm looking a recipe for peanut butter cookies, it's no one elses business and HTTPS means you have no idea what I'm looking at, just which server.
Re: (Score:2)
You don't get it? Privacy. I really don't give a flying f if I'm looking a recipe for peanut butter cookies, it's no one elses business and HTTPS means you have no idea what I'm looking at, just which server.
Privacy is indeed the worry. With HTTPS, those who run the recipe site and their "partners" like Google knows who looked at the recipe for peanut butter cookies.
The biggest privacy problem isn't people sitting in the middle snooping on the traffic, but the remote endpoints collecting data on you. HTTPS makes that easier, which is why Google is all for it. It's not out of the goodness of their hearts and concern for anything but the advertising dollars.
Re: (Score:1)
the remote endpoints collecting data on you. HTTPS makes that easier
I am honestly curious: How does HTTPS make that easier?
Re: Well done! (Score:2)
Re: (Score:2)
Any one along the way can inject MiTM JavaScript attacks to benign html. They can replace images. They can replace content itself. They can do anything, and in many places they actually are doing it.
Sure, and I find that much less of a privacy problem than Google (and anyone who can serve Google a letter) building a complete dossier on what we surf. The difference between obtaining one datum and obtaining all data.
And get rate-limited by Let's Encrypt (Score:3)
There's no reason for skimping on your web server anymore, encryption is easy and even crappy virutal machines can serve up HTTPS without issue.
One reason is that your web server is private, and you don't own a domain.
In order to set up HTTPS traffic to the owner of a home router, printer, or NAS, its owner would first have to acquire a domain and a certificate for said device. But as I understand it, most providers of dynamic DNS on a subdomain without charge still aren't in the Public Suffix List. And if the domain in which your subdomain is registered hasn't completed the process to be added to the Public Suffix List, and 20 other customers on t
TXT editing; carrier-grade NAT (Score:2)
You can set up https from your ISP DNS name. (If it has one) mine is $ip.$isp
I thought you needed to be able to set up TXT records in order to use the ACME DNS challenge. I doubt an ISP lets a residential subscriber edit the domain's TXT records.
ACME also has an HTTP challenge, but you need to forward a port for that. This in turn means you need your own IP address, as opposed to carrier-grade NAT [wikipedia.org], and ISPs in less IPv4-rich countries tend to put residential subscribers behind carrier-grade NAT unless they're paying substantially more per month for "home business" service that inclu
Re: (Score:2)
If the webserver is for your own personal use - which, if it's on a residential connection and without domain name, is likely true - then you may as well just use self-signed.
Re: (Score:3)
This is a big time scam.
To
Re: (Score:2)
yes certificate authorities are the high risk and consolidate control neither of which you would want in a "secure" system
Is this to control who is allowed a Web site? (Score:2, Interesting)
If everyone needs a certificate, you can hold them back from people or invalidate them.
It just seems like the real reason for this, why should a cat meme site need https for example.
Re: (Score:1)
You can get free certs...
Re: (Score:2, Troll)
For how long? A year? Two years? Then how much will they cost?
Sorry, but this whole thing smacks of a corporate-induced tax. Google plays the part of the police here.
Re: Is this to control who is allowed a Web site? (Score:1)
It's about controlling the flow of Fake News and Hate Speech. Eventually Google wants to make it difficult to not connect to websites that are 'disapproved.' It migh be dangerous to go to that site Google doesn't like. Are you sure you want to connect to it?
Re: (Score:1)
For ever from let’s encrypt unless your domain expires.
For domain owners only (Score:2)
Per the CA/Browser Forum Baseline Requirements, Let's Encrypt is forced to banish you for either of the following reasons:
Re: (Score:2)
Some ads are more trusted than others
Re:Is this to control who is allowed a Web site? (Score:4, Informative)
why should a cat meme site need https for example
To protect the users of the cat meme site from malicious parties on the network between their browser and the cat meme site. I don't mean to keep the cat memes secret, obviously that doesn't matter much. The purpose is to ensure that the code executed by the user's browser is the code sent by the cat meme site, not something else intended to exploit browser vulnerabilities to hijack the user's computer.
For lots of sites we could use a TLS cipher suite that doesn't actually encrypt anything. It's the authenticity and integrity properties of TLS that are valuable for every site. Encryption only matters for some.
Re: (Score:3)
The purpose is to ensure that the code executed by the user's browser is the code sent by the cat meme site, not something else intended to exploit browser vulnerabilities to hijack the user's computer.
The cat meme site doesn't need to run javascript.
Then let me restate the spirit of swillden's comment for the noscript case:
The purpose is to ensure that the HTML markup, CSS code, image data, audio data, and video data interpreted by the user's browser is the HTML markup, CSS code, image data, audio data, and video data sent by the cat meme site, not something else intended to exploit browser vulnerabilities to hijack the user's computer.
Re: Is this to control who is allowed a Web site? (Score:1)
So the malware all comes from the main web domain, not scattered from all over. Okay.
The browser vulns still are the main problem. Massively restricting what the browser can connect to is a chickenshit kludge of a solution.
Re: (Score:2)
If you don't have an authenticated source for whatever you're receiving, you don't even know that the site you're seeing at a well-known URL is really the one you think it is. Your ISP, whoever is providing the WiFi you're borrowing at the coffee shop or on the train, your employer, or just some guy with the right gear to spoof the relevant infrastructure on whatever otherwise legitimate network you're connected to could be playing silly games.
As swillden says, in order to prevent this you need to be able t
Re: Is this to control who is allowed a Web site? (Score:1)
That is important for secure e-commerce. But troubling for simple communications. There should not be authentication being performed on plain communications.
Re: (Score:2)
Why not? Any communication over an untrusted network is potentially a source of malware if nothing else.
Re: (Score:2)
Why not? Do you speak in code to other people? Do you watch billboards where you have to decrypt the message?
Information needs to be free. Not subject to logging who saw it, requiring extra resources on the sending and receiving end, and disappearing when certificates expire and the one to renew them is dead.
Re: (Score:2)
I'm sorry, but you appear to be confused about how this all works.
Authentication means proving the identity of the party you're communicating with. It has nothing to do with encryption, other than the fact that certain tools can be useful for both purposes.
There are multiple strategies for authentication that do not require that any third party be involved in or aware of the communication. No-one need be any more able to log your communications just because you authenticated the source.
There are also variou
Re: (Score:2)
Authentication means proving the identity of the party you're communicating with. It has nothing to do with encryption, other than the fact that certain tools can be useful for both purposes.
You are a good example of why a little knowledge is dangerous.
The problem isn't authentication, but that an unintercepted endpoint-to-endpoint connection tells you who requests an URL.
When a user goes through a caching proxy server (which can very well be transparent and at the ISP) with a http request, all the remote web server sees is the IP address of the proxy server, and when others access the same resource while it is still fresh, the remote web server sees nothing at all because it's served from cach
Re: (Score:2)
Are you speaking of cases where the user always Googles EVERYTHING and then clicks the resulting link?
Because in my desktop browser (and whenever possible on my Android) I click links in my Bookmarks or just type the URL into Firefox (not Chrome) and go direct to the site. How could Google intercept that?
Re: (Score:2)
My "little knowledge" comes from about ten years working in relevant areas professionally and knowing how these protocols work down to the bit, but whatever.
The subject of this thread was authentication as a defence against malware injection. Obviously you're welcome to discuss other things, but they're not really on topic in this part of the discussion, and so far you appear to be trying to make some sort of dogmatic point rather than addressing the issue that everyone else is talking about.
In any case, no
Re: (Score:2)
Because in my desktop browser (and whenever possible on my Android) I click links in my Bookmarks or just type the URL into Firefox (not Chrome) and go direct to the site. How could Google intercept that?
Web bugs and scripts. Like on this very page:
Re: Is this to control who is allowed a Web site? (Score:1)
Do people really browse without Google Analytics blocked with NoScript?
I suppose they must.
We need fuzzing browser plug-ins. It's time to make the data miners work for a living.
Re: (Score:2)
Except that I block google-analytics.com and its ilk from executing their scripts via NoScript.
Which was just fine and dandy until Firefox decided to hide the NoScript UI element as "legacy" until they click their heels and salute to the Firefox New Order of Add-Ons. Still works, though.
Re: (Score:2)
How about not block any sites, but disable javascript on non-secure sites?
Because that wouldn't work.
All of the various forms of content downloaded by web browsers can be malformed in ways designed to exploit browser vulnerabilities. HTML, CSS, images, video, audio, PDFs... you name it, there have been vulnerabilities related to it.
Re: (Score:2)
You can self sign.
Re: (Score:2)
Until self-signed certificates are also deemed a security threat by the mighty Google and sites using them are auto-blocked in Chrome.
Re: (Score:2)
Remember that Google also performs a security check of every web address to make sure it is not a malware site. Be more concerned about how Firefox is embedding all sorts of prefetching services for Facebook, Amazon and other websites, even if you don't use them. A web browser shouldn't be sending a constant stream of data out to the internet while it's on a blank page.
Re: (Score:3)
Remember that Google also performs a security check of every web address to make sure it is not a malware site.
Only if you agreed to turn that on.
It's actually a really good idea from a security perspective, assuming you're comfortable with Google receiving that information. I am... but then I browse logged in to a Google account, and have Web History turned on. I find it very useful to be able to search and review my own browsing history. YMMV, and you have to make the privacy vs security/convenience tradeoff yourself. The controls are there to allow you to do it.
Re: How does Google get this? (Score:1)
The default should be opt-out. But Google gives away this free and shiney candy they call Chrome.
I guess it keeps grandma safer.
Re: (Score:2)
The default should be opt-out.
As I recall, there is no default. You have to make a choice.
Re: (Score:1)
Nope, there are boxes pre-checked, and a 'continue forward' type button on the corner of the screen to provide a smooth user experience.
Re: (Score:2)
Is anyone else vaguely perturbed that we are getting information on this increase in a privacy-enhancing technology by Chrome apparently watching every website that a wide variety of users go to and sending that information back to Google?
In Chrome, go into Settings. Click "Advanced", then look under "Privacy" for "Automatically send usage statistics and crash reports to Google". If that is enabled, it's because you approved it. If it's disabled, Chrome is not sending the information.
Re: How does Google get this? (Score:1)
If it's checked, it's because you didn't know well enough to uncheck it during those smooth "let's get you started, now" screens when you first use the browser.
The best part is when it actually gets kinda sulky when you don't make all the correct choices. The Microsoft 'appoval of defaults' process goes the same way.
Make no mistake about it, a LOT of design effort goes into making that a 'smooth experience' for 'the user.'
Re: (Score:2)
The best part is when it actually gets kinda sulky when you don't make all the correct choices
In what way?
That's interesting? (Score:3)
Re:That's interesting? (Score:4, Interesting)
Look for the simplest solutions. Like Mac users visiting shopping sites more. i.e. a correlation between being a consumerist and using a Mac.
Now stop breaking https (Score:3)
Now we just need public wifi to stop breaking https!
Re: (Score:2)
Visit http://example.com/ through cleartext HTTP first in order to trigger the captive portal redirect.
Re: (Score:2)
It doesn't. This is the combination of two things:
a) Your HTTPS connections appear broken and insecure due to HSTS demanding an SSL certificate for a site previously visited securely and the public wifi login page being unable to provide the correct one.
b) Your browser not recognising the need to redirect because of the SSL error.
This isn't the public wifi's fault. All you need to do is open a know non-https page that will force the redirect to the login page. Sometimes this won't work if you force your DNS
Secure us from Google (Score:1)
Google is helping secure the web with HTTPS; great. Now we have to talk about securing the web from Google. Rather than Chrome, at least run open source Chromium, if not Brave or Firefox. Run Google searches with Startpage. Run CopperheadOS rather than stock Android to strip out all the proprietary Google code and secure the OS.
Bad for free speech and experimentation (Score:2)
In not so distant past, you could code your own web server on a home desktop and make it available to any browser worldwide. With https you have to get a domain name and a certificate, adding ongooing expenses and implying someone needs to give you permission for what you want to serve to the world. Plus SSL is not something you can code from scratch on top of the OS as a hobby. We ought to at least establish a strong hobby Internet if commercial one has to be locked down.