Live data from Hacker News

Apple blocks Google from running its internal iOS apps

theverge.com

361–370 of 667 posts

Re: Apple blocks Google from running its internal iOS apps

#361
post #337

Earlier quoted context omitted.

Further everyone's points about a form 1099 and how paying consumers doesn't make them a contractor, I also want to add that people as young as 13 were being targeted by these programs. Everyone under 18 is unable to sign a contract and therefore can't be a contractor, anyway.

Incorrect. People under 18 can enter into a contract with parental permission. Further, some stories have reported that Facebook says they acquired such parental permission for the minor participants.

Do you have a source for these stories you keep reporting happened? Because I haven't seen a single link supporting this narrative.

Additionally, the minimum age for non-agricultural workers is 14 anyway, so even then they're in the wrong and can't legally hire 13-year olds as contractors or employees. There's also several other rules in the FLSA pertaining to workers under 18 including minimum wage. I have a sneaky suspicion $20 per whatever period it is (unless said period is a few hours) is going to be under that wage.

Not to mention there's a whole lot more can of worms being opened specifically around minimum wage and recording hours that I highly doubt either Facebook or Google were actively managing.

Re: Apple blocks Google from running its internal iOS apps

#362
post #214

Earlier quoted context omitted.

Because lots of people still think that if you own a piece of hardware, you should be able to run whatever code you want on it.

Of course you should. It's my device, I should be able to do what I want with it. The default should be protected but root should be available.

And you can. You just can’t do what you want with your _customer’s_ device, according to Apple’s TOS.

Re: Apple blocks Google from running its internal iOS apps

#363
post #21

Earlier quoted context omitted.

I used to feel that way, and I used Android for years for that reason. But since switching to an iPhone, I've found that what I really want from my phone is not a totally open platform, but a tool that's simple, secure, and effective. Something I don't have to mess with, something I can trust to do its job and respect my privacy and be pleasant to interact with. They tried going that direction a bit with macOS when t…

> Workstations need to be totally user-controlled, but phones don't And why this extreme generalization, exactly? Don't you suppose you could have privacy, security, and perhaps even simplicity and ease-of-use with a totally free and open phone that grants control to the user? You really don't explain how "a totally open platform" is mutually exclusive, nor how your own personal needs require the inverse of freedom.…

The two forces are, generally, at odds. Apple screens apps for me to see if they're malicious or snoop my data. They ensure the things on the App Store are of a certain quality and safety. If they discover one that got through, I'm glad they can remove it from my device without waiting on my action. I've effectively outsourced my configuration and security to a company that has strong financial incentives to do a good job at those tasks - certainly a better job than I would do if I had to keep tabs on it all myself. They also do far less "abandoning of devices" than most of their competitors, for what it's worth.

While this kind of support doesn't technically preclude open-source code, it's hard to find both in one. Red Hat is one rare exception to this - providing a comprehensive, supported solution that also happens to be open-source. But the economics tend to push it to be one or the other. In this case, I'm perfectly fine making that trade.

Re: Apple blocks Google from running its internal iOS apps

#364
post #247

Earlier quoted context omitted.

But that "shall not" is prefixed by "Except as expressly set forth herein", and other sections clearly mark many "contractors" as "Permitted Users" who are expressly allowed to use such Apps/Passes.

Okay. Then cite one. The only provision I see that's close to what you're talking about is the definitions section, which provides that Permitted Users include "contractors . . . who have written and binding agreements with You . . . to protect Your Internal Use Application from unauthorized use " It's quite the stretch to say that this language, which by its text limits contractors to authorized uses, somehow expand…

The immediately preceding sentence reads:

"Internal Use Applications or Passes developed using the Apple Software may only be deployed to and used by Your Employees or Permitted Users for internal use purposes or for limited use by Customers on Deployment Devices on Your (or Your Permitted Entity’s) physical premises or in other locations when the use is under Your (or Your Permitted Entity’s) direct supervision and physical control as set forth in Section 2.1(f)."

Is it being used by "Permitted Users", which is elsewhere defined as including "contractors"? Yes.

