Can developer survive after the Symbian 9 release....

Hi Roberto,

>I'm sure that this is an interesting points already discussed with Phil but
>I want to enlarge my question to the forum of what the developers think
>about it: (so I suggest that either me and Phil will not answer but the
>community answer to this question to better understand the poitn of view of
>the community)

I know you are trying to stimulate discussion and I welcome that! But I do feel
I should reply to this initial post because some of your questions are based on
some basic misconceptions of Symbian OS v9, Symbian Signed and the current
market outlook. Allow me to address a couple of points below to give the
discussion a fair and accurate context, and then we can see what other
developers think...

>a) What's happen isf the signing process became mandatory (aka Symbian 9)

The Signing process is not mandatory - around 60% of the APIs in Symbian OS v9
are still open to use by any program with no extra restrictions, just as now.
This new paper:

http://www.symbian.com/developer/techlib/papers/cpp_sysarch.asp#osV9

gives a high-level introduction to the concept.

>tomorrow if the cost of signing , tools , partnership become more and more ?

We will be talking in greater detail at the upcoming Smartphone Show
(www.smartphoneshow.com) about some new initiatives we're introducing along with
various partners to help reduce costs and barriers to entry for developers, and
open Symbian Signed up to serve the needs of every type of ISV. I obviously
cannot say much more now, but there will be some very interesting announcements
at the show which I'd urge people to keep an eye out for (or, better, come to
the show to hear about and talk to myself and my colleagues in person about your
thoughts on developing for Symbian OS)!

>problems ? What's happen if the restricted API are not allowed to Manufactor
>X or Operator Y ? how Symbian will cover the cost raised to the developer to

The basic fact to remember here is it is the manufacturers and operators who
have DEMANDED this decision be placed in their hands. We have the situation now
where Symbian OS is a very powerful open platform with myriad possibilities for
developers to deliver compelling and innovative products which benefit the
entire ecosystem. Sadly, there is also scope for this power to be abused as we
are all well aware. The simple fact is that Symbian OS is destined to be used in
many more handsets which ship in much higher volumes (the so-called "mid range"
devices) and before operators and manufacturers are entirely comfortable with
such a powerful platform reaching many millions more users, they wanted
increased security at a platform level and increased assurances that badly
written (not necessarily malicious) applications will not impact them (i.e. with
returned handsets or support calls). Symbian has simply responded to market
demands to deliver this in a way which ensures continued openness of the
platform.

To put it bluntly, options open to operators and manufacturers looking forward a
few years were basically (1) closed phones or (2) open phones but with greater
control over how sensitive functionality was used and its access approved. It is
(2) which we are working to ensure for everyone's benefit!

Moving to Symbian OS v9 does require a shift in mindset and expectations, but it
is important to remember what we have enabled through a combination of the
enhanced platform security our customers demanded AND Symbian Signed as a
testing and certification program is the continued survival of open Symbian OS
phones. And open Symbian OS phones which are able to penetrate much larger
markets at that, i.e. allow your applications to reach many more paying users.

>c) How developers can keep their secret if they have to show to
>Symbian/manufactros/operators that they need this API to develop this
>particular applications ?

I appreciate information on this has so far been very thin on the ground from
our part, as we have really been waiting for real Symbian OS v9-based SDK to
come out from the UI vendors. The new Test Specification for Symbian Signed will
also soon be published and it talks about the access to the (very small) set of
'Phone Manufacturer Approved' capabilities and, yes, you will need to discuss
with the operator what these APIs are being used for - this does not necessarily
mean sharing source code or your IP. Neither does it mean any discussions have
to be conducted outside of an NDA or other protections.

I should also point out that these most sensitive of all capabilities are
expected to be used only in very, very rare cases so the vast majority of
developers will never need to even consider these...

>d) How delay will took to deliver on the market in terms of decision time
>for the API release and signing process ? Does the time to market is

The basic Symbian Signed process remains unchanged. We are not envisaging any
extra delays will be introduced in the process for Symbian OS v9 applications.
As I said, few people will need to ever do this, but for the 'Phone Manufacturer
Approved' capabilities where extra dialogue is needed with a manufacturer,
imagine this being similar to the current waiver process - i.e. this will add a
small extra delay to the process since it is an extra step...but this is the
exception not the norm.

>e) How many developers incurred into a problem with a certification TEST
>house that fail your application for problem of the OS / manufactors ? how

This is not new to Symbian OS v9. Any issues at the platform level which are
beyond your control are traditionally treated as exceptions to the process and
we are happy to approve these (e.g. on the 9500 there is a defect in the
installer in some versions at least that the 'FN' (remove on uninstall) flag in
PKG files is ignored - this is clearly an exception to that test).

>f) How secure is Symbian 9 ? Do you think that signing and have a secure OS
>will help you to get more profits (aka stop copying your applications) or

The enhanced platform security model in Symbian OS v9 is implemented at the very
lowest level in the operating system and is designed to provide security and
robustness for mass-market requirements (e.g. DRM) and allow greater control
over sensitive API usage (through the capability model). There is nothing
specifically designed to address the copying and cracking of applications per
se.

HOWEVER, getting applications installed on to a Symbian OS v9 phone can only be
done through .SIS files (because of data caging, only the installer can place
the binaries in the right place). This protection also extends to removable
media too (i.e. Symbian OS will not execute an application on a removable disk
unless it has a stored secure hash of it, generated after installation from a
SIS on that particular phone, on the internal drive). If your SIS file is
Symbian Signed because it uses some extended capabilities, a cracker will also
have to get the application Symbian Signed to be able to redistribute any
cracked version of your SIS file which can be installed on another phone easily.
And they could therefore be traced through their ACS ID. This is in practice an
extra practical barrier to cracking.

The key feature of Symbian OS v9 which is likely to help your profits is volume
- as I said above, it is destined to be used in a much higher number of devices
and therefore you have a much larger addressable market.

I hope some of these clarifications are useful.

Kind regards,

Phil

Hi,

I read all the papers on your mentioned link, but still do not know or did
not find a paper answering the questions about specific API calls.
Where do I find a specific overview about each API call?

For example to access Phonebook and Agenda file, will it also work without
Symbina Signed or not?

Best regards
Max

"RobyOneKenoby" <[email protected]> wrote in message
news:EZOnRjwuFHA.1040@extapps30...
> Hi Everyone,
>
> I'm sure that this is an interesting points already discussed with Phil
> but
> I want to enlarge my question to the forum of what the developers think
> about it: (so I suggest that either me and Phil will not answer but the
> community answer to this question to better understand the poitn of view
> of
> the community)

Ok, here is just couple of personal opinions.

> a) What's happen isf the signing process became mandatory (aka Symbian 9)
> does it will increase the cost of development ? Do you think that it will
> be
> easy to retrieve back the profits invested now WITHOUT signing , what
> about
> tomorrow if the cost of signing , tools , partnership become more and more
> ?
> does it will encourage or not encourage people to enter into the platform
> to
> build new KILLER APPS idea ?

If signing process were mandatory, then it would will increase costs.
So we have to hope that most applications (e.g. games) can be
developed without signing. 😊

> c) How developers can keep their secret if they have to show to
> Symbian/manufactros/operators that they need this API to develop this
> particular applications ? Do you think that this big brother will restrict
> the possibilities to deliver good software ? Whats happen if you invest
> thousand Euros for a project that request API and
> SYMBIAN/MAnufactors/Operators think that are not good for their customers
> (or maybe not profitable for them) ?

Yes, there may be cases that symbian applications are built for certain
corporation / user group. So then there could be confidentiality issues.

> d) How delay will took to deliver on the market in terms of decision time
> for the API release and signing process ? Does the time to market is
> important for a developer ? do you think that wait 1 week/1 month / more
> will be acceptable to release a software ?

