Database Info

SecAndy : let's get the party started

Pronounced "say candy", the goal of SecAndy is to come up with as secure and private of an OS as possible. So as not to reinvent the wheel, we'll base this initiative on our open source code of choice (Android or maybe other developers' choice).
I am not a developer myself but I can without a doubt, because of former professional experiences, organize a project and gather the right people together as a community in order to make sure that project sees the light of day after it has acquired a life of its own if needed, which I think we will agree is something that this kind of project requires because of the scrutiny it will quickly attract.
I am officially calling upon this post all interested developers that could help us fork Android or other open source OS.
Let's get a kickstarter funded and let the party begin. I will update you later today on the advancement of such.

This thread welcomes constructive ideas and developer participation, but here are beginning requirements we'll need to fulfill eventually to privatize and secure android :
- default browser allowing custom search engines such as https://ixquick.com or duckduckgo
- default system search pointing to those custom engines for online component
- control of gps at firmware level to allow full disability
- peer to peer file exchange (think BitTorrent sync) with 1024 to 2048 bit encryption
- implementation of secure sms and mms exchange (think textsecure)
- implementation of encrypted voice channels (think redphone or SIP with end-to-end encryption)
- root vpn for all online access
- systemwide warning of insecure solutions (example : wanting to use gmail or regular email)
- PGP transparent email solution
- Tor option for root vpn (subject to mitm attacks but more on that later)
- peerguardian type auto-updated database to identify suspicious IP address ranges
- systematic in-out firewall control auto updated with peerguardian database and community based rules database
- hardened malware protection and app permissions with automatic permission audit based on application type
- full device encryption and lockup (in case of unauthorized user)
- full remote wipe out and bricking with auto IMEI reporting (in case of theft, might have to be amended because of attack vector)
- full remote location capability with real time tracking (that one might have to be scratched, high security risk because of attack vector)
This obviously doesn't cover all the bases but would be a good start... I know a lot of these options can be implemented with a mismatch of apps and custom Roms but having it all at an OS level AOKP style would greatly help in building an android by the people for the people community that could eventually loosen the stranglehold of less than transparent corporations.

60 views in 24 hours and not one comment. Obviously I'm approaching this the wrong way. More news at 11.

e-motion said:
60 views in 24 hours and not one comment. Obviously I'm approaching this the wrong way. More news at 11.
Click to expand...
Click to collapse
I don't want to be insulting, but no programming work has been done on your part, and you're just asking for people to dive in this project to get managed by someone they never heard of. It's not really surprising no one has commented yet.

I understand what you're saying but any comment, even if only just to show interest in such a project, will be key to drive developers to it.
I might not have started any development but I have clear understanding of how to design secure solutions. I can't go into details of why that is, however you can clearly see with my 2nd post that some research has been done. If I wanted a solution for me alone, I could just go on with my own little pudding of custom ROM and security apps.
However, because of the recent news events that SHOULD have awaken this population, I thought now might finally be the right time to try to get such a project off the ground. But without anyone even showing any interest, why would any developer be drawn to it ? If people would rather focus more on content consumerism than on what might happen under an umbrella of spooks that they're paying for with their taxes, then they have learned nothing from history and deserve what's coming to them, simple as that.
This is NOT a development thread in case you haven't noticed, so telling me I haven't developed anything yet is not even relevant.

In case anyone cares, this will be moved shortly in the t-mobile Note 2 Android development thread as a Touchwiz proof of concept ROM. Little steps, little steps...
Sent from my SGH-T889 using Tapatalk 2

mobile sec
While I am not a developer I would be interested in this project. I've been thinking about this a bit lately given recent events. I think a useful privacy preserving security related app and phone combo might have these features:
-some way to separate the baseband processor (radio) from the OS. It seems most phones share memory with the radio and this fact can and has been exploited. Own the bb processor and you own the phone. Perhaps a 3g dongle plugged into an android phone in host mode would work. Some of these usb "data only" radios can be unlocked for voice too. I believe a rooted phone with IP tables/firewall running would be much more secure than a conventional mobile phone.
-an anonymising network for connecting to servers/peers. I think the i2p network is well suited for this purpose. Rather than connect to services that are not designed with your anonymity/privacy in mind, connect to hidden/darknet servers that make it extremely difficult to ascertain your real IP and location. Perhaps an i2p router running on your home computer relaying i2p traffic while also maintaining a long lived encrypted connection to your mobile in order to "push" data to it. In this way the user benefits from the anonymising network, contributes to the network, but doesn't have the battery drain of relaying packets from the phone (if this is even possible).
-end-to-end encryption. Perhaps OTR messaging for texting and perhaps openPGP for transferring binary files as I don't believe file transfer in OTR is available at this time.
-an app that uses the above network that is capable of sending/receiving encrypted text, audio, video, gps location etc and does not leak any personal information that you don't want leaked. XMPP might be a good choice (with perhaps out-of-band binary transfers for efficiency). Giving your unique identifier to another person that is using the same app would allow you to communicate with them while not revealing your phone number, imei, imsi, etc. There would be some latency in the communication especially with binary transfers but I would gladly accept that for the added security.
anyway, just wanted to add this to the conversation and hope to see this project take shape as we definitely need more security enabled os's and apps.

Freeware Apps - Redefining a Lost Genre

Freeware isnt something you really find much in the Android community.
You hear the term thrown around quite a bit, but even alot of what is termed as freeware, actually isnt.
The Lion's Share of Android apps are not Freeware at all, and the Vast majority of the so-called 'freeware' apps that are available for us to download & use daily are not truly freeware at all
I would like to draft a set of guidelines for what would ideally become a certification standard for the ethical creation & development of free apps
Apps adhering to this standard could be classified under this genre of apps, and even bear a symbol within the app, overlaid on its logo, showing users it belongs and mentioned in the app's description, showing users how it was developed, and stating that it adheres to the guidelines and fulfills the requirements of the new standard.
I would also like to compile a list of any existing apps which already meet these criteria
and all Apps filling these requirements will fall under the realm of this Guild.
Please feel free to offer your own ideas & input as to what you feel would be best for the end user, and any rules or criteria you feel are relevant to forming a framework of guidelines & prerequisites needed for apps to be called under this name, and be brought under the umbrella of this guild.
Please feel free to offer suggestions for the certification & class name and/or Guild name as well
this is all preliminary work, and I'm looking for anyone interested in helping to build this community and standard & promote its use.
There could be 2 classes of apps, Freeware & Benefit-Ware
Or there could just be one set of rules for each, stating "IF.. such and such, THEN... such and such"
If you are an App User, please mention anything you find annoying, bothersome, or troublesome.
If you are an App Developer who knows about or is displeased with the ethics and developments of certain apps which gives other apps and developers bad names, please mention anything you can that might assist us in reigning in the cowboys of the App Wild West.
Also, if somethings are simply & 100% "Not Possible" because of the Android OS, these would be issues the Guild will work to make Individual Device Manufacturers as well as the Android team at Google aware of
So, it could start something like this:
- An app should not contain ads nor promotions which cannot be closed or disabled
- An app should not contain any full-screen ads nor any ads which limit or effect user interaction with the app
- An app should not give reminders which pop up and ask the user for money, ratings, or to download additional apps
- All requests for financial support, ratings, and downloading of additional apps should be contained in the 'About' Section of the Apps Settings
- All apps which produce sound of any sort must include its Volume Controls, including in-app Mute
- All apps with services which wish to run at start up must include their own settings option to enable or disable "Start when Android Starts"
- An app must not Auto-start unless the User has specifically selected it to, nor shall it be kept running if it has not been manually Launched by a User since the last Boot time.
- An app must allow users to manually select the installation directory upon installation
- An app must have its own internal Uninstall button in the "About" Menu Settings
- An app must install 'portably', that is, without adding data to the internal phone storage
- All apps which save data must have a User-Selectable Save Location which can be used to replace the App Default Save Location
- All Apps must Uninstall completely and leave no folder behind, asking users whether or not to uninstall specific items which might contain important user data
I hope other people can add to this list
thanks

