Conflicting Google hashing implementations and invalid SHA-256 test vectors, In #1167 and #1168

Problem

In #1167 and #1168, Google confirmed that hashed_first_name, hashed_last_name and hashed_street_address should be calculated from:

UTF-8(NFC(lowercase(trim(original_value))))

Internal whitespace, punctuation, digits and diacritics should be preserved.

This confirmation conflicts with existing Google documentation and language examples that remove internal whitespace, punctuation, digits or symbols before hashing. Following different official Google sources therefore produces different hashes for the same customer data.

The SHA-256 vectors supplied with the clarification are also incorrect. They cannot be reproduced from the input strings shown by Google.

Reproduction

The same calculation was performed with:

• JavaScript: Node.js crypto.createHash() and Web Crypto subtle.digest() with TextEncoder
• PHP: hash('sha256', $value)
• Python: hashlib.sha256(value.encode('utf-8'))
• OpenSSL and sha256sum

All implementations returned the values in the Standard SHA-256 column. None returned the values published by Google.

There is also an unambiguous error across the two responses: Google assigned the same digest, 6f19430c..., to both jan<TAB>kowalski and anna<TAB>maria. These are different byte sequences and their SHA-256 digests are different.

Broader concern

This is not only an isolated error in one table. The confirmed method differs from other official Google documentation and code samples, while the vectors intended to define the correct method are themselves invalid.

Without valid canonical vectors, developers cannot determine which Google implementation matches production behavior. This creates a reasonable concern that other official samples or integrations may also generate incorrect hashes. Such hashes remain syntactically valid and can be accepted by the APIs while silently failing to match.

Required clarification

Please provide:

1. Correct SHA-256 vectors for #1167 and #1168.
2. The exact pre-hash bytes and runnable code used to generate every corrected vector.
3. One authoritative hashing and preprocessing specification shared by Google Ads API, Data Manager API and GA4 Measurement Protocol, or an explicit specification of their differences.
4. Confirmation that Google's production systems use standard FIPS 180-4 SHA-256 without an undocumented transformation, salt, HMAC or additional hashing pass.
5. A review and correction of all official language examples and field documentation that currently produce different hashes.

References:

• #1167
• #1168
• Google Ads API: https://developers.google.com/google-ads/api/docs/conversions/upload-offline#normalize_and_hash_user-provided_data
• Data Manager API: https://developers.google.com/data-manager/api/devguides/concepts/formatting
• GA4 Measurement Protocol: https://developers.google.com/analytics/devguides/collection/ga4/uid-data
• NIST FIPS 180-4: https://csrc.nist.gov/pubs/fips/180-4/upd1/final

Start by reviewing issues #1167 and #1168 alongside the linked Google Ads API, Data Manager API, GA4 Measurement Protocol, and FIPS 180-4 references. Done requires an authoritative preprocessing and hashing specification, reproducible corrected vectors with code and bytes, and confirmation or correction of the affected official examples.