11 ms·

Tauri – toolchain for building secure native apps that have tiny binaries

268 points by jaden 6y ago

rspoerri 6y ago
i'd like to look more into platform independant (desktop/mobile) development. are there other projects working on the same topic? what are the main advantages / disadvantages?
- zedr 6y ago
  Kivy: https://kivy.org https://kivy.org Write your app in pure Python. Deploy on desktops and mobile devices. The main disadvantage is that it does not use the native widget toolkit, although there are projects like KivyMD that attempt to replicate the native look and feel by theming the UI.
  - gridlockd 6y ago
    What is "the" native widget toolkit supposed to be? As far as I see it, it doesn't exist, on any platform. Every operating system has multiple drawing APIs and multiple frameworks that build on them. The HTML engines are just another framework.
- abeltensor 6y ago
  Flutter is one that is moving in that direction.
- qppo 6y ago
  There's no such thing as platform independent UI, at least on that break. You can do a "mobile first" UI that sucks on desktop or a "desktop first" UI that sucks on mobile, or you can just make the decision to only support one first - nail it - then support the other, with a completely different UI. Sharing code is the easy part. The input and output mechanisms and paradigms are completely different, and designs that work great in one context are difficult or impossible to use in another (eg, key bindings or gestures), and hard problems exist in one area that don't in another (mostly on desktop, windows are terrible).
Longhanks 6y ago
„Native“ - uhm no? It just wraps the platform‘s web engine (WebKit or Edge), it’s still resource wasting non native HTML/CSS/JS.
- timw4mail 6y ago
  At least compared to Electron it uses the most efficient browser engine per platform. Definitely not as good as full native, but a definite step up compared to Electron.
  - qppo 6y ago
    Most efficient in terms of what, disk space?
    - abeltensor 6y ago
      Disk space and Memory.
      - gcb0 6y ago
        because Google (and apple) is using the exact same tricky they sued Microsoft for in the 90s: including the browser with the OS.
    - timw4mail 6y ago
      Disk space, memory usage, and often battery life.
      - c-smile 6y ago
        For the browser neither disk space nor memory usage are in top 10 of list of priorities. On the first place in the list, by the way, is safe browsing experience. Rendering is only the second. And that one is the reason why browsers create separate processes for each window/tab. And that one is quite against low memory usage and longer battery life. Browser are designed for the case when user interacts with them "full screen" - as the main application on desktop and so design decision are focused on that. Browser can afford multithreading/multi-processes but far not all applications can afford loading all CPU and GPU cores for rendering "Hello world". That's why people who use VSCode prefer more lightweight solutions for "config file editing" scenarios.
bluehex 6y ago
There's a lot more info at https://tauri.studio https://tauri.studio.
carterklein13 6y ago
Maybe I'm missing something here - can somebody explain the relation to backend interoperability here? This seems, according to the docs, to be a way to make a native app "using virtually any frontend framework in existence." How much Rust knowledge is required? Is this saying that currently, you can build a native app using virtually any frontend framework in existence... as long as your backend is in Rust? Or am I totally whiffing on what's going on here. I don't have much native dev experience, so maybe my thinking is off.
- nim2020 6y ago
  Tauri builds the entire backend for you, all APIs are available out of the box without composing a single line of rust. If you do know rust, however, you can extend at your leisure. The team is currently working on a very slim solution that will build your entire project using a deno-based binary and if you stick to the APIs and can stomach the security risk of JS sidecars, you won't even need to have rust installed. That is probably a month or two away...
