[Branta]

OK now it gets even more interesting. I just downloaded Resolution Diary, another CB featured PlayBook app. I've started to check the support contact info to know who or what kind developer it is. In this case the dev listed [email protected] as his contact info. Well a .org domain is reserved for not for profit organizations and typically not registered to individuals and not used as a mailbox landing point. Then the full domain name of santosa.org doesn't even exist on the Internet!

(redacted):~$ whois santosa.org
...
Domain ID159486554-LROR
Domain Name:SANTOSA.ORG
Created On:23-Jun-2010 08:24:57 UTC
Last Updated On:20-May-2012 10:32:24 UTC
Expiration Date:23-Jun-2013 08:24:57 UTC
Sponsoring Registrar:Wild West Domains, LLC (R120-LROR)
Status:CLIENT DELETE PROHIBITED
Status:CLIENT RENEW PROHIBITED
Status:CLIENT TRANSFER PROHIBITED
Status:CLIENT UPDATE PROHIBITED
Registrant ID:CR50732241
Registrant Name:Rully Adrian Santosa
Registrant Street1:685B Jurong West Street 64
Registrant Street2:
Registrant Street3:
Registrant City:Singapore
Registrant State/Province:
Registrant Postal Code:642685
Registrant Country:SG
Registrant Phone:+975.91799
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:[email protected]
Admin ID:CR50732243
Admin Name:Rully Adrian Santosa
Admin Street1:685B Jurong West Street 64
Admin Street2:
Admin Street3:
Admin City:Singapore
Admin State/Province:
Admin Postal Code:642685
Admin Country:SG
Admin Phone:+975.91799
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email:[email protected]
Tech ID:CR50732242
Tech Name:Rully Adrian Santosa
Tech Street1:685B Jurong West Street 64
Tech Street2:
Tech Street3:
Tech City:Singapore
Tech State/Province:
Tech Postal Code:642685
Tech Country:SG
Tech Phone:+975.91799
Tech Phone Ext.:
Tech FAX:
Tech FAX Ext.:
Tech Email:[email protected]
Name Server:NS-1404.AWSDNS-47.ORG
Name Server:NS-194.AWSDNS-24.COM
Name Server:NS-1594.AWSDNS-07.CO.UK
Name Server:NS-1004.AWSDNS-61.NET
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
DNSSEC:Unsigned


(redacted):~$ dig MX santosa.org

; <<>> DiG 9.4.2-P2.1 <<>> MX santosa.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36510
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;santosa.org. IN MX

;; ANSWER SECTION:
santosa.org. 215 IN MX 10 aspmx.l.google.com.
santosa.org. 215 IN MX 30 alt2.aspmx.l.google.com.
santosa.org. 215 IN MX 20 alt1.aspmx.l.google.com.
santosa.org. 215 IN MX 40 aspmx2.googlemail.com.
santosa.org. 215 IN MX 50 aspmx3.googlemail.com.

Looks real enough to me. Name, address, zip, phone...

[BuzzStarField]

OK now it gets even more interesting. I just downloaded Resolution Diary, another CB featured PlayBook app. I've started to check the support contact info to know who or what kind developer it is. In this case the dev listed [email protected] as his contact info. Well a .org domain is reserved for not for profit organizations and typically not registered to individuals and not used as a mailbox landing point. Then the full domain name of santosa.org doesn't even exist on the Internet!

How can an app get approved with a fake point of contact? Does anyone check these people out?

Information collection and fake addresses being allowed to pass shows a great lax on the part of RIM. Apple maybe, Google, its a given but Research In Motion, not acceptable.

There are a lot of unfounded conspiracy theories being presented in this thread and I think that some of you are a tad paranoid. If you are going to sully a developer's good name at least you should know what you are talking about. In an effort to clear the air, here is the scoop on this developer.

The author of this app (listed in App World as Rully Adrian Santosa) gives a lot more information to the public than I feel is necessary. The domain in question is indeed registered to the author. He used his real name and his street address in Singapore and phone number are available if you want them. I got this information by using Domain Tools to do a whois search.

Santosa.org - Santosa

It is probable that Rully has just not gotten around to putting up his web page yet. So what exactly is wrong with the way that the author identified himself? And what has RIM done wrong?

PS: It is not clear if you have a problem with the permissions that you are asked to give for this app. If you do have a question about his app, why not send an email to the author and ask him what he is up to? This is why he gave a valid email address and I am sure that he would like to hear form you. If you can, try to be nice. Oh and if you don't mind, please report back here when you have completed your investigation.

[Crowezine]

