Related
Is there a way of creating and deploying an wp7 app that would be only available to our company agents.
As far As I understand this you can only deploy any app via the Market Place - this is useless for any internal business application.
Do I need to wait for better mobile device management or is there away around this ?
Any pointers appreciated guys.
Two ways to do it, the way I see it...
1. Add the program to marketplace, but require an registration number to be inputted in the program for it to work.
2. Side-load it
tiwas said:
Two ways to do it, the way I see it...
1. Add the program to marketplace, but require an registration number to be inputted in the program for it to work.
2. Side-load it
Click to expand...
Click to collapse
2 won't work, as it could be redistributed.
1 might, but we all know how well registration models work (cracks)
this might be a job for phone-home drm.
tiwas said:
Two ways to do it, the way I see it...
1. Add the program to marketplace, but require an registration number to be inputted in the program for it to work.
Click to expand...
Click to collapse
This would probably be the best, especially considering that your agents probably need to login anyway.
But I think that you won't pass certification if they can't test the app.
I don't know what your company does, but maybe you could release an app that is many targeted at your customers and everyone could use. This app could then have a hidden setting to enable special functions after a agent has logged in.
Microsoft are planning on supporting this in the future, their current suggestion, IIRC, is to use some sort of login though.
Hello,
I noticed that several apps I install require that I enable my location/position.
For several of them my location has nothing to do with the purpose of the app.
For instance: Bubble Birds.
I was wondering why??! And also, are the developers using the users' location info for some reasons?
Thank you.
This is something that irks me too, and is often a deciding point on whether I buy/install said app.
I can see it as being used for statistical purposes, but still brings out the conspiracy theorist in me.
I think it might be for ads. Maybe it is for stats though
Sent from my HD7 using XDA Windows Phone 7 App
The "ID_CAP_LOCATION" capability is included by default when creating a new project. If the location requirement is derived from this, it could mean that many developers just haven't removed it before submission, making it look like the application needs location info. This would probably be pointed out during submission, though. Maybe it's for the ads?
Thank you for all the answers.
I suppose it's not for the ads. I live in France and, luckily, all the ads are totally irrevelant and in English.
arturobandini said:
Thank you for all the answers.
I suppose it's not for the ads. I live in France and, luckily, all the ads are totally irrevelant and in English.
Click to expand...
Click to collapse
On my App, I have a trial mode that uses ads. If you pass the location information to the adControl, it enhances the selection process for the ads and will provide better focused ads, which also enhances money the developers receive.
AFAIK, WP7 doesn't support the ability to say "no" to the location and still use the app. If you decline the location, the application will not run. It would be nice to deny access to Location to the app, and still let the application run.
spokanedj said:
On my App, I have a trial mode that uses ads. If you pass the location information to the adControl, it enhances the selection process for the ads and will provide better focused ads, which also enhances money the developers receive.
AFAIK, WP7 doesn't support the ability to say "no" to the location and still use the app. If you decline the location, the application will not run. It would be nice to deny access to Location to the app, and still let the application run.
Click to expand...
Click to collapse
Well they have a very strict policy with the location service, it should be comppetely turned off from within the app if the user desires, i had an app with a button to activate and find the current location and it failed certification since the user could not bypass this button! If the user does not want to supply his location dont press te button and the location service will remain off, but this was not strict enough there should have been an extra switch to deactivate this button....
Weird policy really really weird
Hello!
I'm software developer from Russia, and made one very popular app in local market. Very soon I realized that I need an ability to give licensed version of app for my friends or reviewers or someone else.
Unfortunately AppHub doesn't provide such functionality(private distribution is pain in ass), so I created a webservice for myself.
After two days I realized that it may be useful for other developers, so here it is:
promo.g33k.ru (here I wanted to post url, but I can't due to low post count. You may find it in my profile->interests)
Now it has:
- JSON/SDK with RSA1024/SHA1 sign for additional security checks
- Binary SDK available
- Russian localization(if anyone cares ) (btw, if you can help translating to other language(s) or correct english misspellings - i will appreciate this).
Now this service works in beta mode.
So for developers I have two questions:
1) Is such service useful for you?
2) How to develop it further, in which way?
Not yet clear
I am sorry, but after reading your post and also checking your website I am still not sure what you offer. For me there is just not enough information to understand and then judge the usefulness of your service.
Maybe you could give a step-by-step scenario: Dev does this, then interested user does that, dev then this ...
Ok, I'll try to describe a little more details:
1) Developer wants to add capability of promo codes in his app(to give some specific users full licensed app).
The first problem is that developer need his own server for checking of promo code validity(hardcoding is not an option, of course).
2) So, Developer registers in my service, add his app's guid to his app list and create a promo code for specific app via web.
3) Developer adds support for promo codes in his app by:
a) adding an text box for user to enter promode
b) adding a web request to specific URL for promocode activation
c) adding to his license check web request for checking is current user activated a promo code.
Benefits for developer:
- Add support for promo codes without owning a server.
- Simple way to give full version of program to friends
Benefits for users:
- User may found promo code for specific app somewhere and use it to get full version of app in simple manner.
Benefits for reviewers/portals:
- Developers can easily give promo code for reviewing purpose or as giveaway for news post.
Clear now
Thanks for the additional info, now it's clear
Well yes, sounds useful. Properly implemented is probably really easier than Microsoft's "closed beta" mechanism, and of course can be used for other, non-beta apps as well.
The icing on the cake would be a "frame application" as sample code that basically does nothing more than asking for a promo code and then check against the list of valid codes on your server.
Sounds intresting but how do you ensure security?
chabun, I thought about security and situation is same as with default checking for trial - there is no security Man-in-the-Middle and direct cracking of xap will work, and there is no way out. I could use RSA signing for MitM, but still cracking of xap is very easy option today, so no one really interested will try to use MitM. When WP8 SDK will be out(I believe it will be in several weeks) - some developers may implement trial checks in native code - this will be much harder to crack.
As for server part there are following possible problems
- App's ID squatting(same as domain, someone else could reserve developer's app's guid). Don't know yet what to do with this, may be think about it later when this happens?
- Promocode's for App ID bruteforce - could be easily avoided via server throttling, if this ever happens - i'll add such checks
- Server DDoS - every webmaster's nightmare, I hope this never happens(or my Amazon AWS will pour my purse empty
rbrunner7, nice idea, I'll add a sample app as soon as possible on site.
This looks like an interesting concept
Sent from my SGH-i917 using XDA Windows Phone 7 App
Yop, you can never avoid direct cracking... However, RSA signing would be good I'd say as it will avoid MitM - with MitM you could create simple tools which can be used by every noob outhere. Cracking xaps requires some skill and it will need an unlocked WP7 as well.
I can see this working i have been thinking about something similar also. You can encrypt the data on device before sending it off to the cloud, you can than verify the encrypted data with a password and compare it to the codes registered on the server. Than link a code to a certain device id (once the code becomes 'registered') if a certain code is already coupled to a deice id and the device is not the same than the app will jump back into trial mode. Otherwise one can use the paid mode.
This can defenetly work and will prevent reselling th codes. Although it requires a server. And users can still hack/patch the app ofcourse but that will require an unlocked device so I should not worry to much about it.
Also to prevent spoofing you can frequently check with the server if this device is legitetmately registered.
Marvin_S said:
I can see this working i have been thinking about something similar also. You can encrypt the data on device before sending it off to the cloud, you can than verify the encrypted data with a password and compare it to the codes registered on the server. Than link a code to a certain device id (once the code becomes 'registered') if a certain code is already coupled to a deice id and the device is not the same than the app will jump back into trial mode. Otherwise one can use the paid mode.
This can defenetly work and will prevent reselling th codes. Although it requires a server. And users can still hack/patch the app ofcourse but that will require an unlocked device so I should not worry to much about it.
Also to prevent spoofing you can frequently check with the server if this device is legitetmately registered.
Click to expand...
Click to collapse
That's what I thought of... private/public key
chabun, so, for example, how about following scenario:
for each developer server creates public/private key pair.
when checking license on server: if success server encodes userid with developer private key
when checking license in app: server response decoding via public key(hardcoded in app) and comparing to userId. if ok -> licensed.
You might want to ask @ngreader guys on twitter. They do have this concept implemented in their app.
diverofdark said:
chabun, so, for example, how about following scenario:
for each developer server creates public/private key pair.
when checking license on server: if success server encodes userid with developer private key
when checking license in app: server response decoding via public key(hardcoded in app) and comparing to userId. if ok -> licensed.
Click to expand...
Click to collapse
I'm not sure if it would be good to encode the request to the server as well but otherwise it sounds really cool now... I'll use this service when I need this (and tell my friends about it)
Here is one way to do it http://stackoverflow.com/questions/599837/how-to-generate-and-validate-a-software-license-key
wpxbox said:
Here is one way to do it http://stackoverflow.com/questions/599837/how-to-generate-and-validate-a-software-license-key
Click to expand...
Click to collapse
Well, what they suggest is not as good as diverofdark's service which is a lot more secure and still easy to use for the customers...
Greetings everyone!
Today I updated promo.g33k.ru, now it has:
- more detailed about page,
- SDK now includes RSA1024/SHA1 sign for additional security checks
- Binary SDK available
- Russian localization(if anyone cares ) (btw, if you can help translating to other language(s) or correct english misspellings - i will appreciate this).
- Many minor bugfixes.
So, from now this service works in beta mode
diverofdark said:
Greetings everyone!
Today I updated promo.g33k.ru, now it has:
- more detailed about page,
- SDK now includes RSA1024/SHA1 sign for additional security checks
- Binary SDK available
- Russian localization(if anyone cares ) (btw, if you can help translating to other language(s) or correct english misspellings - i will appreciate this).
- Many minor bugfixes.
So, from now this service works in beta mode
Click to expand...
Click to collapse
Thanks! I will check this out
Hey diverofdark
It would be nice if you update the first post in the thread with all information. That's the way it's usually done in the forum.
A possible user (here dev ) can read it and without having to browse the whole thread, he can use your promocode service...
Thanks for mentioning it, I updated the first post.
I'm running MOAR v6.0 MD4 (Android 4.1.2) on Sprint GS3. I never received any alerts from Lookout before but today it report 15 riskware alerts:
com.android.phone
com.mythtrandyr.inkeffectsettings
com.lidroid.settings
com.sonyericsson.lockscreen.uxpnxt
com.jy.iconchanger.ad
de.robv.android.xposed.mods.appsettings
com.asushi.livewallpaper.mytree
com.monotype.android.font.XDAFONTS
com.android.launcher
de.robv.android.xposed.installer
com.android.flashblink
com.sec.android.mimage.photoretouching
com.koo.lightmanager
com.android.lmt
com.lidroid.sgs.secretcode
All have a classification of: Riskware.Android.CompromisedKey.a.
Should I alarmed or this is likely a problem with definition update from Lookout?
Great support from the Lookout guys as I emailed them and they replied right away, here's what they said. I should be okay:
The reason we have flagged this app is as 'Riskware' is due to a special key that this particular developer used when publishing the app. The key is normally a private piece of information that we use to determine if an app is authentic, and to identify the developer. In this particular situation, the developer chose to use a key that has been widely distributed on the internet or has been compromised.
This makes it impossible for us to validate the app and its authenticity. Therefore, we are not calling these apps malware, but we recommend that users not install apps like this because it is inherently more risky (hence the "Riskware" assessment).
If you as a user understands the risk and still decide to trust the app, feel free to ignore the warning.
We have also been seeing some device manufacturer, preinstalled apps also being flagged as 'Riskware' for the same reason. These apps are unable to be uninstalled and we please ask that you ignore the warning if it is an app that came preinstalled on the device. We have reached out to these developers to make the proper changes.
Thanks for using Lookout!
David,
The Lookout Team
mindfulness said:
Great support from the Lookout guys as I emailed them and they replied right away, here's what they said. I should be okay:
The reason we have flagged this app is as 'Riskware' is due to a special key that this particular developer used when publishing the app. The key is normally a private piece of information that we use to determine if an app is authentic, and to identify the developer. In this particular situation, the developer chose to use a key that has been widely distributed on the internet or has been compromised.
This makes it impossible for us to validate the app and its authenticity. Therefore, we are not calling these apps malware, but we recommend that users not install apps like this because it is inherently more risky (hence the "Riskware" assessment).
If you as a user understands the risk and still decide to trust the app, feel free to ignore the warning.
We have also been seeing some device manufacturer, preinstalled apps also being flagged as 'Riskware' for the same reason. These apps are unable to be uninstalled and we please ask that you ignore the warning if it is an app that came preinstalled on the device. We have reached out to these developers to make the proper changes.
Thanks for using Lookout!
David,
The Lookout Team
Click to expand...
Click to collapse
What effect will this have on CM builds because they are using public available keys (https://github.com/CyanogenMod/android_build/tree/gingerbread/target/product/security) to sign ?
xda-developers.com is listed as one of the sites affected by the heartbleed bug, but testing tool now shows no vulnerability. A quick search shows no
Why aren't you bragging about patching this bug and how awesome you are at protecting our data?
At the very least, a notice about what's being done to protect xda and how it affects users would be much appreciated.
dstarfire said:
xda-developers.com is listed as one of the sites affected by the heartbleed bug, but testing tool now shows no vulnerability. A quick search shows no
Why aren't you bragging about patching this bug and how awesome you are at protecting our data?
At the very least, a notice about what's being done to protect xda and how it affects users would be much appreciated.
Click to expand...
Click to collapse
I'm curious what site it was listed on?
Just for anyone who is interested...
As soon as the severity of the flaw was clear, we began updating our machines. Some services use pre-built packages and others use custom-compiled software (using the flawed openssl version). We updated all of our services within 30 minutes or so.
The forum.xda-developers.com hostname uses a 3rd party service who was still vulnerable to heartbeat after we patched our internal services. We opened a ticket with them - I'm sure by that point they were aware of the issue and a fix was already in the works. About an hour after that they had patched their services.
This is definitely one of the worst security flaws in the history of the internet - you pretty much have to assume that any communications thought protected by https have been compromised unless there were other protections in addition to SSL.
https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt
please patch asap
Isriam said:
https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt
please patch asap
Click to expand...
Click to collapse
That list is old... see my statement above.
thats fine, but just so you know that link is posted on front page msn.com under heartbleed headlines.
Isriam said:
thats fine, but just so you know that link is posted on front page msn.com under heartbleed headlines.
Click to expand...
Click to collapse
Sure, but not too much I can do about old information.
The link loriam posted is the one I found xda mentioned on. However, before I posted, I also checked a live testing website that showed xda as safe.
If anybody is interested, the url for that site is filippo.io/Heartbleed/
Unless there is updated information that I was unable to see, your SSL certificate is showing as being from 7 months ago. Shouldn't it be updated since that was part of the information that was vulnerable to Heartbleed?
Are there any plans to replace and revoke the SSL certificates that were on the vulnerable servers? Since there are no logs it is impossible to know if anyone was able to obtain the private key for these certificates, and until revoked xda remains vulnerable to stealth MITM attacks.
wto605 said:
Are there any plans to replace and revoke the SSL certificates that were on the vulnerable servers? Since there are no logs it is impossible to know if anyone was able to obtain the private key for these certificates, and until revoked xda remains vulnerable to stealth MITM attacks.
Click to expand...
Click to collapse
New certs are in process... the CA's are a bit backlogged.
We are vulnerable to stealth MITM attacks only if someone has recorder/intercepted our traffic, and also if someone was able to decode our private key. Of which both are unlikely (but possible). So while we do work to replace our certs, the priority is "hey, we are doing this" and not "hey, let's shut down our ssl services."
bitpushr said:
New certs are in process... the CA's are a bit backlogged.
We are vulnerable to stealth MITM attacks only if someone has recorder/intercepted our traffic, and also if someone was able to decode our private key. Of which both are unlikely (but possible). So while we do work to replace our certs, the priority is "hey, we are doing this" and not "hey, let's shut down our ssl services."
Click to expand...
Click to collapse
I totally agree (and believe me I'm hating this crap as much as I'm sure you guys are)... I just wanted to make sure it was in progress as I'm waiting to change my password until then.
Well, I'm glad that you guys are taking the necessary steps to keep your and your users information safe. I feel bad for whoever would try and hack XDA-Developers, because they would probably receive a huge backlash.
Probably bad enough to melt their computer.
Sent from my dictionary.
Some progress in updating androids vulnerable openssl 1.0.1e ? Heartbleed is disabled (for me) but somehow i imagine unwanted changes like from apps etc
Sent from my GT-I9505 using xda app-developers app
GrammarNazi said:
Well, I'm glad that you guys are taking the necessary steps to keep your and your users information safe. I feel bad for whoever would try and hack XDA-Developers, because they would probably receive a huge backlash.
Probably bad enough to melt their computer.
Sent from my dictionary.
Click to expand...
Click to collapse
We would blow up all mobiles they own. Mwahahahah!
Sent from my HTC Explorer A310e using XDA Premium 4 mobile app
Our new SSL certificates are in place.
Glad to hear were safe. Maybe XDA should force all users to change their passwords?? In the security world it's just better off and safer to assume everything was compromised.
Sent from my Galaxy S4 using Tapatalk
bitpushr said:
Our new SSL certificates are in place.
Click to expand...
Click to collapse
Hi bitpushr,
How to use the secured connection when logging in and/or changing password in this forum? I haven't noticed any ssl connection when logging in and/or changing password from the control panel.
Online test for Heartbleed
There are sites that will test for it.