7 ms·

Although I appreciate Vivaldi for getting a iOS version out, do keep in mind that it's very inferior to Safari much like all non-Safari browsers on iOS running

Although I appreciate Vivaldi for getting a iOS version out, do keep in mind that it's very inferior to Safari much like all non-Safari browsers on iOS running WebKit because of how very privileged Safari is and sadly their hands are very tied. The only hope is that the EU's DMA and DSA can allow third-party browsing engines on iOS eventually, and this release is a head start type of move toward that goal I feel. Until that happens, Safari will always be the only browser that truly matters if you use a iOS device and that's a fact.

freediver 3y ago
Can you give an example of such privileges?
- leodriesch 3y ago
  Support for web extensions as an example (Safari extensions)
  - lhnz 3y ago
    Doesn't Kagi for iOS support web extensions already?
    - elashri 3y ago
      Not yet. The support is very limited.
- heavyset_go 3y ago
  Safari's rendering and JavaScript engines are the only ones allowed to run on, or be distributed to, iOS.
  - freediver 3y ago
    That is technically WebKit, which is open source.
    - heavyset_go 3y ago
      Try to bundle your own WebKit with an app and see what happens.
      - deleted 3y ago
        [deleted]
dkonofalski 3y ago
That's not a fact. All browsers on iOS use the same rendering engine. The differences between them are all in the UI and other front-end features. That doesn't make Safari superior to them, especially since they're all starting off with the same base rendering. Anything outside of that can easily be better than Safari.
- gameoverhumans 3y ago
  Rather than just downvote you for stating incorrect things with such conviction, I'll refer you to Apple's own website :) https://support.apple.com/en-eg/guide/security/sec15bfe098e/web https://support.apple.com/en-eg/guide/security/sec15bfe098e/... > Memory pages marked as both writable and executable can be used only by apps under tightly controlled conditions: The kernel checks for the presence of the Apple-only dynamic code-signing entitlement. Even then, only a single mmap call can be made to request an executable and writable page, which is given a randomized address. Safari uses this functionality for its JavaScript Just-in-Time (JIT) compiler. In other words, Apple only allows Apple to do Javascript JIT on iOS.
  - btown 3y ago
    While this is technically true, WKWebView (which I believe is used by all non-Apple browsers on iOS) does allow Javascript JIT, because the renderer runs in a subprocess with these permissions. See: https://news.ycombinator.com/item?id=19379739 https://news.ycombinator.com/item?id=19379739 . But there are many other reasons besides JIT to want to have non-Apple-Webkit-based rendering engines (including wanting different JS engines with their own JIT) - and so IMO it's very much a restriction that regulators should force Apple to relax. The security considerations should be no different than those on a desktop platform.
    - gameoverhumans 3y ago
      Interesting, thanks. Didn't realise there was ways to embed WebKit views that also got JIT (escaped the walled garden a while ago!) Still, my original point still stands. As you note, you can't have Spidermonkey running on iOS doing JIT. But you also couldn't have Gecko doing rendering and using WebKit JIT, either. ... Right? > The security considerations should be no different than those on a desktop platform. Completely agree. The "it's for your own security" angle is just usual Apple FUD to make their anti-competitive stance seem pro-consumer.
123sereusername 3y ago
[flagged]
btown 3y ago
FWIW as of a few months ago, Google and Mozilla were already prototyping porting their respective engines to iOS to prepare for this eventuality: https://9to5mac.com/2023/02/07/new-iphone-browsers/ https://9to5mac.com/2023/02/07/new-iphone-browsers/ https://9to5google.com/2023/02/06/google-chrome-blink-ios-webkit/ https://9to5google.com/2023/02/06/google-chrome-blink-ios-we... - and Vivaldi would benefit from this work getting to Chromium as well.
brucethemoose2 3y ago
> Although I appreciate Vivaldi for getting a iOS version out, do keep in mind that it's very inferior to Safari much like all non-Safari browsers on iOS running WebKit because of how very privileged Safari is and sadly their hands are very tied. The only hope is that the EU's DMA and DSA can allow third-party browsing engines on iOS eventually, and this release is a head start type of move toward that goal I feel. This is a double sided coin. 90% of the browsers on Google Play are absolute trash (if not, arguably, straight up malware), and some are apparently very popular. Give 3rd party iOS browsers more permissions, and devs will exploit every single bit of privilege to the max, and then some, en masse.
- kernal 3y ago
  [flagged]
  - brucethemoose2 3y ago
    90% may be hyperbole, and I cannot, because the web results are for some reason totally different that what I am being served in a search on my phone. But still: https://play.google.com/store/search?q=adblock%20browser&c=apps&hl=en_US&gl=US https://play.google.com/store/search?q=adblock%20browser&c=a... https://play.google.com/store/search?q=video%20download%20browser&c=apps&hl=en_US&gl=US https://play.google.com/store/search?q=video%20download%20br... Top results are OK, but it goes downhill pretty quickly.
    - kernal 3y ago
      [flagged]
  - menacingly 3y ago
    I dig the consistency of your "bizarrely hostile pro-google" vibe
    - kernal 3y ago
      It pales in comparison to your Apple worship
riscy 3y ago
I think it’s time to recognize that the web browser engine needs to be a trusted, hardened system-level component to protect user security: these engines deals directly with executing untrusted code being served from potential attackers.
- tayistay 3y ago
  Can that be done without disabling JIT for the rest of us? My app would benefit greatly from JIT compilation, and it's always been a bummer that it can't realize its full performance potential on iOS.
  - riscy 3y ago
    No. A JIT requires marking pages of runtime-generated data as executable. It’s an attacker’s dream: https://en.wikipedia.org/wiki/JIT_spraying https://en.wikipedia.org/wiki/JIT_spraying The entire compiler and language-runtime using a JIT becomes an attack surface. Securing Javascript is hard enough.
