From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: Security policy ambiguities - XSA-108 process post-mortem Date: Thu, 30 Oct 2014 11:58:30 +0000 Message-ID: <21586.10214.683512.296628@chiark.greenend.org.uk> References: <21557.24142.873029.148164@mariner.uk.xensource.com> <21557.50031.783473.873273@chiark.greenend.org.uk> <1413894766.23337.34.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XjoN7-0006jP-K7 for xen-devel@lists.xenproject.org; Thu, 30 Oct 2014 11:58:33 +0000 In-Reply-To: <1413894766.23337.34.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Ian Campbell writes ("Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem"): > On Thu, 2014-10-09 at 00:06 +0100, Ian Jackson wrote: > > Please provide URLs which are accessible and legible on mobile phone > > browsers, which do not require cookies enabled to load, and which > > are useable with text mode browsers, browsers which do not execute > > Javascript, and with screen readers and other accessibility > > software. If the member of the Xen Project Security Team who > > processes your application finds that their usual web browser does > > not display the required information, when presented with the URLs > > in your email, your application might be delayed or even rejected. > > While I appreciate where you are coming from I don't think it is the > place of this policy to rail against the crapitude of the modern web and > try and enforce our own standards on things (much as I would like too). > > I don't think it is unreasonable to expect that members of the security > team who typically run a browser with this crud disabled (which includes > myself) would load up their special sandboxed/throwaway browser with a > default config when faced with this sort of thing. I don't think members of the security team should be expected to either (a) set up a parallel sandboxed web browsing infrastructure, and keep that sandbox highly available so that it can be used during a security crisis, or (b) expose themselves to attacks of various kinds. The security list is very different to most of the situations where I am currently expecting to use my crud-enabled browser (as you so aptly put it). At the moment I use my crud-enabled browser when I am expecting to spend money, or engage with organisations that I already have a relationship with. That is, where I have already made a decision to trust the entity whose webshite I'm trying to look at. I am not personally willing to take random URLs sent to me in email from strangers and simply visit them in my usual crud-enabled browser - the same browser I use for my internet banking. I do have a *sandboxed* crud-enabled browser but it lives at home on a machine which has restricted access to and from the rest of my network - and I certainly wouldn't want to try to let it display on my Trusted Computing Base. I think that people who want to be on the predisclosure list should make matters easy for the security team. I think it therefore is only fair to say that an application might be delayed if the team member who happens to deal with the application can't conveniently access the evidence that the applicant is supposed to provide. And that an application might be rejected entirely if insufficiently many members of the team are able to access, and hence verify, the information provided. Or to put it another way: if the Xen Project community decides to reject an explicit statement along the lines I propose above, that won't mean that I will put my own security and privacy at risk when dealing with predisclosure list applications. So those applications might be delayed anyway, unless other members of the team want to take up the slack. Of course if the community doesn't like my attitude, they're free to get rid of me. Ian.