Re: [Performance Timeline] Final change to PerformanceEntry.navigationId

I wasn't part of the earlier discussion, so don't have much context, but if
you're looking for something like UUID that is time ordered and less
compute intensive, consider UUIDv7:
https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-01.html#name-uuidv7-layout-and-bit-order

Philip

On Thu, Oct 12, 2023 at 4:54 PM Ian Clelland <iclelland@google.com> wrote:

> Hey folks,
>
> When I presented two weeks ago at the WG call, I presented a number of
> options for the navigationId field that we want to use to identify certain
> performance timeline entries.
>
> Presentation:
>
> https://docs.google.com/presentation/d/10h4T_JGrBp5db_1owgqBFTCYyydmsEV7PD-l2YG4jjo/edit?usp=sharing
> Issue:
> https://github.com/w3c/performance-timeline/issues/182
> Spec PR:
> https://github.com/w3c/performance-timeline/pull/192
>
> At the time, we discarded most of the options for different reasons:
>  - counters quickly become relied upon by developers, despite any spec
> warnings that they should not
>  - UUIDs could be expensive to produce, and lose all ordering
>  - objects don't have great equality semantics
>
> I left the meeting with rough consensus that a string identifier, of the
> form "{type}-{starttime}" would be easy to compute, easy to compare, well
> ordered, and unique.
>
> However, in talking with Yoav and Yash, who is heading up the Resource
> Initiator project (which has similar requirements to link timeline entries
> through some identifier), we realized that this id format wouldn't be
> sufficient to uniquely identify resource timing entries, as the
> starttimes could easily collide.
>
> *However*, we realized that we already have the idea of a counter which
> deters developers from relying on it, in the interactionId field in Event
> Timing. That spec uses a coarsely-incrementing integer, which starts at a
> random value, and increments by a small (but definitely >1) value each time
> a new ID is required. I think that this would be sufficient for
> navigationId, as well as for resource timing entries, and have reworked the
> spec to use that instead.
>
> I'd still love comments, either on this thread or in gitHub issues, if
> there are ways to improve this; there are a couple of notes in the privacy
> section now, about avoiding either fingerprinting or cross-window leaks,
> but I think that this is sound, and I'm hoping it'll stick.
>
> Ian
>


-- 
hello world