The incident reporting service now calls VerifyModule.

chrome/common/safe_browsing/csd.proto

Index: chrome/common/safe_browsing/csd.proto
diff --git a/chrome/common/safe_browsing/csd.proto b/chrome/common/safe_browsing/csd.proto
index 77c015a47bc67c2525c4ee4b70b5ed8fcd3c476d..89814b1f0f1a43c03a3eddfe5911c0044ca0e31f 100644
--- a/chrome/common/safe_browsing/csd.proto
+++ b/chrome/common/safe_browsing/csd.proto
@@ -411,6 +411,12 @@ message ClientIncidentReport {
       }
       repeated Dll dll = 9;
       repeated string blacklisted_dll = 10;
+      message ModuleState {
+        optional string name = 1;
+        optional uint32 modified_state = 2;

[grt (UTC plus 2), 2014/08/05 16:04:54]

this is really an enum, right? could you make an enum here that mirrors the
values in the code? beware that 0 must be "UNKNOWN", so you may need a function
to map code values to proto values.

[krstnmnlsn, 2014/08/05 23:07:25]

I didn't notice we could do enums, that's great.  
The first/0 value of my enum is "MODULE_STATE_UNKNOWN", returned when
VerifyModule has to return early (the module didn't exist, or the headers were
malformed etc.), so would it be reasonable to let that translate into this
"UNKNOWN" value?

[grt (UTC plus 2), 2014/08/06 01:28:10]

It's best not to. When new values are added to the enum, old clients will see
the field as unset and the getter will return the first-declared value. So the
first value really should mean "I have no idea what this value is." You could
offset the C++ enum so that it starts at 1 rather than 0 and add a doc comment
to it explaining that it maps 1:1 to the protobuf enum.

+        repeated string modified_export = 3;
+      }
+      repeated ModuleState module_state = 11;
     }
     optional Process process = 3;
   }