I would like to stress that this isnt a knock on any existing programs, nor do I expect anyone to change what they are doing who isn't willing to.
If you hate the idea of this, please continue doing what you are doing.
This is for people who want to join or participate because these are the apps they would prefer to use, or make.
thanks

Others may include:
- An app must ask users whether or not the user wants to add a shortcut to the users default Home screen, regardless of the user's own phone settings. Perhaps an "Allow Shortcut" selection for Shortcuts which are going to be added
- An app must ONLY install shortcuts to the program currently being installed, and can in no way add shortcuts to the Home screen, the apps drawer, or the installation directory, to any other program nor any website at all.
- An app may include a single, small, unobtrusive "Donate/Beer" button on a menu bar with other menu buttons, but to be at the far right or farthest/last menu item available on the menu
- An app must not include permissions for anything other than the express intent & use of the app for its specified purpose.
- No app may, at any time, access a users personal information unless the app has direct interaction with such information as directly related to a service it is providing as a primary function of the app - And even then, the apps access to information must not be sent online nor over the internet unless specified as such due to it being a primary function of the app - and if & when personal information is sent online, the owner of the server must have a secure server which is not accessed by himself or his employees, but in which information is automatically transferred by software to and from the end users needed locations, and to no other place shall the information be passed - Nor shall it be kept on the server while not being sent or received to/from the users locations, without the users express consent, as an additional option.
- A "Primary Function" is defined as a Function which is the main or only reason a user installs or interacts with the site, and will be the main focus of the apps description
- Secondary Functions are not allowed to gain internet access, nor have any interaction with any online server or service, nor be granted any access to personal information nor any stored data outside the apps own install directory, etc.
- Apps must, in a written disclaimer provided in the "About" section of the apps own settings, give specific details as to the apps permissions and justify with specific reasons and technical details why each function requires each form of permission, and exactly how the app will use each permission, including server specifications & information-handling specifics, where applicable.
- Apps qualifying for inclusion in the Guild will clearly label themselves in one of 3 categories exclusively - Freeware, Benefitware, or Trialware.
- Apps labelled as Free, or containing the word "Free" must 1.) be 100% ad-free, 2.) not be a Trial, 3.) be fully functional, & 4.) not bother users for payments, ratings, etc.
- Apps labelled as "Benefitware" may include 1.) ads adhering to the guidelines for the inclusion of ads, 2.) requests for financial assistance in accordance with the guidelines for requests of Financial Assistance, 3.) Added Functionality which is above and beyond the scope of the original, feature-rich, fully-functional program, & 4.) Other items which are primarily of benefit to the developer, but which adhere to the guidelines of Enjoyable, Unfettered User Interaction
- Apps labeled clearly as "Trialware" may 1.) Limit the functionality of the apps Primary Functions, 2.) Must have a fully-functioning trial period of no less than 30 days, 3.) Must not be limited in any way during the Evaluation Period (e.g. no "20-character", "2-page", "3-time" limitations, or the such), & 4.) after the Trial Period, the app will be completely 100% uninstallable, and a re-install of the app on a specific device will begin a new 30-day evaluation (Users will not be treated like criminals nor presumed Guilty of Fraudulent use before proven otherwise).
- Other apps will not gain classification, certification, or inclusion in the Guild, and may refer to themselves in anyway they care to, but may broadly be referred to as "junkware" if they are found to not conform to the Principles, Guidelines & Statutes set forth and adhered to by the Guild & its Members & Affiliates
-

Also:
- An app must have an option to turn off Automatic updates, and may not self-check for updates otherwise.
- All Settings a User sets must be permanent and may not be reset nor shall those permission requests for updates, etc, be altered or changed nor be made to reappear, nor require the user to specify the same setting more than once.
- No app shall ever contact its servers for anything other than a user-launched request for the specific function required by the user at the time of the request.
- No app nor server nor company shall in any way interact with its apps or servers in anyway other than to execute the exact function called for by the user according to the UI meaning and implicit intent of the action
-

I have checked almost all the setting of it..But couldn't find the prior results..What are the other alternatives of it?

MarkanthonyDonald said:
I have checked almost all the setting of it..But couldn't find the prior results..What are the other alternatives of it?
Click to expand...
Click to collapse
Hi, markanthonydonald. welcome to the forum, I see this is your first day registered, and your first post no less.
That's right, all the prior results are belong to the settings of it t almost at all from the prior r results, but dont stop trying your point o of that the alternatives are to us, and thats the most bases of it. ll
-

I like the idea of this, and from what youre saying and a few apps I use would fall into this category just fine IF certain things were moved into the 'about' option. How or why a dev would change their current, 100% working fine app, to modify this I dont know.

robneymcplum said:
I like the idea of this, and from what youre saying and a few apps I use would fall into this category just fine IF certain things were moved into the 'about' option. How or why a dev would change their current, 100% working fine app, to modify this I dont know.
Click to expand...
Click to collapse
Great Idea!
- An App must have a complete Version History contained in the About Menu Settings, or a Menu Item Devoted to Version History, with Detailed explanations as to why the changes were added, and if they are only to fix a bug with device x, why is it recommended to install it if you arent using that device
- Each App Update should be available as a complete App Stand-Alone APK installer, or installable from the Play Store Directly. No App should require Updates, nor provide updates for which there is no Standalone APK or an updated Google Play Installation.
alot of devs set up their apps just good enough to get on Google play, without getting kicked off, and then after you install it, they update the app with functions & behaviors that would get it kicked from the Play Store.
great work catching that one, thanks
-

robneymcplum said:
I like the idea of this, and from what youre saying and a few apps I use would fall into this category just fine
Click to expand...
Click to collapse
If you know of any solid apps that you believe fall into this category, or easily could, please post them here
We need a list of example apps that we feel embody the spirit of honesty, transparency, user-centric programming & packaging, and which are either made in the spirit of true freeware, or made in the spirit of goodwill, and have either Benefitware or Trialware which adheres to consumer-oriented needs & interests
The following behaviors DO NOT qualify for inclusion in the Guild:
- Any app which appears desperate to flash things in front of your face, particularly things which flash or change scenes or color rapidly, change in a single frame, or less than a 1 second cross-dissolve, and which are overly animated, bothersome, annoying, or which may lead to epileptic reactions, which cannot be permanently closed or disabled for the duration of the session.
- Any app which appears to desperately or urgently present users with matters of no immediate significance or importance to the user. This includes the pestering need for ratings, requests for financial assistance, downloading of the developers other apps or partner apps, offers to visit the Play store or any other external website, etc..
- Any Benefit-ware app with any full-screen advertisement at all, from Internal or external sources used to promote the sales, use, or downloading of its own other products & services or those of an external company
- Any Benefitware which does not allow you to close a bar-style advertisement with a clear, easily-accessed, and adequately-sized close button
- Any Benefitware which re-opens an ad which has been closed within the same 24-hour period, or since reboot.
- Any Trialware which limits functionality of its products to a state inconsistent with the primary function of the app
- Any Trialware which does not allow a minimum 30-day trial period
- Any Trialware which limits the functions within its trial period in any way
- Any Trialware which doesnt openly allow a re-installation of a Trial package on fresh uninstall/reinstall
A user is to be given as much time as is required for him/her to fully evaluate the product. Often times a user may begin a 30-day trial period, only to never have the time to use it, including having no time to even look through it the day it was installed
Furthermore, All apps containing promotions of their own products are to be classified as Benefitware, and not Freeware, even if there are no ads from external advertising companies.
Feel free to add to this list, or to add an app you believe warrants inclusion for its programming efforts, ethics, & merits
-

