There is a vital global conversation underway about how to best protect young people online. Governments worldwide are introducing a range of proposals, from restrictions on personalized feeds and screen time to outright social media bans. While these proposals share a crucial goal that we support, they often overlook a major practical hurdle: how platforms can safely and accurately verify a teen’s age.

For any of these proposals to succeed, apps must know the age of their users. But proving age on the internet remains a complex, industrywide challenge. Many teens don’t have traditional government IDs, and requiring people to upload sensitive personal documents to every individual app they download creates significant privacy risks. Furthermore, smaller or emerging platforms often lack the robust security infrastructure required to safeguard this data, which can inadvertently expose millions of people to security breaches.

Protecting young people online should not come at the expense of privacy. That’s why parents and safety advocates overwhelmingly support a simpler, more secure approach: centralizing age verification and parental consent in the app store. By handling age verification once at the device level, we can provide young people with consistent, age-appropriate experiences across the many apps they use while keeping their personal data safe.

Unintended Consequences of Bans

We understand the immense pressure lawmakers face to act, and we respect every government’s right to decide what’s best for their citizens. But any truly viable safety proposal must solve the underlying challenge of how to uniformly and accurately understand a person’s age. 

Australia’s under-16 social media ban highlights just how complex this logistical piece remains. Because the policy was introduced without an established, privacy-preserving method for age verification, it has led to the unintended consequences safety experts feared: reports of teens bypassing inconsistent age checks, circumventing restrictions, and migrating to unmonitored apps and gaming sites that fall outside the scope of the ban.

This shift actually makes the internet less safe for young people. When teens access platforms through workarounds, they lose the built-in protections, like Teen Accounts on Instagram, Facebook, and Messenger, specifically designed to keep them safe. These concerns are shared globally; a joint statement from over 370 international academics and privacy experts warned that enforcing broad bans carries massive risks to privacy and autonomy if age verification isn’t built on a coherent, secure foundation. They’re right. If we get this wrong, we create entirely new risks for everyone online.

While Meta will always comply with local laws, current legislative proposals simply do not address these complex age issues — and that should give global lawmakers pause.

The Path Forward

There is a practical framework that directly answers the complex logistical challenges I’ve laid out: centralizing age verification and parental approval at the app store level. App stores are already the gateway through which teens access every app on their phones. And we don’t have to start from scratch. Apple and Google already collect age information when a parent sets up their teen’s phone, and they already have systems in place to obtain parental approval before teens can make purchases. We’re simply asking that this same mechanism be extended to all app downloads. By verifying a person’s age just once at this device level, the phone itself acts as a single, secure checkpoint. This allows parents to seamlessly approve or deny downloads across all platforms simultaneously, removing the need for people to upload sensitive personal documentation to dozens of individual apps.

Over the past year, more than half of U.S. states have introduced app-store age legislation of this kind, with Texas, Utah, Louisiana, Alabama, and California already enacting versions of it — driven largely by parents. Momentum is also building in Washington, where the App Store Accountability Act is advancing through Congress.

Public support is clear: polls show that 85% of American parents support requiring app stores to verify age and get parental approval before teens download apps. Eighty-two percent of Australian parents and nearly 75% of parents across eight European countries support parental approval. Major industry players like Match Group, X, Snap, and Pinterest have also endorsed this approach.

The Core Question

We will continue to comply with laws around the world as they evolve. But the conversation should always come back to the same core question: how will we, as a society, reliably verify age on the internet? Until we answer that question honestly, everything else is a workaround.

The post Why Social Media Bans Alone Can’t Solve the Age Verification Dilemma appeared first on Meta Newsroom.

The Django Software Foundation is happy to share the contributors selected for Google Summer of Code 2026.

This year, we received over 200 proposals from contributors across the world. The level of detail and thought in these proposals made the selection process both exciting and challenging.

Accepted Projects

We’re pleased to announce the following projects:

Implementing an experimental API framework for Django core

Contributor: Praful Gulani
Mentor: Andrew Miller

This project explores an approach to introducing experimental APIs in Django by modernizing DEP 2 and defining an opt-in model.

