Wayne Thornton commented on a discussion on cpukit/include/rtems/age_verify.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1137#note_145752 > + > +#include <rtems.h> > + > +#ifdef __cplusplus > +extern "C" { > +#endif > + > +// These age brackets are arbitrary and can be changed as needed to comply > with the law of different regions. > +// Ultimately, I think that we could even just have a single "over 18" > bracket, but this allows for a little more > +// granularity if desired. Changes to the rtems_age_set_bracket logic in > age_verify.c would be needed if this occurs. > +typedef enum { > + AGE_UNDER_13 = 0, > + AGE_13_TO_18 = 1, > + AGE_18_TO_24 = 2, > + AGE_OVER_24 = 3 > +} rtems_age_bracket; Just a quick heads-up that I updated the MR to adjust the rtems_age_bracket enum. Initially, the brackets I proposed were a bit arbitrary. However, after reviewing the exact chaptered text of the California Digital Age Assurance Act (AB-1043) and the upcoming Colorado legislation, I updated the enums to strictly mirror the statutory boundaries set forth in those laws. This ensures the API provides the exact legal minimums required to shield downstream OEMs from the $7,500/user non-compliance fines. For context on why these specific four brackets are legally required for the API: AGE_UNDER_13: This maps to the federal COPPA threshold. These users require verifiable parental consent. This signal dictates that downstream apps must strictly disable telemetry and tracking. AGE_13_TO_15: This maps to state-level Age-Appropriate Design Codes (AADC). It legally requires downstream applications to default to the highest privacy settings, disabling addictive feature targeting for young teens. AGE_16_TO_17: Older minors. They possess more digital autonomy under the law but still cannot legally agree to binding EULAs, enter contracts, or access adult features. AGE_18_PLUS: The legal age of majority where standard EULAs, data collection, and liability apply. By locking the API to these exact four definitions, we provide the precise signal third-party apps need for compliance while keeping the RTEMS core implementation as lean as legally possible. It *IS* possible for a downstream developer to change these brackets to meet their local requirements and comply, but this is the most prudent default for the time being. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1137#note_145752 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
