OmniFocus has a similar thing, with a standalone “Enterprise” edition (https://apps.apple.com/us/app/omnifocus-3-enterprise/id14847...), where IAP is replaced with an upfront price. I believe it’s because schools can get a volume discount on paid apps but not IAP, and Omni says it “simplifies deployment” for enterprise users.
I’m pretty sure OP is referring to Photos for macOS Preferences > iCloud > “Download Originals to this Mac” - you can move your .photoslibrary file to an external or network drive if you need for space reasons.
Then all your files can be accessed with the .photoslibrary file context menu, “Show Package Contents”, “originals” folder.
Don’t forget that neither is a pure VPN, though that’s not always a bad thing — Private Relay is better than a VPN because onion routing means “no one party”[1] can correlate your connections and identity.
However WARP, being more like a VPN, requires you to trust Cloudflare to not log DNS lookups / the servers you connect to and associate that with your origin IP.
Why do I hesitate to call WARP a real VPN? It reveals your actual IP address to websites you visit via X-Forwarded-For. [2]
Also I think the fact that iCloud Private Relay will be built-in makes it more private than WARP — more users’ traffic will come out of each node.
[1]: Obviously this is imperfect because the Apple (which knows your IP) and third-party (which knows the network traffic) nodes will likely be in the same jurisdiction as each other, subject to the same laws, as mentioned by other commenters.
I think the distaste for Day One’s subscription stems from the fact that an update removed the ability to sync on the user’s platform of choice (iCloud or Dropbox) which they were already paying for, and forced them into the first-party service.
- There’s Clip, a clipboard manager that plays silent audio for backgrounding (something that wouldn’t be allowed in the App Store) and uses a notification extension to allow you to quickly save the current content of your clipboard.
- Delta is a polished game system emulator — part of another category that isn’t allowed on the App Store.
It’s also a distribution mechanism; one could host their own repo of apps. Also AltStore lets you sideload arbitrary IPA files (from backups or devs without a Dev Program membership, for instance).
IMO AltStore is cool because it lets you use your iDevice more like a computer without breaking OS protections.
The issue here is that Apple makes phones (the iOS App Store is the subject of much if these articles) where they are the gatekeepers to the only method of software installation, making this compliance more problematic.
That’s an interesting way to look at it. Funny how this news can be interpreted as both signaling Apple’s interest in E2EE iCloud Photos or weaking their overall privacy stance.
I agree Signal’s default security is a whole lot better than iMessage, which trusts Apple for key exchange and makes it impossible to verify the parties or even the number of parties your messages are being signed for. Default security is super important for communication apps because peers are less likely to tweak settings and know about verification screens.
I think self-hosting email has too many downsides (spam filtering, for example) to be worth it; I’m more concerned about losing my messages (easily solved with POP or mbox exports while still using a cloud account) than government data sharing. Email is unencrypted in transit anyway, and it’s “industry standard” to store it in clear text at each end.
This is the worst tech news headline I’ve ever seen. The change the article is referring to is allowing developers to refer to non-IAP payments in communication with users outside the app (the fact that this was disallowed before blows my mind). This does absolutely nothing to change the in-app anti-steering rules Apple has.
I think I should clarify what changed in the rules. Apple attempted to stop any mass communication to your users from mentioning another way to pay. If they signed up in the app Apple still wanted to lock them in as an IAP customer.
Now you can send bulk emails to consenting account holders and mention non-IAP payment methods without running afoul of the rules.
> 3.1.3 Other Purchase Methods: The following apps may use purchase methods other than in-app purchase. Apps in this section cannot, either within the app or through communications sent to points of contact obtained from account registration within the app (like email or text), encourage users to use a purchasing method other than in-app purchase.
That's been changed to:
> 3.1.3 Other Purchase Methods: The following apps may use purchase methods other than in-app purchase. Apps in this section cannot, within the app, encourage users to use a purchasing method other than in-app purchase. Developers cannot use information obtained within the app to target individual users outside of the app to use purchasing methods other than in-app purchase (such as sending an individual user an email about other purchasing methods after that individual signs up for an account within the app). Developers can send communications outside of the app to their user base about purchasing methods other than in-app purchase.
Then the AFAIK unchanged exceptions follow: "reader" (any content store), multiplatform services (yes the guidelines are made so strict allowing the use of previously purchased accounts had to be an exception, "provided those items are also available as in-app purchases within the app"), P2P, "goods and services outside the app", etc.
They still can't link to third-party payments. The only change is that after users have opted-in to [X company]'s marketing email, the company is allowed to talk about their own payment system to their own mailing list. You know, after the customer has likely already set up an IAP subscription where Apple takes 30%.
They cannot send you to a URL and still can't mention non-IAP payments from the app. Only in a bulk email to users. Emailing your own users and providing them a way to pay for your cross-platform service was disallowed before.
I could be wrong but I interpreted the contact information mention this way.
AFAIK it intends to disallow transactional emails like signup (welcome to netflix) from pushing third-party IAP:
> Developers cannot use information obtained within the app to target individual users outside of the app ... (such as sending an individual user an email about other purchasing methods ...
But that generic sentence means you can have a bulk mailing list with messages that mention your own payment option:
> Developers can send communications outside of the app to their user base about purchasing methods other than in-app purchase.
No, AFAICT that flow wouldn’t be permitted. Only bulk emails to customers that have signed up, making the change pretty useless and the previous rule seem absurd.
At the same time, the native and WebExtension clients are proprietary and autoupdate by default. Travel Mode can only be accessed by typing your decryption keys into the live website (my.1password.com). An infrastructure compromise would be even worse than a database dump.
A lot of these spammers start with a repo’s stargazer list, so I’ve been slowly unstarring everything — if enough people do this GitHub will have to fight at least that kind of scraping. I recommend making a special email alias for git you can rotate, or at least send to a folder you don’t check often.
Does anyone here think an open source blocklist for domains associated with this developer-targeted spam would be useful?
I’m talking about a genre of emails where the targets are those who’ve simply starred a GitHub repo. Even if they get the actual email addresses from a git log or off-platform, they’re still abusing the GitHub API (or screen-scraping) to discover users to spam in the first place. It is possible for GitHub to guard those list pages with captchas and use reports to catch API abusers.
> … we have committed not to pursue any license violation that results solely from the conflict between the GNU GPLv3 and the Apple App Store terms of service, including the FOSS-specific policies as outlined in sections 3.3.22, 5.1, and 9.1
> Until March 2020, the attestations said USDC was backed by dollars, held in government-backed US depository institutions. After that, they said the reserves were held at institutions and in “approved investments”, but did not give precise details about what those investments were. By June, it changed the wording on its website from “backed by US dollars” to “backed by fully reserved assets”.
Don’t know enough about iOS to say for sure about persistence, but recent Pegasus (NSO Group spyware) versions don’t bother[1], instead repeatedly exploiting bugs starting with “features” like background Messages attachment parsing.
Those are the kind of threats Lockdown Mode finally acknowledges — targets (well IMO everyone) would need it permanently enabled.
Otherwise the temporary protection before clicking a link can be had today in other ways, like disabling Settings > Safari > Advanced > JavaScript.
I’m sub-$20. My only work post-graduation (CS) has been a contract with a non-tech org that can’t really afford it. It’s remote, and I currently live in a US state with barely any tech companies.
If Chromium is a requirement I’d choose the ungoogled-chromium flatpak but for normal people Brave is preferable over proprietary options, despite the crypto bullshit.
(edit to add info and link)