bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[daniel watson via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2459 bytes --]


0. in one terminal, run this http server
   https://git.sr.ht/~ozzloy/emacs-bug-63941/tree/master/item/server.py
1. in another terminal, run
   socat -v tcp-listen:8086,fork tcp:localhost:8085
2. browse to the page with EWW,
   M-x eww <ENTER> localhost:8086 <ENTER>
3. put the cursor on the word "Browse" <ENTER>
4. select any file to which you have read access for uploading
5. put cursor on "Submit" <ENTER>
6. observe the full path of the file is sent to the server.  this is
   visible in both the python output and the socat output.

i'm including the diff inline to make it easier to review without
downloading the attached file.

---
 lisp/net/eww.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index 4ddda216afc..f28273dcc58 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -1849,7 +1849,7 @@ eww-submit
                                   (insert-file-contents file)
                                   (buffer-string)))
                           (cons "name" name)
-                          (cons "filename" file))
+                          (cons "filename" (file-name-nondirectory file)))
                     values)))
 	   ((equal (plist-get input :type) "submit")
 	    ;; We want the values from buttons if we hit a button if
-- 
2.39.2




In GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
 cairo version 1.16.0) of 2023-08-03 built on bos03-amd64-031
Repository revision: cf57ec68c2a5ac5b721f445928869ca14232a4d1
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Ubuntu 23.04

Configured using:
 'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
 --without-xaw3d --with-modules --with-cairo
 --with-native-compilation=aot --with-xinput2 --with-tree-sitter
 --with-json
 'CFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
 -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu
 -isystem/build/emacs/stage/usr/include -O2'
 'CPPFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
 -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu
 -isystem/build/emacs/stage/usr/include'
 'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
 -L/build/emacs/parts/emacs/install/usr/lib
 -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
 -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu
 -L/build/emacs/stage/usr/lib''



[-- Attachment #2: 0001-send-filename-not-full-path-on-EWW-form-submit.patch --]
[-- Type: text/x-diff, Size: 1170 bytes --]

From 7b360d91a6667034da7c682af01ee1008d052c40 Mon Sep 17 00:00:00 2001
From: Daniel Watson <ozzloy@each.do>
Date: Tue, 12 Sep 2023 00:06:14 -0700
Subject: [PATCH] ; send filename, not full path, on EWW form submit

; * lisp/net/eww.el (eww-submit): Instead of sending the entire file
; path, send just the filename and not the directory.  This is the
; behavior seen in other clients, such as firefox, chromium, and curl.
; It keeps information about the users directory structure private.
---
 lisp/net/eww.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index 4ddda216afc..f28273dcc58 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -1849,7 +1849,7 @@ eww-submit
                                   (insert-file-contents file)
                                   (buffer-string)))
                           (cons "name" name)
-                          (cons "filename" file))
+                          (cons "filename" (file-name-nondirectory file)))
                     values)))
 	   ((equal (plist-get input :type) "submit")
 	    ;; We want the values from buttons if we hit a button if
-- 
2.39.2

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Stefan Kangas]

daniel watson <ozzloy@challenge-bot.com> writes:

> i'm including the diff inline to make it easier to review without
> downloading the attached file.

