5 ms·

Checking: "Check for server certificate revocation" does not persist. When I check it and then reopen the settings tab it is again unchecked. Does anybody else

Checking: "Check for server certificate revocation" does not persist. When I check it and then reopen the settings tab it is again unchecked. Does anybody else see this ? Chrome Version 34.0.1847.116 I've reported it twice now.

Roritharr 13y ago
Doesn't happen to me on Windows 8.1 Chrome Version 34.0.1847.116 m
thefreeman 13y ago
Wow, you are right. I was chuckling to myself looking at this article thinking Good thing I am smart and enabled this check. Then I read your comment, checked my settings and indeed the setting is no longer enabled. I understand that the CRL isn't fool proof, but if your connection isn't in a position to be MITM'd it still provides protection against some things, for example if the target website DNS has been hijacked. edit: 34.0.1847.116 m
- ryanpardieck 13y ago
  It's persistent for me. I'm on 36.0.1941.0 dev-m.
- chaosmonkey 13y ago
  35.0.1916.27 beta The check is persistent.
- tombrossman 13y ago
  For Chromium version 33.0.1750.152 Ubuntu 12.04, The settings change is persistent. Related question: Is anyone seeing degraded browsing performance as a result of this change yet? It is my understanding that these CRLs are spiking in size to multiple megabytes, no?
  - this_user 13y ago
    Same goes for Chromium 34.0.1847.116 on Arch.
- xux 13y ago
  Using 34.0.1847.120 It's checked by default, just looked.
- seacious 13y ago
  Chromes ability to save settings silently fails with disturbing regularity (in my experience). A lot of people seem to have seen the issue (e.g. [1], and google will reveal many more) but consistent steps to reproduce seem hard to come by. It's one of the main annoyances that made me switch back to firefox. [1] https://productforums.google.com/forum/#!topic/chrome/npSTSOGLy9o https://productforums.google.com/forum/#!topic/chrome/npSTSO...
- crucialfelix 13y ago
  Maybe we have an extension that is causing this. I'll try disabling them tomorrow and see if the UI works.
xtc 13y ago
Does not happen to me. Windows 7 x64, same version number. Perhaps it's an issue with sync?
Atroxide 13y ago
Maybe with news of Heartbleed a chrome update happened which forces chrome to check for revocations? Might just be a UI issue with showing it as an option and could be always on. Is there any way to test if it does indeed do the check? Most likely not though. in the Dev branch its fixed and I was able to turn it on.
lowmagnet 13y ago
Mine's still ticked after setting it last week. Same version you've got, on mac.
- ballpoint 13y ago
  Same here.
- manish_gill 13y ago
  Yep. Check still working on same version for OS X.
- crucialfelix 13y ago
  I'm on OS X too. Possibly could be an extension messing with it. That's usually what causes behavior that not everybody else sees on the same release version. Some above in the comments have confirmed what I saw.

Roritharr 13y ago

Doesn't happen to me on Windows 8.1 Chrome Version 34.0.1847.116 m

thefreeman 13y ago

Wow, you are right. I was chuckling to myself looking at this article thinking Good thing I am smart and enabled this check. Then I read your comment, checked my settings and indeed the setting is no longer enabled. I understand that the CRL isn't fool proof, but if your connection isn't in a position to be MITM'd it still provides protection against some things, for example if the target website DNS has been hijacked. edit: 34.0.1847.116 m

ryanpardieck 13y ago
It's persistent for me. I'm on 36.0.1941.0 dev-m.
chaosmonkey 13y ago
35.0.1916.27 beta The check is persistent.
tombrossman 13y ago
For Chromium version 33.0.1750.152 Ubuntu 12.04, The settings change is persistent. Related question: Is anyone seeing degraded browsing performance as a result of this change yet? It is my understanding that these CRLs are spiking in size to multiple megabytes, no?
- this_user 13y ago
  Same goes for Chromium 34.0.1847.116 on Arch.
xux 13y ago
Using 34.0.1847.120 It's checked by default, just looked.
seacious 13y ago
Chromes ability to save settings silently fails with disturbing regularity (in my experience). A lot of people seem to have seen the issue (e.g. [1], and google will reveal many more) but consistent steps to reproduce seem hard to come by. It's one of the main annoyances that made me switch back to firefox. [1] https://productforums.google.com/forum/#!topic/chrome/npSTSOGLy9o https://productforums.google.com/forum/#!topic/chrome/npSTSO...
crucialfelix 13y ago
Maybe we have an extension that is causing this. I'll try disabling them tomorrow and see if the UI works.

xtc 13y ago

Does not happen to me. Windows 7 x64, same version number. Perhaps it's an issue with sync?

Atroxide 13y ago

Maybe with news of Heartbleed a chrome update happened which forces chrome to check for revocations? Might just be a UI issue with showing it as an option and could be always on. Is there any way to test if it does indeed do the check? Most likely not though. in the Dev branch its fixed and I was able to turn it on.

lowmagnet 13y ago

Mine's still ticked after setting it last week. Same version you've got, on mac.

ballpoint 13y ago
Same here.
manish_gill 13y ago
Yep. Check still working on same version for OS X.
crucialfelix 13y ago
I'm on OS X too. Possibly could be an extension messing with it. That's usually what causes behavior that not everybody else sees on the same release version. Some above in the comments have confirmed what I saw.