Re: comments on draft-barth-mime-sniffing

Joe >> Given that I am looking at it from an author side, how about if 
the
>> current browsing context or whatever higher order process does the 
>> top-level sniffing before it goes to the renderer
>
Boris > To which renderer?

sorry, in the case of <audio> it would be whatever derives what is 
supposed to drive the speakers.
There, I meant renderer to mean the player or whatever that friendly 
thing behind the <audio> element is: the thingee that plays me.ogg and 
knows literallyl nothing else about anything but .ogg and .wav.:)

>> is called the UA, which contains a nested browsing context.<video> 
>> or <audio> element. So in these cases I will call the browser the 
>> host UA and the <video> element the home of the handler which 
>> actually does the rendering.
>
> OK...  I'm not sure how you're separating these, exactly, but under 
> hte only reasonable split that comes to mind for me (the UA is what 
> fetches the data while the handler is what actually renders it), you 
> need to know what kind of data you have so you can select the right 
> handler. Agreed, or not?  If not, is the problem one of disagreement 
> on the definitions, or on the conclusion?

No, in my little fantasy of this case, there is only one renderer for 
.ogg and .wav and that is all the host browser knows about for 
<audio>. There is no choice, If I <audio my.ogg> all I care about is 
that the host browser picks the 'built-in'  or native one that only 
knows about these file types.

>> I would like to say that data-sniffing is not needed. Can the 
>> target files contain any security problems?
>
> The target files (assuming you mean the <video> and <audio> data the 
> server is sending) are always assumed to be malicious and trying to 
> exploit the UA or the renderer to gain access to the user's system.

What can me.ogg do to corrupt the system using the simple native 
player. ogg or .wav does not have and active form, I think.

>> I don't think you will find a MIME string in there unless specially 
>> authored into the file.
>
> Of course not.  Data sniffing doesn't look for MIME strings; it 
> looks for initial bytes identifying the file type.  Many common file 
> types must start with a particular byte sequence.

'I see in the general sniffing algoritm that the file is read to look 
for the internal contenttype in the header. If it finds this, then 
that is the mime.

Yes, you can find the data structures in the detailed specs for the 
streams but lookie here mr browser maker, I don't want to fool with 
all that stuff. I put me.ogg out there on my server somehow and then I 
have an HTML 5 web page that says play what I put out there, please. 
The browser should let this happen with  no built-in security or other 
delays except perhaps some user preferrence settings about multiple 
media, on the level of a show images choice somdwhere.

And even that is OK as long as you give me me fallback content while 
you are asking questions.

>> The author should include both the mime and the target url in the 
>> element.
>
> Actually, no.  The author can just include the target url in the 
> <video>.  If using a <source> element, a type hint 
> (non-authoritative) can be provided; this is to be used only for 
> deciding whether to load the <source> at all, not for what to do 
> with it after loading it.

Oh, I will look at that. If type is there, that should be clue enough 
to start the player and start fetching the content

There should be no choice. <video> might be a bit different than 
<audio> although I better look more closly because why aren't they the 
same?
but ok.
Anyway, the correct thing to do is for the host browser not to worry 
about it all. Just send the url to the player behind the <audio> or 
<video> element and let it figure it out and when it is ready, let it 
ask you for the content by url and really, just let the handler deal 
witht the loading. I would hope the host has better things to do than 
spoonfeed content to the audio or video handler.

>
>> If the type and file extension do not match the content model for 
>> the element then fallback.
>
> Uh... What content model?  And how did extension come in?  Extension 
> is not a reliable indicator of type; the mapping from types to 
> extensions is many-to-many...

'OK, let's make it like that in the spec. Right now are listing the 
acceptable file types identified mainly by file extension. Maybe 
listing MIME first, then. But heck as I see the web from my text 
editor, I know I must know about file extensions first. I see a list 
of allowable ones and I use those. If you tell me the mime type, I 
will use that also. But really, I mainly gotta care about the file 
extension first.

>
>> At this time it is (may not) not reliable to rely upon the served 
>> ContentType so this cannot be used to reject the file.
>
> On the contrary, we should in fact be relying on the served 
> Content-Type.  Anything else means the server has no control over 
> how we handle the content, which can be a huge security problem for 
> the server...

That is very enlightened and forward looking. However in this case 
where all I want to do is play me.ogg I don't really care about all 
that. I know what I put out there. Trust me.
Anyway, with these file extensions, what is the problem? If I can feed 
some string of bits from me.ogg after using an appropriate MIME in my 
user code and and a retrievable file of me.ogg data from the server 
with whatever contenttype and feed it directly to the hanler for 
<audio> element and cause a problem then the problem is not mine, but 
the browser makers who hasn't given me a safe place to play me.ogg.

>> Data-sniffing of file internal structures by the UA could take 
>> place, but I don't think this would give the "standard" handler any 
>> additional info.
>
> Sure it would.  It'd tell it which of a number of container formats 
> or codecs is being used, if done correctly.

OK, I must step back a notch and focus just on <audio>.
No problem for audio, right. Send the url or the file content as 
instructed in the user code no sniffing needed because we trust the 
author to have done the right thing. Aftera ll, it must have worked at 
home, so it must be OK out there in the WWW.

For <video> there are also a few specifc forms that we will allow, but 
we just don't know them now. In the greater scope than <video>. LIke 
when I open to all the big wonderful world, then yes there are alot of 
formats out there and some that can be dangerous.

