B2G security model (debian package management recommended) - help and advice needed
please take a deep breath before reading.
i'm keenly aware of the view that many people hold of me in debian.
that i'm even bringing something to your attention and asking for your
help (not for me, personally) should therefore tell you a lot more
than needs to actually be said.
i'm presently coming up to nine hours of continuous non-stop typing
(just today) to deal with something on the B2G developer mailing
lists: the security model, and it's getting to the point where i'm i
serious need of some highly-technical (as well as social) assistance.
your patience greatly appreciated whilst i explain.
B2G is a new operating system where the Gecko web front-end doubles up
(triples up?) as the window manager as well as the applications
"runner". they started from the android codebase, ripped out java,
ripped out webkit, dropped gecko in place using OpenGL _directly_
writing to the framebuffer, and then went, "ok, now we got the basics,
let's make this work".
as a concept, i find this both fascinating and exciting. the
resources of the mozilla foundation with the non-profit-orientated
motivation to create an open alternative to google's android?
by the time they're done, there will be *another* FOSS operating
system out there - one with the potential to reach a hundred million
units or more, through mass-volume sales world-wide, via numerous
telephone companies. applications could be developed by people that
could take off just as fast as any android or iphone application:
potentially millions of downloads per day if an app becomes highly
and the whole thing *won't* be tied to a particular vendor, or to a
profit-maximising company. the mozilla foundation is a non-for-profit
organisation, so has the potential to take into consideration aspects
that are *not* over-ridden by profit maximisation (such as "increasing
i have every confidence in the mozilla foundation to deliver the goods
on the U.I, on the apps example development, and much more besides.
what's of fundamental and deep concern to me is their ability to
comprehend the security implications of what they're doing.
and, you *know* me - it should come as absolutely no surprise to any
of you to learn that even the mozilla foundation is deploying
increasingly-hostile censorship measures to prevent me from
communicating with them.
ok, you can laugh now. go on. yeah, i know. i did it again.
happy now? :)
but seriously: it should be reasonably clear as to why i've persisted
with this *despite* increasing resistance, and it should speak volumes
that i'm asking (requesting NOT demanding) - publicly - for people to
wander over and take (CONSIDER taking) a look at the security
discussion taking place.
why am i asking [requesting-not-demanding] that _you_ - debian
developers - get [CONSIDER getting] involved? it's because the
application distribution model that i know best (that will also fulfil
the requirements) is... yep, debian.
why i am so deeply concerned about the discussion on the b2g-dev
mailing list has nothing to do with me, but has everything to do with
what the people in the mozilla foundation - those actively involved in
the b2g decision-making process - are recommending be used for
application distribution. it's SSL!
now, i know you know how debian package management works. imagine if
someone on a debian list somewhere went "hey guys! you know that
infrastructure you use to distribute debian packages? i've got a
great idea for a replacement for the system you've been establishing
and refining for almost 20 years, it's called SSL!"
now that you've picked yourself up off the floor, either from shock or
from laughing so hard you couldn't stand upright, you may be wondering
if i've made some sort of hilarious techie joke. i assure you i
what _would_ be funny though would be if, after reading this, someone
who *really* knows how SSL well and truly works actually said "yes,
here's a workable technical solution which uses SSL and delivers the
goods, i did a complete paper on it, it easily scales to the numbers
you describe, but didn't mention it here on the debian lists ever
because they already have a fully-working solution, and i didn't wish
to make an ass of myself like you do on a regular basis, mr lkcl".
then i would be very very happy that the joke was entirely on me.
... but my instincts and experience with SSL (so far) and with the
debian package management system (so far), tell me otherwise (to
the problem is: i've rather comprehensively fucked up relations
with... i think it's now about... ooo, getting on for 30+ people in
mozilla, who are getting so incensed that i'm quotes telling them what
to do quotes that in true terry pratchett style it's going beyond
annoying, gone out the other side and is bordering on becoming funny.
i think saying "i know there are many of you who wish i was dead so
that i'd stop typing" probably did it, this time.
anyway, enough of that: seriously, for those of you who feel some
semblance of duty and responsibility to free software in general, can
i please urge you to look this document over (should you so choose),
or to join the discussion on the dev-b2g mailing list (should you so choose).
my assessment of the situation so far is this (please feel free to
entirely ignore this):
* the required security is divided into four (thoroughly-interlinked) areas:
1) secure application distribution [*1]
2) app permissions enforcement (think: android's kernel-level
security model, SE/Linux etc).
3) decisions on what permissions are *required* to be enforced
(e.g. app can make phone calls,
e.g. app can access GPS,
e.g. app can legitimately access IMEI number etc.)
4) "standard" web security (normally known as XSS in AJAX)
* the mozilla team is giving the impression that they can handle
comprehensively and extremely competently handle jobs 3 and 4.
* the mozilla team is giving the impression that they couldn't find a
solution for 1) or 2) with both hands if it was imprinted on *all* of
* the use of debian's package management and distribution system would
be a significant augmentation of what the B2G team is doing, as well
as comprehensively fulfilling the requirements
* the mozilla team's expertise in operating system security is...
* the mozilla team's expertise in SSL and in Gecko is second-to-none
* the mozilla team's expertise in SSL and in Gecko is bordering on
* i'm not helping by repeating things - even patiently - even though
other people in the mozilla foundation keep repeating "what about SSL,
surely that will work?".
even the name of the wiki pages chosen should give you a massive clue
- and should, if you have any security knowledge or expertise, be
ringing massive alarm bells. all pages are named "App Security".
there *is* no top-level wiki page named "B2G Operating System
so the bottom line is: can someone, who has a clue and the patience,
please take a look at what they're doing, with a view to helping them
evaluate and develop a proper and comprehensive security model - one
that takes into account all 4 aspects?
i've done my best, but i know when i'm getting out of my depth, and
when it's time to ask for help. i've done my best to document what i
believe the B2G team can benefit from the use of debian's package
distribution infrastructure, but they're not really taking it
on-board, for so many reasons it's hard to believe let alone describe
thanks folks. really.
anything i haven't thought of, please do email me. just... give me a
day to recover from today's late night :)
[*1] apps in B2G are actually javacript+HTML source code, but don't
initiate phone calls or to push your details up to a company's web
site, entirely without your permission or even knowledge, if there
wasn't any security.
[*2] do you note how i go to some lengths to praise the expertise of
various teams for what they *can* do, so very very well? it's
genuine. just as genuine as the way that i go to the exact same
lengths to make it a joke or just plain state outright - honest, plain
and simple - when pointing out the *lack* of expertise in certain
areas. as best i can. many people - debian developers included -
ignore the former and focus on the latter. oh well. sorry.
[*3] just one example: i've encountered and listed _seven_ separate
and distinct reasons why the use of SSL as an application distribution
"security" measure does not fulfil the requirements, each of which
purely on their own should be sufficient to pull the plug on further
discussion of the use of SSL, yet i think there have been *nine*
people so far who have all gone "so what about this particular aspect
of SSL security, that'll help, right?" it's... truly, truly