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

Groups > linux.debian.user > #244067 > unrolled thread

Re: Firefox PDF download - strange behaviour.

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#244067 — Re: Firefox PDF download - strange behaviour.

songbird <songbird@anthive.com> writes:

> Kamil Jońca wrote:
>>
>> Recently I recognized strange behaviour during pdf download with
>> firefox.
>> 1. When I enter target name with colon - this colon is replaced with
>> space.
>
>   no idea because i usually replace any strange characters 
> in file names with underlines before saving them to disk.  i
> do not automatically save or open pdfs from firefox or any
> other utility.

>
>
>> 2. When target file exists -  firefox does not ask to replace it but
>> create file with number.
>> (for example: I have already file.pdf, then firefox creates file(1).pdf)
>> What am I missing?
>
>   this is normal behavior for as long as i can remember using
> firefox.

This is simply not true. Because if I try to save *.jpeg, or *.jpg - i
got question if I want to overwrite file, which already exists.
And I am sure that some time ago pdf-s was also treated this way.
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

[toc] | [next] | [standalone]

#244104

Kamil Jońca wrote:
> songbird <songbird@anthive.com> writes:
>
>> Kamil Jońca wrote:
>>>
>>> Recently I recognized strange behaviour during pdf download with
>>> firefox.
>>> 1. When I enter target name with colon - this colon is replaced with
>>> space.
>>
>>   no idea because i usually replace any strange characters 
>> in file names with underlines before saving them to disk.  i
>> do not automatically save or open pdfs from firefox or any
>> other utility.
>
>>
>>
>>> 2. When target file exists -  firefox does not ask to replace it but
>>> create file with number.
>>> (for example: I have already file.pdf, then firefox creates file(1).pdf)
>>> What am I missing?
>>
>>   this is normal behavior for as long as i can remember using
>> firefox.
>
> This is simply not true. Because if I try to save *.jpeg, or *.jpg - i
> got question if I want to overwrite file, which already exists.
> And I am sure that some time ago pdf-s was also treated this way.
> KJ

  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.

  this has been the same for some sites as long as i've used
firefox.  i don't do a ton of file loading or pdf stuff but it
seems to be mostly financial ones that give me access to my 
statements that have this feature.  i still don't like that 
they do automatic filenames as i end up redoing them to fit my
own current naming scheme instead so they could call it file a.pdf
and i'd be fine with that.

  perhaps there is an addon or plugin that will do what you'd 
like.


  songbird

[toc] | [prev] | [next] | [standalone]

#244139

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.

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.

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

-- 
Jeremy Nicoll - my opinions are my own.

[toc] | [prev] | [next] | [standalone]

#244161

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.

  you are running the webpage on your browser so it is your
own computer and your own program that is doing the accessing
just like any other program you run.  what controls you wish
to put on the access to your file system and how you do that
is up to you and your own desires and capabilities.  for some
security systems they allow file access and directory access
controls, but what i do is set where files are saved in a
specific directory and leave it at that.  and, yes, more can
be done but i don't care to do it.  same as i could use a
very paranoid and text only based browser like lynx and
never run javascript or anything else that does things 
automatically, but then i'd probably not really enjoy doing
much on-line.  i pick my battles in other ways (like running
linux and debian) and i don't open or save files 
automatically.  those are good enough for me.  :)


> 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.
>
> 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.
>
> I think I also read that once the code has a handle to a directory
> it can scan sub-directories as well.

  you could break the issue down into two things quite easily
and not get super complicated.  if you are running a linux 
system then you have the capability of using different users
and groups to control file and directory access.  so you only
browse using one user and then set up a directory for that 
user to save files to and then put stuff there.  then you can
make that directory read only to a group and set up another
user to go look at the files saved there.  or something like
that...


  songbird

[toc] | [prev] | [next] | [standalone]

#244189

On Tue, 18 Jan 2022, at 04:51, songbird wrote:
> 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.
>
>   you are running the webpage on your browser so it is your
> own computer and your own program that is doing the accessing
> just like any other program you run.

The problem is that a user would normally only expect a browser to
save a file to the file-system in two cases:

(a) when the user has explcicitly chosen to download something, and 
   then chooses where to put it

(b) when the browser is cacheing content, or manipulating its own
  config files

In both those cases it's code written by the browser's developers 
that's doing the writing.

The new situation will allow any JS written by any page developer to
access my files.  I am unconvinced that this will never lead to malware
doing things to files/folders on my system without my knowledge.

It's a BIG change to users' expectations of what a browser can do.

Users with no technical knowledge could get bitten by this.


> what controls you wish
> to put on the access to your file system and how you do that
> is up to you and your own desires and capabilities.

I don't think it should be up to me.  I'd prefer to prohibit any JS 
in a browser from doing that.


> but what i do is set where files are saved in a
> specific directory and leave it at that

That works fine while you can be sure that a browser is only 
saving downloaded files.  What about when if can do anything
it likes to any file/folder?

