Recommended Posts

I really don't think this is a good idea, to disable direct text input in the <input type="file"> input box, as a security "fix" against a theoretical attack. The reasoning is IMHO ridiculous, it's like saying to prevent potential phishing attacks, all text input box should be disabled. Or to prevent possible trojan downloads, file download should be disabled. The change is really annoying and a great usability drawback, especially when uploading multiple files at once. And it can be easily bypassed by truly malicious sites with flash, java applet, silverlight, etc. making this security "fix" mostly moot. And that's why Firefox 3 has anti-phishing and anti-malware features from the first place right?

Also I think there can be many better alternatives than just disabling the file input box and leaving a confusing interface, like disabling certain stylings of the file input control, gave warnings when there are file uploads to a site for the first time, etc.

Link to comment
https://www.neowin.net/forum/topic/644517-file-input-box-in-firefox-3/
Share on other sites

How is it not a reasonable security measure? And where is there a confusing interface now? If you've used a file open dialog, you know how to choose a file for upload.

The interface is confusing as there's a text input box, but when you click the input box, a file open dialog pops up, that goes against any user expectation of a text input box (or at least the appearance of one).

It's not a reasonable security measure because it outright disabled the text input function just because someone can custom style it to trick people into entering sensitive data. It's like saying, since someone can custom style a page to look like some online banking service and trick people into entering their bank account password into it (phishing), so we should outright disable direct text input in web pages? I think Firefox 3's anti-phishing and anti-malware features are added exactly to counter this kind of bad guys, so we don't need to disable text input or file download to prevent possible exploits from them.

And it's mostly a moot security measure since real malicious people can bypass it easily. So Firefox 3 tried to fix a theoretical security hole (and this "fix" can be bypassed easily) by completely altering the expected behavior of the file input box that leads to great usability problems and resulting in a completely non-sensical UI (a text input box that functions like a button). And this same "security hole" can be fixed with far less drastic means. I don't think this is a good idea IMHO.

And people are allowed to turn the Anti-Phishing and Anti-Malware features off in Firefox3, but there's no option to turn the file input box back on? I'd say that makes little sense.

Safari doesn't even have a text field with a file form element.

yea, and Safari didn't even have a download confirmation dialog (until they just fix it in 3.1.2). It's from Apple, so I guess it's expected to have some great neat features accompanied by some really strange weird usability problems and/or quirks. But then at least Safari's implementation doesn't show a text input box, thus less confusing.

The real problem for me is that Firefox 3 file inputs only seem to return the file name, not the full path.

