@Ian, is there a way to find out what was the Content-Type that the authors
that complained were getting?

Hopefully we can figure out a list of Content-Types that are unlikely to
cause security problems?

On Tue, May 13, 2014 at 8:32 PM, Eduardo' Vela" <Nava> <e...@google.com>wrote:

> So today, we need CT for JSONP and CSV. Those are the ones we *need* CT.
> The idea is to train the browser to recognize the CTs of formats that are
> ambiguous.
> On Tue, May 13, 2014 at 8:26 PM, Michal Zalewski <lcam...@coredump.cx>wrote:
>> > I think that's Ian's point, that for those file types, we need CT, but
>> for
>> > others, like manifest files, and image and plugins we shouldn't need.
>> If we take this route, I think we'd be essentially making sure that
>> many web applications that are safe today will gradually acquire new
>> security bugs out of the blue as the UA "magic signature" detection
>> logic is extended in the future (as it inevitably will - to account
>> for new plugins, new formats with scripting capabilities or other
>> interesting side effects, etc).
>> An out-of-band signalling mechanism has far superior security
>> properties compares to an in-band one, given how many if not most web
>> apps are designed today. It may be that they are designed the "wrong"
>> way, but the security rules were never particularly clear, and serving
>> content off-domain added a lot of complexity around topics such as
>> auth, so I think it's best to be forgiving and accommodate that. The
>> examples of CSV exports, text documents, and several more exotic
>> things aside, most JSONP APIs give the attacker broad control over the
>> first few bytes of the response.
>> /mz

Reply via email to