- 01-01-13, 06:42 PM #26
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 Name:Rully Adrian Santosa
Registrant Street1:685B Jurong West Street 64
Registrant Postal Code:642685
Registrant Phone Ext.:
Registrant FAX Ext.:
Registrant Email:[email protected]
Admin Name:Rully Adrian Santosa
Admin Street1:685B Jurong West Street 64
Admin Postal Code:642685
Admin Phone Ext.:
Admin FAX Ext.:
Admin Email:[email protected]
Tech Name:Rully Adrian Santosa
Tech Street1:685B Jurong West Street 64
Tech Postal Code:642685
Tech Phone Ext.:
Tech FAX Ext.:
Tech Email:[email protected]
(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...
- 01-01-13, 07:05 PM #27
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.
Last edited by BuzzStarField; 01-01-13 at 07:16 PM.
- 01-01-13, 07:41 PM #28
Scary apps that need full disclosure
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
- 01-01-13, 08:16 PM #29
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!
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.
- 01-02-13, 05:48 AM #32
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:
Your turn now - explain to me how RIM and this particular vendor are sullying you and everyone else?
- 01-02-13, 09:10 AM #34
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?
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.
- 01-09-13, 06:02 AM #37
Re: Scary apps that need full disclosure
- CrackBerry User
01-09-13, 10:28 AM #38
- 60 Posts
- CrackBerry Genius of Geniuses
01-09-13, 11:47 AM #39
- 5,330 Posts
I think this Handster business is hurting devs you like buzz and they should never have been allowed into appworld.
- 01-09-13, 11:25 PM #40
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.
- 01-09-13, 11:46 PM #41
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.
- 01-10-13, 07:13 AM #42
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.
- CrackBerry Genius
01-10-13, 07:19 AM #43
- 1,810 Posts
- CrackBerry User
01-11-13, 11:23 AM #46
- 74 Posts
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.
- 01-11-13, 04:29 PM #47
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.
- CrackBerry User
01-12-13, 10:52 AM #48
- 60 Posts
- 01-12-13, 11:30 AM #50
- By pacoman03 in forum PlayBook Android App SideloadingReplies: 13Last Post: 10-05-12, 08:55 PM
- By Chanimal in forum BlackBerry Torch 9800Replies: 0Last Post: 06-15-11, 05:00 PM
- By Chanimal in forum BlackBerry OS AppsReplies: 0Last Post: 06-15-11, 05:00 PM
- By BenjyC in forum BlackBerry Curve 83xxReplies: 6Last Post: 10-23-09, 11:04 AM
- By BenjyC in forum BlackBerry OS AppsReplies: 6Last Post: 10-23-09, 11:04 AM