Well, probably you should take that into account in schedules.

> e) How many developers incurred into a problem with a certification TEST
> house that fail your application for problem of the OS / manufactors ? how
> this problem have delayed in your project and what will be the cost for
> the
> problem patched by you but generated by others ?

Yes, I think this might become a bit annoying. Like consider the following
scenario:
- You develop your software with device X with software version Y
from manufacturer Z.
- Let's consider that everything works ok in your own tests.
- Now you put your application to symbian signed.
- Test house notices that your applications has problems with their
device(s).

So who is responsible of tracking the problem? Developer, I expect.
It might not be fun, especially if the problem happens to be caused by
OS / manufacturer (e.g. prevents use of your application).

Also is one sis file enough? Or do you need one sis file per device model?

> f) How secure is Symbian 9 ? Do you think that signing and have a secure
> OS
> will help you to get more profits (aka stop copying your applications) or
> cause more problem because it will restrict the market to operators only
> customers ? Do you think that Symbian 9 will assure profts to the
> developers
> or keep the operators patient to this virus megalomania effect that are
> just
> a dummy worry ?

How does symbian signed prevent copying of applications?

If you get signed sis file when you purchase application, sis file can be
copied. Of course, sis file may be protected, so then it would not be
possible
to use the file in other devices. (I am not sure if this mechanism is really
used)

Ok, if you are using some kind of registration mechanism (e.g. enter
passphrase to lock to current device), then it may be possible to prevent
copying of cracked applications.

Because if your application is such that it's not required to go through
symbian signed (if I have understood correctly, all apps do not need to
be signed), surely then application can be modified and delivered
(but not symbian signed).

If your application requires symbian signed, then yes, it's not possible
to share modified application.

I think signing would be beneficial for end-users.
If sis file is symbian signed, then end-users know that they are
installing original package.

Symbian signed does not prevent malicious / defective applications
and does not guarantee that the application works always correctly.

However, then it's possible to track who has developed the application.
Is application developer required to make correction? Application
developer might decide not to correct the problem if it occurs rarely
or only in certain variants. It's possible that application developer
cannot even reproduce the problem - thus, even harder to fix.

Finally, it's possible that the problem does not even occur with the
device application developer used to verify the program. It's a bit
unfair to expect application developers to buy all devices with all
different sw versions and test their applications with all of them.

Also I would expect it's hard to say if the problem is caused by a bug
in software or if it's intentional. If you have installed many sis files,
it might be hard to know which application caused the problem.

Anyway, most applications will contain 'disclaimer',
i.e. if something bad happens (e.g. application deletes all your
pictures), it's end-users problem, not company's which developed the
application.

So I think testing part of symbian signed is a bit ridiculous. E.g.
"Yes, the application handles low memory situations in its startup ok" 😊.
Why not trust on application developers to test cases like this?
Anyway, you need to rely on application developer to make sure that
basic behaviour of application is ok.

Ciao Phil,

We will sure meet in Smartphone show but I was miastaken when i said not to
talk about my issue and leave the people open , but I think your
clarification better understand the situation of Symbian signed and give an
extra idea of how symbian will be move forward, so thansk for that I have
only one exceptions to rais , in the future when Symbian 9 will be set and
runnign Symbian will have an open mind to come back or correct mistakes of
the initial starup ? will help developers to let the platform fgrow ? My
question is how flexible can be the Symbian signing in a future where
developers can encounter more problem than today ... thanks Roberto

"RobyOneKenoby" <[email protected]> wrote in message
news:EZOnRjwuFHA.1040@extapps30...
> Hi Everyone,
>
> I'm sure that this is an interesting points already discussed with Phil
but
> I want to enlarge my question to the forum of what the developers think
> about it: (so I suggest that either me and Phil will not answer but the
> community answer to this question to better understand the poitn of view
of
> the community)
>
> a) What's happen isf the signing process became mandatory (aka Symbian 9)
> does it will increase the cost of development ? Do you think that it will
be
> easy to retrieve back the profits invested now WITHOUT signing , what
about
> tomorrow if the cost of signing , tools , partnership become more and more
?
> does it will encourage or not encourage people to enter into the platform
to
> build new KILLER APPS idea ?
>
> b) How Symbian with the release of the Symbian 9 will restrict the API an
> how free will be the developer to sell apps without incourr in thousand
> problems ? What's happen if the restricted API are not allowed to
Manufactor
> X or Operator Y ? how Symbian will cover the cost raised to the developer
to
> support the global customers with different installation with the same
phone
> but with different restrictions ?
>
> c) How developers can keep their secret if they have to show to
> Symbian/manufactros/operators that they need this API to develop this
> particular applications ? Do you think that this big brother will restrict
> the possibilities to deliver good software ? Whats happen if you invest
> thousand Euros for a project that request API and
> SYMBIAN/MAnufactors/Operators think that are not good for their customers
> (or maybe not profitable for them) ?
>
> d) How delay will took to deliver on the market in terms of decision time
> for the API release and signing process ? Does the time to market is
> important for a developer ? do you think that wait 1 week/1 month / more
> will be acceptable to release a software ?
>
> e) How many developers incurred into a problem with a certification TEST
> house that fail your application for problem of the OS / manufactors ? how
> this problem have delayed in your project and what will be the cost for
the
> problem patched by you but generated by others ?
>
> f) How secure is Symbian 9 ? Do you think that signing and have a secure
OS
> will help you to get more profits (aka stop copying your applications) or
> cause more problem because it will restrict the market to operators only
> customers ? Do you think that Symbian 9 will assure profts to the
developers
> or keep the operators patient to this virus megalomania effect that are
just
> a dummy worry ?
>
> g) do you think that Symbian Signing will protect and assure the
developers
> work ? In which way ? Do you think that spending money in support /
signing
> / partnership will benefits you or your customer's visibility or it is
just
> a cost to be added to the list of the initial development ? What is your
> breakheaven (start to making profits) calculating this new increasing of
> cost ?
>
> Sorry for the time spent ... but I think that signing must also consider
> this possibilities that are to the border of the development but important
> to decide to continue to develop or not for Symbian thanks Roberto
>
>

yes I also believe that signing process not cover all the cases especially
in the fixing bugs and in patching problem on different phones, I think that
a good solution is to let the developer trusted (maybe with a process for
that to trust the company who develop symbian) to let them signign their
application for free with their ACS publisher ID because in any case it is a
responsability of the company who develop the application if somethign went
wrong with their applciations so this is the base of trust in a software
made by that company , Test house cannot control all the relevants problem
of the software and for a company who have to certify the application is a
bit expansive to re-sign the applications , so in other hand what's happen
if the software company don't patch the applciation if there is bug just
because for them is an extra cost ? the customer have already buyed the
application so there is no income money , so wo will have this
responsability to check ? i think it is better to give the possibilities to
a company trusted to certify by itself their application and be more
responsabile for the work done ....
Another issue is what's happen for enterprise solutions that must be signed
for particular API used and must be customized for hundreds customers ? it
become a little bit expansive and �rpblematic in terms of time.... so this
discussion is open nto to poitn the finger to symbian but to let them the
problem that developers have every day so the can correct and make a better
work to help us ... thanks Roberto

