
Tauri – toolchain for building secure native apps that have tiny binaries - jaden
https://github.com/tauri-apps/tauri
======
danpalmer
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.

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

~~~
k__
This.

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

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

~~~
_pdp_
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. ;)

~~~
K0nserv
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.

~~~
_pdp_
And who is best to decide what is best for the application but the developer
who created it? If I want to create an app that looks like a game and just
happen not to run fullscreen why should we even discuss conformity with native
UIs as a feature? The user have the right not to bother installing the
software if they don't like it.

The whole argument is just silly. Are shell scripts native? And if my compiled
binary prints a control character in the terminal screen that is not supported
by the terminal you use, does that mean that the binary is not native because
it does not conform with the expected behaviour?

I know that I am not convincing anyone with this comment but it is fascinating
to see people having such a constrained view on software. Software is what you
make out of it and sometimes its weird looks and behaviour is what makes it
special. There are many such examples.

Let's drop this "not native" argument and simply talk about not having the
same performance because JavaScript is interpreted.

~~~
K0nserv
Of course everyone is free to build apps in whichever way they want, others
are free to take issue with it.

My argument here is that these "blank canvas" cross platform UI toolkits are
trading an improved developer experience for hard to spot, but very real, user
experience issues. A very concrete way in which many "blank canvas" cross
platform UI fails the user is accessibility especially on platforms that are
renowned and used for their good accessibility like iOS. There's also memory
and energy consumption concerns with solutions that abstract over native
tooling at the cost of increased memory and energy use, you could argue this
is unethical or at least needlessly limits your addressable market by locking
out segments of world.

Not all users are in charge of the apps they have to use either so the
argument that they can chose to not install an app doesn't hold water.

~~~
_pdp_
The iOS SDKs provide a number of features that increase developer
productivity, many of which are related accessibility because this is what iOS
SDKs are all about. It is not like the iOS OS automatically does all of the
work for you, it is the libraries and how you use them! Without the libraries,
you have to implement these features yourself.

Equally, the web platform increases developer productivity by providing an
easy to use cross-platform UI libraries you can use whichever way you like.
The leverage is different - it is still leverage no different than the iOS
SDKs. Without these libraries, you have to write it all by yourself.

We are looking at the same thing from two different angles, hence why I find
the argument silly. Everything is native if not emulated. We can argue about
performance or the conformity with style guides and UX best practices but to
brush off the web as irrelevant software development platform is crazy given
that you can attribute a lot of the progress we made over the recent history
due to the progress and standardization of web technologies. There is still a
lot to do but, guess what, to create an open cross-platform programming
environment with such a large adoption is a pretty difficult task.

From a UX perspective, there is frankly no particular reason for all apps to
look and behave the same. Your browser is open 100% of the time, it occupies
30-50% of the screen estate, yet 99% of the UX is custom and significant
changes from one web page to another. I don't think that bothers anyone.

> There's also memory and energy consumption concerns with solutions that
> abstract over native tooling

I agree that the web can be made greener but you can write an equally sloppy
app with Swift and Objective-C. But here is the question for which I have no
answer. Is it ethical to write the same software in 3 different ways due to
platform differences and does that contribute to a larger carbon footprint
than one app that is written sloppily with web technologies? Maybe we will
never know but it is an interesting question don't you think?

> Not all users are in charge of the apps they have to use either so the
> argument that they can chose to not install an app doesn't hold water.

And luckily no one is in charge of what software people should write and how
they should write it.

------
zemnmez
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...](https://github.com/tauri-
apps/tauri/blob/2681ad361b4295756bef560b5d74ece2a757749f/cli/tauri.js/api-
src/process.ts#L10) [2]: [https://github.com/tauri-
apps/tauri/blob/015474657c955c7ad29...](https://github.com/tauri-
apps/tauri/blob/015474657c955c7ad29463e9e88a26c34fa8e560/cli/tauri.js/templates/tauri.js#L16)
[3]: [https://github.com/tauri-
apps/tauri/blob/c8f430297f95df16216...](https://github.com/tauri-
apps/tauri/blob/c8f430297f95df16216f222772a8f989d2efd3e5/tauri/src/event.rs#L47)
[4]: [https://github.com/tauri-
apps/tauri/blob/c8f430297f95df16216...](https://github.com/tauri-
apps/tauri/blob/c8f430297f95df16216f222772a8f989d2efd3e5/tauri/src/endpoints.rs#L160)

~~~
zemnmez
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)

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

~~~
nim2020
I just filed one: [https://github.com/tauri-
apps/tauri/issues/814](https://github.com/tauri-apps/tauri/issues/814)

------
K0nserv
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
"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/me...](https://www.devexpress.com/products/net/controls/wpf/grid/media/carousel/wpf-
grid-devav-hd.png)

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.

~~~
p_l
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.

~~~
gridlockd
> Worst, yet still beats the pants off Electron and the like.

I disagree. Sure, Electron uses a lot of memory, but I _have_ a lot of memory
and I _don 't have_ a lot of tolerance for awful looking UI widgets that I
have to stare at all day.

~~~
p_l
I'll take ugly if it means low, predictable latency. And even having lots of
memory, I might have other uses for it than just one electron app.

------
0xcoffee
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...](https://github.com/dotnet/platform-
compat/blob/master/docs/DE0001.md) because it doesn't really provide any extra
security anyway..

~~~
nim2020
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
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.

------
mekkkkkk
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?

------
carterklein13
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
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...

------
DominikD
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

------
ausjke
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
[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.

~~~
ComputerGuru
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.

------
malkia
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
If imgui had accessibility integration it would be great.

~~~
p_l
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.

------
fmakunbound
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
So this is basically "Kind of like Electron, but with reasonable resource
consumption and performance"? An Electron competitor?

~~~
programmarchy
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
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
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
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

------
bluehex
There's a lot more info at [https://tauri.studio](https://tauri.studio).

------
yellowapple
> 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
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.

------
ydj
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.

~~~
baxrob
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)

------
wackget
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.

------
rspoerri
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
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
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.

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

