Open questions:
- ping frequency
- format/data
- whether this can piggyback on existing pings (e.g. the update check or similar)

catmullings@, lottie@, waffles@ - any thoughts?

Frequency: No more than once per update-check.

Format/Data: What's the open question exactly? This should be an Omaha install ping as defined in the protocol (https://github.com/google/omaha/blob/master/doc/ServerProtocolV3.md). In a nutshell, it's an Omaha request without an <updatecheck> but with an <event> instead, much like the uninstall ping. It should at minimum contain:
 • eventtype="2"
 • eventresult="0" (error) or ="1" (success)

Piggybacking: I recommend against it. Since you need to send the outcome of the install attempt, sending it in the install update-check requires you to know the future, and sending it in a later update-check assumes that there will be a later update-check. (It also requires you to persist data in memory/on-disk.)

> Format/Data: What's the open question exactly?
What exactly are the expected/accepted parameters and values.  For instance, do we want to call it "sideloaded", "installsource", "installlocation", etc?  Are accepted values integers related to enums (3) or strings ("sideloaded")?  I don't really have preferences here, but we should have a plan before we add it. :)

> Piggybacking: I recommend against it. Since you need to send the outcome of the install attempt, sending it in the install update-check requires you to know the future, and sending it in a later update-check assumes that there will be a later update-check. (It also requires you to persist data in memory/on-disk.)

We already store this data (it has important chrome implications), so no burden there.  I wasn't sure if we care about having a log of retention (e.g., would it be useful to know that even though 50% of *installs* come from sideloading, only 5% of active users were through sideloading?).  If that's not something we (or most developers) are interested in, then immediately after installation sounds fine.

Sorry, I was confused by this feature request; there are two features bundled into one here:
1 • Send installation pings for side-loaded extensions (i.e. "do crbug/726872 for sideloaded extensions") - this piece should not piggyback on any other request. This is what I refer to in #4.
2 • Report whether a current extension was installed via side-loading or not in the regular roll-call.

Maybe let's consider 1• as part of crbug/726872, leaving us with 2•, in which case:

Format/Data:
Add "installedby" as an attr to <app> (x= parameter in the CRX dialect). Values are strings that match [a-z]* (no spaces, no underscores). I don't know what the possible valid values are - do you have a suggestion?

Piggybacking:
Yes, for 2• let's send it with every Omaha request for the extension.

For off-store extensions:
In https://codereview.chromium.org/1956893004 we stopped sending off-store extension info in Omaha update checks. There seems to be an exception (bug?) where we still do in the case where the extension's update_url in the manifest is not defined: ExtensionDownloader::AddExtensionData fallbacks to the Omaha url if the |extension_update_url| is missing. 

I'll consider that outside of the scope of this bug for now.

FTR, privacy discussion is here: https://groups.google.com/a/google.com/d/topic/chrome-privacy-core/qtAH33f3_UM/discussion

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a696e0dd9250f91c5a3ec0de5e8c9ddc7b8f2a3e

commit a696e0dd9250f91c5a3ec0de5e8c9ddc7b8f2a3e
Author: proberge <proberge@chromium.org>
Date: Wed Feb 21 15:54:36 2018

Add extension manifest locations to Omaha update checks

Bug:  727861 
Change-Id: Ibe0088f38ee185a4cae88e5d9933ce0caa1eedac
Reviewed-on: https://chromium-review.googlesource.com/912365
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Joshua Pawlicki <waffles@chromium.org>
Commit-Queue: proberge <proberge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538116}
[modify] https://crrev.com/a696e0dd9250f91c5a3ec0de5e8c9ddc7b8f2a3e/chrome/browser/chromeos/extensions/external_cache_impl.cc
[modify] https://crrev.com/a696e0dd9250f91c5a3ec0de5e8c9ddc7b8f2a3e/chrome/browser/extensions/updater/extension_updater.cc
[modify] https://crrev.com/a696e0dd9250f91c5a3ec0de5e8c9ddc7b8f2a3e/chrome/browser/extensions/updater/extension_updater_unittest.cc
[modify] https://crrev.com/a696e0dd9250f91c5a3ec0de5e8c9ddc7b8f2a3e/extensions/browser/updater/extension_downloader.cc
[modify] https://crrev.com/a696e0dd9250f91c5a3ec0de5e8c9ddc7b8f2a3e/extensions/browser/updater/extension_downloader.h
[modify] https://crrev.com/a696e0dd9250f91c5a3ec0de5e8c9ddc7b8f2a3e/extensions/browser/updater/manifest_fetch_data.cc
[modify] https://crrev.com/a696e0dd9250f91c5a3ec0de5e8c9ddc7b8f2a3e/extensions/browser/updater/manifest_fetch_data.h

The change in comment #11 adds an "installedby" field to some Omaha update checks. It should be present in:
1. Initial installation and update checks of sideloaded & policy-installed extensions that are updated through the CWS.
2. Update checks of CWS-installed extensions (but not the initial installation)

The original description mentions the following:
"This information would be useful for extension developers who are interested in the degree to which their extensions are sideloaded."

As per the discussion with Chrome Privacy, the collected data is to be used for anti-abuse purposes. We should not be sharing the information with extension developers without another privacy review. 

+jawag@ in case he wants to pursue surfacing this to developers and taking on that privacy review.

As of now, there aren't immediate plans to surface this data in the developer dashboard. We'll do a separate launch review if/when we decide to proceed with that feature.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc16497ea2ff2d60576f76118fa14136f42d068a

commit fc16497ea2ff2d60576f76118fa14136f42d068a
Author: Minh X. Nguyen <mxnguyen@chromium.org>
Date: Tue Apr 24 16:05:35 2018

[update_client] Add installedby (extension manifest location) to update check requests.

Bug: 722942,  727861 , 835936
Change-Id: I256f5b1c54143a0c4ec5dccea668eb669673cc3d
Reviewed-on: https://chromium-review.googlesource.com/1025073
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Joshua Pawlicki <waffles@chromium.org>
Reviewed-by: Sorin Jianu <sorin@chromium.org>
Commit-Queue: Minh Nguyen <mxnguyen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553145}
[modify] https://crrev.com/fc16497ea2ff2d60576f76118fa14136f42d068a/chrome/browser/extensions/updater/update_service_browsertest.cc
[modify] https://crrev.com/fc16497ea2ff2d60576f76118fa14136f42d068a/components/update_client/protocol_builder.cc
[modify] https://crrev.com/fc16497ea2ff2d60576f76118fa14136f42d068a/components/update_client/update_checker_unittest.cc
[modify] https://crrev.com/fc16497ea2ff2d60576f76118fa14136f42d068a/components/update_client/update_client.h
[modify] https://crrev.com/fc16497ea2ff2d60576f76118fa14136f42d068a/extensions/browser/updater/update_data_provider.cc
[modify] https://crrev.com/fc16497ea2ff2d60576f76118fa14136f42d068a/extensions/browser/updater/update_data_provider_unittest.cc