[Q] Public data access... - Java for Android App Development

I'm looking to make an app that will store and relay wait times to multiple users via the internets. Will SQLite fill that hole?

Yes.

Related

Is it safe to give an App my gmail password ?

NM. I answered my own question. The log in screen was misleading. Have to stop multi tasking when I do these things. @ me.
KOF33 said:
NM. I answered my own question. The log in screen was misleading. Have to stop multi tasking when I do these things. @ me.
Click to expand...
Click to collapse
Just for fun, the answer is most definitely *NO*. Not if you have any personal information on your google account since this would allow that app to not only steal all your personal information, it would allow the app author to hijack your account, send your login credentials to china, etc.
lbcoder said:
Just for fun, the answer is most definitely *NO*. Not if you have any personal information on your google account since this would allow that app to not only steal all your personal information, it would allow the app author to hijack your account, send your login credentials to china, etc.
Click to expand...
Click to collapse
So can't use GDoc or Greed?
cigar3tte said:
So can't use GDoc or Greed?
Click to expand...
Click to collapse
I wouldnt...
Unless you know the code and compiled it yourself.
Or if you definitely don't have any sensitive info on your account.
There's no telling what they'll do with it.
Do you know the author? Have you met them? Do you even know what country they're in?
If you have a rooted device then id watch out for any apps you install, I've read about malware that uploads you browser.db and other data, and we all know that google didn't implement encryption into password storage.
I'm developing a shell app to do this over adb or on the phone console I have implemented
Browser database
Contact database
Ebuddy password
you could always use a password you just made up out of the blue. the app won't be able to recognize whether it's your actual gmail password or not.
tazz9690 said:
you could always use a password you just made up out of the blue. the app won't be able to recognize whether it's your actual gmail password or not.
Click to expand...
Click to collapse
Well the app that made me ask didnt "Require" it. But just recently after that A Gmail/Fbook sync app asks for both passwords.
Without it it wont work. I dont feel comfortable giving my PW to some random app.
Sudox-
Do you mean installing from non marketplace ?
Even rooted marketplace should be ok no ?
Ive never looked extensively at the safety precautions Google implemented.
KOF33 said:
Well the app that made me ask didnt "Require" it. But just recently after that A Gmail/Fbook sync app asks for both passwords.
Without it it wont work. I dont feel comfortable giving my PW to some random app.
Sudox-
Do you mean installing from non marketplace ?
Even rooted marketplace should be ok no ?
Ive never looked extensively at the safety precautions Google implemented.
Click to expand...
Click to collapse
The only thing that the market gives you is a partial assurance that the publisher's market account can be traced back to them based on the credit card number that was used to sign up. Google does NOT security verify the applications that are posted there. The security is built in to the OS -- and note that the app shows you what kind of data it can access at install time. It is therefore UP TO YOU to ensure that the application doesn't get any information that you would consider "sensitive".
And as for root access... this is a potential danger if you aren't careful about limiting root access from certain applications. The community-root scheme is fairly OK, but any program to which you grant ROOT PERMISSION will have access to *everything*. Be careful about what applications you give root to.
lbcoder said:
The only thing that the market gives you is a partial assurance that the publisher's market account can be traced back to them based on the credit card number that was used to sign up. Google does NOT security verify the applications that are posted there. The security is built in to the OS -- and note that the app shows you what kind of data it can access at install time. It is therefore UP TO YOU to ensure that the application doesn't get any information that you would consider "sensitive".
And as for root access... this is a potential danger if you aren't careful about limiting root access from certain applications. The community-root scheme is fairly OK, but any program to which you grant ROOT PERMISSION will have access to *everything*. Be careful about what applications you give root to.
Click to expand...
Click to collapse
This is something I have been wondering for a while now. Say you grant an app SU rights, however upon installation that app did not specify "Internet Access", meaning that the permissions for that program do not allow access to the internet (for sending of any information it could possibly gather). Can that app somehow access the internet, or modify it's own permissions in packages.xml?
daveid said:
This is something I have been wondering for a while now. Say you grant an app SU rights, however upon installation that app did not specify "Internet Access", meaning that the permissions for that program do not allow access to the internet (for sending of any information it could possibly gather). Can that app somehow access the internet, or modify it's own permissions in packages.xml?
Click to expand...
Click to collapse
Yes, any app with root access *can* change its own permissions, yes, any app with root access can access the internet, even withOUT internet permissions, and yes, an update to the app can come with additional permissions than an earlier version.
Note possible attack;
publish an app withOUT internet and/or read contacts permission,
app tries to send sensitive information to china -- permission denied, catch exception, no visible effect to the user. App granted ROOT access, alters /data/system/packages.xml to add internet and read contacts permissions and immediately the phone "randomly" reboots, upon reboot, that app has permissions required to send sensitive information to china.
And yes, the root app is NOT completely secure/trustworthy. There are several vulnerabilities that need to be considered...
1) A *pair* of apps can conspire to break out... i.e., one "trusted" app with root can modify a DIFFERENT app into the whitelist. This can include granting blanket root access.
2) The userid of an uninstalled application may remain in the whitelist, allowing it to be replaced by a *different* app that could later use that root access to do all kinds of nasty things.
In general, a better form for the community root database app would be along the following lines;
1) There should be NO WHITELIST.
2) The root permission state should remain in *memory* for a limited period of time (i.e. 1 minute).
3) The root app should request a PASSWORD (to prevent other people from tampering with it) -- store a password hash in the app's home directory,
4) The root app should be *forced* to be a *system* app in order to eliminate possibility of other user uninstalling and reinstalling it to bypass the password.
1 and 2 should be considered essential. 3 and 4 make it bulletproof, but still can't possibly do anything to stop an app given root from running amok.
In fact, note this;
Even WITH a secured root app, all any app needs is a MOMENT with root to do severe nastiness -- like give itself its very own su command that can't be stopped by the root-app...
Note: in order to *really* give decent security, the su command/app should work more like 'sudo' than like 'su'.
I.e., some app runs "sudo somecommand". This invokes the "sudo" app, which says... "XYZ is attempting to run this command as root: ---. Do you want to allow it?" You know, it is a much stronger position to be in if you can see *exactly* what some root-wanting app is trying to run. Also, nice to prevent some app from just going off as root any time it wants to.