Most (or all?) people reviewing patches use Emacs mail readers, so we
have no trouble reviewing attached files.  Getting it as an attachment
actually makes things easier for us, as our tools are adapted to that
workflow.  That's the main reason why we have a preference for that
format.

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[daniel watson via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Fri, Sep 15, 2023 at 04:47:08AM -0700, Stefan Kangas wrote:
> Most (or all?) people reviewing patches use Emacs mail readers, so we
> have no trouble reviewing attached files.  Getting it as an attachment
> actually makes things easier for us, as our tools are adapted to that
> workflow.  That's the main reason why we have a preference for that
> format.

that makes sense.  i want to get my email setup like that.

the inline patch was included for easier viewing in the browser and not
as a replacement for the attachment, or endorsing skipping the
attachment.  so i'm glad you clarified

on the last bug report, when i got help from people, i found myself
linking to both the bug report page, and separately to another page
where they could view the code in-browser.  maybe the bug report page
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65973
could display the attached patch in addition to having a download link.
the source code for this page has not been touched in years though, so
that makes me think it will be difficult to contribute a change.

thanks for the assistance with this and the prior bug!

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[ozzloy]

[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]

bump

On Wed, Sep 13, 2023 at 11:10 PM daniel watson <ozzloy@challenge-bot.com>
wrote:

>
> 0. in one terminal, run this http server
>    https://git.sr.ht/~ozzloy/emacs-bug-63941/tree/master/item/server.py
> 1. in another terminal, run
>    socat -v tcp-listen:8086,fork tcp:localhost:8085
> 2. browse to the page with EWW,
>    M-x eww <ENTER> localhost:8086 <ENTER>
> 3. put the cursor on the word "Browse" <ENTER>
> 4. select any file to which you have read access for uploading
> 5. put cursor on "Submit" <ENTER>
> 6. observe the full path of the file is sent to the server.  this is
>    visible in both the python output and the socat output.
>
> i'm including the diff inline to make it easier to review without
> downloading the attached file.
>
> ---
>  lisp/net/eww.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lisp/net/eww.el b/lisp/net/eww.el
> index 4ddda216afc..f28273dcc58 100644
> --- a/lisp/net/eww.el
> +++ b/lisp/net/eww.el
> @@ -1849,7 +1849,7 @@ eww-submit
>                                    (insert-file-contents file)
>                                    (buffer-string)))
>                            (cons "name" name)
> -                          (cons "filename" file))
> +                          (cons "filename" (file-name-nondirectory file)))
>                      values)))
>            ((equal (plist-get input :type) "submit")
>             ;; We want the values from buttons if we hit a button if
> --
> 2.39.2
>
>
>
>
> In GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
>  cairo version 1.16.0) of 2023-08-03 built on bos03-amd64-031
> Repository revision: cf57ec68c2a5ac5b721f445928869ca14232a4d1
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
> System Description: Ubuntu 23.04
>
> Configured using:
>  'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
>  --without-xaw3d --with-modules --with-cairo
>  --with-native-compilation=aot --with-xinput2 --with-tree-sitter
>  --with-json
>  'CFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
>  -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu
>  -isystem/build/emacs/stage/usr/include -O2'
>  'CPPFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
>  -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu
>  -isystem/build/emacs/stage/usr/include'
>  'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
>  -L/build/emacs/parts/emacs/install/usr/lib
>  -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
>  -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu
>  -L/build/emacs/stage/usr/lib''
>
>
>

[-- Attachment #2: Type: text/html, Size: 3539 bytes --]

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Sebastián Monía]

/added Jim for visibility/

This seems like something simple enough to merge.
Thoughts?

ozzloy <ozzloy@gmail.com> writes:
>  bump
>
>  On Wed, Sep 13, 2023 at 11:10 PM daniel watson <ozzloy@challenge-bot.com> wrote:
>
>  0. in one terminal, run this http server
>     https://git.sr.ht/~ozzloy/emacs-bug-63941/tree/master/item/server.py
>  1. in another terminal, run
>     socat -v tcp-listen:8086,fork tcp:localhost:8085
>  2. browse to the page with EWW,
>     M-x eww <ENTER> localhost:8086 <ENTER>
>  3. put the cursor on the word "Browse" <ENTER>
>  4. select any file to which you have read access for uploading
>  5. put cursor on "Submit" <ENTER>
>  6. observe the full path of the file is sent to the server.  this is
>     visible in both the python output and the socat output.
>
>  i'm including the diff inline to make it easier to review without
>  downloading the attached file.
>
>  ---
>   lisp/net/eww.el | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
>  diff --git a/lisp/net/eww.el b/lisp/net/eww.el
>  index 4ddda216afc..f28273dcc58 100644
>  --- a/lisp/net/eww.el
>  +++ b/lisp/net/eww.el
>  @@ -1849,7 +1849,7 @@ eww-submit
>                                     (insert-file-contents file)
>                                     (buffer-string)))
>                             (cons "name" name)
>  -                          (cons "filename" file))
>  +                          (cons "filename" (file-name-nondirectory file)))
>                       values)))
>             ((equal (plist-get input :type) "submit")
>              ;; We want the values from buttons if we hit a button if
>  -- 
>  2.39.2
>
>  In GNU Emacs 29.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
>   cairo version 1.16.0) of 2023-08-03 built on bos03-amd64-031
>  Repository revision: cf57ec68c2a5ac5b721f445928869ca14232a4d1
>  Repository branch: master
>  Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
>  System Description: Ubuntu 23.04
>
>  Configured using:
>   'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
>   --without-xaw3d --with-modules --with-cairo
>   --with-native-compilation=aot --with-xinput2 --with-tree-sitter
>   --with-json
>   'CFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
>   -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu
>   -isystem/build/emacs/stage/usr/include -O2'
>   'CPPFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
>   -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu
>   -isystem/build/emacs/stage/usr/include'
>   'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
>   -L/build/emacs/parts/emacs/install/usr/lib
>   -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
>   -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu
>   -L/build/emacs/stage/usr/lib''
>

-- 
Sebastián Monía
https://site.sebasmonia.com/

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Eli Zaretskii]

