scient

Even then the external services will still require first and second factors of authentication. If your workstation is compromised on an ongoing basis, then nothing matters. If its an one-time even, 2FA will protect the external services still.

My anecdotal opinion - pure tech people don't usually make good founders because they are too realistic and grounded.

A company needs a visionary, someone who is at times even blinded by their optimism and vision. You pair that visionary with a strong grounded realist, and they balance each other out. There are times when both are needed - to either take a leap of faith (risk) or mitigate/avoid risks.

But this dynamic will also only work if these founders have good communication and respect towards each other, otherwise friction can turn into bitterness and resentment.

Uber is literally having the same business model of subsidizing rides, which loses them a lot of money. This is not even tied to simply being competitive with Lyft - its also to incentivize users to choose them over taxis. You really thing that upping their prices is going to a simple decision and people will just keep using them because of what? Just out of habit?

Quite the feat to build a site this slow...

Its absolutely ridiculous. Its now to a point where 15-18% is expected even for bad service, and 25% and up for good services. There is no way I'm paying an extra quarter of my bill in tips because the restaurant owner is too cheap and offloads the staff costs directly to their customers.

Not a good look questioning people who know what they are doing by promoting a service apparently built by someone who does NOT know what they are doing.

Data breaches are never a question of "if", but "when".

Preach. Them changing the rules and overriding the usage of this attribute is ridiculously stupid in the first place. HTML attributes are there for a reason, developers are supposed to be able to use them and they are supposed to work as expected. But in order to push their password management and form filling functionality, they just give everyone a finger.

I think the statement you make about "something you know" always being more secure is not nearly as clear cut as you present it.

A combination of "something you know" and "something you have" is always going to be a very strong authentication scenario, and making "something you have" a non-hackable thing that truly only you can have (i.e not a USB key or a TOTP seed etc.) is a good choice.

The catch here is that when you mention biometrics, you make the assumption of static biometrics (rightfully so, as most methods like Touch ID and Face ID are static), but if you combine lets say face biometrics with liveness checks, you are getting into a territory where faking them becomes much much more difficult (there are various mechanisms out there, the good ones rely on completely random interactions and light-bouncing detection methods as an example).

The real challenge is how do you make these very strong biometric methods frictionless and cheap? Or how do you introduce similar controls - like liveness - for easier methods like fingerprints?

And using any of these (ideally) has absolutely nothing to do with anonymity. You are not anonymous online regardless of what you use for authentication - and you are frankly not smart if you assume thats the case. A company offering a service with biometrics is no different from a company doing the same based on email/username and a password, if they do privacy and security right.

I could actually get into a much longer rant about this last part, as it blows my mind how many netizens are all about privacy and whatnot, yet are willing to expose every single detail about them when its convenient from them...

How is it not? Consent to releasing information should be supported on a granular on-demand level. If I initially only need name, I'll ask the user to consent for that. If I later on need an email (lets say for some additional functionality user is trying to access), I'll ask for email separately. This is much better than being constrained to only the initial scope being respected, resulting everyone basically request everything right away, faced with a situation where they can't do it later.

Its only "popular" because for a long time it was the only choice in Europe pretty much. In several countries it still is.

It also was total garbage developer friendliness wise ~5 years ago.

So you are blaming them for your own fault?

And finding that place also means you will never be anything more than that. Thats what always strikes me about these complaints about having to do a little extra, or stuff thats not directly in your job description etc. And then complain about how your manager sucks because you are not valued or promoted fast enough.

Trust me, most engineers are not THAT good that their code writing contributions alone would justify high career leaps. Even the highly technical leaders need to do a lot of brain work thats not necessarily coding - like architecture design and whatnot, and most of that requires a lot of interaction, discussions and other soft skills.

CTO sets the technical and architectural vision, also security and toolchain being used etc. You can think of it as CTO is leading the technical vision, while a VP of E is helping out managing the team on a daily basis, organizing the product work, managing sprint resourcing etc.

You should look into Estonian ID card program. Its exactly what should be done.

I think you are the one lacking perspective here. The same way you are trying to make a point, I can make a counter point. The person making $20 is considered comparatively rich by someone making less than a dollar a day in some underdeveloped country. Everything is relative. If you make $100k and you live paycheck to paycheck because of housing costs, education costs, grocery cost etc., how can you claim their should shut up because they are rich?

And what would the lawsuit be based on? Stealing documentation for how OAuth 2.0 works?

Its not even their proprietary API, its OAuth endpoints.

Its OAuth documentation - its a very well described standard protocol. Most of the OAuth documentation looks and reads exactly like this. The only "smoking gun" is the "random" value used for the state parameter, which seems to be copied over - and developers copy other products/sites documentation ALL THE TIME.

While there is substance in the post that some other company is building the same product, saying that its literally cloning it and using documentation similarity for a standardized protocol is not really cutting it.

But muh decentralization! /s

In reality most of the exchanges and sites dealing with crypto were (and probably still are) built by absolute amateurs with no checks and balances on their apps from a security perspective. Its scary as hell that people trust those sites with their actual money.

One can only hope this would make it to the US as well. The problem largely seems to be banks being ancient behemoths in terms of technology, and introducing APIs like this poses a significant risk from security and policy perspective. Plus its not going to be a major source of revenue either, so why bother?

I hope not, because its such a shitshow. You literally give your bank credentials to a third party who then logs in to your account and scrapes info off of it - info that you have no control over.

Capital One was smart enough to block them off (which is the bank I use), and now they actually provide proper OAuth based APIs to access your account.

How much does it hurt?

Yeah, KYC/AML is totally bad because of trying to actually prevent money being funnelled into crime organization etc.

This is why I cant stand ignorant crypto-fans.

OAuth access tokens? The difference being that JWTs contain information directly, as well as an access token to hit any APIs, while an access token contains no information on its own - thus solving the revocation issue.

Now I don't think anyone really uses JWTs for API authentication, or they should not at least. APIs should still be gated by access tokens.

Except cookies are quite literally perfect for that - set the expiration to 30 minutes from issuance and it will automatically be expired with inactivity. Or bumped on activity.

And why would someone put $50m into a highly volatile, unchecked tech, where mediators are mostly known because of their security problems and breaches?

So you're saying cant read existing code in order to understand it, or you just wont? Not arguing that self-documenting code is a good excuse for not documenting anything, but if you have to write an essay to go with your code, maybe the code itself is not that great?

I've done major upgrades from 3.2 to 4.1/4.2, and from there to 5.1 followed by 5.2 - the only time we had to put in a little work was when moving from 3 to 4.

When moving from 4 to 5, we relied on simple smoke tests and unit tests, and had no major issues or bugs. The biggest effort was to make sure all of the application and environment configurations were up to date and using all the new settings introduced etc.

My very subjective opinion is that either most of these code bases are low on quality (meaning they are harder to maintain in general), too tightly coupled with Rails itself (models stuffed full of logic, instead of using plain ruby objects for logic and keeping ActiveRecord for persistence level logic), or engineers are just too scared to make changes to the codebase - which again is perhaps a combination of bad test coverage and bad code quality.

Either way the stories of upgrading major versions being a huge undertaking always make me scratch my head and wonder what are we doing wrong if its easy for us.

And inb4 someone claims our apps are just small and simple - we run about 12 Rails applications in production in various sizes, about half of them being relatively large.

BLE solutions are going to work much better for mobile devices than NFC I think. Google already supports it for their apps via SmartLock and Advanced Protection on both major mobile platforms. Its the browsers, and namely Safari, thats being the blocker on iOS right now - both for NFC and BLE solutions.