A similar Evaluation Period problem arises when users are given a 30-time evaluation. As one "Evaluation" day is simply a 24-hour period since the app was launched.
Launching the app by accident, or launching the app and immediately closing it, removes evaluation days from your trial, days in which no evaluating took place.
Even if we give each launch a time-specific interval where an app which is running for 10 or 15 minutes is considered "Evaluated" for one day, it doesnt take into account that launching the app then closing it where it sits opened in the background still takes away your evaluation days, or opening it, then answering the door or going to grab a sandwich also takes from your evaluation period
We could find other solutions to this problem, but one of the primary characteristics for an app or developer to be included in the Guild is to treat the user as if they were a guest in an actual store, and not a criminal pirate on a baby-killing spree, meaning:
- No app or developer should treat a user like a criminal, nor assume he is engaging or will engage in criminal activity, nor accuse him of such activities, nor behave in a manner which displays mistrust or accusations of users
- An app & developer must leave it to fate, heaven, and the common goodwill of mankind to have its requests & guidelines (such as for trials, etc) met, and can in no way behave in a manner which is inconsistent with good will
- All agreements made will be made in Good Faith with the community at large
you wont walk into a department store and be tackled by the security guards and forced to pay for something you didnt even try on, simply because you touched in on the rack, or be banned from the store for life until you do pay for it.. simply because the paranoid psychotic lunatic in charge of the store thinks everybody who walks into his store is a dirt-poor crack-head criminal out to steal his supremely precious goods
-

Also:
- An app is not to be created for the sole intention of Data Collection or Information Gathering, and apps which appear to do so will be blacklisted
- An app is not to be developed or created for the primary purpose of spreading advertising spam, shady promotions, other sites & services, etc, and any app found to be out of balance with respect to this criteria will be blacklisted
- Any app found to be in breech of any of the guidelines shall be blacklisted. Concerned Members could write a letter to the developer instructing them on the things they could change for inclusion in the Guild, if they so choose
- No app shall include advertisements or links of/to any shady or malicious programs or websites, including phishing sites, spoof sites, porn sites, or any site which executes malicious code or scripts, or which is deemed as an unhealthy website, program, or service by the world-wide community of web experts as a whole
- Any app or developer found in severe breech of the spirit of the Guild will be banned for life. Severe offenses include things such as falsifying information, deception, betrayal, lying, perpetuating viruses/malware or web-based attacks, hacks or intrusions, or stealing private information & personal data; the gathering of personal data for uses unspecific to the service or which willfully compromise the security & privacy of users; or if an app or developer is found to be using the information & data of users in a way which destroys the Integrity & Trustworthiness of the app & developer, and undermines, corrupts, corrodes, or destroys the Trust & Faith the community has put in the app & developer
-

chinarabbit said:
If you know of any solid apps that you believe fall into this category, or easily could, please post them here
Click to expand...
Click to collapse
I use zeam launcher, that definetely qualifies.

robneymcplum said:
I use zeam launcher, that definetely qualifies.
Click to expand...
Click to collapse
Cool, thanks
It seems its not under development anymore.
Perhaps a goal of the Organization can be to encourage, promote, or reward excellence in Programming as well..
It may help to motivate devs who've grown disassociated or whos apps may not be getting the attention they deserve.
I currently use Lightning Launcher, and I would definitely say it qualifies as well. It has the most features of any launcher I've tested, and one of the smallest foot prints as well.. its fast and minimalistic, and completely free, and never bothers you about anything.. it has more features than you'd expect from any high-priced app.. if it has additional paid options I dont even know, as the app is extremely feature rich and has all the functions you could ever want, and many more you havent even thought up yet
These kinds of apps make using Android Phones worthwhile
-

Other important requirements -
- Any App wherein the user enters personal, private, or sensitive information, which has the ability to sync Across Devices & Computers through Web-based Servers, shall:
- Provide a switch to turn off all syncing options & functions
- Provide an adequately useful method for SD Card Storage export which is not dependent on the software which was used to create it
- Be fully functional, practical & useful, as per the intent for use of the primary function of the app, in an offline state.
- No app shall automatically start Services such as GPS, Wi-Fi, etc, without offering a user Prompt for acceptance of such actions
- All apps which turn on services like GPS, Wi-Fi, Bluetooth, etc, shall contain a settings option to permanently disable turning on of any such external services
- All information Sent or Received through online servers or web services shall be secure & inaccessible by the host, in the following ways:
- The information & data sent by users shall enter the server and leave the server, and not be kept on the server except for the brief moment during transfer, without being subject to any sort of copy mechanism, nor filter, nor scan, nor shall accessing the content in any way while the information is passing through the server be allowed
- Information & Data uploaded to storage servers for later access by users shall be encrypted by the server administrators with 128-bit encryption, and be stored thus encrypted until it is Retrieved from the server by the user or users granted password access by the owner of the information.
- Server administrators & owners are forbidden from accessing any user information on their servers, and must encrypt the files & user data in such a way that its available only to the user, and otherwise remains in a software-encrypted state upon the server, inaccessible by server admins & owners
- Servers shall be vigilantly maintained and frequently tested for security
- If a server is used for "cloud" storage by the user, the User Data shall be backed-up in an Encrypted state, and frequently tested for data integrity
- Servers which are not secure and which do not encrypt user files & data files, or which do not design themselves to be secure from admin access of data and other third-party viewers, shall be known as "Public Servers", and a Warning Prompt shall appear on the device or computer each time the Server is accessed and data is sent or received (there shall be no method for disabling this prompt). The Warning Message shall clearly state the user is accessing a "Public Server" (capitalized) and that any data sent or received is freely viewable to third-parties, and server owners & administrators shall include themselves as third-party viewers
- First Party users & viewers (hereafter referred to as the "Owner") are designated as both the Device & User which uploaded the data to the server for storage
- Second Party users & viewers are defined specifically as both the Device & User which downloads or accesses the data which was previously stored, and who has been given password-protected permission by the Owner (First Party)
-Third Party is broadly inclusive of any organization, company, or individual who has access or potential access to the Owner's Data. Third Party also includes Devices, Computers, Servers, & Software which handles, accesses or views (or has the potential to do so), in an unencrypted state (not 128-bit or higher), any data or information belonging to or uploaded by the First Party / Owner, with the exception of Software or an Algorithm accessing the data for the sole purpose of automated Encryption to 128-bit level, or decryption from 128-bit, which does not copy, record, send or store any user-sent/received data at all, and which no other software or entity views, has access to, or monitors, records, sends, or retrieves in any way whatsoever
- "Encrypt" (also Encryption, Encrypted, Encrypting, etc) is defined as 128-bit automated, unmonitored software / algorithm encryption processed by a program without oversight or monitoring by any other software, algorithm, or entity,and which has no other function other than Encryption
- To Qualify for Inclusion in the Guild, Server owners must open up their server modules, processes and other relevant information to review by the Guild or one of its member affiliates for inspection, review, & certification. Server Owners must also provide sworn affidavits stating the integrity and security of the data, and how the data is used, who has access, how information is processed, transferred, encrypted, etc. and submit said Affidavits to the Guild before being removed from the Guild Security Blacklist.
-

