Would also be cool if they had an aux jack

Oh wow, there’s no aux jack!?! Thanks for pointing that out. That kills this for me.

I am guessing they don’t have an IP protection for liquid/dust.

The product page’s specification’s section lists it as having “IP66 certification: Splash proof and dust resistant”

Before this launch, could you walk into a store in The Netherlands, pay cash, and walk out with a anonymously-purchased SHIFT phone?

Can you walk into a store in The Netherlands, pay cash, and walk out with a anonymously-purchased SHIFT phone?

looks like they’re collaborating by giving some of their profits upstream, and creating feature requests

hardened LinaegeOS forks seems like exactly what we need…

Isn’t the whole point that this thing can be upgraded?

Also, Pixel 3 still runs great, once you strip off all the google spyware.

Yeah, small dutch company that has a good history. They’ve been making highly customizable laptops for the EU market since 2015. And since 2021, they’ve been focusing on security and right-to-repair. You can watch an interview with the NovaCustom founder (Wessel Klein Snakenborg) here:

• https://techlore.tv/w/hAQNnw9eQndZRJe438DqRF

They’re one of very few laptop manufacturers that sell QubesOS certified laptops. And that come with coreboot.

Upon further reading of RFC 6749, it appears that OAuth does require this – sometimes.

It depends on the OAuth Flow. In this case, Stripe uses the “Authorization Code” Grant.

This is documented in Stripe’s OAuth reference documentation here:

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

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

Authorization Code Grants are defined in RFC 6749 (The OAuth 2.0 Authorization Framework), Section 4.1 (Authorization Code Grant):

• https://www.rfc-editor.org/rfc/rfc6749.html#section-4.1

To better understand why the OAuth Authorization Code Grant requires sharing the access token with a thrid party server, I found this article (Common OAuth Vulnerabilities) by Doyensec very elucidating:

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

It says that the Authorization Code Flow is supposed to be used when you don’t want to share the tokens with the user agent.

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.

But this doesn’t make sense for this use-case. It appears Stripe is needlessly putting us at risk by choosing the Authorization Code Grant.

Thanks, but I don’t think this is the case here. The Authentication provider is Stripe (or, at least, it’s a stripe.com domain name). The 3rd party is the app developer’s server.

Stripe’s infra is already PCI compliant.

I’m not sure how a hardware security token would be relevant here. The end result must be something-you-know access token. Initial setup is done with 2FA, sure. But I don’t think the server can store (or emulate) a passkey. The issue here isn’t how I authenticate with Stripe. It’s after that – when Stripe gives the tokens to the third party (the dev’s server) and then the third party gives the token to my server. I don’t understand why Stripe doesn’t just let the devs implement it so Stripe gives the tokens directly to my server.