Using search options in HTTP-style links

Using search options in HTTP-style links

[Joseph Turner]

Hello!

[[info:org#Search Options]] says that search options are intended for
file: type links only.  However, since Org documents can also be loaded
over network protocols like HTTP and hyper://, I'd like to deliberate
if/how search options might be encoded inside HTTP-style link fragments.

HTTP-style links are URL-encoded with "#"-prefixed link fragments:

(let ((domain "https://ushin.org")
      (filename "needs-list.org")
      (search-option "::#care"))
  (format "%s/%s#%s" domain (url-hexify-string filename)
          (url-hexify-string search-option)))

=>  "https://ushin.org/needs-list.org#%3A%3A%23care"

Currently, loading the above URL with EWW...

(eww "https://ushin.org/needs-list.org#%3A%3A%23care")

...loads the file in eww-mode with point at the top of the file.

I think it would be more useful to instead activate org-mode (or a mode
which derives from it - "eww-org-mode"?), decode the link fragment, and
then jump to the location specified by the search option.

Web browsers like Firefox don't handle Org search options in link
fragments, but then again, they don't handle Org documents at all.  On my
machine, loading https://ushin.org/needs-list.org#%3A%3A%23care in
Firefox downloads the file as if the fragment weren't there.

What other issues might arise when encoding search options this way?

Any other comments/questions welcome :)

Thank you!

Joseph

Re: Using search options in HTTP-style links

[Ihor Radchenko]

Joseph Turner <joseph@ushin.org> writes:

> ...
> (eww "https://ushin.org/needs-list.org#%3A%3A%23care")
>
> ...loads the file in eww-mode with point at the top of the file.
>
> I think it would be more useful to instead activate org-mode (or a mode
> which derives from it - "eww-org-mode"?), decode the link fragment, and
> then jump to the location specified by the search option.

There is a convention for pdfs:
http://www.example.com/document.pdf#page=5
But, AFAIK, it is not RFC.

So, there is nothing stopping from creating an ad-hoc convention to
parse URL locators in links to PDFs or org files or whatnot.

However, the question about activating a major mode on web content is a
question to Emacs developers. It should be considered carefully, because
activating major modes may not be safe.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Using search options in HTTP-style links

[Joseph Turner]

Ihor Radchenko <yantar92@posteo.net> writes:

> Joseph Turner <joseph@ushin.org> writes:
>
>> ...
>> (eww "https://ushin.org/needs-list.org#%3A%3A%23care")
>>
>> ...loads the file in eww-mode with point at the top of the file.
>>
>> I think it would be more useful to instead activate org-mode (or a mode
>> which derives from it - "eww-org-mode"?), decode the link fragment, and
>> then jump to the location specified by the search option.
>
> There is a convention for pdfs:
> http://www.example.com/document.pdf#page=5
> But, AFAIK, it is not RFC.
>
> So, there is nothing stopping from creating an ad-hoc convention to
> parse URL locators in links to PDFs or org files or whatnot.

I'll need to dig a little more to see what changes would need to be made
in order for org-store-link to store properly formatted search options
with http: or hyper: links.  Currently, org-create-file-search-functions
is only used when creating a file: link.

> However, the question about activating a major mode on web content is a
> question to Emacs developers. It should be considered carefully, because
> activating major modes may not be safe.

hyperdrive.el activates a major mode with set-auto-mode when content is
loaded over the network.  This behavior is on by default.  Do you have
any advice about this?

Should hyperdrive.el set untrusted-content to t?

Thanks!

Joseph

Re: Using search options in HTTP-style links

[Ihor Radchenko]

Joseph Turner <joseph@ushin.org> writes:

>> So, there is nothing stopping from creating an ad-hoc convention to
>> parse URL locators in links to PDFs or org files or whatnot.
>
> I'll need to dig a little more to see what changes would need to be made
> in order for org-store-link to store properly formatted search options
> with http: or hyper: links.  Currently, org-create-file-search-functions
> is only used when creating a file: link.

You can instead use :store link parameter. It takes precedence over
everything else in `org-store-link'.

>> However, the question about activating a major mode on web content is a
>> question to Emacs developers. It should be considered carefully, because
>> activating major modes may not be safe.
>
> hyperdrive.el activates a major mode with set-auto-mode when content is
> loaded over the network.  This behavior is on by default.  Do you have
> any advice about this?
>
> Should hyperdrive.el set untrusted-content to t?

I was mostly talking about commands like eww - I simply recall a similar
proposal being made about activating Org mode when the URL points to Org
file. That proposal has been rejected on the grounds of security. See
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774

The case with hyperdrive.el is not the same.
You may want to discuss it on emacs-devel.

As for untrusted-content, there is no point using it now - it was
specifically introduced for Org mode. It may or may not become a part of
more general security framework in Emacs.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Using search options in HTTP-style links

[Joseph Turner]

Ihor Radchenko <yantar92@posteo.net> writes:

> I was mostly talking about commands like eww - I simply recall a similar
> proposal being made about activating Org mode when the URL points to Org
> file. That proposal has been rejected on the grounds of security. See
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774
>
> The case with hyperdrive.el is not the same.
> You may want to discuss it on emacs-devel.

Thank you!  It is a good idea to get more input on securing
hyperdrive.el.  For now, I went through bug#58744 and took some notes in
two relevant hyperdrive.el issues:

- https://todo.sr.ht/~ushin/ushin/178
- https://todo.sr.ht/~ushin/ushin/178

> As for untrusted-content, there is no point using it now - it was
> specifically introduced for Org mode. It may or may not become a part of
> more general security framework in Emacs.

Sounds good.

Thank you!!

Joseph

Re: Using search options in HTTP-style links

[Ihor Radchenko]

Joseph Turner <joseph@ushin.org> writes:

>> The case with hyperdrive.el is not the same.
>> You may want to discuss it on emacs-devel.
>
> Thank you!  It is a good idea to get more input on securing
> hyperdrive.el.  For now, I went through bug#58744 and took some notes in
> two relevant hyperdrive.el issues:
>
> - https://todo.sr.ht/~ushin/ushin/178

I think I mentioned earlier that a good way to make file links work
magically is using TRAMP or `file-name-handler-alist'.

> - https://todo.sr.ht/~ushin/ushin/178

You probably meant to link to some different ticket here.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Using search options in HTTP-style links

[Joseph Turner]

Ihor Radchenko <yantar92@posteo.net> writes:

> Joseph Turner <joseph@ushin.org> writes:
>
>>> The case with hyperdrive.el is not the same.
>>> You may want to discuss it on emacs-devel.
>>
>> Thank you!  It is a good idea to get more input on securing
>> hyperdrive.el.  For now, I went through bug#58744 and took some notes in
>> two relevant hyperdrive.el issues:
>>
>> - https://todo.sr.ht/~ushin/ushin/178
>
> I think I mentioned earlier that a good way to make file links work
> magically is using TRAMP or `file-name-handler-alist'.

Thank you.  Yes, I'd like to explore these options more.

>> - https://todo.sr.ht/~ushin/ushin/178
>
> You probably meant to link to some different ticket here.

https://todo.sr.ht/~ushin/ushin/188

Thanks!

Joseph

Re: Using search options in HTTP-style links

[Ihor Radchenko]

Joseph Turner <joseph@ushin.org> writes:

>> You probably meant to link to some different ticket here.
>
> https://todo.sr.ht/~ushin/ushin/188

So, you want an equivalent of `org-safe-remote-resources'.

Generally, we might eventually move it to Emacs core, making a more
general Emacs safety framework with unified preferences.
But someone™ has to do this job. As usual.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Using search options in HTTP-style links

[Joseph Turner]

Ihor Radchenko <yantar92@posteo.net> writes:

> Joseph Turner <joseph@ushin.org> writes:
>
>>> You probably meant to link to some different ticket here.
>>
>> https://todo.sr.ht/~ushin/ushin/188
>
> So, you want an equivalent of `org-safe-remote-resources'.

For now, we've added a command `hyperdrive-mark-as-safe`, which causes
automatic major modes activation when opening a file in a "safe" drive:

https://ushin.org/hyperdrive/hyperdrive-manual.html#Mark-a-hyperdrive-as-safe
https://git.sr.ht/~ushin/hyperdrive.el/commit/1e9b892e87979d3da5e9a1f04d0255a620500214

`org-file-contents' and `org-safe-remote-resources' already work with
hyperdrive.el.  We just need to figure out a way to treat

#+SETUPFILE: /foo/bar.org

as

#+SETUPFILE: hyper://CURRENT-DRIVE-PUBKEY/foo/bar.org

since the latter already works.  Perhaps this link conversion will work
when we implement magic file name handlers.  :)

> Generally, we might eventually move it to Emacs core, making a more
> general Emacs safety framework with unified preferences.
> But someone™ has to do this job. As usual.

Yes, a general Emacs safety framework would be an improvement.

Thank you for helping thinking through these security concerns!

Joseph