5 ms·

You can run Chrome, which has a virtual machine in it. Maybe not the same kind of virtual machine that you're talking about, but this is the kind of virtual mac

You can run Chrome, which has a virtual machine in it. Maybe not the same kind of virtual machine that you're talking about, but this is the kind of virtual machine that Apple has banned: any kind of code that isn't statically compiled, that isn't immediately readable. This is why Chrome (actual, not the thin cosmetic shell over Safari WebView available now) can't run on iOS: Chrome has to download & run JS code, and that's impossible because it doesn't know ahead of time what code to run. Apple has society in the pinchers. Conversely, I have no respect at all for the m-f a-h at Google who have, in MV3, pulled an Apple and banned anything but statically compiled code in WebExtensions. Google is doing the worst thing Apple did, but to the web. And I absolutely hate it. Hate it hate it hate it hate it. Abominable way to hurt the web. https://github.com/w3c/webextensions/issues/139 https://github.com/w3c/webextensions/issues/139

TechBro8615 3y ago
While not directly applicable to this case, it's worth noting that you cannot run Chrome on iOS, explicitly because it's a VM (in the sense that it executes user-defined code). That's why iOS Chrome uses WebKit, and not V8, as its rendering and JS engine.
- corndoge 3y ago
  That is what the parent comment says
stuckkeys 3y ago
Can you tone it down a bit with the “has a virtual machine in it” part. The word you are looking for is “sandbox” virtualization.
- rektide 3y ago
  I'm not sure what logic or system you're applying, but it seems categorically wrong. Java is a VM. JS has a VM. .NET has a VM. These are all virtual machines. They're their own execution engines running compiled user code. I think your gatekeeping here is very technically incorrect. This isn't tone. This is what the industry actually has used for multiple decades now as terminology. Is the code being run natively compiled? No? Is it running in a machine which is virtual? It's a virtual machine. This has incredibly long precdence of terminology. It's been what Apple has gate-kept with for a long time now. I disagree with your tone policing, on a number of grounds.
- rezonant 3y ago
  Actually trying to distribute a web browser with its own JS engine that does _not_ sandbox JS code is also disallowed on iOS.
qball 3y ago
>pulled an Apple and banned anything but statically compiled code in WebExtensions Yes; the point of this move is specifically to render the vast majority of adblocking efforts non-viable.
- rektide 3y ago
  I'm not quite so pointed. I am quite willing to believe 98% of the really bad shit the Chrome Store extensions team has seen, the really henious anti-user malware shit, has been dynamically delivered payloads. I think there's real cases to be made. But I also don't think those security woes justify the horror Google is besetting upon users. I don't think it justifies stripping away agency in such broad course. I think it's hypocritical & shameful in extreme they'd do what the worst most fascist competitor does on their app store. I think the team isn't honest, hasn't presented viable evidence, hasn't made the case, hasn't presented real evidence for their actions in nudering web extensions. I have many many qualms. But I think I can still see legit cause for what would make them so very very cowardly, to do such a henious & unbespeakable act as they've doing with WebExtensions MV3. Alas it's just misaligned incentives here. Ideally users would actually see what pages & the extensions do. We could be our own network, our own reviwers, we could warn each other of malware. But Google, like all app-store providers, is the only intermediary of trust, has made themselves solely responsible. Rather than tackle this as a mature problem of great powers that must be watched and regulated, they've taken an extremely convenient & easy route out that makes their job as authoritarian regulators infinitely easier, at the expense of enormous power, at the expense of becoming extreme & perposterous hypocrites at the foot of the Apple tribulations they've undergone, but in a much worse manner.
varenc 3y ago
You're mixing up executing JavaScript generally vs JavaScript with a JIT. Apple has specifically banned Just-in-Time (JIT) compilation, where JavaScript (or anything) is translated into machine code, marked for execution, and ran directly on the processor. There are real security reasons for forbidding this[0]. All modern browsers use JIT compilation for JS since this is crucial for good performance. But a JIT isn't a requirement for running JS, it just makes things faster. You can run JavaScript without a JIT no problem, but there is a separate Apple ban on alternative browser engines. Ostensibly browsers are banned because without a JIT they'd very slow and lead to a bad user experience, though I'm doubtful this is the only reason. (You can try Safari with the JIT disabled by turning on Lockdown Mode) But there's nothing forbidden about interpreting code, as long as you don't generate machine code and try to mark pages of memory for execution. Practically this means scripting languages and nothing that's compiled or interpreted with a JIT. For example: with iSH, available on the app store, you can get a full virtual Linux environment and write all the JavaScript (via Node) or Python code you want: https://apps.apple.com/us/app/ish-shell/id1436902243 https://apps.apple.com/us/app/ish-shell/id1436902243 [0] I wrote another comment recently re: Apple/JIT and mention some of the security reasoning behind this, though I'm no expert: https://news.ycombinator.com/item?id=35695431 https://news.ycombinator.com/item?id=35695431
- saagarjha 3y ago
  There's not much of a security argument for forbidding a JIT.
  - varenc 3y ago
    Interesting! I had assumed that if you could mark pages of memory as executable (for a JIT), that an app could use that to call all sorts of security/privacy sensitive private APIs they're usually forbidden from using. But maybe not? Or is iOS sandboxing just good enough it doesn't matter? (but at the minimum, it does still seem to nullify the app store review process if apps can introduce arbitrary new behavior/code after review)
    - saagarjha 3y ago