This is why it's better to stick to certain developers, like in a thread I've posted before; XLabz, Cooklet, Union etc. Random developers tend to have shoddy apps, and you can sometimes tell this by swiping from the top bezel of a PlayBook, because a little grey bar will appear. Normally, this means It's a sideloaded app, but most of all, it can indicate a shoddy app, and furthermore, a shoddy developer.

Sent from my BlackBerry 9320 using Tapatalk

[BuzzStarField]

This is why it's better to stick to certain developers, like in a thread I've posted before; XLabz, Cooklet, Union etc. Random developers tend to have shoddy apps, and you can sometimes tell this by swiping from the top bezel of a PlayBook, because a little grey bar will appear. Normally, this means It's a sideloaded app, but most of all, it can indicate a shoddy app, and furthermore, a shoddy developer.

Sent from my BlackBerry 9320 using Tapatalk

In my opinion, your post is off-topic and has nothing to do with the OP's complaint about unnecessary permissions being required. Further, I don't think that your rules of thumb are all that useful to someone who is trying to pick a winning app or a competent developer..

For starters, not every Android app in App world is "shoddy" and every developer began as a "random" developer. Even established developers can make a mistake and issue a bad release. I have done this once or twice myself and I only have one app in App World at the current time.. Am I a "random" developer because I don't have your endorsement and am missing from your list? If this is what you think then I hate you. Something else - when I "sideload" my (admittedly non-Android) app during testing, a little grey bar never shows. Does this mean I am not a random developer and that everyone should buy my app? If so, thanks for the endorsement!

[Zildjian71]

Proving with whois that someone owns the domain does not prove legitimate support contact. There are literally thousands of inactive registered domains and finding them isn't difficult with web tools like Whois, personally I use Netcraft. The point is there is no functional point of contact and it got approved in App World. I'm not faulting a single man operation, more power to them, how did the app get approved for publication with no viable point of contact?

This isn't sullying a developer its doubting the thoroughness of the application process for publication.

Transparent intent of use of data collected and proof of viable support are not conspiracies they are mature and professional.

Both are valid issues that have been faulted at both Apple and Google, which is something RIM needs to avoid to maintain the presence of a more professional reputation than what both Apple and Google have displayed so far.

Raise the bar not in just user experience on the device but in all aspects of delivery of support and services as well.

A corporate disregard for the end user sullies everyone.

[FSeverino]

i would feel much better with answering a dew questions before playing the game as a one-time thing instead of them always having access

[BuzzStarField]

Proving with whois that someone owns the domain does not prove legitimate support contact. There are literally thousands of inactive registered domains and finding them isn't difficult with web tools like Whois, personally I use Netcraft. The point is there is no functional point of contact and it got approved in App World. I'm not faulting a single man operation, more power to them, how did the app get approved for publication with no viable point of contact?.

You evidence of fraud is lacking to say the least. If you did a whois on the domain in my support address, you would find that Bell Canada owns it.

What makes you think that there is "no valid point of contact"? It is possible to have an email server but not run a webserver at a specific IP address. Did you take my suggestion to contact the developer via email - did your message get bounced?

