Intermittent issues with Chrome

[jordan23]

Any updates on Chrome v 80?

[jsubbura]

Hi @Linuxxo  / @jordan23  / @vnaidu ,

Thank you for writing in here.

Am addressing all your questions in this single post. This post is quite big and more technical, so I advise you to go through the post slowly .

As per the above post from Linuxxo I can explain as of why he is seeing this,

Linuxxo comments: "I have DLP setup to block all file uploads for all browsers, everything works as expected, however from time to time, I see that the DLP fails to block files uploads with a "Non-Supported Chrome Version" reason. The DLP Enpoint version installed on the client is 11.3.2.82, whilst the Google Chrome version is 79.0.3945.130."

Answer: First things first, DLP 11.3 onward DLP-Chrome file blocking architecture has been changed. DLP on chrome will always block the file uploads to chrome, the Incident screenshot which you have shown is just a snippet, it is not complete. This Incident snippet screenshot which you have uploaded in here is a screenshot taken from a Incident which was triggered by uploading texts in Web Form Fields.

As per the release notes of DLP 11.3, you can see that the file upload block is only supported, if you try to upload the texts in web form fields DLP cannot block and will only monitor.

So when you set the rule to be blocked and when you try to post text in a chat box in a website or post classified text in a form field in web page, DLP can only monitor it, so the Expected Action will be block in here as per your rule and the Actual action will be Monitor as per the product design.

However I can explain you as of why you see the Failure Reason as "Non Supported Chrome Version"

Failure Reasons are defined as numbers in the backend,

Failure Reason 29 corresponds to "Non Supported Chrome Version"

So When the user performs a web post on a form field in a web page as below, DLP can only monitor the web post action in the form field. At this time, when the web post rule action is configured to Block and the actual action is No-Action (monitor), then the failure reason 29 will be triggered.

Sample Screenshots taken from my test lab are as follows,

Am uploading mcafee test text to form field, mcafee is the keyword

Incident triggered for the same,

So at the backend you can see the failure reason for this Incident.

However in DLP 11.3 and 11.4 we have only 22 Failure Reasons in and they are given below, and you can verify the same from the EPO -> DLP Incident Manager Console -> Filters,

Failure Reason 0: No Failure

Failure Reason 1: FRP Service not found

Failure Reason 2: FRP Invalid key

Failure Reason 3: Disk full

Failure Reason 4: RM service is disabled

Failure Reason 5: RM error

Failure Reason 6: File does not exist

Failure Reason 7: File wait reaction timeout

Failure Reason 8: Copy to quarantine failed

Failure Reason 9: Discovery session stopped

Failure Reason 10: Discovery error

Failure Reason 11: Plug-in disconnected

Failure Reason 12: Encrypt portable device not supported

Failure Reason 13: Timeout exceeded

Failure Reason 15: Justification disabled

Failure Reason 16: Privilege user

Failure Reason 17: Bypass mode

Failure Reason 18: Not able to block

Failure Reason 19: File already encrypted

Failure Reason 20: StormShield encryption failed

Failure Reason 21: Files with size over 10 MB are not encrypted

Failure Reason 22: Unsupported FRP version

Failure Reason 14 is not listed in the above list and we are working internally on the same to remove failure reason 29 and change it to failure reason 14 for “Non-Supported Chrome Version”

And also we are working in changing the Failure Reason "Non-Supported Chrome Version" to "Text Uploads can only be Monitored"

Hope the above clarifies your question on Failure reasons and why you are seeing Non-Supported Chrome version.

Note: All versions of Chrome is being supported by DLP 11.3 and DLP 11.4 to block file uploads and to monitor text uploads.

Kindly let us know if you have further questions on the above.

Was my reply helpful?
If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!

Thank you.

[ISmith]

Let me point out flaws in this explanation:

#1: I have only 1 rule that blocks web posts and it is a very specific rule that has only ever been triggered in testing. Therefore, the expected action=Block I am seeing, is a very unlikely thing. The incidents I see have no indication of which rule was triggered. It says Match count=0 and there is no rule listed, so how would I know if this particular rule was triggered? I maintain that my one block rule is not triggered because the terms are so specific.

#2: the URLs for the vast majority of the incidents are background process URLs use for tracking, metrics, and background data synching. These are not URLs that present a user-facing text box for the users. A common URL I see is doubleverify.com, which is by design a tracking and metrics domain that is invisible to the user. 
None of this would be bad if this was invisible to the end-user, but this morning I have another helpdesk ticket where the user is experiencing the popup "web post analysis exceeds timeout". The two sites this morning (so far) are these same kind of "background" URLS. If I cannot control or hide this, then I have to uninstall the DLP agent, which is a very bad thing.

I have 20,000+ incidents in the last 7 days that are "non supported chrome version" and only a handful are typical "www." sites. Deduplicated URLs are about 475 in total. Here is a small sample:

1.next.westlaw.com
14-southcentralus1.pushp.svc.ms
165962ea794a4deba466d65a256dcf42-1ad356638475.cdn.forter.com
17.client-channel.google.com
173c5b09.akstat.io
17d09914.akstat.io
17d09916.akstat.io
17d0991a.akstat.io
17d0991b.akstat.io
25.client-channel.google.com
28.client-channel.google.com
4-northcentralus1.pushp.svc.ms