I noticed the site was down, and I was very sad :(

Thanks for your work. Lemmy is a piece of shit to host and moderate, but is there really a better option in 2025?

I still would like to…start building a community on there instead of a federated platform

I definitely think federated is the best solution. Specifically ActivityPub. Is nostr not federated?

What’s the state of SubLinks and PyFedi?

𝐒𝐨𝐜𝐤·​𝐩𝐮𝐩·​𝐩𝐞𝐭⁣
/ˈ𝘴ɑː𝘬 ˌ𝘱ʌ𝘱.ɪ.𝘵𝘳𝘪/

(n.) An online identity created, and used, for purposes of deception. A sockpuppet purports to be an independent party that supports, approves of, or agrees with some agent (a person, organization, agency, or state), but is in fact created and controlled by that agent, and has no independent existence. Common uses of sockpuppets include plausibly deniable hacking or information operations, provocation, and astroturfing (creation of the illusion of grassroots support).

Source: https://thecyberwire.com/glossary/sockpuppet

𝐒𝐨𝐜𝐤·​𝐩𝐮𝐩·​𝐩𝐞𝐭⁣
/ˈ𝘴ɑː𝘬 ˌ𝘱ʌ𝘱.ɪ.𝘵𝘳𝘪/

(n.) An online identity created, and used, for purposes of deception. A sockpuppet purports to be an independent party that supports, approves of, or agrees with some agent (a person, organization, agency, or state), but is in fact created and controlled by that agent, and has no independent existence. Common uses of sockpuppets include plausibly deniable hacking or information operations, provocation, and astroturfing (creation of the illusion of grassroots support).

Source: https://thecyberwire.com/glossary/sockpuppet

Daniel Micay = the (former?) lead dev of GrapheneOS who did the banning
Michael Altfield = the author and person who was banned

I will, but I’m 85% sure they already know – but they made a business decision to make one OAuth flow for all “platforms” for a consistent & simpler UX (at the expense of extra security risk, which they’ve accepted).

Edit: wait, did you mean email stripe or email the pentest company that authored the article of common oauth vulns?

https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html

I haven’t seen it. Thanks for sharing!

afaik, it doesn’t cover this use-case (where the Resource Server [Stripe] just uses the wrong flow – forcing us to expose our access keys to a third party).

But, curious, it lists 0 attacks for the OAuth Flow that Stripe should be using here = Client Credentials Flow.

Edit: ahhhhh, this paragraph is elucidating

The Authorization Code Flow is one of the most widely used OAuth flows in web applications. Unlike the Implicit Flow, which requests the Access Token directly to the Authorization Server, the Authorization Code Flow introduces an intermediary step. In this process, the User Agent first retrieves an Authorization Code, which the application then exchanges, along with the Client Credentials, for an Access Token. This additional step ensures that only the Client Application has access to the Access Token, preventing the User Agent from ever seeing it.

I confirmed that Stripe is using the Authorization Code Flow

curl https://connect.stripe.com/oauth/token \
-u sk_test_MgvkTWK1jRG3olSRx9B7Mmxo: \
-d “code”=”ac_123456789” \
-d “grant_type”=”authorization_code”

• source: https://docs.stripe.com/connect/oauth-reference#post-token-request

…but it does appear to be using the wrong OAuth Flow type. They give the token to us in the end. There’s no need to expose it to a third party.

So I guess “choosing the wrong flow type” would be a valid addition to the “attacks” section under Authorization Code Flow

No, I’m not forced to use Stripe.

I’m looking at mollie now, but I don’t really know of any better alternatives to Stripe. Got a recommendation?

Anything that requires a PayPal account is not an option.

Edit: Mollie won’t let us create an account unless we push >50.000 EUR/mo. Yeah, we’re a small business. We’re wayyy under that limit. So no Mollie :(

Thanks. It’s a good guess, but that’s not the case.

The developers confirmed that the only place the OAuth access tokens are stored is on my server. Of course, the dev’s server (which sees the [non-expiring!] access keys for >800,000 Stripe Accounts!) would be a ripe target for someone malicious. But it’s not designed to store the keys there. All subsequent connections to the Stripe API are done directly between my server and Stripe’s server (with no intermediary “platform”). The token is only exposed to the dev server when OAuth flow is first established. Then the dev server (effectively a MITM, by design) sends it down to my server for storing and future use.

PCI compliance on my server isn’t an issue because all sensitive payment information is tokenized.

The reason this is done is because Stripe doesn’t allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that’s hard-coded into the app.

For security purposes, Stripe redirects a user only to a predefined URI.

• https://docs.stripe.com/connect/oauth-reference#redirect-uri

That’s why Stripe forces you to expose your access tokens to the developer’s servers.

I’d still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer’s servers.

Update: It looks like you’re describing their “Platform” option. In 2025, there’s 3 “authentication types” for Stripe Apps, as documented here

1. Platform
2. OAuth 2.0
3. Restricted API Keys

In this case, I’m talking about OAuth 2.0 (Stripe Connect), not “Platform”

I have been, but Stripe support hasn’t been helpful.

Update: one of the plugin authors finally explained it well:

It’s because Stripe doesn’t allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that’s hard-coded into the app.

For security purposes, Stripe redirects a user only to a predefined URI.

• https://docs.stripe.com/connect/oauth-reference#redirect-uri

That’s why Stripe forces you to expose your access tokens to the developer’s servers.

I’d still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer’s servers.

Can you elaborate? Any idea why Stripe would choose this design?

I think Stripe generally has good security practices. But I just can’t understand this design choice. There has to be a reason…

Please read the question. I am not the developer; I can’t change to keycloak.

No, please do not deactivate downvote functionality.

(I say this as someone who has received a lot of downvotes; they’re useful feedback that I appreciate)

Also, monero.town is currently a recommended instance on awesome-lemmy-instances (at the time there’s only 7 recommended instances, and monero.town is one). If this instance deactivates downvote functionality, it will no longer be recommended as downvote functionality is one of the requirements for recommendation.

Can you elaborate on the phone-friendly point? I spent a long time translating it to markdown so the contents would be lemmy-native and also the source article’s website is responsive.

Thank you for your input, but I think it’s worth mentioning that that’s absolutely not true.

To be clear: I’m not asking for a no-KYC solution. I’m happy to auth with my company’s official government-issued registration records, with my personal government-issued ID, etc.

I’m not aware of any regulations that require a phone number. There are regulations (eg UK’s PSD2) that effectively require 2FA – and many banks chose to implement this requirement via phone numbers.

Hopefully one day the regulations will explicitly prohibit 2FA OTPs from being transmitted at all (ie so banks are forced to use secure 2FA methods like TOTP or U2F instead of insecure methods like SMS, email, etc). But currently I’m not aware of any KYC regulations that require a phone number from the customer.

Thanks for PMing me. I’ve left my comments here

• https://monero.town/post/1146423

In addition to being vouched-for by ProxyStore, we also have the green check box on Monerica. If you have specific criticisms of our product, please let us know. Mostly we’ve got “you’re a scam because everything blockchain is a scam.” – but I would expect better from the monero community.

Not sure how providing journalists, activists, human rights defenders, crypto traders, etc with open-source hardware kill cords makes us illegitimate…

Sorry folks, just seeing this. Obviously I do not think I’ve posted spam.

1. I only post at most one link per month. I have no idea how one could consider publishing content that infrequently to be spam.
2. I post once in every relevant community on lemmy. Again, that’s not spam; that’s the nature of the fediverse. As there’s so many “world news” communities, I am pretty annoyed when users don’t take the time to post a link to an important news story to all of the “world news” comms.
3. Obviously many communities found value in my posts, as can be seen by the upvotes.

I make an effort to only post to communities that I think the article is relevant-to. But If someone thinks that an article is not relevant to the community in which it was posted, they can downvote it. That’s what the button is for.

You associate everything that can be bought with cryptocurrency as a scam? It sounds like you haven’t even read the post. I spent a lot of time making it easily accessible here on Lemmy. You don’t even have to click the link. Just scroll-up and read :)

How exactly did you come to the conclusion that this is a scam? We’re a fully open-source hardware & software project that’s been around for a few years. If you don’t want to buy from us, we go out of our way to help users build their own 3D-printed BusKill cables (currently in prototype stage).

• https://www.buskill.in/tag/3d-printing/

Our software is free as in speech and free as in beer under the CC BY-SA and GNU GPL licenses.

• https://github.com/buskill/buskill-app

Yes, BusKill works with any USB drive.

• https://github.com/buskill/buskill-app

In fact, the BusKill cable is just a USB Drive. The only thing “fancy” that it has is a magnetic coupler in the middle of the 1-meter cable so that it will breakaway at any angle. But, if you’d like, you can build your own. The instructions are here:

• https://docs.buskill.in/buskill-app/en/stable/hardware_dev/bom.html