14,424 karma · joined January 17, 2017
OTOH bodybuilding (the part people care about) and some strength sports allow PEDs. Some people do die young from steroid abuse, but not a lot of top dogs.
In the US, it’s not only disrupted by the activists briefly mentioned in the article, but by the mediocre part of the elite that would rather have such a system not exist or be easily gamed/rigged than to have it exist and their child not in it. Given the more classist nature of life in the UK I’m sure this is even moreso a factor there.
Plenty of examples of elite bodybuilders training with them.
I remember when I first started exercising, I was a fat alcoholic that was usually the youngest person there and had no idea what he was doing. I was very anxious about potentially doing something wrong, or being taunted or judged. I didn’t know how to use a lot of equipment and it took a long time before I even realized kind of “obvious” stuff like you being able to swap out attachments on cable systems. I knew my body language was glaringly displaying low self confidence and anxiety, and was further psyched out by knowing that it was obvious and I couldn’t do anything about it.
As I went to the gym more I became more self confident and also assured through experience that I wasn’t doing anything wrong and nobody would be a dick to me. I mean, people are dicks sometimes, but usually only out of their own selfishness (like wanting to use something you are, or hogging something they’re not use because of fucking supersets), not malice. There’s always a small chance of a bad interaction along those lines every time you go but the anxiety definitely greatly subsides over time.
I would also try to incorporate pull-ups (some parks have pull up bars, or you can install one at home) to work your lats. This might be tricky if you’re not at the point where you can do a body weight pull-up yet. If that’s the case, you can probably figure out how to do a lat pull down with elastic bands and the right kind of rigid surface.
You can use your feet to stabilize the bands to do curls (biceps, some forearms) and shrugs (traps) to round out most “pulling” movements. Also you can isolate your triceps and side delts with bands. And do “harder” ab exercises than just sit-ups. They’re very versatile, like a much less expensive cable system.
It’s certainly something you can do and get good results, but it’s also a limitation. If you want to build muscle or strength past a certain point it will be very inefficient not to use free weights. Maybe you don’t want to do that, and that’s ok. But it’s kind of weird to be smug about it
So it’s not-impossible that this is a non-appreciated offer designed to compete with/recruit away from such compensation.
I think most people here don’t have any experience building for the kind of use cases I’m considering here (imagine a proxy like Envoy, which btw does give you at least the option to configure header casing transformations). When you have customers that can’t be forced to behave in a certain way up/down stream, you have to deal with this kind of stuff.
Go makes the argument that they can format your headers in canonicalized casing because casing shouldn't matter per the HTTP spec. That's fine for applications I guess, though still kind of an overreach given they have added code to modify your headers in a particular way you might not want to spend cycles on - but unacceptable for a systems language/infrastructure implementation.
It’s absolutely an applications language.
What I’m trying to prevent, while adhering to general authN best practices, is a user accidentally or unknowingly sharing their access code because they copied the address in their browser bar/history and sent it to someone. If they jump through hoops to share it there is nothing I can do to stop it. But the default Cognito footgun I’m mentioning is that the code ends up in their browser window in a way that could be easily copy and pasted without them knowing why they shouldn’t do that.
It seems like an underserved market.
* mainsite.tld checks if user is unauthenticated/uses expired tokens. If so, redirect to Cognito UI hosted in a subdomain (auth.mainsite.tld) but managed by Cognito.
* Cognito UI prompts user for username/email and password. Potentially also MFA. Handles password reset. Eventually also handles signup.
* On successful sign in, Cognito redirects to my login endpoint with the access code in url params (login.mainsite.tld/?code=foo).
* My login endpoint extracts the access code, talks to Cognito again to confer it to tokens. Returns tokens via cookies in a response that redirects to my main site (mainsite.tld). (This is what prevents the user from accidentally sharing their access code in url params, manually copied out of their browser address bar, if I had instead done this in the browser).
* The main site now has working credentials; if the credentials go missing (because user cleared cookies) or expire (indicated in currently-unimplemented response when they interact with my authz/game server) they’ll be redirected back to the same Cognito UI.
I do not have control over how (url parameters) Cognito spits out the access code with this flow; still this flow is preferable to most others as at no point whatsoever am I responsible for managing user passwords, yet unlike a lot of new auth solutions that accomplish the same thing, users still actually have the option to sign in with passwords. What I do have control over is what redirects addresses are allowed out of Cognito, so afaict a compromised client (something bad that points to my login) can only redirect to my login endpoint which only redirects to my main site. There is no way to stop a compromised client (like a malicious browser and unsuspecting user) from doing bad things with the code or tokens but the same is true of anything entered into a browser ever, so that’s not a problem worth caring about.
But maybe I misunderstand (because I’m new to webdev too lol): what you’re suggesting in that last paragraph might be possible if I can reliably get the browser to hide the access code url param from the address bar/history. I just didn’t know how to do that from the browser without a redirect or reload. Even if that’s possible I’d still consider it a pretty glaring footgun, because while (hypothetically) possible it’s not necessarily obvious.
The extra redirect converts login.mainsite.url/?code=foo to mainsite.url with the code converted to tokens passed back via cookies. That way it’s much harder for a user to leak account details accidentally. In this auth flow, Cognito hands off the login by redirecting to foo.bar/?code=baz which could leak baz if baz gets shared.
My tokens’ cookies themselves are same-site only/https only and not directly accessible, so they’re protected against XSS AFAICT. AFAIK the only MITM security risk, once I got this working properly, is if something on the user’s network sniffs and leaks url params to my login endpoint (not sure if TLS makes this impossible by encrypting the url path, hope it does, but not something I can easily workaround anyway) or injects arbitrary code to my backend (in which case almost everything is compromised anyway).
I’m new to this auth stuff so I might be missing something, but I was surprised at the subtle security risk of Cognito’s default redirect behavior once I noticed it.
My philosophy toward authn right now is to never have to worry about security at all, so I want to completely minimize any personal responsibility towards managing passwords and tokens, first by outsourcing it as much as I can to products like Cognito, and failing that, by following best practices. My gripe with Cognito, as someone who doesn’t know much about auth and would prefer to learn as little as possible (I just want to add logins to my site!), is that it doesn’t give you an understandable API or user flow or best practices for implementing what I’d consider to be a “happy path” use case, unless you use Amplify. So if you’re someone like me who is learning as they go, there are tons of footguns and mistakes you can easily expose yourself to.
As an example: it’s not obvious that using their hosted UI with a redirect, for USER_SRP_AUTH, should point to a backend endpoint hosted/managed by you that converts access codes to tokens and performs a second redirect back to your actual site. You could easily do the wrong thing and redirect back to your main site with the access code still in the URL params, and then issue a call from the webclient that converts that code to tokens ( Which is terribly insecure as it opens up an exploit - user could share that URL with another not knowing that the access code in the url params is sensitive and could allow others to sign into their account). In fact, that entire exploit/antipattern was never even mentioned anywhere in any docs I found, but it would be extremely easy to accidentally introduce by naively using Cognito.
[0] https://aws.amazon.com/blogs/security/reduce-risk-by-impleme...
[1] https://dev.to/jinlianwang/user-authentication-through-autho...
I’ll say though, my personal “customer demographic” ATM is more along the lines of someone who wants to get working user signups and auth and then never think about it again - so mentioning SAML/OIDC building blocks is a bit of a turn off for me. The reason is that I’m a solo dev trying to ship a browser-based multiplayer game, which I assign a low (maybe 5%) probability of ever becoming something with multiple people working on/turning into a real business - so I need auth, but would prefer to spend as much time as possible on the game itself, and don’t have anybody to farm the work out to.
But I’m happy to give workos a shot to see if it makes my life easier.
I would normally consider myself pretty competent, but I stood up my first fully featured website recently with logins and such, and it took me about 2 days of work to get AWS Cognito working (using their recommended USER_SRP_AUTH). That’s not including 3rd party login functionality from Google and friends.
Their documentation and UX is piss-poor unless you’re willing to onboard your entire project to Amplify and enter npm-hell, which I wasn’t. It’s almost like they don’t even want your business.
I looked into using Auth0 instead and it didn’t seem to be any easier. Better docs, seems like they’re actually written by someone who both understands the auth problem domain and how to explain it to those that don’t, but still complex.
Yet when I was finished finally getting everything to work, it seems like the kind of thing you could easily package into an off-the-shelf product. It’s just that existing products don’t do it. Like why the fuck is there a guide explaining how to write a lambda to convert access codes to refresh tokens and persist them via cookies? That should be part of the Cognito platform!
Honestly thinking of just starting my own auth SAAS with blackjack and hookers
The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself. Containers are not insecure/composed with VMs to protect against memory safety issues so much as to implement sandboxing preventing these syscalls from doing bad shit.
Even just considering Linux security itself: there are so, so many ways OS security can break besides a slight (you’re going to have to use unsafe a whole lot) increase in memory safety
The ideal software implementing a given functionality has as low of a carrying cost as possible. More code, in quantity and complexity, typically means more carrying costs.
One of the appeals of SAAS is that this carrying cost is easy to quantify and predict. Going further, for high-quality OSS projects like the Linux Kernel, the carrying cost may be 0 or close to 0 for most users. But lower quality OSS or buggy SAAS has a carrying cost in the form of bugs (possibly affecting downstream users), patches, need for support + back and forth.
In this analogy tech debt is a tradeoff for some short term benefit (like simplicity, time to market) at the expense of higher carrying costs down the line. But some carrying costs simply can’t be reduced - you can’t mooch off something like the Linux kernel, get your own carrying costs all the way to 0, or find a SAAS provider/vendor willing to give you the software for free. So in this model not all code is technical debt.
I think this is harder to see if you grew up in a nice area, with educated upper-middle class parents, and followed the traditional college->office jobs path. Or conversely, it’s hard to see if you didn’t grow up in that kind of life but were never appreciably immersed in it. We have a social contract that strongly discourages punching down so I’m trying to be delicate here… but if you spend a significant amount of time with poorer people you find that negative personality traits (to the point of being pathological and actively harmful) are much more common outside of relatively “elite” circles than within.
Any sort of institution that is “picky”, including most good jobs, naturally selects against moderate-severely negative personality traits. If someone shirks all responsibility or work they’re unlikely to have a meaningful career unless a family member swings them a sinecure. If someone is overly confrontational or aggressive they’ll get fired from their jobs. If someone is unable to take blame or accept feedback they’ll never develop appreciable skills. By all means I’m not saying well-off/famous/affluent/accomplished people are all virtuous or good people, simply that those who do so on their own merit typically as a group lack major personality flaws, which actually may resemble something of an “inner-ring” to those who grew up/live outside those circles where those traits are more common.
Once you have sufficient electrical power, you can heat things in other ways - for example, aluminum smelting requires even higher temperatures than steel and uses electricity https://en.wikipedia.org/wiki/Aluminium_smelting.
What about wood, or more "advanced" biofuels (idk, some kind of highly productive grass or a refined algae product), prevents us from developing wind and hydro power? Those were both developed before fossil fuels were widely used anyway. They produced mechanical power instead of electrical, but only because electricity was not understood yet.
The more energy you have, the easier it is to scale energy production up, but you have the resources required to initiate that process with just biofuels. And once you have a base of wind and hydro energy, that allows you to begin the feedback loop of using that energy to assist in constructing more power generation in a virtuous cycle.
edit: I'll also add that the industrial revolution came about after there had already been notable advances in mechanization and manufacturing - the introduction of fossil fuels quite literally threw gas on the fire, but people had started developing increasingly sophisticated machinery like the cotton gin (https://en.wikipedia.org/wiki/Cotton_gin) and mechanically-powered loom (https://en.wikipedia.org/wiki/Lancashire_Loom) before fossil fuels started being widely used. And indeed, many of these were hydro-powered.
People simply romanticize that kind of work because of its loose association with highly-prestigious creative work. I don't think we lose out on Picassos if we lower the number of graphic designers or caricature artists.
McDonalds is also at the far end of the spectrum of "human service jobs that are less-skilled but difficult to automate". There is plenty of demand for higher quality versions - requiring a higher degree of skill and creativity - of the same general type, like fine-dining.
Truly creative (in the sense of it having a high degree of novelty and quality) work is not at risk of being automated any time soon. What is at risk of being automated is the category of "creative" work that requires some skills but is mostly assembly line. Category-defining or truly novel art almost by definition can't be produced by existing AI in any form, because AI can only remix the content it's seen already. "Generic rock song" or "clip-art like picture of a guy yelling at a computer" are at risk of going away, but I hardly think that means humanity will no longer flourish - producing that kind of stuff is romanticized as a cool, highish status thing to do, but functionally I don't really see it as any different or more worth preserving than obsolete skilled labor of the past like carriage-makers or human-computers.
I also think people tend to make the "Lump of Labor" fallacy when thinking about this stuff - economically speaking, if human workers are no longer needed to produce some high-value output, in the long run the excess labor/"talent" that gets freed from that task finds other value-producing tasks to do: https://en.wikipedia.org/wiki/Lump_of_labour_fallacy. Long-term unemployment and underemployment is completely a solvable economic problem; both can increase due to short term shocks like technological development and shifts in supply/demand, and in some cases underemployment is more a matter of "wrongly skilled", but long term they're both a matter of ensuring there is enough money, liquidity, and capital deployed to drive demand for marginal increases in both jobs and quality-of-jobs (without ruinous inflation).