InputEvent for click verification on Android

[taddcrockett]

Hello privacy sandbox team. I want to inquire about the usage of InputEvent as part of the registerSource API. I understand that InputEvent is required for validation to ensure that a click came from the system and not bots/other sources. However, my codebase has made extensive use of onClickListener instead of onTouchListener and it would be a difficult and costly migration to use onTouchListener instead.

Do you have recommended approach for using this API for developers that use onClickListener? Click listeners are a basic, ingrained part of Android development used everywhere, and essentially this API is not compatible with that as far as I can tell.

Alternatively, looking at the AOSP https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/Ad[…]=351;drc=ad68ffd12e70704e6cfe2e33af3fed993d78464e;bpv=1;bpt=1 this verification can be disabled. Will you allow consumers of this API to disable click verification and assume the risk of invalid clicks themselves?

[hannahtchang]

Thanks for raising, @taddcrockett

First, I wanted to provide some context for why InputEvent (and by extension, onTouchListener) was chosen to verify clicks in the current registerSource API design.

• onTouchListener enables the API to ensure clicks are coming from the system rather than being programmatically generated. With onTouchListener, the system gets access to both the "View" and "InputEvent" objects. InputEvent is created by the system and therefore enables the API to verify an actual click took place.
• Alternatively, with onClickListener, the system only gets access to the "View" object, not InputEvent. In other words, had the registerSource API design leveraged onClickListener, developers would only be able to call the API to register clicks with programmatically created InputEvents, which is counter to the goal of click verification.

Regarding your question on whether developers can use the API without click verification. If developers wish to use onClickListeners and choose not to use InputEvent to verify click events, the API will treat those click events as views.

• One practical implication of this is that, by default, the API permits developers to receive 1 bit of trigger data via event-level reporting about view-through conversions vs. 3 bits of trigger data about click-through conversions.
• However, forthcoming flexible event-level reporting features will give developers the ability to increase the number of bits for view-through conversions in exchange for higher noise, or reducing other parameters of their event-level reports.

[jorgesaldivar]

Hello privacy sandbox team. I want to inquire about the usage of InputEvent as part of the registerSource API. I understand that InputEvent is required for validation to ensure that a click came from the system and not bots/other sources. However, my codebase has made extensive use of onClickListener instead of onTouchListener and it would be a difficult and costly migration to use onTouchListener instead.

Do you have recommended approach for using this API for developers that use onClickListener? Click listeners are a basic, ingrained part of Android development used everywhere, and essentially this API is not compatible with that as far as I can tell.

Alternatively, looking at the AOSP https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/Ad[…]=351;drc=ad68ffd12e70704e6cfe2e33af3fed993d78464e;bpv=1;bpt=1 this verification can be disabled. Will you allow consumers of this API to disable click verification and assume the risk of invalid clicks themselves?

Regarding a recommended approach for developers that use onClickListener, the following proposal offers an interim strategy as we seek a more effective solution to ensure the authenticity of clicks.

Defining an onTouchListener to store the InputEvent of action type MotionEvent.ACTION_DOWN or MotionEvent.ACTION_UP as an instance variable. The instance variable can then be referenced within the onClickListener on the same object.

For the onClickListener to keep being invoked, the onTouch method from the onTouchListener must return false, allowing the touch event to continue propagation. Here's an example that demonstrates how this can be achieved:

view.setOnTouchListener((v, event) -> {
    if (MotionEvent.ACTION_DOWN == event.getAction()) {
        mInputEvent = event;
    }
    return false; // Return false so the onClickListener may be called
});

view.setOnClickListener(v -> {  
    MeasurementManagerFutures measurementManager = 
        MeasurementManagerFutures.from(getApplicationContext());  
 
    measurementManager.registerSourceAsync(registrationUri, mInputEvent);
});