I think we've already narrowed the list of qualifying software to less than what's available for Windows Phone
-

A qualifying app must also have the ability to retain full functionality after an Android OS reinstall.. meaning a portable install or an install which can use existing files found in File System Root/data/data without errors when reinstalling the app
No developer shall make any requests for donations or monetary compensation of any kind, who has included in his app any form of advertising or which has been given any permissions pertaining to user data & usage information
No App shall require specific permissions for advertisements or promotions.
No in-app advertisement shall require any special permissions or access whatsoever.
No advertisement or information gathering function shall piggyback on other functions requiring access or permissions, nor shall any advertisement or information gathering function utilize access or permissions granted to the app for its core, non-advertising, non-data collecting, non-marketing functions

Samsung KNOX 2.0 = NSA 3.0 ?

The Main Problem with KNOX
Is that end-users are left-out cold without any form of privacy control.
As cool as MDM is to the "enterprise" developer and from a hacker's
perspective, there's nothing attractive with this to the end-user. How
can the end-user be certain that his store-bought KNOX enabled device,
hasn't already been compromised by some "enterprise"?
Without fully transparent, open source and public KNOX documentation,
this will be practically impossible to answer. As far as we know from
recent past experiences, on how "curious" enterprises like Google,
Samsung and NSA have been, why should we trust them this time? Or what
about the mobile service providers themselves? We know from many recent
examples how companies like Verizon and AT&T have been spying on their
customers before.
What follows is a few enlightening excerpts from the latest KNOX
white-paper. Before reading this and having recent major KNOX related
developer issues, I have gone from a "KNOX-who-cares" person, to a vivid
Anti-KNOX-er! I will most likely stay that way, at least until our
devices are sold without KNOX, and only available as a voluntary device
add-on/feature, using open source as it's basis.
What about you? Would you be happy to walk around the streets with a
laptop that has a remote access tool that constantly tracks your every
move, picture, sound and friends you meet and call, all while not
informing of any of that? While being way beyond you control? In fact,
you will not even have any choice, if Godzilla and Samsung gets their
way, in the next year.
Attestation
Attestation offers verification of a mobile device's core system
software i.e, the boot loaders and the kernel, at runtime based on the
measurement data collected during trusted boot. Attestation can be
requested at any time by the enterprise's Mobile Device Management (MDM)
system. All security critical operations of attestation are performed in
Trustzone.
When requested, the Attestation feature reads the previously stored
measurement information and the fuse value (see Trusted Boot above) and
combines these data to produce an Attestation "verdict". This verdict,
which essentially an indicate for whether tampering has occured, is
simply returned to the requesting MDM. The Attestation result is
returned to the requesting MDM server with a signature based on the
device's unique "Attestation Certificate" that is configured in the
device during the manufacturing process. This ensures that the
Attestation verdict cannot be altered during transfer.
Any further action is determined by the enterprise's MDM security
policy. It might choose to detach from the device, erase the contents of
the secure application container, ask for the location of the device, or
any of many other possible security recovery procedures.
The KNOX Container
...
The enterprise can manage the container like any other IT asset using an
MDM solution. Samsung KNOX supports many of the leading MDM solutions on
the market. Container management is affected by setting policies in the
same fashion as those traditional MDM policies. Samsung KNOX Container
includes a rich set of policies for authentication, data security, VPN,
email, application blacklisting, whitelisting, etc.
...
The new container also allows enterprise IT administrators to control
the flow of information between the container and the rest of the
device. This allows enterprises to strike the right balance between
security and user productivity. Users can also control the data sharing
capability based on their personal preferences, within the limits
specified by the enterprise IT administrator.
Mobile Device Management (MDM)
Enrolling an Android device into a company’s MDM system typically begins
with the user downloading the agent application from the Google Play
store and then configuring it for work. Enterprises are facing
increasing help desk calls as more and more users are activating mobile
devices for work and run into issues during this process. In addition
the user is presented with prompts, privacy policies and license
agreements at various stages resulting in a poor overall experience.
The KNOX platform provides a unified enrollment solution that is simple
and intuitive, and eliminates many steps in the enrollment process.
The process begins with the employee navigating to a web page and
clicking on an enrollment link. The link to the original web page may be
provided to the employee via an e-mail or SMS, or via the company’s
internal or external website. Clicking on the enrollment link brings up
a screen that prompts for the user’s corporate email address. The device
then displays all notices for the user to accept, which include privacy
policies and agreements from Samsung, the MDM vendor and the enterprise.
Upon accepting the terms, the user is directed to a screen to enter the
password for the corporate account. If authentication is successful the
enrollment is complete. Any agent application required by the MDM server
is automatically downloaded and installed, without user intervention.
MDM vendors can take advantage of this feature and simplify the
onboarding process for enterprise users and significantly improve the
user experience and reduce support costs.
​In a nutshell, this is legalized control and spying.

I believe the quoted features have to be enabled by the company paying for the subscription (ie employer providing the devices), which is pretty standard MDM. If you are going to agree to use a MDM (as such an employee would have to) I see no issue here unless I am missing something.
I would be much more worried about abuse of the baseband, than MDM software which isn't enabled by default. Much more likely, and better target.
E:V:A said:
The Main Problem with KNOX
Is that end-users are left-out cold without any form of privacy control.
As cool as MDM is to the "enterprise" developer and from a hacker's
perspective, there's nothing attractive with this to the end-user. How
can the end-user be certain that his store-bought KNOX enabled device,
hasn't already been compromised by some "enterprise"?
Without fully transparent, open source and public KNOX documentation,
this will be practically impossible to answer. As far as we know from
recent past experiences, on how "curious" enterprises like Google,
Samsung and NSA have been, why should we trust them this time? Or what
about the mobile service providers themselves? We know from many recent
examples how companies like Verizon and AT&T have been spying on their
customers before.
What follows is a few enlightening excerpts from the latest KNOX
white-paper. Before reading this and having recent major KNOX related
developer issues, I have gone from a "KNOX-who-cares" person, to a vivid
Anti-KNOX-er! I will most likely stay that way, at least until our
devices are sold without KNOX, and only available as a voluntary device
add-on/feature, using open source as it's basis.
What about you? Would you be happy to walk around the streets with a
laptop that has a remote access tool that constantly tracks your every
move, picture, sound and friends you meet and call, all while not
informing of any of that? While being way beyond you control? In fact,
you will not even have any choice, if Godzilla and Samsung gets their
way, in the next year.
Attestation
Attestation offers verification of a mobile device's core system
software i.e, the boot loaders and the kernel, at runtime based on the
measurement data collected during trusted boot. Attestation can be
requested at any time by the enterprise's Mobile Device Management (MDM)
system. All security critical operations of attestation are performed in
Trustzone.
When requested, the Attestation feature reads the previously stored
measurement information and the fuse value (see Trusted Boot above) and
combines these data to produce an Attestation "verdict". This verdict,
which essentially an indicate for whether tampering has occured, is
simply returned to the requesting MDM. The Attestation result is
returned to the requesting MDM server with a signature based on the
device's unique "Attestation Certificate" that is configured in the
device during the manufacturing process. This ensures that the
Attestation verdict cannot be altered during transfer.
Any further action is determined by the enterprise's MDM security
policy. It might choose to detach from the device, erase the contents of
the secure application container, ask for the location of the device, or
any of many other possible security recovery procedures.
The KNOX Container
...
The enterprise can manage the container like any other IT asset using an
MDM solution. Samsung KNOX supports many of the leading MDM solutions on
the market. Container management is affected by setting policies in the
same fashion as those traditional MDM policies. Samsung KNOX Container
includes a rich set of policies for authentication, data security, VPN,
email, application blacklisting, whitelisting, etc.
...
The new container also allows enterprise IT administrators to control
the flow of information between the container and the rest of the
device. This allows enterprises to strike the right balance between
security and user productivity. Users can also control the data sharing
capability based on their personal preferences, within the limits
specified by the enterprise IT administrator.
Mobile Device Management (MDM)
Enrolling an Android device into a company’s MDM system typically begins
with the user downloading the agent application from the Google Play
store and then configuring it for work. Enterprises are facing
increasing help desk calls as more and more users are activating mobile
devices for work and run into issues during this process. In addition
the user is presented with prompts, privacy policies and license
agreements at various stages resulting in a poor overall experience.
The KNOX platform provides a unified enrollment solution that is simple
and intuitive, and eliminates many steps in the enrollment process.
The process begins with the employee navigating to a web page and
clicking on an enrollment link. The link to the original web page may be
provided to the employee via an e-mail or SMS, or via the company’s
internal or external website. Clicking on the enrollment link brings up
a screen that prompts for the user’s corporate email address. The device
then displays all notices for the user to accept, which include privacy
policies and agreements from Samsung, the MDM vendor and the enterprise.
Upon accepting the terms, the user is directed to a screen to enter the
password for the corporate account. If authentication is successful the
enrollment is complete. Any agent application required by the MDM server
is automatically downloaded and installed, without user intervention.
MDM vendors can take advantage of this feature and simplify the
onboarding process for enterprise users and significantly improve the
user experience and reduce support costs.
​In a nutshell, this is legalized control and spying.
Click to expand...
Click to collapse

