When can a browser context read a valid navigator.globalPrivacyControl? about gpc-spec HOT 4 CLOSED

@michael-oneill I'm not sure why per-origin control would require a promise? If the user makes that decision in the browser or the extension the browser would understand that at the point of page load. Are you thinking of some other user flow?

from gpc-spec.

The problem is how to make an internal record (i.e. a boolean) available so that script loaded synchronously on page initialisation so the browsing context gets an accurate value from the navigator.gpc property.The browser itself could maybe have an internal record, but it is hard for an extension to do it.

A callback does not have that issue becase it only needs to occur once the determination is made (by examining non-origin storage out of process i.e. in a background script), and a promise is the modern way to achieve that.

You can do it employing some localStorage but it is quite hard to get it right, and it uses up some of the origin's storage that may get overwritten or cleared.

I know this from developing a browse extension to implement the DNT API back in 2013.

from gpc-spec.

I understand where you're coming from, but I don't think that adding the overhead of a promise only to support extensions is a good compromise. Also, I would think that an allowlist managed by an extension should be at most of the order of tens of entries, thousands at the most (beyond that it's not a very good mechanism). This can readily by managed in memory and implemented synchronously.

from gpc-spec.

Its not only to support extensions, making the decision early enough to guarentee the signal would be hard for native browsers also.
The problem with synchronously using localStorage is it is accessable to other script, so could be amended by a third-party to simulate the presense or absense of a consent signal.
AdTech lobbyists would use the resulting uncertainty to justify ignoring it.

from gpc-spec.