replace obsolete AOSP applications

[thestinger]

The replacements need to be well-maintained open-source projects. They should also have minimal dependencies and sane build systems so they can be integrated into the source tree without a hassle. Chromium is a special case.

• #108 Browser (replaced with Chromium)
• Calendar
• QuickSearchBox (removed, yet to be replaced)
• Music

[Bmme2GFTbU]

Maybe Chromium (as a replacement) could be replaced by Firefox (with duckduckgo). Firefox is also available in F-Droid and could be easily updated. I get Popups of winning-announcements with Chromium, which uses vibrations. This seems to be weird and not really secure.
Also VLC could replace the Music-App and had a Video-Player integrated. So two apps in one and again available over F-Droid.
At last K9-Mail could replace the E-Mail-App. It is F-Droid-compatible, well maintained and can be used with APG.

[Bmme2GFTbU]

Maybe Chromium (as a replacement) could be replaced by Firefox (with duckduckgo). Firefox is also available in F-Droid and could be easily updated. I get Popups of winning-announcements with Chromium, which uses vibrations. This seems to be weird and not really secure.
Also VLC could replace the Music-App and had a Video-Player integrated. So two apps in one and again available over F-Droid.
At last K9-Mail could replace the E-Mail-App. It is F-Droid-compatible, well maintained and can be used with APG.

[Bmme2GFTbU]

And to get back to the start-topic: The DuckDuckGo Search Widget could be a good replacement for the quicksearchbox.

[Bmme2GFTbU]

And to get back to the start-topic: The DuckDuckGo Search Widget could be a good replacement for the quicksearchbox.

[thestinger]

K-9 mail seems like a good option for replacing the Email app. VLC is a great video player but it's not necessarily a great choice from a security perspective. It supports a huge number of codecs which is another of way of saying that it has ridiculous amounts of attack surface. It also has issues like requiring text relocations so it requires an exception from the PaX MPROTECT mitigation. It's unclear what should be done about that. Requires a lot of thought and research.

The built-in apps will be built as part of the OS and signed with the OS key so the standard F-Droid repository packages won't work as updates. The eventual goal will be to have our own F-Droid repository with the apps from the standard F-Droid repository built with the additional compiler and C library hardening features. It can also drop all of the zombie packages that are kept in the standard F-Droid repository.

Firefox is too far behind Chromium on the security front to be the default browser. It doesn't have a sandbox at all and is far less hardened. Chromium lacks support for extensions on Android which is a major flaw but it's acceptable while Firefox's security situation is not.

Note that the build of Chromium is an arbitrary last known good revision right now rather than stable because being able to build the full browser on Android with no hard dependencies on Google Play is a very new development. So it has some weird issues because it's the development branch but it can be switched over to a stable build soon.

And to get back to the start-topic: The DuckDuckGo Search Widget could be a good replacement for the quicksearchbox.

That makes sense. It's better to offer only DuckDuckGo than only Google, but the ideal would be a flexible search applications with good support for multiple search engines. It probably doesn't exist though.

[thestinger]

K-9 mail seems like a good option for replacing the Email app. VLC is a great video player but it's not necessarily a great choice from a security perspective. It supports a huge number of codecs which is another of way of saying that it has ridiculous amounts of attack surface. It also has issues like requiring text relocations so it requires an exception from the PaX MPROTECT mitigation. It's unclear what should be done about that. Requires a lot of thought and research.

The built-in apps will be built as part of the OS and signed with the OS key so the standard F-Droid repository packages won't work as updates. The eventual goal will be to have our own F-Droid repository with the apps from the standard F-Droid repository built with the additional compiler and C library hardening features. It can also drop all of the zombie packages that are kept in the standard F-Droid repository.

Firefox is too far behind Chromium on the security front to be the default browser. It doesn't have a sandbox at all and is far less hardened. Chromium lacks support for extensions on Android which is a major flaw but it's acceptable while Firefox's security situation is not.

Note that the build of Chromium is an arbitrary last known good revision right now rather than stable because being able to build the full browser on Android with no hard dependencies on Google Play is a very new development. So it has some weird issues because it's the development branch but it can be switched over to a stable build soon.

And to get back to the start-topic: The DuckDuckGo Search Widget could be a good replacement for the quicksearchbox.

That makes sense. It's better to offer only DuckDuckGo than only Google, but the ideal would be a flexible search applications with good support for multiple search engines. It probably doesn't exist though.

[thestinger]