jcase said:
I believe the quoted features have to be enabled by the company paying for the subscription (ie employer providing the devices), which is pretty standard MDM. If you are going to agree to use a MDM (as such an employee would have to) I see no issue here unless I am missing something.
I would be much more worried about abuse of the baseband, than MDM software which isn't enabled by default. Much more likely, and better target.
Click to expand...
Click to collapse
I don't know to what extent you're playing devils advocate, but I am still a bit surprised, you can't see any issues with this.
The issue is, that we're not able to see how this enabling mechanism work, and therefore cannot even make any half-baked guess if this is actually secure, or can be easily broken, abused or circumvented, if not so, already. In addition the MDM software is enabled by default, at least as far as my processes and device drivers present, shows. It's just not visibly activated, until you go through the signup procedures. Furthermore it seem that the MDM features are very well weaved into the baseband functionality. Not that baseband is using MDMD, but that MDM makes extensive use of the baseband and features not documented. But to what extent that is true, I can 't really say at this time, as I have not spent any time on it.
One more thing. They say that KNOX is a security "addition" to the default SELinux policies, but that is not the whole story. Actually it seem more that KNOX is replacing or overriding the SEL policies already present. How can we actually test and see this, when we're not even allowed (or given) the tools to do so?

E:V:A said:
I don't know to what extent you're playing devils advocate, but I am still a bit surprised, you can't see any issues with this.
The issue is, that we're not able to see how this enabling mechanism work, and therefore cannot even make any half-baked guess if this is actually secure, or can be easily broken, abused or circumvented, if not so, already. In addition the MDM software is enabled by default, at least as far as my processes and device drivers present, shows. It's just not visibly activated, until you go through the signup procedures. Furthermore it seem that the MDM features are very well weaved into the baseband functionality. Not that baseband is using MDMD, but that MDM makes extensive use of the baseband and features not documented. But to what extent that is true, I can 't really say at this time, as I have not spent any time on it.
One more thing. They say that KNOX is a security "addition" to the default SELinux policies, but that is not the whole story. Actually it seem more that KNOX is replacing or overriding the SEL policies already present. How can we actually test and see this, when we're not even allowed (or given) the tools to do so?
Click to expand...
Click to collapse
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.

puzzled
I don't get it - I thought "knox" was just that thing that counts how many times you've flashed a custom rom (which can easily be removed and reset).
b

jcase said:
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
Click to expand...
Click to collapse
We are not able to see how any closed source security component works, and you investigate it the same way you investigate any closed source feature.

jcase said:
I'm not playing devils advocate, I'm saying that I don't think this is the route the NSA would take.
Click to expand...
Click to collapse
I think it's pointless to speculate in which route they would take, as they would certainly take whatever route available to accomplish their mission. Together with Google own INSTALL ASSET methods, MDM makes that even more simple on Samsungs.
I'm sure we'll see more posts like this in the near future.
FYI - How the NSA can 'turn on' your phone

E:V:A said:
I think it's pointless to speculate in which route they would take, as they would certainly take whatever route available to accomplish their mission. Together with Google own INSTALL ASSET methods, MDM makes that even more simple on Samsungs.
I'm sure we'll see more posts like this in the near future.
FYI - How the NSA can 'turn on' your phone
Click to expand...
Click to collapse
I'll make sure to remove such paranoia posts in the future, one is enough. I think a baseband attack is more likely, as it is more likely to impact more phones, from more OEMs, running more firmwares etc. The baseband is much harder to investigate as well, less people looking at it, more potential for bugs living longer, easier not to get noticed.

jcase said:
I'll make sure to remove such paranoia post in the future, one is enough. I think a baseband attack is more likely, as it is more likely to impact more phones, from more OEMs, running more firmwares etc. The baseband is much harder to investigate as well, less people looking at it, more potential for bugs living longer, easier not to get noticed.
Click to expand...
Click to collapse
Well, I'm not sure that post fulfill all the criteria of "paranoia", especially since it is mostly grounded in truth, apart from the CNN journalism. But my point is already there. When people have no insight or control over what's happening in their pockets, they start getting religiously paranoid. I guess from an anthropological point of view, paranoia has some kind of good survival function for the group. So it serves well as a counter balance to being completely ignorant.

E:V:A said:
Well, I'm not sure that post fulfill all the criteria of "paranoia", especially since it is mostly grounded in truth, apart from the CNN journalism. But my point is already there. When people have no insight or control over what's happening in their pockets, they start getting religiously paranoid. I guess from an anthropological point of view, paranoia has some kind of good survival function for the group. So it serves well as a counter balance to being completely ignorant.
Click to expand...
Click to collapse
It has been removed from the security forum, it is a copy paste of an article reportedly from cnn (no source link to back that), without any citations to the claims made. I will make a better effort to keep the forum accurate, and fud free in the future.
It has factual inaccuracies, and seems to be just a promo piece for a custom Android ROM that indeed has it's own issues.

@E:V:A
I do appreciate your posts, they are welcome here, but some of the posts ive been removing are just FUD, way out there or unsourced.

when I got my phone rooted and opened supersu, it suggested to disable KNOX. Before then, I didn't even know what KNOX is. I searched some information about it, looks like it is just security solution.

explanation
yueyejinghun said:
when I got my phone rooted and opened supersu, it suggested to disable KNOX. Before then, I didn't even know what KNOX is. I searched some information about it, looks like it is just security solution.
Click to expand...
Click to collapse
It's just a feature that counts how many times you've flashed a custom rom to your phone; easily removed and reset.

