I'm going to suggest dev-tech-network is the wrong level to be making this decision. (Ironic, I know - I'm always pushing stuff at d.t.n).
But in this case this should be decision driven, imo, by the product teams (performance regression!) and the privacy teams. They are in the position to manage the tradeoff. If they come to a conclusion that this should be done if the hit is within some cost boundary then d.t.n seems like the right place to work on making that happen, fill out a product feature, etc.. I would ask those teams to really consider, at least in the initial pass, the question of "how much of a performance hit is this worth to you upfront" rather than punting it back and saying "how much would this cost?". On Tue, 2012-02-28 at 21:56 -0800, Zack Weinberg wrote: > On 2012-02-28 4:06 PM, Brian Smith wrote: > > Henri Sivonen wrote: > >> Are there any plans to include the referring origin in the cache > >> key to address the cache probing history leak that was demoed at > >> http://lcamtuf.coredump.cx/cachetime/ ? > > > > There is no plan. I suggestion you file a bug (if there isn't one > > already). > > Please cc: me on the bug. I may be able to help and/or scare up some > student help. > > > It would be tricky to do, as we would have to avoid major > > performance regressions by doing so. > > To some extent it *has* to regress performance, because this is a timing > attack: when the attack site tries to iframe something, it has to > *appear* to not be in the cache, even if it is, and that means delaying > the load. > > I have no idea whether this is feasible with our cache architecture, but > in principle it would be possible to record the original load time for > each cached item. Then, when we see one of these cross-domain loads > that has to appear to be a miss, we could delay the load for that much > time (with some randomization) but not actually hit the network. That > might mitigate secondary performance hits from having to waste a network > channel on stuff we already have but can't admit to having. On the > other hand, an even sneakier attacker might be able to find a way to > detect *this* behavior... but that's the arms race for ya. > > zw > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
