Hi,
I made a new app: NFC Safe!
With NFC Safe you will be able to encrypt your private data with a NFC Tag (e.g. NFC Key Fob). You can add unlimited custom folder and entries. You will have only access to those entries with the specific NFC Tag! This is much more secure than protecting your data only with a password!
You can use any NFC Tag for this app! Your NFC Tag will be written with some data so it can only be used for this app.
NFC Safe | Windows Phone Apps+Games Store (United States)
Would be nice, if you test my app! My app is available for free!
With one of the next releases it will be also possible to encrypt/decrypt media files (images, audio, etc.)
Best Regards,
Sascha
I don't have any NFC tags on me right now nor would i really use this, but i have to say, this is a really cool idea!
While I understand if you're hesitant to post it, I'd want to review the app's source code before using it myself. Getting cryptography right, even when just using existing and well, implemented pieces, is vastly harder than getting it wrong. What algorithm do you use to encrypt the data? How about generating the key data? Are you using secure buffers? Initialization vectors? How are you detecting which key is correct for the data you're trying to access; is there a hash? What hash function? There are a lot of other important questions here, too.
With that said, the idea is fantastic. It would be especially great if you could support two-factor authentication (password + NFC tag, in this case) for extra-sensitive data, although password management in crypto has its own set of problems (what key derivation function, with what parameters? How are the password verifiers stored? Etc.)
Sorry for late reply!
xandros9 said:
I don't have any NFC tags on me right now nor would i really use this, but i have to say, this is a really cool idea!
Click to expand...
Click to collapse
Then you should buy an NFC Tag! They are really cheap. For example you could buy a NFC keyfob, so you will have your NFC tag always in your pocket and as said, such a NFC Tag costs ca. 1 USD at ebay
GoodDayToDie said:
While I understand if you're hesitant to post it, I'd want to review the app's source code before using it myself. Getting cryptography right, even when just using existing and well, implemented pieces, is vastly harder than getting it wrong. What algorithm do you use to encrypt the data? How about generating the key data? Are you using secure buffers? Initialization vectors? How are you detecting which key is correct for the data you're trying to access; is there a hash? What hash function? There are a lot of other important questions here, too.
With that said, the idea is fantastic. It would be especially great if you could support two-factor authentication (password + NFC tag, in this case) for extra-sensitive data, although password management in crypto has its own set of problems (what key derivation function, with what parameters? How are the password verifiers stored? Etc.)
Click to expand...
Click to collapse
Hi thanks for your feedback and your questions! I think you misunderstood my app. It's not a military app, where the highest security is important! My app doesn't need to encrypt the data, because the data is stored on your Windows Phone in the application data storage. Noone has access to this. If ever any person has access to those data, you and all other Windows Phone users have a very big problem!
So, my app is an app, not a Windows Application, where virus, NSA, etc. have access to your data There are a lot of apps which protect your personal data with a password. So if someone else has your phone (stolen, or a friend while you are not watching at it), he will be able to see your data, if the know your password (this is not impossible!) or guess your password! So my app protects your data with an NFC Tag. It's very comfortable to use and faster than typing a password and also more secure, because the third-person needs your phone AND your NFC Tag.
However, my app also encrypts the whole data, so even if someone have access to the application data storage, he will be unable to read your data. Windows Phone has a built in encryption mechanism, which can be used from an API. I'm using this encryption mechanism. This mechanism uses Triple-DES. It uses the user credentials and a randomly generated password (GUID with 36 chars/numbers and "-"-sign) to encrypt the data.
Hi! Welcome to XDA-Developers, where all of your assumptions about what cannot be accessed on the phone are wrong, or will be shortly!
OK, that's half a joke. But only half... as it turns out, the claim that "... Windows Phone in the application data storage. Noone has access to this." has been untrue for months. Check the Dev&Hacking forum, especially the Interop-unlock and SamWP8 Tools threads. We have the ability to access the entire WP8 file system. Currently that access is only via MTP (USB connection), but I and other people are working on extending it to homebrew apps as well.
Moving on... 3DES (even if used with a good mode of operation and a unique initialization vector, which I am guessing you probably didn't do) is obsolete and should not be used anymore. While it is considered adequate for existing code, it should not be used in new software, and cryptographers have been recommending a move to newer ciphers (such as AES) for years. As for using a GUID as a password, GUIDs are 128 bits (the dashes don't count, because they are always the same value in the same place, and each of the other 32 digits is hexadecimal only, meaning merely 4 bits of data), which is plenty if they are generated securely; however, most GUID generators do not use cryptographically secure random number generators. GUIDs are supposed to be unique (that's what the U stands for), but are not guaranteed to be unpredictable (which is one of the key requirements for an encryption key), and the way they are generated reflects this.
Oh, and good security is important in an awful lot more places than "a military app"! In fact, there's no such thing as "military-grade" encryption, really; there's only good encryption, and encryption which shouldn't be used for any purpose. For example, modern TLS (Transport Layer Security, the replacement for SSL or Secure Sockets Layer) cipher suites are intended to be secure even against governments and megacorporations (although there is of course suspicion as to whether the NSA have broken some of those cipher suites)... but TLS isn't just used on extremely sensitive stuff like top-secret documents and such, it's also used when browsing Facebook and Twitter, or accessing Gmail, or many other things of similarly minor sensitivity.
Thank you for explaining the intended use cases of the app, though. Do please be careful when making claims such as that something is "much more secure", though; you are liable to mislead people. TrueCrypt, a PC app that performs disk encryption and is intended to stand up to very powerful adversaries, uses only a password most of the time - but I would expect that, given a well-chosen password, it is more secure than this app. There are many critical components to security, and only the weakest link in the chain matters.
For what it's worth, if you are interested, I would be happy to help secure the app (on my own time, free of charge) as it sounds like something that I would quite like to use, if I could trust its security.
What exactly is your problem?!?!
I said, that noone has access to the Application Data Storage and this is true! There is no Virus available for Windows Phone and there is no App in the Store available which has access to another app's data storage! We are not talking about some special cases where the third-person already have STOLEN your device, because nothing in this world is safe! NOTHING! Everything can be hacked! Also I didnt know that all current Lumia devices were hacked. Other devices are not relevant (Nokia has a market share of more than 90%!).
The built-in encryption mechanism in Windows Phone is the same almost ANY Windows Phone app uses! Any banking app, Facebook, eBay, PayPal. The Wallet feature of Windows Phone uses it. If you have set up accounts (E-Mail, Microsoft Account, Office365, etc.) your passwords were encrypted with the SAME API my app uses. So if you think this API is totally unsafe, WHY THE HELL are you using Windows Phone? Also Windows Vista, 7, 8 and 8.1 uses THE SAME API for a lot of thinks. So please don't use Windows anymore!
I said, my app is more secure THAN AN APP which only uses a password and that is true. Also my app additionally encrypts the data and not only block the access to the data (which a lot of other apps only do!).
Please decrypt the attached file and tell me, how you did that and how long it took Thanks!
Whoa, whoa, calm down.
First of all, don't count on that "no app in the store..." business; There's *probably* no malicious app that can do so, but OEM apps can, if they have som reason to do so, access other app's install and data folders. I've written apps (using the Samsung OEM components, which are clumsy for the purpose but *do* work) to do it myself. It's not something you're likely to see in widespread use, but it's possible.
If you aren't bothering with the case of your phone being stolen, what's the point of the encryption anyhow? I mean, prevention of data loss in the event of device theft is one of *the* key use cases for data storage encryption! It's the rationale behind things like BitLocker (which is available on WP8, but only if the user has connected their phone to a company's Exchange server that pushes a policy requiring device encryption).
If you were honestly worried about market share, you probably wouldn't target WP at all; Nokia's fraction of the WP market share is lower than WP's fraction of the smartphone market share. Nonetheless, you are correct that, at this time, Nokia WP8 devices haven't been cracked. Nor have HTC's phones. I'm confident that this will change in time, though. You might have misunderstood my little joke at the start of my last post... but breaking into smartphone operating systems, getting past the lockdown policies that say "noone[sic] has access" (it's "nobody" or "no one", by the way) and taking those decisions into our own hands.
I guarantee you that the vast majority of WP apps don't use 3DES. I *know* full well that the Microsoft code doesn't; they had already deprecated that cipher years ago, when I interned there, long before even WP7 existed; its use was prohibited for new code. Just because you used the DPAPI (Data Protection API) doesn't mean you used it correctly (and by the way, that internship involved working on encryption in Windows, writing test tools for it). Please don't take this as some kind of personal insult; in my line of work (security engineer), I see a ton of misuse of cryptography. It is, as I said in my first post, hard to get right. That's why I offered to help.
I'm not going to bother taking the time to figure out what cipher you used on that file, and what its contents are supposed to look like enough to start doing any cryptanalysis, but I guarantee you it's not very good. There are repeated patterns, including long strings of null bytes, that are phenomenally unlikely to occur in a file that short after passing it through even a half-decent cipher (we're talking 1-in-several-billion chance here, no joke). Coming to this conclusion took all of a few seconds, by the way, using no tool more sophisticated than Notepad++. If I was pulling it off of a phone, I'd have a lot more idea of what type of plaintext to expect, and I could examine the decompilation of the app to see what ciphers were used, which would make things a lot easier. I'd say "for all I know, you just took the output of CryptGenRandom and put it in a file" but if you had, it wouldn't have had obvious patterns in it... in any case, it doesn't matter. I don't have to prove anything to you. I'm *trying* to help, and offer some good advice as well, but I can't force you to take it. There's no call for getting defensive, though. I wrote a file encryption utility myself one, in fact. It sucked, so then I wrote a program to break its encryption. Both experiences (but mostly the latter) taught me things.
A new version is available now, which includes image/photo encryption, OneDrive backup, bugfixes and other small improvments!
http://www.windowsphone.com/s?appid=0a8656d4-ed32-4bb5-baac-1317827e18d8
Hi,
I have a question:
My app is available in German and English since one year now! It was downloaded over 1000 times in Germany, but only 80 times in USA, UK, etc. I got 40 reviews (4-5 stars) in Germany and only one bad review in USA. So could someone explain what's wrong with my app? Is it not visible in the US Windows Phone store? Is my app very bad translated? Are there no Windows Phone users in the USA? Or maybe no one use NFC in the USA?
Best regards,
Sascha
Sorry, I don't tried your app yet but will try to answer your questions.
First, probably it's something wrong with your marketing, not the app Le me say: 1080 downloads per year - it's too small number (even 1000 in Germany). For example, my "marketplace entry ticket", "Lunar Lander Touch" app, very unpopular and underrated (but it's still one of my favorite games on WP, and good alcohol tester ), has 4078 for the year 2013.
As for NFC: I've tried to use it but stopped because of very uncomfortable WP implementation. That service should work flawlessly, without user interaction, stupid questions and dialogs, to be useful and popular. But unfortunately it's not (for the Windows Phones). Microsoft must add an option to disable NFC warnings.
P.S. I may recommend you to use "Snowden case" for advertizing
Thanks for your feedback!
Yes, I know that the download numbers are very bad, but I don't have an idea how to improve this. Because of my app is free and my private hobby I don't have money to buy ads, etc.
Improving my app had not effect. Thanks to DVLUP I "bought" ads for 50$ with AdDuplex, but this also had no effect.
It's really hard for individuals to get their apps famous and in a higher ranking in the Windows Phone Store without investing money
I understand... AdDuplex is really bad: I've tried once ($100 from DVLUP meeting plus I've bought another $100 coupon for $40) during a week - no results at all. Complained to AdDuplex support and manager gave me additional $300 for free, to spend within one day (sic! He-he, I wish to get $300 daily from my app!) - still no visible results, just a regular download fluctuations...
What you may try: advertise on more forums, prepare good pictures/screenshots; may be, video clip "howto" will be helpful. Embed RateMyApp Nokia's control (check NuGet) to your form. If you have XP on DVLUP, spend 'em for advertising campaign (these ones are extremely effective!).
P.S. I also thought about xda-based developers club, with "rate 5 stars my apps, and I'll rate yours" rule but I don't know how to implement it properly (but good customer rating is very important for the app distribution).
Thanks!
I already added RateMyApp. This was really helpfull to get more reviews. It's a pity that I had not implemented such a thing from the very first time my app was added to the Windows Phone Store :-/
I "bought" 1 week in App Social (DVLUP). Hope this helps. But it is also only in Germany.... I have enough users and reviews in Germany, I need them in USA, UK, etc. The problem with the DVLUP campaigns is, that you need at least 50 or 100 reviews (and 4,5 stars) as a requirement for the advertising. But you don't have so many reviews and that's the reason why you need the campaign to get more reviews, but you can't buy the campaign... A vicious circle!
I will do my best to get more downloads in other countries than Germany!
Hey, thanks for this app i find it realy useful.
Danke!
And here is the idea for the ad banner
Great idea
btw: Version 2.1 with new type "User Credentials" is available now!
Ok, I stopped developing, it's not worth. Sorry!
This is my first post to XDA.
I have been asking this question about various OS's in various forums, for past 18 months, and each time I ask it, the person who answers it spends a few iterations with me bending-over-backwards trying to avoid telling me what I want to know. I hope that this does not happen here.
I have a native C++ application. It currently runs on Linux desktop. It does many things that native C++ applications do, including sending raw Ethernet frames (mesh networking).
Obviously, if one of my customers tries to install this application on his/her Android device, there will be problems, and it won't work.
I am aware that a human being has the ability to root his/her phone.
I am aware that a human being has the ability to root his/her phone.
I am aware that a human being has the ability to root his/her phone.
Please do not send me a reply saying, "But your customer has the ability to root his/her phone!" :cyclops:
What I would like, is a smartphone, that is running Linux, that allows my customer to install a 100% Native C++ application, >>>WITHOUT<<< having to go through the process of rooting his/her phone. Ideally, the barrier-to-installation would be roughly equivalent to what s/he would experience on a desktop computer.
I am not concerned about the presence of X or any particular GUI subsystem, but I will definitely need access to all the normal system-level Linux primitives (multi-threading, asynchronous I/O, etc.)
Please do not send me a reply saying, You can ssh into the phone and install the app that way."
I would like to know if Ubuntu on smartphone allows a relatively naive user to install a 100% native C++ application that interfaces with the system-level primitives of Linux.
And finally, please note that I am not interested in finding a work-around to an engineering problem that I am having. I am trying to determine the maximum permissible degree of nativity of Ubuntu Touch applications when the application is to be installed by a naive user.
If Ubuntu touch does allow such native applications to be installed, I would be interested in getting an idea of the steps that a customer would take.
UT apps can be uploaded as a click app to the UbuntuOne store and then can be installed as easy as any Android app. You should be able to "sideload" click apps, but I never tried.
UT apps - that are not a web app - are written in native C++ using QT5/QML for UI.
UT apps are restricted by apparmour profiles, but that should not keep them from using multithreading or asynchronous I/O. You would have to test, if your specific requirements work.
There is only one way to answer all your questions: give it a try!
Sent from my TF300T using Tapatalk
f69m said:
UT apps can be uploaded as a click app to the UbuntuOne store and then can be installed as easy as any Android app. You should be able to "sideload" click apps, but I never tried.
UT apps - that are not a web app - are written in native C++ using QT5/QML for UI.
UT apps are restricted by apparmour profiles, but that should not keep them from using multithreading or asynchronous I/O. You would have to test, if your specific requirements work.
There is only one way to answer all your questions: give it a try!
Sent from my TF300T using Tapatalk
Click to expand...
Click to collapse
:good:
Yes, you would need to change the packaging system from debian archives to click packages but that shouldn't be too difficult. If you run into problems with the Ubuntu SDK in connection with C++, have a look at this bug report and the mentioned fixes: https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1215913
f69m said:
UT apps can be uploaded as a click app to the UbuntuOne store and then can be installed as easy as any Android app. You should be able to "sideload" click apps, but I never tried.
Click to expand...
Click to collapse
Any idea at all what the user would see when trying to sideload a click app. [I am trying to set my expectations before diving in.] Would the user download package to a directory, then click on it, or?
UT apps are restricted by apparmour profiles, but that should not keep them from using multithreading or asynchronous I/O. You would have to test, if your specific requirements work.
There is only one way to answer all your questions: give it a try!
Click to expand...
Click to collapse
OK, apparmour seems to be the focal point. I would be really interested (if any knows), how restrictive apparmour will be with a newly-purchased UT phone, and what control a naive user of that phone will have in allowing native C++ applications to run. I would check this myself, but I cannot do any significant coding (porting) until mid-March.
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.). I would like to know what I, and the user, can expect when s/he:
acquires my app from my web site
does something to install it (what would s/he do at this step?)
attempts to execute it (will apparmour block access to mac80211-like drivers)
RareHare said:
Any idea at all what the user would see when trying to sideload a click app. [I am trying to set my expectations before diving in.] Would the user download package to a directory, then click on it, or?
OK, apparmour seems to be the focal point. I would be really interested (if any knows), how restrictive apparmour will be with a newly-purchased UT phone, and what control a naive user of that phone will have in allowing native C++ applications to run. I would check this myself, but I cannot do any significant coding (porting) until mid-March.
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.). I would like to know what I, and the user, can expect when s/he:
acquires my app from my web site
does something to install it (what would s/he do at this step?)
attempts to execute it (will apparmour block access to mac80211-like drivers)
Click to expand...
Click to collapse
Applications should be installed from the Ubuntu app store. If you've just got the click package, you currently need to use the command line to install it:
Code:
sudo install <path to package>
sudo register --user=phablet <package name> <package version>
I hope that this will change though. (It's name is "click" package. )
RareHare said:
Any idea at all what the user would see when trying to sideload a click app. [I am trying to set my expectations before diving in.] Would the user download package to a directory, then click on it, or?
Click to expand...
Click to collapse
nikwen said:
Applications should be installed from the Ubuntu app store. If you've just got the click package, you currently need to use the command line to install it:
Click to expand...
Click to collapse
Technically it should be possible to install a click package just by clicking on a web link, if the web site serves a specific mime type, but this is not implemented.
Not sure about Canonical's policy on that, they might not like the idea. Otherwise they might implement it or at least accept a patch from a community developer.
RareHare said:
OK, apparmour seems to be the focal point. I would be really interested (if any knows), how restrictive apparmour will be with a newly-purchased UT phone, and what control a naive user of that phone will have in allowing native C++ applications to run. I would check this myself, but I cannot do any significant coding (porting) until mid-March.
Click to expand...
Click to collapse
Sorry, have not looked myself into the apparmour profiles too closely and don't have the time to do that right now.
However you can download a recent UT rootfs using the link below and have a look at the profiles yourself:
https://system-image.ubuntu.com/pool/ubuntu-cd4246419c888397c0d8debbd9f945219f40fc670220b7ac86753dc79eb73707.tar.xz
RareHare said:
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.).
Click to expand...
Click to collapse
I don't think this is possible with any current or future off-the-shelf phone. Any OS will provide an abstract API for WLAN and require root to talk to the drivers directly.
As you say requiring your customers to root the phone is not an option, this seems to leave only one way out: you need to split off the low-level code of your app into a generic and secure API and submit it to Ubuntu Touch. If it is accepted, your app can use the new API.
f69m said:
Technically it should be possible to install a click package just by clicking on a web link, if the web site serves a specific mime type, but this is not implemented.
Not sure about Canonical's policy on that, they might not like the idea. Otherwise they might implement it or at least accept a patch from a community developer.
Click to expand...
Click to collapse
Of course, it would technically be possible. Recently, I read a Google Plus post on that topic. Here's the link. (The interesting part is in the comments. Read all of them. )
They said that they'll offer those options in the future.
f69m said:
Technically it should be possible to install a click package just by clicking on a web link, if the web site serves a specific mime type, but this is not implemented.
Not sure about Canonical's policy on that, they might not like the idea. Otherwise they might implement it or at least accept a patch from a community developer.[
Sorry, have not looked myself into the apparmour profiles too closely and don't have the time to do that right now.
Click to expand...
Click to collapse
I am in the same situation myself - I do not have enough time to experiment with apparmour, so I'm asking Ubuntu so that I do not have to search/guess.:victory:
I don't think this is possible with any current or future off-the-shelf phone.
Click to expand...
Click to collapse
So it would seem.
Any OS will provide an abstract API for WLAN and require root to talk to the drivers directly.
As you say requiring your customers to root the phone is not an option, this seems to leave only one way out: you need to split off the low-level code of your app into a generic and secure API and submit it to Ubuntu Touch. If it is accepted, your app can use the new API.
Click to expand...
Click to collapse
Well, the low-level code, in my case, is the WiFi drivers. Also, I cannot imagine submitting a new API to Ubuntu Touch every-time a new model for accessing system-level primitives arrive. That would essentially loop Canonical into all of our engineering processes.
Your last comment actually is the crux of the issue. It points to a policy question, not a technical one, and one for which the answer is yes or no. I would imagine that, at this point, Canonical already knows the answer...
Principle:
There are numerous situations where it is good for a native application to not be sand-boxed, but have the same access to the Linux subsystems as a user would have on Ubuntu Desktop. There are situations where the owner of the phone would be sophisticated and comfortable enough that s/he can decide for himself/herself whether an application should be allowed root access to the phone. A fellow engineer called this the "welded-hood" principle:
Do people prefer buying cars that have the hoods welded-shut?
Many people might, but there are a significant number who would prefer not. As it turns out, an automobile can dangerous if the person opens the hood and starts working on things that s/he should not be touching (no pun intended). In the case of the fuel and braking system, it can even be lethal. But in the end, it was decided that, since we are all liberated adults, it is better to allow the customer freedom-of-choice.
What we have, right now, is a situation where the "hoods" on all mobile devices are essentially welded shut. I think that is unfortunate, because there is a huge latent demand for mobile devices that "still have their hoods", but if the user chooses to open the hood, with they key word here being easily, that would be his/her prerogative.
By the default, the system should be sand-boxed, but the user should have a facility that allows him/her access to install some native, system-level applications, easily, just as a user is allowed to tap-off her break fluid or bleed the fuel-line if she so desires, even though there are many warnings about what could happen if the application is installed. The "open-the-hood" operation would come with warnings that the user can choose to ignore, with resulting consequences.
Question:
Will Ubuntu Touch allow the owner of an Ubuntu Touch phone to side-load a native C++ application that interfaces with the various existing WiFi drivers in Linux, if the user decides for himself/herself, that it is OK for the application to interface with such drivers?
I have a feeling that the answer is no, but I am asking here to make sure.
RareHare said:
I am in the same situation myself - I do not have enough time to experiment with apparmour, so I'm asking Ubuntu so that I do not have to search/guess.:victory:
So it would seem.
Well, the low-level code, in my case, is the WiFi drivers. Also, I cannot imagine submitting a new API to Ubuntu Touch every-time a new model for accessing system-level primitives arrive. That would essentially loop Canonical into all of our engineering processes.
Your last comment actually is the crux of the issue. It points to a policy question, not a technical one, and one for which the answer is yes or no. I would imagine that, at this point, Canonical already knows the answer...
Principle:
There are numerous situations where it is good for a native application to not be sand-boxed, but have the same access to the Linux subsystems as a user would have on Ubuntu Desktop. There are situations where the owner of the phone would be sophisticated and comfortable enough that s/he can decide for himself/herself whether an application should be allowed root access to the phone. A fellow engineer called this the "welded-hood" principle:
Do people prefer buying cars that have the hoods welded-shut?
Many people might, but there are a significant number who would prefer not. As it turns out, an automobile can dangerous if the person opens the hood and starts working on things that s/he should not be touching (no pun intended). In the case of the fuel and braking system, it can even be lethal. But in the end, it was decided that, since we are all liberated adults, it is better to allow the customer freedom-of-choice.
What we have, right now, is a situation where the "hoods" on all mobile devices are essentially welded shut. I think that is unfortunate, because there is a huge latent demand for mobile devices that "still have their hoods", but if the user chooses to open the hood, with they key word here being easily, that would be his/her prerogative.
By the default, the system should be sand-boxed, but the user should have a facility that allows him/her access to install some native, system-level applications, easily, just as a user is allowed to tap-off her break fluid or bleed the fuel-line if she so desires, even though there are many warnings about what could happen if the application is installed. The "open-the-hood" operation would come with warnings that the user can choose to ignore, with resulting consequences.
Question:
Will Ubuntu Touch allow the owner of an Ubuntu Touch phone to side-load a native C++ application that interfaces with the various existing WiFi drivers in Linux, if the user decides for himself/herself, that it is OK for the application to interface with such drivers?
I have a feeling that the answer is no, but I am asking here to make sure.
Click to expand...
Click to collapse
Well, your comparison is not quite correct. On most phones, there is a way for an educated user to open the hood. This is usually referred to as rooting the phone. Some companies will give you a tool to unlock the bootloader and thus open the hood easily, for others it is a little harder. But any user has the freedom of choice to open the hood or leave it closed.
Now, what you are asking for is something completely different. You are asking for a closed-source "black box" app to get access to what is under the hood, without the user ever opening it. This would mean opening the door for all kinds of malware, and I sure hope this will not be allowed by Ubuntu Touch . Let an educated user open the hood and place the black box there, if he feels comfortable about it, but don't make it too easy. A user that is not willing or not able to open the hood himself should also not be required to understand the consequences of installing a black box app with root privileges.
And there is another thing to consider: Ubuntu is heading for convergence, meaning the same app runs fine on a phone, on a tablet and on a desktop. This means apps must be written against an abstract SDK and not have access to the actual hardware.
Well, I am afraid we have hit a dead end now, unless you are willing to disclose more details on the functionality of your app.
Sent from my TF300T using Tapatalk
83594455 676
And there is another thing to consider: Ubuntu is heading for convergence, meaning the same app runs fine on a phone, on a tablet and on a
desktop. This means apps must be written against an abstract SDK and not have access to the actual hardware.
Click to expand...
Click to collapse
I think my native, system-level app would not only run on all versions of Ubuntu, regardless of device, but most versions of Linux, on 100's of different hardware devices, without changes to my code. So actually, I would be accessing a standard Linux software interface.
Well, I am afraid we have hit a dead end now, unless you are willing to disclose more details on the functionality of your app.
Click to expand...
Click to collapse
Sure. I would like to send and receive raw 802.11 frames from user-space utilizing the various standard Linux 802.11 system-level API's for mesh networking. My application is entirely user-space, and would run on any stock Linux kernel. My field of work is wireless communication, so naturally, if someone were to offer me a mesh-networking packaging as an alternative, I could not use it - my goal is not to have a mesh network for mesh networking sake, but to create a mesh network using my own user-space algorithms. In other words, I really do need access to the 802.11 drivers.
You can run every system command from your app using C++: http://askubuntu.com/questions/288494/run-system-commands-from-qml-app
The sudo password is "phablet". You could also ask the user for it if it was changed. You can pass it like this:
Code:
echo phablet | sudo -S <my command>
That might help you.
You could also ask in the IRC channel for Ubuntu app development (search the internet and you'll find it). Some Canonical people as well as some awesome community members will surely answer your questions. (But tell us the result, please.)
nikwen said:
You can run every system command from your app using C++: http://askubuntu.com/questions/288494/run-system-commands-from-qml-app
The sudo password is "phablet". You could also ask the user for it if it was changed. You can pass it like this:
Code:
echo phablet | sudo -S <my command>
That might help you.
Click to expand...
Click to collapse
That works for the development images and community ports, but I am afraid if you buy a pre-configured UT phone (once they are available), sudo will not work. At least I would be surprised if a company would give full warranty for a device with working sudo.
Sent from my TF300T using Tapatalk
---------- Post added at 11:14 PM ---------- Previous post was at 11:02 PM ----------
RareHare said:
I think my native, system-level app would not only run on all versions of Ubuntu, regardless of device, but most versions of Linux, on 100's of different hardware devices, without changes to my code. So actually, I would be accessing a standard Linux software interface.
Sure. I would like to send and receive raw 802.11 frames from user-space utilizing the various standard Linux 802.11 system-level API's for mesh networking. My application is entirely user-space, and would run on any stock Linux kernel. My field of work is wireless communication, so naturally, if someone were to offer me a mesh-networking packaging as an alternative, I could not use it - my goal is not to have a mesh network for mesh networking sake, but to create a mesh network using my own user-space algorithms. In other words, I really do need access to the 802.11 drivers.
Click to expand...
Click to collapse
Hmm, never really used the user-space network link interface, but I believe it would be possible to grant the required capabilities to a click application.
You would have to figure out, exactly what capabilities your process needs to run this as a non-root user. Then the right place to ask for supporting this would be the Ubuntu Phone mailing list.
Just a Tip: You should present a very strong use case to get this kind of capabilities. The benefits of using your user-space algorithms should be plain, even to someone just scanning over your email.
Sent from my TF300T using Tapatalk
f69m said:
That works for the development images and community ports, but I am afraid if you buy a pre-configured UT phone (once they are available), sudo will not work. At least I would be surprised if a company would give full warranty for a device with working sudo.
Click to expand...
Click to collapse
When nikwen made the suggestion, I was happy for maybe 2-3 seconds, but then caught myself, because I suspected this.
[Notice how I am saving myself enormous amounts of time and frustration by avoiding downloading the SDK, opening my compiler tool-chain, and experimenting., and discovering all the things that you are telling me as we go along (especially about apparmour). Yes, I am very proud of myself for saving myself so much time by asking questions here. :angel:]
So my question still stands:
Under the assumption that my customers (doctors, scientists, etc.) are mature/sophisticated/responsible/whatever enough to know that the application that they are about to install on their smartphone (mine) is potentially very dangerous, but they are still interested in installing my app, and that they are uninterested in going through the manual process of rooting their phone or engaging in any other type of significant manual reconfiguration, what are my options?
Can Ubuntu Phone to be the OS-of-choice for this situation, or am I out-of-luck?
RareHare said:
Under the assumption that my customers (doctors, scientists, etc.) are mature/sophisticated/responsible/whatever enough to know that the application that they are about to install on their smartphone (mine) is potentially very dangerous, but they are still interested in installing my app, and that they are uninterested in going through the manual process of rooting their phone or engaging in any other type of significant manual reconfiguration, what are my options?
Can Ubuntu Phone to be the OS-of-choice for this situation, or am I out-of-luck?
Click to expand...
Click to collapse
Maybe my second answer and your post crossed? But anyhow, here are the steps you can take:
1) Figure out the minimum set of capabilities your process needs to run as a non-root user.
2) Write an email to the Ubuntu Phone mailing list, describing the required capabilities and a convincing use case that motivates the engineers to have a hard look into it.
Honestly, I think the chances are slim, given the kind of capabilities you probably need. But Ubuntu Touch is probably your best bet of all the OSs out there.
EDIT: Mind that Ubuntu Touch uses a read-only rootfs, with only some config files being writable (via bind mount) and apt/dpkg is not supported. Your app must be running as a click package as a non-root user, but I believe it is technically possible to elevate an app process with certain capabilities. It would be your job to convince Canonical to make the policy decision to support it and to make the effort of implementing it.
EDIT2 (you see, I am giving it some thought): Not sure, how your business plan looks like or if your app makes this approach feasible, but another option could be to open-source your basic algorithms and try to have them included into Ubuntu Touch. Then cash in on an app to make the features easily accessible.
f69m said:
That works for the development images and community ports, but I am afraid if you buy a pre-configured UT phone (once they are available), sudo will not work. At least I would be surprised if a company would give full warranty for a device with working sudo.
Sent from my TF300T using Tapatalk
---------- Post added at 11:14 PM ---------- Previous post was at 11:02 PM ----------
Hmm, never really used the user-space network link interface, but I believe it would be possible to grant the required capabilities to a click application.
You would have to figure out, exactly what capabilities your process needs to run this as a non-root user. Then the right place to ask for supporting this would be the Ubuntu Phone mailing list.
Just a Tip: You should present a very strong use case to get this kind of capabilities. The benefits of using your user-space algorithms should be plain, even to someone just scanning over your email.
Sent from my TF300T using Tapatalk
Click to expand...
Click to collapse
Hm...it would be a bit weird for me to justify the benefits my user-space algorithms to Canonical. My app is not an open-source app. I guess I should have mentioned that first. In any case, I can say that I am "experienced" in this field, and my colleagues, at least, are experts in the field, so if the question is whether I am mistaken in thinking I need this capability, the answer is probably no.
However, you do have me intrigued regarding the granting of capability for a click application. My guess is that this would have to happen within the context of Ubuntu Store and not any other way or?
I ask because it is not yet definite that we will choose Ubuntu Phone. That is what I am determining now. I would hate to get into a situation where we have to "work with" Canonical to get access to the Linux API that we need, which is why I was suggesting putting the decision into the hands of the user. I would also like to avoid "lobbying" Canonical for a feature. It would be more efficient for us if Canonical would simply tell us whether they are going to allow it or not, to what extent, and what would be involved.
Again, what we are asking for is pretty straightforward - access to the standard Linux WiFi drivers from user-space.
There's really not much more to it. I was hoping that, based upon the assumption that we actually need this, that Canonical would be able to give us an answer.
[P.S. Yes, our posts got crossed. ]
RareHare said:
Hm...it would be a bit weird for me to justify the benefits my user-space algorithms to Canonical. My app is not an open-source app. I guess I should have mentioned that first.
Click to expand...
Click to collapse
Well, I somehow guessed it would not be open source, and probably my EDIT2 to my last post (crossed again) is not an option. But make sure to read my first EDIT, it might have helpful information.
I think the question is not, if it is a benefit to Canonical directly, but if it is a benefit to potential users of Ubuntu Touch. The API support you need might be helpful for other applications too.
RareHare said:
However, you do have me intrigued regarding the granting of capability for a click application. My guess is that this would have to happen within the context of Ubuntu Store and not any other way or?
I ask because it is not yet definite that we will choose Ubuntu Phone. That is what I am determining now. I would hate to get into a situation where we have to "work with" Canonical to get access to the Linux API that we need, which is why I was suggesting putting the decision into the hands of the user. I would also like to avoid "lobbying" Canonical for a feature. It would be more efficient for us if Canonical would simply tell us whether they are going to allow it or not, to what extent, and what would be involved.
Click to expand...
Click to collapse
Any decision taken by the user must first be implemented by Canonical, or there is no way for the user to make that decision. Unfortunately, I am not an expert on UT app development and the UT SDK, working mostly on low-level things like porting UT to my own device. But, as an example, it should be possible to have an API that creates a sub-process with elevated capabilities (there might be a more elegant solution). Still Canonical will have to implement that and to do this, they need some kind of motivation. The motivation could be a good use case that shows potential for other applications or indeed "lobbying" them directly (which probably means to send them some money).
RareHare said:
Again, what we are asking for is pretty straightforward - access to the standard Linux WiFi drivers from user-space.
There's really not much more to it. I was hoping that, based upon the assumption that we actually need this, that Canonical would be able to give us an answer.
Click to expand...
Click to collapse
I have not really used those APIs, but I assume that the kernel capabilities needed for this are usually granted to the root user only. I am pretty certain that UT will not allow you to run a process as root, but as mentioned above, it should be possible to create a subprocess with certain elevated capabilities.
f69m said:
Well, I somehow guessed it would not be open source, and probably my EDIT2 to my last post (crossed again) is not an option. But make sure to read my first EDIT, it might have helpful information.
Click to expand...
Click to collapse
OK.
f69m said:
I think the question is not, if it is a benefit to Canonical directly, but if it is a benefit to potential users of Ubuntu Touch. The API support you need might be helpful for other applications too.
Click to expand...
Click to collapse
Well, the API that I need is definitely helpful for other applications. Namely, it is helpful to any application that already uses it. And there are many such applications that use the 802.11 WiFi drivers that come with Linux.
Any decision taken by the user must first be implemented by Canonical, or there is no way for the user to make that decision. Unfortunately, I am not an expert on UT app development and the UT SDK, working mostly on low-level things like porting UT to my own device. But, as an example, it should be possible to have an API that creates a sub-process with elevated capabilities (there might be a more elegant solution). Still Canonical will have to implement that and to do this, they need some kind of motivation. The motivation could be a good use case that shows potential for other applications or indeed "lobbying" them directly (which probably means to send them some money).
I have not really used those APIs, but I assume that the kernel capabilities needed for this are usually granted to the root user only. I am pretty certain that UT will not allow you to run a process as root, but as mentioned above, it should be possible to create a sub-process with certain elevated capabilities.
Click to expand...
Click to collapse
OK.
I am going to send an email to Canonical asking if they could articulate, clearly, in a manner that a Linux C/C++ software engineer can understand, their policy on native application development. Here's what it currently says on their Wiki:
Which applications do run on Ubuntu Touch?
Ubuntu Touch is primarily designed to support web apps, and native apps programmed in qml and javascript or C++. As it is a real linux, of course all non graphical applications run equally as on any other linux system. You can ssh to Ubuntu Touch and run any console based application.
X11 is not supported (so far) so all GUI standard applications will not run.
This is slightly confusing, because it gives the impression that, with the exception of X11, the run-time environment on Ubuntu Touch is equal to the run-time environment on Ubuntu Desktop.
Obviously, that is not true. Native applications on Ubuntu Touch are sand-boxed. My customer can run a console app on Ubuntu Desktop just fine, but on Ubuntu Touch, she cannot not - I guess she could if she rooted or re-flashed her phone, but that is not practical.
I think Canonical should make it clear that native C/C++ applications on Ubuntu Touch will be sand-boxed. Then they should articulate, clearly on their web site, just how that works, at least the part that they know so far.
The reason I feel this is necessary is that there are a lot of developers who read the press releases and see the words open source native C/C++, more open than Android, etc...and they get the impression that it is basically Ubuntu Desktop for small form-factor, but that is not quite true.
Spelling-out, explicitly, Canonical's native C/C++ strategy would save such developers a lot of time and hacking trying to figure out what is feasible and what is not.
To be fair, I just received feedback from a competitor to Ubuntu Touch, giving me assurances that the competing OS will allow the user/owner of the phone to determine whether any software should have root access, etc - basically, like the desktop version of the OS. I will send them an email asking them if they could make public what they have assured me in private.
These are things that should be crystal clear to C/C++ software developers long in advance before committing to a platform. I can only imagine the time that would have been lost if I had misinterpreted what Canonical wrote above, only to find out that there is nothing practical that my customer can do to install my application as easily as they would on Ubuntu Desktop because of the sandbox that cannot be easily turned-off.
RareHare said:
I think Canonical should make it clear that native C/C++ applications on Ubuntu Touch will be sand-boxed. Then they should articulate, clearly on their web site, just how that works, at least the part that they know so far.
Click to expand...
Click to collapse
Of course I can't speak for Canonical and I might be wrong, but I would really be surprised, if it was possibly to run applications as root on an off-the-shelf Ubuntu Touch device.
RareHare said:
To be fair, I just received feedback from a competitor to Ubuntu Touch, giving me assurances that the competing OS will allow the user/owner of the phone to determine whether any software should have root access, etc - basically, like the desktop version of the OS. I will send them an email asking them if they could make public what they have assured me in private.
Click to expand...
Click to collapse
Interesting, but then it might be a difference between the "reference" implementation and what is being delivered on an out-of-the-shelf phone. I can't belive a device vendor to take the risk of allowing root access and still providing full warranty. Most likely the user will have to accept a "no warranty" waiver to get root access, if that feature is not completly disabled by the device vendor. The same kind of holds for UT, as sudo works on the development images as mentioned previously.
EDIT: Make sure the feedback you received does refer to an actual device that is/will be available for sale and not to a development platform. Marketing wording can be tricky about simple issues like that,
RareHare said:
These are things that should be crystal clear to C/C++ software developers long in advance before committing to a platform. I can only imagine the time that would have been lost if I had misinterpreted what Canonical wrote above, only to find out that there is nothing practical that my customer can do to install my application as easily as they would on Ubuntu Desktop because of the sandbox that cannot be easily turned-off.
Click to expand...
Click to collapse
Agreed, but the same holds for any other platform.
f69m said:
Of course I can't speak for Canonical and I might be wrong, but I would really be surprised, if it was possibly to run applications as root on an off-the-shelf Ubuntu Touch device.
Interesting, but then it might be a difference between the "reference" implementation and what is being delivered on an out-of-the-shelf phone. I can't belive a device vendor to take the risk of allowing root access and still providing full warranty. Most likely the user will have to accept a "no warranty" waiver to get root access, if that feature is not completly disabled by the device vendor. The same kind of holds for UT, as sudo works on the development images as mentioned previously.
Agreed, but the same holds for any other platform.
Click to expand...
Click to collapse
I was very careful in asking the UT-competitor what their policy would be with regard to the subject of this thread, and they assured me that, when they say open, they really do mean open, as in open-like-the-desktop. However, just now, I found clues on the Internet what they said might not be quite true. So I just sent a grab-me-by-the-ears-while-you-are-speaking email asking them to be clear.
However, they have committed to allowing the user to install my application. They know that my application will open a device driver, and they said that it should work fine, that they would allow the user to do it, and that they had already intended to create a feature where the user gets to decide, after a WARNING, though they are not yet certain what this feature will be called. Note that they are not doing this for me alone. They are doing it, in general. In other words, they are doing what I proposed earlier: give the user the choice of whether to "use metal chainsaw".
As far as voiding the warranty goes...honestly, I do not think that will be a problem. As you know, I can write software that will wipe my hard disk clean on Windows, right now, put it up on my web site, and anyone in the world can download that software, and the most that will happen before they install my application is that they will get a brief warning. So the model for allowing the user to do foolish things has been with us for a while, and companies are still very profitable with this model, and despite viruses (I developed anti-virus algorithm that some of you use, btw), most people are happy with the level-of-control they get with their desktop devices. When Windows Vista tried to remove some of it, even moderate users were very angry, as you know.
I think that, especially for cell-phone carriers in the USA (Verizon, AT&T, Sprint)...the reason is not so much to protect the consumer, but to make sure that the user is not able...for example...to remove the bloatware that they put on the phone. It is more about controlling the customer experience for profit than for protection or being liable for damages.
The UT-competitor has probably figured out that there is a market for a truly open mobile platform, one where the decision of what happens to the device reverts to the owner of the device. They are probably counting on all the pent-up demand of C/C++/etc. native software developers who have been trying to escape the Android/Java iOS/* Sandbox, and not only that, the developers who are able to create revolutionary innovations if they had more access to the Linux API. My guess is that, once one OEM takes this path, the others will not have any choice but to follow, because there will be a free-for-all (no pun intended) in the development market. It will be messy, perhaps, but there will no longer be any restrictions on getting the most out of the device.
It will definitely be more efficient to decouple development from deliverance.
Well, sounds good, just hope that they will find an OEM that shares their views. I think Desktop/Windows is not a relevant reference, as nobody will send their PC back to Microsoft, if it is not working. And if you want to use official MS support you are paying dearly. On the other hand support/warranty is a huge concern for phone and tablet vendors.
Again, not being able to run a process as root on a UT device is my personal opinion and I am not speaking for Canonical or their partners.
EDIT: Do the "bad" operations you mentioned work on Windows 8 phone? I suppose not.
Sent from my TF300T using Tapatalk
Hi all,
I'd like to share great news. Sicher, our free secure messenger finally comes to Windows Phone.
Sicher features true end-to-end encryption of both text messages and file attachments. With anonymous push notifications and the ability to set a timer for when messages will self-destruct, Sicher also includes password protection for the app itself.
Please try Sicher and share your feedback in this post.
FairyMary
Sicher Team
App is free, store link is here: EDIT: Removed because this thing looks like a scam and its description is a lie
I haven't been able to find a lot of info about how the app works (I'm talking about at a very technical level). My general advice regarding crypto code is to open it up for review, either publicly or by a professional security assessment firm (disclaimer: I work at one of those). If the code is already open for review somewhere, that would be awesome; if not, I recommend getting in touch with some external security experts (same disclaimer, but I can provide contact info if you want). The Internet is full of things that the developer claimed (and often even sincerely believed) were secure.
Aaaand just for fun, I decided to take a look at the app and see if there was anything obviously wrong. Let's start with the presence of no fewer than *three* advertisement networks, shall we? Begun Advertising is Russian and Google-owned, Google AdMob is self-explanatory, as is Microsoft Advertising Mobile. Your store description claims you
don’t use any advertising engines
Click to expand...
Click to collapse
. Did you really think nobody would check this?
WTF are you trying to pull here?!? I can't think of any way to faster burn trust in a "secure" app than to make a claim that is trivially disprovable in a way that benefits nobody except you.
I'll come right out and say it: Sicher looks like a scam!
Oh look, a Facebook library as well. Totally expected to see that, given that you
don’t integrate social network SDKs
Click to expand...
Click to collapse
Oh, and before anybody asks about responsible disclosure, that's for when there's an unintentional bug in somebody's code. This just looks like pure exploitation of your users! (I say "looks like" because I haven't actually decompiled the code to see if those libraries are being used, but it's hard to imagine why you'd have them otherwise...). The only responsible way to disclose malware is to do it publicly, and this looks malicious.
EDIT: I'll give you 24 hours to give me a good argument why I shouldn't report my findings to the stores themselves.
Time's up. You actually got over 48 hours because I was busy yesterday. Hope not too many people got scammed and tracked by your "secure" and "private" app...
Hey @GoodDayToDie, unfortunately I don't know where else to ask this, since you seem to be really interested (and skilled) in this topic, what messengers do you consider secure? WhatsApp is obvious, the only ones on Windows Phone I know of that come to my mind are Telegram and (soon) Threema.
What do you think about the two? I have basically no knowledge, but what seems odd to me about Threema is their faqs answer to "what about MITM?" they just say they use certs, hardcoded in the app. Aren't they with their servers in control then? How I understand this, the Threema servers could perfectly perform a MITM attack.
And Telegram has a completely confusing protocol.. So please share your thoughts!
I have no personal knowledge of one, sadly. Take anything I say here with a huge grain of salt (including the fact that Sicher looks like a scam; I haven't actually verified that it *uses* all those ad networks + Facebook that it integrates, just that it has them) as I'm not spending the time & effort for a full security review of these apps at this time.
Threema actually looks quite good.
Pros:
They don't try to implement the crypto themselves (they use NaCl, which is both written by people who know what they're doing, and well-reviewed).
The design of their end-to-end solution makes sense (it connects through the server since phone networks won't allow incoming/direct connections, but the messages are encrypted to only the recipient and doesn't require that the recipient be online to receive the message).
They are relatively open about how things work (although those *could* be lies; I haven't pulled the app apart).
It is possible for the user to verify the key of another user.
Cons:
They don't have Perfect Forward Secrecy on messages. PFS would require that the intended recipient be online at the start of any given conversation (to negotiate the ephemeral keys) so this isn't terribly surprising, but it is disappointing. An attacker (including a government agency) who gets access to your private key could decrypt historical traffic to you if they'd recorded it.
The app is proprietary; there's nothing stopping them from pushing a malicious update.
The server supplies the public keys of users; until such time as the user validates the other party's key (which is difficult to do except in person) the server could have sent a public key that the server has the private key for (instead of the user's own public key) and then MitM the user's traffic. This would break down when verified though, unless the app lied about the result of the verification process (you don't actually see the key itself).
To address your concern about MitM, the app says they use certificate pinning (a standard and very smart security measure, assuming they did it right) for app-to-server communication, so nobody (including third-party security engineers) can MitM the app traffic. They also claim to use PFS. However, if the server itself is untrusted (i.e. some government thugs show up to demand access, although bear in mind that apparently the servers are all in Switzerland) then the server could give you the wrong public key for a user you try and add, allowing the server to MitM you. Also, the company could push an update that is malicious.
The only protection against the server-sends-wrong-key threat is to either require that the user manually import all keys (think PGP minus keyservers and assuming trustworthy key exchanges) or exactly verify the key (i.e. personally ensure that it matches the other user's key by actually checking the bytes or at least the hash). The only protection against the malicious update is to make the source code available and have a method by which users can either compile it themselves (though see "Reflections on Trusting Trust") and/or have a way to verify the application binaries.
I'll look at Telegram later. For the moment, though, I would loosely recommend Threema once it's available. There's also Skype, of course, but while it was decompiled once long ago (and found to use secure encryption, although some non-crypto vulns were found) that was many versions ago (and, in particular, was before Microsoft bought them).