FIRST Read the OP and then the KNOX whitepaper.
and maybe someone will open this thread again...or remove it.

Privacy with Play Services

Hello all! I'm sure most of you are familiar with Google Play Services, the base of Google's Android framework and the brains behind all the Google things you do on your phone. Less of you, however, might also know that Play Services is notorious for being a beast of an application that no one truly knows the function of.
Below here is a rough explanation of Play Services from what I know about it. You can skip this if you already know and move on to the bread and butter of this post.
Play Services is proprietary software, meaning that its source code is not available to the public. All of Google's apps are proprietary like this as well. While developers like Chainfire have legitimate reasons to close off their app source code so others don't steal it, and so does Google, it is extra worrying from a company that makes a profit off of collecting userdata. Many people, including me, do not trust Google with our data, so we try to avoid their products as much as possible.
I thought that it would be nice to create a megathread of sorts with various users' suggestions on how to subvert the constant surveillance of Play Services, while also attempting to maintain the useful functionality of it. Below are some of the primary methods that I have thought of, and that I and some others have tried:
LineageOS/CyanogenMod Privacy Guard - If you are using LineageOS or any derivative thereof, you can go to Privacy Guard and deny certain permissions from Play Services. I and another user have denied permissions from Play Services without side effects, but your mileage may vary. @javelinanddart said on Reddit that Privacy Guard does indeed block permissions from Play Services and other system apps, so rest assured that Privacy Guard actually does something rather than being a placebo.
XPrivacyLua - This is an Xposed module that feeds false data to apps rather than blocking it entirely. I haven't tried this method myself, but the XDA post I linked above reports that XPrivacyLua works, even in tandem with Privacy Guard.
microG - microG is an open-source alternative to Play Services. It emulates many key functions of Play Services - push notifications, location services, etc - without the data collection running alongside such functionality. To clarify, this is a full replacement for Play Services, so you would flash a microG package instead of a GApps package. There are lots of bugs, though, even admitted by the developer. If you want to learn more, I suggest you visit the XDA thread for it, or view the implementation progress for various pieces of functionality.
There is nothing else that I know of, so if anybody knows of another viable method or can provide their own experiences with the above ones, your contributions would be appreciated by me and the rest of the privacy community.

Thanks for thread.
My only reason to use custom ROM is because they are GApps-free. In nearly every other aspect stock ROMs are better. Phones without good custom ROM I simply setup without Google account and install f-droid and yalp stores.
Another idea:
Imagine: Google is not as evil as we think: there are many privacy related settings in your Google account. You can login with a web browser and try through all these settings - and hope.

Device is a Samsung i9305 with RR-N-v5.8.5-final, Magisk v16.0, XPosed, XPrivacyLua, microG (via NanoDroid). No genuine Google services; Google Play Store is the one and only Google application installed.
I hope it suits into this thread (thanks very much for creating it!), and I'd like to share my settings. Please refer to the screenshots; I think it's self-explaining where they where taken from.
Actually no restrictions to microG, only to Play Store.
Remarks: µG has no restrictions in the firewall (AFWall+ Donation Beta); Play Store only granted internet access via WiFi and VPN. Just for completeness; running a RaspberryPi in the home network with Pi-Hole installed and acting as the DNS-server in the network. Unless using the home network i.e. using a foreign WiFi network or mobile data, ALWAYS establishing my own secure VPN to my RaspberryPi (with PiVPN installed) via OpenVPN and again the Pi acting as the DNS-server. If interested in further details please refer to this thread.

Thanks for this.
I was considering asking for a forum section here devoted to privacy, but it doesn't seem like a popular subject here. (After all, most of the people who have already picked the most snoopery OS in the world could be assumed to be not particularly worried about privacy. ? )
I come from a different motivation: the hope that by using a somewhat hackable OS, one can theoretically modify it in ways to achieve one's objectives, including privacy. But the last few years have made it rather clear that the Big G is working determinedly to foil such efforts.
Lately that seems to take the form of pushing more and more essential services into the Gplay frameworks, and deprecating perfectly working things like GCM in favor of intertwining it with Firebase, which may saddle us with that analytics data vacuum in order to get another essential service, push notifications.
Re: revoking permissions from Gplay frameworks, I feel like Google's determination to get their hands on data by hook or by crook (eg their ignoring of user preferences to disable various radios and enabling them in the background anyway, to track location and such) means they will quite possibly circumvent these preferences at some point as well.
As I mentioned in another thread I've experienced various problems in the past when I tried to aggressively restrict perms on the Gplay services using CM/LOS Privacy Guard, but perhaps some of that came from choosing interactive restriction prompts rather than blanket revoking. I do know that so many essential services are tied-into the Gplay frameworks these days that blocking tons of perms will inevitably cause breakage of some things depending how you use your device.

Jrhotrod said:
...
There is nothing else that I know of, so if anybody knows of another viable method or can provide their own experiences with the above ones, your contributions would be appreciated by me and the rest of the privacy community.
Click to expand...
Click to collapse
Due to your request above, please allow me to draw your attention to two threads by me. In these threads I tried about one and a half year ago to initially capture but also to update how I believe to have enhanced the battery duration, privacy and security of my GT-i9305 and how I went for a GApps-free device with microG.
Over the time until today, some of the described implementations, applications and measures became absolete or were replaced by others (e.g. using NanoDroid - or Nanomod as it was called in the beginning, since it has come out). Some changes occured due to the step from Marshmellow to Nougat or the non-availabilty of the official Xposed framework for Nougat in the very beginning. However, over all the time I've tried to maintain both threads updated and amended but currently not to much occuring on that frontline, probably because I've received a privacy status on our devices that obviously satisfies me in my personal opinion.

Oswald Boelcke said:
Due to your request above, please allow me to draw your attention to two threads by me. In these threads I tried about one and a half year ago to initially capture but also to update how I believe to have enhanced the battery duration, privacy and security of my GT-i9305 and how I went for a GApps-free device with microG.
Over the time until today, some of the described implementations, applications and measures became absolete or were replaced by others (e.g. using NanoDroid - or Nanomod as it was called in the beginning, since it has come out). Some changes occured due to the step from Marshmellow to Nougat or the non-availabilty of the official Xposed framework for Nougat in the very beginning. However, over all the time I've tried to maintain both threads updated and amended but currently not to much occuring on that frontline, probably because I've received a privacy status on our devices that obviously satisfies me in my personal opinion.
Click to expand...
Click to collapse
Wow, this is really great! Very high-quality thread.
Will add to OP later today

I apologise for the double post (original in my thread here) but I guess it also suits in this thread.
Found the below quoted post by @jawz101 in the XPrivacyLua thread here. Pretty interesting, and therefore I like to share:
Looking around on Data Transparency Lab website http://datatransparencylab.org/ - they fund grants for research in privacy stuff.
...I found an app called AntMonitor, an academic research project that does a MITM SSL cert + local VPN to look at sensitive traffic - even that which is encrypted. https://play.google.com/store/apps/d...it2.anteatermo
Anyways, it shows some apps trying to send my gps coordinates even though it doesn't have Android permission. Like, my coordinates are actually attempting to be sent encrypted to a destination. XPrivacyLUA doesn't trigger so I can only assume they grab my coordinates in a way that circumvents the traditional Android permission model.
To test, just try the app and open a few apps. I think it's apps with the Facebook graph API that is maybe doing it.
If you like ANTMonitor another app that does an SSL cert+ VPN is Lumen Privacy Monitor- a project by Berkely, but it doesn't seem to detect raw coordinates like ANTMonitor does.
Click to expand...
Click to collapse
However, I suggest to also follow the discussion/conversation between jawz101 and M66B, which has developed after this post.