"Pekka" <pekka@unknown> wrote in message news:XOCkH$6uFHA.2464@extapps30...
>
> "RobyOneKenoby" <[email protected]> wrote in message
> news:EZOnRjwuFHA.1040@extapps30...[color=green]
> > Hi Everyone,
> >
> > I'm sure that this is an interesting points already discussed with Phil
> > but
> > I want to enlarge my question to the forum of what the developers think
> > about it: (so I suggest that either me and Phil will not answer but the
> > community answer to this question to better understand the poitn of view
> > of
> > the community)
>
> Ok, here is just couple of personal opinions.
>
> > a) What's happen isf the signing process became mandatory (aka Symbian[/color]
9)[color=green]
> > does it will increase the cost of development ? Do you think that it[/color]
will[color=green]
> > be
> > easy to retrieve back the profits invested now WITHOUT signing , what
> > about
> > tomorrow if the cost of signing , tools , partnership become more and[/color]
more[color=green]
> > ?
> > does it will encourage or not encourage people to enter into the[/color]
platform[color=green]
> > to
> > build new KILLER APPS idea ?
>
> If signing process were mandatory, then it would will increase costs.
> So we have to hope that most applications (e.g. games) can be
> developed without signing. 😊
>
> > c) How developers can keep their secret if they have to show to
> > Symbian/manufactros/operators that they need this API to develop this
> > particular applications ? Do you think that this big brother will[/color]
restrict[color=green]
> > the possibilities to deliver good software ? Whats happen if you invest
> > thousand Euros for a project that request API and
> > SYMBIAN/MAnufactors/Operators think that are not good for their[/color]
customers[color=green]
> > (or maybe not profitable for them) ?
>
> Yes, there may be cases that symbian applications are built for certain
> corporation / user group. So then there could be confidentiality issues.
>
> > d) How delay will took to deliver on the market in terms of decision[/color]
time[color=green]
> > for the API release and signing process ? Does the time to market is
> > important for a developer ? do you think that wait 1 week/1 month / more
> > will be acceptable to release a software ?
>
> Well, probably you should take that into account in schedules.
>
> > e) How many developers incurred into a problem with a certification TEST
> > house that fail your application for problem of the OS / manufactors ?[/color]
how[color=green]
> > this problem have delayed in your project and what will be the cost for
> > the
> > problem patched by you but generated by others ?
>
> Yes, I think this might become a bit annoying. Like consider the following
> scenario:
> - You develop your software with device X with software version Y
> from manufacturer Z.
> - Let's consider that everything works ok in your own tests.
> - Now you put your application to symbian signed.
> - Test house notices that your applications has problems with their
> device(s).
>
> So who is responsible of tracking the problem? Developer, I expect.
> It might not be fun, especially if the problem happens to be caused by
> OS / manufacturer (e.g. prevents use of your application).
>
> Also is one sis file enough? Or do you need one sis file per device model?
>
> > f) How secure is Symbian 9 ? Do you think that signing and have a secure
> > OS
> > will help you to get more profits (aka stop copying your applications)[/color]
or[color=green]
> > cause more problem because it will restrict the market to operators only
> > customers ? Do you think that Symbian 9 will assure profts to the
> > developers
> > or keep the operators patient to this virus megalomania effect that are
> > just
> > a dummy worry ?
>
> How does symbian signed prevent copying of applications?
>
> If you get signed sis file when you purchase application, sis file can be
> copied. Of course, sis file may be protected, so then it would not be
> possible
> to use the file in other devices. (I am not sure if this mechanism is[/color]
really
> used)
>
> Ok, if you are using some kind of registration mechanism (e.g. enter
> passphrase to lock to current device), then it may be possible to prevent
> copying of cracked applications.
>
> Because if your application is such that it's not required to go through
> symbian signed (if I have understood correctly, all apps do not need to
> be signed), surely then application can be modified and delivered
> (but not symbian signed).
>
> If your application requires symbian signed, then yes, it's not possible
> to share modified application.
>
> I think signing would be beneficial for end-users.
> If sis file is symbian signed, then end-users know that they are
> installing original package.
>
> Symbian signed does not prevent malicious / defective applications
> and does not guarantee that the application works always correctly.
>
> However, then it's possible to track who has developed the application.
> Is application developer required to make correction? Application
> developer might decide not to correct the problem if it occurs rarely
> or only in certain variants. It's possible that application developer
> cannot even reproduce the problem - thus, even harder to fix.
>
> Finally, it's possible that the problem does not even occur with the
> device application developer used to verify the program. It's a bit
> unfair to expect application developers to buy all devices with all
> different sw versions and test their applications with all of them.
>
> Also I would expect it's hard to say if the problem is caused by a bug
> in software or if it's intentional. If you have installed many sis files,
> it might be hard to know which application caused the problem.
>
> Anyway, most applications will contain 'disclaimer',
> i.e. if something bad happens (e.g. application deletes all your
> pictures), it's end-users problem, not company's which developed the
> application.
>
> So I think testing part of symbian signed is a bit ridiculous. E.g.
> "Yes, the application handles low memory situations in its startup ok" 😊.
> Why not trust on application developers to test cases like this?
> Anyway, you need to rely on application developer to make sure that
> basic behaviour of application is ok.
>
>

"RobyOneKenoby" <[email protected]> schreef in bericht
news:EZOnRjwuFHA.1040@extapps30...
> Hi Everyone,
>
> I'm sure that this is an interesting points already discussed with Phil
> but
> I want to enlarge my question to the forum of what the developers think
> about it: (so I suggest that either me and Phil will not answer but the
> community answer to this question to better understand the poitn of view
> of
> the community)
>
> a) What's happen isf the signing process became mandatory (aka Symbian 9)
> does it will increase the cost of development ? Do you think that it will
> be
> easy to retrieve back the profits invested now WITHOUT signing , what
> about
> tomorrow if the cost of signing , tools , partnership become more and more
> ?
> does it will encourage or not encourage people to enter into the platform
> to
> build new KILLER APPS idea ?

The costs of having the an app signed aren't that high. The most expensive
one is about day paying for a West-European programmer.
If you are a commercial developer, and the problem is that having the app
signed will make your profit evaporate, you should not have written the app
in the first place.
Think of it. In a market with 50 million devices a proper commercial app
doesn't make a profit of EUR 500,--

It looks expensive for shareware programmer's, because thy do not take their
own time into account. And if you as a shareware developer have the next
killer app, it will make millions (by *definition*), so investing EUR 500,--
doesn't sound too unreasonable.

The apps that will suffer are the shareware apps that will make thir authors
around EUR 500,--. So don't sign those apps, and if they must be signed on
OS 9.1, don't write them. Nobody wants them anyway, so why bother 😉

> b) How Symbian with the release of the Symbian 9 will restrict the API an
> how free will be the developer to sell apps without incourr in thousand
> problems ? What's happen if the restricted API are not allowed to
> Manufactor
> X or Operator Y ? how Symbian will cover the cost raised to the developer
> to
> support the global customers with different installation with the same
> phone
> but with different restrictions ?

If operators and device manufacturers are going to selectively restrict API
(they can't AFAIK, but who knows), the marketplace will sort this out in no
time. If a popular program/killer app doesn't work on their network/device
because of that restriction, people will not want to use their
network/device, and complain. This will result in them loosing lots of
money.

> c) How developers can keep their secret if they have to show to
> Symbian/manufactros/operators that they need this API to develop this
> particular applications ? Do you think that this big brother will restrict
> the possibilities to deliver good software ? Whats happen if you invest
> thousand Euros for a project that request API and
> SYMBIAN/MAnufactors/Operators think that are not good for their customers
> (or maybe not profitable for them) ?

The device will not allow an unsigned app access to API's. When you call a
method, the method checks if you are allowed to make the call and it will
refuse to run when you don't have the neccessary capabilities. This means
that the program will not work.
Nobody is going to look at your source code because it isn't necessary.

You know upfront which API's are restricted and that set is fixed. This
means that after you have done the design you know whether the app must be
signed or not. You can then make the go/no go decision.

Operators are not very important, because they are restricted to a country
and if there is one thing in this market, you are not restricted to one
country. So if A doesn't want to sell you app, who cares. B might want to
sell it, and in country C A" will sell because in another country A" is not
number one but number 4 and struggling.

