> Although I illustrated the non-overt channel here as a covert channel in a 
> possibly failed attempt at clarity, my real point and my real worry is about 
> its use as a side channel. As a side channel, this ability to sense the 
> collection of individual objects is much more informative than anything I 
> know of in current JS. If anyone knows of any side channels that seem as bad, 
> perhaps I've overlooked them, so please post. If they also seem unpluggable, 
> then I would agree that my position here becomes pointless and we'd need to 
> give on resisting side channels as well.
> 


Off the top of my head:

1) Does ES5 fully freeze the global / root protos / etc. or allow a way to call 
function without them? Taint can show up through here.

2) Even with frozen APIs, do we acknowledge timing attacks? Out-of-memory, 
non-termination, and other platform exception tricks? 

3) Sniffing is already ubiquitous in terms of language / host API variants

Stepping back, I'm not even sure precisely why gc status classifies as a side 
channel. First, when passing references, defensive coders must already consider 
non-local properties to protect against memory leaks: gc state should, 
arguably,  already be carefully thought about when dealing with components. 
Second, this seems somewhat close to a transient resource reification pattern 
where it's use as explicit communication seems fine: you check against what the 
system has reclaimed, etc.**

Lest anyone misunderstands, I actually do agree that it's suspicious if you do 
not consider coding wrt to gc as being natural. Making the intended threat 
model to protect against more precise would help me at least. For example, it 
could answer why the ability to check whether an object has been collected is 
not an overt channel that is part of getting a reference: if you don't want 
somebody to check, don't give them the object.


**having overidable object destructors are probably a cleaner alternative in 
most cases for this second use




_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to