7786655

    $ touch $'foo\'\n\'bar'
    $ ls --quoting-style=shell-escape-always | while read -r escaped; do
    >   eval "filename=$escaped"
    >   echo "[$filename]"
    > done
    [foo'
    'bar]

So don't use that app.

>Users may not be able to see a list of all in-app purchases (and their guaranteed prices) as they can on the App Store, without downloading the app.

If a store is missing a feature you want, you can simply choose not to use it.

>Sharing your payment details and other information with multiple entities, and having to continually trust each of them (e.g. to not abuse or leak).

This is a real problem, but solving it with an app store monopoly is a case of the cure being worse than the disease. Besides, I think the risks of sharing you credit card number are wildly overstated. You can issue a chargeback on any transaction, and reverse fraudulent purchases.

>Confused users may clog up Apple's customer support with complaints related to third-party payment systems.

Confused users already have enough complaints to clog up Apple's customer support with. Apple can just tell them to contact the third party's support.

>Angry users may demand Apple to offer refunds for shit that was paid for via third-party payment systems.

And Apple may tell them no. They're adults, the made a decision, now they have to live with the consequences.

>How will iOS sandboxing be enforced for apps delivered via third-party stores? Will those apps still have to be submitted to and signed by Apple?

That's not how sandboxing works.

>Store apps would need the privilege to write binaries on your iPhone. How will that privilege be regulated to prevent abuse? e.g. what happens if a store starts writing malware?

Malware is software that acts against the interests of the user. Nobody can know what the user wants except the user themself, so it must be the user's responsibility to install only the apps that they want on their device. This is already the current situation, since malware exists on the Apple App Store.

It's worth noting the although I'm technically on Epic's side here, I don't trust Epic and I would not install any of their software on one of my computers.

>Users may sometimes have to wait longer for an app to update on one store than on others (as already happens on Steam vs GoG).

Sometimes there are good reasons for this. For example, F-Droid users usually have to wait longer for updates than Google Play users, since F-Droid has a much more thorough review process. I think it's worth waiting longer so that I know the app hasn't introduces anti-features with its updates. Other people might disagree, and prefer getting updates as fast as possible. That's fine, Android allows multiple app stores so we can both get what we want.

I think this is also an interesting point: We've talked a lot about users who think the Apple App Store's rules are too strict but what about the users who think they aren't strict enough?

>Developers would no longer be assured that they will have access to literally all the users that iOS has, by publishing on just one store.

The Apple App Store will still be installed on every iOS device, unless you choose to remove it. No one is arguing otherwise.

>You would have to submit to each store, wait for approval on each of them, update for each of them... to come close to the userbase that you can currently access by just publishing once on the App Store.

Maybe so, but this is a relatively minor inconvenience, and apps are still free to choose to provide their app only on the Apple App Store, which every iPhone will have except where the user chose to remove it.

A great deal of evidence suggests otherwise.

My VPN subscription has saved me hundreds, if not thousands of dollars.

    #define ARRAY_SIZE(x) ((sizeof x) / sizeof *(x))

In theory it could push everything through a <canvas>, but that can be done in JS as well and doesn't seem to be that common.

2. Before calling your render function, it stores a reference to that object in a private, global variable. (Global in the sense that there's only one per JS VM) (Javascript is single-threaded so this is perfectly safe to do).

3. Each of the built-in hooks has access to that variable, and use it to increment a number representing the current hook index and then store information in an array at the current index.

4. The next time your component is rendered, that information is still there and the hooks can retrieve it.

5. Also some hooks like useEffect set up functions to be called by react later.

https://offensi.com/2020/08/18/how-to-contact-google-sre-dro...

>An attempt to modify the database name in the API call from ‘mysql’ into ‘--help’ results into something that surprised us...

    exec(["tar", "cz", ...user_wanted_files])

To do it correctly, you would have to do:

    exec(["tar", "cz", "--", ...user_wanted_files])

Yes, and that's also bad.