> d) How delay will took to deliver on the market in terms of decision time
> for the API release and signing process ? Does the time to market is
> important for a developer ? do you think that wait 1 week/1 month / more
> will be acceptable to release a software ?

You will need to take the signing time into account.

> e) How many developers incurred into a problem with a certification TEST
> house that fail your application for problem of the OS / manufactors ? how
> this problem have delayed in your project and what will be the cost for
> the
> problem patched by you but generated by others ?

The requirements are well-known and testing for them can be taken into
account. The requiremnents are not unreasonable so you would be testing for
them anyway (if you want a killer app, that is).

> f) How secure is Symbian 9 ? Do you think that signing and have a secure
> OS
> will help you to get more profits (aka stop copying your applications) or
> cause more problem because it will restrict the market to operators only
> customers ? Do you think that Symbian 9 will assure profts to the
> developers
> or keep the operators patient to this virus megalomania effect that are
> just
> a dummy worry ?

It will in some measure protect your app. A hacker cannot create a signed
version of a sis file after he has altered your app. But hackers can still
post unaltered apps for people to download freely. This means that adding
protection to your app is worthwhile because the signing process and the
capability restrictions will act as a protection mechanism.

I don't see why signing the app makes the program available to operator
customenrs only. You can still sell the app to anybody you want and through
as many channels as you can make deals with.

> g) do you think that Symbian Signing will protect and assure the
> developers
> work ? In which way ? Do you think that spending money in support /
> signing
> / partnership will benefits you or your customer's visibility or it is
> just
> a cost to be added to the list of the initial development ? What is your
> breakheaven (start to making profits) calculating this new increasing of
> cost ?

It is of course a cost to be added. If signing the app gets it into more
channels, changes are that it will sell more.

> Sorry for the time spent ... but I think that signing must also consider
> this possibilities that are to the border of the development but important
> to decide to continue to develop or not for Symbian thanks Roberto

--
Sander van der Wal
www.mBrainSoftware.com
>

"RobyOneKenoby" <[email protected]> schreef in bericht
news:JLPaUH7uFHA.1000@extapps30...
> yes I also believe that signing process not cover all the cases especially
> in the fixing bugs and in patching problem on different phones, I think
> that
> a good solution is to let the developer trusted (maybe with a process for
> that to trust the company who develop symbian) to let them signign their
> application for free with their ACS publisher ID because in any case it is
> a
> responsability of the company who develop the application if somethign
> went
> wrong with their applciations so this is the base of trust in a software
> made by that company , Test house cannot control all the relevants problem
> of the software and for a company who have to certify the application is a
> bit expansive to re-sign the applications , so in other hand what's happen
> if the software company don't patch the applciation if there is bug just
> because for them is an extra cost ? the customer have already buyed the
> application so there is no income money , so wo will have this
> responsability to check ? i think it is better to give the possibilities
> to
> a company trusted to certify by itself their application and be more
> responsabile for the work done ....

It helps a lot not having a lot of defects in your app. If you find a lot of
defects in your apps after the first release date, you might want to rethink
your development strategy.

For instance, if you decide not to implement all features in the first
release, you can make in the same time a better first release by doing more
tests and doing less programming. Defects found can be fixed in the next
release. You can ask money for the next release too, by making it
substantial enough to ask for an upgrade price which is lower than buying
the full app. For certain apps this works well.

You can also do a subscription model. People pay a subscrpition and get bug
fixes for free with the subscription.

> Another issue is what's happen for enterprise solutions that must be
> signed
> for particular API used and must be customized for hundreds customers ? it
> become a little bit expansive and �rpblematic in terms of time.... so this
> discussion is open nto to poitn the finger to symbian but to let them the
> problem that developers have every day so the can correct and make a
> better
> work to help us ... thanks Roberto

In this case, you simply tell your enterprise customer the situation: you
must pay for signing otherwise the app will not work. Or, you become a
self-signing developer, and factor the cost of that into your proposal.

--
Sander van der Wal
www.mBrainSoftware.com

> "Pekka" <pekka@unknown> wrote in message
> news:XOCkH$6uFHA.2464@extapps30...[color=green]
>>
>> "RobyOneKenoby" <[email protected]> wrote in message
>> news:EZOnRjwuFHA.1040@extapps30...[color=darkred]
>> > Hi Everyone,
>> >
>> > I'm sure that this is an interesting points already discussed with Phil
>> > but
>> > I want to enlarge my question to the forum of what the developers think
>> > about it: (so I suggest that either me and Phil will not answer but the
>> > community answer to this question to better understand the poitn of
>> > view
>> > of
>> > the community)
>>
>> Ok, here is just couple of personal opinions.
>>
>> > a) What's happen isf the signing process became mandatory (aka Symbian[/color]
> 9)[color=darkred]
>> > does it will increase the cost of development ? Do you think that it[/color]
> will[color=darkred]
>> > be
>> > easy to retrieve back the profits invested now WITHOUT signing , what
>> > about
>> > tomorrow if the cost of signing , tools , partnership become more and[/color]
> more[color=darkred]
>> > ?
>> > does it will encourage or not encourage people to enter into the[/color]
> platform[color=darkred]
>> > to
>> > build new KILLER APPS idea ?
>>
>> If signing process were mandatory, then it would will increase costs.
>> So we have to hope that most applications (e.g. games) can be
>> developed without signing. 😊
>>
>> > c) How developers can keep their secret if they have to show to
>> > Symbian/manufactros/operators that they need this API to develop this
>> > particular applications ? Do you think that this big brother will[/color]
> restrict[color=darkred]
>> > the possibilities to deliver good software ? Whats happen if you invest
>> > thousand Euros for a project that request API and
>> > SYMBIAN/MAnufactors/Operators think that are not good for their[/color]
> customers[color=darkred]
>> > (or maybe not profitable for them) ?
>>
>> Yes, there may be cases that symbian applications are built for certain
>> corporation / user group. So then there could be confidentiality issues.
>>
>> > d) How delay will took to deliver on the market in terms of decision[/color]
> time[color=darkred]
>> > for the API release and signing process ? Does the time to market is
>> > important for a developer ? do you think that wait 1 week/1 month /
>> > more
>> > will be acceptable to release a software ?
>>
>> Well, probably you should take that into account in schedules.
>>
>> > e) How many developers incurred into a problem with a certification
>> > TEST
>> > house that fail your application for problem of the OS / manufactors ?[/color]
> how[color=darkred]
>> > this problem have delayed in your project and what will be the cost
>> > for
>> > the
>> > problem patched by you but generated by others ?
>>
>> Yes, I think this might become a bit annoying. Like consider the
>> following
>> scenario:
>> - You develop your software with device X with software version Y
>> from manufacturer Z.
>> - Let's consider that everything works ok in your own tests.
>> - Now you put your application to symbian signed.
>> - Test house notices that your applications has problems with their
>> device(s).
>>
>> So who is responsible of tracking the problem? Developer, I expect.
>> It might not be fun, especially if the problem happens to be caused by
>> OS / manufacturer (e.g. prevents use of your application).
>>
>> Also is one sis file enough? Or do you need one sis file per device
>> model?
>>
>> > f) How secure is Symbian 9 ? Do you think that signing and have a
>> > secure
>> > OS
>> > will help you to get more profits (aka stop copying your applications)[/color]
> or[color=darkred]
>> > cause more problem because it will restrict the market to operators
>> > only
>> > customers ? Do you think that Symbian 9 will assure profts to the
>> > developers
>> > or keep the operators patient to this virus megalomania effect that are
>> > just
>> > a dummy worry ?
>>
>> How does symbian signed prevent copying of applications?
>>
>> If you get signed sis file when you purchase application, sis file can be
>> copied. Of course, sis file may be protected, so then it would not be
>> possible
>> to use the file in other devices. (I am not sure if this mechanism is[/color]
> really
>> used)
>>
>> Ok, if you are using some kind of registration mechanism (e.g. enter
>> passphrase to lock to current device), then it may be possible to prevent
>> copying of cracked applications.
>>
>> Because if your application is such that it's not required to go through
>> symbian signed (if I have understood correctly, all apps do not need to
>> be signed), surely then application can be modified and delivered
>> (but not symbian signed).
>>
>> If your application requires symbian signed, then yes, it's not possible
>> to share modified application.
>>
>> I think signing would be beneficial for end-users.
>> If sis file is symbian signed, then end-users know that they are
>> installing original package.
>>
>> Symbian signed does not prevent malicious / defective applications
>> and does not guarantee that the application works always correctly.
>>
>> However, then it's possible to track who has developed the application.
>> Is application developer required to make correction? Application
>> developer might decide not to correct the problem if it occurs rarely
>> or only in certain variants. It's possible that application developer
>> cannot even reproduce the problem - thus, even harder to fix.
>>
>> Finally, it's possible that the problem does not even occur with the
>> device application developer used to verify the program. It's a bit
>> unfair to expect application developers to buy all devices with all
>> different sw versions and test their applications with all of them.
>>
>> Also I would expect it's hard to say if the problem is caused by a bug
>> in software or if it's intentional. If you have installed many sis files,
>> it might be hard to know which application caused the problem.
>>
>> Anyway, most applications will contain 'disclaimer',
>> i.e. if something bad happens (e.g. application deletes all your
>> pictures), it's end-users problem, not company's which developed the
>> application.
>>
>> So I think testing part of symbian signed is a bit ridiculous. E.g.
>> "Yes, the application handles low memory situations in its startup ok"
>> 😊.
>> Why not trust on application developers to test cases like this?
>> Anyway, you need to rely on application developer to make sure that
>> basic behaviour of application is ok.
>>
>>
>
>[/color]

