Re: SourceXchange wish

James Salsman <j.salsman@bovik.org> wrote:

> I've put a corresponding wish up on SourceXchange:
>   http://www.sourcexchange.com/WishDetail?wishID=227
> Anybody who would like to sponsor this development should please 
> submit an official SourceXchange RFP and/or comment the wish.

Looks good. Only problem is that it doesn't state which platform(s)
the feature needs to work on, or whether it means just general core
support for having extra button(s) there that launch something to
capture input. Microphone input would need drivers for the Windows
WAVE API, OSS/Free, whatever the Mac uses, and so on.

(RISC OS, of course, doesn't *have* a mic input API, so those
chaps from comp.sys.acorn who complained are probably a bit
stuffed anyway. Audio input cards were never really very popular
for some reason.)

> in pursuit of backward-compatibility it is best to emphasize
> compatibility over backwardness. If MSIE and NS stop interpreting
> ACCEPT as a filename pattern (which I hope they both already have;
> I haven't checked lately)

Well, neither developer.netscape.com nor msdn.microsoft.com
currently document ACCEPT as even existing; certainly I wasn't
aware of either browser using it as a filename match until you said
so. I don't know where/when this usage was documented, but
hopefully most web authors were, like me, unaware of it, making
usage of this "feature" low.

> Yes, Client-file-maxlength would be useful for an ultra-thin 
> client with limited buffer memory, for example a wireless phone 
> with only a few MB of recording RAM.

Yes, I understood that; I just couldn't see what the server might
usefully do with such information. Maybe it could offer to accept
chunks of audio at a time and then stick them back together; but
then, there'd probably be no reason not to also allow this
functionality for ultra-obese-clients too. (Not that I'm calling
current browsers fatties, obviously, for that would be rude.)

> All of these pie-in-the-sky features are distractions until the 
> basics are implemented on common browsers.

Fair enough then.

> And about the security considerations, lets just hope that 
> Java/J/ECMAscript and the DOMs aren't allowing write access to 
> the INPUT TYPE=FILE VALUE attributes and submitting forms by 
> themselves these days.

Luckily Microsoft and Netscape have indeed noticed this, and both
have made file input VALUE attributes read-only (you can write to
them but it fails silently). This is contrary to the documentation
at msdn.microsoft.com though. (Which says value and outerHTML are
both read/write.)

I think I've tested and ruled out most possible security problems
in Internet Explorer's file inputs, but to be honest the range
of methods and properties it exposes is so mind-bogglingly
complex that I can't say for sure. I'm slightly concerned that
IE 5.5's fireEvent method might be a problem if it can make
keypress events happen, but I haven't tried 5.5 so I wouldn't
know. I expect it's safe.

The nearest I can think of to a file-stealing exploit along these
lines is a label saying, "Type C:\Secret\file.txt into this
box little child" over a text box that when you click on, the
focus goes to a file input that has been positioned off-screen.
Everything you type into the file input box gets copied into the
text box on a poll event. This would only work if the user didn't
notice the lack of caret and was also thick. It's not a very
good exploit, is it?

-- 
Andrew Clover
Technical Support
1VALUE.com AG

Received on Monday, 3 April 2000 10:23:28 UTC