> Cc: daniel watson <ozzloy@challenge-bot.com>, 65973@debbugs.gnu.org
> From: Sebastián Monía
>  <sebastian@sebasmonia.com>
> Date: Tue, 05 Nov 2024 09:34:46 -0500
> 
> 
> /added Jim for visibility/
> 
> This seems like something simple enough to merge.
> Thoughts?
> 
> ozzloy <ozzloy@gmail.com> writes:
> >  bump
> >
> >  On Wed, Sep 13, 2023 at 11:10 PM daniel watson <ozzloy@challenge-bot.com> wrote:
> >
> >  0. in one terminal, run this http server
> >     https://git.sr.ht/~ozzloy/emacs-bug-63941/tree/master/item/server.py
> >  1. in another terminal, run
> >     socat -v tcp-listen:8086,fork tcp:localhost:8085
> >  2. browse to the page with EWW,
> >     M-x eww <ENTER> localhost:8086 <ENTER>
> >  3. put the cursor on the word "Browse" <ENTER>
> >  4. select any file to which you have read access for uploading
> >  5. put cursor on "Submit" <ENTER>
> >  6. observe the full path of the file is sent to the server.  this is
> >     visible in both the python output and the socat output.
> >
> >  i'm including the diff inline to make it easier to review without
> >  downloading the attached file.

I'd like some rationale for this change.  The original report never
explains why sending the full absolute file name to the server is bad.

Please note that using file names without directories in Emacs means
that the file is presumed to live in the current-buffer's
default-directory.  I'm not sure I understand why this is correct in
this case, and neither am I sure that the server will interpret it
like that (because the server might run in a different directory).
But maybe I'm missing something important here.

Thanks.

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Jim Porter]

On 11/5/2024 9:08 AM, Eli Zaretskii wrote:
>> Cc: daniel watson <ozzloy@challenge-bot.com>, 65973@debbugs.gnu.org
>> From: Sebastián Monía
>>   <sebastian@sebasmonia.com>
>> Date: Tue, 05 Nov 2024 09:34:46 -0500
>>
>>
>> /added Jim for visibility/
>>
>> This seems like something simple enough to merge.
>> Thoughts?
>>
>> ozzloy <ozzloy@gmail.com> writes:
>>>   bump
>>>
>>>   On Wed, Sep 13, 2023 at 11:10 PM daniel watson <ozzloy@challenge-bot.com> wrote:
>>>
>>>   0. in one terminal, run this http server
>>>      https://git.sr.ht/~ozzloy/emacs-bug-63941/tree/master/item/server.py
>>>   1. in another terminal, run
>>>      socat -v tcp-listen:8086,fork tcp:localhost:8085
>>>   2. browse to the page with EWW,
>>>      M-x eww <ENTER> localhost:8086 <ENTER>
>>>   3. put the cursor on the word "Browse" <ENTER>
>>>   4. select any file to which you have read access for uploading
>>>   5. put cursor on "Submit" <ENTER>
>>>   6. observe the full path of the file is sent to the server.  this is
>>>      visible in both the python output and the socat output.
>>>
>>>   i'm including the diff inline to make it easier to review without
>>>   downloading the attached file.
> 
> I'd like some rationale for this change.  The original report never
> explains why sending the full absolute file name to the server is bad.

I see three possible reasons: 1) there could be (probably minor) privacy 
issues with sending the directory structure along to a server; 2) as far 
as I'm aware, other browsers only pass the "leaf" of the filename; 3) 
RFC 2813 says that *recipients* should ignore any directories:

    The receiving MUA SHOULD NOT respect any directory path information
    that may seem to be present in the filename parameter.  The filename
    should be treated as a terminal component only.  Portable
    specification of directory paths might possibly be done in the future
    via a separate Content-Disposition parameter, but no provision is
    made for it in this draft.

RFC 2813 is primarily about mail clients, but MDN suggests following it 
in a web context as well: 
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition>. 
So I think the RFC would suggest that it's *allowed* to send the 
directories in the "filename" field, but since the server is supposed to 
ignore it, there's no benefit to doing so.

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Sebastián Monía]

Jim Porter <jporterbugs@gmail.com> writes:
> On 11/5/2024 9:08 AM, Eli Zaretskii wrote:
>> I'd like some rationale for this change.  The original report never
>> explains why sending the full absolute file name to the server is bad.
>
> I see three possible reasons: 1) there could be (probably minor)
> privacy issues with sending the directory structure along to a server;
> 2) as far as I'm aware, other browsers only pass the "leaf" of the
> filename; 3) RFC 2813 says that *recipients* should ignore any
> directories: [...]
> RFC 2813 is primarily about mail clients, but MDN suggests following
> it in a web context as well:
> <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition>.

> So I think the RFC would suggest that it's *allowed* to send the
> directories in the "filename" field, but since the server is supposed
> to ignore it, there's no benefit to doing so.

I didn't get as far as Jim did. I assumed the concern was #1, and I knew
the rest of the path is ignored, so figured we should go ahead.

Regards,
Seb