saagarjha 3y ago
Web Extensions can run arbitrary JavaScript in the context of the web page they're injected into.

TechBro8615 3y ago

While not directly applicable to this case, it's worth noting that you cannot run Chrome on iOS, explicitly because it's a VM (in the sense that it executes user-defined code). That's why iOS Chrome uses WebKit, and not V8, as its rendering and JS engine.

corndoge 3y ago
That is what the parent comment says

stuckkeys 3y ago

Can you tone it down a bit with the “has a virtual machine in it” part. The word you are looking for is “sandbox” virtualization.

rektide 3y ago
I'm not sure what logic or system you're applying, but it seems categorically wrong. Java is a VM. JS has a VM. .NET has a VM. These are all virtual machines. They're their own execution engines running compiled user code. I think your gatekeeping here is very technically incorrect. This isn't tone. This is what the industry actually has used for multiple decades now as terminology. Is the code being run natively compiled? No? Is it running in a machine which is virtual? It's a virtual machine. This has incredibly long precdence of terminology. It's been what Apple has gate-kept with for a long time now. I disagree with your tone policing, on a number of grounds.
rezonant 3y ago
Actually trying to distribute a web browser with its own JS engine that does _not_ sandbox JS code is also disallowed on iOS.

qball 3y ago

>pulled an Apple and banned anything but statically compiled code in WebExtensions Yes; the point of this move is specifically to render the vast majority of adblocking efforts non-viable.

rektide 3y ago
I'm not quite so pointed. I am quite willing to believe 98% of the really bad shit the Chrome Store extensions team has seen, the really henious anti-user malware shit, has been dynamically delivered payloads. I think there's real cases to be made. But I also don't think those security woes justify the horror Google is besetting upon users. I don't think it justifies stripping away agency in such broad course. I think it's hypocritical & shameful in extreme they'd do what the worst most fascist competitor does on their app store. I think the team isn't honest, hasn't presented viable evidence, hasn't made the case, hasn't presented real evidence for their actions in nudering web extensions. I have many many qualms. But I think I can still see legit cause for what would make them so very very cowardly, to do such a henious & unbespeakable act as they've doing with WebExtensions MV3. Alas it's just misaligned incentives here. Ideally users would actually see what pages & the extensions do. We could be our own network, our own reviwers, we could warn each other of malware. But Google, like all app-store providers, is the only intermediary of trust, has made themselves solely responsible. Rather than tackle this as a mature problem of great powers that must be watched and regulated, they've taken an extremely convenient & easy route out that makes their job as authoritarian regulators infinitely easier, at the expense of enormous power, at the expense of becoming extreme & perposterous hypocrites at the foot of the Apple tribulations they've undergone, but in a much worse manner.

varenc 3y ago

You're mixing up executing JavaScript generally vs JavaScript with a JIT. Apple has specifically banned Just-in-Time (JIT) compilation, where JavaScript (or anything) is translated into machine code, marked for execution, and ran directly on the processor. There are real security reasons for forbidding this[0]. All modern browsers use JIT compilation for JS since this is crucial for good performance. But a JIT isn't a requirement for running JS, it just makes things faster. You can run JavaScript without a JIT no problem, but there is a separate Apple ban on alternative browser engines. Ostensibly browsers are banned because without a JIT they'd very slow and lead to a bad user experience, though I'm doubtful this is the only reason. (You can try Safari with the JIT disabled by turning on Lockdown Mode) But there's nothing forbidden about interpreting code, as long as you don't generate machine code and try to mark pages of memory for execution. Practically this means scripting languages and nothing that's compiled or interpreted with a JIT. For example: with iSH, available on the app store, you can get a full virtual Linux environment and write all the JavaScript (via Node) or Python code you want: https://apps.apple.com/us/app/ish-shell/id1436902243 https://apps.apple.com/us/app/ish-shell/id1436902243 [0] I wrote another comment recently re: Apple/JIT and mention some of the security reasoning behind this, though I'm no expert: https://news.ycombinator.com/item?id=35695431 https://news.ycombinator.com/item?id=35695431

saagarjha 3y ago
There's not much of a security argument for forbidding a JIT.
- varenc 3y ago
  Interesting! I had assumed that if you could mark pages of memory as executable (for a JIT), that an app could use that to call all sorts of security/privacy sensitive private APIs they're usually forbidden from using. But maybe not? Or is iOS sandboxing just good enough it doesn't matter? (but at the minimum, it does still seem to nullify the app store review process if apps can introduce arbitrary new behavior/code after review)
  - saagarjha 3y ago

saagarjha 3y ago

Web Extensions can run arbitrary JavaScript in the context of the web page they're injected into.