Is it for "internal use purposes"? An internal customer research program, which is a cost-center and involves compensated research subjects, where the data is kept internal-confidential – and where perhaps even the research-subjects are under various kinds of NDA – is pretty "internal use" from my perspective. So, yes.

There's the "express authorization" that the following sentence doesn't revoke.

(Even the 2.1(f) allowance for customer use might be satisfied if the app has a central monitoring/disabling switch that counts as "direct supervision and physical control". But that's a little murkier, and the 2.1(f) allowance isn't strictly necessary for this use by compensated research subjects.)

Re: Apple blocks Google from running its internal iOS apps

#365

Let’s say you’re using a Google API like Maps, and you violate terms by snapshotting sections of their maps and storing them on your severs so you can serve static maps without making API calls. They’d shut down your API access immediately Google and Facebook both knew the terms. They both knew that the Enterprise Distribution Program was for internal use only. They still put ads out in the wild to recruit regular co…

I am a bit offended that google has a phone number and means of communications to resolve the issue with a real human at Apple. Nobody has that at google.

Re: Apple blocks Google from running its internal iOS apps

#366
post #339

Earlier quoted context omitted.

That's a misstatement of the principle here. I bought a thing. It's my thing, not someone else's thing. Things don't have "terms". I signed no contract. Let me use my thing. I mean, yes, we shouldn't buy iOS devices. But we should accept that things have ad hoc vendor-controlled "rules" just because someone baked them into the things, either. > what Apple allows you to run on your own device is actually a different s…

> Things don't have "terms". Technically correct. But software running on "things" has terms. It's called a license. When you buy a movie, you don't own the film. You own the right to use that film in accordance with the license.

You're conflating things. Your example is about copyright, not licenses. Copyright doesn't constrain use, it constrains distribution (though there's a parallel argument there about DRM and things like DVD region codes, etc...).

The question you're sidestepping is whether a license can say "you can't run your own software on your own thing". Obviously it can be implemented to do so given the way computers work, but it's not at all clear why that should be so.

Re: Apple blocks Google from running its internal iOS apps

#367

Earlier quoted context omitted.

I would bet good money that the large majority of iPhone users don't know that Apple has this much control (ie, that they can decide whether you're allowed to install custom apps provided by your employer).

I'm sure many iOS users are not aware that you can install apps outside of the App Store.

Yes. And for tech savvy people, such as Facebook developers, the fact that you need to install a special certificate before you can use internal company apps should give you a clue about what’s going on.

Re: Apple blocks Google from running its internal iOS apps

#368
post #159

There are over 100,000 Google and Facebook employees, just a small percentage of them with good old fashion loyalty to their companies could explain the amount offended here.

I haven't seen any people offended by it. I know some people are disappointed because of internal apps that are no longer accessible, e.g. dogfood builds, transportation app, apps to contact security, identification app, etc.

Re: Apple blocks Google from running its internal iOS apps

#369

Let’s say you’re using a Google API like Maps, and you violate terms by snapshotting sections of their maps and storing them on your severs so you can serve static maps without making API calls. They’d shut down your API access immediately Google and Facebook both knew the terms. They both knew that the Enterprise Distribution Program was for internal use only. They still put ads out in the wild to recruit regular co…

Good for the goose, good for the gander. AND, there's a huge difference from banning a small time developer that might tripped the wire accidentally, and banning Google and FB, full of lawyers. Frankly, FB and GOOG cannot do well at all in the privacy-caring ecosystem that Apple claims to want to build. Buh Buh Bye...

Re: Apple blocks Google from running its internal iOS apps

#370
post #95

Earlier quoted context omitted.

The parent is correct if you're not using the Developer Certificate, but relying on the Free Provisioning Profile - as the name implies, it is free, but it only lasts for 7 days instead of the 1 year you get with a paid developer account / Developer Certificate. The advantage of the Free Profile is that (afaik) it can't be revoked or censored. Disadvantage is 7 day lifespan.

Ahh, thanks, I forget the free version exists. That is a very annoying limitation of it.

Apple also weirdly limits the capabilities available to free developer accounts, like AutoFill and built-in IPSec/IKEv2 VPN support.

https://help.apple.com/developer-account/#/dev21218dfd6

Post reply on HN