Re: [guardian-dev] Seeking Jetpack Compose Security Concerns
On Mon, Nov 4, 2019, at 05:08, Hans-Christoph Steiner wrote: > Thanks for all your work tracking and pushing stuff like this! Sounds > like you're already raising some key points. I haven't looked at this > at all yet. I must say: such a drastic change sounds scary in terms of > the amount of work it'll take to move apps. It is really warranted to > ditch the whole View structure? It depends on how you define "ditch". There is a View in the end, because Activity needs one. However, that View has a Canvas, and all the composable functions that make up a Compose UI just draw on that Canvas. So, the view hierarchy has a very shallow depth, with all of the real application logic all in one View. In terms of the level of effort to move apps... I expect it to be a bit more difficult than the effort to move from Java to Kotlin. More code is affected in the Java -> Kotlin migration, as not all Android app code is tied to the UI. However, I expect that the View -> Compose migration will be more manual. In terms of whether any of this is "warranted"... Google has their reasons (maintainability, more open, first-class reactive implementation, etc.). The bigger thing is that Google will be steering developers to use it, which means the next generation of Android developers will start with Compose. So, while Compose is still nicely malleable, we need to try to make sure that it doesn't screw up security. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] Seeking Jetpack Compose Security Concerns
Hey Mark, Thanks for all your work tracking and pushing stuff like this! Sounds like you're already raising some key points. I haven't looked at this at all yet. I must say: such a drastic change sounds scary in terms of the amount of work it'll take to move apps. It is really warranted to ditch the whole View structure? .hc Mark Murphy: > As you may be aware, Google is working on Jetpack Compose, a next-generation > UI toolkit for Android apps, effectively replacing the existing View-based > system that we have been using since the beginning. Barring unexpected > technical problems, I expect Compose to be Google's Android UI focus for the > next decade. > > Since it is being developed in the open, and since it is still early in > developer previews, we have a wonderful opportunity to try to ensure that > this toolkit handles security-related scenarios well. > > If you find security-related concerns in Compose, file issues! If you know of > security-related concerns in the existing View system, and you want me to try > to determine if Compose suffers from similar problems, reach out! > > > > As an example, we use FLAG_SECURE to have a window block screenshots and > screencasts. However, Android lacks any concept of window inheritance or > ownership, so you have to put FLAG_SECURE on each window that needs to be > secured. Unfortunately, Google created lots of windows without giving us any > opportunity to add that flag, so we cannot readily secure our menus, Spinner > and similar drop-downs, toasts, and so on. See > https://github.com/commonsguy/cwac-security/blob/master/docs/FLAGSECURE.md > for more on that. > > As it turns out, Compose also creates windows, and it presently does not give > us the ability to add FLAG_SECURE to them. So, I filed issues for that: > > https://issuetracker.google.com/issues/143778148 > https://issuetracker.google.com/issues/143778149 > > Next weekend, I plan to look at text entry in Compose and confirm that we > have a way of avoiding String objects, so passphrases can be zero'd out and > we don't have plaintext passphrases floating around our heap unnecessarily. > > That's the sort of thing that we need to try to identify. In theory, since > Compose is shipped as libraries, this sort of thing can be improved later > (unlike framework classes that are baked into the firmware). In practice, > large code bases tend to ossify, and so the longer problems linger, the less > likely it is that we will be able to get them fixed. > > Thanks in advance for any suggestions or support! > > -- > Mark Murphy (a Commons Guy) > https://commonsware.com | https://github.com/commonsguy > https://commonsware.com/blog | https://twitter.com/commonsguy > ___ > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org > -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556 ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
[guardian-dev] Seeking Jetpack Compose Security Concerns
As you may be aware, Google is working on Jetpack Compose, a next-generation UI toolkit for Android apps, effectively replacing the existing View-based system that we have been using since the beginning. Barring unexpected technical problems, I expect Compose to be Google's Android UI focus for the next decade. Since it is being developed in the open, and since it is still early in developer previews, we have a wonderful opportunity to try to ensure that this toolkit handles security-related scenarios well. If you find security-related concerns in Compose, file issues! If you know of security-related concerns in the existing View system, and you want me to try to determine if Compose suffers from similar problems, reach out! As an example, we use FLAG_SECURE to have a window block screenshots and screencasts. However, Android lacks any concept of window inheritance or ownership, so you have to put FLAG_SECURE on each window that needs to be secured. Unfortunately, Google created lots of windows without giving us any opportunity to add that flag, so we cannot readily secure our menus, Spinner and similar drop-downs, toasts, and so on. See https://github.com/commonsguy/cwac-security/blob/master/docs/FLAGSECURE.md for more on that. As it turns out, Compose also creates windows, and it presently does not give us the ability to add FLAG_SECURE to them. So, I filed issues for that: https://issuetracker.google.com/issues/143778148 https://issuetracker.google.com/issues/143778149 Next weekend, I plan to look at text entry in Compose and confirm that we have a way of avoiding String objects, so passphrases can be zero'd out and we don't have plaintext passphrases floating around our heap unnecessarily. That's the sort of thing that we need to try to identify. In theory, since Compose is shipped as libraries, this sort of thing can be improved later (unlike framework classes that are baked into the firmware). In practice, large code bases tend to ossify, and so the longer problems linger, the less likely it is that we will be able to get them fixed. Thanks in advance for any suggestions or support! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
