W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CfC to publish FPWD of "Upgrade Insecure Resources"; Deadline Feb 17th.

From: Mike West <mkwst@google.com>
Date: Mon, 16 Feb 2015 16:05:42 +0100
Message-ID: <CAKXHy=cwaTGHqm5E4cnp3dne4Ggii_kNY6Wsou57n4O8j-Ua3A@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>, Peter Eckersley <pde@eff.org>, yan zhu <yan@mit.edu>
Given Brian's comments, let's extend this CfC to the 23rd, to coincide with
the MIX CfC I just threw at the list:
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0295.html.

Comments on both are, of course, welcome!

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Thu, Feb 12, 2015 at 8:32 AM, Mike West <mkwst@google.com> wrote:

> On Wed, Feb 11, 2015 at 9:04 PM, Brian Smith <brian@briansmith.org> wrote:
> > I support this effort. However, this shouldn't be a separate spec from
> > MIX. I understand that from a document preparation perspective, there
> > are benefits to having things split up in multiple documents. However,
> > from the perspective of somebody trying to read such specifications,
> > having related content spread across multiple documents is confusing.
>
> Hrm. Ok, that's a fair point.
>
> That said, the current upgrade draft is nicely self-contained; it lays
> out a problem, then it describes a solution. I like that. Personally,
> I find it easier to deal with documents that have this kind of narrow
> focus and limited scope. They're certainly easier to write, as you
> noted, but I find them easier to read as well. The HTML spec is a bad
> example, because it's truly large in a way that MIX isn't, but I
> certainly find it hard to work with when I want to know all the things
> about how a single something works.
>
> > In this case, in particular, having one of the coping mechanisms for
> > the rest of MIX defined in a separate document is bad.
>
> I can see that. I'm not convinced it's the right thing to do, but if
> folks generally disagree with me, then I'll see what I can do about
> gluing them together. :)
>
> That said, my argument is significantly weakened since we introduced
> strict mode to the MIX doc. Hrm.
>
> > Maybe there is some concern that if we add this to MIX, then the rest
> > of MIX will be delayed. I am not sure that matters, practically.
>
> I'd like to get MIX out the door to lock in a baseline of expected
> behavior that browsers, with the notable exception of Safari, have
> more or less already agreed upon. Given that there's apparently
> disagreement with the approach from folks like Tim Berners-Lee, I
> think there's value in getting that baseline settled and shipped.
>
> > if people feel like that is a concern, then we should just start a MIX
> > 2 draft that is MIX + this feature.
>
> Another approach (which is much more work) would be to continue moving
> towards small documents, while at the same time curating a WebAppSec
> summary document that could serve as an introduction to the features
> described in each. I can imagine that being useful and approachable
> for developers.
>
> -mike
>
> --
> Mike West <mkwst@google.com>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany,
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine
> Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
Received on Monday, 16 February 2015 15:06:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC