17 ms·

Technical question: What would a third party browser rendering engine allow, that using the safari renderer doesn't? I figure if you make a browser by just wrap

Technical question: What would a third party browser rendering engine allow, that using the safari renderer doesn't? I figure if you make a browser by just wrapping the safari renderer then you can make it do whatever you want it to. Why does the renderer make such that big of a difference?

creatonez 4y ago
Firefox addons on iOS, ported directly from the desktop versions with no modifications, will be possible. Gecko has a lot of under-the-hood knobs and dials that simply don't exist in Webkit, but are needed by the addon ecosystem.
- gnicholas 4y ago
  That would be great! Is it currently available on FF for Android?
  - Mogzol 4y ago
    Yes, you can run standard desktop Firefox extensions on FF for Android. There was a whitelist of extensions Mozilla allowed you to install though, I'm not sure if that still exists on the most recent versions.
    - toastal 4y ago
      The hoops are far too technical, finicky, and poorly documented for the average user to curate their own add-on list for Fx. It's a real shame since I think a lot of it is to make sure the add-on's UI is responsive, but many of most used add-ons on desktop have no UI to speak of (like redirecting AMP links, skipping short links, etc.).
  - gtk40 4y ago
    You can use uBlock Origin on Firefox for Android. The biggest feature I miss when I switched to iOS, although I've found Orion beta also has this feature and is decent.
- KMnO4 4y ago
  Have you seen Orion browser? Simply go to either the Chrome or FF addon store and install whichever extensions you want. (Some obviously work better than others)
kevingadd 4y ago
Actual extensions (like ublock!), bleeding edge/experimental web features like new webassembly or web APIs (firefox and chrome usually implement these before Safari does), stuff Apple has decided to sabotage because it threatens the app store (like fullscreen).
- scarface74 4y ago
  Safari has supported “actual extensions” for two yeass.
  - jwitthuhn 4y ago
    Yes but their API is very limited and by design doesn't allow a good ad blocker like ublock to be built.
    - scarface74 4y ago
      The actual “extension” framework does. It’s used by 1Blocker. Not just the “we send you a JSON set of rules”. But on the other hand, if you care about your privacy, why would you trust a third party to intercept all of your web traffic?
      - commoner 4y ago
        > But on the other hand, if you care about your privacy, why would you trust a third party to intercept all of your web traffic? uBlock Origin is free and open source, and its code is thoroughly reviewed by many contributors every release. I trust uBlock Origin over a filtering mechanism built into a closed source browser such as Safari.
        scarface74 4y ago
        WebKit is also open source and you can see exactly how it works. But did you personally download the open source version review the code and install it?
rektide 4y ago
Your scope is way way off. It's far from just the render engine that's being constrained. The whole virtual machine is restricted. The DOM, the js engine, the wasm engine, anything at all running or touching web code is locked the heck down. There's a couple places browsers can add or supplant web platform features, but it largely prevents browsers from doing much at all to add to the web platform in any way. In the rendering case, there's always work on css features & especially tuning that the browsers are up to. Just being faster, lighter weight, having more or better tuning is a great capability, a place where more than one small in-group should be able to experiment & improve & explore.
- madeofpalk 4y ago
  > It's far from just the render engine that's being constrained. It is unclear whether this would still even be the case. My understanding is that it's a _policy_ limitation preventing third party browsers on iOS. But there's also iOS security policies preventing JIT to have a fast browser. I cannot imagine Apple opening up JIT-capabilities to all developers on the app store. I wouldn't be surprised if they didn't relax this at all. Perhaps they will they grant entitlements for JIT to a select few.
  - eklitzke 4y ago
    I agree that whether or not they'll allow JIT is an orthogonal issue based on security policies, but I don't think it's out of the question. The security argument to not allow a JIT is that mapping code segments as executable+writeable opens up a lot of interesting attack vectors, and therefore allowing JIT weakens security. This is true of course, but the argument is a bit dubious for a few reasons. The first of which is that the OS is supposed to have sandboxing mechanisms that don't allow escape from the sandbox even if something goes wrong, and therefore prohibiting a JIT shouldn't be required in the first place. Furthermore WebKit itself has a JIT (whatever Apple calls their JS implementation), so iOS is already vulnerable to these kinds of issues in some sense. Finally, in general you can write and link in arbitrary code into your program (in read-only sections of memory), so attackers can already write exploits in C/C++/asm/whatever. Obviously Apple needs special consideration for WebKit itself since the WebKit rendering engine is linked into a ton of applications, so a security issue in WebKit is a major problem because it affects many programs on the phone, including a lot of first party applications. But this wouldn't be the case with a third-party iOS browser, since even if Apple allows you to install a third party browser, they're not going to allow you to replace the system webview implementation with a third party one. Therefore a bug or security problem in Firefox/Chrome/whatever should be limited to just that app, and wouldn't have the same scope as a WebKit vulnerability. Apple is notoriously restrictive so maybe they won't change their policies. On the other hand I think the current technical argument for not allowing third party programs to have JIT code is pretty weak, so I could definitely see a different decision being made at some point in time, especially if there was pressure from the legal team (e.g. due to things like EU anti-trust regulations).