This is different from Firefox 2 and with Internet Explorer when working from the same 'URL security zone' (see http://msdn.microsoft.com/en-us/library/ms535128.aspx).

See www.samdutton.com/firefox.html for an example.

The reason they've done this, is so you can't hide the button via CSS and trick people into thinking it's a normal text-box (so you can upload files on their system without them knowing it).

People whined and bitched at Safari for doing the same thing.

There is a work around for it: http://damnmachine.com/128/fx3_upload-fix.html

well, "drag n' drop" doesn't help the situation much, since one still can't just copy&paste multiple file names without the file browser popping up repeatedly, a real usability drawback with multiple file uploads.

The reason they've done this, is so you can't hide the button via CSS and trick people into thinking it's a normal text-box (so you can upload files on their system without them knowing it).

well, by the same logic, to prevent phishing, they should disable all input box by default, and enable them only after you have scanned through the whole URL with the mouse pointer or cursor keys.

really, there are much better ways to deal with this potential "security hole", without drastically changing the behavior of the file input box and ending up with a confusing UI.

But then people can be tricked into uploading files with a simple flash form anyway.

People whined and bitched at Safari for doing the same thing.

Apparently they still need to whine and bitch some more to make Apple add an option to prompt before saving files in the Mac OS X version :laugh:

The file selector uploads files, it isn't comparable to a plain text box, I don't see why you're even using that argument.

And just because there are multiple ways to do it (like through Flash), doesn't mean we shouldn't bother fixing any of them ("I was going to lock my door, but then I noticed my window was open, so I left my door unlocked").

The file selector uploads files, it isn't comparable to a plain text box, I don't see why you're even using that argument.

It's changing the behavior of the file input box drastically, so it's very comparable to drastically changing the behavior of the plain text box for some potential exploits.

A site exploiting the file input box to trick you into uploading files in disguise of a normal text input is comparable to a site exploiting the password text input to trick you into entering your password in disguise of an online banking site. So Firefox "fixing" the file input box by completely disabling the text input, it's indeed comparable to "fixing" the password text box by requiring you first scan through the URL to prevent phishing.

They are both examples of over-reactions against some "security holes", one is already implemented in Firefox 3, the other hypothetical, but both are at the same level of absurdity, both are "let's fix a security hole by a drastic measure that greatly reduces the usability, while other much less drastic and more user-friendly alternatives are clearly available". That's why I'm using this argument. There's no good reason behind this file input "fix", just like there'd be no good reason to disable password input box until a full scan of URL.

And just because there are multiple ways to do it (like through Flash), doesn't mean we shouldn't bother fixing any of them ("I was going to lock my door, but then I noticed my window was open, so I left my door unlocked").

The point is that such drastic "fix" leads to great usability problems, in the name of "fixing" a "security hole" which it doesn't patch up anyway. It's like giving your door a complex lock that takes hours to open, but leaving the windows with a normal lock, so the legal inhabitants of the house has to spend hours to enter their own home, while a real thief can still enter the house easily under minutes, is just not logical.

Not to mention when they have enforced such drastical measures against the file input box with no option to turn it off, but give easy options to turn off the anti-phishing and anti-malware features, it's simply ridiculous and shows a severe lack of consistency in their logic and reasoning regarding "security".

This new text box drove me CRAZY. I couldn't take it one more minute so now I use IE (ugh) when I'm doing a lot of uploads or other such activities.

At work I upload updated data files to various websites, ours and our clients', so there are endless variations of the same bunch of data. I might need to import a set of 5 files in 3 or 4 different formats (ex: NewData1.csv, NewData2.csv; NewData1.txt, NewData2.txt, etc.) to 9 different websites.

Before this crappy new feature ruined my life, I was able to browse for the first file, then copy and paste the path/filename into the other admin pages, and THEN simply change a number in the filename and click import to upload the next file. Now with copy/paste and editing disabled I have to browse through dozens or hundreds of files and click the file I need every single time, over and over and over and over and over and over. It's a MAJOR pain. I broke up the dir with hundreds of data files, then I made separate "recent ULs" dirs, but with so many formats that filled up too, so then I was constantly shifting files into old, new, staging, recent (and onandonandon) directories, trying other things to make life easier. By the time I got to making "AAADataFile6.csv", then renaming it after the upload, I realized I'd gone off the deep end and was going to need to check into a rest home. I wised up and dusted off my IE icon.

I haven't had IE visible on my desktop in years, but now there it is in all it's glory. I hope the FF developers that came up with this garbage feature are proud of themselves.

I hate, hate hate that new feature.

It's changing the behavior of the file input box drastically, so it's very comparable to drastically changing the behavior of the plain text box for some potential exploits.

A site exploiting the file input box to trick you into uploading files in disguise of a normal text input is comparable to a site exploiting the password text input to trick you into entering your password in disguise of an online banking site. So Firefox "fixing" the file input box by completely disabling the text input, it's indeed comparable to "fixing" the password text box by requiring you first scan through the URL to prevent phishing.

They are both examples of over-reactions against some "security holes", one is already implemented in Firefox 3, the other hypothetical, but both are at the same level of absurdity, both are "let's fix a security hole by a drastic measure that greatly reduces the usability, while other much less drastic and more user-friendly alternatives are clearly available". That's why I'm using this argument. There's no good reason behind this file input "fix", just like there'd be no good reason to disable password input box until a full scan of URL.

The point is that such drastic "fix" leads to great usability problems, in the name of "fixing" a "security hole" which it doesn't patch up anyway. It's like giving your door a complex lock that takes hours to open, but leaving the windows with a normal lock, so the legal inhabitants of the house has to spend hours to enter their own home, while a real thief can still enter the house easily under minutes, is just not logical.

Not to mention when they have enforced such drastical measures against the file input box with no option to turn it off, but give easy options to turn off the anti-phishing and anti-malware features, it's simply ridiculous and shows a severe lack of consistency in their logic and reasoning regarding "security".

Can you explain to me exactly what has your panties in a twist? Like what action I need to take to duplicate the behaviour this non-issue fix, as you call it?

Can you explain to me exactly what has your panties in a twist? Like what action I need to take to duplicate the behaviour this non-issue fix, as you call it?

can you explain to me exactly what you mean by this? I think I've already stated quite clearly what this so-called "security fix" affects, the file input box, ie. any <input type=file> HTML control.

if you want an example, then just go to http://xs.to and click the input box before the "Choose..." button.

Can you explain to me exactly what has your panties in a twist? Like what action I need to take to duplicate the behaviour this non-issue fix, as you call it?

Well, did you read my post (right before yours)?? You just TRY selecting 10-20 files and see how long it takes in FF as opposed to IE or the old FF, where you can copy and paste, or [heaven forbid!] actually TYPE a path/filename.

In the new FF, at least 5-10 seconds each. 20 files with dir browsing is well over 3 mins, just to select the files.

In old FF or IE, it takes as long as you need to go to the next tab, click the box, and hit CRTL-V. Less than 2 secs, all 20 files ready for upload in less than a minute. Less than ONE THIRD the time.

And, yes, 3 mins is a big deal. It means just one of my tasks takes 3x longer than necessary. 3 mins or 3 hours, it adds up.

  • 2 weeks later...
Well, did you read my post (right before yours)?? You just TRY selecting 10-20 files and see how long it takes in FF as opposed to IE or the old FF, where you can copy and paste, or [heaven forbid!] actually TYPE a path/filename.

You know you can type paths in the file upload dialog box, right? What's the difference? You click in the upload field in Fx3 (like you would anyway to make the cursor go there). and you paste the path in the File Name line.

The time you waste opening multiple tabs and hitting Upload multiple times is a saver to you?

can you explain to me exactly what you mean by this? I think I've already stated quite clearly what this so-called "security fix" affects, the file input box, ie. any <input type=file> HTML control.

if you want an example, then just go to http://xs.to and click the input box before the "Choose..." button.

It does the same as if you hit the browse button. What is the big deal?

  • 4 weeks later...
You know you can type paths in the file upload dialog box, right? What's the difference? You click in the upload field in Fx3 (like you would anyway to make the cursor go there). and you paste the path in the File Name line.

The time you waste opening multiple tabs and hitting Upload multiple times is a saver to you?

Another problem with this "feature": because you can not edit in the text box, it is IMPOSSIBLE to remove a file once it's in there. I selected a file and then made a lot of edits on the page. Then I decided that I didn't want to replace the file on the server, but there was NO WAY to remove the contents of that box. I had to cancel the entire transaction.

THIS can not be fixed by pasting into the File Open dialog box.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Windows Server gets DNS over HTTPS (DoH) support by Usama Jawad For the past few months, Microsoft has been previewing DNS over HTTPS (DoH) for Windows DNS Server, touting it as a foundational upgrade for zero-trust enterprise networks. It essentially introduces encrypted, authenticated DNS for the networks rather than transmitting DNS traffic in clear. Now, the company has introduced the general availability (GA) of this feature. The GA of DoH encourages organizations to deploy the solution in production environments without implementing a new client-to-resolver architecture. DoH helps improve the overall security of the network and reduces the risk of spoofing due to its zero-trust design. This is a significant change because pretty much every interaction with the network requires interfacing with DNS. DoH offers several advantages over standard DNS traffic, such as encryption using HTTPS, preventing unauthorized inspection, man-in-the-middle attacks, and traffic analysis. Since it leverages TLS certificates so that clients can verify the identity of the DNS server, it prevents spoofing through this authentication mechanism. Additionally, it's built on the DoH standard defined by the Internet Engineering Task Force (IETF), which means that it should work with modern RFC 8484-compliant clients. Finally, it integrates into the existing network architecture seamlessly and can even run in parallel with standard DNS, so that customers can migrate to the new technology at their own pace. Microsoft says that in the past few months of preview, DoH has become more stable, and customers can confidently deploy it in production environments with proper guidance. Microsoft has emphasized that migrating to DoH is necessary for organizations that are moving toward zero-trust DNS solutions. Windows clients already support DoH, but the latest availability on Windows Server provides encrypted DNS to all endpoints. The company has also mentioned that "while this release focuses on encrypting client-to-resolver communication, support for encrypted communication between Windows DNS Server and upstream DNS resolvers is planned for a future update." You can follow Microsoft's guidance to deploy DoH here, but keep in mind that you need a Windows Server 2025 installation with the latest Patch Tuesday updates installed.
    • Lol I had one of these turn faulty in Jan, guess it wasn't just bad luck lol
    • I'm team Rossmann all the way. I have the exact same NVME, altough not in an array like him.
    • It had gone weeks ago. Although thinking about it I'm on the beta.
    • They thought value of their goods would forever only drop like it used to and didn't account for sudden increase in price because of all the Ai hype. Tough luck Samsung, don't try to weasel this one out. Also American customer protection laws are a**. In Europe, you need to be compensated for a functioning product of same or better characteristics (not same price point as when it was originally bought!) if it can't be repaired and when you receive a replacement product your warranty starts from scratch because you received a different item than you previously had and old warranty thus cannot apply to it anymore. If your actual item was successfully repaired, warranty gets extended for the period the item was in service. If item is repaired to a significant extent, warranty also starts over from scratch because major part of it was replaced. Americans need to fight to get this kind of consumer protections because they are constantly getting screwed over.
  • Recent Achievements

    • Week One Done
      davidbazooked earned a badge
      Week One Done
    • One Month Later
      Jamswaz earned a badge
      One Month Later
    • Week One Done
      Jamswaz earned a badge
      Week One Done
    • Rookie
      Marzoid went up a rank
      Rookie
    • Community Regular
      coch went up a rank
      Community Regular
  • Popular Contributors

    1. 1
      +primortal
      511
    2. 2
      PsYcHoKiLLa
      184
    3. 3
      +Edouard
      159
    4. 4
      Steven P.
      83
    5. 5
      ATLien_0
      75
  • Tell a friend

    Love Neowin? Tell a friend!