Phil Spencer wrote:

> Hi Roberto,
[...]
[color=green]
>>c) How developers can keep their secret if they have to show to
>>Symbian/manufactros/operators that they need this API to develop this
>>particular applications ?
>
>
> I appreciate information on this has so far been very thin on the ground from
> our part, as we have really been waiting for real Symbian OS v9-based SDK to
> come out from the UI vendors. The new Test Specification for Symbian Signed will
> also soon be published and it talks about the access to the (very small) set of
> 'Phone Manufacturer Approved' capabilities and, yes, you will need to discuss
> with the operator what these APIs are being used for - this does not necessarily
> mean sharing source code or your IP. Neither does it mean any discussions have
> to be conducted outside of an NDA or other protections.
>
> I should also point out that these most sensitive of all capabilities are
> expected to be used only in very, very rare cases so the vast majority of
> developers will never need to even consider these...
>
>[/color]

Today, we can look at the exports and import tables of a dll/app and
deduce what dlls and APIs are used. Maybe it is not that easy for
everyone out there (because to get some more context and meaning you
need to know the symbolic info as to what that API is, hence the libs)

Tomorrow (a.k.a post v9.x) this will be the same 😊

This is common with all OSs, but with Symbian OS it is more difficult to
get this info (if you're not Symbian😊 since we link by ordinal only
and not by name (and strip all such symbolic info from the binaries).

Just telling a test house you use some APIs is not giving away much and
it certainly is cheaper (and safer in my opinion😊 than inspection.

You amy want toa rgue why you'd need a test house in the middle and not
do it directly to symbian, which you may/many not trust more. But this
is another discussion.

(of course for all above cases there is the caveat of compressed
binaries which could not be inspected taht easily, but still it is
possible and known)

hope that clarifies it a bit

/JP

There are a lot more to this. _IF_ Symbian wanted more security and
__WANTED__ to keep the developers happy they could have reached a
compromise. Basically Symbian went to the Phone Developers and Networks but
they ignored the developer completely.

Statement "Applications compromise network security."

They might, but it is irrelevent. Think about it, you can have access to
GPRS/3G from your laptop. Locking down the API in such a
way that you cannot port an application from your laptop to your cellphone
in the name of network security does not make sense.

The handset manufacturers have another reason they want to lock down their
handsets. Most of the hardware functionality stays the same, it is only the
software and packaging that differs. If for some reason you could download
the next-generation features why would you buy a new handset? Of course,
scratching an itch is one of the main motivations for open source software.
Nokia and the like wouldn't want anybody else to fix their mess would they?

If Symbian were an independent software company you could have everything as
advertised plus security. Possible solutions that were not given
consideration:

1) Give control to the users: If the user wants to install software that
does XY and Z let them. Even if it requires that they enter a "software
installation pin number" or the like.
2) Add the ability for more certificates. If an enterprise wants to deploy
and application to all their employees on company phones I think they should
have a right to install their own root certificate
3) Develop mechanisms whereby a user can "give" network credits to an
application. E.g. allows 100KB to every application by default. Application
can request more from the user. Isolated Storage. You get the idea. There
are technical stuff that can be done to improve the situation.

The big thing is that the certificates will do nothing for security, besides
giving a false sense of it. Only one bug in the operating system can lead to
a hole that a virus can exploit to run inside the kernel. In the age of the
internet that code will be out there for other people to copy. Thus we have
a situation were ethical programmers are punished but with minimal impact on
the bad guys. Please also note, that if a third party wish to write an
open-source firewall to prevent worms from exploiting an OS bug it would
almost be impossible under the signing thing. Software that do automatic
updates will be a mess as well. So in general, the platform will be a lot
poorer from a security viewpoint as well IMHO.

