Chrome executable do not opt-out telemetry code embedded by Visual C++ 2015 update 2 |
|||
Issue descriptionVersion: 53.0.2766.0 (Official Build) canary (64-bit) OS: Windows 10 (64-bit) Version 1511 (OS Build 10586.318) What steps will reproduce the problem? (1) dumpbin /imports:advapi32.dll "%USERPROFILE%\AppData\Local\Google\Chrome SxS\Application\53.0.2766.0\chrome.dll" What is the expected output? It depends on SystemFunction036 exported from advapi32.dll What do you see instead? It's questionable if we really want to ship our binaries with that API call. Please use labels and text to provide additional information. Reportedly this is a telemetry funcrion named __telemetry_main_invoke_trigger/__telemetry_main_return_trigger in Visual C++ Runtime library shipped with Visual C++ 2015 update 2. See "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\crt\src\vcruntime\vcruntime_internal.h" about its definition. - https://www.infoq.com/news/2016/06/visual-cpp-telemetry - https://www.reddit.com/r/cpp/comments/4ibauu/visual_studio_adding_telemetry_function_calls_to/d30dmvu Note that this is affecting all the executables built by us such as chrome_child.dll. I'm not completely sure if what we should react for this, but dev manager for the Visual C++ team confirmed that we can opt out this by adding "notelemetry.obj" to the linker input, and actually they are considering to to remove the code in question Visual C++ 2015 update 3. So for us, opting out this is pretty easy, it's just one line change in 'VCLinkerTool' - 'AdditionalDependencies' section of common.gypi. https://chromium.googlesource.com/chromium/src/+/01c031ab48e032bc73aa39f1d5871ed3b9d4c7e5/build/common.gypi#3178 Scott, Bruce, what do you think?
,
Jun 13 2016
> I think that there is no good technical or privacy reason to bother doing this. Yeah I personally agree with you, because to me there seems to be no technical difference between doing this in CRT and doing this in OS module, and in practice there have already been lots of ETW events sent from OS. It's also understandable that Microsoft can do whatever they think OK in vcruntime140.dll. Having the same code in chrome.dll is just a side effect of statically linking to CRT. Also, I just realized that SystemFunction036 is indeed documented in MSDN. So at least that API in question is not something completely unknown. https://msdn.microsoft.com/en-us/library/windows/desktop/aa387694.aspx > This function is available as a resource named SystemFunction036 in Advapi32.dll. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Advapi32.dll.
,
Jun 13 2016
And if SystemFunction036 is just a synonym of RtlGenRandom, I have no concern about the dependency on it.
,
Jun 13 2016
What does RtlGenRandom (SystemFunction036) have to do with the telemetry/etw hooks? Or just that it was "mysterious" looking? We've used that function for a long time rand_util anyway.
,
Jun 13 2016
My guess so far is their __telemetry_main_invoke_trigger/__telemetry_main_return_trigger are somehow depending on RtlGenRandom. So external visible dependency on RtlGenRandom (SystemFunction036) is not a cause of telemetry/etw hooks, but just a symptom of embedding those telemetry/ETW hooks in question.
,
Jun 13 2016
I think that the imports are not relevant, or at least not important. The only issue is whether __telemetry_main_invoke_trigger() is linked in to our code. This can be determined by setting a breakpoint when launching, dumping That said, removing this function is all about allaying people's concerns, and will not solve an actual privacy problem, but I suspect it is worth doing just to avoid distractions.
,
Jun 28 2016
Either way Visual C++ 2015 update 3 is now publicly available, which removed that code in question. https://www.visualstudio.com/news/releasenotes/vs2015-update3-vs > We've removed ETW eventing calls from vcruntime140.dll and static > libraries that previously fired during process startup and dllmain. Let's close this as obsolete and just keep updating toolchain as usual.
,
Jul 11 2016
|
|||
►
Sign in to add a comment |
|||
Comment 1 by brucedaw...@chromium.org
, Jun 13 2016