Waiver for CON-02?

Our application was rejected because the privacy dialog was missing. The 
application is a virtual switchboard client, and uses the PIM to let the 
user easily transfer calls and set up conferences; it also uses 
NetworkServices to send DTMF tones over an open line, and location to 
automatically switch languages. The customer (the operator) does not 
want this dialog, and privacy-wise the dialog is redundant since it is 
obvious to the user what the application does. Is it possible to avoid 
putting this in by having the operator sign a waiver?

Stig Tollefsen

"Stig Tollefsen" <sto@antares.no> wrote in message 
news:f5XbQHdVHHA.412@UKCOL01WWEB01.symbian.intra...
> Our application was rejected because the privacy dialog was missing. The 
> application is a virtual switchboard client, and uses the PIM to let the 
> user easily transfer calls and set up conferences; it also uses 
> NetworkServices to send DTMF tones over an open line, and location to 
> automatically switch languages. The customer (the operator) does not want 
> this dialog, and privacy-wise the dialog is redundant since it is obvious 
> to the user what the application does. Is it possible to avoid putting 
> this in by having the operator sign a waiver?

That's what I would expect. Operators are the driving force behind Symbian 
Signed, so having an operator-requested feature not passing Symbian Signed 
is a political oddity.


-- 
Sander van der Wal
www.mBrainSoftware.com 

Sander van der Wal wrote:
> "Stig Tollefsen" <sto@antares.no> wrote in message 
> news:f5XbQHdVHHA.412@UKCOL01WWEB01.symbian.intra...
>> Our application was rejected because the privacy dialog was missing.
The 
>> application is a virtual switchboard client, and uses the PIM to let
the 
>> user easily transfer calls and set up conferences; it also uses 
>> NetworkServices to send DTMF tones over an open line, and location to 
>> automatically switch languages. The customer (the operator) does not
want 
>> this dialog, and privacy-wise the dialog is redundant since it is
obvious 
>> to the user what the application does. Is it possible to avoid putting

>> this in by having the operator sign a waiver?
> 
> That's what I would expect. Operators are the driving force behind Symbian

> Signed, so having an operator-requested feature not passing Symbian Signed

> is a political oddity.
> 
> 
However, the waivers are granted by the manufacturer not operator. Not 
sure what would happen in this case. IMO displaying the privacy dialog 
at least once is not asking for too much.

"AMK" <amk@example.com> wrote in message 
news:yp8JJ5nVHHA.4132@UKCOL01WWEB01.symbian.intra...
> Sander van der Wal wrote:
>> "Stig Tollefsen" <sto@antares.no> wrote in message 
>> news:f5XbQHdVHHA.412@UKCOL01WWEB01.symbian.intra...
>>> Our application was rejected because the privacy dialog was
missing. The 
>>> application is a virtual switchboard client, and uses the PIM to
let the 
>>> user easily transfer calls and set up conferences; it also uses 
>>> NetworkServices to send DTMF tones over an open line, and location
to 
>>> automatically switch languages. The customer (the operator) does
not 
>>> want this dialog, and privacy-wise the dialog is redundant since it
is 
>>> obvious to the user what the application does. Is it possible to
avoid 
>>> putting this in by having the operator sign a waiver?
>>
>> That's what I would expect. Operators are the driving force behind 
>> Symbian Signed, so having an operator-requested feature not passing 
>> Symbian Signed is a political oddity.
>>
>>
> However, the waivers are granted by the manufacturer not operator. Not 
> sure what would happen in this case. IMO displaying the privacy dialog at 
> least once is not asking for too much.

Operators are the manufacturers biggest clients. It's unlikely that a 
manufacturer will refuse such a request. Get the operator involved is what I 
would do.

As an alternative, it might be possible for the operator to add a root 
certificate to the device so they can do their own signing. But that's a lot 
of extra work.


-- 
Sander van der Wal
www.mBrainSoftware.com