>
>> Literally, the handler should be able to handle any .wav or .ogg 
>> spec files.
>
> That's not very reasonable for .wav (see the earlier mention in this 
> thread of the number of diffever WAVE codecs out there).  And it's 
> completely unreasonable for .ogg, since that's just a container 
> indicator.  Anyone can make up a new codec and stick it in a .ogg.

I willhave to look at that in more detail. Are you saying there are 
.wev files out there that this simple player is not going to play. 
Please show me.

As for the ogg, I will look more closely at that one.

However, in either of these, there is nothing that would give the 
player the idea that there was some script it was supposed to execute 
or anything wlse hazardous.

>> The handler may need to do some data-sniffing to get set up. but 
>> all it needs from the UA is the content.
>
> I think you're drawing the line between "handler" and "UA" very 
> arbitrarily here... and I can't tell exactly where you're doing it. 
> Can we please define _very_ clearly where the line is being drawn?

For me it is easy to draw the line: I'm just the simple little <audio> 
player. I know I don't do much, but give me a chance. Host, get out of 
the way and let me do it.
For these file types, give me the bits straight for the server as fast 
as you can and I will handle it.

>> Again, the load on the author should be no more than getting the 
>> type and file name correct for the element and it should just work.
>
> The load on the author should be pointing to the right URI; after 
> that it should Just Work assuming the server and UA don't screw up.
>

Great. But how is the server going to screw it up. I ask for the file 
and he sends it, but uhoh he sends the wrong contenttype. Maybe not, 
maybe he is up to date or the webmaster has used .htaccess corretly. 
For <audio> why do I care?


>>> 2) Sniffing the file extension instead of the content 
>>> significantly complicates server-side solutions that, say, send 
>>> different content based on query params in the URL.  Of course 
>>> these should arguably send a Content-Type header anyway.
>>
>> The file is there with the right extension but maybe I can't get 
>> control of the server
>
> Sorry, then you have a buggy server.

Sorry, I don't. My htaccess is just fine, thank you. Somebody else may 
be torched because the mime has not passed ietf or whoever and/or the 
server has not been updated. Do I gotta take the wrap for that?

>
>> and its defaults are not sufficient for the UA sniffer (like maybe 
>> I can't use htaccess).
>
> Again, sounds like you have a buggy server.

I will ask more nicely, then.

>> Is my document success going to depend on the fact that the server 
>> must be configured to send the specified MIME?
>
> Yes.  It generally is already; why should this case be different?

If it was, you wouldn't need to sniff for that. Sure, as we see, 
mostly a user can manage to get .html served correctly as text/html or 
whatever the recommendation.

>
>> If it is served wrong or even absent a MIME am I going to be saved 
>> by the UA data-sniffing to figure out that the misserved file is 
>> really OK?
>
> Under the current proposal, no.  If it's served wrong or with no 
> MIME type, you will get no video.  Then you will realize that you 
> need to fix your server setup.

Maybe I will be luckler with <audio> and you won't try to oursmart me 
as a author and user.
But how do I fix my server?

I pick a file extension, like .x3d for instance, then I tell my server 
(maybe via .htaccess) to serve that file extension as model/x3d+xml.
Simple but effective and sure there are other ways to do it by 
standadrd bulletin from ietf but that is it. You figure out and 
designate which file extension you want to seved with which MIME.

Why not fix that in the host browser by me telling it that if you see 
a .x3d always treat it as being served as model/x3d+xml. Well, I 
already can sort of do that in some browsers. But really, from the 
server, as far as I know, it keys on file extension. Sure there are 
some fancy extensionless negotiation concepts out there, but that is 
complex stuff and this is easy.

>>> say, send different content based on query params in the URL.
>>
>> Are we going to see this with these elements?
>
> I don't see why not.  We see it all the time now with objects, 
> iframes, etc...

Some of those may be fallback content, or the <audio> may be fallback 
content for object to get audio playing that wouldn't in an object 
that asked for "house player" (not the <audio> player because the UA 
did so much sniffing to protext the house player that it wouldn't go. 
Now, for the fallback, we pick the simple littl ogg/wav player that 
always just works because I tested it at home and it worked so it must 
be ok out there on the World Wild Web.

>
>> We have already negotiated the content model down to a simple set. 
>> Many times those query forms are built from scripts that have 
>> determined or are determining some client capabilites?
>
> No, often enough they're just built from web pages that give the 
> user a list of choices and ask him to pick one, then just have one 
> script on the server that reads the data from somewhere (database, 
> filesystem, whatever) and returns it.

Well, I think when you ask the sever for what to send, you will ask 
something in a way that ends up with a file name and certain 
extension. Then, once the server knows what file it is going to send, 
it looks up the mime that is supposed to be in the head stuffs.

But even so, I don't think you are going to have success with that 
scale of use for these simple elements. What you describe will work I 
guess, but that sort of more side open stuff may work better with 
<object> and a more full-featured player.

>
>> The application and content types of these elements seems quite 
>> clear as defined by the keystrokes that actually appear in the 
>> element code at run time. .
>
> I have no idea what you're trying to say here.

Basically, please give me what I am asking for.
A simple way to play <audio> and <video> from a very limited list of 
input fomats. I shouldn' have to promise not to break anything because 
they should be bulletproof if the file is within the specs.

>
> -Boris

Thanks, Boris,
Joe

Received on Friday, 19 June 2009 01:53:58 UTC