- Not necessarily.
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.
- I think the author of the article really misses the point here. While "true multitasking" might be a neat technical feature, it's not something that the end user really cares about or would base a buying decision on, especially if running multiple apps in the background at the same time came at the expense of battery life. Those early versions of iOS employed a lot of tricks to squeeze performance and battery life out of underpowered devices.
- I once did something similar with a recipe from a cookbook where the recipe started at the bottom of one page and continued onto the next page. It correctly identified the first few ingredients present in the photo of the first page but then proceeded to hallucinate another half-dozen or so ingredients in order to generate a complete recipe.
- > If I try to do an UPDATE ... SET x = x + 1, that will always increment correctly in SQL. But if read x from an ORM object and write back x + 1, that looks like I'm just writing a constant, right?
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.
- Yes I suspect a lot of the ORM hate comes 1) from people using poorly designed ones or 2) from people working on projects that don't really require the features I mentioned. Like if you are generating reports that just issue a bunch of queries and then dump the results to the screen you probably don't care that much about the lifetime of what you've retrieved. But just because an ORM might not be the right tool for your project doesn't make it a bad tool overall, that would be like saying hammers are bad tools because they can't be used to screw in screws.
- I've never understood the ORM hate because a good ORM will get out of the way and let you write raw SQL when necessary while still offering all of the benefits you get out of an ORM when working with query results:
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.
- Before becoming too overconfident in SQLite note that Rebello et al. (https://ramalagappan.github.io/pdfs/papers/cuttlefs.pdf) tested SQLite (along with Redis, LMDB, LevelDB, and PostgreSQL) using a proxy file system to simulate fsync errors and found that none of them handled all failure conditions safely.
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.
- Your quote does not actually contradict my original statement, full reply here: https://www.hackerneue.com/item?id=42743263
- I suppose this comes down to the interpretation of the documentation. Note that it only says "a workspace", not "a specific workspace" or "which workspace".
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.
- > In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application.
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.
- > If I log in using Google oauth, you already know the Google account is active.
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=...
- Assuming the above is correct, if you decide to connect Google SSO to your application using option (3), then it is not a vulnerability that a Google account from a different workspace can connect to your application, because the entire point of option (3) is that users with any Google account (regardless of workspace) can connect to your application.
If you intended to restrict your application to users of your own workspace then you should have used option (1) or (2).
- > despite Google's docs stating that this is a valid use. :)
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.
- Google's public OAuth is intended for situations where you want to allow anyone with a Google account to login to your application, regardless of workspace. Given that, it is not a Google OAuth vulnerability that a user can login to your application using a Google account from a different workspace.
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.)
- If I'm understanding your comment correctly there are three different ways to connect Google SSO to your application:
1. SAML. This avoids the issue because certificates need to be exchanged between Google and your application, but an attacker that recreates a duplicate workspace using your domain won't have access to those certificates. Only users from your workspace will be allowed to login.
2. A custom Google OIDC IdP configured for internal access only. This also avoids the issue because a secret key is required to set this up and the attacker won't have access to that key. Again, only users from your workspace will be allowed to login.
3. The public Google OAuth API which will allow any Google user from any workspace (or non-workspace users) to login to your application.
Is this correct?
- > And people are telling you that this is not possible with the Google public OAuth API.
Yes I understand, however it is possible to integrate Slack and Google SSO in such a way that it checks that the user belongs to the correct workspace, correct? Either via the SAML integration (https://support.google.com/a/answer/6357481) or an internal Google OAuth integration? The purpose of the public Google OAuth API as opposed to the previous two options is to allow logins from non-workspace or cross-workspace Google accounts, correct?
- What I'm suggesting is if you were able to pre-configure Slack to only allow logins for valid users from Google Workspace X, then even if someone creates a new workspace Y with the same domain, Slack would still be checking against workspace X. (And similar for non-Google based identity providers.)
- I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee.
If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@company.com was a valid user that should be allowed to login, then this problem would be avoided entirely because the defunct company would no longer report any valid users.
This would also avoid further problems with attackers being able to login with unattended email addresses like support@company.com, as was discussed here: https://www.hackerneue.com/item?id=41818459 (There's a lot of discussion below about whether the "sub" claim is stable or not but it's a red herring because of this IMO, also the proposed fix in the article wouldn't address it either.)
- > I worry about things like fetching new data into a page not altering the screen reader user in the same way as refreshing a page completely would.
Isn't this more of a general browser question that would apply to any website that uses Javascript to load page elements?
How would using HTMX (as opposed to any other library, or plain old Javascript) affect the answer to the question?
- As far as I can tell the two main criticisms in the video are that:
1. The Redis API requires the developer to use different commands to retrieve/manipulate data depending on the type of data being stored. To retrieve a string you use GET, but if you want to retrieve a list it's LRANGE, for a set it's SMEMBERS, for a hash it's HGETALL. (As opposed to an API design which would allow you to call GET on all of the different data types and have it return the right thing.)
2. The lack of a predefined schema means you can overwrite values with different types. So you can create a list named "foo" and then overwrite it with a string named "foo" and then overwrite that with a hash named "foo" and Redis will happily do it, meaning the developer needs to keep track on their end what actual type any given key is holding onto.
To me these criticisms come across as essentially saying "Redis doesn't behave like a RDBMS" to which I suppose antirez's point is "well, yeah, it's not supposed to".
- Just to be clear, the Justice Department has filed a lawsuit but they have not actually won it. Until a judge or jury rules in their favor (and appeals are exhausted) you cannot cite the mere existence of a lawsuit as proof of anything. Keep in mind that Epic also filed a lawsuit claiming Apple was a monopoly but could not prove it in court.
> 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?