[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.