Chrome2Phone -- Exploitable?

Had the thought that perhaps the new feature, to send your nexus a direct link from your computer, might be exploitable by some unfriendly people.
What do you all think the risks are, if any?
If it can tell your phone to open the browser and launch a website, whats to stop someone from telling your phone to buy ten thousand copies of Conan the Barbarian, or destroying itself and catching on fire. Kidding of course, but you get what i mean.
Very difficult. It'd be just as likely as someone stealing your Gmail account.
Mmm, ok. Thought I would ask
It has the potential, under the right circumstances, to be used for evil though! EVIL!
I'm not entirely sure, but from what I understand all intents go through google servers. I assume google is doing checks for malicious behaviour on their end.
Don't you have to register a phone to a gmail account and be logged into that account to send to the phone?
Haven't tried the app myself make it wouldn't make sense any other way ;-)
You have to be logged in. And i thing info is sendt via google servers, so unless someone steals your google account, i think you should be safe
it only triggers the browser or maps. I guess the risk would be real, but on the phone side you have the option to set it to do nothing but notify you FIRST prior to any action. If you didn't initiate anything, then you could click cancel at that time.
chromiumcloud said:
it only triggers the browser or maps. I guess the risk would be real, but on the phone side you have the option to set it to do nothing but notify you FIRST prior to any action. If you didn't initiate anything, then you could click cancel at that time.
Click to expand...
Click to collapse
one of the things being worked on is making the phone dial a number selected on the browser. that could get interesting
I believe that Google are running a closed beta at present too, so the only people that can write apps that use cloud messaging will have been vetted by Google.
All the components of the extension (chrome extension, android application and application server) are open source, what prevent anyone from developing an other extention that use google cloud service to communicate with android ?
ludo218 said:
All the components of the extension (chrome extension, android application and application server) are open source, what prevent anyone from developing an other extention that use google cloud service to communicate with android ?
Click to expand...
Click to collapse
All of the messages go through the Google servers
As I understand, the application engine part of the extension (which runs on google application engine) register itself to "the cloud" using google api. Anyone should be able to use these api, no?
It most certainly could be exploited. I can think of a javascript exploit that would work right now.
However the consequences of an exploit are severely limited by the security model that Android uses. Something can not run in another security context unless you allow it to.
The day "Chrmoe2Phone" asks for root access is the day it should be removed from your phone. Until then they most it could do is tell an app to do something that you've already allowed that app to do (which could arguably be undesirable things).
The user needs to explicitly permit all security privileges in Android remember (read that app install page with security details!). If it can do something, you've permitted it to do so.
tanman1975 said:
one of the things being worked on is making the phone dial a number selected on the browser. that could get interesting
Click to expand...
Click to collapse
That is true, but if i recall correctly, when you choose a phone number link from the browser, it will bring the number up in your dialer application, but you must initiate the call with the green call button, so there is a level of security there.
actually this could be a pretty nifty security feature. Is the phone gets stolen how great would It be to able to enable the gps, camera or mic? Given proper security protocols of course...
@tanman1975
Didn't think of that one. T'would be a very powerful tool against the robbers out there. Nice.