"Phil Spencer" <[email protected]> wrote in message
news:[email protected]...
> Hi Roberto,
>[color=green]
>>I'm sure that this is an interesting points already discussed with Phil
>>but
>>I want to enlarge my question to the forum of what the developers think
>>about it: (so I suggest that either me and Phil will not answer but the
>>community answer to this question to better understand the poitn of view
>>of
>>the community)
>
> I know you are trying to stimulate discussion and I welcome that! But I do
> feel
> I should reply to this initial post because some of your questions are
> based on
> some basic misconceptions of Symbian OS v9, Symbian Signed and the current
> market outlook. Allow me to address a couple of points below to give the
> discussion a fair and accurate context, and then we can see what other
> developers think...
>
>>a) What's happen isf the signing process became mandatory (aka Symbian 9)
>
> The Signing process is not mandatory - around 60% of the APIs in Symbian
> OS v9
> are still open to use by any program with no extra restrictions, just as
> now.
> This new paper:
>
> http://www.symbian.com/developer/techlib/papers/cpp_sysarch.asp#osV9
>
> gives a high-level introduction to the concept.
>
>>tomorrow if the cost of signing , tools , partnership become more and more
>>?
>
> We will be talking in greater detail at the upcoming Smartphone Show
> (www.smartphoneshow.com) about some new initiatives we're introducing
> along with
> various partners to help reduce costs and barriers to entry for
> developers, and
> open Symbian Signed up to serve the needs of every type of ISV. I
> obviously
> cannot say much more now, but there will be some very interesting
> announcements
> at the show which I'd urge people to keep an eye out for (or, better, come
> to
> the show to hear about and talk to myself and my colleagues in person
> about your
> thoughts on developing for Symbian OS)!
>
>>problems ? What's happen if the restricted API are not allowed to
>>Manufactor
>>X or Operator Y ? how Symbian will cover the cost raised to the developer
>>to
>
> The basic fact to remember here is it is the manufacturers and operators
> who
> have DEMANDED this decision be placed in their hands. We have the
> situation now
> where Symbian OS is a very powerful open platform with myriad
> possibilities for
> developers to deliver compelling and innovative products which benefit the
> entire ecosystem. Sadly, there is also scope for this power to be abused
> as we
> are all well aware. The simple fact is that Symbian OS is destined to be
> used in
> many more handsets which ship in much higher volumes (the so-called "mid
> range"
> devices) and before operators and manufacturers are entirely comfortable
> with
> such a powerful platform reaching many millions more users, they wanted
> increased security at a platform level and increased assurances that badly
> written (not necessarily malicious) applications will not impact them
> (i.e. with
> returned handsets or support calls). Symbian has simply responded to
> market
> demands to deliver this in a way which ensures continued openness of the
> platform.
>
> To put it bluntly, options open to operators and manufacturers looking
> forward a
> few years were basically (1) closed phones or (2) open phones but with
> greater
> control over how sensitive functionality was used and its access approved.
> It is
> (2) which we are working to ensure for everyone's benefit!
>
> Moving to Symbian OS v9 does require a shift in mindset and expectations,
> but it
> is important to remember what we have enabled through a combination of the
> enhanced platform security our customers demanded AND Symbian Signed as a
> testing and certification program is the continued survival of open
> Symbian OS
> phones. And open Symbian OS phones which are able to penetrate much larger
> markets at that, i.e. allow your applications to reach many more paying
> users.
>
>>c) How developers can keep their secret if they have to show to
>>Symbian/manufactros/operators that they need this API to develop this
>>particular applications ?
>
> I appreciate information on this has so far been very thin on the ground
> from
> our part, as we have really been waiting for real Symbian OS v9-based SDK
> to
> come out from the UI vendors. The new Test Specification for Symbian
> Signed will
> also soon be published and it talks about the access to the (very small)
> set of
> 'Phone Manufacturer Approved' capabilities and, yes, you will need to
> discuss
> with the operator what these APIs are being used for - this does not
> necessarily
> mean sharing source code or your IP. Neither does it mean any discussions
> have
> to be conducted outside of an NDA or other protections.
>
> I should also point out that these most sensitive of all capabilities are
> expected to be used only in very, very rare cases so the vast majority of
> developers will never need to even consider these...
>
>>d) How delay will took to deliver on the market in terms of decision time
>>for the API release and signing process ? Does the time to market is
>
> The basic Symbian Signed process remains unchanged. We are not envisaging
> any
> extra delays will be introduced in the process for Symbian OS v9
> applications.
> As I said, few people will need to ever do this, but for the 'Phone
> Manufacturer
> Approved' capabilities where extra dialogue is needed with a manufacturer,
> imagine this being similar to the current waiver process - i.e. this will
> add a
> small extra delay to the process since it is an extra step...but this is
> the
> exception not the norm.
>
>>e) How many developers incurred into a problem with a certification TEST
>>house that fail your application for problem of the OS / manufactors ? how
>
> This is not new to Symbian OS v9. Any issues at the platform level which
> are
> beyond your control are traditionally treated as exceptions to the process
> and
> we are happy to approve these (e.g. on the 9500 there is a defect in the
> installer in some versions at least that the 'FN' (remove on uninstall)
> flag in
> PKG files is ignored - this is clearly an exception to that test).
>
>>f) How secure is Symbian 9 ? Do you think that signing and have a secure
>>OS
>>will help you to get more profits (aka stop copying your applications) or
>
> The enhanced platform security model in Symbian OS v9 is implemented at
> the very
> lowest level in the operating system and is designed to provide security
> and
> robustness for mass-market requirements (e.g. DRM) and allow greater
> control
> over sensitive API usage (through the capability model). There is nothing
> specifically designed to address the copying and cracking of applications
> per
> se.
>
> HOWEVER, getting applications installed on to a Symbian OS v9 phone can
> only be
> done through .SIS files (because of data caging, only the installer can
> place
> the binaries in the right place). This protection also extends to
> removable
> media too (i.e. Symbian OS will not execute an application on a removable
> disk
> unless it has a stored secure hash of it, generated after installation
> from a
> SIS on that particular phone, on the internal drive). If your SIS file is
> Symbian Signed because it uses some extended capabilities, a cracker will
> also
> have to get the application Symbian Signed to be able to redistribute any
> cracked version of your SIS file which can be installed on another phone
> easily.
> And they could therefore be traced through their ACS ID. This is in
> practice an
> extra practical barrier to cracking.
>
> The key feature of Symbian OS v9 which is likely to help your profits is
> volume
> - as I said above, it is destined to be used in a much higher number of
> devices
> and therefore you have a much larger addressable market.
>
> I hope some of these clarifications are useful.
>
> Kind regards,
>
> Phil[/color]

"Johan du Plessis" <[email protected]>
schreef in bericht news:ZXjeJIX2FHA.2948@extapps30...
> There are a lot more to this. _IF_ Symbian wanted more security and
> __WANTED__ to keep the developers happy they could have reached a
> compromise. Basically Symbian went to the Phone Developers and Networks
> but they ignored the developer completely.
>
> Statement "Applications compromise network security."
>
> They might, but it is irrelevent. Think about it, you can have access to
> GPRS/3G from your laptop. Locking down the API in such a
> way that you cannot port an application from your laptop to your cellphone
> in the name of network security does not make sense.
>
> The handset manufacturers have another reason they want to lock down their
> handsets. Most of the hardware functionality stays the same, it is only
> the software and packaging that differs. If for some reason you could
> download the next-generation features why would you buy a new handset? Of
> course, scratching an itch is one of the main motivations for open source
> software. Nokia and the like wouldn't want anybody else to fix their mess
> would they?
>
> If Symbian were an independent software company you could have everything
> as advertised plus security. Possible solutions that were not given
> consideration:
>
> 1) Give control to the users: If the user wants to install software that
> does XY and Z let them. Even if it requires that they enter a "software
> installation pin number" or the like.
> 2) Add the ability for more certificates. If an enterprise wants to deploy
> and application to all their employees on company phones I think they
> should have a right to install their own root certificate
> 3) Develop mechanisms whereby a user can "give" network credits to an
> application. E.g. allows 100KB to every application by default.
> Application can request more from the user. Isolated Storage. You get the
> idea. There are technical stuff that can be done to improve the situation.
>
> The big thing is that the certificates will do nothing for security,
> besides giving a false sense of it. Only one bug in the operating system
> can lead to a hole that a virus can exploit to run inside the kernel. In
> the age of the internet that code will be out there for other people to
> copy. Thus we have a situation were ethical programmers are punished but
> with minimal impact on the bad guys. Please also note, that if a third
> party wish to write an open-source firewall to prevent worms from
> exploiting an OS bug it would almost be impossible under the signing
> thing. Software that do automatic updates will be a mess as well. So in
> general, the platform will be a lot poorer from a security viewpoint as
> well IMHO.

Operators have a large influence because they are paying for most user's
handsets by heavily subsidizing them. As we say in Holland, "Wie betaalt,
bepaald." (The guy who pays the bill is the boss).

Then, operators *own* their networks. This means that (within limits set by
applicable law) they can do as please. This includes setting all kinds of
restrictions. Remember the Motorola A920?

Software is not selling phones at this moment. Nobody buys a phone because
he can download cool software for it. Otherwise, the software market for
Series 60 would be a *lot* better than it is now.
If software was selling devices, ISV's would have a stronger bargaining
position with handset manufacturers.

Nobody is using lots of bandwidth with the software they bought from ISV's.
If software was selling bandwidth, ISV's would have a stronger bargaining
position with operators.

--
Sander van der Wal
www.mBrainSoftware.com

