proposal for an 'appstart' protocol

[Egmont Koblinger]

Hi all,

Responding briefly, because I won't have too much time to dig into the details.


On Mon, Jan 6, 2020 at 10:46 PM Bruno Haible <bruno at clisp.org> wrote:

>       - The 'grep' program shows references into disk files. When the
>         user selects one of these references, a text editor opens the
>         referenced file at the particular line.

This (opening a text file at a particular line, maybe column as well)
is the only feature missing from the hyperlink protocol that users are
asking for. See the comments at the gist. We spent some time trying to
find the right solution, but it's not easy.

Other tools, most notably gcc and friends would also highly benefit
from this feature.

If you aim to fix this, that would be highly appreciated!

Two bits are missing. One is: How to denote the line in the hyperlink.
Either make it part of the URL (e.g. #L1234, a notation often seen on
web VCS frontends), or pass it as another field in the OSC 8 protocol,
that is, outside of the URL. Both approaches have pros and cons,
again, read the gist's comments for more info.

The other missing bit is: How to launch the corresponding app? This
again has at least two levels: the desktop file and the supporting
code. There's no slot for the line number in the existing
infrastructure, e.g. corresponding parameter in .desktop files, so a
terminal emulator on Linux would figure out its own way of opening the
app, not integrating with the rest of the desktop (e.g. would need to
offer its own config for the user's favorite editor). But, luckily,
this xdg mailing list is the right place to address this. The desktop
file should be extended to support a line offset (and maybe character
too, but see the gist comments for problems with that). Then the next
question is: how to open it from existing toolkits, e.g. how would you
pass the external line number (if that's the answer to the previous
paragraph's question) to gtk_show_uri() or similar toolkits'
corresponding methods; would GTK and other developers accept a new
method taking an additional parameter?

All this can (and should) be addressed _within_ the already existing
frameworks of .desktop files, file:// protocol and so on; inventing
something brand new for this sounds a really bad idea to me.

The scheme could also be extended to time offset within a media file,
track on an audio CD, page number within a doc/pdf and so on, although
there's probably hardly any demand for these. (And seriously, who uses
audio CDs in computers anymore?)

> When the hostname is equal to the machine's gethostname(), the
> application should be started on that machine, without using network
> protocols.

And when the hostname is different... Trying to connect to that
hostname is potentially highly problematic. It might work in simple
setups, but not if there are firewall rules, proxying / load balancing
rules, if the server was reached via multiple hops, and so on. Also
note that most apps place the short hostname in file:// URLs because
that's what hostname() returns on many distros, and this is a concept
that belongs to the host itself, whereas the FQDN is subject to name
resolution and such, and a host might have multiple FQDNs, or one per
network interface etc., it's not easy to find one (let alone a
canonical) fqdn, and there's absolutely no guarantee others might
locate the host based on this.

Your other proposal is also problematic about listening: what if
you're not allowed to listen on that port? What if another user
already listens there?

Also I can't help notice that there's absolutely no security involved
in your protocols. Like, could anyone just connect there and ask to
run a certain app?

The current hyperlink behavior, including its security model,
deliberately follows what the web already does. It would be a
conceptual mistake to diverge from it, including building up
connections that the user doesn't expect.

> Why an apptype? Why not directly include the application name in
> the URI? Because the user may want to customize things:
>   - Different text editors exist.
>   - Different audio players exist.
>   - Different PO file editors exist.

No, not because of these reasons, but because of way more essential
security. Many times you can't control the message that gets printed
to the terminal; you might 'cat' a file you receive from an untrusted
source, or a buggy software might print raw data received from an
untrusted source, or you might ssh into a compromised server, and so
on. The data that arrives to your terminal is not guaranteed to be
safe, yet the experience of using the terminal must be safe.

Your proposal opens up the door for someone to inject a link into my
terminal which, should I ctrl+click on it, would locally wipe out my
files, or upload my potentially sensitive/confidential data to the
attacker's site. Such design is unacceptable.

I'm afraid that with your two proposals, you're trying address
problems that don't exist, as well as 1 actual problem where you take
a wrong approach. The existing 1 problem should be addressed inside
the familiar concepts, tools, protocols, file formats and security
model, and not by inventing something brand new that doesn't even
remotely resemble what we already have.


regards,
egmont