Oswald Boelcke said:
Found the below quoted post by @jawz101 in the XPrivacyLua thread here. Pretty interesting, and therefore I like to share:
However, I suggest to also follow the discussion/conversation between jawz101 and M66B, which has developed after this post.
Click to expand...
Click to collapse
This is certainly an important discovery, thanks for the news.
Now for the sidenote that's 10x longer than the main comment. ?
One of the key issues I have with the various "privacy tools" is trying to figure out whether or not I trust all these entities that produce these diagnostic things to not be a solution worse than the problem when it comes to possessing and safeguarding my sensitive personal data.
It's getting to the point where I'm no longer enamored of giving *anyone* access to such stuff if I can help it, no matter *who* they are.
Even if they're not lying about their intentions and their commitment to security/privacy, there are still matters like carelessness/incompetence and targeted attacks to worry about.

@Exabyter: You're statement and expressed concerns are abolutely correct. Nothing to add except that I wouldn't limit it to "privacy tools" but especially include all applications that require root (and get it granted by the user) or all Magisk and Xposed modules. The latter should definitely concern.
My personal decision:
I'm not willing to trust anybody from the very beginning but I'm willing to trust single persons, groups or agencies. I've developed my own, private criteria, to which I stick but I've also admit the final decision isn't always based on rationality but also a lot on my feeling (in my stomage).
I don't held any confidential data on my device but privacy related ones, and I don't use my device for any kind of banking, shopping or payments.
I consider to use tools, modules and applications if their functionality rests within my defined specifications for the use of my device. Then I go for "the shopping tour" while I try to look into the details of the tools under closer examination, which includes where is it from, who's the developer etc.
I'll continue with the measures already described in one of my threads.

Oswald - I think we have largely similar stances on such things. In my case I will sometimes sway towards the pragmatic over the pedantic when the pedantic involves so many inconveniences that the tech becomes more of a burden than a help to me.
For example, I really don't like the idea of 3rd-parties keeping data pertaining to my daily geographic movements, but I also use several tools and services that by their nature rely on location data which could in some cases end up in the hands of parties I'd rather didn't have access to it. So I have to regularly weigh the apparent cost/benefit of such services and there are certainly some of them which have a high enough value to me that I willingly lower my default "protection level" in order to keep the other benefits of such tools/services.
Certainly microG is an important tool in that toolchest as it has a major disruptive impact on some of the most common ways Google and other parties snoop on users. But some of its imperfections also threaten to keep me from my ultimate goal of carrying a single phone which performs all the tasks I need to accomplish with it without undermining my privacy in a major way. (And ultimately, my freedom and agency as a citizen in a nominally and allegedly "free and democratic society", which is the actual "big picture" problem with privacy incursions in general IMHO)
I have spent several years now, with varying degrees of effort and success, trying to come up with a hardware/software solution to this problem, and I've never reached a point where I'm fully satisfied with the results. The fact that I am still carrying several mobile devices with me everyday is proof enough that I haven't achieved my objective in this regard and it gets tiring. As does all the time spent on venues such as XDA, researching, discussing and keeping-up with all the relevant issues, not to mention the large amount of time spent tinkering with HW/SW in order to keep all the special measures working. (And after we finally get things working more or less the way we want, we are faced with the particularly customized hardware wearing out, becoming unsupported, 3rd-party ROM and other compatible and necessary software being abandoned/deprecated, and so on and so forth.)
Truth to tell I'm a bit bitter about the amount of time/energy I have to spend to achieve something which should have been part of the mobile platforms in the first place. The current de-facto mobile platform duopoly certainly doesn't help matters.
---------- Post added at 03:39 PM ---------- Previous post was at 02:57 PM ----------
Now that I've gotten that philosophical rant out of the way ? ...
So as far as technical specifics:
microG of course is a big help as it either neuters or removes many troublesome anti-privacy vectors. For example, at the present time it does not support Firebase Analytics at all, which means (as far as I can tell) any app that expects to get telemetry on users via Firebase Analytics will not get anything if the app user's device is Gapps-free and using microG instead. (It remains to be seen if adding Firebase Cloud Messaging capability to microG will negate this presumed benefit. Cynics like myself are inclined to think one of Google's key objectives in deprecating Google Cloud Messaging and rolling push notification frameworks into Firebase instead was specifically to undermine the ability of users to avoid/circumvent Firebase Analytics)
XprivacyLUA looks interesting and is on my list to test. I found its predecessor Xprivacy to be an extremely tedious and labor-intensive option so I never seriously pursued it after my initial testing.
There are various tools I find handy to help get a sense of how dangerous certain apps may be to privacy. Here are a few:
AppBrain Ad Detector
https://play.google.com/store/apps/details?id=com.appspot.swisscodemonkeys.detector
Addons Detector
https://play.google.com/store/apps/details?id=com.denper.addonsdetector
Checkey (also on f-droid)
https://play.google.com/store/apps/details?id=info.guardianproject.checkey
Applications Info (also on f-droid)
https://play.google.com/store/apps/details?id=com.majeur.applicationsinfo
Permission Friendly Apps
https://play.google.com/store/apps/details?id=org.androidsoft.app.permission

[App][7.0+][Early Access] Truvark - modern file encryption

