I figured it out. 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.
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.
Why OAuth MUST share access token with 3rd party?!?
Why does Stripe require OAuth tokens to pass through a third party server?
Can someone who understands OAuth better than me explain to me why Stripe REQUIRES that their OAuth Access Keys get shared with a third party?
I've tried RTFM, but my biggest hangup is that the OAuth docs appear describe a very different situation than mine. They usually describe a user agent (web browser) as the client. And they talk about "your users" as if I have a bunch of users that I'm going to be fetching access keys for.
Nah, this is server <--> server. I have a server. Stripe has a server. I am one user. All I need is ONE API key for ONE account. But I'm forced to use OAuth. It doesn't seem appropriate, and it's especially concerning that the "flow" requires the (non-expiring!) Access Token to be shared with a third party server. Why?!?
I recently learned that Stripe has been pushing OAuth (branded as "Stripe Connect") to its integration apps as the "more secure" solution, compared to Restricted API
Why OAuth MUST share access token with 3rd party?!?
Why does Stripe require OAuth tokens to pass through a third party server?
Can someone who understands OAuth better than me explain to me why Stripe REQUIRES that their OAuth Access Keys get shared with a third party?
I've tried RTFM, but my biggest hangup is that the OAuth docs appear describe a very different situation than mine. They usually describe a user agent (web browser) as the client. And they talk about "your users" as if I have a bunch of users that I'm going to be fetching access keys for.
Nah, this is server <--> server. I have a server. Stripe has a server. I am one user. All I need is ONE API key for ONE account. But I'm forced to use OAuth. It doesn't seem appropriate, and it's especially concerning that the "flow" requires the (non-expiring!) Access Token to be shared with a third party server. Why?!?
I recently learned that Stripe has been pushing OAuth (branded as "Stripe Connect") to its integration apps as the "more secure" solution, compared to Restricted API
(I see my reply yesterday didn't federate; trying again from an alt instance)
o hai. Curious that you expected a bunch of people to support you within a couple days. I never saw your proposal (buried in a comment thread in one post on lemmy). I'm only first hearing of this 6 hours after you specifically tagged me. I think you could do more to publish & advocate your proposals if you're serious about them..
Before the incident described in the article you're referencing, I had never spoken to any instance admins. Since I published it, I have spoken to several instance admins (many reached out to me), and they all expressed similar frustrations with the lemmy devs and fatigue in contributing to this project.
No matter how much people will tell you that something is important to them, the true test is seeing how many are willing to pay the asking price.
I think it's important to consider that there's many ways that people contribute to Lemmy. Equally as important as the work that the devs are doing is the work that the instance admins are doing. Collectively the community of instance admins are contributing much more money and time into lemmy than the developers are. That shouldn't be discounted. Both should be appreciated.
There are other ways that people take time out of their lives to support Lemmy, such as finding and filing bug reports, writing documentation, answering questions about the fediverse to new users, raising awareness about lemmy on other centralized platforms, etc. These are also all contributions that benefits the project. Don't discount them.
But when our contributions are met with disrespect, it pushes us away. Based on my conversations with countless Lemmy contributors in the past few days, that's where a lot of people are. They don't want to invest any more time or money into Lemmy because of their previous interactions with the Lemmy devs.
This can be repaired, but the Lemmy devs do need to work on fixing their Image Problem.
oh, I got too excited. The instance sidebar says image uploads are available 4 weeks after account creation, though :(
This is false.
In the case of the article, the image was never sent to other servers. In fact, that is the last thing it does.
How? I want to block my app from being able to upload images.
Author here. A "KYC Selfie" is a selfie photo where you hold-up a State-issued photo-identity document next to your face. This is not a US-specific thing; it's also used in the EU.
I used to work for a bank in Europe where we used KYC seflies for authentication of customers opening new accounts (or recovering accounts from lost credentials), including European customers. Most KYC Selfies are taken with a passport (where all the information is on one-side), but if your ID has data on both sides then the entity asking you for the KYC seflie may require you to take two photos: showing both sides.
Some countries in the EU have cryptographic authentication with eIDs. The example I linked-to in the article is Estonia, who has made auth-by-State-issued-private-key mandatory for over a decade. Currently MEPs are deciding on an eID standard, which is targeting making eIDs a requirement for all EU Member States by 2016.
I recommend the Please Identify Yourself! talk at 37c3 about the state of eID legislation as of Dec 2023 (and how to learn from India, who did eID horribly wrong):
They definitely should remove it, at least until moderation tools are available.
That’s a great idea :) Maybe you can submit a feature request for this on GitHub?
We already have Sublinks
Better to publish such issues on a public website than let it get buried in matrix. People other than devs & instance admins need to be aware of the risks that they’re taking when using Lemmy.
Under GDPR you can just send a request for them to send you all of the data that they’ve stored about you on their backend.
It's also hard for admins to delete it from their own instance:
If you want this to be fixed, please tell the devs on the relevant GitHub Ticket
For some reason they think I'm literally the only person who wants it? At least that's what they keep saying as the reason for why they won't work on it.
It would be possible to locally save the delete tokens of every image you upload, so that you can request that they be removed later. I don’t know of any clients that can do this yet, though (if someone knows of one, feel free to mention it).
@[email protected] I'm told Boost does this.
PSA: Upgrade your LUKS PBKDF to Argon2id !!
TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.
When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.
The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.
And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.
PSA: Upgrade your LUKS PBKDF to Argon2id!
TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.
When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.
The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.
And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.
PSA: Upgrade your LUKS PBKDF to Argon2id!
TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.
When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.
The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.
And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.
PSA: Upgrade your LUKS PBKDF to Argon2id !!
TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.
When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.
The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.
And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.
PSA: Upgrade your LUKS PBKDF to Argon2id !!
TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.
When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.
The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.
And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.
PSA: Upgrade your LUKS PBKDF to Argon2id !!
TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.
When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.
The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.
And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.
PSA: Upgrade your LUKS PBKDF to Argon2id !!
TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.
When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.
The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.
And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.
PSA: Upgrade your LUKS PBKDF to Argon2id !!
TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.
When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.
The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.
And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.
PSA: Upgrade your LUKS PBKDF to Argon2id !!
TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.
When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.
The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.
And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.