Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #244196

Re: Firefox PDF download - strange behaviour.

From The Wanderer <wanderer@fastmail.fm>
Newsgroups linux.debian.user
Subject Re: Firefox PDF download - strange behaviour.
Date 2022-01-18 17:40 +0100
Message-ID <DGZGy-ZZ-9@gated-at.bofh.it> (permalink)
References <DGiLg-63n-7@gated-at.bofh.it> <DGiLg-63n-9@gated-at.bofh.it> <DGiLg-63n-5@gated-at.bofh.it> <DGsKC-4kR-1@gated-at.bofh.it> <DGHgC-5zu-5@gated-at.bofh.it>
Organization This space intentionally left blank.

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On 2022-01-17 at 15:55, Jeremy Nicoll wrote:

> On Mon, 17 Jan 2022, at 05:19, songbird wrote:
> 
>> you are right, but i just wanted to say that for some sites the
>> behavior is to generate a unique file name if they find one that
>> already exists with the same name and for other sites it is not.  i
>> think this is dependent upon the website designers and not
>> firefox.
> 
> Are you saying that code on a webpage can interrogate my file system
> to see whether certain files exist?  I don't like the sound of that.
> 
> A quick google found me: 
> https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API
>
>  which seems to describe ways that Javascript can read and write my
> files, and scan my directories (or will be able to when this API is
> implemented).
> 
> There's not enough information, in my view, explaining how a browser
> user can prevent that.  It says - if I'm reading it right - that it's
> secure because users are offered file pickers etc when a file is to
> be opened or file-save dialogs when something is to be created.

The key is probably that - if my reading is correct - then what the
handles acquired by presenting such a file picker dialog do is to grant
access to the specified directory *and everything underneath it*, but
not to anything *outside* of that.

> But one of the code examples describes getting a handle to a
> directory and says if the directory doesn't exist yet it will be
> created.  That suggests that rogue code could create folders on my
> system.

Looking at that example, I note that it starts with the variable name
"currentDirHandle". I think it's intended, although not explicitly
stated, that the directory path specified in that function call is
*relative*; that would let the API be used to create subdirectory trees
underneath the user-chosen directory, but not outside of there.

So this could potentially be dangerous if the user chooses a directory
location that's high enough in the directory tree to have important
files already underneath it, but not if the user chooses e.g. a
dedicated Downloads directory.

I can still envision scenarios in which this could be dangerous, but
unless there are ways to get access to a file-handle variable that don't
rely on something directly user-interactive (the ones described in that
page are file-picker dialogs and "drag and drop a file into (a specific
area of?) the browser window"), I don't think it can plausibly do so in
a way that's invisible to the user.

> I think I also read that once the code has a handle to a directory it
> can scan sub-directories as well.

Yes, that appears to be correct.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Firefox PDF download - strange behaviour. Kamil Jońca <kjonca@o2.pl> - 2022-01-16 19:50 +0100
  Re: Firefox PDF download - strange behaviour. songbird <songbird@anthive.com> - 2022-01-17 06:30 +0100
    Re: Firefox PDF download - strange behaviour. "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2022-01-17 22:00 +0100
      Re: Firefox PDF download - strange behaviour. songbird <songbird@anthive.com> - 2022-01-18 06:00 +0100
        Re: Firefox PDF download - strange behaviour. "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2022-01-18 15:50 +0100
          Re: Firefox PDF download - strange behaviour. David Wright <deblis@lionunicorn.co.uk> - 2022-01-18 17:50 +0100
          Re: Firefox PDF download - strange behaviour. songbird <songbird@anthive.com> - 2022-01-18 17:50 +0100
            Re: Firefox PDF download - strange behaviour. Vincent Lefevre <vincent@vinc17.net> - 2022-01-18 19:30 +0100
          Re: Firefox PDF download - strange behaviour. Curt <curty@free.fr> - 2022-01-19 13:50 +0100
      Re: Firefox PDF download - strange behaviour. The Wanderer <wanderer@fastmail.fm> - 2022-01-18 17:40 +0100
        Re: Firefox PDF download - strange behaviour. "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2022-01-18 17:50 +0100
        Re: Firefox PDF download - strange behaviour. Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-21 10:50 +0100

csiph-web