1,535 karma · joined September 22, 2014
I know various Zanzibar implementations have exposed APIs to solve this problem, but I still don't have a great intuitive understanding of how they work beyond 'push the ACL logic into the data layer', which brings us back to a pre-zanzibar world.
(1) When there's peer-reviewed replication from a group of reputable labs.
(2) When I see the classic superconductor-on-magnetic-track demo, but without liquid nitrogen.
Nobody really believes this - not even Wall Street - but everyone knows how the game is played and begrudgingly plays along.
While I never bought one of these NUCs myself, I've used quite a few deployed as thin clients and kiosk machines. Let's see what ASUS ends up doing with the product segment.
More broadly, I hope the trend of selling off business units rather than closing them outright continues (Google Domains selling to Squarespace being another recent example).
When your browser navigates to a Discord channel's join page, it sends a request to localhost via this port and sends the channel ID to the client. This lets the app pop open a native 'Join Channel' experience.
I discovered this when I noticed how this behavior worked even in incognito mode and my browser was signed out of Discord.
Not. Cool. We need to massively improve sandboxing - of all applications - in the desktop world.
Having said that this is the type of thing that is likely to get dragged in front of a judge, so the more foolproof way would be to retain 51% control or dual-class shares. Once you give up majority control to third parties, you can't really prevent everyone else ganging up on you and outvoting you.
When I bought a (single) Yubikey from their website late last year, it was Fedexed to me directly from their Palo Alto downtown office, not some distribution center in the middle of nowhere. That can't be cheap.
Ultimately, the price of SSDs dropped to the level were such solutions filled an ever shrinking niche and they fell out of favor.
They also control inflows of money from outside investment.
Disclosure: work at Meta, not on Threads
EDIT: I do wonder if the price point of youtube premium is too high to capture an audience that simply doesn't want ads but doesn't care about any other features. $6/mo feels higher than the typical per-user ad revenue.
EDIT2: While I don't know youtube's average revenue per user, both Facebook and Google's ARPU for the NA segment is ~$100-$200/y, which would put $6/mo quite close to the replacement cost of lost ads revenue.
All I'm saying is that if you're approaching a benchmark between serious competitors providing similar functionality used in the intended way, you almost never see 1000x+ performance differences.
The load time of the oft-considered-bloated reddit.com for me is ~5s. Let's use that as a benchmark. If you told me you got reddit.com to load 1000x faster (5ms), then yes that is extraordinary.
You're also missing the point of my 'apples-to-apples' caveat. A modern webpage might load slowly, but it also does a lot more than a static html one-pager. Sure you might not consider that to be useful, but those features (tracking, A/B testing, ads, redundancy, CDN, etc.) are useful to someone.
OLTP != OLAP, and the sooner database vendors learn to stay in their lane and focus on one use case, the better.
Broadly speaking, there's plenty of public benchmarks indicating that a properly-configured Aurora is within the same order magnitude as a properly-configured RDS Postgres which is in the same ballpark as MySQL. That's an indication to me that Aurora isn't fundamentally broken in some way, making a 1000x claim quite extraordinary.
You claim it's 1.5x-2x faster? Sure I might believe that despite your prohibition against benchmarks.
10x faster? You better show how your engineers pulled out that miracle.
1000x? You've either picked out a very weird edge case, used something in a way it's not meant to be used, or just made that up. Anyone who's done any serious benchmarking in a competitive space will instantly recognize that as a 'that cant be right' result.
In this case, it's a statement from the US to the Bahamas about what they intend to do to SBF once he's in custody. If the US then goes on and punishes SBF even harder than what they originally told the Bahamas, the Bahamas might feel lied to. Think of it as a "we wouldn't have extradited if we knew he was facing the death penalty" kind of scenario. This rule thus exists to give the Bahamas a chance to remedy that.
I write SPAs. I use Keycloak OIDC as the authentication layer. I have the SPA set up as a client using the 'Standard Flow' with no Client Authentication[0]. I've carefully set my valid redirect URIs. I use the official Keycloak JS client and the standard JWT authentication implementation in my API server.
To this day I still have no idea if I'm doing everything correctly. I guess I'll have to eventually hire some expensive security consultant to go over everything, but every step of this setup is filled with hidden gotchas:
* There's multiple overlapping standards, each with a dozen different variants. The Keycloak OIDC config refers to OAuth2 over a dozen times.
* There's thousands of blogs and articles, each 1000s of words long and each recommending different things. I have yet to find a concrete guideline for what a 'sane default' set of choices are.
* Am I vulnerable to the issue described in the article? I guess I must be, given I don't see the server-side JWT validator doing anything special beyond validating the signature, so there's no validation of whether the token was generated for my app.[1][2]
* What are best practices for "client scopes"? I notice that the more I add the larger the JWT, but are there any gotchas to watch out for?
I think much of this boils down to there needing to be a published set of recommended defaults for common use cases, alongside some cleanup around deprecated/not-recommended config options.
[0] Given client secrets can be trivially extracted.
[1] Though I guess the fact I'm only using my own auth server and there's only one client means this isn't a problem.
[2] Isn't this how SSO works? One set of tokens to grant access to a bunch of different services?