The base OS also has to have Chromium for the WebView, so sticking to Chromium or a Chromium-based browser as the main browser avoids introducing extra attack surface. No need to give the attacker a choice between 2 browser implementations when one will do just fine.

[thestinger]

The base OS also has to have Chromium for the WebView, so sticking to Chromium or a Chromium-based browser as the main browser avoids introducing extra attack surface. No need to give the attacker a choice between 2 browser implementations when one will do just fine.

[Bmme2GFTbU]

I see why Firefox is not a good idea. And I think an own F-Droid Repo is a good solution. I'll keep an eye on an alternative to VLC

With the DuckDuckGo SearchBar it is possible to search through amazon, bing, google maps, youtube, wikipedia, ebay, etc. To do that you have to add "!" and the related letter to your search. This is maybe not the best usability but it offers a huge amount of different search plattforms (except Google itself). Maybe it is possible to add startpage or ixquick to get googles results. I'll try that.

Furthermore I would appreciate DAVDroid for CalDAV and CardDAV synchronization.

[Bmme2GFTbU]

I see why Firefox is not a good idea. And I think an own F-Droid Repo is a good solution. I'll keep an eye on an alternative to VLC

With the DuckDuckGo SearchBar it is possible to search through amazon, bing, google maps, youtube, wikipedia, ebay, etc. To do that you have to add "!" and the related letter to your search. This is maybe not the best usability but it offers a huge amount of different search plattforms (except Google itself). Maybe it is possible to add startpage or ixquick to get googles results. I'll try that.

Furthermore I would appreciate DAVDroid for CalDAV and CardDAV synchronization.

[Bmme2GFTbU]

Do you plan to replace the SMS-App ?