-- 
Jeremy Nicoll - my opinions are my own.

[toc] | [prev] | [next] | [standalone]

#244197

On Tue 18 Jan 2022 at 14:46:48 (+0000), Jeremy Nicoll wrote:
> On Tue, 18 Jan 2022, at 04:51, songbird wrote:
> > 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.
> >
> >   you are running the webpage on your browser so it is your
> > own computer and your own program that is doing the accessing
> > just like any other program you run.
> 
> The problem is that a user would normally only expect a browser to
> save a file to the file-system in two cases:
> 
> (a) when the user has explcicitly chosen to download something, and 
>    then chooses where to put it
> 
> (b) when the browser is cacheing content, or manipulating its own
>   config files
> 
> In both those cases it's code written by the browser's developers 
> that's doing the writing.
> 
> The new situation will allow any JS written by any page developer to
> access my files.  I am unconvinced that this will never lead to malware
> doing things to files/folders on my system without my knowledge.
> 
> It's a BIG change to users' expectations of what a browser can do.
> 
> Users with no technical knowledge could get bitten by this.
> 
> > what controls you wish
> > to put on the access to your file system and how you do that
> > is up to you and your own desires and capabilities.
> 
> I don't think it should be up to me.  I'd prefer to prohibit any JS 
> in a browser from doing that.
> 
> > but what i do is set where files are saved in a
> > specific directory and leave it at that
> 
> That works fine while you can be sure that a browser is only 
> saving downloaded files.  What about when if can do anything
> it likes to any file/folder?

Songbird went on to say:

> > if you are running a linux 
> > system then you have the capability of using different users
> > and groups to control file and directory access.  so you only
> > browse using one user and then set up a directory for that 
> > user to save files to and then put stuff there.  then you can
> > make that directory read only to a group and set up another
> > user to go look at the files saved there.  or something like
> > that...

… which is what I do: user "flash" browses all except a few
trusted sites. I can read flash's ~/PDF/, downloads and browser
cache, and after a minute, I own the first two categories,
thanks to cron.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#244198

Jeremy Nicoll wrote:
> songbird wrote:
...
>> but what i do is set where files are saved in a
>> specific directory and leave it at that
>
> That works fine while you can be sure that a browser is only 
> saving downloaded files.  What about when if can do anything
> it likes to any file/folder?

  i'm trusting the developers of the browser just like
everyone else who uses it.

  javascript has always been an issue, i don't see that
changing.  if you are paranoid about that kind of access
then the OS does let you set things up to be doubly sure
(different users and groups) and there are even security
protocols that go even further.  i don't bother with 
them.

  Debian itself is also another web of trust that us 
users rely upon.  i consider it similar enough to what 
happens at firefox devs that i don't really worry about
it.


  songbird

[toc] | [prev] | [next] | [standalone]

#244203

On 2022-01-18 11:23:14 -0500, songbird wrote:
> Jeremy Nicoll wrote:
> > songbird wrote:
> ...
> >> but what i do is set where files are saved in a
> >> specific directory and leave it at that
> >
> > That works fine while you can be sure that a browser is only 
> > saving downloaded files.  What about when if can do anything
> > it likes to any file/folder?
> 
>   i'm trusting the developers of the browser just like
> everyone else who uses it.

The main issue is security bugs.

>   javascript has always been an issue, i don't see that
> changing.  if you are paranoid about that kind of access
> then the OS does let you set things up to be doubly sure
> (different users and groups) and there are even security
> protocols that go even further.  i don't bother with 
> them.

I systematically run firefox in firejail.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#244211

On 2022-01-18, Jeremy Nicoll <jn.ml.dbn.25@letterboxes.org> wrote:
>
> The problem is that a user would normally only expect a browser to
> save a file to the file-system in two cases:
>
> (a) when the user has explcicitly chosen to download something, and 
>    then chooses where to put it
>
> (b) when the browser is cacheing content, or manipulating its own
>   config files
>

And (c) as in cookies, of course.

[toc] | [prev] | [next] | [standalone]

#244196

[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

[toc] | [prev] | [next] | [standalone]

#244199

On Tue, 18 Jan 2022, at 16:35, The Wanderer wrote:

> 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'd expect malware using this mechanism to put forward a "plausible"
reason why a naive user should select an unsafe directory, rather than
a downloads one.


>> 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.

And that opens up the scourge of malware that correctly identifies what
software one has installed, and/or aspects of its configuration, just based
on what files/folders exist.

-- 
Jeremy Nicoll - my opinions are my own.

[toc] | [prev] | [next] | [standalone]

#244256

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

On Ma, 18 ian 22, 11:35:04, The Wanderer wrote:
> 
> 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.

This reminds me of 

https://arstechnica.com/gadgets/2021/07/separate-eop-flaws-let-hackers-gain-full-control-of-windows-and-linux-systems/

(the second part, with the Linux vulnerability)

Letting some random site have access to local storage seems like a Very 
Bad Idea.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web