I get the appeal of manual levers to espresso enthusiasts but would strongly dissuade beginners from starting with one. When you are learning to dial in a shot what you want is consistency and reproducibility which is the opposite of what you get with a manual lever.

Also it doesn't steam milk so you need to figure out a separate solution for steaming if you want to make a flat white/cappuccino/latte/etc.

That's not to say you should dump thousands of dollars into a La Marzocco, but there are plenty of entry level machines in the $300-500 range that would suit a beginner just fine.

> although inter-personal coefficient of variation is up to 28.3%

Why does that matter? Isn't the entire point of this study's design to eliminate the impact of the inherent variability between test subjects?

For starters, small companies are paying 15%, not 30%.

I'm also not sure where a small company can find a payment processor that will only charge 1%. Stripe charges 2.9% plus 30 cents per transaction.

If you have a $4.99 in-app purchase that will cost you 44 cents per transaction to use Stripe vs 75 cents to use Apple's IAP.

But Stripe does not act as a merchant of record so you are responsible for remitting sales tax yourself. Registering for and remitting sales tax in every jurisdiction where you have nexus adds huge administrative overhead to a small company.

If you want to avoid this overhead, Paddle will act as a merchant of record for you, but then you're paying 5% plus 50 cents which adds up to 75 cents on a $4.99 purchase anyway.

Linking to external payments also reduces conversion rates (https://www.revenuecat.com/blog/growth/iap-vs-web-purchases-...) compared to using IAP.

Taken all together, depending on their pricing structure, small companies may very well be financially better off sticking with IAP rather than linking to external payments anyway.

This is not specific to ORMs... you can run into the same problem without one.

> Extra magic: if you've read a class from the db, pass it around, and then modify a field in that class, will that perform a db update: now? later? never?

In every ORM I've used you have specific control over when this happens.

1. Mapping result rows back to objects, especially from joins where you will get back multiple rows per "object" that need to be collated.

2. Automatic handling of many-to-many relationships so you don't have to track which ids to add/remove from the join table yourself.

3. Identity mapping so if you query for the same object in different parts of your UI you always get the same underlying instance back.

4. Unit of work tracking so if you modify two properties of one object and one property of another the correct SQL is issued to only update those three particular columns.

5. Object change events so if you fetch a list of objects to display in the UI and some other part of your UI (or a background thread) add/updates/deletes an object, your list is automatically updated.

6. And finally in cases where your SQL is dynamic having a query builder is way cleaner than concatenating strings together.

For those who are against ORMs I am curious how you deal with these problems instead.

I keep telling my users to make sure to plug their phones in before the battery dies, but for some reason they keep forgetting...

In practice I believe I've seen SQLite databases corrupted due to what I suspect are two main causes:

1. The device powering off during the middle of a write, and

2. The device running out of space during the middle of a write.

1) The "hd" claim tells you that the user is a member of a workspace. If the user is a member of a workspace it tells you the domain name of that workspace.

2) The "hd" claim tells you which specific workspace the user is a member of.

You are taking interpretation (2) whereas I am taking interpretation (1). I believe interpretation (1) is correct given the next sentence says you can use the "hd" claim to restrict access to only members of certain domains. If interpretation (2) was intended, they could have instead said you can use the "hd" claim to restrict access to only members of a certain workspace.

If Google is at fault for anything here it is for writing confusing documentation, however given the totality of the documentation where:

a) Google describes public applications as intended for logins from all Google accounts regardless of workspace, and

b) Google offers the internal application option for situations where you want to restrict logins to users of a specific workplace,

I'm going to stand by my conclusion that the real fault lies with service providers choosing the wrong integration option in the first place and then making invalid assumptions about what information the "hd" claim supplies in the public option.

There are plenty of use cases where this is appropriate. If you wanted to allow users to login to Hacker News with their Google accounts you would use this option because you do not care what workspace they belong to.

> Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts.

This is a misuse of the public Google OAuth API. Your first link clearly states: "A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." In other words it is intended for scenarios where you want to allow access to users outside your workspace.

> Instead, Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes.

According to your second link the "hd" parameter only tells you what domain the user belongs to, it does not tell you what workspace the user belongs to.

> You can avoid this issue by using a custom Google OIDC IdP configured for internal access only in your applications, rather than using a pre-configured public Google OIDC IdP

So Google offers an OAuth integration option that actually restricts access to your specific workspace. Choosing to ignore this option and instead integrating with the option designed for public access from all Google accounts, and then calling it a vulnerability when someone can login with an account from another workspace, is frankly, absurd.

You know there is an active Google account but (for the public OAuth integration option) it can be any Google account from any workspace, or no workspace.

"A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." [1]

> Yes, but that's an additional check, separate from the one you suggested would eliminate the issue:

If you set up an internal OAuth integration option no separate check is necessary, it will actually restrict access to users of your workspace.

"An internal application will only allow access to users from your organization (@your-organization.com)." [1]

You can use the SAML integration option as well. [2]

[1] https://support.google.com/cloud/answer/6158849?hl=en#zippy=...

[2] https://support.google.com/a/answer/6357481

If you intended to restrict your application to users of your own workspace then you should have used option (1) or (2).

I don't think Google's docs actually say this. I assume you are referring to the "hd" claim, but that only says:

"The domain associated with the Google Workspace or Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization. You must check this claim when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain."

It does not say you can use this claim to restrict access to members of a certain workspace, only for a certain domain.

I think certain service providers might have made the assumption that if a user belongs to a certain domain that also means they belong to a certain workspace, but that is clearly not a valid assumption.

I think that Google's public OAuth integration is only intended for use in situations where you want to allow logins from any Google account, regardless of workspace membership, and if you want to restrict logins to Google accounts belonging to a specific workspace, you are supposed to use one of the other integrations.

Given all that, I still do not think this is a problem with Google's OAuth implementation. Instead it is a problem with service providers who have incorrectly used the wrong type of Google SSO integration. Or in the case of service providers that offer multiple Google SSO integration options (like Slack), it is a problem with the company for selecting the wrong one.

If you want to integrate Google SSO into your application and restrict logins to a specific workspace, there are other options you can use that will actually check if the user belongs to that workspace (SAML or internal OAuth).

To the extent that service providers are using Google's public OAuth and then trying to read the domain name out of the returned ID token in order to restrict logins a specific Google workspace, they are using Google's public OAuth instance for a situation it was not intended for because domain names do not map 1:1 to workspaces. However that is a vulnerability on the service provider's side, not Google's.

To the extent that a service provider offers Google SSO integration via Google's public OAuth but also via workspace restricted options, if a company selects the former instead of the latter then the responsibility for the vulnerability is on the company's side. (Slack, for example, offers both because there are some Slack groups where allowing access from any Google account makes sense, and other groups where you would want to restrict access to Google accounts from a specific workspace.)