If so, maybe SMSSecure is worth a look. (http://smssecure.org/) Its a fork from Signal/TextSecure from earlier this year, but got the original encrypted SMS-feature build-in. (https://github.com/SMSSecure/SMSSecure)

And maybe Signal as the equivalent for IM as a replacement for Google Talk (i know, it is not a AOSP app).

[Bmme2GFTbU]

Do you plan to replace the SMS-App ?

If so, maybe SMSSecure is worth a look. (http://smssecure.org/) Its a fork from Signal/TextSecure from earlier this year, but got the original encrypted SMS-feature build-in. (https://github.com/SMSSecure/SMSSecure)

And maybe Signal as the equivalent for IM as a replacement for Google Talk (i know, it is not a AOSP app).

[thestinger]

Yeah, SMSSecure was actually bundled before. Planning on building everything rather than simply bundling the existing F-Droid packages this time though. I don't want to place trust in another party even though I love the work they do. Makes more sense to build everything.

[thestinger]

Yeah, SMSSecure was actually bundled before. Planning on building everything rather than simply bundling the existing F-Droid packages this time though. I don't want to place trust in another party even though I love the work they do. Makes more sense to build everything.

[Bmme2GFTbU]

What do you think about a Service/App like Wifi-Matic to avoid connecting to fake-aps? And do you see a possibility to add swype?

[Bmme2GFTbU]

What do you think about a Service/App like Wifi-Matic to avoid connecting to fake-aps? And do you see a possibility to add swype?

[polyzen]

Haven't tried Wifi-Matic; sounds like it works like Privacy Police (which I think was suggested for inclusion before). Privacy Police currently doesn't work properly on Marshmellow.

[polyzen]

Haven't tried Wifi-Matic; sounds like it works like Privacy Police (which I think was suggested for inclusion before). Privacy Police currently doesn't work properly on Marshmellow.

[Bmme2GFTbU]

I'll switched to Copperhead as my first phone yesterday, I'll give Wifi-Matic a try and get back with informations

[Bmme2GFTbU]

I'll switched to Copperhead as my first phone yesterday, I'll give Wifi-Matic a try and get back with informations

[polyzen]

Not sure if a file manager is on the list, but just found Amaze today. The repo appears active, though the release is from the end of July.

[polyzen]

Not sure if a file manager is on the list, but just found Amaze today. The repo appears active, though the release is from the end of July.

[dschuermann]

If you decide switching to K-9 Mail, conider bundling OpenKeychain with it instead of APG. See on https://www.openkeychain.org/faq at "What is the relationship between APG and OpenKeychain?" why. We are also working hard on a better K-9 Mail PGP/MIME support, see https://www.openkeychain.org/k-9

[dschuermann]

If you decide switching to K-9 Mail, conider bundling OpenKeychain with it instead of APG. See on https://www.openkeychain.org/faq at "What is the relationship between APG and OpenKeychain?" why. We are also working hard on a better K-9 Mail PGP/MIME support, see https://www.openkeychain.org/k-9

[thestinger]

@polyzen Amaze seems great. Bundling a file manager would be nice since most people do actually want one and the goal for the bundled apps is guiding people towards solid FOSS options.

[thestinger]

@polyzen Amaze seems great. Bundling a file manager would be nice since most people do actually want one and the goal for the bundled apps is guiding people towards solid FOSS options.

[Bmme2GFTbU]

I think a button to kill all running apps at once (like cyanogenmod) would be great

[Bmme2GFTbU]

I think a button to kill all running apps at once (like cyanogenmod) would be great

[polyzen]

@Bmme2GFTbU, is that a widget they have?

[polyzen]

@Bmme2GFTbU, is that a widget they have?

[Bmme2GFTbU]

No, I dont think it is a widget. Its a button at the "Opened Process Overview" where you slide apps manually to close them. Furthermore the standard search engine and start screen of chromium should be changeable.

[Bmme2GFTbU]

No, I dont think it is a widget. Its a button at the "Opened Process Overview" where you slide apps manually to close them. Furthermore the standard search engine and start screen of chromium should be changeable.

[thestinger]

Chromium's search engine can be changed in the settings menu. The home screen is just the pinned icons and a search-specific logo / search box that's only there for Google right now. Alternatives like DuckDuckGo can be added to the search engine list.

[thestinger]

Chromium's search engine can be changed in the settings menu. The home screen is just the pinned icons and a search-specific logo / search box that's only there for Google right now. Alternatives like DuckDuckGo can be added to the search engine list.

[polyzen]

@thestinger, I've tried adding DDG before with no luck. Is there some trick to it?

On January 6, 2016 8:28:40 AM EST, Daniel Micay notifications@github.com wrote:

Chromium's search engine can be changed in the settings menu. The home
screen is just the pinned icons and a search-specific logo / search box
that's only there for Google right now. Alternatives like DuckDuckGo
can be added to the search engine list.

---

Reply to this email directly or view it on GitHub:
#123 (comment)

[polyzen]

@thestinger, I've tried adding DDG before with no luck. Is there some trick to it?

On January 6, 2016 8:28:40 AM EST, Daniel Micay notifications@github.com wrote:

Chromium's search engine can be changed in the settings menu. The home
screen is just the pinned icons and a search-specific logo / search box
that's only there for Google right now. Alternatives like DuckDuckGo
can be added to the search engine list.

---

Reply to this email directly or view it on GitHub:
#123 (comment)

[thestinger]

I mean they can be added in the build in CopperheadOS. I don't think there's an interface to do it right now even though the code to support it is there, they just never wrote the frontend for Android.

[thestinger]

I mean they can be added in the build in CopperheadOS. I don't think there's an interface to do it right now even though the code to support it is there, they just never wrote the frontend for Android.

[polyzen]

Ah, I see. Great.

[polyzen]

Ah, I see. Great.

[Bmme2GFTbU]

the user can only choose between Yahoo, Bing and Google. This seems to be a bad collocation for a privacy-focused user :-P

[Bmme2GFTbU]

the user can only choose between Yahoo, Bing and Google. This seems to be a bad collocation for a privacy-focused user :-P

[thestinger]

Well, don't worry, the default will be DuckDuckGo as it was before the port to AOSP. FWIW, I got them to fix the Play Services issue upstream: https://codereview.chromium.org/1554103002.

[thestinger]

Well, don't worry, the default will be DuckDuckGo as it was before the port to AOSP. FWIW, I got them to fix the Play Services issue upstream: https://codereview.chromium.org/1554103002.

[Bmme2GFTbU]

Nice to hear :-) BTW Wi-Fi Matic seems to work with the right settings. And could not recognize huge battery drain.

[Bmme2GFTbU]

Nice to hear :-) BTW Wi-Fi Matic seems to work with the right settings. And could not recognize huge battery drain.

[Bmme2GFTbU]

Any thoughts about davdroid ? To me it's realy useful.

[Bmme2GFTbU]

Any thoughts about davdroid ? To me it's realy useful.

[Bmme2GFTbU]

Amaze looks good but maybe some built-in Network-Features may be useful ?

[Bmme2GFTbU]

Amaze looks good but maybe some built-in Network-Features may be useful ?

[Bmme2GFTbU]

What are your thoughts about Telegram ?

[Bmme2GFTbU]

What are your thoughts about Telegram ?

[thestinger]

