Closed Bug 1031621 Opened 11 years ago Closed 11 years ago

More detail in age request re: FxA

Categories

(Cloud Services :: Server: Firefox Accounts, defect)

Product:
Cloud Services
Component:
Server: Firefox Accounts
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: galacpropo, Unassigned)

References

(
URL
)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140608211622 Steps to reproduce: I tried to sign up for a Firefox account via (three lines) > Sign in to Sync. I selected my date of birth. Actual results: FxA signup did not ask for the month of birth and decided that I was not 13, despite my birthday having passed recently. Expected results: I should be able to sign up without issue.
It is really difficult to overstate the importance of this bug. I've heard it approximated that for every user who takes the time and trouble to file a bug, anywhere from hundreds to thousands of people have experienced the bug and not taken any action. This should be a wake-up call; the current COPPA flow may be simple, but it also forbids access to people for no legal reason.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: kthiessen
We're suffering from the collision of a few things here: 1. It would not appear to be very Mozilla like if we asked YYYY-MM-DD birthday of every user. 2. Legal requires that the age screening mechanism be "neutral" 3. It's inconvenient to input YYYY-MM-DD on devices like mobile. We're working on ways to address this so that we can support: 1. Users who are 13 years old born earlier in year than when registering 2. People who don't want to feel old (1991 or earlier) The hard part is appearing age neutral. We are thinking of just putting a YYYY text input box, and when the user enters the magic 12/13 year, they are then required to append MM/DD. Thoughts?
Fine by me, and you may want to cc product folks as well.
Ryan(In reply to Ryan Feeley from comment #2) > We're suffering from the collision of a few things here: > > 1. It would not appear to be very Mozilla like if we asked YYYY-MM-DD > birthday of every user. > 2. Legal requires that the age screening mechanism be "neutral" > 3. It's inconvenient to input YYYY-MM-DD on devices like mobile. > > We're working on ways to address this so that we can support: > > 1. Users who are 13 years old born earlier in year than when registering > 2. People who don't want to feel old (1991 or earlier) > > The hard part is appearing age neutral. > > We are thinking of just putting a YYYY text input box, and when the user > enters the magic 12/13 year, they are then required to append MM/DD. I don't think changing to a manual age year entry is any more or less *age neutral* than using a select list. Actually, I don't know what age neutral actually means in practice, but FTR neither option seems age neutral to me. My guess would be that age neutral means that all users see the same thing no matter what. > > Thoughts?
Ryan: why don't we just go with a formatted text box and do MM-DD-YYYY or DD-MM-YYYY for all users. We can even get fancy and flip MM and DD for different locales.
Thank you for working on this. (Especially Thiessen.) It has been a few days since I've posted the bug; I didn't think anything would happen. It's out of my hands now -- I'm not a web developer nor a legal guy nor a security expert. For my two cents, though, I like Ryan's idea. (Not sure about age neutral either, though.)
You're very welcome; thank you for reporting it.
:jgruen, any word on who I need to poke to get this into a train?
Flags: needinfo?(jgruen)
Android work for this bug is in bug 1058806. I'll update here when there's a bug for Desktop work, as well.
Hey Karl, I've updated the COPPA bug on FxA to reflect these discussions. We should be able to determine which train to target in our next triage meeting.
Flags: needinfo?(jgruen)
This work has been merged in https://github.com/mozilla/fxa-content-server/pull/1682/commits -- not sure whether it will make this week's train or not, but it is definitely moving forward.
This is finally fixed and pushed to production. galacpropo@myaccess.ca, please try it now and comment here if it doesn't work for you. My apologies that this has taken this long to resolve.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Marking this as VERIFIED, since I just verified it in production.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.