danpalmer 6y ago
We're moving in the direction of apps being a bit like games: a fast native core that's relatively generic and platform specific but available on major platforms, and "scripting" that's cross-platform and specific to the application and use-cases being solved. If we agree that this is a useful approach to take for developing cross-platform applications, and I think it is for most, are web technologies the best way to achieve this or is there a better alternative? Web tech has the advantage that when you don't have that "game engine" you can still run in a browser, but with these engines getting better, more storage, more use of app stores, and the fact that these apps are very much that, apps, and not publicly indexable web content, maybe this isn't a useful advantage anymore? Web tech also brings a number of disadvantages, such as a different security model and unnecessary legacy compatibility that holds back modernisation.
- ordinaryradical 6y ago
  Great observation and questions. What would you put in place of a WebView core? I know very little about this but I assumed one advantage to doing it this way would be that browsers have to access the same web and thus conform to some kind of web standards, making your cross-platform core achievable. What else could you reliably expect to be on a Windows/Linux/MacOS install with enough shared DNA or similar feature set to build your engine?
  - danpalmer 6y ago
    If we're building a new cross platform engine for these sorts of applications, then we get to define those standards. Electron essentially "bootstrapped" a standard environment from things people were already familiar with, but my point is that this may not necessarily be the best way forward in the long term because the requirements on the web don't match the requirements of desktop apps anymore. I think a new engine here would need to provide things like a UI model, filesystem access, OS interoperability (e.g. open/save dialogs, drag and drop), maybe sound/video, things like that. Web tech gives us these things, but they were all designed to run in browsers, not app-specific instances, so they have additional security/sandboxing requirements[1], they don't necessarily expose great multi-threading primitives because JS doesn't have any concept of these, and they do have a bunch of complexity around the notion that resources all used to be served up by a remote server, but are now embedded in your application. [1]: This means that Slack on a Mac is sandboxed at the macOS level and the Blink/Chromium level. There's no need for the latter, and it adds complexity and performance overhead.
0xcoffee 6y ago
What is the security model for hardening a local application? I see this in the docs >Hashing important messages with a OTP salt, you are able to encrypt messages between the user interface and the Rust backend. We are currently investigating the use of additional sources of entropy such as the amazing Infinite Noise TRNG. It reminds me of .net `SecureString`, which they then don't recommend using: https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md https://github.com/dotnet/platform-compat/blob/master/docs/D... because it doesn't really provide any extra security anyway..
- nim2020 6y ago
  A local tauri binary that is optimally secured: - all assets are baked into the binary, not an ASAR or some kind of sidecar - uses minimal javascript obfuscation - disables console availability in the webview - detects if it has been invoked from command line and exits - uses a minimal CSP to prevent the webview from reaching out to unknown resources - uses an API acceptlist, to treeshake out any unneeded functionality - injects the code directly into the webview from rust, circumventing the need for a localhost server - communicates with the event API, which uses randomized handles for all events to prevent static attacks from knowing in advance what a function call will be - never relies on external resources like remote servers / CDNs - removes all println! macros from consumer side rust - uses the forthcoming signed updater system - has been audited with frida-trace on delegate platforms - probably a couple more I am forgetting
  - 0xcoffee 6y ago
    It feels like there are good security measures mixed with 'bad' ones in here. It may be useful to focus more on the why, then the what. I see you are familiar with frida and know a thing about reverse engineering, so I assume you know that just like most local protectors, someone will just eventually write a wrapper that automatically bypasses all the 'security' measures. If we take electron as an example, why do I care that Tauri implements all these things, while electron doesn't. How does it make it more secure? Am I supposed to be worried someone is sitting in between my GUI and backend intercepting messages? Is this a common attack vector for electron? I'm really have a lot of questions why to put effort into developing all these things.
ausjke 6y ago
the core is https://github.com/webview/webview https://github.com/webview/webview with its rust binding, electron binds chromium and nodejs, I don't really know how webview works, a thin cross-platform API wrapper layer on top of native browser engine for each OS, so that you leverage the pre-installed browser in the OS and use it kind of like a shared library to minimize the app size? electron always bundles the whole chromium into its binary, what is exactly "webview" comparing to chromium inside electron app?
- ausjke 6y ago
  https://webkitgtk.org/ https://webkitgtk.org/ is what webview uses on Linux, this is gnome's own web engine and has nothing to do with chromium engine, so webview leverages similar web libraries to do the native GUI then.
  - monocasa 6y ago
    I wouldn't say it had nothing to do with chromium; chromium's blink engineer is a fork of webkit.
  - ComputerGuru 6y ago
    It's not gnome's own engine at all, it's the forked-a-long-time-ago from KDE's KHTML, adopted by Apple and significantly improved internally under the WebCore project/framework with changes shared from time to time with KDE devs before it was hard-forked as webkit and developed more in the open, then adopted by Chrome/Chromium (before Google hard-forked and renamed it to blink), with gnomifications for integrations and wrappers for the GTK userland.