> "Phil Spencer" <[email protected]> wrote in message
> news:[email protected]...[color=green]
>> Hi Roberto,
>>[color=darkred]
>>>I'm sure that this is an interesting points already discussed with Phil
>>>but
>>>I want to enlarge my question to the forum of what the developers think
>>>about it: (so I suggest that either me and Phil will not answer but the
>>>community answer to this question to better understand the poitn of view
>>>of
>>>the community)
>>
>> I know you are trying to stimulate discussion and I welcome that! But I
>> do feel
>> I should reply to this initial post because some of your questions are
>> based on
>> some basic misconceptions of Symbian OS v9, Symbian Signed and the
>> current
>> market outlook. Allow me to address a couple of points below to give the
>> discussion a fair and accurate context, and then we can see what other
>> developers think...
>>
>>>a) What's happen isf the signing process became mandatory (aka Symbian 9)
>>
>> The Signing process is not mandatory - around 60% of the APIs in Symbian
>> OS v9
>> are still open to use by any program with no extra restrictions, just as
>> now.
>> This new paper:
>>
>> http://www.symbian.com/developer/techlib/papers/cpp_sysarch.asp#osV9
>>
>> gives a high-level introduction to the concept.
>>
>>>tomorrow if the cost of signing , tools , partnership become more and
>>>more ?
>>
>> We will be talking in greater detail at the upcoming Smartphone Show
>> (www.smartphoneshow.com) about some new initiatives we're introducing
>> along with
>> various partners to help reduce costs and barriers to entry for
>> developers, and
>> open Symbian Signed up to serve the needs of every type of ISV. I
>> obviously
>> cannot say much more now, but there will be some very interesting
>> announcements
>> at the show which I'd urge people to keep an eye out for (or, better,
>> come to
>> the show to hear about and talk to myself and my colleagues in person
>> about your
>> thoughts on developing for Symbian OS)!
>>
>>>problems ? What's happen if the restricted API are not allowed to
>>>Manufactor
>>>X or Operator Y ? how Symbian will cover the cost raised to the developer
>>>to
>>
>> The basic fact to remember here is it is the manufacturers and operators
>> who
>> have DEMANDED this decision be placed in their hands. We have the
>> situation now
>> where Symbian OS is a very powerful open platform with myriad
>> possibilities for
>> developers to deliver compelling and innovative products which benefit
>> the
>> entire ecosystem. Sadly, there is also scope for this power to be abused
>> as we
>> are all well aware. The simple fact is that Symbian OS is destined to be
>> used in
>> many more handsets which ship in much higher volumes (the so-called "mid
>> range"
>> devices) and before operators and manufacturers are entirely comfortable
>> with
>> such a powerful platform reaching many millions more users, they wanted
>> increased security at a platform level and increased assurances that
>> badly
>> written (not necessarily malicious) applications will not impact them
>> (i.e. with
>> returned handsets or support calls). Symbian has simply responded to
>> market
>> demands to deliver this in a way which ensures continued openness of the
>> platform.
>>
>> To put it bluntly, options open to operators and manufacturers looking
>> forward a
>> few years were basically (1) closed phones or (2) open phones but with
>> greater
>> control over how sensitive functionality was used and its access
>> approved. It is
>> (2) which we are working to ensure for everyone's benefit!
>>
>> Moving to Symbian OS v9 does require a shift in mindset and expectations,
>> but it
>> is important to remember what we have enabled through a combination of
>> the
>> enhanced platform security our customers demanded AND Symbian Signed as a
>> testing and certification program is the continued survival of open
>> Symbian OS
>> phones. And open Symbian OS phones which are able to penetrate much
>> larger
>> markets at that, i.e. allow your applications to reach many more paying
>> users.
>>
>>>c) How developers can keep their secret if they have to show to
>>>Symbian/manufactros/operators that they need this API to develop this
>>>particular applications ?
>>
>> I appreciate information on this has so far been very thin on the ground
>> from
>> our part, as we have really been waiting for real Symbian OS v9-based SDK
>> to
>> come out from the UI vendors. The new Test Specification for Symbian
>> Signed will
>> also soon be published and it talks about the access to the (very small)
>> set of
>> 'Phone Manufacturer Approved' capabilities and, yes, you will need to
>> discuss
>> with the operator what these APIs are being used for - this does not
>> necessarily
>> mean sharing source code or your IP. Neither does it mean any discussions
>> have
>> to be conducted outside of an NDA or other protections.
>>
>> I should also point out that these most sensitive of all capabilities are
>> expected to be used only in very, very rare cases so the vast majority of
>> developers will never need to even consider these...
>>
>>>d) How delay will took to deliver on the market in terms of decision time
>>>for the API release and signing process ? Does the time to market is
>>
>> The basic Symbian Signed process remains unchanged. We are not envisaging
>> any
>> extra delays will be introduced in the process for Symbian OS v9
>> applications.
>> As I said, few people will need to ever do this, but for the 'Phone
>> Manufacturer
>> Approved' capabilities where extra dialogue is needed with a
>> manufacturer,
>> imagine this being similar to the current waiver process - i.e. this will
>> add a
>> small extra delay to the process since it is an extra step...but this is
>> the
>> exception not the norm.
>>
>>>e) How many developers incurred into a problem with a certification TEST
>>>house that fail your application for problem of the OS / manufactors ?
>>>how
>>
>> This is not new to Symbian OS v9. Any issues at the platform level which
>> are
>> beyond your control are traditionally treated as exceptions to the
>> process and
>> we are happy to approve these (e.g. on the 9500 there is a defect in the
>> installer in some versions at least that the 'FN' (remove on uninstall)
>> flag in
>> PKG files is ignored - this is clearly an exception to that test).
>>
>>>f) How secure is Symbian 9 ? Do you think that signing and have a secure
>>>OS
>>>will help you to get more profits (aka stop copying your applications) or
>>
>> The enhanced platform security model in Symbian OS v9 is implemented at
>> the very
>> lowest level in the operating system and is designed to provide security
>> and
>> robustness for mass-market requirements (e.g. DRM) and allow greater
>> control
>> over sensitive API usage (through the capability model). There is nothing
>> specifically designed to address the copying and cracking of applications
>> per
>> se.
>>
>> HOWEVER, getting applications installed on to a Symbian OS v9 phone can
>> only be
>> done through .SIS files (because of data caging, only the installer can
>> place
>> the binaries in the right place). This protection also extends to
>> removable
>> media too (i.e. Symbian OS will not execute an application on a removable
>> disk
>> unless it has a stored secure hash of it, generated after installation
>> from a
>> SIS on that particular phone, on the internal drive). If your SIS file is
>> Symbian Signed because it uses some extended capabilities, a cracker will
>> also
>> have to get the application Symbian Signed to be able to redistribute any
>> cracked version of your SIS file which can be installed on another phone
>> easily.
>> And they could therefore be traced through their ACS ID. This is in
>> practice an
>> extra practical barrier to cracking.
>>
>> The key feature of Symbian OS v9 which is likely to help your profits is
>> volume
>> - as I said above, it is destined to be used in a much higher number of
>> devices
>> and therefore you have a much larger addressable market.
>>
>> I hope some of these clarifications are useful.
>>
>> Kind regards,
>>
>> Phil[/color]
>
>[/color]

>There are a lot more to this. _IF_ Symbian wanted more security and
>__WANTED__ to keep the developers happy they could have reached a
>compromise. Basically Symbian went to the Phone Developers and Networks but
>they ignored the developer completely.