It's insecure by default so it's not a good fit. It has end-to-end encryption via secret chats but it lacks an equivalent for other features like group chats even though it's possible. The encryption is also quite sketchy and goes out of the way to avoid best practices for no reason.

Signal is what should be bundled for encrypted chat and calling via the internet connection, but it depends on Google Play Services. It works with the open-source GmsCore implementation but bundling that isn't really desired right now. It would be best to use the websocket port, The caveat is that the websocket port doesn't have working calling support right now.

[thestinger]

It's insecure by default so it's not a good fit. It has end-to-end encryption via secret chats but it lacks an equivalent for other features like group chats even though it's possible. The encryption is also quite sketchy and goes out of the way to avoid best practices for no reason.

Signal is what should be bundled for encrypted chat and calling via the internet connection, but it depends on Google Play Services. It works with the open-source GmsCore implementation but bundling that isn't really desired right now. It would be best to use the websocket port, The caveat is that the websocket port doesn't have working calling support right now.

[thestinger]

@Bmme2GFTbU: Amaze does seem to have SMB support.

[thestinger]

@Bmme2GFTbU: Amaze does seem to have SMB support.

[Bmme2GFTbU]

Finally I found it too. It's nice and it works, but hard to find this connection settings. Well, nobody said it will be easy :-P

[Bmme2GFTbU]

Finally I found it too. It's nice and it works, but hard to find this connection settings. Well, nobody said it will be easy :-P

[thestinger]

I'll remove QuickSearchBox for now but I'm still interested in an open-source alternative the Google search bar on the launcher (not just a search widget to put on the home screen).

[thestinger]

I'll remove QuickSearchBox for now but I'm still interested in an open-source alternative the Google search bar on the launcher (not just a search widget to put on the home screen).

[neo-luddite]

there is a signal fork called "libresignal" (Open Wisper Systems insisted that the dev changes the name of the app) which uses websocket: https://github.com/JavaJens/TextSecure

[neo-luddite]

there is a signal fork called "libresignal" (Open Wisper Systems insisted that the dev changes the name of the app) which uses websocket: https://github.com/JavaJens/TextSecure

[neo-luddite]

I'd really like to see some firewall implemented. would it be possible to integrate e. g.AFWall+? further on an adblocker (AdAway?) would be really nice to have. you could just ship an updated hosts file with every update and implement a button which switches between adblock-hosts-file and unchanged-hosts-file so that users could decide between adblocking and non adblocking...?

[neo-luddite]

I'd really like to see some firewall implemented. would it be possible to integrate e. g.AFWall+? further on an adblocker (AdAway?) would be really nice to have. you could just ship an updated hosts file with every update and implement a button which switches between adblock-hosts-file and unchanged-hosts-file so that users could decide between adblocking and non adblocking...?

[thestinger]

I guess what you're asking for is the ability to toggle off the network permission which has an open issue: #128. There's no reason to have a firewall app as it's OS functionality. There's a firewall but there's no way for users to control it yet.

[thestinger]

I guess what you're asking for is the ability to toggle off the network permission which has an open issue: #128. There's no reason to have a firewall app as it's OS functionality. There's a firewall but there's no way for users to control it yet.

[thestinger]

I'm aware of LibreSignal. It doesn't have working support for the RedPhone functionality, only texting. It's not acceptable to ship something broken. The broken functionality would have to be hidden at a bare minimum. It wouldn't fill the need for encrypted calling support so something else would be required anyway.

[thestinger]

I'm aware of LibreSignal. It doesn't have working support for the RedPhone functionality, only texting. It's not acceptable to ship something broken. The broken functionality would have to be hidden at a bare minimum. It wouldn't fill the need for encrypted calling support so something else would be required anyway.

[thestinger]

CopperheadOS used to have domain and IP blacklists but it's too heavy handed and user unfriendly. Ad-blocking at a browser level is much more powerful and much friendlier. It's too much for me to implement myself though. It will be adopted if and when it exists for Chromium (i.e. extension support or even a hard-wired uBlock Origin).

[thestinger]

CopperheadOS used to have domain and IP blacklists but it's too heavy handed and user unfriendly. Ad-blocking at a browser level is much more powerful and much friendlier. It's too much for me to implement myself though. It will be adopted if and when it exists for Chromium (i.e. extension support or even a hard-wired uBlock Origin).

[neo-luddite]

hm...if there is no frontend for cutomizing iptables rules I'll try Netguard ( https://github.com/M66B/NetGuard ) in the meantime. my usage of AFwall+ also includes the blocking of certain IP-adress ranges (e. g. facbook)a nd not only blocking app network access.