Truvark is a modern file encryption app for Android. You might be wondering why building another vault app as there are already a lot of options. The difference is that Truvark is built around security by design and privacy by default. To proof that I take that serious, this is an offline app, it does not have/requests Android's Internet permission. Features like cloud synchronization are not compatible with the mentioned paradigms. However, that does not mean that you cannot sync or backup your data through a third-party app (on your own risk). Read more about (unique) features below.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Features​Multiple vaults​You can create multiple vaults on your device. Any empty folder can become a vault. All your data remains on the shared device storage, means you can access the encrypted files from a file manager e.g. for backups.
This is a major difference to alternatives. Some apps don't even encrypt your files, they just move them to the app's internal storage. These often speak about "hiding data" instead of encrypting. Others using encryption still prohibit access. You fully rely on their export feature.
Deep folder structures​Truvark is not an encrypted gallery that just lets you group your pictures into albums. It is a file encryption app providing full support for creating folders inside folders. You are not limited in organizing your files.
View encrypted files​The aim is to be able to view common file types in the app. Currently supported are images, videos and audio. The decryption takes place "on the fly" means the required data is decrypted in memory while needed. This is especially important for long videos that would not fit into memory. The image viewer supports high-res pictures and shows more details when zooming in instead of becoming pixelated.
Here are more differences to alternatives to spot. While I analyzed a wide range of vault apps from multimillion downloads to open source ones I found many flaws. Apps decrypting the full file to disk before showing it, scarify performance and possibly put that file on a risk. Others don't encrypt thumbnails, just the original files.
Privacy by default​To make it short this app has no Internet permission. There are no analytics, ads, telemetry or requirements for an account. However, there is an option for logging that is turned off by default. Logging is required to be able to help any user that has an issue with my app. The user needs to provide these logs, they are not automatically sent (what is technically impossible because of the missing Internet permission).
Security by design​Truvark is using a component (library) for encryption that is built by Google engineers and used in Google Pay. It's called Tink and has the following promise:
A multi-language, cross-platform library that provides cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse.
Click to expand...
Click to collapse
The last part is important. In cryptography it is enough to get a single parameter wrong to make an encryption insecure. Therefor I decided to rely on a popular open source library.
Additionally, Argon2(id) is used for key derivation. It won the Password Hashing Competition back in 2015 and is one of the best (if not the best) algorithm for that task out there.
The cryptographic core of Truvark (the combination of both libraries) is open source and available on GitHub.
The database is a Realm database. Realm can feature encrypted databases and of course that is in use. I have seen a lot of vault apps without encrypted database during my analysis.
Furthermore, Truvark supports biometric (e.g. fingerprint) authentication for unlocking a single vault. That feature is backed by the Android Keystore and might not be available on devices even though they offer biometric authentication because a strong authentication is required that not every device supports.
Partly open source, fully in future​As mentioned above the cryptographic core is already open source and available on GitHub. You can see that this is not my first open source project. Because I'm committed to open source, I plan to publish the full source code sometime in future. The idea is to do that when the app leaves early access but all in all I will do that when I think it's ready.
About development​On the one hand I want to let you know that I'm a professional software developer and not coding as hobby only, on the other hand I have to put a disclaimer here that I'm not a cryptography expert. However this app was carefully build over time and not in a hastle. Although this app is in early access, it is not a prototype or minimal valuable product. Every release is going trough automated and manual tests. For the manual tests I'm using multiple devices. Nevertheless I'm not afraid to say that bugs can happen. I personally lost data using alternatives in the past, so I am very aware of that issue. Therefor this app stores many information redundant. For example in near future a corrupted or deleted database can be almost fully restored (only some information about the folder structure will be lost but you don't need to organize all files again). The app is already designed to support featues like this in future. Furthermore to backup your encrypted files all you need to do is copy the vault folder.
Upcoming features​
Move files and folders to different folders
Rename folders
Rename vault
Material3, followed by many UI and UX improvements
Performance improvements
Future plans​
Support more file types (like text and PDF)
Fully open source
Provide desktop clients (cross platform)
Download​Download from Google Play

Changelog:
0.4.0:
Target Android 13
Handle new notification permission (first and only required permission)
Support themed icons (Android 13)
Update dependencies
0.3.2:
Replace prebuild Argon2 (used for password derivation) with own build from official source
Update various dependencies (including improvements to the in-app file presenter)
0.3.1:
Fix a bug during biometric setup

Thanks for this, I noticed in recents I did not have to relog in to open, pixel as far as I understand doesn't close recents and clearing them also doesn't actually end the process losing a security risk. Great app though!

7h3DuD3 said:
Thanks for this, I noticed in recents I did not have to relog in to open, pixel as far as I understand doesn't close recents and clearing them also doesn't actually end the process losing a security risk. Great app though!
Click to expand...
Click to collapse
Hi,
many thanks for giving Truvark a try and for providing feedback. Indeed there is no mechanism automatically closing a vault or the app itself. Actually I spend a bunch of hours on this feature already and haven't found a solution yet that significantly improves security while keeping encryption/decryption/etc reliable.
You might have noticed that this app makes heavy use of background scheduling. Other apps show a dialog forcing you to wait while they encrypt one file after another, where Truvark runs encryption parallel in background and you still can view your already encrypted files. This is one of the reasons why the feature you mentioned is not available yet, closing a vault would cancel background operations that cannot be automatically started again when the vault is opened next time, because of storage permissions.
Truvark is completely build on Android's "new" storage design (that Google enforced in Android 10/11) by using the storage access framework (SAF).
Therefor I cannot grantee that automatically closing a vault will ever be available, however likely there will be at least a button to close a vault inside the app or maybe a login screen to prevent access to the UI while still having that vault open in background. Actually I’m planning bigger changes on how the vaults are opened with the goal to make it possible having multiple vaults open at the same time. During that process I will reevaluate if it is easier to implement that feature.

@7h3DuD3 did my post answered your questions or are you looking for different information? Happy to answer any question or feedback.
May I ask you in case you regularly use a vault/encryption app what app you're using? What you like about it and what could be improved in your opinion?
Furthermore, I might be able to give insights about the security and privacy of alternative apps if they were part of my analysis. Hoping to analyze more vault apps soon, possibly on request.

Actually don't use one ever for more than a few days, however I've been using this for a bit and find it adequate. Perhaps a triggered deletion of the vault, say recieve an email or text, but I'm fairly certain tasker could do that or multiple other apps not to mention the security risk of having something like that poses a security risk in itself. But overall I'd say it's better then what I've used in the past and files I carry on my personal thumbdrive are vaulted which feels better knowing should I lose it my personal information won't just be in a .hiddenpasswords.txt file lol that's been the main thing is bs where they hide the file like no one's gonna see that or rename the extension with no encryption. I haven't tried a brute force, might be kinda fun to do. Suggestion, Better variety of file types *

7h3DuD3 said:
I haven't tried a brute force, might be kinda fun to do.
Click to expand...
Click to collapse
Starting with your last sentence, I wish you good luck with that. Of course it depends on your password. Assuming you picked a good password (Truvark requires 8 character at the moment) brute force is by far the worst attack you could try. For hashing Argon2id is used with a configuration above the minimal recommendations by OWASP and for encryption Google's Tink library is used that "has been deployed in hundreds of products and systems" (quote from their readme file) including Google Pay.
I think you should try attacking the implementation instead of globaly used algorithms.
7h3DuD3 said:
Actually don't use one ever for more than a few days, however I've been using this for a bit and find it adequate. Perhaps a triggered deletion of the vault, say recieve an email or text, but I'm fairly certain tasker could do that or multiple other apps not to mention the security risk of having something like that poses a security risk in itself. But overall I'd say it's better then what I've used in the past and files I carry on my personal thumbdrive are vaulted which feels better knowing should I lose it my personal information won't just be in a .hiddenpasswords.txt file lol that's been the main thing is bs where they hide the file like no one's gonna see that or rename the extension with no encryption. I haven't tried a brute force, might be kinda fun to do. Suggestion, Better variety of file types *
Click to expand...
Click to collapse
Thanks that you overall seem to like my app. I don't plan to implement a remote deletion because I believe that strong cryptography does not need that. If you really want to build that yourself in a first step you could just delete the file with the name "vault". It contains a so called salt and the encrypted database key, without the file the attack surface is reduced (and you lose access to your files even with correct password btw).
Because you mentioned a thumb drive, that is one of the benefits of the new storage APIs. Truvark fully supports sdcards and external USB devices without workarounds or the need to move data manually from time to time. I have seen lots of vault apps with bad sdcard support.
What file support are you looking for? I plan GIFs, basic text files and PDFs next.

0.3.2:
Replace prebuild Argon2 (used for password derivation) with own build from official source
Update various dependencies (including improvements to the in-app file presenter)
Development is currently a little slow or let's say less visible to users because of many under the hood changes. Furthermore, I'm waiting for improvements/new features in some dependencies. Next will be various improvements to the database. After that I plan to work on Material3 design.

0.4.0:
Target Android 13
Handle new notification permission (first and only required permission)
Support themed icons (Android 13)
Update dependencies
Was quiet in the last months, also because I had little time, the development will progress much faster in the next weeks. I am still working on the replacement of the database implementation. Afterwards it goes on with the Material3 redesign that will come with many new features.

0.5.0:
Fix lags affecting the in-app file viewer
Loop video/audio playback
Update various dependencies
Drop a dependency in favor of official implementation
Obviously, my plans (see above) didn't work out. Unfortunately I'm still waiting for a final feature for database migration, which is finally in development upstream. So here is another small update.
I commit to continue improving this app and bring it out of early access status, as well as go fully open source in future.