| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kind of a subtle idea. Teliva the framework is intended to be
trustworthy software that people install on their computers. The apps
people run using Teliva may be less trustworthy. The whole point of
Teliva is to provide a sandbox for running code before you trust it.
One way (of many) apps can be malicious is by subtly getting between
what people see and reality. Imagine, for example, an app that draws a
fake menu bar and offers a different hotkey to edit source code. When
someone presses that hotkey they think they're using the standard Teliva
editor but they're really using an editor within the app, which the app
uses to hide its most malicious bits from view.
Down the road Teliva will have more bits of UI, such as for asking for
permission to read sensitive data. It's important that people understand
what they're granting permission to, that apps can't tamper with the
communications channel between them and Teliva.
This is likely just one of many ways for an app to break out of its
sandbox. Teliva isn't sandboxed yet. I'm just taking my first steps on
this journey. In particular, there are other mechanisms for asking for
user input besides `getch()`. I don't yet have a big-picture view of the
Teliva sandbox.
It seems clear that I need to educate people on the difference between
different parts of screen. Depending on the app you install, most of the
screen may be a dark forest. It'll be important to know where the safe
path is, where you can speak to trusted advisors while in the forest.
|