In Encryption Push, Chrome Flags HTTP Sites as 'Not Secure' (zdnet.com) 268
On Tuesday, Chrome started marking sites that don't use HTTPS as "not secure." From a report: First announced two years ago, Google said it would flag any site that still uses unencrypted HTTP to deliver its content in the latest version of Chrome, out Tuesday. It's part of the company's years-long effort effort to gradually nudge more webmasters and site owners into adopting HTTPS, a secure encryption standard for data in transit. Any site that doesn't load with green padlock or a "secure" message in the browser's address bar will be flagged -- and shamed -- as insecure.
[...] According to nightly data compiled by security experts Troy Hunt and Scott Helme, roughly 100 of the top 500 websites are still serving their pages over unencrypted HTTP -- all of which will today be flagged as "insecure." Many of those sites -- like Baidu, JD.com, and Google.cn -- are Chinese language sites, but many popular Western sites -- including BBC.com, DailyMail.co.uk, and Fedex.com -- are HTTP. Of the top million sites, a little over half do not redirect to HTTPS. Chrome 68 also brings with it Page Lifecycle API, and the Payment Handler API. From a report: The Payment Handler API builds on the Payment Request API, which helped users check out online. The new API enables web-based payment apps to facilitate payments directly within the Payment Request experience, as seen above. As with every version, Chrome 68 includes an update to the V8 JavaScript engine: version 6.8. It reduces memory consumption as well as includes improvements to array destructuring, Object.assign, and TypedArray.prototype.sort. Check out the full list of changes for more information.
[...] According to nightly data compiled by security experts Troy Hunt and Scott Helme, roughly 100 of the top 500 websites are still serving their pages over unencrypted HTTP -- all of which will today be flagged as "insecure." Many of those sites -- like Baidu, JD.com, and Google.cn -- are Chinese language sites, but many popular Western sites -- including BBC.com, DailyMail.co.uk, and Fedex.com -- are HTTP. Of the top million sites, a little over half do not redirect to HTTPS. Chrome 68 also brings with it Page Lifecycle API, and the Payment Handler API. From a report: The Payment Handler API builds on the Payment Request API, which helped users check out online. The new API enables web-based payment apps to facilitate payments directly within the Payment Request experience, as seen above. As with every version, Chrome 68 includes an update to the V8 JavaScript engine: version 6.8. It reduces memory consumption as well as includes improvements to array destructuring, Object.assign, and TypedArray.prototype.sort. Check out the full list of changes for more information.
MitM https proxies should be flagged too (Score:5, Interesting)
All of this is pointless as long as we encourage corp IT firewall admins to completely break https with their MitM proxies that use fake wildcard certs and bogus CAs as part of a GP push.
Re:MitM https proxies should be flagged too (Score:5, Insightful)
It's not "breaking" HTTPs, any more that distributed authorized_keys "break" SSH. The owner of Group Policy on a machine has (by definition) the authority to set HTTPs policies, read files, spy on the screen and plant furry porn in your home directory. That's literally what it means to be in group policy.
As I see it, the IT admins should be absolutely transparent with employees that all content touching the machine is subject to being recorded and have clear policies on whose approvals are necessary to go read the logs.
The problem:ALL HTTPS is insecure and allows MitM (Score:5, Informative)
The entire concept of certificate "authorities" is already fundamentally broken by design. (Kinda obvious, given the "argument from authority" fallacy.)
I can not trust an organization that happens to host a website, but I'm supposed to trust an organization that happens to be a CA? Because the browser maker said so? Whose trustworthiness is not established either, by the way.
If you want at least some trust, you either have to BE the CA (like with my own servers), or meet and get to know the person *personally*. Everything else is just hearsay, and of comparable trustworthiness to whatever you receive when you send out an unencrypted HTTP request to a random unknown domain.
Comment removed (Score:4, Interesting)
Lost trust - lost their CA. Kinda proves the point (Score:2)
BTW you made a very good point in this other post, though I don't think most people have the background knowledge to fully appreciate your point.
https://tech.slashdot.org/comm... [slashdot.org]
> They had to divest themselves of the CA business because they prove themselves repeatedly to be not trustworth
Symnatec couldn't be trusted, therefore they couldn't have a CA business. That seems to indicate that untrustworthy companies can't be CAs (for long).
Re: (Score:2)
How do you go to the grocery store? Surely you don't believe that unless you personally milked the cow, you can't know that it's milk and of comparable trustworthiness to any white liquid you find in a random
Re: (Score:2)
I'm sure there's an option to run Chrome with these warnings disabled. Any corporate IT capable of running a HTTPS proxy, requiring them to load an extra trusted cert on all their Chrome installs, is going to be able to activate this option. If Chrome lacks such an option it's just going to force companies to choose some other browser.
So, yes, Google's move is good for personal and small business users who just run with all the defaults. But they have limited power to force changes on large businesses wi
Re: (Score:2)
Back in the 1990's I made a "Online ordering system" that was https but all it was a bash script CGI app once filled out the data it would send the order to the printer for the Admin to handle the order.
We just made sure people from outside the network couldn't packet sniff the message. Then everything else was unencrypted. Granted the paper print out didn't leave a digital database trail for remote access later on. The orders were just placed in a Real Folder.
Comment removed (Score:4, Interesting)
This is true (Score:3)
I suspect most people reading this haven't worked in a SOC, so they won't appreciate how much truth there is in what Bobmorning said.
> There is a delicate balance between having situational awareness of what is going on in the network versus
Exactly. We have systems that can see when a site is trying to do a drive-by malware installation or whatever, lots of ways to protect people in some pretty advanced ways. We can't protect what we can't read, though. So there is a balance. Encrypting everything makes
Just be aware of the trade-off (bank hack yesterda (Score:2)
Your concern may have some merit.
Just be aware of the trade-off. Remember the $100 million hack yesterday, where the same company got hit twice in eight months, from phishing attacks? Corp sec could have prevented those if they had visibility into what pages the employees were loading. They could have seen the employees entering their ldap credentials into corporateHR.ru and prevented it. Our SOC catches a LOT of that stuff.
Also catches and blocks a lot of malware, crypto-locker style ransomware, etc.
So you
The browser does TLS internally (Score:2)
The broswser does TLS, so system access doesn't give you access to monitor it. Not using safe APIs. An attacker with root could dig into your RAM or whatever, but that's not a safe approach.
Thanks Google! (Score:5, Insightful)
Thanks, Google, for breaking the internet.
Misusing your power (client & server) to push people around and to shape a landscape favoring your business and nothing else. You are finishing the nightmare Microsoft tried to realize.
Assholes.
Comment removed (Score:4, Insightful)
Re:Thanks Google! (Score:5, Insightful)
The warning isn't fucking unobtrusive, that's the problem.
Any time you do something Google doesnt' like, it makes sure to make a big fucking fuss about it.
And that's going to give people the idea that the age they're trying to visit has been hijacked or otherwise when it has not.
It's going to pretty much result in digital libel and defamation of the site as idiots who don't know better start spreading word that "site x is hacked because Google Said So."
Too bad nerds like you quite often have shorter sight than your coke-bottle glasses lets on.
Re: (Score:2)
The warning isn't fucking unobtrusive, that's the problem.
They changed the "(i)" icon to now say "(i) Not Secure" just to the left of the URL in the address bar.
How is that obtrusive?
Do you consider the padlock icon with the words "Secure" equally as obtrusive?
They are now the exact same length as each other.
Too bad nerds like you quite often have shorter sight than your coke-bottle glasses lets on.
No, we just prefer to ignore assholes that make shit up that is demonstrably not true.
This [bbci.co.uk] is literally the change you are bitching up a storm about as "The warning isn't fucking unobtrusive"
Re: (Score:2)
Uh, no, how about a full-page warning going to http-only sites that are known-good yet Google classifies as 'dangerous sites?'
JUST got that going to an HTTP site (one used for looking up MIDI files.)
You apparently must be very new with Google and the internet in general despite your UID.
Shut your mouth until you're fully-informed on the subject. It is apparent that you're only about 10% informed. Good day.
Re: Thanks Google! (Score:2)
Secure Contexts (Score:2)
W3C maintains a spec called Secure Contexts [github.io], which encourages web browsers to completely disable certain sensitive JavaScript features within HTML documents served over a cleartext HTTP connection. Only HTTPS and http://localhost/ [localhost] are allowed to use Service Workers, Geolocation, Payment Request, Presentation, and several other web platform APIs.
Re: (Score:2)
There is absolutely no reason to enable most of the crap we have now by default (battery status, access to gps, usb, vr, etc). TELL me when sites need it
Many of these sensitive web platform APIs, such as location and notifications, already require the user to interact with a permission dialog presented by the browser before a script in a document can use them.
Re: (Score:2)
I'm failing to see how an unobtrusive warning that the webpage you're looking at wasn't served securely is "breaking the Internet".
Dude I work corporate IT. Holy Crap will my phone ring off the phone tomorrow with HEEELLLP my intranet site is saying it is compromised! I probably will be working 16 hours a day without lunch telling everyone to use IE. Ugh.
Yes it does brink corporate apps and remember business use is part of the internet as well and is HUGE. This is unacceptable as no where in the IEEE standards does it say WWW must be encrypted by default.
Re: (Score:2)
This is stupid garbage (Score:5, Insightful)
Most web sites don't need https. Most web sites don't take payments, don't transmit user data, etc.
Bbc.com doesn't need encryption. My business site which doesn't take payments or allow user accounts does not need encryption. It's a wall of text and pictures.
Google acting like the entire world needs this is incredibly stupid.
I already have to use Firefox to access firewalls because Google decided that "go to the site anyway goddammit" just means "allow traffic for 2 minutes, and then complain about the certificate again. And again. And again"
Now it's going to scare people for no reason. Screw them
Re: (Score:2)
Come on - http://www.miketaylor.org.uk/tech/oreilly/truenut.html [miketaylor.org.uk] needs to be encrypted. Think of the children.
(any more cliches?)
Re: (Score:3)
Re: (Score:3)
They say "not secure" rather than "insecure." It's a fair distinction, that makes more sense in the context. The least of the problems are the wording.
Re:This is stupid garbage (Score:5, Insightful)
Bbc.com doesn't need encryption.
You visit bbc.com. The great firewall [wikipedia.org] inserts javascript to DoS attack another website.
You visit bbc.com. You read a simple article about foreign policy. In between you and the BBC, the text of the article has been replaced, changing your knowledge of facts, your opinion, and ultimately your vote.
You visit bbc.com. To preserve your privacy, you use a VPN or Tor. Your HTTP request has a BBC-UID cookie. Anyone snooping the connection can tell which link is yours as opposed to someone else's, and can track when you're there using the internet and which pages you go to.
You visit bbc.com. You're an activist in a country which would like to not have you around. Instead of receiving bbc.com, you receive child porn. It only takes a minute for the police to be signalled and break down your door and confiscate your computer. In court, experts testify that you hid the CP in a clever place (the browser cache). Not only do you go away for life, but you're discredited to the public and the court, police and experts don't have to be in on it.
Explain why it is essential to have bbc.com not be encrypted.
Re: (Score:2)
Re: (Score:2)
Most web sites don't need https. Most web sites don't take payments, don't transmit user data, etc. Bbc.com doesn't need encryption.
Do you want your ISP to be able to see and use your browsing history? Do you want them to be able to block websites they deem inappropriate? Do you want Comcast to start injecting ads into websites like they've been caught doing before?
What if your bbc.com login is the same as your bank login? What happens when you get hit by one of those router worms that are popping up all over the place? Hopefully most people on /. will not have this issue, but I guarantee you that this is the case for most users.
Yes, Go
ISP caught injecting cross-site scripting (Score:3)
Comcast has been caught injecting advertisements [gizmodo.com] into HTML documents that Comcast customers view over cleartext HTTP. If BBC doesn't want Comcast performing cross-site scripting on BBC's site, BBC needs to use HTTPS.
Re: (Score:2)
All it said is whatabout man-in-the-middle. And if it's dry, uninteresting facts - who cares?
Is this like DRM? (Score:2)
I have to wonder if we lockup all websites as viewable only via SSL - does that limit access to anything (historical) ? Alright - time to through away the crap, we can't keep everything.
Why is bbc.com insecure because it uses HTTP? I understand why mybank.com would be insecure. I'm worried well lose something valuable when Chrome et al block (some day in the future) all of HTTP.
Besides - it's only a matter of time before hackers move to SSL attacks. When the low hanging HTTP fruit is all gone, SSL loo
Re: (Score:2)
It's not just about securing the data in transit, it prevents tampering (eg. ISP or router injected ads) and tracking (your ISP cannot know what you visited on the site, just that you visited that particular ip and domain)
Re: (Score:2)
I have to wonder if we lockup all websites as viewable only via SSL - does that limit access to anything (historical) ?
It would only affect servers where the admin is doing just barely enough maintenance to keep the site alive. HTTPS doesn't affect scripts running on the server, page rendering, etc. The content is not affected in any way, and really the only reason that anything at the application layer even needs to know about the encryption is because it has to listen/connect on port 443 instead of port 80.
Re: (Score:2)
See the site, get the approved secure ads.
Re: (Score:2)
You shouldn’t have given Chrome market share (Score:3, Interesting)
"Redirect" (Score:3)
Their metric specifically mentions redirecting. One of the sites that I manage is an antique auto parts store. There is still a large fraction of our customers using Windows 98 era PCs. Due to this, automatic redirects from HTTP to HTTPS are disabled, so they can still browse the catalog and call us on the phone to order. Bots testing this site would notice the lack of redirection. However, modern browsers pass in some new additional headers which mention some HTTPS capabilities, and *IF* these headers are available, automatic redirection happens (since we know the client will be on a browser which supports the proper TLS version)
I'm sure several of these other sites are using a similar approach. I just personally tested FedEx.com, and it is properly redirecting from HTTP to HTTPS in an up-to-date browser. So odds are that these bots testing these sites are not fully supplying all the same headers that browsers do.
Re: (Score:2)
Due to this, automatic redirects from HTTP to HTTPS are disabled,
You can check the user-agent string before redirecting and still secure the majority and protect moderately aged browsers. And the rest should be warned heavily what risk they are under.
Re: (Score:2)
Last version of Firefox that runs on Win98 is in the 2.x series, without some third party hack like KernelEx, which these people aren't likely to be running. So yeah, a little over a decade.
As long as they're behind NAT they're probably safe from a lot of the immediate remote exploits. XP was kind of a mess because it was still in an era when people connected to the internet directly with public IPs on individual computers with no firewalling at all, whereas these days most people are at least behind some k
Re: (Score:2)
"I've seen unpatched windows xp machines completely break down due to the volume of competing viruses on them"
What are you considering "unpatched?" After SP2 (it went up to 4 in XP) the system is rock-solid. Looking at two XP systems right now on the internet, not giving a fuck - my laptop and one of my legacy desktop systems.
Not what the web was made for (Score:2)
I don't see any reason most web sites need to be encrypted.
Re: (Score:2)
HTTPS breaks intermediate caches (Score:2)
Encrypting the material in transit doesn't make any less freely disseminated or the information less free.
It prevents caching. Say a school in sub-Saharan Africa has only a 128 kbps, harshly metered connection for all its computers to use. With cleartext HTTP, if all the students visit the same encyclopedia page, a Polipo caching proxy inside the school can retrieve it once and serve it to 25 students in a classroom. But with HTTPS, the proxy can only handle the CONNECT verb to tunnel the connection to the origin server, causing transfer of 25 times as much data compared to the case with an intermediate cache.
Re: (Score:2)
Back when the web was designed, it was filled with engineers and technogeeks whose interest in information was one where your status and "street cred" depended on the value and veracity of your information.
In the current time of fake news, lies and deceit, your status depends mostly on how many people you can dupe into hating your opponent in any way possible because you yourself don't have any positive traits either, so you have to get people to hate the other guy even more.
In this climate, yes, I DO want
Software updates etc... (Score:5, Interesting)
Hopefully, though, software updates (such as Windows Update, Apple Update, etc...) will remain unencrypted. I run a network that services some remote communities via satellite, and those things are eminently cacheable (we have a WSUS server for our corporate computers).
Before you get your panties in a twist about that being insecure, the way I recall these things working is that the update client fetches SHA256 sums of the update files via HTTPS, and then downloads the files over HTTP. That way, the updates can be cached locally, but the end user can still be assured that they haven't been tampered with.
internal apps / IPMI's don't need certs (Score:2)
internal apps / IPMI's don't need certs so why push this?
Re: (Score:2)
"but this is just a nightmare for those of us who have to deal with low-bandwidth and/or high-latency links."
Quite clearly folks like you do not belong on the modern internet which is being designed by the greatest geniuses in human history to perfectly satisfy all legitimate needs.
You and your motley friends should pack up your kit and leave.
Crying Wolf (Score:5, Interesting)
Re: (Score:2)
There are multiple reasons why a certificate might trigger a warning. Being self-signed is only one of them. Another reason is when the server name on the certificate does not match the URL you typed in your browser. That is one example I consider a legitimate warning, and one that a user might just ignore if they become conditioned to just click "proceed".
Re: (Score:2)
I can see why you posted as AC. I, too, wouldn't want my name attached to this display of ignorance.
Encryption isn't the point (Score:2)
Re: (Score:2)
How about a compromise (Score:2)
How about Chrome finally taking my word for it when I tell it I trust a particular cert even if it isn't officially signed by some entity I have never heard of.
Meanwhile, if it's so important, why do they make it a pain in the ass for me to examine the cert used by a site? Shouldn't it be in the menu that drops down when I click on the lock icon?
For that matter, why isn't it easy for me to tell Chrome that I do NOT trust a given cert no matter who signed it or that I don't trust a particular CA to sign off
Re: (Score:2)
How about Chrome finally taking my word for it when I tell it I trust a particular cert even if it isn't officially signed by some entity I have never heard of.
The vast majority of users shouldn't be doing that. There are some exceptions (such as for developers), but Chrome should cater to the larger number even if it inconveniences the tiny a minority a little if it means greater security.
Meanwhile, if it's so important, why do they make it a pain in the ass for me to examine the cert used by a site? Shouldn't it be in the menu that drops down when I click on the lock icon?
Click the lock, click "Certificate" works for me
For that matter, why isn't it easy for me to tell Chrome that I do NOT trust a given cert no matter who signed it or that I don't trust a particular CA to sign off on water being wet?
Not a highly requested feature
Re: (Score:2)
Developers, admins, people using a private webmail, etc. In those cases, I know with greater certainty that I have the correct un-intercepted site than if a CA signed it. The option exists to temporarily accept the cert, why not be less of a pest? But make it equally easy to stop trusting the cert.
Click the lock, click "Certificate" works for me
It's not there, I just tried it. It used to be there once upon a time.
Re: (Score:2)
On linux, you have to right click->inspect->security->view cert. They clearly have a dialog for it, they should make it available without drilling down 4 levels into a developer tools menu.
Re: (Score:2)
The vast majority of users shouldn't be doing [accepting certificates from an unknown issuer]. There are some exceptions (such as for developers), but Chrome should cater to the larger number even if it inconveniences the tiny a minority a little if it means greater security.
You said home users shouldn't accept certificates from unknown issuers, and Let's Encrypt doesn't issue certificates for names in non-public TLDs. So what certificate should be used instead for a private HTTPS server on the home LAN, such as the configuration page for an Internet gateway or network printer?
HTTPS is centralizing the internet (Score:5, Interesting)
I'm all for encrypting web traffic, but this push for HTTPS-everything is kind of terrifying. It puts us in this dystopian future where we rely on CAs to decide whether or not we can visit a website.
If a couple of CAs decide (or are told) to revoke my cert, there's literally nothing I can do about it. And all of a sudden my website is inaccessible to 90% of browsers, and there's nothing I can do about it.
I would happily support some kind of peer-to-peer encryption scheme (HTTPS with no CA, maybe). But centralizing everything through CA gatekeepers is just asking for a government to butt in.
Re: (Score:3)
A revoked certificate isn't much different from a self-signed certificate. You can still connect to the server, there is just no guarantee that you're actually talking with the correct server. Which is something you kinda need someone to vouch for unless you want to manually verify every certificate of every server you communicate with.
Re: (Score:2)
That's logically true, yeah - but browser UIs make it increasingly tough to accept self-signed certs. Tough enough that my grandma wouldn't be able to figure it out. Which effectively makes a revoked cert into a death sentence for a website.
Great. Could we get educated users next? (Score:2)
Because we're now teaching the mantra of "encryption makes you secure", and people will swallow it. Unfortunately, it's not true. It is absolutely possible that you connect to hxtps://onlinebanking.bankofmurrica.com, log in and be surprised that suddenly your money is gone. Because encryption only means that traffic is secure between you and the target, and a certificate only says that the other side is who they claim to be.
What a certificate cannot ensure is that you're really connected to who you think yo
Re: Baked in financial transactions? (Score:3, Insightful)
Some of us remember when the web was for the interchange of ideas and knowledge, not some glorified shopping cart for mouth breathers.
Re: (Score:2)
Exactly! eg. USENET:
alt.barny.die.die.die
Re:To be honest (Score:4, Funny)
Do you not want any guarantees that your news is unaltered from the source?
Re:To be honest (Score:4, Insightful)
Do you not want any guarantees that your news is unaltered from the source?
Nobody is doing that. It's the source itself that is usually subverted.
Re:To be honest (Score:5, Informative)
Re: (Score:2)
That has little, even nothing, to do with HTTPS. "Altered from the source" is occurring in such volume at the news agencies themselves that HTTP insertion is not even a significant issue.
It's business sites, where manipulation of order forms and prices can cause fraudulent orders, that man-in-the-middle abuse is the much larger risk.
Re: (Score:2)
... you can argue until the cows come home about intercepting raw HTTP and altering it all you want, because corporations MITM HTTPS anyway, so it would just as easy to do the same thing.
Corporations can do that on devices they control because they have the necessary administrative access to install their own root certificates. Your local coffee shop or residential ISP can't MitM their customers' HTTPS traffic so easily, whereas the practice of tampering with pages served over HTTP is depressingly commonplace. This is far from theoretical; major ISPs have been caught red-handed injecting scripts and other content into web pages as well as splicing unique user IDs into HTTP headers for track
What certificate for home HTTPS? (Score:2)
I would at least propose to restrict pages served over HTTP from any form of interactivity. No scripts, no plugins, no forms, no "responsive" CSS, limited media formats—no audio or video
Under your suggestion, with what certificate on what domain should the operator of a private video server on a home LAN run HTTPS? Public CAs don't sign certificates for RFC 1918 private IP addresses or for names within non-public TLDs (such as .local used by mDNS). Some users have suggested using dynamic DNS, but in order to qualify for a certificate from Let's Encrypt, a subdomain needs a TXT record, and the domain it's under needs a Public Suffix List entry. Many dynamic DNS providers don't support those
Re: To be honest (Score:3)
Re: To be honest (Score:2)
All domain owners qualify for LE cert (Score:2)
It's about making sure that only registered publishers put material on the internet.
I don't see what practical problem that causes for publishers on the Internet, seeing as Let's Encrypt allows anybody who owns a domain name to register as a publisher without charge. Or are you anticipating tighter control of domain names in the first place?
Re: All domain owners qualify for LE cert (Score:2)
Either that or a tighter control of CAs where you need to pay a considerable sum each year for a certificate for your site.
Re: (Score:2)
I don't see how increasing the price of TLS certificates fits into Google's plans as long as Google's Chrome division remains listed on LetsEncrypt.org as a sponsor.
Why encrypt LOLcats? (Score:5, Insightful)
I'd be very concerned if any site I used for monetary purposes wasn't using HTTPS. On the other hand, sites providing data services like streaming or news probably don't need to encrypt anything.
Yes!
for 90% of the stuff I browse on the web, I don't need https. I really don't care who sees the cat pictures I look at.
https should be saved for pages that actually need encryption
Re: (Score:2, Insightful)
Because it's none of the NSA's or any other sniffing scumbag's damned business what you're viewering, full stop. If you only establish encrypted connections for things that you want private, then the snoops know what to focus on. If everything is encrypted, you offer them no clue.
Re: Why encrypt LOLcats? (Score:2)
Re:Why encrypt LOLcats? (Score:5, Insightful)
Honestly, I want encryption so my ISP *can't* inject adds into the pages. Need has nothing to do with it.
Re: (Score:2)
Re: (Score:2)
Some ISPs inject advertisement scripts directly into the port 80 TCP connection regardless of what DNS server is used.
Re: (Score:3)
Re:Why encrypt LOLcats? (Score:4, Informative)
HTTPS isn't just about encrypting information like bank info - but also about preventing tracking. If all of your websites use HTTPS, your ISP can't snoop on your traffic to sell your data.
Re: (Score:2)
HTTPS also stops malicious routers (like at a coffee shop or something) from executing MITM attacks.
Re: (Score:2)
Fixed that for you.
Re: (Score:2)
Re: (Score:2)
Yes they can. With the DNS cache they can track you and sell it to marketers and ads
Re: (Score:2)
Why not take steps to prevent both from tracking you?
Re: Why encrypt LOLcats? (Score:2)
Re: (Score:2)
You could not use google's browser and still accept that https is important.
Re: (Score:2)
https should be saved for pages that actually need encryption
But why?
Too many warnings = people ignore warnings (Score:3)
The number one reason, from my experience, is that of people see warnings a lot, especially for dumb things, they are quickly trained to ignore warnings. Microsoft learned this lesson with their first attempt at UAC. SELinux had a similar problem for a few years.
For best security, you should alert people to actual security problems, and only problems they can do something about. Reading Wikipedia over http is not a problem.
Also, Bobmorning makes a good point here:
https://tech.slashdot.org/comm... [slashdot.org]
The securit
You think that is the main feature of https? (Score:3)
Yes, a source can be compromised too, but the ease of mitm http is just amazing. Also, any http security header (csp, hsts, hpkp, etc) or other mitigation techniques are futile if transport can't be trusted.
Re:celf signed certificates (Score:4, Funny)
elf signed certs are fine, but they cause all sorts of issues in Gnome environments and Men in the Middle-earth attacks are possible.
Re: (Score:2)
I've heard of cert-signed ELF's, but not the other way around.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Here is the release information - https://www.chromestatus.com/f... [chromestatus.com]
I'm guessing it won't be released until later today (11:59PM UTC)?
Re: (Score:3)
The text on duck.com is significantly more informative than I expected.
Re: (Score:2)
You are aware that certificates have very little to do with encryption and are mostly about proving that you're actually talking with who you want to talk to, yes?