blocking ads on system level has the advantage, that also in-app-ads are blocked, not only the ads on the websites.

for me it's better to use a not fully functioning LibreSignal and beeing able to communicate google-free encrypted with my contacts. signal was actually the last thing that kept me installing google stuff on my phone.

[neo-luddite]

hm...if there is no frontend for cutomizing iptables rules I'll try Netguard ( https://github.com/M66B/NetGuard ) in the meantime. my usage of AFwall+ also includes the blocking of certain IP-adress ranges (e. g. facbook)a nd not only blocking app network access.

blocking ads on system level has the advantage, that also in-app-ads are blocked, not only the ads on the websites.

for me it's better to use a not fully functioning LibreSignal and beeing able to communicate google-free encrypted with my contacts. signal was actually the last thing that kept me installing google stuff on my phone.

[neo-luddite]

CopperheadOS used to have domain and IP blacklists but it's too heavy handed and user unfriendly. > Ad-blocking at a browser level is much more powerful and much friendlier. It's too much for me to
implement myself though. It will be adopted if and when it exists for Chromium (i.e. extension
support or even a hard-wired uBlock Origin).

right now I'm using firefox and ublock origin for adblocking on copperhead. beeing tracked with chromium is something I really don't like.

imho it would just be the decision hosts adblocking yes or no. you could write a small script which pulls the same sources as adaway does and would only have to cat it together and push it in the build directory. users wouldn't have to fiddle around with it because it would get updated with the normal copperhead updates. it would be a completely automated process.

I can live with it this way (till something is implemented in chromium), but I think adblocking and firewall are probably the mostly missed features for people moving away from rooted roms - or at least it is for me :)

[neo-luddite]

CopperheadOS used to have domain and IP blacklists but it's too heavy handed and user unfriendly. > Ad-blocking at a browser level is much more powerful and much friendlier. It's too much for me to
implement myself though. It will be adopted if and when it exists for Chromium (i.e. extension
support or even a hard-wired uBlock Origin).

right now I'm using firefox and ublock origin for adblocking on copperhead. beeing tracked with chromium is something I really don't like.

imho it would just be the decision hosts adblocking yes or no. you could write a small script which pulls the same sources as adaway does and would only have to cat it together and push it in the build directory. users wouldn't have to fiddle around with it because it would get updated with the normal copperhead updates. it would be a completely automated process.

I can live with it this way (till something is implemented in chromium), but I think adblocking and firewall are probably the mostly missed features for people moving away from rooted roms - or at least it is for me :)

[marix11]

How is opera as browser?

[marix11]

How is opera as browser?

[thestinger]

The browser decision is already made. Opera wasn't ever on the table because it's proprietary.

[thestinger]

The browser decision is already made. Opera wasn't ever on the table because it's proprietary.

[neo-luddite]

just fyi: netguard now supports hosts files, so the firewall and the ad problem without root are now somehwat solved for me and I can remove firefox from my phone again - yay

[neo-luddite]

just fyi: netguard now supports hosts files, so the firewall and the ad problem without root are now somehwat solved for me and I can remove firefox from my phone again - yay

[thelifeofjay]

@thestinger Music: I recommend either https://github.com/vanilla-music or https://github.com/naman14/Timber, both of which are updated often.

[thelifeofjay]

@thestinger Music: I recommend either https://github.com/vanilla-music or https://github.com/naman14/Timber, both of which are updated often.

[eighthave]

I can second OpenKeychain over APG by a long shot. K-9+OpenKeychain should become a lot more usable soon since they are adding PGP/MIME support to K-9. Also, using a Yubikey NEO NFC with OpenKeychain for PGP is interesting, but I still wonder what the vulns are re: PGP keys via NFC.

[eighthave]

I can second OpenKeychain over APG by a long shot. K-9+OpenKeychain should become a lot more usable soon since they are adding PGP/MIME support to K-9. Also, using a Yubikey NEO NFC with OpenKeychain for PGP is interesting, but I still wonder what the vulns are re: PGP keys via NFC.

[thelifeofjay]

Quick Search Box: https://f-droid.org/repository/browse/?fdid=com.duckduckgo.mobile.android

[thelifeofjay]

Quick Search Box: https://f-droid.org/repository/browse/?fdid=com.duckduckgo.mobile.android

[polyzen]

Hans, you could also use the yubikey over usb otg.

On Thu, Mar 31, 2016 at 4:12 PM, J notifications@github.com wrote:

