Re: Shall we serve scripts as application or as text?

[Seth Arnold]

On Mon, Aug 30, 2021 at 10:58:45PM +0100, Roger Lynn wrote:
> It is usually easy to save a text file from a web browser, while it is hard
> (impossible?) to persuade it to display an unknown application/* type. Thus,
> even if your latter example is more common, it may be preferable use text/.

There's a Firefox addon that you can use to tell the browser to just
try displaying whatever it is as text (or image or a few other options)
rather than spawning an application or saving it:

https://addons.mozilla.org/en-US/firefox/addon/open-in-browser/

This plugin has vastly improved my opinion of Firefox.

Thanks


signature.asc
Description: PGP signature

Re: Shall we serve scripts as application or as text?

[Jeremy Stanley]

On 2021-08-30 22:58:45 +0100 (+0100), Roger Lynn wrote:
[...]
> It is usually easy to save a text file from a web browser, while
> it is hard (impossible?) to persuade it to display an unknown
> application/* type. Thus, even if your latter example is more
> common, it may be preferable use text/.

I too prefer to view them as text, but this seems like something
which should be fixed *in* the browsers/clients, not worked around
at the server side (and more importantly, not by baking those
workarounds into default configuration). If everyone just serves the
workaround, the client-side bugs will almost certainly never be
fixed.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Shall we serve scripts as application or as text?

[Roger Lynn]

On 29/08/2021 15:20, Simon McVittie wrote:

The major difference is fallback behaviour. If a client (web browser or
email client or similar) receives a file with a text/* type for which it
has no special handler, in the absence of other context it is expected
to treat it like text/plain, and show the file to the user as text. If a
client receives a file with an unknown application/* type, it is expected
to treat it like application/octet-stream, assume that viewing the file as
text would be pointless because the user wouldn't necessarily understand
it anyway, and offer to save it or open it in an external program instead.

[snip]

For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter,
application/.


It is usually easy to save a text file from a web browser, while it is hard 
(impossible?) to persuade it to display an unknown application/* type. Thus, 
even if your latter example is more common, it may be preferable use text/.


Roger

Re: Shall we serve scripts as application or as text?

[Jonas Smedegaard]

Quoting Gunnar Wolf (2021-08-30 17:07:23)
> Simon McVittie dijo [Sun, Aug 29, 2021 at 03:13:02PM +0100]:
> > Using types outside text/ is definitely appropriate for very verbose text
> > languages like SVG and "flat" OpenDocument, where it's *technically*
> > text, and *technically* you could edit it with a text editor, but in
> > practice that's rarely what anyone wants.
> > 
> > For scripting languages like sh and Python, I'm not sure: either way
> > could be appropriate. Which is more common: sharing scripts as source
> > code to read and edit, or sharing scripts as executables to download
> > and run as-is? If the former, text/ makes sense, if the latter,
> > application/.
> 
> I side with Paul Wise -- If a script is served by a Web server to a 
> browser, I don't think the desired result will be to download and 
> execute right away. text/* seems much better suited for me. Users 
> willing to execute said scripts should download and execute locally -- 
> and nobody should be bitten by the surprise of automatic (even after a 
> UI acknowledgement) code execution of random Internet content.

You cannot know that a human is at the other end of the exchange.

You can choose to be honest about what your serve your audience, or you 
can try steer them when you think that you know better than them what 
they should do with it.

I think that the game of steering certain types of users belongs in the 
configuration files of web servers for specific web sites, not in the 
general defaults of the whole system.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Shall we serve scripts as application or as text?

[Jonas Smedegaard]

Quoting Paul Wise (2021-08-30 02:32:14)
> On Sun, Aug 29, 2021 at 2:13 PM Simon McVittie wrote:
> 
> > For scripting languages like sh and Python, I'm not sure: either way
> > could be appropriate. Which is more common: sharing scripts as source
> > code to read and edit, or sharing scripts as executables to download
> > and run as-is? If the former, text/ makes sense, if the latter,
> > application/.
> 
> I would lean towards encouraging review of scripts rather than
> downloading and executing them.

I would lean towards encouraging review of **all** objects downloaded 
online - not only scripts.

My point is, that I think the reasoning above is wrong: Improving 
user-operated web agents a.k.a. web browsers is better done at another 
layer than the classification of objects.

Is readability or executability the primary feature of a script?

I'd say it is the executability feature.

Yes, executing stuff can be dangerous sometimes, but emphasizing other 
features is a bad security practice.  If you sell a gun then warn that 
it can damage feet - don't emphasize how it can be used as a hammer.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Shall we serve scripts as application or as text?

[Russ Allbery]

Gunnar Wolf  writes:
> Simon McVittie dijo [Sun, Aug 29, 2021 at 03:13:02PM +0100]:

>> Using types outside text/ is definitely appropriate for very verbose
>> text languages like SVG and "flat" OpenDocument, where it's
>> *technically* text, and *technically* you could edit it with a text
>> editor, but in practice that's rarely what anyone wants.

>> For scripting languages like sh and Python, I'm not sure: either way
>> could be appropriate. Which is more common: sharing scripts as source
>> code to read and edit, or sharing scripts as executables to download
>> and run as-is? If the former, text/ makes sense, if the latter,
>> application/.

> I side with Paul Wise -- If a script is served by a Web server to a
> browser, I don't think the desired result will be to download and
> execute right away.

I certainly hope that no web browser would download *and execute* a script
from the web without user intervention.  I think the primary difference
between application/* and text/* is whether the web browser will display
the script like a web page by default or whether it will download it (but
not execute it) by default.

I'm not sure either of those will always be right.  In some cases, the
download behavior is probably desirable and displaying the script as text
will be irritating and make it harder to save; in other cases, downloading
it first will be annoying.  I personally would probably prefer the text/*
behavior most of the time, but I'm also not a typical user.

-- 
Russ Allbery (r...@debian.org)  

Re: Shall we serve scripts as application or as text?

[Gunnar Wolf]

Simon McVittie dijo [Sun, Aug 29, 2021 at 03:13:02PM +0100]:
> Using types outside text/ is definitely appropriate for very verbose text
> languages like SVG and "flat" OpenDocument, where it's *technically*
> text, and *technically* you could edit it with a text editor, but in
> practice that's rarely what anyone wants.
> 
> For scripting languages like sh and Python, I'm not sure: either way
> could be appropriate. Which is more common: sharing scripts as source
> code to read and edit, or sharing scripts as executables to download
> and run as-is? If the former, text/ makes sense, if the latter,
> application/.

I side with Paul Wise -- If a script is served by a Web server to a
browser, I don't think the desired result will be to download and
execute right away. text/* seems much better suited for me. Users
willing to execute said scripts should download and execute locally --
and nobody should be bitten by the surprise of automatic (even after
a UI acknowledgement) code execution of random Internet content.

mime.types vs mime/globs (was Re: Shall we serve scripts as application or as text?)

[Charles Plessy]

Le Sun, Aug 29, 2021 at 10:53:04PM +, Thaddeus H. Black a écrit :
> 
> What is the relationship between /etc/mime.types
> and /usr/share/mime/globs, please?  When to use the one and when,
> the other?

Hi Thaddeus,

/etc/mime.types is a conffile; you can edit it and dpkg will ensure to
preserve the changes or prompt you in case of conflicts during upgrades.

/usr/share/mime/globs is an autogenerated file.  Any change you make
there can be silently lost.

Also, /etc/mime.types is provided by a package, media-types, that
contains only this file, does not have dependancies and is more likely
to be installed on desktopless systems.

So if you only need a one-to-one lookup table for associating media
types and file extensions, and if you need to allow easy extension and
customisation by the local administrator, you should better use
/etc/mime.types.

The information in both files overlap a lot since most of it has the same
origin: the media types registered at the IANA.

https://www.iana.org/assignments/media-types/media-types.xhtml

This said, the XDG's shared MIME-info database contains much more
information than /etc/mime.types, such as magic numbers or subtypes.
If you write an application for a system where you can be sure that
this information is available, use it !

Cheers,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Shall we serve scripts as application or as text?

[Paul Wise]

On Sun, Aug 29, 2021 at 2:13 PM Simon McVittie wrote:

> For scripting languages like sh and Python, I'm not sure: either way
> could be appropriate. Which is more common: sharing scripts as source
> code to read and edit, or sharing scripts as executables to download
> and run as-is? If the former, text/ makes sense, if the latter,
> application/.

I would lean towards encouraging review of scripts rather than
downloading and executing them.

> If scripts and other source code are to be served as application/*, it
> would be good to check that all our "programmer's editor"-style programs
> have a MIME association set up for that type. In an extremely quick survey
> of the .desktop files of editors I happen to have installed on my GNOME
> laptop: gedit (a text editor) only registers itself to handle text/plain,
> GNOME Builder (an IDE for programmers) handles both text/ and application/
> for a wide variety of languages, and gvim (a text editor in hard mode :-)
> mostly only handles text/ types, except for application/x-shellscript
> where it only has application/ and not text/ for whatever reason.

application/x-shellscript seems to have wider support than text/x-shellscript:

https://wiki.debian.org/MimeTypesSupport/PackageList

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Shall we serve scripts as application or as text?

[Thaddeus H. Black]

Charles:

On Sun, Aug 29, 2021 at 02:17:10PM +0900, Charles Plessy wrote:
> Before I remove text/x-sh and the like so that shell and tcl scripts
> files are served as 'application' like others, I would like to hear if
> some of you see a potential problem with that.

Someone might see a problem, but I don't.  However, I have a question.

> Since Bullseye, the /etc/mime.types is provided in its own package,
> media-types, and in Bookworm I would like to brush up its contents
> further.

What is the relationship between /etc/mime.types
and /usr/share/mime/globs, please?  When to use the one and when,
the other?

I ask because I have been using /usr/share/mime/globs for all
purposes, and have not been using /etc/mime.types at all.

(You probably know already but to inform other readers:
the /usr/share/mime/globs file is installed by the
shared-mime-info package.)



signature.asc
Description: PGP signature

Re: Shall we serve scripts as application or as text?

[Simon McVittie]

On Sun, 29 Aug 2021 at 14:17:10 +0900, Charles Plessy wrote:
> Judging from IANA's registered types for other script languages, it
> looks like the application type is more relevant.  Also, the
> application/ types appear first in our /etc/media.types file, and if I
> remember well this gives them precedence anyway.  A quick random check
> in the Internet shows that there is no consistency on how shell scripts
> are served, but that the application type is used among others.

The major difference is fallback behaviour. If a client (web browser or
email client or similar) receives a file with a text/* type for which it
has no special handler, in the absence of other context it is expected
to treat it like text/plain, and show the file to the user as text. If a
client receives a file with an unknown application/* type, it is expected
to treat it like application/octet-stream, assume that viewing the file as
text would be pointless because the user wouldn't necessarily understand
it anyway, and offer to save it or open it in an external program instead.

Using types outside text/ is definitely appropriate for very verbose text
languages like SVG and "flat" OpenDocument, where it's *technically*
text, and *technically* you could edit it with a text editor, but in
practice that's rarely what anyone wants.

For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter,
application/.

If scripts and other source code are to be served as application/*, it
would be good to check that all our "programmer's editor"-style programs
have a MIME association set up for that type. In an extremely quick survey
of the .desktop files of editors I happen to have installed on my GNOME
laptop: gedit (a text editor) only registers itself to handle text/plain,
GNOME Builder (an IDE for programmers) handles both text/ and application/
for a wide variety of languages, and gvim (a text editor in hard mode :-)
mostly only handles text/ types, except for application/x-shellscript
where it only has application/ and not text/ for whatever reason.

smcv

Re: Shall we serve scripts as application or as text?

[Paul Wise]

On Sun, Aug 29, 2021 at 5:17 AM Charles Plessy wrote:

> Before I remove text/x-sh and the like so that shell and tcl scripts
> files are served as 'application' like others, I would like to hear if
> some of you see a potential problem with that.

Do the new MIME types cause different behavior in common browsers? ie
downloading instead of displaying or vice-versa.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise