Re: Proposal for fixing race conditions

> You can always speculate about what types of mistakes and bugs could exist in a specific browser implementation.  But if you do find any issues which you do believe to be security related, please contact the individual browser vendors privately.  There is certainly nothing in the design which prevents a safe implementation.

That wasn't random speculation. I was pointing out places where someone looking to do a buffer overrun exploit might poke around just after reading the *spec*. I'm not a security expert, so at that level, yes, it is speculation. 

>  
> So, we ought to first take race conditions seriously and at least prove that they cannot cause serious harm before deciding they are not a problem in a design.
> 
> We have looked at it in quite some detail, and so far we believe we have a safe solution.

Glad to hear that and, as I said, I believe so as well. The thing with security issues is that a system is insecure unless proven otherwise and even then stuff breaks. In other words, the spec shouldn't *prevent* safe implementations. All this discussion about race conditions is moot if a) the spec guarantees correct audio output under known circumstances, though it might behave non-deterministically in others, and b) the only consequence of the racy API design is garbled audio.

-Kumar

On 18 Jul, 2013, at 11:28 PM, Chris Rogers <crogers@google.com> wrote:

> 
> 
> 
> On Thu, Jul 18, 2013 at 4:23 AM, Srikumar Karaikudi Subramanian <srikumarks@gmail.com> wrote:
>> You're simplifying my position a bit.  
> 
> Perhaps ...
> 
>> What I'm saying is there are no sensible or normal calling patterns where this type of race conditions is even a possibility.  As the API is designed and has been used for over 2 years, these calling patterns are not used and so simply are not an issue.  We do have substantial developer experience to support this view, and these developers come from a wide range of backgrounds and experience levels from complete novices playing with audio for the first time, all the way to seasoned professional audio developers.
> 
> 
> .. but the ignorability of nonsensical and abnormal calling patterns depends on the impact that any race condition possibility in the API can have. If, for example, they can be used to compromise the security of the browser sandbox, say, because these buffers are hooking into high priority scheduling at the OS level, then wouldn't it be worth making even compatibility breaking changes or taking some constant malloc+memcpy hits to solve that? So it does seem to me that the fact that such calling patterns cannot cause harm beyond garbled audio output is the key behind this argument. 
> 
> But Srikumar, we're currently talking about a situation which is not a security issue as you describe.  Unless you have very specific and concrete issues in that regard, please don't make such vague statements implying that kind of risk.  That's why I was saying that in the case where somebody does actually write some nonsensical code that there is little risk, other than the sound playing wrong.  In all of the APIs which exist today there are so many ways to write buggy JS/HTML/CSS code which will draw random pixels on the screen, send incorrect bytes to a server, layout divs badly on a page because of incorrect CSS, make incorrect assumptions about the order of event handlers, setTimeout, etc. getting called.  What we can do is teach best practices about using all of these APIs and spread that knowledge.
> 
> 
>  
> 
> The benign-ness of the current race conditions seems (to me) likely, since the lengths of ArrayBuffers cannot be changed. If their lengths can be changed, the current API might permit buffer overrun exploits (still only guessing here). Even if they can't be changed, there could exist small windows of vulnerability in an implementation where the length of an array is kept around while an updated pointer to the array data is taken. 
> 
> You can always speculate about what types of mistakes and bugs could exist in a specific browser implementation.  But if you do find any issues which you do believe to be security related, please contact the individual browser vendors privately.  There is certainly nothing in the design which prevents a safe implementation.
>  
> 
> So, we ought to first take race conditions seriously and at least prove that they cannot cause serious harm before deciding they are not a problem in a design.
> 
> We have looked at it in quite some detail, and so far we believe we have a safe solution.
>  
> Chris