Drive marker PII sanitization from schemas

[fatadel]

Main | Deploy preview

Markers requiring PII sanitization were identified through hardcoded data.type checks. Putting PII directives in marker schema fields removes type-specific branching and makes sanitization generic.

Closes #6290

---

Profile

Published using Prod | Published using Deploy Preview

[codecov]

Codecov Report

❌ Patch coverage is 95.45455% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.88%. Comparing base (18e46d8) to head (b5c6842).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
src/profile-logic/marker-data.ts	92.42%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6291      +/-   ##
==========================================
+ Coverage   83.84%   83.88%   +0.04%     
==========================================
  Files         352      353       +1     
  Lines       37807    37905      +98     
  Branches    10674    10683       +9     
==========================================
+ Hits        31698    31797      +99     
  Misses       5679     5679              
+ Partials      430      429       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[canova]

Thanks a lot! I have some high level schema related question, let me know what you think!

[mstange]

I haven't looked at the code yet but I'd like to point out #5301 which has a related proposal.

[canova]

@mstange ah thanks! I forgot that this was filed. Structurally it's actually very similar to what I suggested (minus the naming differences) but I forgot the sanitized-string one. It looks nice

[fatadel]

@mstange ah thanks! I forgot that this was filed. Structurally it's actually very similar to what I suggested (minus the naming differences) but I forgot the sanitized-string one. It looks nice

Let's handle sanitized-string in that issue then and keep this one's scope to the one we already defined?

[fatadel]

Thanks for the review, @canova! I've addressed the issues now.

[fatadel]

Thanks for the feedback, @mstange! Done now ✅

[mstange]

I don't see an upgrader; what happens if you re-upload an existing old uploaded profile and uncheck some checkboxes in the re-upload?

[mstange]

Also does there need to be code in profile processing which adds these annotations when converting from a Gecko profile?

[fatadel]

@mstange Both concerns are valid. My bad. Fixed now.

[canova]

Thanks, looks good to me!

[canova]

Re extension id removal code: after thinking about it again, I think we should have converted these extension related markers to real marker schema types with their own payload and convert them in the upgrader + the processing phase. This would allows us remove the markerName need, and we could fix the gecko side later and have a gecko profile format bump later.

Sorry for not catching it sooner!

[fatadel]

Re extension id removal code: after thinking about it again, I think we should have converted these extension related markers to real marker schema types with their own payload and convert them in the upgrader + the processing phase. This would allows us remove the markerName need, and we could fix the gecko side later and have a gecko profile format bump later.

Sorry for not catching it sooner!

I'll create a follow-up PR before we deploy, no worries.