Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On May 16, 2008, at 5:50 AM, Jon Barnett wrote:
On Thu, May 15, 2008 at 5:04 PM, Matthew Paul Thomas
[EMAIL PROTECTED] wrote:
...
Imagine further that this iPhone has no user-visible file system. It
stores music, but annoyingly, the device vendor doesn't want to let
people upload songs to Web sites. What the vendor *does* want to let
people do is upload photos to Web sites, so that they can use sites
like Flickr or even post photos to their Weblogs from the road.
So the iPhone vendor implements input type=file just for photos.
Is this the iphone's behavior? (earlier you said it doesn't implement
input type=file, but here you're saying it's implemented for photos)
No, this is a hypothetical scenario, but I think a highly realistic one.
It's rendered in a Web page as three components: (1) a button for
taking a new photo, (2) a button for choosing an existing photo, and
(3) a thumbnail of the selected photo. There's no filename: that
wouldn't make any sense, because device has no user-visible files.
The interface for choosing a file isn't particularly important. It's
the style/presentation of the button that triggers that interface
that's in question, or being able to create your own interface to
trigger that file-choosing interface.
So if an author said input[type=file]::button {width: 100px} (or
whatever the selector turned out to be), what should this device's
browser do? Style both of the buttons as 100px wide? Or both of them as
50px? Or ignore any width completely, on the grounds that the author
probably doesn't know what they're doing?
...
Sure, we agree that tricking a user into typing a filename is somewhat
of a security risk, and browsers have mitigated that. My point was
disguising the button that triggers the file-choosing dialog box (or
web-page-like interface, if you will) is NOT a security issue.
...
Agreed. My issue is not with its security, but with its
device-independence.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
Samuel Santos wrote: I don't think this is a valid argument since you can change it anyway [1]. [1] http://www.quirksmode.org/dom/inputfile.html I should note that some consider this a (low priority, low severity) security bug that should just be fixed (e.g. by disallowing opacity styling on file inputs or some such). -Boris
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On May 14, 2008, at 9:55 AM, Křištof Želechovski wrote: I do not feel like having the file submission control styled and customized in any way; submitting a file poses a serious security and privacy risk so I would not like to see this control disguised as something else. Just like an alert window title, it should have a consistent look for all applications. The WebKit file input control would, I think, be safe to style because it does not have a text field to type into, so no matter what it looks like the user has to actively choose a file from the file open dialog after clicking on it. The designs of most other browsers would be vulnerable to disguising it as something else though, if the user can be tricked into typing a file path. Regards, Maciej Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Samuel Santos Sent: Wednesday, May 14, 2008 6:38 PM To: WHATWG; HTMLWG Subject: Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface This issue seems to be a very recurring and still unsolved problem when dealing with Web internationalization / multi-language Web Apps. I would like to suggest this to be reviewed with an editor comment please. Additionally, it's important if we could decorate separately the file path text field and the browse button using CSS. Best reagards, Samuel Santos
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On Thu, May 15, 2008 at 1:23 AM, Boris Zbarsky [EMAIL PROTECTED] wrote: Samuel Santos wrote: I don't think this is a valid argument since you can change it anyway [1]. [1] http://www.quirksmode.org/dom/inputfile.html I should note that some consider this a (low priority, low severity) security bug that should just be fixed (e.g. by disallowing opacity styling on file inputs or some such). -Boris The Yahoo! UI toolkit [1] allows a developer to create a browse that looks like whatever he wants it to and can be controlled by javascript pretty much however he wants it to. Flickr uses this (you have no log in, so no link here). It also has more robust features than input type=file - the interface can have custom styles - the dialog can choose multiple files - the dialog can filter certain file types That Yahoo widget uses Flash and Javascript to make all that happen. Adobe isn't going to take this feature of Flash away (Javascript control of a file dialog) and I wouldn't expect browsers to try to block it. The W3C File Upload [2] draft allows for the something similar using plain javascript without the requirement for Flash, and there are already implementations in the wild. That's just a generic Javascript API - I can't imagine browsers trying to restrict how that looks on the page. Again, - the interface that have custom styles (anything with an onclick will do) - the dialog can choose multiple files These aren't features you're going to take away from today's users of popular web applications. Those features are here to stay. I don't see how customizing the look of the file dialog's button is a security risk. Sure, the button might say something malicious, but it still requires the user to browser his local files, choose a file, and click Open. One problem with either the Yahoo widget or the File Upload draft is that they both require Javascript to function. If you want these features to be accessible to non-Javascript enabled browsers, we'll need to include it in HTML. It would probably call for a new input type with a more specific, flexible presentation (i.e. just a button that can be styled with CSS) If Javascript is as an acceptable requirement, another problem with those solutions is that they require separate POSTs. The Yahoo uploader uses a separate request for each file. The File Upload API has functions like getDataAsHexBinary that, I guess, could put a file's data into a hidden input field, but that data still wouldn't be uploaded the same way regular input type=file is uploaded (as multipart/form-data with headers for each file, etc). It would be better for HTML to specify an accessible and clean way of styling buttons for producing file dialogs than to force Samuel Santos to use dirty CSS hacks, a proprietary tool, or an API that interfaces with HTML forms in a clunky way. [1] http://developer.yahoo.com/yui/uploader/ [2] http://www.w3.org/TR/file-upload/ -- Jon Barnett
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
Maciej Stachowiak wrote: On May 14, 2008, at 9:55 AM, Křištof Želechovski wrote: I do not feel like having the file submission control styled and customized in any way; submitting a file poses a serious security and privacy risk so I would not like to see this control disguised as something else. Just like an alert window title, it should have a consistent look for all applications. The WebKit file input control would, I think, be safe to style because it does not have a text field to type into, so no matter what it looks like the user has to actively choose a file from the file open dialog after clicking on it. The designs of most other browsers would be vulnerable to disguising it as something else though, if the user can be tricked into typing a file path. Because of this Firefox 3 does not allow typing filenames. If you click the input field it always brings up the file picker. / Jonas
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On Thu, May 15, 2008 at 5:04 PM, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Imagine that there is a popular mobile device with a Web browser. Imagine further that this browser is widely used, despite having no support for Flash, no support for W3C File Upload, and not even any support for input type=file. I know, I know, this seems unrealistic, because those features are here to stay, but humor me here for a moment. For ease of discussion, let's call this device the iPhone. Except for the needless sarcasm - we're on the same page here. Imagine further that this iPhone has no user-visible file system. It stores music, but annoyingly, the device vendor doesn't want to let people upload songs to Web sites. What the vendor *does* want to let people do is upload photos to Web sites, so that they can use sites like Flickr or even post photos to their Weblogs from the road. So the iPhone vendor implements input type=file just for photos. Is this the iphone's behavior? (earlier you said it doesn't implement input type=file, but here you're saying it's implemented for photos) It's rendered in a Web page as three components: (1) a button for taking a new photo, (2) a button for choosing an existing photo, and (3) a thumbnail of the selected photo. There's no filename: that wouldn't make any sense, because device has no user-visible files. The interface for choosing a file isn't particularly important. It's the style/presentation of the button that triggers that interface that's in question, or being able to create your own interface to trigger that file-choosing interface. It's a security risk in those browsers where input type=file contains an editable text field, because a page could trick you into typing the pathname of a confidential file into the field, and the button would no longer warn you that it wasn't an innocent text field. In browsers (such as Firefox 3, as Jonas just mentioned) where the field is not editable, the button is safer to style -- but if you're assuming the control contains only one button, you might produce ugly results on devices where it has more. Sure, we agree that tricking a user into typing a filename is somewhat of a security risk, and browsers have mitigated that. My point was disguising the button that triggers the file-choosing dialog box (or web-page-like interface, if you will) is NOT a security issue. It's very possible to create a custom interface for triggering that dialog, but all the solutions I know of are convoluted and don't interface well with web forms. For example, if I want just a plain blue, underlined link (a la Flickr, click here to upload your photos) to trigger that browse dialog, I have to use something like Yahoo's widget or the File Upload API. Or, I have to use CSS hacks that are probably going to look silly on an iPhone. I only have a couple possible solutions in mind: - Insist that input type=file always be rendered like input type=button and therefore can be styled as such. That's not such a great solution for lots of reasons. - Insist that the HTMLInputElement.click() method in Javascript trigger the UAs file-choosing dialog. I don't know any browsers that support that, you know, for security reasons - never mind that there are two other ways to already do that with Javascript today. That would require Javascript to function, but at least it degrades more gracefully than depending on Flash or the File Upload API just to have a custom button. The HTMLInputElement would stay intact, so you don't have to code two or three separate methods of handling file uploads (see my note about separate POST requests, etc.). Plus it would be more feasible on a device like the iPhone that may not support a whole new complex API (and may never get Flash). So, is there any reason for browsers to NOT support HTMLInputElement.click() to trigger a file dialog? Is it reasonable to insist that they do? Would that solve Samuel Santos' original concern for wanting a custom, localized button that says Upload a file in his site's native language? ... If Javascript is as an acceptable requirement, another problem with those solutions is that they require separate POSTs. The Yahoo uploader uses a separate request for each file. The File Upload API has functions like getDataAsHexBinary that, I guess, could put a file's data into a hidden input field, but that data still wouldn't be uploaded the same way regular input type=file is uploaded (as multipart/form-data with headers for each file, etc). ... Web Forms 2.0 already defines min= and max= attributes for this purpose. Thanks, I hadn't seen that. input type=file max=n where n is greater than 1 would allow for mutliple files. I hadn't seen that. -- Jon Barnett
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
I do not feel like having the file submission control styled and customized in any way; submitting a file poses a serious security and privacy risk so I would not like to see this control disguised as something else. Just like an alert window title, it should have a consistent look for all applications. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Samuel Santos Sent: Wednesday, May 14, 2008 6:38 PM To: WHATWG; HTMLWG Subject: Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface This issue seems to be a very recurring and still unsolved problem when dealing with Web internationalization / multi-language Web Apps. I would like to suggest this to be reviewed with an editor comment please. Additionally, it's important if we could decorate separately the file path text field and the browse button using CSS. Best reagards, Samuel Santos
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
I don't think this is a valid argument since you can change it anyway [1]. [1] http://www.quirksmode.org/dom/inputfile.html Samuel 2008/5/14 Křištof Želechovski [EMAIL PROTECTED]: I do not feel like having the file submission control styled and customized in any way; submitting a file poses a serious security and privacy risk so I would not like to see this control disguised as something else. Just like an alert window title, it should have a consistent look for all applications. Chris -Original Message- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Samuel Santos *Sent:* Wednesday, May 14, 2008 6:38 PM *To:* WHATWG; HTMLWG *Subject:* Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface This issue seems to be a very recurring and still unsolved problem when dealing with Web internationalization / multi-language Web Apps. I would like to suggest this to be reviewed with an editor comment please. Additionally, it's important if we could decorate separately the file path text field and the browse button using CSS. Best reagards, Samuel Santos -- Samuel Santos http://www.samaxes.com/
