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

by jaden • 6 years ago

268 116 6 years ago

rspoerri• 6 years 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• 6 years ago

Kivy: 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.

gridlockd10• 6 years 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.

abeltensor3• 6 years ago

Flutter is one that is moving in that direction.

qppo2• 6 years 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• 6 years 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.

timw4mail3• 6 years 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.

qppo2• 6 years ago

Most efficient in terms of what, disk space?

gridlockd10• 6 years ago

What exactly makes a GUI "native", in your view? WebKit and MSHTML/Edge, they all render to the screen with native APIs. They're part of the operating system. Lots of native applications have used these for decades.

distances• 6 years ago

For me "native" on desktop still means compiled to target architecture without any runtime VM/interpretation.

I agree this is getting more muddy on mobile as, say, "native Android" almost always now means bytecode using the platform SDKs.

_pdp_3• 6 years ago

Please don't take it the wrong way but using the same logic gaming engine are not native either because they have a scripting component to draw all the widgets on the screen.

I get exactly what you mean though but I find this logic difficult to understand. ;)

K0nserv3• 6 years ago

Yes but the counter argument here is that games are all extremely custom anyway and it makes sense for them to render their UI completely from scratch in a blank canvas.

For typical applications the blank canvas/from scratch approach does not result in the best outcome. Each platform has HIGs, native UI toolkits etc and those are what should be used, I assume that's what the parent is getting at.

cocktailpeanuts3• 6 years ago

By your logic, all apps that run on a computer are "native apps", because they are somehow using the native features of the computer to render the webview.

When you say "native" apps in this context, it 100% refers to non-webview based apps.

monocasa3• 6 years ago

Yes. Game engines structured like that don't have native UIs.

nim20206• 6 years ago

I find it interesting that many people hold so tightly onto the "it is not native unless it is written entirely in %my_favorite_language%". I think a little controversy is good, but what the heck does native mean anymore? Wasn't it really invented as a kind of "shaming" because front-end developers were never considered "real programmers" and when hybrid apps came out some folks felt the need to line their pockets with this differentiation?

Don't get me wrong, I am very well acquainted with the tragedies of JS - and the propensity of amateurs to just "do it all" in a single-threaded webrenderer. In fact, I think that this is why most of the first and second generation "web-apps" built on cordova and electron were such poor performers.

But nevertheless, what we are trying to do with Tauri is to open up the boundaries between development communities and leverage the particular strengths of each of them. So if you don't feel Tauri is "native" enough, then maybe you are missing the point.

monocasa3• 6 years ago

In this context, it means that it uses the UI toolkit provided by the OS/display env to do it's UI rather than opening a custom rendered surface and doing it all manually in your app (as a browser engine does). That includes using the browser engine on the system.

There's a weird impedance mismatch in the UIs of any non native apps that comes simply from recreating the UI elements and not using the system provided ones. This isn't an aspect of trying to 'feel superior' to JS devs, but a reflection of the real trade-offs of the technique. And I say this as the lead from a traditionally systems oriented team that's about to ship our first electron app. We took a look at the costs, and decided that in this particular case the tradeoffs were worth it, but it's not an easy decision.

And one thing I'll say is that a piece of what makes electron attractive at the organizational level is the fact that it doesn't use the system libraries. That greatly reduces QA burden by not having a spread of different versions of underlying infra to deal with. As an enduser I'd love if all the chrome/blink based apps on my machine (let's see, chrome, spotify, vscode, slack are all running) shared resources, but if they had to test against different versions of runtime or each version of their code they released, they probably wouldn't be using this model in the first place.

bmn__• 6 years ago

It's not native because it does not even make the slightest attempt to adapt to the DE! What a waste of potential. I invite the HN readers to compare:

https://i.imgur.com/GVlm9c2.png

Font size is wrong. Colours are wrong and 250% too many. Hover/active state is wrong. Hyperlinks are unmarked. Context menu in editing widgets missing. Menu bar and status bar missing. Accelerator keys missing.

bluehex• 6 years ago

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

carterklein13• 6 years 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.

nim20206• 6 years 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...

danpalmer7• 6 years 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• 6 years 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?

danpalmer7• 6 years 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.

danpalmer7• 6 years ago

I suspect React Native is probably the closest thing we have to this at the moment.

k__• 6 years ago

This.

If the web on iOS wasn't such a garbage fire, we could use React directly

ci5er• 6 years ago

Flutter?

quotemstr• 6 years ago

So, like Emacs has been for decades? :-)

danpalmer7• 6 years ago

Yep, I think that's another pretty good example!

sm4sh• 6 years ago

The thing is most companies would want to have a web presence anyway. It's just easiest exposure and people have to be willing to install a software - visiting a website not so much. So if you're building these cross-platform apps on anything other than the Web stack people will still have to have different code bases for native and web which kinda defeats their purpose.

So I don't think you have any real alternatives until there's other technologies on the web or wasm can do everything.

danpalmer7• 6 years ago

As I kind of alluded to in my comment, I'm not sure many of these things need to be web apps. OS level sandboxing has come a long way in the last ~10 years, and need fewer of the benefits of the web (like publicly addressable resources), and more of the benefits of desktop apps (like filesystem access). Web tech is improving its support for the latter, but I think we could do better if we designed a system today, rather than using one mostly designed between 95-05.

