[Replying to myself to avoid editing the above.] I typically don't give a damn to downvotes but I'm wondering why they popped up in this case. So, just to be clear:
OP is asking specifically about single women and my answer talks about it, focusing on the fact that child raising is a bit too much for a single person. I am not talking about lesbian couples because they fall outside the scope of the question, my views on the later in this regard are the same as heterosexual couples.
(If the issue that people saw with my comment is something else, say it because I don't have a crystal ball.)
Every time that people talk about Chrono Cross's soundtrack (it's great by the way, I agree with you), this reminds me a little SNES game called Radical Dreamers. The soundtrack - largely shared with Chrono Cross - is perhaps its biggest selling point.
My take varies by case, but I don't think that children should be raised by a single person. Otherwise it could turn really nasty, like the child being alone most of the time, unsupported by any able-bodied adult (as their mum goes to work), effectively becoming the housemate for their breadwinning parent.
The situation is different however if the single woman is well supported by her family, living with them, and at least one of them is able to take responsibility for either bringing money in or taking care of the child as the mum is gone.
The words "update" and "agreement", when found in the same sentence, usually prompt me to roll my eyes and say "oh look corporation found another way to stab customers".
This is not the case - what they're doing is sensible and fair. I don't even know how forced arbitration is even legal for some countries, it's basically "we expect you to give up your legal rights".
What you're proposing is effectively the same as "they should publish inaccurate guidelines that do not actually represent their informed views on the matter, misleading everybody, to pretend that they can prevent the stupid from being stupid." It defeats the very reason why guidelines exist - to guide you towards the optimal approach in a given situation.
And sometimes the optimal approach is not a bigger min length. Convenience and possible vectors of attack play a huge role; if
due to some input specificity, typing out the password is cumbersome, and
there's no reasonable way to set up a password manager in that device, and
your blocklist of compromised passwords is fairly solid, and
you're reasonably sure that offline attacks won't work against you, then
min 8 chars is probably better. Even if that shitty manager, too dumb to understand that he shouldn't contradict the "SHOULD [NOT]" points without a good reason to do so, screws it up. (He's likely also violating the "SHALL [NOT]" points, since he used the printed copy of the guidelines as toilet paper.)
I don't think that the entity should be blamed for the shitty manager. Specially given that the document has a full section (appendix A.2) talking about pass length.
They might mean well, but the reason we require a special character and number is to ensure the amount of possible characters are increased.
The problem with this sort of requirement is that most people will solve it the laziest way. In this case, "ah, I can't use «hospital»? Mkay, «Hospital1» it is! Yay it's accepted!". And then there's zero additional entropy - because the first char still has 26 states, and the additional char has one state.
Someone could of course "solve" this by inserting even further rules, like "you must have at least one number and one capital letter inside the password", but then you get users annotating the password in a .txt file because it's too hard to remember where they capitalised it or did their 1337.
Instead just skip all those silly rules. If offline attacks are such a concern, increase the min pass length. Using both lengths provided by the guidelines:
8 chars, mixing:minuscules, capitals, digits, and any 20 special chars of your choice, for a total of 82 states per char. 82⁸ = 210¹⁵ states per password.
15 chars, using only minuscules, for a total of 26 states per char. Number of states: 26¹⁵ = 1.710²¹ states per password.
I think so, based on the original: "Verifiers and CSPs [credential service providers] SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant." With "shall not" being used for hard prohibitions.
That stipulation goes rather close to #5, even not being a composition rule. EDIT: see below.
I think that a better approach is to follow the recommended min length (15 chars), unless there are good reasons to lower it and you're reasonably sure that your delay between failed password attempts works flawlessly.
EDIT: as I was re-reading the original, I found the relevant excerpt:
If the CSP [credential service provider] disallows a chosen password because it is on a blocklist of commonly used, expected, or compromised values (see Sec. 3.1.1.2), the subscriber SHALL be required to choose a different password. Other complexity requirements for passwords SHALL NOT be imposed. A rationale for this is presented in Appendix A, Strength of Passwords.
So they are requiring CSPs to do what you said, and check it against a list of compromised passwords. However they aren't associating it with password length; on that, the Appendix 2 basically says that min length depends on the threat model being addressed; as in, if it's just some muppet trying passwords online versus trying it offline.
I did some tests here, setting up my browser config to show content preferably in Italian, then German, then Portuguese, then English. It showed something like 5~10 posts in English for each post in Portuguese. (No content was shown in either Italian or German, so odds are that Bluesky doesn't even take the browser config into account.)
Granted, for most Portuguese speakers it should be 7:00 now, so it might be worth repeating the test for the later afternoon, dunno, 18:00 or so. Or in the weekend.
Don't bug users to change passwords periodically. Only do it if there's evidence of compromise.
Don't store password hints that others can guess.
Don't prompt the user to use knowledge-based authentication.
Don't truncate passwords for verification.
I was expecting idiotic rules screaming "bureaucratic muppets don't know what they're legislating on", but instead what I'm seeing is surprisingly sane and sensible.
I can’t believe I’m considering moving away from Ubuntu after 20 years…
The good news is that all distros are pretty much similar to each other, so you can transpose most of those two decades of experience to any other distro that you might want to use. Typically the key differences are
defaults - including the desktop environment
package manager and format - YaST vs. APT vs. RPM etc.
stability vs. newer software continuum - different distros aim for one, another, or a balance between both
The problem is that Ubuntu overuses snaps, even when there are completely acceptable .deb alternatives, that will perform consistently better; typically distros using appimage and flatpak don't do the same.
That said if this isn't a big deal for you Ubuntu might be still an option. As the saying goes, better the devil that we know.
Since your main priority is stability, I'd suggest either Debian Stable or Mint. Debian Stable is rock solid, but the software is ancient; Mint is a good compromise. They both have a nice package selection.
The reason why I don't recommend Ubuntu itself is snaps. Huge downloads with lots of wasted disk space, wasted memory, less user control, mismatching themes, larger loading times... urgh.
Desktop environment is such a personal matter that it's hard to say which one would be the best for you. I'm a big fan of MATE - it's small, it's nice, you can reasonably customise it without new extensions or applets. Xfce would be also a good performance-focused choice.
![Lvxferre [he/him]](https://mander.xyz/pictrs/image/333d03a0-bcae-434b-a8d1-7dfd18962d20.jpeg?format=webp&thumbnail=128)
Yup! Frankly it isn't a really great visual novel, but the soundtrack is fire.