Meta & Children's Online SafetyUnderage Enforcement Handover Tracker (Ongoing Commitments, Backlog, New Requests)
Raw text
Case 4:22-md-03047-YGR Document 3012-22 Filed 05/02/26 Page 1 of 9 Exhibit 132 Case 4:22-md-03047-YGR Document 3012-22 Filed 05/02/26 Page 2 of 9 Ongoing commitments, Deadlines, Plans Responsibilities/projects that we will continue overseeing until handover or completion Work Monitoring SLA and job inventories (enforcement, appeals) Taking actions to prevent SLA dropping, backlogs building, or jobs expiring Monitoring automation precisions and rates Acting to fix changes Support and triage for new requests Coordinating open SEVs Annotating dashboards to make CSER reporting easier Underage simile enforcement + monitoring Wrap-up (document) audits (basic + RR) Motivation Maintaining our commitments to enforce underage Responsible policies and unblock falsely checkpointed accounts On-call within a reasonable timeframe (48 hours). Maintaining an acceptable precision + recall to ensure false positives are low and ops demand is On-call within limits. Handover Plan Set a deadline for when we will stop doing this Set a deadline for when we will stop doing this Handover documented new requests or escalate exceptional cases to current roadmap. Making sure urgent company priorities are addressed, and other requests are documented for the handover team. Addressing outstanding enforcement gaps. Not being handed over, will continue until resolution Setting us up for CSER reporting (comitted to by end of September). N/A - completed before handover Unblocking project Simile work (launching August N/A - completed before handover 23rd). Wrapping up findings of our audits to be addressed N/A - completed before handover by handover team. Aid in handover. N/A - completed before handover Aid in handover. N/A - completed before handover Migrate SRT reporting (enforcement) jobs to Routing 3.0 (wiki) (Human Ops request) Commitment we made with HOP to be completed by end of Q3. N/A - completed before handover Security Risk Assessment - U13 Enforcement for FRL Accounts Unblocking Simile work (seperate GDPR related N/A - completed before handover security review process) Migrate legacy SRT renderers - T121019057 High priority task to ensure SRT jobs are still rendered correctly. N/A - completed before handover Migrate over buggy legacy flow users - T121031500 Ensure legacy flow is entirely empty of users so that deprecation can begin and no users are violating regulatory commitments. N/A - completed before handover Overhaul Underage wiki Create wiki for consolidated age jobs Open Questions 1. Are the new teams going to care about the SLA? Should we still be caring about the SLA? 2. Should we set a deadline where we will no longer be acting to remedy any ops capacity issues? 1. Will the new team take over reporting to CSER? Bug with users getting checkpointed multiple times T127394536 IG U13 Legacy flow deprecation Supporting external data requests - pulling data, completing stat review, assisting with transparency documentation Deprecation of dormant checkpoint policy Considered part of maintenance - some high-reaching users are being checkpointed multiple times. May be de-prid to backlog in favour of new team commitments. BE task - removal of legacy code and old appeal CFs, makes handover simpler May be de-prid to backlog in favour of new team commitments. Needed to comply with transparency requests Deprecation this indefensible policy as part of Roadmap to BASIC maturity. N/A - completed before handover (or moved to backlog) N/A - completed before handover (or moved to backlog) and Handover to new team once identified N/A - completed before handover 1. If the new team takes over CSER reporting, are they also going to be responsible for data transparency requests? Case 4:22-md-03047-YGR Document 3012-22 Filed 05/02/26 Page 3 of 9 Backloa Work that we have dropped and will now handover to new team. Item Number Task Underage Description Ensure legislation in 1 Spain and South Korea is being applied properly vve enforce this correctly in most places - but we don't have proper testing to guarantee this, and without a proper audit we are at risk of enforcement (or communication) gaps. Places for consideration: 1. Proper handling at DOB confession entrypoints 2. Proper handling during appeals review 3. Appropriate UX during enforcement and reporting (e.g "You must be at least X years old", or picking an age in FB form) 4. Any automations that may be relevant (e.g. auto-ignore where report says user is 13+) 5. Proper handling during underage L Task Links Other Links Motivation Comments AM to scope this work either way. We believe all major gaps T105424323 The age limit in Spain and South Korea is are covered, 14, rather than 13 in the rest of the world. but there may be some minor cases (e.g. user facing copy) that can be corrected. 2 3 4 Reduce U13 retention window to 60d Youth pXFN have advised us that it is not defensible to retain underage user data for 180d (the standard for admin scheduled deletions) - we need to coordinate with Deletion API and modify propagation behaviour to reduce this to 60d Fix escalated underage jobs tracking Add U13 end-to-end and integration tests We have a number of reports of users being underage that come from other report types that are escalated to us based on the reviewer's decision. We have very poor tracking of the sources of these jobs so are unable to map what the source of different escalated jobs are. Push blocking E2E tests (perhaps Westworld) T123747277 Investigation quip: We are unable to identify the source of https://fb.quip.com/1K8PAUgkdgAh escalated underage jobs. This means we can't verify that escalations are working as intended from all sources and can't be sure we are reviewing all suspected cases of an account being underage. Lockdown quip: https://fb.quip.com/by6PAn7KBTL7 AM to understand latest state on this (as this required coordination with owners of Deletion ΑΡΙ). Improve monitoring of 5 deleting underage accounts At the moment we have sql queries to monitor the % of accounts that should be deleted for being underage that are deleted. These are slow to load and lack any alerting. We should speed them up and add alerts, and ideally add tracking for the volume of accounts due to be deleted on a given date Underage audit: https://docs.google.com/document/ d/1iAKrguTEO5Rj2U2i_7gDWqCfu Anzk50iHtZVUE- _toY/edit?usp=sharing Previous issues relating to not deleting accounts on time: S272759, S276725 Dashboard widget: https://fburl.com/datainsights/hwub Біз Crucial to adhering to regulations is our deleting of underage accounts. We need to be monitoring and responding to this if it breaks to ensure regulatory compliance. 6 Improve monitoring of underage appeals Understand and remove (or pXFN align) soft- 7 linking enforcement against underage accounts for FB 8 Identify and resolve automation issues We lack visibility of a few important components of our appeals flow. 1. No visibility of the precision of the automations we run on submitted IDs 2. No visibility on the volume of underage appeals on Facebook 3. No visibility of the volume of manual ID reviews jobs that are created for IG appeals 4. No visibility of the average handle time for manual appeal jobs We uncovered the use of soft-linking to disable FB accounts for being underage. We are unsure why and want to understand what this is being triggered by We've observed that the automations we run on 3rd party reports don't always trigger when expected. This could be because of the legacy of our old automation accuracy holdout implementation. We need to investigate the cause of this and resolve it Underage audit: https://docs.google.com/document/ d/1iAKrguTEO5Rj2U2i_7gDWqCfu Anzk50iHtZVUE- _toY/edit?usp=sharing Underage dashboards: https://fburl.com/unidash/lq915801 Underage audit: https://docs.google.com/document/ d/1iAKrguTEO5Rj2U2i_7gDWqCfu Anzk50iHtZVUE- _toY/edit?usp=sharing In order to respond quickly to issues with the user experience in our appeals flow, we need better monitoring. Without this we will not be able to detect issues with appeal decision precision or spikes / drops in appeal volumes or average handle times that will needs ops capacity / indicate upstream issues. We have no ground truth for what an underage account is, so we cannot measure the precision of an approach where we remove soft-linked accounts. In the current situation, this approach may be indefensible Automations failing to run costs us both unecessary ops capacity, and also poor Workplace post: user experiences where accounts may https://fb.workplace.com/groups/14 be checkpointed repeatedly for being 26463750895412/permalink/1959 underage. This has led to at least one 675747574207/ high profile IG account needing internal assistance in resolving this repeat checkpoint behaviour Case 4:22-md-03047-YGR Document 3012-22 Filed 05/02/26 Page 4 of 9 Improve monitoring of 9 underage 3rd party reporting 10 We lack visibility of a few important components of our 3rd party reporting flow: 1. No visibility of the percent of escalated underage jobs that end up in our underage queue 2. No visibility of the percent of jobs that should be decisioned automatically, that are Audit the checkpoint We didn't manage to audit the checkpoint enrolment logic for users enrolment as part of our planned audit that change their DOB to sprint. To ensure it is working as an underage value understood, we should audit it Improve monitoring of 11 underage enrolments via DOB updates Logging is broken for reports coming from We lack visibility of a few important components of our DOB enrolment flow. 1. No visibility of the volume of date of birth change requests that are made for an underage date of birth 2. No visibility of the rate of underage date of birth changes that result in a checkpoint We rely on single_review_tool_main for realtime monitoring of incoming report volumes. We split it using 12 escalations and IG in-app object_family_member to visualise splits reporting in across FB and IG. This column isn't set single_review_tool_main properly for escalations and for IG in-app reporting. Apply NLP to SRT underage enforcement 13 jobs to automate review of age admittance in user bios Update DOB to the DOB of the submitted ID 14 when a user successfully appeals the underage checkpoint 15 16 17 Reduce IDV match criteria to 1 of 3? Restrict Adult Classifier enforcement automation policy to supported regions Add the ability to include content from messages or posts in our underage enforcement review jobs Align FB u13 flow 18 content with what was approved for IG Part of our review policy for instagram user reports is to see if the reported account has an admittence of age in their bio. We've been discussing using NLP to automate this process and reduce handle time for manual review jobs On IG we don't update DOB when appeal is successful, on FB we do but we believe it may be broken (as updating DOB is blocked when account is restricted). Let's get this working in both places and add proper E2E testing to protect this. Also add for FRL. On FB we currently match for 2 of 3 of {name, profile-pic, dob} - given that during U13 appeals we often can't trust the dob - Without monitoring whether underage escalations are arriving in our queue we ttps://docs.google.com/document/ will be slow to respond to issues in this d/1iAKrguTEO5Rj2U2i_7gDWqCfu pipeline that could lead to reports of Anzk50iHtZVUE- _toY/edit?usp=sharing underage accounts not being reviewed. Likewise, lacking monitoring of how well our automations are running means we are unaware of issues as they happen Users changing their date of birth to an underage value is the major source of https://docs.google.com/document/ accounts being checkpointed for being d/1iAKrguTEO5Rj2U2i_7gDWqCfu underage. Knowing how the system for Anzk50iHtZVUE- _toY/edit?usp=sharing this is working, and being aware of issues or gaps, will help us ensure we can respond to issues in our primary source of account takedowns. Without monitoring the volume and rate of date of birth changes that are ttps://docs.google.com/document/ underage, and that result in an underage d/1iAKrguTEO5Rj2U2i_7gDWqCfu checkpoint, we have no visibility of Anzk50iHtZVUE- _toY/edit?usp=sharing Workplace post: https://fb.workplace.com/groups/93 6804576456887/permalink/12372 T124731450 78320176171/ T123416896 T123105786 we may want to relax to just matching one T121798765 of this set - else users with profile pictures that do not fully display the user's face will aet reiected. One of the automations we run on reports of users being underage relies on the adult classifier model from core dimensions. At the moment on Instagram we are calling this model for users in unsupported regions T120684412 and actioning them based on their stated age instead of realising they have no prediction and skipping this automation policy for them. At the moment our third party report review doesn't include any message or post content from users, so totally lacks any insight into place where users have admitted to being underage. Adding these features may help the precision of our enforcements. Reels/stories also apply here. IG content was recently overhauled and aligned with Youth pXFN - we should do the same with FB. T119369460 T119132544 Meeting notes from initial discussion: whether our systems for self-confession are working as intended. There could be an unknown number of users we should be checkpointing that we aren't Realtime monitoring of report volumes is vital in helping us respond to breaks in our reporting flows or to alert ops to spikes in demand. Diagnosing and fixing the issue with logging is important to ensure we maintain our ability to respond quickly Our Instagram review protocol asks reviewers to look at the account bio for https://docs.google.com/document/ an admission of being underage. This is d/1klkowzrXztspsJRKcL1H02n16gr likely a straightforward tasks for NLP and will speed up our review jobs, meaning we need less ops capacity. o_1WMxdU- zyNiM5Y/edit?usp=sharing By failing to update account DOBs after they have been ID verified, we are facilitating age misrepresentation which could have harmful downstream effects. Ignoring reports of accounts being underage based on their stated age is a poor approach and means we are likely ignoring reports of many legitimately underage accunts. Our review protocol is currently based almost exclusively on account photos. If the account in question has admitted to being underage via message or post, we may still end up ignoring them despite them self-admitting. This is quite an indefensible enforcement gap Case 4:22-md-03047-YGR Document 3012-22 Filed 05/02/26 Page 5 of 9 Support inclusion of 19 user's bio in FB report jobs Implement job stacking 20 for underage reports Align underage country 21 calcuation with Youth pXFN 22 Handle IG to IG U13 propagation Audit U13 escalations 23 that lead to immediate disables 24 25 Explore Age Verification Menu / Yoti Selfi integration in underage flows Actor-centric account reviews Enable captcha 26 protection on FB reporting contact forms 27 Establish U13 SEV guidelines In IG reporting jobs we assess two things to decide if an account should be underage checkpointed: - If there appears to be a clear account owner who is underage from the photos (including profile picture) - If there is an admittance of being underage in the bio In FB jobs we do not search the bio - only the photos are considered. We ought to achieve parity with both platforms, and Youth pXFN have also asked us to do this. Things to do/consider: 1. File a LaMa to get approval (should be easy as Youth pXFN originally requested this) 2. File an Ops request to handle small increase in AHT 3. Surface the bio content in the SRT job 4. Queues will either need to be marketised (they are not currently in FB) OR we need to use auto-translation 5. Change the decision tree to ask if there's an admittance in the bio We're checking for underage enforcement eligibility in all different places, some places in distillery use the GeoAPI to get T119131329 T116542084 the country, other places use the request IP T115985075 country, others use the registered country. Let's place all these checks in one thrift service and call it from everywhere. We probably shouldn't be escalating to immediate disables - we have a policy to always allow users to appeal for 30 days. Let's figure out where we have places that we're doing this, record them below and discuss if they're justified. Explore reviewing hard-link FB and IG accounts when reviewing a report of an account being underage to ensure we're using all available information where possible T112855432 T114122201 T124745948 T124434942 Using the bio on Instagram but not on Facebook for account reviews means our enforcement is not in parity across our apps and means we may be missing important information in deciding to checkpoint an account on FB Using disparate sources of information for country means we may be incorrectly handling underage accounts in countries where the requirements are stricter (e.g. U14 in Spain and S.Korea) and could have downstream impacts on the routing of our underage reports to the correct review queues This is a poor user experience and given we lack visibility into the precision of our enforcement (as we lack a ground truth) is likely too extreme an approach Age Verification menu could provide options for reducing ops demand in our 3rd party review flow, but more important can reduce the high friction in our account appeals flow, reducing the impact on voice The underage violation type depends on the user's age and is surface-agnostic. We should be using all available information to identify if a user is underage rather than silo-ing our reviews to the surface they were reported on At the moment our underage reporting contact forms on FB are not as well protected against scripted attacks as they could be. We've previously had a https://www.internalfb.com/launch_ SEV because of scripted attacks on our manager/reviews/L1116429API LAMA: SEV guidelines meeting notes: https://docs.google.com/document/ T111858912 d/1Q0MwyqGrBlWtl2elaCrqF6Jkfly r8UBP8yHKwNOtnas/edit?usp=sha IG reporting form, which is now captcha protected. We should aim to achieve parity between the apps and prevent future SEVs. We have no objective measures of when we should be opening a SEV. This leads to slower response times when it comes to issues we should be escalating. 28 IG-SURF monitoring IG-SURF (the in-app underage reporting flow for IG) is currently rolled out to 1% of prod but we don't have much logging or alerting around this flow - it will be crucial to have this before rolling out any further. ring Case 4:22-md-03047-YGR Document 3012-22 Filed 05/02/26 Page 6 of 9 29 Prevent accounts being checkpointed for underage multiple times at UFAC config level Invest in further 30 automations for enforcement jobs See quip doc. Reduce FP rate of 31 business accounts for U13 Applying the same friction that Age Platform applied for Age Collection to our edit DOB flows - with the aim of reducing underage admittance FPs Understand why such a high proportion of 32 reported accounts are reported multiple times by the same reporters Understand why such a high proportion of 33 reported accounts are reported multiple time by different reporters 34 35 Deprecate dormant account policy Escalations from group review jobs Discuss improving action 36 rate of oculus abuse reported FRL accounts. Explore softlink 37 matching to reduce recidivism 16% of accounts reported for being underage are reported multiple times by the same reporter. We don't know if this is driven by abusive behaviour on behalf of the reporters, or a lack of understanding / ease in our reporting flows. 8% of accounts reported for bieng underage are reported multiple times by different reporters. We are less likely to checkpoint these accounts than those reported by only a single reporter. We don't understand why this is. Deprecate the dormant account automation policy across all markets. There are cases where users are being reported from group posts for admitting being underage. As a minimum we should offer the ability to escalate these jobs to Underage queue - perhaps including evidence to increase action rate. POC is If there has not been a direct admittance of being underage in an oculus abuse report then we instead report the hardlinked FB account (if exists) for review - but the action rate here is extremely low. We should consider other signals that can be used (e.g. number of times reported - if they seem natural, other signals like height and sound of voice etc from the headset) to improve the action rate of reported FRL accounts. FEP can match with retrospective takedowns from the last 90 days - so if an account is taken down and the user spins up a new one - it can be detected. Comments discussion here https://fb.workplace.com/groups/14 26463750895412/posts/1959675 747574207/?comment_id=197121 4809753634&reply_comment_id=1 971331279741987 Z Accounts being checkpointed for being underage repeatedly after clearing them is a poor user experience and has led to at least one issue with a high profile Instagram account requiring internal intervention. We should prevent this at the checkpoint level rather than relying on our third party report automations to limit this We have flat ops capacity this half. Finding a way to reduce our ops demand https://fb.quip.com/gCniAy10MDN with enforcement job automations frees up capacity that we may be able to use for iniatives to drive down underage prevalence Anecdotally we know many business accounts are checkpointed for being underage due to mistakes. Given these are high value users, we should be doing more to protect them from being enrolled in this very high friction checkpoint Understanding why users are reported repeatedly by the same people may help Workplace post: https://fb.workplace.com/groups/14 us protect them from abuse, or 26463750895412/permalink/1968 alternatively, identify pain points in our 890873319361/ Workplace post: https://fb.workplace.com/groups/14 26463750895412/permalink/1968 890873319361/ Policies.hs See Groups SRT Jobs:179728374335162, 304958561121251, 645517163495754, 421372736094374, T117141515 294353098804373 T124434880 https://docs.google.com/spreadshee ts/d/1vNZoEfqJEhD1A1cHqYG8mZ PqsDqHLmrxcjLbu6Cx6a0/edit#gid =404447256 Speak with VR Integrity Speak with Enforcement Propagation team. reporting flow that is leading to reporters misunderstanding them In theory, multiple people reporting an account for being underage should be a strong signal the account is underage. In reality, it is the opposite. We may be lacking key information in our review protocol that is leading to this outcome and investigating these cases may unearth components we should be considering in review The dormant account policy automation (auto checkpoint reported accounts which have been inactive for over 30 days) was only ever shipped as an emergecy solution to a large backlog it is not defensible long term as there's no known correlation between account dormancy and underage users, nor is there any correlation expected. It's not defensible to be ignoring cases of direct and public admittance of being underage when these users get reported. There will likely be lots of cases where the user sounds underage and will be obviously underage to other users, but we will dismiss the reports because we don't have direct evidence. We have lots of issues, particularly on IG, with users spinning up new accounts as soon as their last one was taken down. This is hard to defend and we can detect these with FEP. Deprecated in all but 3 markets- waiting on ops approval for the final 3. Other Age Case 4:22-md-03047-YGR Document 3012-22 Filed 05/02/26 38 Unify FB report job creation In places where jobs are created not via the CF - we have to create dummy CF objects in order to file reports because this is what the report handler requires - this is hacky and we should change it so that it doesn't have to take a CF object. T114670094 BE task Page 7 of 9 Develop 'Adult Age We have already established Adult Age Misrepresentation (Adults pretending to be 50 Misrepresentation' VT & teens) as a new violation type. We still Enforcement need to development enforcement for this violation. https://www.internalfb.com/cases/1 036903 AAM is a serious violation from child https://l.facebook.com/l.php?u=http safety perspective as evident from s%3A%2F%2Fdocs.google.com%2 linked case study, we currently do not Fdocument%2Fd%2F15bky7UAQ enforce proactivly on age lying. T105935149 MtdG8DBLx_6PnNqQNsiJ SecoteS2 This is also linked to Teen As x6_N1TQ%2Fedit%23&h=AT2rsN Misrep (Teens pretending to be adults) 6VsW54DBdYcQRUmzOJjk0NGJm both problems will benefits from L2dGpNct17ZB1dWo_dls_oCicBKP deleloping proactive enforcement for uKKimJnVDi5mBjvfdC5f9lqUF5pDy age lying. mYlnEarCSwud5kTTeYAbnRBi0rv_ xcgVjD__7IqQYe505_aG 51 52 53 54 Fix EditDOB Auto- Classifiers Audit age transition blocks Audit edit DOB appeals systems Improve monitoring of edit DOB appeals Improve monitoring of 55 account center edit DOB restrictions Improve monitoring of 56 legacy edit DOB restrictions Auto-close edit DOB 57 requests that are older than 30 days We run classifiers to determine if we should permit a user's date of birth change. The use of this classifiers for this purpose is broken and means we aren't gating date of birth changes based on our adult classifiers or inappropriate-interactions with children classifier. As part of the edit DOB flows we run checks to block a DOB change request if it meets logic surrounding age transitions e.g. changing DOB to an under 18 value. We haven't been able to audit these checks to ensure they are working as intended We were unable to audit our edit DOB appeals flow fully during our Reliability and Response audit. The unaudited systems: 1. Appeals contact forms 2. Authenticity Platform Integration and SRT job creation 3. Decision handler 4. Birthday updates vve LaCK VISibiuty от key components of our edit DOB appeals flow 1. No visibility of the rate of users that submit a DOB change request that is blocked, that go on to appeal 2. No visibility of the volume of submitted appeals that fail i.e. don't result in an appeal job being created 3. No visibility of the average handle time of a manual ID review job for a DOB change appeal 4. No visibility of appeal approval, rejection, or pending rates 5. No visibility of appeal automation We lack visibility of the volume of edit DOB requests blocked in account center by the validation logic We lack visibility of the restrictions we apply to DOB change requests in our legacy edit DOB flows 1. No visibility of the volume of requests blocked by frequency limits 2. No visibility of the volume of requests blocked by age transition blocks 3. No visibility of the volume of requests blocked by auto-decision classifiers Automatically close out Edit DOB requests that are in inventory for over 30 days.... perhaps the user can get a email to retry submitting the request. T115611755 https://docs.google.com/document/ d/1pYGmSTOy41fwd5-9UL- CElz898mR_kwuk- ugNovv70w/edit?usp=sharing https://www.internalfb.com/intern/ wiki/Attribute_Misrepresentation/Ini tiatives/EditDOB/(Edit_DOB)_Age_ Transitions/ https://docs.google.com/document/ d/1pYGmSTOy41fwd5-9UL- CElz898mR_kwuk- ugNovv70w/edit?usp=sharing https://docs.google.com/document/ d/1pYGmSTOy41fwd5-9UL- CElz898mR_kwuk- ugNovv70w/edit?usp=sharing https://docs.google.com/document/ d/1pYGmSTOy41fwd5-9UL- CElz898mR_kwuk- ugNovv70w/edit?usp=sharing https://docs.google.com/document/ d/1pYGmSTOy41fwd5-9UL- CElz898mR_kwuk- ugNovv70w/edit?usp=sharing Case 4:22-md-03047-YGR Document 3012-22 Filed 05/02/26 Page 8 of 9 Ensure we have visibility 58 over Fb EditDOB auto- accepts 59 60 Prepare for new regulatory standards pending for Teen Age Misrep Add logging for age/iic-classifier based FB EditDOB auto-accept/rejects Account centre work [Placeholder] Scope and build for U18-as- 018 (Teen Age Misrep) as we get clarity on new regulations (likely, develop an integrity. aware U18 signal to support product experiences for minors). T125285383 Another compliance case Action: Prioritize and work on this Case 4:22-md-03047-YGR Document 3012-22 Filed 05/02/26 New Requests New requests from partners - these will be reviewed once per week and either triaged into backlog or escalated to be worked on by us (dependent on urgency). Project Description Request POC Due to recent regulatory scrutiny we may Support IG-SURF rollout in limited markets need to rollout the in-app flow in some markets. WhatsApp is being integrated with the What do you need from us? Support rolling out and monitoring. - Potentially some heavier lifting shipping automations/optimisations to offset ops demand increase If urgent - why? Page 9 of 9 Notes Upcoming regulator investigation A request from a policy/legal group during a regulator inquiry quite some time ago, pretty sure this inquiry is wrapped up now and we did not choose to pursue further. Can be considered dropped WhatsApp underage enforcement for WAFFLE Age enforcement for Meta work profiles Youth Ads UK External Data Request for U13 Takedowns FTC U13 Reporting Numbers accounts centre - which now means that we have signal when users are underage, Unclear - potentially just support we should be enforcing as we do with other accounts (e.g. integrated with FEP) Fresh discussion with team working on Work accounts We are launching a new youth ads technology, need to understand risks of adults changing their birthdays to <18 in order to be in youth ads experience The ICO (UK regulator) has made a Response For Information (RFI) on the number of underage accounts we have removed across some time period (specifically UK accounts) Request for annual US-only data about the number of "contacts, complaints, or inquiries" that the company has received related to use of IG or FB by a child under 13. An Integrity priority is reducing impact on benign tenured users. Underage is one of Tenured user compromised-then-disabled the largest causes of tenured user account Attend to CCSR (Critical Commitment Safeguard Review) Requests disables. We suspect much of this is actually compromised activity. As part od the Sensitive Data Use Audit the SDU team identified EditDOB contact form flow as one of the flows where user uploads an ID. CCSR request is audit the flows and have guards in place to prevent misuse of these uploaded IDs Unclear - potentially just support Information about how birthday change appeals work, specifically how age prediction is incorporated - which versions of age prediction (thresholds, etc) Computing numbers, taking these through stat review, collaborating on data transparency request Computing numbers, taking these through stat review, collaborating on data transparency request Sample of 300 users with linf > 365 disabled for Underage, split by reason (e.g. changed DOB on account vs user report) Prepare an audit document with code pointers and then work with the team to put the safeguards and evidence in place. This has been flagged as a topic in a review with R&P leads on 8/18/22. Just need a simple answer Not had any further contact with this team, they have not reached out to use since. Not had any further contact with this team, they have not reached out to use since. Not had any further contact with this team, they have not reached out to use since. Regulator data request Complete. Regulator data request Complete. Complete. Estimated effort: 20 days for 1 eng