Re: Passing "origin" with intents

Many use cases don't require that origin be disclosed, so I think
making a MUST requirement on origin disclosure isn't as good as making
the disclosure optional. It may be that for some intents, origin
disclosure is mandatory to make them work, but at the API level, it
ought to be optional.

I think having the origin disclosed as an 'origin' property on the
intent object, the way Conrad proposed, is a good idea. How shall the
client cause the UA to attach that field? Some options:

1. a "useOrigin: true" member of the constructor literal.
2. an "origin: xyz" member of the constructor literal.
3. Set up out-of-band by the user as a property of the registered
service. (i.e. "always disclose origin to this service" registration
option)
4. Possible exception: for explicit intents, always attach the origin.

Does (3) (and possibly 4) solve all the use cases we know about? If
so, that's the least intrusive modification to the API.


On Wed, Aug 29, 2012 at 7:05 AM, Josh Soref <jsoref@rim.com> wrote:
> Paul wrote:
>> If the client is receiving data back from a service, it too should be aware of the
>> origin.
>
> I object to this.
>
> If a service is sending back data, it should be able to say whether it wants its origin to be shared with the client. And the user should be able to have the UA strip the origin.
>
> If I'm using an internal secret service, my service's existence shouldn't be leaked to the world just because I'm using it with external sites.
>
> The design of intents should be such that I could hand fill in all the values requested by the client and the client would accept it without discriminating against me doing that.
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Wednesday, 29 August 2012 16:15:36 UTC