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 220.127.116.11, 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!
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: