101–110 of 118 posts
Earlier quoted context omitted.
It is sad when even here people dont care about the right to run whatever code you want in the hardware you own.
You're mistaken, you don't actually own it.
As far as the software - Apple owns iOS and licenses it to you for your device.
Earlier quoted context omitted.
They're not a monopoly; they're a duopoly. It is a marginally better position but I have no idea how you justify to yourself handing over a consumer's power to the largest tech company in the world.
Because it's a set of tradeoffs and not a strict better/worse?
Earlier quoted context omitted.
Windows isn't a platform for developers. It's a platform for normie consoomers. Isn't that obvious? If you want an engineering OS, use GNU/Linux.
Yes that's easy advice to follow when you don't have a job
At my job, we build cross-platform software, but we build it on Linux. It runs on Windows, but building it on Windows is torture, so almost all our dev machines are Linux.
Earlier quoted context omitted.
Until you can run a Windows-free build system with WINE (there are a few reported blockers, several others and I have tried) and PyInstaller, cross-platform apps will require developers to compile their Windows ports on Windows itself. Windows is where the users are. Not targeting it is a bad financial decision.
Past 10 years we ship py2exe based Win32/Win64 software from WINE / Ubuntu There are no problems - we don't sign it ( https://www.vintech.bg )
Can we have Separation of Powers on our digital platforms? It is pretty shitty that the one who sells phones also determines what goes on them.
Earlier quoted context omitted.
The wording could be better. But it has been known for over a decade now that Apple searches binaries for strings. They've never done runtime execution checks which would pick up you actually making such an HTTP call.
My baseline would be similar to that which you get from modern compilers and automated tests. Something like: Lib/urllib/parse.py contains disallowed string "itms-services" at line 62 column 25 Reason: Apps may not install or launch executable code, such as through the itms-services URI schema. To get credit for "giving you a clear direction", I'd want them to make available and suggest a fix. In general that could b…
1. Apple received a copy of your source code to do source analysis
2. Apple actually supported running python code as an option for writing iOS apps and wrote source code analysis tools for python for reporting compliance issues
neither of these are true.
Earlier quoted context omitted.
Python just has to rot13 the scheme and hash the encrypted schemes.
That came up in the original post with whether an obfuscation could be an acceptable workaround; but it came up that Apple really doesn’t like obfuscation techniques. The workaround for now is a compiler flag that excludes problematic code from iOS builds. I’m still asking though why, if Apple doesn’t like apps which use this protocol, the sandbox is not intervening; as surely an approved app could have a malicious w…
That sounds like the correct fix, in that it is least likely to get your developer account banned
Earlier quoted context omitted.
Sandboxed apps are allowed to use itms-services:// links, it's just not allowed in the App Store - iOS enterprise apps using in-house deployments can use it for installs and updates, and sandboxed Mac apps deployed outside of the App Store can use it as well. However, App Review Guidelines forbid App Store apps from installing other apps, so that scheme gets scanned during review.
That makes some sense, but then I have a new question: Why doesn’t Apple have different certificate schemes for in-house versus App Store (if they don’t already)? In which case, the iOS Sandbox should be smart enough, and probably does already delineate, allowed functionality based on whether an app comes via App Store or via a private deployment.
Enterprise distribution allows you to deploy applications to corporate managed devices with no App Store review whatsoever. The restrictions are mostly in the business agreement in who you can provide enterprise distribution to (e.g. employees and contractors) and on what your apps can do. The justification is that the enterprise has a relationship with the employee/contractor, is ultimately on the hook for abuses/harms they do via MDM on employee devices.
This is the situation that led to both Facebook and Google having their enterprise accounts banned temporarily a few years ago, as they were each using them as part of a market analysis program - they offered to install VPN software onto consumer devices that monitored web and third-party app usage. Such monitoring is not allowed even for employees per the enterprise developer account agreement.
Why does urllib have this URL scheme anyway? If Python libraries are hard-coding knowledge about Apple proprietary stuff, then it should be no surprise that Apple may take issue with that.
I believe it was added as the `itms-services://?` URL format is non-standard and broke the existing logic in `urllib.parse`: https://github.com/python/cpython/pull/104312
The authority consists of a host with a blank name and blank path (path-abempty).
The issue is a lot of libraries do not make a distinction between a field explicitly being declared blank and being left undeclared (e.g. nil vs ""). Looks like rather than change python's URL library to recognize this distinction, they created an exception list that just hard-codes output behavior.
One can make a case that client software should be robust enough to handle both forms of URL (e.g. itms-service URLs are likely just URI, but the original developers thought all URI should have two forward slashes in them). I can say specifically for "scheme://" calls that such robustness on the recipient side is very rare, because if they understood URI well enough to be robust then they wouldn't have had two extra slashes that they will never use.
Earlier quoted context omitted.
I believe it was added as the `itms-services://?` URL format is non-standard and broke the existing logic in `urllib.parse`: https://github.com/python/cpython/pull/104312
My understanding per RFC 3986 is this is a valid URL. The authority consists of a host with a blank name and blank path (path-abempty). The issue is a lot of libraries do not make a distinction between a field explicitly being declared blank and being left undeclared (e.g. nil vs ""). Looks like rather than change python's URL library to recognize this distinction, they created an exception list that just hard-codes…
¹Also I checked, that standard does actually define an empty host (https://url.spec.whatwg.org/#empty-host) as a distinct concept from a null host.