[Meego-security-discussion] Arbitrary 3rd Party Code
pgupta at mobilestack.com
Fri Apr 8 11:40:06 PDT 2011
Given all the posturing in this thread as well as resource constraints in
development of open source software, I am getting more and more convinced
that "enterprise users" have to lean on Microsoft to develop what they
need.. It will take "longer" for such features to show-up in open-source
Open source platform have "serious security gaps" for "adoption by
Enterprise users". Nobody in open source community is willing to develop
them for free (for obvious reasons).
I will keep quite now. I belong to a boutique firm and, hence, no cloud /
For obvious selfish reasons, Google does not want to introduce security
feature to limit "local access only" type features in Android (or listen to
Enterprise user's demand). I thought that this situation has created an
opportunity for Meego to "score over Android" and create a platform of
choice for "Enterprise & consumers" by introducing what is good for such
users (and not for Google or other such vendors).
Meego needs to create 10-times better platform then Android to win
market-share. Where are such features?
IMO, Security is one such area in which Meego can "score high points" over
Android and create a niche for itself.
If Meego's "large" customers are satisfied with what they have and willing
to push Meego in the market-place then everything is fine.
From: meego-security-discussion-bounces at lists.meego.com
[mailto:meego-security-discussion-bounces at lists.meego.com] On Behalf Of Ryan
Sent: Friday, April 08, 2011 10:26 AM
To: meego-security-discussion at lists.meego.com
Subject: Re: [Meego-security-discussion] Arbitrary 3rd Party Code
On 04/07/2011 04:32 PM, Praveen Gupta wrote:
> URL is not usable.. Please re-send..
> Again, separation of local-access only data is, just, one usecase..
> There are several other usecases.. For example -
> * Separation of "enterprise", "Carrier" and "application-sensitive"
> * Restriction of data cross-over from one domain to another
> Mobile platforms has "unique" security requirements.
> Implementation of these requirements is *necessary* for adoption of
> mobile platforms by "sensitive" enterprise applications (for
> example).. Several other such scenarios / use-cases exists.
> We need *requirements* which we can map to different Meego releases..
> After requirements are frozen, we need to propose "architecture" with
> release plan.
Please don't top-post.
This might be the case if we were following a waterfall development model.
We are not in any way following that type of model.
Additionally, we already have security requirements that have previously
been defined and published. There are others that have been defined and
will be published in the near future.
As for the specific requirement that you've proposed, I do not see it as a
requirement for MeeGo. Even if it was, I don't see a viable technical
solution that could be put in place. Content providers have been trying to
do this exact thing with various digital rights management systems since the
dawn of digitally distributed, consumer oriented products. As we all know,
their efforts with all of their resources have not yet created a solution
that would meet the intent of your requirement. If they've never been able
to do it, we have no hope of doing that with the small number of resources
we have working on MeeGo.
I believe I have a good understanding of what you would like to see and we
can't do it. We can't have a requirement saying we need to govern what an
application does with data after it's received it. What we
*can* have though (and do, but not published yet) is a requirement stating
that the end-user can control which applications are allowed which type of
personal data. That is reasonable and implementable and we already have
things in flight to get there.
MeeGo-security-discussion mailing list
MeeGo-security-discussion at lists.meego.com
More information about the MeeGo-security-discussion