Quick Search Box:
https://f-droid.org/repository/browse/?fdid=com.duckduckgo.mobile.android

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#123 (comment)

[polyzen]

Hans, you could also use the yubikey over usb otg.

On Thu, Mar 31, 2016 at 4:12 PM, J notifications@github.com wrote:

Quick Search Box:
https://f-droid.org/repository/browse/?fdid=com.duckduckgo.mobile.android

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#123 (comment)

[eighthave]

it would be awesome to get all these apps included in copperhead via the reproducible build process, so that people can just update directly via fdroid. I can help with that.

[eighthave]

it would be awesome to get all these apps included in copperhead via the reproducible build process, so that people can just update directly via fdroid. I can help with that.

[thestinger]

@darknetj That's not usable as the quick search box widget. It's a separate widget and doesn't use the screen space dedicated to search and the drag actions.

[thestinger]

@darknetj That's not usable as the quick search box widget. It's a separate widget and doesn't use the screen space dedicated to search and the drag actions.

[thestinger]

The problem with the Music app is that I think it's going to need to provide all of the AOSP Music app APIs in order for us to pass the Conformance Test Suite. There might not be a viable open-source alternative to the AOSP Music app right now.

[thestinger]

The problem with the Music app is that I think it's going to need to provide all of the AOSP Music app APIs in order for us to pass the Conformance Test Suite. There might not be a viable open-source alternative to the AOSP Music app right now.

[thestinger]

@eighthave I would still want to sign them with the CopperheadOS keys. It probably won't be the same build process because it should really be using the internal SDK / NDK. I do want reproducible builds for the OS as a whole but it's going to be a long path. We could offer updates to apps via F-Droid but it won't really matter once there are delta updates: nothing stops up from pushing out an OS update on short notice to just update an app.

[thestinger]

@eighthave I would still want to sign them with the CopperheadOS keys. It probably won't be the same build process because it should really be using the internal SDK / NDK. I do want reproducible builds for the OS as a whole but it's going to be a long path. We could offer updates to apps via F-Droid but it won't really matter once there are delta updates: nothing stops up from pushing out an OS update on short notice to just update an app.

[eighthave]

If you sign your build with your own key, then you'd have to maintain
the updates yourself entirely, since Android would see that as a
separate app. The combo of package name and signing key is the
identifier. In general, its best that a given packageName is only ever
signed by a single signing key. So to go the route you propose, you
should also change the package name of the apps that you are building
that way.

I don't see the advantage of going that route. It seems to me that it
just creates maintenance workload for Copperhead and generates confusion
in users since they would wonder why Copperhead's version of the app is
not interchangeable.

[eighthave]

If you sign your build with your own key, then you'd have to maintain
the updates yourself entirely, since Android would see that as a
separate app. The combo of package name and signing key is the
identifier. In general, its best that a given packageName is only ever
signed by a single signing key. So to go the route you propose, you
should also change the package name of the apps that you are building
that way.

I don't see the advantage of going that route. It seems to me that it
just creates maintenance workload for Copperhead and generates confusion
in users since they would wonder why Copperhead's version of the app is
not interchangeable.

[thestinger]

We need to be able to make changes to any bundled code, even if it's just temporary. And only apps in /system are covered by dm-verity and available in Android's safe mode. Since there's little barrier to releasing lots of OS updates (especially once there are delta updates), it makes sense to update anything deemed important enough to bundle that way.

It might make sense to change the package names but it doesn't really matter right now.

[thestinger]

We need to be able to make changes to any bundled code, even if it's just temporary. And only apps in /system are covered by dm-verity and available in Android's safe mode. Since there's little barrier to releasing lots of OS updates (especially once there are delta updates), it makes sense to update anything deemed important enough to bundle that way.

It might make sense to change the package names but it doesn't really matter right now.

[ghost]

I have some suggestions for alternatives, awaiting your judgment on security practices.

Calendar: Etar
Music: Vanilla Music
Mail: K-9 Mail
+1 for Amaze

I would prefer users be able to choose their own apps. If you add more and more system apps that makes it impossible to update them from other sources such as F-Droid. Consider allowing users to uninstall the non AOSP apps you sign so they can choose their own source. I see above you mentioned changing the package name, that feature would be much appreciated.

Echoing @eighthave's statement, reproducible builds are the holy grail.

[ghost]

I have some suggestions for alternatives, awaiting your judgment on security practices.

Calendar: Etar
Music: Vanilla Music
Mail: K-9 Mail
+1 for Amaze