LeifCarrotson• 6 years ago

Web tech also means that the Tauri devs can stand on the shoulders of giants. Billions of dollars and billions of man-hours have gone into the development of web tech.

It's not perfectly aligned with the use case, and those billions have not been efficiently spent due to competing interests and design-by-comittee, but you're going to have a really hard time matching that investment.

hinkley• 6 years ago

I hope we learn the lesson of Blizzard but it doesn't seem we really are.

For the scripted part of the application, you can allow 3rd party plugins. If you do, you should keep tabs on the success of different solutions in this Marketplace of Ideas. You should absorb (probably native code) the ideas with the broadest appeal. But don't forget to find a way to compensate the person whose plugin you just deprecated.

Anything you don't know will stick, should be done on the cheap, and in a problem space where porting is expensive, scripting seems to be the winning strategy. And some commentary from various game authors suggests to me that the scripting language also opens up some development parallelism that is harder to get with an API.

We get the majority of the features of jQuery in HTML 5, and I bristle a bit when people try to act like jQuery is dumb. jQuery won. We are here now because of jQuery. It is useful even if you never use it, maybe especially so.

proc0• 6 years ago

Games are simulations, arguably the hardest paradigm of software. Games have always included user interfaces, and in many cases they are just user interfaces. Web apps for the most part are also just user interfaces. React has basically adopted the equivalent of a game loop architecture. I guess the only thing holding back web apps becoming basically game engines are search engines like Google indexing different parts of it. In other words, search engines are better adapted to index and make sense of files on a computer, rather than a runtime simulation of some kind.

t0astbread• 6 years ago

Maybe a bit off-topic for this comment but I really like (most of) the web's security model and I wish I had the same on my desktop. Specifically I'd like a strong per-program permission model, ideally in some sort of pluggable fashion (like, have a configurable chain of programs determine other programs' permissions, à la middleware).

You could take this to the extreme and have every program run in a "pure" fashion per default (i.e. no inputs other than command line args - no outputs other than the exit status).

baxrob5• 6 years ago

0xcoffee2• 6 years 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/D... because it doesn't really provide any extra security anyway..

nim20206• 6 years 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

0xcoffee2• 6 years 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.

archgoon• 6 years ago

They discuss some features that they are adding

https://tauri.studio/docs/about/security

Unfortunately, they don't explicitly say what their threat model is, but you may be able to infer it from their feature list.

I am surprised they list "Decompilation is Difficult" as a feature. I'd be hesitant to rely on this for long.

c-smile4• 6 years ago

Hard to speak about security when <input type="password"> is handled in a 3-rd party process with unknown telemetry settings.

ausjke2• 6 years ago

the core is 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?

ausjke2• 6 years ago

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.

monocasa3• 6 years ago

I wouldn't say it had nothing to do with chromium; chromium's blink engineer is a fork of webkit.

ComputerGuru2• 6 years 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.

baxrob5• 6 years ago

I think this is the clearest explanation of the current webview implementation: https://github.com/webview/webview/issues/305

abeltensor3• 6 years 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• 6 years 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?

K0nserv3• 6 years 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.

gridlockd10• 6 years 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://i.stack.imgur.com/MoMKp.jpg

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.

AnIdiotOnTheNet4• 6 years 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.

akx• 6 years ago

Wait, so can you explain what exactly was awful about those screenshots? I'm genuinely interested since I don't see anything horribly wrong with them (aside from some dated gradients).

p_l3• 6 years ago

All the screenshots you linked look, and most importantly, work, better than pretty much every "blank canvas" application I have encountered, though I'll admit the last one is worst implemented. Worst, yet still beats the pants off Electron and the like.

DominikD• 6 years 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

malkia2• 6 years 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...

api3• 6 years ago

If imgui had accessibility integration it would be great.

p_l3• 6 years 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.

malkia2• 6 years 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• 6 years ago

How does this compare to neutralino (https://github.com/neutralinojs/neutralinojs)

At first glance it’s the same idea but with more APIs to native functionality.

nim20206• 6 years 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

baxrob5• 6 years 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

zemnmez3• 6 years 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/2681ad361b4295756be... [2]: https://github.com/tauri-apps/tauri/blob/015474657c955c7ad29... [3]: https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216... [4]: https://github.com/tauri-apps/tauri/blob/c8f430297f95df16216...

zemnmez3• 6 years 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

buffersandbeer• 6 years ago

Has an issue been opened in their github for this? I looked quickly and didn't see one, but would love to track it.

ori_b• 6 years ago

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

fmakunbound• 6 years 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• 6 years ago

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

programmarchy2• 6 years ago

Yes, here's the magic sauce: 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.

baxrob5• 6 years 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/ which uses WebKitGTK

wackget• 6 years 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• 6 years ago

Detail | Tauri | Electron
FLOSS | Yes | No

Pardon? https://github.com/electron/electron/blob/master/LICENSE Looks awfully FLOSS to me.

dljsjr• 6 years ago

Seems somebody asked them about this already on their issue tracker: 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.

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

Related Stories