[arrakeenrevived]

> security needs to be the easiest path. If it is not, then that is the fault of the Security folks; not the end user.

There's truth to what you say, but you're blaming the wrong crowd. Security people are rarely (if ever) the same people that are creating the tools and the security features of the tools you're using. In most cases, I'm powerless as a security engineer to "make security easy to use", the only thing I could do in that regard would be to loosen our security requirements and make our systems less secure, which isn't what you want either.

IMO the problem is more that when developing products, security (and ease of security) is still not seen as that important of a feature (if its even seen as a feature at all and not an annoying cost that the product managers have to deal with). In our application security group, we actually do have requirements that any new product being built must have certain security features that make it easier to secure things, but those requirements are often some of the very first things that the product development teams try to justify delaying or ignoring.

[rqtwteye]

Seems you are actually working with developers. At my company, the security people just say "no" but don't really work with people who have legitimate needs. So often you end up doing stuff on your personal equipment just to get something done. They also block sites like "nature.com" but don't block downloads from shady download sites.

[ChrisMarshallNY]

It's quite possible to develop products that afford security. I'm pretty sure that I know why it doesn't happen, but I won't get into it.

In the app I just released, we take security very seriously. I have spent days on just the login screen, tuning it, so that it lubricates the sign on experience.

In fact, that's what I'm doing, right now. Some of our users have been getting confused with Sign In With Apple, so I'm looking at ways to make it even smoother.

[buttcomputing]

At some point, "not taking security seriously" is simply negligence. Other fields already have ways of punishing people for negligence (up to and including suspension of licensure and/or prosecution). Why are software developers immune to consequences for not realizing they need to use parameter binding in their SQL statements?

[mewpmewp2]

Is that security or just UX thing?

[ChrisMarshallNY]

> just UX thing?

To engineers, especially ones that use CLIs a lot, "UI" is simply "silly chrome for lusers."

However, the other 90% of users think that it is very important.

I have been looking at the signups for a while, and wondering why the SiA signups have been going unused (or the person tries again, with a non-SiA signup).

It was because of a "UX thing."

It's really, really important to take the "UX thing" seriously. It can make or break products. The OXO line of kitchen gadgets got huge, because the designer's wife was disabled, and he designed tools to make her life easier, which also made everyone else's life easier.

[mewpmewp2]

What was the thing they got confused about and what is the fix?

It's just that it only makes sense to me as a security thing if Sign in with Apple is specifically more secure than other methods of sign in.

I usually like 3rd party logins, don't need passwords, but there's potential for them to be multi-edged sword. Depending on the implementation.

[ChrisMarshallNY]

SiA is quite secure, but on my end, it could be quite insecure. It's basically an SSO-type thing.

The workflow is a bit different from the standard login ID/password entry. You use a "Sign In With Apple" button that the OS provides, and that has its own on-device (and cloud) credential generation.

I was not optimizing for the button. There's no need for a user ID, if you are using SiA, so I should not have presented that field to users. Also, some credentials are only available at generation time, and have to be maintained by the app (securely, in the keychain).

That behavior can get reflected in the UI, and may be confusing to folks.

SiA is the only SSO solution we use. I won't use anyone else's code for that stuff, and we keep all user data inside the app. We also don't collect very much.