Nasty Permissions

How does the Android community ban apps that ask for crazy permissions? For people who root and have some level of sophistication - we're not going to fall for bad behaving apps.
But for all those who don't even know what permissions are, they need to be warned.
Take a look at this one:
https://market.android.com/details?id=com.antonio.fashion&feature=search_result
Comes from a banned company called Plankton that rebranded itself as StartApp.
I feel sorry for people that install this and can't get rid of all the nasty stuff they injected into their device.
Android Market said:
Permissions
This application has access to the following:
Network communication
full Internet access
Allows an application to create network sockets.
Your personal information
write Browser's history and bookmarks
Allows an application to modify the Browser's history or bookmarks stored on your device. Malicious applications can use this to erase or modify your Browser's data.
read Browser's history and bookmarks
Allows the application to read all the URLs that the Browser has visited, and all of the Browser's bookmarks.
Phone calls
read phone state and identity
Allows the application to access the phone features of the device. An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like.
Storage
modify/delete USB storage contents modify/delete SD card contents
Allows an application to write to the USB storage. Allows an application to write to the SD card.
Show all
Network communication
view network state
Allows an application to view the state of all networks.
view Wi-Fi state
Allows an application to view the information about the state of Wi-Fi.
System tools
automatically start at boot
Allows an application to have itself started as soon as the system has finished booting. This can make it take longer to start the device and allow the application to slow down the overall device by always running.
Click to expand...
Click to collapse
I have a problem with an app that supposedly just displays pictures but needs access to my phone, my browser AND starts on boot. The network communication and SD modify I understand since it needs to retrieve the pictures from somewhere and save them in the memory other than the internal one but the rest of the permissions are just completely unnecessary.
Wow that's crazy, I fully agree!
Wow! Those permissions are crazy. That company should be banned. People are having a similar issue with the Amazon "Free app of the day" today. It's a game that is asking for a ton of permissions. There were a lot of complaints and the developer remarked on their Twitter account that they accidentally uploaded a version with "remnant permissions." Ya..right. Too many companies are getting away with this "we accidentally uploaded a test/alpha/beta/developer...etc version of our app." *rolls eyes
Sent from my PC36100 using xda premium

Google + = huge roaming data charge

Never started thread before but wanted to warn Google + users that the app will upload pics BY DEFAULT. Just been hit with £300 bill for just a few days on holiday in USA. I had a 25mb/day limit and found G+ had consumed 111mb which is more than all the other apps combined! So be warned.
4braid said:
Never started thread before but wanted to warn Google + users that the app will upload pics BY DEFAULT. Just been hit with £300 bill for just a few days on holiday in USA. I had a 25mb/day limit and found G+ had consumed 111mb which is more than all the other apps combined! So be warned.
Click to expand...
Click to collapse
Actually its not by default when you first sign into the app it give you the option to turn off instant upload, set it to instant upload on just wifi or on wifi and mobile.
But it is a good point to remember when going on holiday or planning on taking alot of pictures to make sure this (and dropboxs similar feature) are turned off
zacthespack said:
Actually its not by default when you first sign into the app it give you the option to turn off instant upload, set it to instant upload on just wifi or on wifi and mobile.
But it is a good point to remember when going on holiday or planning on taking alot of pictures to make sure this (and dropboxs similar feature) are turned off
Click to expand...
Click to collapse
True but you should have to opt in not opt out. I'm using Droidwall now to stop all those data hungry apps
always use wifi
Sent from my GT-N7000 using Tapatalk 2
AW: Google + = huge roaming data charge
I use LBE to control internet access of certain very data intensive apps, among them are dropbox, skydrive, youtube... For those apps access to the internet is granted as long as there is a wifi connection. But as soon as the apps want to access the internet through the mobile network LBE asks me whether to grant access or not. This way I have never experienced any unpleasent surprises.
Sent from my revived Galaxy Note