-- 
Sebastián Monía
https://site.sebasmonia.com/

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[daniel watson]

the rationale was initially #1.

every other browser i looked into sent the filename only.  based on
that, i was more confident that it was worth submitting a patch.

#3 seems like a good reason too, but i did not know about that until
reading this thread.

Sebastián Monía <sebastian@sebasmonia.com> writes:

> Jim Porter <jporterbugs@gmail.com> writes:
>> On 11/5/2024 9:08 AM, Eli Zaretskii wrote:
>>> I'd like some rationale for this change.  The original report never
>>> explains why sending the full absolute file name to the server is bad.
>>
>> I see three possible reasons: 1) there could be (probably minor)
>> privacy issues with sending the directory structure along to a server;
>> 2) as far as I'm aware, other browsers only pass the "leaf" of the
>> filename; 3) RFC 2813 says that *recipients* should ignore any
>> directories: [...]
>> RFC 2813 is primarily about mail clients, but MDN suggests following
>> it in a web context as well:
>> <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition>.
>
>> So I think the RFC would suggest that it's *allowed* to send the
>> directories in the "filename" field, but since the server is supposed
>> to ignore it, there's no benefit to doing so.
>
> I didn't get as far as Jim did. I assumed the concern was #1, and I knew
> the rest of the path is ignored, so figured we should go ahead.
>
> Regards,
> Seb

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Stefan Kangas]

Jim Porter <jporterbugs@gmail.com> writes:

> On 11/5/2024 9:08 AM, Eli Zaretskii wrote:
>
>> I'd like some rationale for this change.  The original report never
>> explains why sending the full absolute file name to the server is bad.
>
> I see three possible reasons: 1) there could be (probably minor) privacy
> issues with sending the directory structure along to a server;

From a privacy perspective, I don't think this we can really consider
this as a minor issue.

Users commonly use their full names, or another similarly unique
identifier, as their login name.  It goes without saying, that sending a
string such as "/home/myfullname/some/file" to a remote host completely
defeats all notions of preserving user privacy.

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 6 Nov 2024 23:30:54 +0000
> Cc: ozzloy@challenge-bot.com, 65973@debbugs.gnu.org, ozzloy@gmail.com
> 
> Jim Porter <jporterbugs@gmail.com> writes:
> 
> > On 11/5/2024 9:08 AM, Eli Zaretskii wrote:
> >
> >> I'd like some rationale for this change.  The original report never
> >> explains why sending the full absolute file name to the server is bad.
> >
> > I see three possible reasons: 1) there could be (probably minor) privacy
> > issues with sending the directory structure along to a server;
> 
> >From a privacy perspective, I don't think this we can really consider
> this as a minor issue.
> 
> Users commonly use their full names, or another similarly unique
> identifier, as their login name.  It goes without saying, that sending a
> string such as "/home/myfullname/some/file" to a remote host completely
> defeats all notions of preserving user privacy.

The private information can be in the file name you send as well, so
this is not a convincing argument.

But since the RFC says to ignore the leading directories, I think the
change is okay, provided we describe the rationale in the comments to
the code.  It is very unusual thing in Emacs to remove leading
directories from a file name, so doing so generally begs for some
commentary.

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Jim Porter]

On 11/5/2024 11:36 AM, Jim Porter wrote:
> I see three possible reasons: 1) there could be (probably minor) privacy 
> issues with sending the directory structure along to a server; 2) as far 
> as I'm aware, other browsers only pass the "leaf" of the filename; 3) 
> RFC 2813 says that *recipients* should ignore any directories:

Just in case people get confused here (I did, upon re-reading my 
message): The correct RFC is 2183, not 2813.

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Jim Porter]

On 11/6/2024 10:20 PM, Eli Zaretskii wrote:
> But since the RFC says to ignore the leading directories, I think the
> change is okay, provided we describe the rationale in the comments to
> the code.  It is very unusual thing in Emacs to remove leading
> directories from a file name, so doing so generally begs for some
> commentary.

It sounds like we all agree on doing this for various reasons. I've now 
merged this to the master branch as f6b55678d76 with some commentary 
mentioning RFC 2183, so closing this bug.

Of course, if the commentary is insufficient or anyone notices any other 
issues, just let me know.

bug#65973: [PATCH] ; send filename, not full path, on EWW form submit

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> The private information can be in the file name you send as well, so
> this is not a convincing argument.

True, but then at least it's obvious to the user that private
information is being sent.  Leaking your username on file upload is not
something that I believe most users would expect.  I didn't, at least.

> But since the RFC says to ignore the leading directories, I think the
> change is okay, provided we describe the rationale in the comments to
> the code.  It is very unusual thing in Emacs to remove leading
> directories from a file name, so doing so generally begs for some
> commentary.

It seems like we agree then, thanks.