Did you know that RIM demands verification of email address, a valid credit card and valid PayPal account (even if you don't sell your apps)? RIM accesses the credit card twice when you register as a vendor and is not used again - they debit the card and then immediately credit it with $1 to prove that you are a real person. When I signed up, they demanded a copy of my government-supplied photo identification and a notarized verification of my name/address. If you register as a legal business, then you have to satisfy other requirements. The process may have changed since I signed up but I will attest to the fact that RIM must know all about you before they will allow you to upload apps to App World.

If you are interested, you can scroll through (I mean read) the developers' agreement and then have a look at the application form. Here is the URL:

https://appworld.blackberry.com/isvp...r/reg_terms.do

Your turn now - explain to me how RIM and this particular vendor are sullying you and everyone else?

[backfire101]

mail santosa.org is a google mailbox. Simple to be tested with mxtools.

[Techno-Emigre]

Its too bad this conversation took such a negative turn. I feel it is an important one. Developers are here to give us things we want. We need to understand what they need and why. Developers need to understand legitimate consumer concerns over privacy issues. Perhaps RIM needs to help create safe ways to bring those two camps closer together. Let's teach each other rather than lash out. Not only is accuracy important when making a statement, but the "tone" (how it sounds to the reader) is just as important. I think we all want very similar things. This is the year that BB10 astounds the world, right?

[Zildjian71]

I agree my tone can be different. My points of concern are still just as real regardless.

As far as my understanding goes in the requirements of regestering a .org domain requires proof of not for profit and are usually not a mail only address. Yes any one can set up a proxy email address with most mail providers providing proof of domain ownership, but not restricted domains such as .gov .edu and .org. These all require proof of domain ownership. Knowing that is the rule set be ICANN.org seeing a .org as a support address raises red flags and the fact that the above address has no live server visible to a web browser raises even more red flags.

Having been burnt in Internet commerce and having to have settled a dispute over a registered domain (my company won the dispute) I'm leery of things that do not look right. I would rather be corrected for misstrusting than get burnt again.

Thank you for clearing up the RIM developer requirements. Apparently Google and Apple are not as thorough.

Specifically thank you M. Rice.

[Zildjian71]

FYI for anyone still on this thread in the United States:

http://www.nytimes.com/2013/01/06/te...src=rechp&_r=0

[Xopher]

But why exactly do small time developers need to know where I am at?

Is the app free? Does it have ads? If there are banner ads within the app, internet access may be needed. The ad module can use location (coarse or specific) to tailor the ads by region. The ad service will also use device identifying information. It doesn't include any personal information on the ad request, but it does require those permissions.

[pbluv]

Is the app free? Does it have ads? If there are banner ads within the app, internet access may be needed. The ad module can use location (coarse or specific) to tailor the ads by region. The ad service will also use device identifying information. It doesn't include any personal information on the ad request, but it does require those permissions.

That's fine, but why is it so difficult for the developer to explain this in their app description. If they were upfront about the need, it goes a long way to establishing trust and credibility, and allows the user to make a decision before downloading the app.

[Cynycl]

Did you know that RIM demands verification of email address, a valid credit card and valid PayPal account (even if you don't sell your apps)? RIM accesses the credit card twice when you register as a vendor and is not used again - they debit the card and then immediately credit it with $1 to prove that you are a real person. When I signed up, they demanded a copy of my government-supplied photo identification and a notarized verification of my name/address. If you register as a legal business, then you have to satisfy other requirements. The process may have changed since I signed up but I will attest to the fact that RIM must know all about you before they will allow you to upload apps to App World.

I don't see how this would work with an outfit like Handster who seems to be spamming appworld with junk/suspect apps that want access to everything they can possibly get (for no apparent reason other than to have it). I've watched many of these apps be posted and shortly removed from appworld. As a mass distributor for spam/suspect apps I doubt they have any quality control over these apps.

I think this Handster business is hurting devs you like buzz and they should never have been allowed into appworld.

[BuzzStarField]

I don't see how this would work with an outfit like Handster who seems to be spamming appworld with junk/suspect apps that want access to everything they can possibly get (for no apparent reason other than to have it). I've watched many of these apps be posted and shortly removed from appworld. As a mass distributor for spam/suspect apps I doubt they have any quality control over these apps.

I think this Handster business is hurting devs you like buzz and they should never have been allowed into appworld.

I was addressing one particular poster's complaint that one particular vendor might be a bad apple and that this one case was evidence that RIM did not require potential vendors to identify themselves so that disgruntled customers could contact the perpetrator. The main thesis of this thread is that App World is rife with spy-ware and the the particular vendor was a perpetrator. I didn't think that the poster made a very good case and I wanted to say so.

One thing that bothers me about this thread is that no one is identifying specific apps that ask for random access to a users location, files etc for no good reason. I see a lot of highly generalized accusations but nothing that is really helpful in educating consumers about how to recognize bad apples. I am not a prolific downloader of free apps, but those that I have loaded on my device have not been guilty of asking for unnecessary permissions. That being the case, I would really appreciate it if you could identify some specific apps form Handster or otherwise that you suspect of being spyware. I would like to conduct a bit of an investigation for myself.

[KermEd]

I can't answer for all dvs but

Some of my apps ask for one off reasons. For example if you want to use logging in secure browser, it will query device information. Not because I want your pin bug because I want to know what language you are using (troubleshooting) or what Os build you have (did u install a buggy rim patch they pulled) or sometimes I need model info to see if an issue is related to a specific cpu model.

I also have open source apps I've recompiled that ask stuff too. But because I don't like modifying known good open source apps, I leave the security.

It would be better if rim gave us space in the pop up to say why we need it (not many people read appworld discriptions.

But I have no hard feelings when someone gets mad about it.

There are lots of creepy people out there.

[BuzzStarField]

@KermEd
It would also be nice is the stock warnings weren't so ominous. It is overkill to tell a novice user that I will be able to read/modify ALL of their sensitive information if they say "yes" to file access. The pop-up is a blunt instrument and I can understand why some users hesitate to say "yes". But just because I CAN use shared space doesn't mean that I WILL send all their images to my server and data-mine their documents. If all I want to do is enable the user to backup/restore app settings in the shared space, it's a huge problem that the user thinks that I am able to read their email, address book and so on. In fact, the PlayBook doesn't have any APIs that would allow me to do these nefarious things. A scary pop-up during the installation process almost guarantees that the user will deny access and cripple the app.

People should also realize that a some developers are not as experienced as others. They might fail to allow for the likelihood that a user will say "no, I don't want you to see my files". But then again there is a reason why apps can be offered for free in App World - not all app were created equal. A good programmer must anticipate that users will find a way to break his "perfect" app and must spend many hours writing code that has little to do with the app's main mission. Even so, no app is completely *****-proof. It takes one line of code to try to access the file system - but it takes perhaps two hundred lines of code to include all of the necessary exception-handling routines, the custom warning pop-ups and the on-board help system. Mistakes will be made- that's why we post a support email address. I wish that more customers would use it instead of writing a nasty review every time something goes wrong.

And to those who think that an explanation in the app's description is a good solution, I would counter by saying that my description is already too long, and judging by some of the email I get, far too many users fail to read it completely before downloading the app. This space is meant to be my sales-pitch - treating it as a help system by trying to explain every nuance in my app is just not feasible.

[Banco]

@KermEd
It would also be nice is the stock warnings weren't so ominous. It is overkill to tell a novice user that I will be able to read/modify ALL of their sensitive information if they say "yes" to file access. The pop-up is a blunt instrument and I can understand why some users hesitate to say "yes". But just because I CAN use shared space doesn't mean that I WILL send all their images to my server and data-mine their documents. If all I want to do is enable the user to backup/restore app settings in the shared space, it's a huge problem that the user thinks that I am able to read their email, address book and so on. In fact, the PlayBook doesn't have any APIs that would allow me to do these nefarious things. A scary pop-up during the installation process almost guarantees that the user will deny access and cripple the app.

This is a really important point I feel. When I see that option I tend to deny completely and uninstall the app if it then doesn't work, simply because I don't know what that means and what the app actually is able to obtain. I feel that Android actually does this better in terms of explaining what the app does and doesn't have access to on the device. Certainly I'm less likely to routinely deny everything on the basis that I don't know how much access it is getting.

[KermEd]

Agreed

I mean don't get me wrong - I'm glad there are warnings. But it does need better explanation.

Sent from my BlackBerry 9360 using Tapatalk

[Xopher]

That's fine, but why is it so difficult for the developer to explain this in their app description. If they were upfront about the need, it goes a long way to establishing trust and credibility, and allows the user to make a decision before downloading the app.

I definitely agree. Devs need to do a better job of informing what permissions are used for.

[coolpowers]

I agree that "most people don't read descriptions" but would counter that the people who take app security seriously DO read the descriptions, so it's a valid place for a dev to explain why permissions are needed.

Usually an app that seems to ask for unrelated permissions (especially games) will do so for one of three reasons - metrics, ads, and social elements (such as leaderboards). I'm only planning on using ScoreLoop for my BB games, because it's RIM-owned and hopefully users will trust it. ScoreLoop does have social elements though, so it may ask for device identifying information or location. Same with ads and metrics. I don't use metrics myself, but there are valid reasons for a dev to want to user them - automatically tracking where players fail in a game, crash reports, and so on. Ads can be tricky - there are some shady business practices so I prefer to only ever use "official" ad services. Actually I'd prefer not to have ads at all.

So, as a developer and user I share your concerns, but ask that you don't jump the gun. The best way to keep ads out of your apps is to support developers and show that there is a healthy paid market on the platform.

[Techno-Emigre]

Thanks so much for the contributions here. I just feel like this is a vital discussion and all voices need to be at the table. Good point about discriptions in AppWorld. That really is where you need to promote your app. Maybe FAQ link? All I know is that I have a lot to learn and we all had better be discussing this.

If CB isn't going to write any articles on this, maybe this should be a sticky? I have no idea how to ask for that. Not even sure everyone here would feel comfortable with it. It would be cool to have a short FAQ file for newbies as a sticky. That is all way beyond my skills, tho.

[pbluv]

Perhaps another article like BlackBerry 101 - Application permissions | CrackBerry.com for the playbook would help.

[Techno-Emigre]

Thanks for reminding me. I read it so long ago I forgot about it and it was useful. However, this is a constantly evolving topic. I would sure like to see periodic articles from CB on this and other security related topics.

[Techno-Emigre]

On the same note .. I would appreciate some guidance from CB (or anyone on this thread) about how the Java 10 issue should be handled on our devices. I didn't even pick up on this until this morning. Dept of Homeland Security is recommending Java (not JavaScript) be disabled. I can only find JavaScript on my Berries. Is this a concern?