I would prefer users be able to choose their own apps. If you add more and more system apps that makes it impossible to update them from other sources such as F-Droid. Consider allowing users to uninstall the non AOSP apps you sign so they can choose their own source. I see above you mentioned changing the package name, that feature would be much appreciated.

Echoing @eighthave's statement, reproducible builds are the holy grail.

[thestinger]

You can already disable apps if you don't want them. It's impossible for there to be any way to actually remove them. Reproducible builds would be nice, but all bundled are still going to be signed with the release key. It's the whole OS build that needs to be reproducible, not just individual apps. They should be built with the OS, not bundled as binaries - at least the ones that aren't Chromium, which can't be bundled for practical reasons (ridiculous compile-time). They should be built with the SDK, etc. included with the OS too, not an external one.

There needs to be an SMS app in the base OS, which is why SMSSecure replaced Messenger. There also needs to be a Music app implementing the expected APIs - only apps implementing the APIs required by the CTS are viable replacements. The same thing might apply to the Calendar and Mail client, but I don't think it does.

I don't really want to bundle a file manager. There's already a very primitive one in the Settings app (Storage -> Explore), and unlike Amaze it handles USB-OTG storage and can be used to safely unmount. Makes more sense to improve that as part of AOSP.

[thestinger]

You can already disable apps if you don't want them. It's impossible for there to be any way to actually remove them. Reproducible builds would be nice, but all bundled are still going to be signed with the release key. It's the whole OS build that needs to be reproducible, not just individual apps. They should be built with the OS, not bundled as binaries - at least the ones that aren't Chromium, which can't be bundled for practical reasons (ridiculous compile-time). They should be built with the SDK, etc. included with the OS too, not an external one.

There needs to be an SMS app in the base OS, which is why SMSSecure replaced Messenger. There also needs to be a Music app implementing the expected APIs - only apps implementing the APIs required by the CTS are viable replacements. The same thing might apply to the Calendar and Mail client, but I don't think it does.

I don't really want to bundle a file manager. There's already a very primitive one in the Settings app (Storage -> Explore), and unlike Amaze it handles USB-OTG storage and can be used to safely unmount. Makes more sense to improve that as part of AOSP.

[ghost]

Makes more sense to improve that as part of AOSP.

Completely agree, the fewer bundled apps the better IMHO.

[ghost]

Makes more sense to improve that as part of AOSP.

Completely agree, the fewer bundled apps the better IMHO.

[thestinger]

The only compelling reason to bundle them is that since they're part of the system image, they're protected by verified boot and are available in Android's safe mode.

[thestinger]

The only compelling reason to bundle them is that since they're part of the system image, they're protected by verified boot and are available in Android's safe mode.

[thestinger]

There should at least be an email client and browser in safe mode.

[thestinger]

There should at least be an email client and browser in safe mode.

[ghost]

How is the AOSP mail client in terms of security? Is it something I should recommend others use?

[ghost]

How is the AOSP mail client in terms of security? Is it something I should recommend others use?

[thestinger]

It's a dead project just like the Music and Calendar apps so no, it's not really a good idea to use it rather than another mail client.

[thestinger]

It's a dead project just like the Music and Calendar apps so no, it's not really a good idea to use it rather than another mail client.

[polyzen]

Just to note: based on comments in Amaze's bugtracker, USB OTG appears to be working(fixed?) since early Jan.

On April 21, 2016 8:37:55 AM EDT, Daniel Micay notifications@github.com wrote:

You can already disable apps if you don't want them. It's
impossible for there to be any way to actually remove them.
Reproducible builds would be nice, but all bundled are still going to
be signed with the release key. It's the whole OS build that needs to
be reproducible, not just individual apps. They should be built with
the OS, not bundled as binaries - at least the ones that aren't
Chromium, which can't be bundled for practical reasons (ridiculous
compile-time). They should be built with the SDK, etc. included with
the OS too, not an external one.

There needs to be an SMS app in the base OS, which is why SMSSecure
replaced Messenger. There also needs to be a Music app implementing the
expected APIs - only apps implementing the APIs required by the CTS are
viable replacements. The same thing might apply to the Calendar and
Mail client, but I don't think it does.

I don't really want to bundle a file manager. There's already a very
primitive one in the Settings app (Storage -> Explore), and unlike
Amaze it handles USB-OTG storage and can be used to safely unmount.
Makes more sense to improve that as part of AOSP.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#123 (comment)

[polyzen]

Just to note: based on comments in Amaze's bugtracker, USB OTG appears to be working(fixed?) since early Jan.