[Q] Textsecure integration?

https://whispersystems.org/blog/cyanogen-integration/
The client logic is contained in a CyanogenMod system app called WhisperPush, which the system hands outgoing SMS messages to for optional delivery. The Cyanogen team runs their own TextSecure server for WhisperPush clients, which federates with the Open WhisperSystems TextSecure server, so that both clients can exchange messages with each-other seamlessly. All of the code involved throughout the entire stack is fully Open Source.
"All of the code involved throughout the entire stack is fully Open Source."
So any possibility of seeing this in omnirom?
SHAWDAH said:
https://whispersystems.org/blog/cyanogen-integration/
The client logic is contained in a CyanogenMod system app called WhisperPush, which the system hands outgoing SMS messages to for optional delivery. The Cyanogen team runs their own TextSecure server for WhisperPush clients, which federates with the Open WhisperSystems TextSecure server, so that both clients can exchange messages with each-other seamlessly. All of the code involved throughout the entire stack is fully Open Source.
"All of the code involved throughout the entire stack is fully Open Source."
So any possibility of seeing this in omnirom?
Click to expand...
Click to collapse
Hmm.
1) All of it would have to get reviewed for security. I know pulser has looked at some of CM's other solutions and found vulnerabilities.
2) Since it sounds like it needs some server infrastructure, it would take some time and planning before we could get it up and running.
TextSecure definitely looked interesting until seeing that it requires gapps.
wkwkwk said:
TextSecure definitely looked interesting until seeing that it requires gapps.
Click to expand...
Click to collapse
Yea its stupid, he partially justifies it here https://github.com/WhisperSystems/TextSecure/issues/127
He also said this
"If you want alternatives to things like GCM, you have to either build them or help the people that are. I would love to use a different push service, but they don't exist.
Likewise, if we want an alternative to Play, we have to build it. What exists now (f-droid) has a centralized trust model, so we're building something else."
Entropy512 said:
2) Since it sounds like it needs some server infrastructure, it would take some time and planning before we could get it up and running.
Click to expand...
Click to collapse
For whatever it is worth, Moxie Marlinspike has said that Open WhisperSystems has a TextSecure server that they will let other ROMs use. Sadly I am unable to link, but /r/Android/comments/1shejv/as_of_today_cyanogenmod_is_integrating/cdxlnck should give you the info and context you're after. I hope that helps alleviate some concerns, or at least makes this somewhat more doable--I would love to see this adopted much more widely!
I just wish they could add return receipt functionality, and fall back to SMS if data delivery doesn't provide one in a reasonable time frame.
palpitations said:
For whatever it is worth, Moxie Marlinspike has said that Open WhisperSystems has a TextSecure server that they will let other ROMs use. Sadly I am unable to link, but /r/Android/comments/1shejv/as_of_today_cyanogenmod_is_integrating/cdxlnck should give you the info and context you're after. I hope that helps alleviate some concerns, or at least makes this somewhat more doable--I would love to see this adopted much more widely!
I just wish they could add return receipt functionality, and fall back to SMS if data delivery doesn't provide one in a reasonable time frame.
Click to expand...
Click to collapse
Ok, that's useful.
I'll let pulser do final judgement on this. He's our resident tinfoilhatter.
I got myself a tinfoil wide-brim to match my duster...
I'll have to get a 4.4 capable phone in the future so I can get OMni.
Entropy512 said:
Ok, that's useful.
I'll let pulser do final judgement on this. He's our resident tinfoilhatter.
Click to expand...
Click to collapse
Resident tinfoil hat responding to duty...
The issue I've seen with this system (and I must say, it is good that work is done on this, and I commend that it has been done) is the implementation.
Once again, a solution has been made, which is smart, has good features, but is crippled in the security area, due to making things "easy to use".
The specific issue is that, from what I can see, at least right now, there is no way to tell if a message is going to be sent encrypted or unencrypted. It's no good knowing AFTER the fact - you need to know before it is sent how it will be sent.
Additionally, if you are using encryption, from what I can see, the message is actually sent over the internet. This means there is a central repository of users stored on a server somewhere. That is centralisation, centralisation is bad... As I raised back at the time, there are side-information risks.
While the new implementation may well eliminate some of these, I am not convinced this system provides the level of anonymity that some may desire. My worry is that since the original idea was conceived, where a user's phone number being available to CM was not seen as a concern, that any solution has been architected without considering every aspect of security.
Securing correspondence via SMS would be very nice to have done properly. But this is simply a "hook", that takes what you *think* is an SMS, and sends it over the internet. There are plenty of people in the world (particularly developing nations), where they have poor, or limited, access to the internet. SMS can be a lifeline for them.
There are also many places (some incredibly large), which regularly and routinely block internet services they disagree with (not at all looking at China here...) - it is important that any system works worldwide, and is resistent to easy "blocking".
I would personally prefer to see the actual messages sent over SMS... That means if you have no internet connection, you can still send the SMS. And you can do so ENCRYPTED, rather than unencrypted.
At the end of the day though, until you can tell 100% whether something will be sent encrypted or unencrypted, you can't trust a system. The server operator may also gain useful metadata in this case (though not ideal, your carrier already gets metadata for SMS).
Tl;dr, it looks nice, but we need to look at everything here, and consider that not everyone has internet access all the time. After key-exchange is complete (I would like offline key exchange via NFC and QRcode (on the screen) as well, for in-person identity verification), we need to ensure that a user can securely communicate without internet connectivity.
Until then, this is just a smaller rival to iMessage. And hey, maybe that's a good thing... But for my money, it's not a secure SMS system...
Thoughts welcomed.
pulser_g2 said:
Resident tinfoil hat responding to duty...
The issue I've seen with this system (and I must say, it is good that work is done on this, and I commend that it has been done) is the implementation.
Click to expand...
Click to collapse
Great criticism Pulser but surely this system (even with its flaws) is better than traditional SMS, where everything you send and receive is logged by your carrier?
slashslashslash said:
Great criticism Pulser but surely this system (even with its flaws) is better than traditional SMS, where everything you send and receive is logged by your carrier?
Click to expand...
Click to collapse
The thing is, since everything is sent via the Internet, there are plenty of other existing ways to send encrypted messages over the Internet where *you can be sure the message is encrypted*.
Pulser touched on my initial concern (which I held off on voicing until he chipped in) - To determine whether to send a cleartext SMS or send the SMS via an Internet message, the app needs to know whether the recipient is "enabled" with this service. There are two ways to do this:
1) The sender explicitly configures the app to say that recipient Y is capable of receiving encrypted SMS
2) The app does some form of peer-to-peer negotiation
3) The app sends data associating your phone number with an account on another service to a centralized server. This appears to be what CM's solution is doing. Which is kind of silly - This is an app for extremely privacy-conscious people, that is enabling widespread data collection of mappings between a users' phone number and other accounts.
Stay away from this app and developer, who in my view, has been compromised. In the latest release (which I compiled about an hour ago), he removed the ability of the user to regenerate identity key. In the last couple of releases, the app would crash unless you allow it to use the internet. He also introduced Google Cloud Pushing services, which means that everyone who is using textsecure will be recorded in centralized Google/Nsa database. That is if you compiled the app from the source. If you download the app from the store, you wouldn't be able to use it at all without Google account and GSF. Having GSF defeats any encryption as every keystroke is recorded and regularly submitted Home (Google/NSA). Stay away and look for alternatives. I am checking Tinfoil sms app.
optimumpro said:
Stay away from this app and developer, who in my view, has been compromised. In the latest release (which I compiled about an hour ago), he removed the ability of the user to regenerate identity key. In the last couple of releases, the app would crash unless you allow it to use the internet. He also introduced Google Cloud Pushing services, which means that everyone who is using textsecure will be recorded in centralized Google/Nsa database. That is if you compiled the app from the source. If you download the app from the store, you wouldn't be able to use it at all without Google account and GSF. Having GSF defeats any encryption as every keystroke is recorded and regularly submitted Home (Google/NSA). Stay away and look for alternatives. I am checking Tinfoil sms app.
Click to expand...
Click to collapse
Stop spreading this your uninformed opinion everywhere.
I answered each and every one of your "arguments" in your original thread:
http://forum.xda-developers.com/showpost.php?p=51818980&postcount=10

Categories

Resources