nicoburns 4y ago
Some big ones: - Push notifications - Offline storage that doesn't disappear after 7 days. In other words it could actually make "PWAs" viable for a lot of use cases.
- scarface74 4y ago
  Every single time I’ve been asked to allow notifications on the web it’s been for spamming.
  - kelthuzad 4y ago
    Ok? that's why you have the option to disallow them!? I for one use web-apps that I need notifications from, it's a crucial feature which Apple has sabotaged on purpose for no other reason than self-interest. If you personally don't want to use a feature, that's fine, but you're putting out a statement like that as if no one should be allowed to use that feature because some devs tend to use it for spam. It just takes like 2 or 3 clicks to remove rights of notification from a specific app, so it's not a big deal either way.
  - nicoburns 4y ago
    It would be possible to only enable them for Web apps you’ve explicitly installed / added to your home screen
randyrand 4y ago
- Web Bluetooth. - Web USB - Web NFC - Web Notifications - Web Midi - Offline Storage - Gryo, Accelerometer, Magneto, Proximity - Vibration feedback
- swamp40 4y ago
  I seriously doubt Apple will ever allow web browsers direct control of their hardware.
  - smoldesu 4y ago
    What if it's my hardware?
    - encryptluks2 4y ago
      You don't own Apple products, they own you.
  - monocasa 4y ago
    A lot of that is already exposed to developers.
    - swamp40 4y ago
      Yes, but each app is approved by Apple before being put on the App store. Direct BLE and NFC control have lots of spoofing "dangers" and privacy issues.
  - randyrand 4y ago
    The web browser is just an app (possibly side loaded). Apps already have all of this.
- pertymcpert 4y ago
  Just write an app, Jesus.
  - 4y ago