- baxrob 6y ago
  I think this is the clearest explanation of the current webview implementation: https://github.com/webview/webview/issues/305 https://github.com/webview/webview/issues/305
- abeltensor 6y ago
  You are pretty much on the spot, its a library that directly interfaces with the existing browser engines on the user's computer.
mekkkkkk 6y ago
Oh fun! So now we can have browser inconsistencies for desktop apps as well? Jokes aside; looks interesting! Does it bundle plain text assets, or does it obfuscate/compile the dependencies?
K0nserv 6y ago
I am not a fan of the general trend in cross platform UI that can be described as "blank canvas" cross platform i.e. where cross platform UI is achieved by treating the app as a blank canvas ala web or OpenGL/Vulkan/Metal and drawing from scratch. I really like the approach that SwiftUI is taking for cross platform(Apple only I know) much more i.e. describe at a higher level what experience the user should have and SwiftUI takes care of rendering appropriate UI for the current device and interaction patterns. SwiftUI embedes a lot of knowledge about the HIG of all the platforms it supports and can thus render appropriate UI resulting in the best user experience on every platform. It's really impressive how well this works, you can use the same code from the smallest screen on Apple Watch to the largest on Apple TV. Of course "blank canvas" cross platform UI is much simpler for developers and designers like the explicit control so I fully expect it to win in the long term. But hopefully, at least on Apple's platform, the "high level intent" style of cross platform gains some ground.
- gridlockd 6y ago
  "High level intent" and "cross platform" just doesn't work out well. On Windows, the native widget toolkits are just awful: https://www.mono-project.com/archived/images/1/18/Build.png https://www.mono-project.com/archived/images/1/18/Build.png https://i.stack.imgur.com/MoMKp.jpg https://i.stack.imgur.com/MoMKp.jpg https://www.devexpress.com/products/net/controls/wpf/grid/media/carousel/wpf-grid-devav-hd.png https://www.devexpress.com/products/net/controls/wpf/grid/me... Microsoft doesn't even use them anymore in many of their apps, they often use "free form UI", they also seem to use HTML/Javascript a lot. It at least has the potential to look alright, it's not forced to look like garbage by the framework. I can see that Mac users prefer the native widgets, because Apple has put a little more thought into them, but also because they're more consistent. That doesn't mean going "native" is the right way for cross-platform development. Linux doesn't have a native toolkit either, it's either GNOME/GTK (looks alright) or KDE/Qt (looks alright sometimes, awful other times) or worse.
  - AnIdiotOnTheNet 6y ago
    > Microsoft doesn't even use them anymore in many of their apps, they often use "free form UI", they also seem to use HTML/Javascript a lot. Yeah, and I and many other users fucking hate it. It's awful to work with, it's inconsistent, it looks like shit... I don't think it was a decision based on better UX, but rather that it is easier and cheaper to hire kids with no experience with anything but webshit.
DominikD 6y ago
This may be a silly nitpick but it bugs me that "Setup for Windows" in the documentation marks node and rust/cargo as "This step is skippable if already satisfied" but VS Build tools as "This step is required". But I already have it installed, I'm not a web developer so I don't have node but I do write native code. Like... Why the silly distinction between dependencies and skippable dependencies? I know, it's a dumb thing to rant about but for some reason this web-centrism bugs me. :S
malkia 6y ago
Flutter has been trimming down, to ~15-20mb on my windows, but does not rely on any outside webtech. Another good example is Dear imgui, it's even smaller, and portable almost anywhere... And plenty of other examples...
- api 6y ago
  If imgui had accessibility integration it would be great.
  - p_l 6y ago
    I'm not sure it's doable to do non-retained accessible UI, as it would essentially require to build a retained mode representation for accessibility interfaces to walk through.
  - malkia 6y ago
    imgui has special applications, but it's becoming ready for more general use - especially in game tools where you want densely packed content over 3D render (or not even).
