- Jul 30, 2017
- 54
On the surface no. But you know how Google is. For all I know it could be an extension trying to update or something. Will keep an eye on it. I thought you mentioned that a rule needs to be created for Chrome? I have not created one as of yet however.
I will offer my personal experience and opinion based as a user (NOT expert) of AppGuard in Locked Down Mode:
1)
Context:
I am running Google Chrome on my Win10 64-bit OS with AppGuard in Locked Down Mode.
My Google Chrome instance was installed on C:\Program Files (x86)\ , by an Administrative user:
I experienced a
C:\Users\<UserName>\AppData\Local\Google\Update\GoogleUpdate.exe
block event
2)
One AppGuard Support individual suggested the following configuration:
"Just add the GoogleUpdate.exe file path to User Space and set to NO."
3)
On 2 different Support pages, AppGuard support suggested the following configuration for Chrome on Win7 :
AppGuard | Support
Support
"
Google Chrome
In order to use Google Chrome in the Locked Down protection level on Windows 7 64-bit PCs, do either of the following:
- Install Google Chrome in the Program Files directory (preferred).
- Exclude the following directories from the User-space protection definition
-- C:\Users\\AppData \Local\Google\Chrome\Application
-- C:\Users\\AppData \Local\Google\Update
"
4)
I noticed:
- many .exe's within directory
C:\Users\<UserName>\AppData\Local\Google\Update\
:
I.e., not just
C:\Users\<UserName>\AppData\Local\Google\Update\GoogleUpdate.exe
- directory
C:\Users\\AppData \Local\Google\Chrome\Application
did not exist
5)
The configuration I implemented in AppGuard:
- Excluded the following from the User-space protection definition
-- C:\Users\<UserName>\AppData\Local\Google\Google Talk Plugin\googletalkplugin.exe
-- C:\Users\<UserName>\AppData\Local\Google\Update
I guess that the above was overkill and that instead I could have just excluded a few .exe's within *\Update.
Please PM me if you would more detail.