choppaface 4y ago
Well there’s setting the default search engine. That’s not part of the rendering engine, but remember when IE6 was so much better than Netscape? Or vice-versa? If content is way better from one part of the internet, then users will select that corner for search too. WebGPU is key. Apple has been dragging their feet here while their AR / ML teams catch up to the rest of the industry. 8thwall (https://www.8thwall.com/projects https://www.8thwall.com/projects) has some pretty good demos of completely cross-platform AR/VR stuff. All this gets a ton better if iOS somehow supports WebGPU. And then there is user fingerprinting and ads stuff. A ton of fingerprints today are from CSS quirks and the like. Renderers can favor or disfavor these things.
shmerl 4y ago
Codecs and formats that Apple tries to ban, touch events API that Apple tries to ban, support for DASH that Apple tries to ban. And so on. Basically anything that Apple tries to ban for anti-competitive reasons. Once this blocker is removed, no one will care about Apple bans anymore.
- kouteiheika 4y ago
  > Codecs and formats that Apple tries to ban [..] Basically anything that Apple tries to ban for anti-competitive reasons. Opus support: Firefox: 2012 Chrome: 2014 Safari: Unsupported AVIF support: Firefox: Oct 2021 Chrome: Aug 2022 Safari: Oct 2022 (but incomplete and buggy) AV1 support: Firefox: 2019 Chrome: 2018 Safari: Unsupported WebP support: Firefox: 2019 Chrome: 2014 Safari: 2022 WebM support: Firefox: 2014 Chrome: 2013 Safari: 2022 Ogg Vorbis support: Firefox: 2009 Chrome: 2010 Safari: Unsupported FLAC support: Firefox: 2017 Chrome: 2017 Safari: 2019 Basically any codec/container that's open and/or royalty-free Apple isn't very keen to support, and if they do they always drag their feet.
  - thiht 4y ago
    Why do they drag their feet so much regarding open codecs? It seems like they just need to take an existing dependency and integrate it in their browser, that doesn't seem like a lot of work. Maybe I'm completely wrong about that? Are there hidden complexities? Maybe they want to implement the codecs in-house? Royalty/licensing issues?
    - dontlaugh 4y ago
      They want to only offer good options, to guarantee a certain UX. All of the codecs they do support have hardware acceleration and tend to be among the best in their class. Why would they duplicate functionality they already have? I agree it's annoying on occasion.
      - kouteiheika 4y ago

creatonez 4y ago

Firefox addons on iOS, ported directly from the desktop versions with no modifications, will be possible. Gecko has a lot of under-the-hood knobs and dials that simply don't exist in Webkit, but are needed by the addon ecosystem.

gnicholas 4y ago
That would be great! Is it currently available on FF for Android?
- Mogzol 4y ago
  Yes, you can run standard desktop Firefox extensions on FF for Android. There was a whitelist of extensions Mozilla allowed you to install though, I'm not sure if that still exists on the most recent versions.
  - toastal 4y ago
    The hoops are far too technical, finicky, and poorly documented for the average user to curate their own add-on list for Fx. It's a real shame since I think a lot of it is to make sure the add-on's UI is responsive, but many of most used add-ons on desktop have no UI to speak of (like redirecting AMP links, skipping short links, etc.).
- gtk40 4y ago
  You can use uBlock Origin on Firefox for Android. The biggest feature I miss when I switched to iOS, although I've found Orion beta also has this feature and is decent.
KMnO4 4y ago
Have you seen Orion browser? Simply go to either the Chrome or FF addon store and install whichever extensions you want. (Some obviously work better than others)

kevingadd 4y ago

Actual extensions (like ublock!), bleeding edge/experimental web features like new webassembly or web APIs (firefox and chrome usually implement these before Safari does), stuff Apple has decided to sabotage because it threatens the app store (like fullscreen).

scarface74 4y ago
Safari has supported “actual extensions” for two yeass.
- jwitthuhn 4y ago
  Yes but their API is very limited and by design doesn't allow a good ad blocker like ublock to be built.
  - scarface74 4y ago
    The actual “extension” framework does. It’s used by 1Blocker. Not just the “we send you a JSON set of rules”. But on the other hand, if you care about your privacy, why would you trust a third party to intercept all of your web traffic?
    - commoner 4y ago
      > But on the other hand, if you care about your privacy, why would you trust a third party to intercept all of your web traffic? uBlock Origin is free and open source, and its code is thoroughly reviewed by many contributors every release. I trust uBlock Origin over a filtering mechanism built into a closed source browser such as Safari.
      - scarface74 4y ago
        WebKit is also open source and you can see exactly how it works. But did you personally download the open source version review the code and install it?

rektide 4y ago

Your scope is way way off. It's far from just the render engine that's being constrained. The whole virtual machine is restricted. The DOM, the js engine, the wasm engine, anything at all running or touching web code is locked the heck down. There's a couple places browsers can add or supplant web platform features, but it largely prevents browsers from doing much at all to add to the web platform in any way. In the rendering case, there's always work on css features & especially tuning that the browsers are up to. Just being faster, lighter weight, having more or better tuning is a great capability, a place where more than one small in-group should be able to experiment & improve & explore.

madeofpalk 4y ago
> It's far from just the render engine that's being constrained. It is unclear whether this would still even be the case. My understanding is that it's a _policy_ limitation preventing third party browsers on iOS. But there's also iOS security policies preventing JIT to have a fast browser. I cannot imagine Apple opening up JIT-capabilities to all developers on the app store. I wouldn't be surprised if they didn't relax this at all. Perhaps they will they grant entitlements for JIT to a select few.
- eklitzke 4y ago
  I agree that whether or not they'll allow JIT is an orthogonal issue based on security policies, but I don't think it's out of the question. The security argument to not allow a JIT is that mapping code segments as executable+writeable opens up a lot of interesting attack vectors, and therefore allowing JIT weakens security. This is true of course, but the argument is a bit dubious for a few reasons. The first of which is that the OS is supposed to have sandboxing mechanisms that don't allow escape from the sandbox even if something goes wrong, and therefore prohibiting a JIT shouldn't be required in the first place. Furthermore WebKit itself has a JIT (whatever Apple calls their JS implementation), so iOS is already vulnerable to these kinds of issues in some sense. Finally, in general you can write and link in arbitrary code into your program (in read-only sections of memory), so attackers can already write exploits in C/C++/asm/whatever. Obviously Apple needs special consideration for WebKit itself since the WebKit rendering engine is linked into a ton of applications, so a security issue in WebKit is a major problem because it affects many programs on the phone, including a lot of first party applications. But this wouldn't be the case with a third-party iOS browser, since even if Apple allows you to install a third party browser, they're not going to allow you to replace the system webview implementation with a third party one. Therefore a bug or security problem in Firefox/Chrome/whatever should be limited to just that app, and wouldn't have the same scope as a WebKit vulnerability. Apple is notoriously restrictive so maybe they won't change their policies. On the other hand I think the current technical argument for not allowing third party programs to have JIT code is pretty weak, so I could definitely see a different decision being made at some point in time, especially if there was pressure from the legal team (e.g. due to things like EU anti-trust regulations).

nicoburns 4y ago

Some big ones: - Push notifications - Offline storage that doesn't disappear after 7 days. In other words it could actually make "PWAs" viable for a lot of use cases.

scarface74 4y ago
Every single time I’ve been asked to allow notifications on the web it’s been for spamming.
- kelthuzad 4y ago
  Ok? that's why you have the option to disallow them!? I for one use web-apps that I need notifications from, it's a crucial feature which Apple has sabotaged on purpose for no other reason than self-interest. If you personally don't want to use a feature, that's fine, but you're putting out a statement like that as if no one should be allowed to use that feature because some devs tend to use it for spam. It just takes like 2 or 3 clicks to remove rights of notification from a specific app, so it's not a big deal either way.
- nicoburns 4y ago
  It would be possible to only enable them for Web apps you’ve explicitly installed / added to your home screen

randyrand 4y ago

- Web Bluetooth. - Web USB - Web NFC - Web Notifications - Web Midi - Offline Storage - Gryo, Accelerometer, Magneto, Proximity - Vibration feedback

swamp40 4y ago
I seriously doubt Apple will ever allow web browsers direct control of their hardware.
- smoldesu 4y ago
  What if it's my hardware?
  - encryptluks2 4y ago
    You don't own Apple products, they own you.
- monocasa 4y ago
  A lot of that is already exposed to developers.
  - swamp40 4y ago
    Yes, but each app is approved by Apple before being put on the App store. Direct BLE and NFC control have lots of spoofing "dangers" and privacy issues.
- randyrand 4y ago
  The web browser is just an app (possibly side loaded). Apps already have all of this.
pertymcpert 4y ago
Just write an app, Jesus.
- 4y ago

choppaface 4y ago

Well there’s setting the default search engine. That’s not part of the rendering engine, but remember when IE6 was so much better than Netscape? Or vice-versa? If content is way better from one part of the internet, then users will select that corner for search too. WebGPU is key. Apple has been dragging their feet here while their AR / ML teams catch up to the rest of the industry. 8thwall (https://www.8thwall.com/projects https://www.8thwall.com/projects) has some pretty good demos of completely cross-platform AR/VR stuff. All this gets a ton better if iOS somehow supports WebGPU. And then there is user fingerprinting and ads stuff. A ton of fingerprints today are from CSS quirks and the like. Renderers can favor or disfavor these things.

shmerl 4y ago

Codecs and formats that Apple tries to ban, touch events API that Apple tries to ban, support for DASH that Apple tries to ban. And so on. Basically anything that Apple tries to ban for anti-competitive reasons. Once this blocker is removed, no one will care about Apple bans anymore.

kouteiheika 4y ago
> Codecs and formats that Apple tries to ban [..] Basically anything that Apple tries to ban for anti-competitive reasons. Opus support: Firefox: 2012 Chrome: 2014 Safari: Unsupported AVIF support: Firefox: Oct 2021 Chrome: Aug 2022 Safari: Oct 2022 (but incomplete and buggy) AV1 support: Firefox: 2019 Chrome: 2018 Safari: Unsupported WebP support: Firefox: 2019 Chrome: 2014 Safari: 2022 WebM support: Firefox: 2014 Chrome: 2013 Safari: 2022 Ogg Vorbis support: Firefox: 2009 Chrome: 2010 Safari: Unsupported FLAC support: Firefox: 2017 Chrome: 2017 Safari: 2019 Basically any codec/container that's open and/or royalty-free Apple isn't very keen to support, and if they do they always drag their feet.
- thiht 4y ago
  Why do they drag their feet so much regarding open codecs? It seems like they just need to take an existing dependency and integrate it in their browser, that doesn't seem like a lot of work. Maybe I'm completely wrong about that? Are there hidden complexities? Maybe they want to implement the codecs in-house? Royalty/licensing issues?
  - dontlaugh 4y ago
    They want to only offer good options, to guarantee a certain UX. All of the codecs they do support have hardware acceleration and tend to be among the best in their class. Why would they duplicate functionality they already have? I agree it's annoying on occasion.
    - kouteiheika 4y ago