ydj 6y ago
How does this compare to neutralino (https://github.com/neutralinojs/neutralinojs https://github.com/neutralinojs/neutralinojs) At first glance it’s the same idea but with more APIs to native functionality.
- nim2020 6y ago
  The big two that I see are: - neutralino uses cpp, so there are likely to be many more memory safety issues here than with tauri (because rust). - tauri does not force you to ship a localhost server
- baxrob 6y ago
  I haven't tried tauri itself, but both it and neutralino use the underlying "webview" C library https://github.com/webview/webview/tree/0.1.1 https://github.com/webview/webview/tree/0.1.1
zemnmez 6y ago
since this is for security: I'm quite uncomfortable with the way APIs are exposed to the browser instance that does the UI rendering. As far as I can see from the code, extremely sensitive functions such as 'execute' are attached directly to the window [1][4], then they are invoked by postMessaging into the topmost window [2][3]. This makes XSS in essence immediate remote code execution, but more pointedly it voids some of the security guarantees about iframes, which can assumedly use window.top.postMessage() to post the 'execute' call directly to the browser. If you're developing, e.g. a chat app, you might use iframes to support, for example OEMBED -- and then even codepen oembeds may well be able to execute code. I like this direction for applications, but browser security protocols are a nightmare to replicate properly. I recommend using pre-existing interfaces for launching apps like custom scheme URIs, or if really necessary writing individual handlers for the heavy lifting. I think the postMessage approach is great, too but it's vital that the caller `origin` is checked. The web app shouldn't need to run arbitrary commands on the computer. [1]: https://github.com/tauri-apps/tauri/blob/2681ad361b4295756bef560b5d74ece2a757749f/cli/tauri.js/api-src/process.ts#L10 https://github.com/tauri-apps/tauri/blob/2681ad361b4295756be... [2]: https://github.com/tauri-apps/tauri/blob/015474657c955c7ad29463e9e88a26c34fa8e560/cli/tauri.js/templates/tauri.js#L16 https://github.com/tauri-apps/tauri/blob/015474657c955c7ad29... [3]: https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216f222772a8f989d2efd3e5/tauri/src/event.rs#L47 https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216... [4]: https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216f222772a8f989d2efd3e5/tauri/src/endpoints.rs#L160 https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216...
- zemnmez 6y ago
  The author(s) got in contact with me about this post: it does appear that the APIs are exposed at the window level, meaning any iframe can access these functions. It's important to note that CSP does not traverse iframes, or at least, has very strict rules about how it does due to an information leak in CSP1 [1]. This means embedded content is not going to be affected by any CSP rules. OEMBED content, or sandboxed rendered markdown is going to be served from the `null` origin, meaning that frame-src rules will have no granularity. [1]: http://archive.is/UXD8j http://archive.is/UXD8j
ori_b 6y ago
What kind of privilege separation does this implement, and how does it prevent confused deputy style problems?
fmakunbound 6y ago
I thought a native UI application was where you used the user interface components that came with the platform, not bundle a web application. Also, the only reason the Tauri project has to focus on security in the first place is because it relies on the overly complex HTML/JavaScript security model it chose to build upon in the first place.
jrochkind1 6y ago
So this is basically "Kind of like Electron, but with reasonable resource consumption and performance"? An Electron competitor?
- programmarchy 6y ago
  Yes, here's the magic sauce: https://github.com/Boscop/web-view https://github.com/Boscop/web-view It creates Rust bindings to WKWebView on macOS, Windows::Web::UI on Windows, and haven't looked at Linux yet.
  - baxrob 6y ago
    It looks like they've moved things around, but as I understand it the Rust bindings C/C++ code is derived from https://github.com/webview/webview/ https://github.com/webview/webview/ which uses WebKitGTK
    - programmarchy 6y ago
      Ah ok. I just followed the repository link from https://libraries.io/cargo/tauri-web-view https://libraries.io/cargo/tauri-web-view which I saw in the Cargo file. How did you find that?
      - baxrob 6y ago
        I've been following the webview project for a few months. It works for me to avoid Electron, and is pretty interesting on the whole I think
wackget 6y ago
Anyone got a "hello world" example of an app made with this which doesn't rely on other frameworks and uses only vanilla HTML/JS/CSS? All the examples on the site are built on top of vue.js.
yellowapple 6y ago
> Detail | Tauri | Electron > FLOSS | Yes | No Pardon? https://github.com/electron/electron/blob/master/LICENSE https://github.com/electron/electron/blob/master/LICENSE Looks awfully FLOSS to me.
- dljsjr 6y ago
  Seems somebody asked them about this already on their issue tracker: https://github.com/tauri-apps/tauri/issues/35 https://github.com/tauri-apps/tauri/issues/35 TL;DR: It's not about license but about being properly "free as in speech", and Electron includes non-free DRM implementations.

268 points by jaden 6y ago

i'd like to look more into platform independant (desktop/mobile) development. are there other projects working on the same topic? what are the main advantages / disadvantages?

zedr 6y ago
Kivy: https://kivy.org https://kivy.org Write your app in pure Python. Deploy on desktops and mobile devices. The main disadvantage is that it does not use the native widget toolkit, although there are projects like KivyMD that attempt to replicate the native look and feel by theming the UI.
- gridlockd 6y ago
  What is "the" native widget toolkit supposed to be? As far as I see it, it doesn't exist, on any platform. Every operating system has multiple drawing APIs and multiple frameworks that build on them. The HTML engines are just another framework.
abeltensor 6y ago
Flutter is one that is moving in that direction.
qppo 6y ago
There's no such thing as platform independent UI, at least on that break. You can do a "mobile first" UI that sucks on desktop or a "desktop first" UI that sucks on mobile, or you can just make the decision to only support one first - nail it - then support the other, with a completely different UI. Sharing code is the easy part. The input and output mechanisms and paradigms are completely different, and designs that work great in one context are difficult or impossible to use in another (eg, key bindings or gestures), and hard problems exist in one area that don't in another (mostly on desktop, windows are terrible).

Longhanks 6y ago

„Native“ - uhm no? It just wraps the platform‘s web engine (WebKit or Edge), it’s still resource wasting non native HTML/CSS/JS.

timw4mail 6y ago
At least compared to Electron it uses the most efficient browser engine per platform. Definitely not as good as full native, but a definite step up compared to Electron.
- qppo 6y ago
  Most efficient in terms of what, disk space?
  - abeltensor 6y ago
    Disk space and Memory.
    - gcb0 6y ago
      because Google (and apple) is using the exact same tricky they sued Microsoft for in the 90s: including the browser with the OS.
  - timw4mail 6y ago
    Disk space, memory usage, and often battery life.
    - c-smile 6y ago
      For the browser neither disk space nor memory usage are in top 10 of list of priorities. On the first place in the list, by the way, is safe browsing experience. Rendering is only the second. And that one is the reason why browsers create separate processes for each window/tab. And that one is quite against low memory usage and longer battery life. Browser are designed for the case when user interacts with them "full screen" - as the main application on desktop and so design decision are focused on that. Browser can afford multithreading/multi-processes but far not all applications can afford loading all CPU and GPU cores for rendering "Hello world". That's why people who use VSCode prefer more lightweight solutions for "config file editing" scenarios.

bluehex 6y ago

There's a lot more info at https://tauri.studio https://tauri.studio.

carterklein13 6y ago

Maybe I'm missing something here - can somebody explain the relation to backend interoperability here? This seems, according to the docs, to be a way to make a native app "using virtually any frontend framework in existence." How much Rust knowledge is required? Is this saying that currently, you can build a native app using virtually any frontend framework in existence... as long as your backend is in Rust? Or am I totally whiffing on what's going on here. I don't have much native dev experience, so maybe my thinking is off.

nim2020 6y ago
Tauri builds the entire backend for you, all APIs are available out of the box without composing a single line of rust. If you do know rust, however, you can extend at your leisure. The team is currently working on a very slim solution that will build your entire project using a deno-based binary and if you stick to the APIs and can stomach the security risk of JS sidecars, you won't even need to have rust installed. That is probably a month or two away...

danpalmer 6y ago

We're moving in the direction of apps being a bit like games: a fast native core that's relatively generic and platform specific but available on major platforms, and "scripting" that's cross-platform and specific to the application and use-cases being solved. If we agree that this is a useful approach to take for developing cross-platform applications, and I think it is for most, are web technologies the best way to achieve this or is there a better alternative? Web tech has the advantage that when you don't have that "game engine" you can still run in a browser, but with these engines getting better, more storage, more use of app stores, and the fact that these apps are very much that, apps, and not publicly indexable web content, maybe this isn't a useful advantage anymore? Web tech also brings a number of disadvantages, such as a different security model and unnecessary legacy compatibility that holds back modernisation.

ordinaryradical 6y ago
Great observation and questions. What would you put in place of a WebView core? I know very little about this but I assumed one advantage to doing it this way would be that browsers have to access the same web and thus conform to some kind of web standards, making your cross-platform core achievable. What else could you reliably expect to be on a Windows/Linux/MacOS install with enough shared DNA or similar feature set to build your engine?
- danpalmer 6y ago
  If we're building a new cross platform engine for these sorts of applications, then we get to define those standards. Electron essentially "bootstrapped" a standard environment from things people were already familiar with, but my point is that this may not necessarily be the best way forward in the long term because the requirements on the web don't match the requirements of desktop apps anymore. I think a new engine here would need to provide things like a UI model, filesystem access, OS interoperability (e.g. open/save dialogs, drag and drop), maybe sound/video, things like that. Web tech gives us these things, but they were all designed to run in browsers, not app-specific instances, so they have additional security/sandboxing requirements[1], they don't necessarily expose great multi-threading primitives because JS doesn't have any concept of these, and they do have a bunch of complexity around the notion that resources all used to be served up by a remote server, but are now embedded in your application. [1]: This means that Slack on a Mac is sandboxed at the macOS level and the Blink/Chromium level. There's no need for the latter, and it adds complexity and performance overhead.

0xcoffee 6y ago

What is the security model for hardening a local application? I see this in the docs >Hashing important messages with a OTP salt, you are able to encrypt messages between the user interface and the Rust backend. We are currently investigating the use of additional sources of entropy such as the amazing Infinite Noise TRNG. It reminds me of .net `SecureString`, which they then don't recommend using: https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md https://github.com/dotnet/platform-compat/blob/master/docs/D... because it doesn't really provide any extra security anyway..

nim2020 6y ago
A local tauri binary that is optimally secured: - all assets are baked into the binary, not an ASAR or some kind of sidecar - uses minimal javascript obfuscation - disables console availability in the webview - detects if it has been invoked from command line and exits - uses a minimal CSP to prevent the webview from reaching out to unknown resources - uses an API acceptlist, to treeshake out any unneeded functionality - injects the code directly into the webview from rust, circumventing the need for a localhost server - communicates with the event API, which uses randomized handles for all events to prevent static attacks from knowing in advance what a function call will be - never relies on external resources like remote servers / CDNs - removes all println! macros from consumer side rust - uses the forthcoming signed updater system - has been audited with frida-trace on delegate platforms - probably a couple more I am forgetting
- 0xcoffee 6y ago
  It feels like there are good security measures mixed with 'bad' ones in here. It may be useful to focus more on the why, then the what. I see you are familiar with frida and know a thing about reverse engineering, so I assume you know that just like most local protectors, someone will just eventually write a wrapper that automatically bypasses all the 'security' measures. If we take electron as an example, why do I care that Tauri implements all these things, while electron doesn't. How does it make it more secure? Am I supposed to be worried someone is sitting in between my GUI and backend intercepting messages? Is this a common attack vector for electron? I'm really have a lot of questions why to put effort into developing all these things.

ausjke 6y ago

the core is https://github.com/webview/webview https://github.com/webview/webview with its rust binding, electron binds chromium and nodejs, I don't really know how webview works, a thin cross-platform API wrapper layer on top of native browser engine for each OS, so that you leverage the pre-installed browser in the OS and use it kind of like a shared library to minimize the app size? electron always bundles the whole chromium into its binary, what is exactly "webview" comparing to chromium inside electron app?

ausjke 6y ago
https://webkitgtk.org/ https://webkitgtk.org/ is what webview uses on Linux, this is gnome's own web engine and has nothing to do with chromium engine, so webview leverages similar web libraries to do the native GUI then.
- monocasa 6y ago
  I wouldn't say it had nothing to do with chromium; chromium's blink engineer is a fork of webkit.
- ComputerGuru 6y ago
  It's not gnome's own engine at all, it's the forked-a-long-time-ago from KDE's KHTML, adopted by Apple and significantly improved internally under the WebCore project/framework with changes shared from time to time with KDE devs before it was hard-forked as webkit and developed more in the open, then adopted by Chrome/Chromium (before Google hard-forked and renamed it to blink), with gnomifications for integrations and wrappers for the GTK userland.
baxrob 6y ago
I think this is the clearest explanation of the current webview implementation: https://github.com/webview/webview/issues/305 https://github.com/webview/webview/issues/305
abeltensor 6y ago
You are pretty much on the spot, its a library that directly interfaces with the existing browser engines on the user's computer.

mekkkkkk 6y ago

Oh fun! So now we can have browser inconsistencies for desktop apps as well? Jokes aside; looks interesting! Does it bundle plain text assets, or does it obfuscate/compile the dependencies?

K0nserv 6y ago

I am not a fan of the general trend in cross platform UI that can be described as "blank canvas" cross platform i.e. where cross platform UI is achieved by treating the app as a blank canvas ala web or OpenGL/Vulkan/Metal and drawing from scratch. I really like the approach that SwiftUI is taking for cross platform(Apple only I know) much more i.e. describe at a higher level what experience the user should have and SwiftUI takes care of rendering appropriate UI for the current device and interaction patterns. SwiftUI embedes a lot of knowledge about the HIG of all the platforms it supports and can thus render appropriate UI resulting in the best user experience on every platform. It's really impressive how well this works, you can use the same code from the smallest screen on Apple Watch to the largest on Apple TV. Of course "blank canvas" cross platform UI is much simpler for developers and designers like the explicit control so I fully expect it to win in the long term. But hopefully, at least on Apple's platform, the "high level intent" style of cross platform gains some ground.

gridlockd 6y ago
"High level intent" and "cross platform" just doesn't work out well. On Windows, the native widget toolkits are just awful: https://www.mono-project.com/archived/images/1/18/Build.png https://www.mono-project.com/archived/images/1/18/Build.png https://i.stack.imgur.com/MoMKp.jpg https://i.stack.imgur.com/MoMKp.jpg https://www.devexpress.com/products/net/controls/wpf/grid/media/carousel/wpf-grid-devav-hd.png https://www.devexpress.com/products/net/controls/wpf/grid/me... Microsoft doesn't even use them anymore in many of their apps, they often use "free form UI", they also seem to use HTML/Javascript a lot. It at least has the potential to look alright, it's not forced to look like garbage by the framework. I can see that Mac users prefer the native widgets, because Apple has put a little more thought into them, but also because they're more consistent. That doesn't mean going "native" is the right way for cross-platform development. Linux doesn't have a native toolkit either, it's either GNOME/GTK (looks alright) or KDE/Qt (looks alright sometimes, awful other times) or worse.
- AnIdiotOnTheNet 6y ago
  > Microsoft doesn't even use them anymore in many of their apps, they often use "free form UI", they also seem to use HTML/Javascript a lot. Yeah, and I and many other users fucking hate it. It's awful to work with, it's inconsistent, it looks like shit... I don't think it was a decision based on better UX, but rather that it is easier and cheaper to hire kids with no experience with anything but webshit.

DominikD 6y ago

This may be a silly nitpick but it bugs me that "Setup for Windows" in the documentation marks node and rust/cargo as "This step is skippable if already satisfied" but VS Build tools as "This step is required". But I already have it installed, I'm not a web developer so I don't have node but I do write native code. Like... Why the silly distinction between dependencies and skippable dependencies? I know, it's a dumb thing to rant about but for some reason this web-centrism bugs me. :S

malkia 6y ago

Flutter has been trimming down, to ~15-20mb on my windows, but does not rely on any outside webtech. Another good example is Dear imgui, it's even smaller, and portable almost anywhere... And plenty of other examples...

api 6y ago
If imgui had accessibility integration it would be great.
- p_l 6y ago
  I'm not sure it's doable to do non-retained accessible UI, as it would essentially require to build a retained mode representation for accessibility interfaces to walk through.
- malkia 6y ago
  imgui has special applications, but it's becoming ready for more general use - especially in game tools where you want densely packed content over 3D render (or not even).

ydj 6y ago

How does this compare to neutralino (https://github.com/neutralinojs/neutralinojs https://github.com/neutralinojs/neutralinojs) At first glance it’s the same idea but with more APIs to native functionality.

nim2020 6y ago
The big two that I see are: - neutralino uses cpp, so there are likely to be many more memory safety issues here than with tauri (because rust). - tauri does not force you to ship a localhost server
baxrob 6y ago
I haven't tried tauri itself, but both it and neutralino use the underlying "webview" C library https://github.com/webview/webview/tree/0.1.1 https://github.com/webview/webview/tree/0.1.1

zemnmez 6y ago

since this is for security: I'm quite uncomfortable with the way APIs are exposed to the browser instance that does the UI rendering. As far as I can see from the code, extremely sensitive functions such as 'execute' are attached directly to the window [1][4], then they are invoked by postMessaging into the topmost window [2][3]. This makes XSS in essence immediate remote code execution, but more pointedly it voids some of the security guarantees about iframes, which can assumedly use window.top.postMessage() to post the 'execute' call directly to the browser. If you're developing, e.g. a chat app, you might use iframes to support, for example OEMBED -- and then even codepen oembeds may well be able to execute code. I like this direction for applications, but browser security protocols are a nightmare to replicate properly. I recommend using pre-existing interfaces for launching apps like custom scheme URIs, or if really necessary writing individual handlers for the heavy lifting. I think the postMessage approach is great, too but it's vital that the caller `origin` is checked. The web app shouldn't need to run arbitrary commands on the computer. [1]: https://github.com/tauri-apps/tauri/blob/2681ad361b4295756bef560b5d74ece2a757749f/cli/tauri.js/api-src/process.ts#L10 https://github.com/tauri-apps/tauri/blob/2681ad361b4295756be... [2]: https://github.com/tauri-apps/tauri/blob/015474657c955c7ad29463e9e88a26c34fa8e560/cli/tauri.js/templates/tauri.js#L16 https://github.com/tauri-apps/tauri/blob/015474657c955c7ad29... [3]: https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216f222772a8f989d2efd3e5/tauri/src/event.rs#L47 https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216... [4]: https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216f222772a8f989d2efd3e5/tauri/src/endpoints.rs#L160 https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216...

zemnmez 6y ago
The author(s) got in contact with me about this post: it does appear that the APIs are exposed at the window level, meaning any iframe can access these functions. It's important to note that CSP does not traverse iframes, or at least, has very strict rules about how it does due to an information leak in CSP1 [1]. This means embedded content is not going to be affected by any CSP rules. OEMBED content, or sandboxed rendered markdown is going to be served from the `null` origin, meaning that frame-src rules will have no granularity. [1]: http://archive.is/UXD8j http://archive.is/UXD8j

ori_b 6y ago

What kind of privilege separation does this implement, and how does it prevent confused deputy style problems?

fmakunbound 6y ago

I thought a native UI application was where you used the user interface components that came with the platform, not bundle a web application. Also, the only reason the Tauri project has to focus on security in the first place is because it relies on the overly complex HTML/JavaScript security model it chose to build upon in the first place.

jrochkind1 6y ago

So this is basically "Kind of like Electron, but with reasonable resource consumption and performance"? An Electron competitor?

programmarchy 6y ago
Yes, here's the magic sauce: https://github.com/Boscop/web-view https://github.com/Boscop/web-view It creates Rust bindings to WKWebView on macOS, Windows::Web::UI on Windows, and haven't looked at Linux yet.
- baxrob 6y ago
  It looks like they've moved things around, but as I understand it the Rust bindings C/C++ code is derived from https://github.com/webview/webview/ https://github.com/webview/webview/ which uses WebKitGTK
  - programmarchy 6y ago
    Ah ok. I just followed the repository link from https://libraries.io/cargo/tauri-web-view https://libraries.io/cargo/tauri-web-view which I saw in the Cargo file. How did you find that?
    - baxrob 6y ago
      I've been following the webview project for a few months. It works for me to avoid Electron, and is pretty interesting on the whole I think

wackget 6y ago

Anyone got a "hello world" example of an app made with this which doesn't rely on other frameworks and uses only vanilla HTML/JS/CSS? All the examples on the site are built on top of vue.js.

yellowapple 6y ago

> Detail | Tauri | Electron > FLOSS | Yes | No Pardon? https://github.com/electron/electron/blob/master/LICENSE https://github.com/electron/electron/blob/master/LICENSE Looks awfully FLOSS to me.

dljsjr 6y ago
Seems somebody asked them about this already on their issue tracker: https://github.com/tauri-apps/tauri/issues/35 https://github.com/tauri-apps/tauri/issues/35 TL;DR: It's not about license but about being properly "free as in speech", and Electron includes non-free DRM implementations.