search

gorhill / httpswitchboard

Point & click to forbid/allow any class of requests made by your browser. Use it to block scripts, iframes, ads, facebook, etc.
GNU General Public License v3.0
1.33k stars 83 forks source link

Extension Content Verification flag in Chrome Beta, Canary breaks HTTP Switchboard, uBlock #390

Closed rusvnc closed 9 years ago

rusvnc commented 9 years ago

Just a heads up -- this flag is available in Chrome Beta and Canary at least, therefore must be in Dev channel as well (haven't checked Stable though). I do not know if it will be on by default in future releases of Chrome, but if enabled and set to enforce, it flags HTTP Switchboard, uBlock, HTTPS Everywhere, among others, as possibly corrupted by malware and disables them. (Once you have enabled the flag you can only recover by exiting Chrome and editing the Local State file to remove the extension-content-verification flag entirely (setting to 0 will hang the browser)). Uninstalling and reinstalling the tagged extensions then restores them.

This is the relevant flag:

Extension Content Verification Mac, Windows, Linux, Chrome OS This flag can be used to turn on verification that the contents of the files on disk for extensions from the webstore match what they're expected to be. This can be used to turn on this feature if it would not otherwise have been turned on, but cannot be used to turn it off (because this setting can be tampered with by malware). #extension-content-verification

gorhill commented 9 years ago

I believe I fixed it with #379. I tested with Chrome 38 dev and it looks like it's fixed from my side. Did you try with release 1.0.0.3?

rusvnc commented 9 years ago

I will check when I get back to the machine where I can test it.

rusvnc commented 9 years ago

uBlock HTTPSB Chrome flag Chrome Version

gorhill commented 9 years ago

I am going to have to investigate. It's really puzzling, as I removed all code which write using the File System API, now only the chrome.storage.local API is used, and this can't be the problem as this would probably break most extensions.

Did you re-install the extension from scratch?

When I tested last time I didn't get the warning. I will go try again.

I haven't seen any feedback from Chromium devs about this: http://code.google.com/p/chromium/issues/detail?id=389879

rusvnc commented 9 years ago

Yes I reinstalled. I also changed the settings (e.g. adding and removing lists). It would seem poorly designed if their verification scheme did not allow for preference changing. But could that be it?

It is fine IF you don't enable extension content verification in flags. But it looks like they will implement that by default eventually.

rusvnc commented 9 years ago

This is probably a chrome bug. On Jul 29, 2014 3:19 PM, "Raymond Hill" notifications@github.com wrote:

I am going to have to investigate. It's really puzzling, as I removed all code which write using the File System API, now only the chrome.storage.local API is used, and this can't be the problem as this would probably break most extensions.

Did you re-install the extension from scratch?

When I tested last time I didn't get the warning. I will go try again.

I haven't seen any feedback from Chromium devs about this: http://code.google.com/p/chromium/issues/detail?id=389879

— Reply to this email directly or view it on GitHub https://github.com/gorhill/httpswitchboard/issues/390#issuecomment-50524717 .

gorhill commented 9 years ago

Ok, I checked and using Chrome 38 dev, I got the same problem.

Now the next thing I think where the problem could be, is that for backward compatibility reasons, I still query the window.webkitRequestFileSystem, in order to move user data from the old location to the new one in chrome.storage.local.

It could be that merely calling window.webkitRequestFileSystem does create the root of the virtual file system, and just that causes the hash generated for content verification purpose to change. So next thing to try for me is to remove all the code left related to window.webkitRequestFileSystem. But whoever hasn't upgraded to 1.0.0.3 would probably lose data, not something I want.

And to make thing more complicated, I cannot even test this without publishing a version to the store, since the good hash is certainly generated by the store (locally installed copies are not flagged as tampered with).

If at least there was some detailed information about that content verification flag from the chromium devs, we would know what to do exactly. Maybe it's there somewhere and I just don't know where to find it. Currently I am left speculating about how I can fix this.

rusvnc commented 9 years ago

https://code.google.com/p/chromium/issues/detail?id=398557

gorhill commented 9 years ago

Could be related to this: Content verification handles 0-length files incorrectly.

There are zero-length files under assets/user/.