This *is* the compromise. At one end of the scale, you have totally open,
unbounded phones (think the first releases of Symbian OS v6.1). At the other end
of the scale you have totally locked down phones (think the non-UIQ Symbian
OS-based handsets on NTT DoCoMo). In the middle-ground, you have the situation
we have worked hard to create to serve there needs of operators, manufacturers
AND developers - a situation whereby open phones remain, applications can still
be created and sold but for some more sensitive functionality which causes
operators/manufacturers most concern, there are tighter access controls in
Symbian OS v9, handled through programs such as Symbian Signed (which itself has
become cheaper, faster and easier to use and we continue to work to evolve it in
this manner). Now, you tell me logically which is preferable for developers
trying to sell their applications - a marketh wit slightly more consideration
for security than may have existed in the past...or no market at all?

>They might, but it is irrelevent. Think about it, you can have access to
>GPRS/3G from your laptop. Locking down the API in such a
>way that you cannot port an application from your laptop to your cellphone
>in the name of network security does not make sense.

You can do this. I do it myself. By setting up a modem, making a connection and
finally dialling something like *#99#. Not something your average users knows
how to do or will ever do...and more to the point, something which requires
active involvement and investigation from the user first for the very purpose of
using the network (i.e. spending money). This is not a mass-market use of mobile
phones...Symbian OS is. For Symbian OS applications whose very purpose is
network-based, Symbian Signed merely enforces best practice for this usage (i.e.
effectively brings in the active user involvement, as in your modem example) to
ensure the user is aware of what is happening.

>scratching an itch is one of the main motivations for open source software.
>Nokia and the like wouldn't want anybody else to fix their mess would they?

Perhaps you have not seen the details of the Freeware and Open Source Symbian
Signed route to market we announced at The Smartphone Show. Some links for you:

http://www.symbian.com/news/pr/2005/pr20053160.html
http://www.symbianone.com/content/view/2391/118/
https://www.symbiansigned.com/app/page/freeware

>If Symbian were an independent software company you could have everything as
>advertised plus security. Possible solutions that were not given
>consideration:

Symbian is run as an independant company. But any company has customers to
consider and market needs to respond to - it really is as simple as that,
there's no conspiracy!

>1) Give control to the users: If the user wants to install software that
>does XY and Z let them.

This is the current situation for the most part...and that is OK in the
higher-end devices with more tech-savvy users. As you move in to the mass-market
(100s of millions of units vs. 10s of millions as now) with lower-priced,
mid-range handsets, users become less tech-savvy. Complexity results in returned
handsets, higher support costs to operators, misunderstandings, etc., etc.
Similar to my response above: would you rather have a market measured in 10s of
millions or 100s of millions to address with your products?

>2) Add the ability for more certificates. If an enterprise wants to deploy
>and application to all their employees on company phones I think they should
>have a right to install their own root certificate

This is entirely possible, but it's a matter between the Enterprise/Handset
vendor/Operator and not one which will concern or affect end-users.

Regards,

Phil

You state:
> This is entirely possible, but it's a matter between the
> Enterprise/Handset
> vendor/Operator and not one which will concern or affect end-users.

in connection with custom root certificates. How do you do it? How much will
it cost? Bearing in mind that I will not be able to jet around the world to
arrange all of it with individual handset manufacturers - it will cost to
much and take to long. Do symbian signed have enterprise software
certificate program?

"Phil Spencer" <[email protected]> wrote in message
news:[email protected]...[color=green]
> >There are a lot more to this. _IF_ Symbian wanted more security and
>>__WANTED__ to keep the developers happy they could have reached a
>>compromise. Basically Symbian went to the Phone Developers and Networks
>>but
>>they ignored the developer completely.
>
> This *is* the compromise. At one end of the scale, you have totally open,
> unbounded phones (think the first releases of Symbian OS v6.1). At the
> other end
> of the scale you have totally locked down phones (think the non-UIQ
> Symbian
> OS-based handsets on NTT DoCoMo). In the middle-ground, you have the
> situation
> we have worked hard to create to serve there needs of operators,
> manufacturers
> AND developers - a situation whereby open phones remain, applications can
> still
> be created and sold but for some more sensitive functionality which causes
> operators/manufacturers most concern, there are tighter access controls in
> Symbian OS v9, handled through programs such as Symbian Signed (which
> itself has
> become cheaper, faster and easier to use and we continue to work to evolve
> it in
> this manner). Now, you tell me logically which is preferable for
> developers
> trying to sell their applications - a marketh wit slightly more
> consideration
> for security than may have existed in the past...or no market at all?
>
>>They might, but it is irrelevent. Think about it, you can have access to
>>GPRS/3G from your laptop. Locking down the API in such a
>>way that you cannot port an application from your laptop to your cellphone
>>in the name of network security does not make sense.
>
> You can do this. I do it myself. By setting up a modem, making a
> connection and
> finally dialling something like *#99#. Not something your average users
> knows
> how to do or will ever do...and more to the point, something which
> requires
> active involvement and investigation from the user first for the very
> purpose of
> using the network (i.e. spending money). This is not a mass-market use of
> mobile
> phones...Symbian OS is. For Symbian OS applications whose very purpose is
> network-based, Symbian Signed merely enforces best practice for this usage
> (i.e.
> effectively brings in the active user involvement, as in your modem
> example) to
> ensure the user is aware of what is happening.
>
>>scratching an itch is one of the main motivations for open source
>>software.
>>Nokia and the like wouldn't want anybody else to fix their mess would
>>they?
>
> Perhaps you have not seen the details of the Freeware and Open Source
> Symbian
> Signed route to market we announced at The Smartphone Show. Some links for
> you:
>
> http://www.symbian.com/news/pr/2005/pr20053160.html
> http://www.symbianone.com/content/view/2391/118/
> https://www.symbiansigned.com/app/page/freeware
>
>>If Symbian were an independent software company you could have everything
>>as
>>advertised plus security. Possible solutions that were not given
>>consideration:
>
> Symbian is run as an independant company. But any company has customers to
> consider and market needs to respond to - it really is as simple as that,
> there's no conspiracy!
>
>>1) Give control to the users: If the user wants to install software that
>>does XY and Z let them.
>
> This is the current situation for the most part...and that is OK in the
> higher-end devices with more tech-savvy users. As you move in to the
> mass-market
> (100s of millions of units vs. 10s of millions as now) with lower-priced,
> mid-range handsets, users become less tech-savvy. Complexity results in
> returned
> handsets, higher support costs to operators, misunderstandings, etc., etc.
> Similar to my response above: would you rather have a market measured in
> 10s of
> millions or 100s of millions to address with your products?
>
>>2) Add the ability for more certificates. If an enterprise wants to deploy
>>and application to all their employees on company phones I think they
>>should
>>have a right to install their own root certificate
>
> This is entirely possible, but it's a matter between the
> Enterprise/Handset
> vendor/Operator and not one which will concern or affect end-users.
>
> Regards,
>
> Phil[/color]

> Similar to my response above: would you rather have a market measured in
> 10s of
> millions or 100s of millions to address with your products?

I'd rather have a market measured in 10s of millions. What's the use of
large market if entry barrier is too high for individual developer?

-- Harry

All seems to be perfect to Symbian but main delveloper start to put their
eyes alone from Symbian just because Symbian left them as the last thing in
a scale of priorities and left them only the cost to be afforded and peanuts
in terms of profti.... so thanks Symbian we are proud to be a Symbian
developer....

No, its not all perfect to Symbian. Its a compromise. However it seems to be
working pretty well for *most* of the developer community.

I refer you to Sander van der Wal's comments of 19/9/05 in response to this
thread which I think cover the economics of the situation fairly well.

Regards
Hamish

"RobyOneKenoby" <[email protected]> wrote in message
news:[email protected]...
> All seems to be perfect to Symbian but main delveloper start to put their
> eyes alone from Symbian just because Symbian left them as the last thing
in
> a scale of priorities and left them only the cost to be afforded and
peanuts
> in terms of profti.... so thanks Symbian we are proud to be a Symbian
> developer....
>
>