Status Update
No update yet.
Comments
ma...@google.com
no...@google.com
It doesn't look like this bug has a link to the affected dataset(s) in Earth
Engine. Please reply to this bug with a comment containing a URL of the form
"
If this issue doesn't affect an existing dataset, consider moving in into the "Public Trackers > Earth Engine > Datasets > New Datasets" component. If the dataset is a new or updated version of an existing dataset, you can add the URL of the existing one. And if you cannot add a URL, you can disable future automated messages by adding a comment with "dataset_bug_ranker: disable" on its own line.
Reason: Issue does not contain a dataset URL. dataset_bug_ranker: remind=P7D
si...@google.com
On Thu, 16 Jan 2025, 13:25 , <buganizer-system@google.com> wrote:
no...@google.com
direct me to the appropriate place, many thanks
On Thu, Jan 16, 2025 at 1:39 PM Hope Irvine <hopekathleenirvine@gmail.com>
wrote:
no...@google.com
ch...@gmail.com
Closing as intended behavior. Use the panel handle to reduce the Code and Map panel area and increase the Console panel.
Description
Android Studio 4.0 Canary 2
Build #AI-192.6817.14.36.5984562, built on November 3, 2019
Runtime version: 1.8.0_212-release-1586-b4-5784211 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 5.0.0-32-generic
GC: ParNew, ConcurrentMarkSweep
Memory: 1981M
Cores: 8
Registry: ide.new.welcome.screen.force=true, debugger.watches.in.variables=false
Non-Bundled Plugins: CheckStyle-IDEA
Version of Gradle Plugin: gradle:4.0.0-alpha02
Version of Gradle: 5.6.1
Version of Kotlin: 1.3.60-eap-25
OS: Ubuntu 19.04
Steps to Reproduce: Look at the EditorModel in TextField.kt from androidx.ui:ui-framework:0.1.0-dev02
Expected Results: EditorModel to use a CharSequence or some other text representation that can be cleared from memory
Actual Results: EditorModel uses a String, which is immutable in the JVM
---
While String is super-convenient, one big flaw is that it is immutable. That is not a problem in most situations, but it is a substantial issue in password fields. It's generally recommended to try to remove all traces of a password as soon as those traces are no longer needed. This includes wiping out whatever text is held by the text entry widget used for the password. See for example:
In the Android view-based system, EditText uses an Editable, which is a sub-type of CharSequence. We can clear those, setting their contents to all zeros (or whatever). So, once the user is done entering the password, we can get the Editable, use it for our secure situation (e.g., send it to the server), and then clear its contents.
EditorModel not only uses an immutable String, but it does so for each intermediate step in the text input. Now we have N-1 partial passwords (or more) for an N-character password, represented as String objects. Those will remain in the heap until the memory get reused, and that is a risk for certain types of attacks.
Ideally, EditorModel would use a different text representation, one that we can clear, the way we can with Editable in an EditText. If the vision is that this is handled by a separate composable (e.g., PasswordField) with its own model, that's fine (though you'll want to move the visualTransformation over to this other composable, as otherwise developers will use TextField for passwords).
Thanks for considering this!