After reading the blogpost, it seems like it was working as intended. Why "fix" it?
Supposedly, the following command line options will enable it, but it seems like just upgrading is a better option:
--variations-server-url=https://clients4.google.com/chrome-variations/seed --fake-variations-channel=stable
I'm not a Chrome user. But that sounds awful at first. What is the idea behind this service? Is there any documentation about the 'features' these flags can enable/disable?
I understand that I'm paranoid at times AND I really dislike Google, but why would you have an extra channel to influence deployments, other than offering a global update file?
Finch is mainly used for A/B testing. It doesn't push actual updates, all it does it turn existing features (flags) on and off. It's used for quickly A/B testing or incremental rolling new features and is designed to be more agile.
> not wanting to be tracked
here's a hint: ad impression for unknown user is 0.01$ and for logged in user 2$. guess why Google has a browser now...
if you have a logged-off cookie, and the publisher can associate you with a logged-in user at a near point in time, they can charge you as logged in impression.
It should be entertaining when car makers use the same strategy: "Oh yeah, we have this system where everytime you turn the ignition, your car polls us and updates its assistant, motor, steering and airbag settings. Don't worry though, we mostly just use it for randomized tests and field trials."
Finch only turns certain features on/off. It's used for A/B testing and incremental rollouts.
You can see a list of flags in chrome://flags
Mostly experimental stuff that will become full features soon, but until then they are behind a flag.
The two systems fulfill very different roles.
Also look for base::FieldTrialList in Chromium source. In this case, it seems to be: https://chromium.googlesource.com/chromium/src/net/+/master/...
interesting, if you're a victim of mitm attacks, i wonder if attackers can abuse that to disable some certificate check features to make spoofing ssl sites easier.
A) why is this possible, and B) isn't the whole point of the expiring list to provide a stick? Why remove the stick at the last moment?
We've got customers that mostly run Windows, however, and it's a helluva lot easier to, for example, just get a three-year certificate from <vendor>, install it, and then forget about it for the next three years.
Fortunately, I don't (usually) have to deal with the Windows boxes (i.e. actually installing and/or configuring the certificates) but I'm often the one acquiring the certificates.
Also, inventory management, which is helpful when you have hundreds or thousands of certs.
CertSimple only does EV, and we do it completely differently from every other company: we check as much of your company's details before you pay, matching your order to a registered/active entity, flagging up things before asking for your credit card number, and helping you resolve any missing identification steps based on your company, order and the domain names involved.
I've been on HN for a decade and was at YC in Mountain View last week for the 10-min final interview last week (we didn't make it, which I blame on me being a jetlagged mess). OTOH the AirBnB we stayed in used a customer as their ISP.
We're used by a bunch of companies HN folks might know, including Travis, Tito, and Monzo.
If I hadn't seen it repeatedly with my own eyes - most trust images will get you a small bump, for some reason Symantec performs the best. It's understandable and yet very frustrating!
The checkmark been around since at least 1997, and in it existence it has been associated with the most trustworthy institutions. It has become a synonym of trust. That checkmark is one of Symantec's most valuable assets.
incompetence promoting incompetence. the staple of big corporations.
Symantec acquired the CA business from the old VeriSign in 2010, which back then was the largest CA and had a large corporate client portfolio accustomed to paying $$$$ per certificate per year. Corporations can become very reluctant to change, even if it benefits them, and there are some who just pay up every year without researching alternatives or even being aware of any.
You will find that there are a lot of similarities with the domain name industry where there is also a company operating with a VeriSign heritage: Network Solutions. Network Solutions also charge premium prices, because their legacy customers expect those. And although market share is slowly eroding over the years and cheap (and even free) competitors rise, more than enough legacy customers stay on board to remain very profitable for many years to come. What definitely helps is that most of the processes in the domain registration and CA industries can be automated and don't need a lot of maintenance.
They don't even need to be subdomains.
In the parent poster's case, it sounds like a good use case for a wildcard cert. They may have thousands of affiliates, and may not know all of the affiliates ahead of time, so with a SAN cert, would need to reissue the certificate each time a new affiliate signs up.
https://community.letsencrypt.org/t/subjectaltname-certifica...
But there are options, and a SAN has lower risk if your key is leaked (only the enumerated domains will validate).
1. In September, Chrome 53 was released, which enabled mandatory Certificate Transparency for Symantec certificates due to Symantec's history of incompetence. Some website operators, such as Chase, asked Symantec to submit their certificates to Certificate Transparency logs in such a way that the certificate wouldn't be trusted by Chrome, triggering the ERR_CERTIFICATE_TRANSPARENCY_REQUIRED error. This is when I wrote this blog post.
2. Last week, an internal timebomb expired in older versions of Chrome causing this error message for any website using a Symantec certificate issued since June. Basically, Chrome contains a list of Certificate Transparency logs that it trusts, and this list has a 10 week expiration date. So if Chrome was built more than 10 weeks ago, there would be no trusted Certificate Transparency logs, and therefore any certificate that was supposed to be logged (such as new Symantec certs) would be untrusted and display this error message. The Chrome team was able to fix this within 24 hours by remotely disabling CT enforcement in Chrome. (When Chrome starts up, it fetches a list of feature flags from a Chrome server using a system called Finch which is independent of the normal upgrade system.)
3. Today, the Chromium packages in several Linux distros, including Ubuntu, became 10 weeks old. For some reason, they have not picked up the Finch update, and so they are displaying this error message for all Symantec certificates issued since June. This is not confirmed yet, but the current hypothesis is that the distros have disabled Finch for privacy reasons. It will probably require a distro package upgrade to fix.