- arzig 3y ago
  Some interesting research I found through serenity os suggesting jit may not be worth it for most things. https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
deleted 3y ago
[deleted]

freediver 3y ago

Can you give an example of such privileges?

leodriesch 3y ago
Support for web extensions as an example (Safari extensions)
- lhnz 3y ago
  Doesn't Kagi for iOS support web extensions already?
  - elashri 3y ago
    Not yet. The support is very limited.
heavyset_go 3y ago
Safari's rendering and JavaScript engines are the only ones allowed to run on, or be distributed to, iOS.
- freediver 3y ago
  That is technically WebKit, which is open source.
  - heavyset_go 3y ago
    Try to bundle your own WebKit with an app and see what happens.
    - deleted 3y ago
      [deleted]

dkonofalski 3y ago

That's not a fact. All browsers on iOS use the same rendering engine. The differences between them are all in the UI and other front-end features. That doesn't make Safari superior to them, especially since they're all starting off with the same base rendering. Anything outside of that can easily be better than Safari.

gameoverhumans 3y ago
Rather than just downvote you for stating incorrect things with such conviction, I'll refer you to Apple's own website :) https://support.apple.com/en-eg/guide/security/sec15bfe098e/web https://support.apple.com/en-eg/guide/security/sec15bfe098e/... > Memory pages marked as both writable and executable can be used only by apps under tightly controlled conditions: The kernel checks for the presence of the Apple-only dynamic code-signing entitlement. Even then, only a single mmap call can be made to request an executable and writable page, which is given a randomized address. Safari uses this functionality for its JavaScript Just-in-Time (JIT) compiler. In other words, Apple only allows Apple to do Javascript JIT on iOS.
- btown 3y ago
  While this is technically true, WKWebView (which I believe is used by all non-Apple browsers on iOS) does allow Javascript JIT, because the renderer runs in a subprocess with these permissions. See: https://news.ycombinator.com/item?id=19379739 https://news.ycombinator.com/item?id=19379739 . But there are many other reasons besides JIT to want to have non-Apple-Webkit-based rendering engines (including wanting different JS engines with their own JIT) - and so IMO it's very much a restriction that regulators should force Apple to relax. The security considerations should be no different than those on a desktop platform.
  - gameoverhumans 3y ago
    Interesting, thanks. Didn't realise there was ways to embed WebKit views that also got JIT (escaped the walled garden a while ago!) Still, my original point still stands. As you note, you can't have Spidermonkey running on iOS doing JIT. But you also couldn't have Gecko doing rendering and using WebKit JIT, either. ... Right? > The security considerations should be no different than those on a desktop platform. Completely agree. The "it's for your own security" angle is just usual Apple FUD to make their anti-competitive stance seem pro-consumer.

123sereusername 3y ago

[flagged]

btown 3y ago

FWIW as of a few months ago, Google and Mozilla were already prototyping porting their respective engines to iOS to prepare for this eventuality: https://9to5mac.com/2023/02/07/new-iphone-browsers/ https://9to5mac.com/2023/02/07/new-iphone-browsers/ https://9to5google.com/2023/02/06/google-chrome-blink-ios-webkit/ https://9to5google.com/2023/02/06/google-chrome-blink-ios-we... - and Vivaldi would benefit from this work getting to Chromium as well.

brucethemoose2 3y ago

> Although I appreciate Vivaldi for getting a iOS version out, do keep in mind that it's very inferior to Safari much like all non-Safari browsers on iOS running WebKit because of how very privileged Safari is and sadly their hands are very tied. The only hope is that the EU's DMA and DSA can allow third-party browsing engines on iOS eventually, and this release is a head start type of move toward that goal I feel. This is a double sided coin. 90% of the browsers on Google Play are absolute trash (if not, arguably, straight up malware), and some are apparently very popular. Give 3rd party iOS browsers more permissions, and devs will exploit every single bit of privilege to the max, and then some, en masse.

kernal 3y ago
[flagged]
- brucethemoose2 3y ago
  90% may be hyperbole, and I cannot, because the web results are for some reason totally different that what I am being served in a search on my phone. But still: https://play.google.com/store/search?q=adblock%20browser&c=apps&hl=en_US&gl=US https://play.google.com/store/search?q=adblock%20browser&c=a... https://play.google.com/store/search?q=video%20download%20browser&c=apps&hl=en_US&gl=US https://play.google.com/store/search?q=video%20download%20br... Top results are OK, but it goes downhill pretty quickly.
  - kernal 3y ago
    [flagged]
- menacingly 3y ago
  I dig the consistency of your "bizarrely hostile pro-google" vibe
  - kernal 3y ago
    It pales in comparison to your Apple worship

riscy 3y ago

I think it’s time to recognize that the web browser engine needs to be a trusted, hardened system-level component to protect user security: these engines deals directly with executing untrusted code being served from potential attackers.

tayistay 3y ago
Can that be done without disabling JIT for the rest of us? My app would benefit greatly from JIT compilation, and it's always been a bummer that it can't realize its full performance potential on iOS.
- riscy 3y ago
  No. A JIT requires marking pages of runtime-generated data as executable. It’s an attacker’s dream: https://en.wikipedia.org/wiki/JIT_spraying https://en.wikipedia.org/wiki/JIT_spraying The entire compiler and language-runtime using a JIT becomes an attack surface. Securing Javascript is hard enough.
arzig 3y ago
Some interesting research I found through serenity os suggesting jit may not be worth it for most things. https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

deleted 3y ago

[deleted]