> reports that said the app will require a confirmation of identity, such as a driver’s license, your tax records to prove income and a signed form that says you are ready to get married.

Not sure why someone would sign up for a dating app that is this invasive

because it means you're going to get matched with people who are real, honest about their income and serious about marrying. If I was looking to date this is probably the only app I'd consider signing up for.

Not sure why the Tokyo Metropolitan Government would need that info to begin with. They're going to have most of that on file already.

yes, it is a typo from the independent.

> Its driving my insane.

Off topic, but you made another typo here lol

> The Royal Navy seems to advertise all levels of jobs on LinkedIn - and wider.

Wasn't aware of this. Can you please link to some more similar job ads? Is this the standard in other militaries too?

Based on what I know there is a roster of eligible candidates with the required experience in most countries. One of them is promoted from there to fill in the vacancy. I've never seen an ad for a post like this before.

> why would it be bad to advertise the position?

Not an expert but from what I understand a position of this level should ideally be filled internally by reassigning or promoting a officer that is already serving. These posts are really important and need someone with decades of experience in the navy. It is terrible if they cannot find someone internally.

I wouldn't even say ideally. I would say filling internally is essential. The top comment on the featured article I think summarizes it well: It's not the broader recruitment issue among gen Z. It's that for some reason none of the senior officers below this position want it. THAT is indeed quite troubling.

It suggests strongly that the entire organization has deep systemic issues that no one wants to step up and try to fix.

Congrats to the team at ISRO!

It makes me wonder, what is it that ISRO does differently than most other government agencies in India that makes them so efficient.

There you go https://archive.ph/fmQR9

Sorry I should probably have put the non-paywalled link in the submission

Thank you, this is even more insane a notion than I thought before reading!

This is exactly what I was looking for! Thank you so much for the help.

I was checking out the docs for that and a few other similar solutions too. This is very true. Most of the secret managers are primarily intended for config-like data.

Thanks for the help. So that two options that I was thinking about -

Option A 1. My user creates an secure (with API keys or some other method) API endpoint to provide the Client secrets when I need them.

2. When my app needs to access the client secrets, I maker an API call to the users endpoint to get the Client Secret.

Option B 1. 1. When user signs up, generate an encryption key and ask the user to save it securely. (With the warning that in case this key is lost, the user would have to configure the Client Secrets again)

2. Whenever the user makes an API call (over HTTPS ofc) that involves reading/writing sensitive data, require him to provide the encryption key as well.

Which one is better?

If I understand correctly, option B makes not much sense. If your user can provide an encryption key, he can as well provide the token or whatever directly.

When does your SaaS initiate the connection to the other services? Autonomous at arbitrary times? Or does the user initiate the connection? In the latter case, your app can store the secrets like Browsers do. In the former case, and when your user can provide an always on endpoint to provide the secrets, your option A seems the best way. If not, you must store the secrets server side, but then you definitely should consult an appropriate security guy to make this as secure as possible.

>If your user can provide an encryption key, he can as well provide the token or whatever directly.

Yeah that makes sense, thanks for pointing that out. I'm just brainstorming at this point and will consult a security person before going to prod. Thanks for your pointers!

>What are you going to do to keep the key safe in the scenarios of your threat model where an adversary can access the DB contents?

One option that I have been thinking is - 1. When user signs up, generate an encryption key and ask the user to save it securely. (With the warning that in case this key is lost, the user would have to configure the Client Secrets again) 2. Whenever the user makes an API call that involves reading/writing sensitive data, require him to provide the encryption key as well.

Here I won't store any encryption key on the server side and only the user will be able to decrypt the data.