Replace `Sec-` header with more industry specific prefix

[amicus-veritatis]

Related: #207, #183

In #207, there was an explanation regarding the use of Sec-, indicating that the contents of the header are chosen by the browser, rather than by arbitrary JS code that happens to make network requests.

While I acknowledge that data integrity is critical for the advertising industry and that there exists a legitimate concern (e.g., AdNauseum), my opinion is that we need an alternative, industry-specific, and semantic prefix for forbidden headers.

As I understand, the primary purpose of the sec- prefix is to prevent malicious websites from convincing user agents to send forged metadata along with requests. It is fundamentally a security-related prefix.

I believe that using an industry-specific, intuitive and semantic prefix would help stakeholders (publishers, users, developers, regulators, etc.) of the Topics API understand the purpose and objective of the header. It does not necessarily mean we should abandon the goal of maintaining data integrity. Therefore, if it should be a forbidden header, I propose a new, industry-specific, semantic, and intuitive prefix: Analytics-.

[michaelkleber]

The point of the Sec- header is that all browsers already do not allow any JS to modify that header. We can't just create a new prefix with that property — that would require going back in time and getting every browser to agree to not allow JS to set those header names a long time ago.

[amicus-veritatis]

The point of the Sec- header is that all browsers already do not allow any JS to modify that header. We can't just create a new prefix with that property — that would require going back in time and getting every browser to agree to not allow JS to set those header names a long time ago.

So it is a matter of backward compatibility. Thanks for your explanation.