You're implying that this is a mislabeled long exposure photograph. The fact that you can see distinct ripples at all shows the exposure time was less than a second. I think it's fair to call three lightning strikes within a second of each other "simultaneous".
Do you have a reasonable example of why a library that would call location or history?
All I can think of is "using query string as getenv() for random debug hacks" or "using history as a hack to synchronously reach the structured clone algorithm", neither of which a library should do (but both easily emulatable).
> The first two values — the time taken for a RunInstances API call to successfully return, and the time taken after RunInstances returns before a DescribeInstances call says that the instance is "running" — are consistent across all the AMIs I tested, at roughly 1.5 and 6.9 seconds respectively
“Running to available” is what’s in the table, ranging from 1.23s to 70 or so.
Who is responsible for issues caused by Epic's store? What are the ramifications from an API point of view? Will having another store change the limitiations imposed on what can or can't be done? If so, people already have a choice - Android.
Another reply said "censor" which implies speech, but Apple's rejections can be more fundamental.
Have an app you want to ship? Apple gets to decide whether you meet "minimum functionality requirements". You cannot distribute your app to paying consumers without their approval.
Doing something truly unique, perhaps with some hardware in the phone? Apple may decide they simply do not want this feature in an app on the App Store. Which means you cannot distribute your app to consumers.
I'm less concerned about having other "stores," I just want a way to buy apps from legit developers that don't involve Apple dictating look and feel and entire feature sets.
You know, the same way I can purchase and run software on a Mac without Apple being involved in the transaction.
Apple's rules are completely arbituary, so many apps simply don't exist due to vague guidelines. There are zero 4chan apps on the app store, but a dozen reddit apps (which is ironic given recent news over there). There are dozens of these odd edge cases based on Apple's whimsy that just means there are zero IOS options for what Android has dozens of, even before getting into "obviously" banned content like adult apps and piracy.
So while a few (like, literally 5-10) blockbuster game companies may take the PC launcher route if this wins, there are several smaller time apps that can benefit form this if the app store wasn't the only source of downloading here.
The option to install applications that are censored by the the Default App Store for whatever reason.
Plus, this case probably has pretty far reaching implications on the future of computing. If Apple is allowed to lock down their phones & tables, can they do so with Mac OSX? If Apple can do so with OSX, can Microsoft do the same and lock down Windows to prevent apps from being installed outside of their App Store?
If Microsoft can lock down Windows like iOS/OSX, can Dell lock down their servers to prevent other operating systems from being installed?
Being able to have Microsoft XCloud (and other cloud gaming) as a native app instead of forced to only have the Apple games/arcade.
This is one example of a completely legitimate scenario in a very popular entertainment category and yet it's blocked because of Apple's arbitrary rules of what you can do on your own device.
It still has to run on the IPhone and ask for location, ad ID, etc. from iOS. Where the app comes from doesn't change that it must make the same system calls as everything else.
All apps on iOS need to pass App Store review, which means all apps that integrate third-party SDKs need to ensure those SDKs don't violate App Store policies, including policies on fingerprinting. Apple has already started to deny approval of apps using third-party SDKs that violate user tracking policies on iOS 14.
Of course you can. You're entirely missing the point, which is that without a review process that sets explicit limits for how data can be used, developers will abuse system APIs to violate user privacy.
Restricting APIs doesn't solve the problem because there are plenty of APIs that apps need for legitimate purposes but can be abused by bad actors. Many of the APIs used for device fingerprinting would fall under this category.
There's a difference between sneaking through App Store review and not enforcing anything at all. People still shoplift even though theft is a crime, that's not an argument against having laws.
No. Apple provides a door (advertising ID) but there's also a window (fingerprinting). Right now both things exist. Apps already have the ability to fingerprint users with data they collect and that's not sneaky.
That's a strange argument though. Apple forks over an advertising ID so that any app can fingerprint you with a single system call yet you complain that more apps might in the future fingerprint you themselves.
Without app review there would be no practical way for end users to avoid fingerprinting.
> That's a strange argument though.
Only if you don't consider consent. A user opting-in and enabling the advertising ID is very different from a bunch of apps using third-party SDKs to fingerprint their device without asking.
What does it do on Google's app store? If they are still playing by google's rules, why would they take themselves off Apple's store? is Apple's data more valuable than Google's?
These kinds of theoreticals have likely already been addressed with Apple's biggest competitor. Androids aren't known to be virus ridden privacy compromising devices. At least, no more than any device with communication antennas installed.
Figure 3 provides a breakdown of infections by device type in 2020. Among smartphones, Android devices are the most commonly targeted by malware. Android devices were responsible
for 26.64% of all infections, Windows/PCs for 38.92%, IoT devices for 32.72% and only 1.72% for iPhones.
statistically, maybe. But it's more about mindshare in cases like these. IoT devices based on your report is even more prone to compromises, but there's not much fear for a person's fridge being compromised.
And as always, these cases come down to how many people really concern themselves with that risk. Windows has had that reputation, but it hasn't helped Apple that much in terms of Mac adoption, let alone Linux.
I'm not sure why mindshare is relevant? You might not worry much about your fridge being compromised, but these days smartphones contain a lot of personal data which could be very problematic if compromised. There is even Android malware out there that steals 2FA codes.
because many people commenting on security and privacy aren't necessarily experts on such topics. Their interpretations of what is secure or not comes from marketing and word of mouth.
If you look at the stats in an extremely stark interpretation; no device is perfectly secure (0%), but no device is so malware ridden that you are more likely than not to be compromised (50%). most users will be safe as long as they don't go out of their way to disable default security settings, and few need to. In that way, privacy won't be the main factor determining why a user purchases a device or chooses an OS.
In that respect, What a user feels (or what their immediate bubble feels) has more weight than any statistical reality. Or in other words, "mindshare".
It would be WeChat, which is an entire ecosystem and OS within itself. Apple seems to regret letting that one through and is determined to not let it happen again.
That's true -- the parser can just translate any lookalike errors into the canonical character.
But I wish the standard was to keep all digits and drop the lookalike letters. I can't think of a reason for the extra (human) burden of remembering whether it's 0 over O, or I over 1, etc.
Being liberal in what you accept is fine, but being strict in what you emit requires extra mental overhead.
It's nothing cataclysmic (and "on the developer" is a often a reasonable place to add the extra overhead) but in this case it seems like selecting 0 instead of O or o, and 1 instead of I or l, would have been more straightforward.
Selecting "1" (ASCII 49), and "o" (ASCII 111) is inconsistent and feels odd.
EDIT: OK, I can think of one possible justification: with zero disallowed, a leading zero can never be lost. In a short Base58 string, it's not unusual for all characters to be numeric, and some overzealous readers will interpret the whole value as an integer. See also: hex strings, US ZIP codes, ABA routing numbers, etc, vs Microsoft Excel. :)
EDIT2: Nevermind, that's a lame justification. The likelihood of a Base58 string of any useful length containing numeric chars only is very low, since the alphabet would be 17.2% numeric) unlike hex strings (61.5% numeric), or ZIP codes and ABA numbers (100% numeric). Additionally, IIRC Base58 was invented for BTC addresses, which necessarily started (at the time) with a "1" char (now "1", "3", or "bc1").
I think you're missing the fundamental point that the pair 0 O is very easily confused, but o O and o 0 are less easily confused, by virtue of differing height.
I do understand, but that's only true for [0Oo], and does not help with [1Il]. In either case, the risk of human confusion is removed by transliteration in parser code.
But on the parser implementation side, I need to remember that numeric 0 maps to lowercase o, but lowercase l maps to numeric 1.
My thought is that it would be simpler to only remember one rule: numeric chars are canonical, lookalikes are dropped.
Clearly, not a big deal -- you write it once, correctly, and move on (or try to!). That "once" has apparently stuck in my head, and now a few years later I still wonder about the reason for the design choice. :)
So the big idea is "simulate user keypresses and mouse events", and it works if the user answers "yes" to the prompt "Program X wants to control other programs on this computer".
To be fair, Steam games request that permission, so users may be trained to accept it.
I thought so too, but the paper version apparently has a ridiculously high (user) error rate. When the failure mode is an extra human it might be a net win.
While may will buy a pregnancy to check for unwanted pregnancies, there's also many who use them to check for wanted pregnancies, so perhaps only to not wanting to be pregnant should use the electronic tests?
I feel like there's a better option, it has to be possible to improve the paper version, without adding a battery, LCD and a CPU.
Oh this is a good idea. Calibrate for the phone / camera version and test used and just let your phone read the test and run a little timer.
TestBuddy
Would be a good add in for ovulation tracking apps.
Also, if you are a pregnancy test manufacturer, maybe you release this app so you can see what other tests people use; educate them on the error rates of competitors; and offer 1 click purchase of your products.
I was going to comment “oh for f* sake not another app”, but that actually pretty clever. Just add a QR code to the test and the text: having trouble reading our test, download our app”.
Funny how the waves are always extra blurry when that happens.