Comments (12)
Start to take a look at this issue.
Original comment by [email protected]
on 26 May 2010 at 12:16
from omnidroid.
Here are some of the approach I have considered so far for this problem.
Approach 1 &
2 also includes some sample source code that shows how I would implement them.
Note
that these codes covers only the twitter action and as of r699, gmail actions
also
use passwords.
1. Encrypt passwords stored in DB. (please refer to cipher directory)
To make it simple, the following invariant must be followed - password string
in the
action class is always encrypted. As long as this invariant is followed, there
shouldn't be a case were a password becomes irrecoverable because it was
encrypted or
decrypted twice in a row.
The problem I see with this approach is that we need an encryption mechanism
where
the cipher text is recoverable, otherwise, we wouldn't be able to extract the
original password and pass it to jtwitter. I think this is a problem because
if we
can recover the password, then others can do it too. To make things worse, our
code
is open source so the method on how to decrypt the password is available to the
public.
2. Use OAuth. (please refer to oauth directory)
Almost the same problem as approach 1. Since we need to store the token, it
should be
placed somewhere that it can't be compromised. This may be actually worse than
approach 1, because the user can change the password if the password is
compromised,
but I don't think the user can invalidate the OAuth access token.
3. Use Android's AccountManager.
This approach has not yet been fully studied, but it requires API level of at
least
5. Sample use can be seen on android documentation online:
http://developer.android.com/resources/samples/SampleSyncAdapter/index.html
The source is also available on the android SDK under the directory:
samples/android-x/SampleSyncAdapter
note that x is a number, in my computer, both android-7 and android-8 had this
directory.
Related discussion can also be found on:
http://groups.google.com/group/omnidroid-devel/browse_thread/thread/dab55b1d6967
a6ac
Attached file contains sample codes.
Original comment by [email protected]
on 1 Jun 2010 at 6:31
Attachments:
from omnidroid.
Current status: on hold.
Reason: AccountManager looks promising and we want to use it, but it requires a
higher
API level, which could potentially leave out old android users. So this has
been put on
hold for the moment.
Original comment by [email protected]
on 2 Jun 2010 at 12:20
from omnidroid.
Original comment by [email protected]
on 2 Jun 2010 at 2:18
- Added labels: Security
from omnidroid.
One approach I can think of is to use PBE (Password based encryption). It is
basically an encryption scheme where a password will be used in the
cryptographic process. The idea is to ask the user for a master password that
will be used in PBE. The downside is since we can't store the master password
in the DB for security reasons, we need to ask the master password from the
user every time the phone boots which can ruin the user experience.
Alternatively, we can also provide the user with the option of storing the
password less securely for convenience...
Original comment by [email protected]
on 22 Jun 2010 at 3:52
from omnidroid.
Original comment by [email protected]
on 6 Jul 2010 at 2:22
from omnidroid.
I have taken a deeper look at the AccountManager and we can definitely use it.
But are we really not going to address this security concern till the next
release? I am also planning to have this released together with issue 89 since
changes in both of them would require users to setup their account again. And
having them in one release would only require the users to do the adjustment
once.
Original comment by [email protected]
on 15 Jul 2010 at 4:09
from omnidroid.
If you're not planning to use the AccountManager, then I don't see any reason
why this can't be applied before the initial release.
Original comment by [email protected]
on 15 Jul 2010 at 4:50
from omnidroid.
Since using AccountManager or not is going to greatly affect the code I want to
hear about your opinion on this. I have listed some of the points about
AccountManager:
AccountManager pros:
1. Does not need another table to support multiple accounts.
2. Integrated solution with the Android system.
cons:
1. Needs at least API level 5.
2. We are trusting Google is doing a good job in keeping the user credentials
secure.
In house cons:
1. As stated in the issue, I couldn't think of any way of having a truly secure
solution but it can deter potential attackers.
2. Need separate table if we need to add multi-account support for each
application.
Original comment by [email protected]
on 15 Jul 2010 at 5:49
from omnidroid.
I said my peace (no one replied) in :
https://groups.google.com/group/omnidroid-devel/browse_thread/thread/46841a21232
fa7f1
[start re-post]
Application Account Management
-------------------
Randolph brings about the point about application account management
again in Issue99. It begs the question of whether we want to build
out a more robust account management system inside our application or
possibly integrate with the Android-5 AccountManager. I don't think
there is really much to be gained by staying with an outdated API
level in a fast changing mobile market. If upgrading to a higher
version will provide us with critical functionality that we want to
take advantage of we probably want to migrate as soon as possible. By
as soon as possible though I think I'm thinking after the 1.0
Milestone has been reached. The question continues to remain as to
how much functionality the android-5 AccountManager will buy us. With
how tightly we'll want to integrate account configuration with
Omnidroid would leveraging it be a substantial benefit? If we can't
integrate well with it, or it doesn't provide the functionality we
want or need, then we probably want to build this out ourselves. If
it would provide a great benefit, then I think we should slate the
better backend support of account management as a post 1.0 Milestone.
So here's my current 2.0 proposal:
2.0 Release Milestone Strategy
-------------------
Omnidroid 2.0 main feature advancements:
- Integration with remaining standard set of apps
(Calendar/Email/Music/Contacts/etc.)
- Enhanced Account Management
Proposal if an Android-5 AccountManager is the way to go:
- Omnidroid 1.0 compatible with Android-4+ (1st generation) devices.
- Omnidroid 2.0 compatible with Android-5+ (2nd gen) devices.
Proposal if an in-house AccountManager is the way to go:
- Omnidroid 1.0 compatible with Android-4+ (1st generation) devices.
- Omnidroid 2.0 compatible with Android-4+ (1st & 2nd gen) devices.
[/end-repost]
I read this interesting blog post about supporting older platforms that doesn't
sound too bad:
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-
it-too.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%
2FhsDu+%28Android+Developers+Blog%29&utm_content=Google+Reader
If we provide the API-4 support in-house, but use AccountManager in future, we
can wrap it with some generic and continue to support the API-4 version.
Thoughts?
Original comment by [email protected]
on 15 Jul 2010 at 6:07
from omnidroid.
interesting, I've heard this somewhere before, assuming you speak decent
english, i wonder why "said my peace" not "said my piece"?
Original comment by sv767%[email protected]
on 15 Jul 2010 at 6:31
from omnidroid.
lots of typing, little proofreading
Original comment by [email protected]
on 15 Jul 2010 at 7:34
from omnidroid.
Related Issues (20)
- Event Handler Limit Crash HOT 1
- Events not executing until lock/unlock performed HOT 12
- no market access HOT 2
- Adopt Guice
- Filter, between pre-midnight and post-midnight HOT 1
- contact groups/aliases for recipient/blacklists HOT 3
- decide whether to perform actions smartly
- An action to Enable/disable actions HOT 1
- Crash when using "Time is day of week" filter HOT 2
- Sensor data not fully utilized in some cases HOT 6
- Enhancement: Disable Data traffic on low battery HOT 2
- Trigger on Wi-Fi SSID HOT 1
- Performance improvement suggestion
- Slow operation in UI thread HOT 1
- Add phone filter : in contact / not in contact
- Enhancement request: action on enter/leave WiFi or mobile base station HOT 1
- Unlock attempt event
- Phone shut down action
- Feature request: event on wifi network available / unavailable
- wrong orders of longitude and latitude when constructing a new OmniArea object in the LocationMonitor
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from omnidroid.