Add support for table-valued expressions in the ORM

Contributor: p-r-a-v-i-n
Mentors: Bhuvnesh Sharma, Jacob Walls

This project develops a way to join against table-valued expressions such as Subquery() or PostgreSQL functions like generate_series() within the ORM.

Unified dark mode and UI consistency for Django’s issue tracker

Contributor: Keha Chandrakar
Mentors: Saptak S, Sarah A

This project adds dark mode support to Django’s issue tracker and brings it closer in visual consistency to the main Django website.

Switch to Playwright tests for integration testing

Contributor: Varun Kasyap Pentamaraju
Mentor: Sarah Boyce

This project focuses on improving Django’s browser integration testing by transitioning from Selenium to Playwright.

Each of these projects focuses on areas of Django that we’re looking to improve over the coming months. Contributors will work closely with their mentors, participate in regular check-ins, and engage with the broader Django community.

To everyone who applied

Thank you to everyone who submitted a proposal this year.

We know the effort it takes to explore ideas, write proposals, and engage with the community. Not being selected this time does not reflect the overall quality or potential of your work.

Given the number of applications and that the program is run by a small group of volunteers, we’re not able to provide individual feedback on proposals. Selections are based on a combination of factors including alignment with project goals, feasibility within the program timeline, prior contributions, and clarity of the proposal.

We encourage you to stay involved. Many contributors to Django started in similar positions. Keep building, keep contributing, and stay connected with the community. There will always be more opportunities.

What’s next

The community bonding period has begun, and contributors will soon start working on their projects. We’ll share updates as the program progresses and highlight the work along the way.

Please join us in welcoming the selected contributors and supporting them during the program.

In accordance with our security release policy, the Django team is issuing releases for Django 6.0.5 and Django 5.2.14. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

CVE-2026-5766: Potential denial-of-service vulnerability in ASGI requests via file upload limit bypass

ASGI requests with a missing or understated Content-Length header could bypass the FILE_UPLOAD_MAX_MEMORY_SIZE limit, potentially loading large files into memory and causing service degradation.

As a reminder, Django expects a limit to be configured at the web server level rather than solely relying on FILE_UPLOAD_MAX_MEMORY_SIZE.

This issue has severity "low" according to the Django security policy.

This issue was originally highlighted by Kyle Agronick in Trac. Thanks to Jacob Walls for following up and reporting it.

CVE-2026-35192: Session fixation via public cached pages and SESSION_SAVE_EVERY_REQUEST

Response headers did not vary on cookies if a session was not modified, but SESSION_SAVE_EVERY_REQUEST was True. A remote attacker could steal a user's session after that user visits a cached public page.

This issue has severity "low" according to the Django security policy.

CVE-2026-6907: Potential exposure of private data due to incorrect handling of Vary: * in UpdateCacheMiddleware

Previously, django.middleware.cache.UpdateCacheMiddleware would erroneously cache requests where the Vary header contained an asterisk ('*'). This could lead to private data being stored and served.

This issue has severity "low" according to the Django security policy.

Thanks to Ahmad Sadeddin for the report.

Affected supported versions

• Django main
• Django 6.0
• Django 5.2

Resolution

Patches to resolve the issue have been applied to Django's main, 6.0, and 5.2 branches. The patches may be obtained from the following changesets.

CVE-2026-5766: Potential denial-of-service vulnerability in ASGI requests via file upload limit bypass

• On the main branch
• On the 6.0 branch
• On the 5.2 branch

CVE-2026-35192: Session fixation via public cached pages and SESSION_SAVE_EVERY_REQUEST

• On the main branch
• On the 6.0 branch
• On the 5.2 branch

CVE-2026-6907: Potential exposure of private data due to incorrect handling of Vary: * in UpdateCacheMiddleware

• On the main branch
• On the 6.0 branch
• On the 5.2 branch

The following releases have been issued

• Django 6.0.5 (tarball | checksums)
• Django 5.2.14 (tarball | checksums)

The PGP key ID used for this release is Sarah Boyce: 3955B19851EA96EF

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance, nor via the Django Forum. Please see our security policies for further information.