On April 21, 2016 8:37:55 AM EDT, Daniel Micay notifications@github.com wrote:

You can already disable apps if you don't want them. It's
impossible for there to be any way to actually remove them.
Reproducible builds would be nice, but all bundled are still going to
be signed with the release key. It's the whole OS build that needs to
be reproducible, not just individual apps. They should be built with
the OS, not bundled as binaries - at least the ones that aren't
Chromium, which can't be bundled for practical reasons (ridiculous
compile-time). They should be built with the SDK, etc. included with
the OS too, not an external one.

There needs to be an SMS app in the base OS, which is why SMSSecure
replaced Messenger. There also needs to be a Music app implementing the
expected APIs - only apps implementing the APIs required by the CTS are
viable replacements. The same thing might apply to the Calendar and
Mail client, but I don't think it does.

I don't really want to bundle a file manager. There's already a very
primitive one in the Settings app (Storage -> Explore), and unlike
Amaze it handles USB-OTG storage and can be used to safely unmount.
Makes more sense to improve that as part of AOSP.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#123 (comment)

[thestinger]

Last release was in July 2015 though.

[thestinger]

Last release was in July 2015 though.

[eighthave]

What is this "safe mode"? I don't really see the advantage of including the core apps as system apps rather than just installing the developer's official release. What threat model would be addressed by having the app built as part of the ROM and included as a system app rather than just pre-installed in /data? I guess it would be possible to uninstall and reinstall a malware version when the app is installed in /data while that would not be possible on ROMs that use a read-only /system.

[eighthave]

What is this "safe mode"? I don't really see the advantage of including the core apps as system apps rather than just installing the developer's official release. What threat model would be addressed by having the app built as part of the ROM and included as a system app rather than just pre-installed in /data? I guess it would be possible to uninstall and reinstall a malware version when the app is installed in /data while that would not be possible on ROMs that use a read-only /system.

[thestinger]

The system, vendor, boot and recovery partitions are verified by dm-verity. Safe mode disables apps in /data, including updates installed for apps in /system or /vendor.

[thestinger]

The system, vendor, boot and recovery partitions are verified by dm-verity. Safe mode disables apps in /data, including updates installed for apps in /system or /vendor.

[eighthave]

so you're thinking of having a "no user-installed apps" mode? Otherwise, for regular operation, moving regular apps to custom builds embedded in the ROM will add substantially to your maintenance load, and I don't really see big gains in real world security.

[eighthave]

so you're thinking of having a "no user-installed apps" mode? Otherwise, for regular operation, moving regular apps to custom builds embedded in the ROM will add substantially to your maintenance load, and I don't really see big gains in real world security.

[thestinger]

I wouldn't want any privileged apps to be outside verified partitions, for example.

Android has safe mode already. There's a way to trigger it at boot and it falls back to it in some conditions. So the basics really need to be built-in. They are already there in AOSP, it just shouldn't all be removed without replacing it.

[thestinger]

I wouldn't want any privileged apps to be outside verified partitions, for example.

Android has safe mode already. There's a way to trigger it at boot and it falls back to it in some conditions. So the basics really need to be built-in. They are already there in AOSP, it just shouldn't all be removed without replacing it.

[tobia]

As I mentioned in the linked issue, Silence crashes on the 5X, losing all SMS: you don't get a notification and don't have a clue that it's swallowing your messages.

Whether the issue is upstream or not, I would suggest shipping a different SMS app, at least as the default SMS handler, until that issue is resolved. I haven't tried many SMS apps, but I can attest that QKSMS from F-Droid works well.

[tobia]

As I mentioned in the linked issue, Silence crashes on the 5X, losing all SMS: you don't get a notification and don't have a clue that it's swallowing your messages.

Whether the issue is upstream or not, I would suggest shipping a different SMS app, at least as the default SMS handler, until that issue is resolved. I haven't tried many SMS apps, but I can attest that QKSMS from F-Droid works well.

[thestinger]

I think you're the first person to report an issue like this with it so it can't be a common issue. I'm interested in fixing any problems with it. I don't plan on replacing it.

[thestinger]

I think you're the first person to report an issue like this with it so it can't be a common issue. I'm interested in fixing any problems with it. I don't plan on replacing it.

[thestinger]

There are no current concrete plans in this area and I don't want to have non-actionable meta bugs, so I'm going to close this. It became too off-topic and hard to follow.

[thestinger]

There are no current concrete plans in this area and I don't want to have non-actionable meta bugs, so I'm going to close this. It became too off-topic and hard to follow.