On Tue, 13 May 2014, Eduardo Vela wrote:
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
What about X-Content-Type-Options: nosniff?
Could we formalize it and remove the X and disable sniffing all
together?
Do you mean for manifests specifically, or more generally?
I agree
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote:
On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch wrote:
Note that there _is_ still a content type check with appcache, it's
just done on the first few bytes of the file instead of on the
metadata. (This is IMHO how all file
Yup, from the perspective of a significant proportion of modern
websites, MIME sniffing would be almost certainly a disaster.
I'm not suggesting sniffing, I'm suggesting having a single well-defined
algorithm with well-defined fixed signatures.
For formats that don't have signatures, this
We probably can't support a well-defined algorithm for detecting
documents that have distinctive signatures while safely supporting
formats that don't have them (because there is always a possibility
that the non-structured format with user-controlled data could be used
to forge a signature).
On Tue, 13 May 2014, Michal Zalewski wrote:
We probably can't support a well-defined algorithm for detecting
documents that have distinctive signatures while safely supporting
formats that don't have them (because there is always a possibility that
the non-structured format with
On Tue, May 13, 2014 at 9:38 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote:
On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch wrote:
Note that there _is_ still a content type check with appcache, it's
just done on the first few bytes of
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
I agree that you're less likely to be able to control the headers. But
I don't think that's enough. A big part of the reason that authors
find it hard to set HTTP headers is that doing so is technically
complicated, not that it's
Thanks!
Just to ensure this wasn't lost in the thread.
What about X-Content-Type-Options: nosniff?
Could we formalize it and remove the X and disable sniffing all together?
On Tue, May 13, 2014 at 12:06 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
(for context [tests]
http://philip.html5.org/tests/ie8/cases/content-type-nosniff.html)
On 13 May 2014 17:38, Ian Hickson i...@hixie.ch wrote:
Are the lessons learnt here being reported to the Service Worker team?
Yes, I've been discussing this with them in
https://github.com/slightlyoff/ServiceWorker/issues/224 and
https://github.com/slightlyoff/ServiceWorker/issues/253, which
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
Thanks!
Just to ensure this wasn't lost in the thread.
What about X-Content-Type-Options: nosniff?
Could we formalize it and remove the X and disable sniffing all
together?
Do you mean for manifests specifically, or more generally?
For
On Tue, May 13, 2014 at 1:06 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
Thanks!
Just to ensure this wasn't lost in the thread.
What about X-Content-Type-Options: nosniff?
Could we formalize it and remove the X and disable sniffing all
(for the sake of completeness)
On Tue, May 13, 2014 at 12:06 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote:
I agree that you're less likely to be able to control the headers. But
I don't think that's enough. A big part of the reason that authors
I disagree. Much of the Web actually relies on this today, and for the
most part it works. For example, when you do:
img src=foo ...
...the Content-Type is ignored except for SVG.
Well, img is actually a fairly special case of content that is
difficult for attackers to spoof and that
If CSS, JS and plugins had magic numbers at the beginning of the file, then
that would prevent the issues that you are discussing right?
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.
PDFs, and JARs
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
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.cxwrote:
I think that's Ian's point, that for those file types, we
@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.comwrote:
So today, we
Hi!
In the following bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14701the Content-Type
requirement for AppCache manifest files was dropped, and
the security implications of such change probably weren't fully understood
at that time, and we want to start a discussion on this topic to
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote:
Now, with appcache manifest files, we are introducing a
security-sensitive change based on a file with special powers (more on
this later), and while before they were guarded by a Content-Type check,
this isn't the case anymore.
Note that
On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote:
Now, with appcache manifest files, we are introducing a
security-sensitive change based on a file with special powers (more on
this later), and while before they were guarded
On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote:
Now, with appcache manifest files, we are introducing a
security-sensitive change based on a file with special powers (more on
this later), and while before they were guarded by a
22 matches
Mail list logo
