Add SpeechRecognitionResult Timestamps

[alan33d]

Description

The Web Speech API currently does not expose the start and end timestamps of the source audio corresponding to a given transcription result. This limitation creates two major challenges for API clients and end users:

• Timeline Association: Developers cannot readily associate the transcribed text with specific segments of the audio source, making it difficult to map the generated text to the timeline.
• Latency Tracking: Developers cannot programmatically calculate transcription latency or detect performance degradation. This can create poor user experiences by showing users high latency results without explanation, or an opportunity to recover by switching to a more performant backend (e.g. transitioning from local on-device ASR to a cloud backend provider).

Specification

Expose nullable source audio timestamps on the SpeechRecognitionResult interface (e.g. audioStartTime and audioEndTime).

Web IDL

partial interface SpeechRecognitionResult {
    ...
    readonly attribute DOMHighResTimeStamp? audioStartTime;
    readonly attribute DOMHighResTimeStamp? audioEndTime;
};

Usage Example
Developers can compute real-time processing latency by comparing audioEndTime with Event.timeStamp:

recognition.onresult = (event) => {
  const result = event.results[event.resultIndex];
  if (result.audioEndTime !== null) {
    const latencyMs = event.timeStamp - result.audioEndTime;
    // If latency exceeds acceptable threshold (app specific), switch to cloud backend.
    if (latencyMs > LATENCY_THRESHOLD_MS) {
      switchToCloudBackend();
    }
  }
};

Security & Privacy Considerations

Fingerprinting Risk: High-precision timing can expose micro-architectural hardware and CPU performance characteristics for device fingerprinting.

• Mitigation: Implement timestamp fuzzing and rounding (e.g. matching HTMLMediaElement.currentTime with 2ms precision or aligning with browser timer resolution limits).

Alternatives Considered

• Browser Warning Events (e.g. onprocessinglag): Difficult to standardize a single threshold across applications with varying latency tolerances.
• Internal Queue Metric (e.g. queueDepth): Difficult to standardize across fragmented engine architectures and buffering models.
• Binary Status Flag (e.g. isRealTime): Lacks flexibility for applications to measure progressive degradation trends.

Browser support

http://chromestatus/5811907077472256