341–350 of 498 posts
Earlier quoted context omitted.
Except, apparently, Chrome https://blog.chromium.org/2016/01/a-faster-more-stable-chrom...
Chrome uses WKWebView on iOS, so it's basically safari with a different UI (so does firefox on iOS)
I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…
I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…
"We are in full compliance. Everything is fine. The house is not on fire. The heat you are feeling is coincidential." Man, do I dislike marketing speak. A "We knew we were non-compliant, but think the security benefits of quick bugfixes outweigh the disadvantages. We will work with apple to return to compliance." would've been honest, better and not bs.
Did you see the article on HN last weekend about Wifi routers? "I have a 1.3gbps wireless ac router...but only at the PHY layer, but only in an RF test lab, but only if the client is MU-MIMO enabled, but only if they talk on all 4 channels, but only if the signal connects at 100%, but only if your data is 10:1 compressible, but only if you have one client, " even after like 5 "but only if"'s , there was still this unexplained 20% discrepancy between the advertised "speed" and what the device was physically capable of. I'd love to hear their lawyer explain how thats not false advertising.
Earlier quoted context omitted.
No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their device. Apple signs apps for a reason -- now we have to trust you to deliver that code safely to the user without being manipulated in transit. I also have to trust that you will respect my privacy. And I don't. It also seems clearly against their EULA, so yo…
now we have to trust you to deliver that code safely to the user without being manipulated in transit. You have to trust app developers anyway, since they run native code on your machine. While there are security concerns, these are not the real motivation. Apple is gradually closing down their platform, as many people have predicted in the past. You can also see that in various subtle changes to Gatekeeper and the S…
Time will tell. I think it will really come down to the severity of malware problems of the future.
But I really think we'll just move 100% into bifurcated systems (we're already there with Intel's ME to a large extent) where the place that arbitrary code can run is completely segmented off from trusted code.
Earlier quoted context omitted.
Judging by how sluggish and annoying the HSBC app is, I think it is a web app framed in a thin launcher from the app store. I.e. it downloads a bunch of javascript/html/css and that executes within a UIWebView/WKWebView. Using caching and localStorage, you can construct such an app to not need to download everything on each launch. The reason that's allowed is because everything executes within a sandboxed browser en…
> The reason that's allowed is because everything executes within a sandboxed browser environment. No native code is downloaded. That's the same thing Rollout does. In fact, iOS apps can't download and run native code. The OS won't let you mark pages as executable unless they're appropriately signed, and only Apple has those keys.
Earlier quoted context omitted.
No, what you end up doing is effectively destroying the security protections Apple puts in place to protect the user from unknown/bad code from running on their device. Apple signs apps for a reason -- now we have to trust you to deliver that code safely to the user without being manipulated in transit. I also have to trust that you will respect my privacy. And I don't. It also seems clearly against their EULA, so yo…
> And ultimately it's their store and their rules. It wouldn't be as bad if their store weren't also the only store available for the platform. Because of this forced monoculture, the criticisms are well within scope.
Earlier quoted context omitted.
> The reason that's allowed is because everything executes within a sandboxed browser environment. No native code is downloaded. That's the same thing Rollout does. In fact, iOS apps can't download and run native code. The OS won't let you mark pages as executable unless they're appropriately signed, and only Apple has those keys.
If they're using JSC, then they can definitely download JS and execute native methods. They could subclass any UIKit object and make it conform to JSExport. Done, now they're "running native code."
Earlier quoted context omitted.
This is obviously getting off topic, but in a common law system that interpretation is just wrong. The law is an evolving thing, it is meant to be interpreted, read, and understood, not to be exploited.
Then the letter of the law means nothing.
Earlier quoted context omitted.
The problem with Apple that you and your customers need to be aware of (or concerned about), is that once a number of your customers sidestep Apple policies w.r.t. pushing or changing features via JavaScript, Apple will change their policies to close that loophole. It's only a matter of time before companies take advantage of this path to sidestep app store approvals.
As a client I'm pretty baffled that some developer had specifically bypassed something that I see as a security measure. If an app is modified on the fly to use an undocumented and maybe "forbidden by apple" method in order to bypass security features or worse spy on me I'm clearly not ok. Do you really think the apple ecosystem work because clients see AppStore as a evil cage and that the external developers are all…
By not allowing developers to patch their app 'on the fly', directly, without going through a new version in the app store (which is a very lengthy process, almost forever in security terms), Apple effectively protects their iOS users from malicious code (not from the dev, which is probably to be trusted if the app is already installed, but from MITM attacks and the likes). However at the same time they deny very hasty security patches, which may compromise the device and all associated data and accounts entirely.
So there's no best world but undoubtingly many aspects to consider. Anecdotally I find that it's often better to trust the developers of an app to maintain their own thing; the OS only being a facilitator, provided the user has control (UAC on Windows, Permissions on mobile, etc.) [note: obviously you trust the OS vendor to patch said OS, it's just a particular kind of app]
edit: wording
Earlier quoted context omitted.
> We are contacting Apple in order to get further clarification on why Rollout doesn't fall under the clause that lets developers push JS to live apps as long as it does not modify the original features and functionality of the app. As a security-conscious user, live patching is awful. Nothing guarantees me that the benign app I've been granting various permissions to doesn't get altered by a fourth party adversary t…
Nothing guarantees that. There have been RCE exploits on iOS. One could argue that live patching allowed companies to fix or mitigate security problems faster than Apples (awful) app store policy (and timescale) would otherwise allow.
Your argument does sound good, but it's a double-edged sword.