S
sha0

  • 27 minutes ago
  • Joined Aug 12, 2024

  • C programmer.

  • In DevTools with Vanadium

    If DevTools is crashing, then I believe that DevTools has the problem and not Vanadium. Even if an old Vanadium is "speaking a broken protocol," a high-quality DevTools would cope with that. Since it crashes, it's not coping with that. I should be able to "fuzz" DevTools without it crashing and my "fuzzer" could be an old Vanadium, a new Vanadium, or /dev/urandom.

    Thank you for considering the situation. I wasn't complaining about Vanadium nor reporting an issue with it. I was asking if it could be used with DevTools. The answer is "yes." And that's great! 😀

  • In PIN Ordeal

    Thank you for your response, GrapheneOS.

    I must admit that given that my 2 other forum discussions have just been locked, perhaps what I've typed has offended one or more GrapheneOS folks. What can I type and/or do to try to repair the relationship? The "obvious" answer is "use the latest GrapheneOS," it seems, but that has challenges, which I'll explain later on.

    In one of the now-locked topics, I was simply asking a question, then shared a self-answer, which someone else in the community liked, then a response from today seems to be that if I don't use the latest GrapheneOS version, I should not participate in the forum.

    In another of the now-locked topics, I explained that I had indeed updated my GrapheneOS version to the latest one available for my device, which then involved obtaining the Google features via that latest GrapheneOS' Google-fetching features, but that Google Maps' Timeline feature still didn't work. Perhaps that was somehow unclear from my message.

    Later in that same topic, I'm accused of going on an ignorant rant and attacking GrapheneOS and software developers without understanding how it works. Perhaps that response might be viewed in a different light, given the clarification of my previous paragraph, just above. I don't think that's a fair characterization.

    I haven't intended to "attack" anyone. I'm unsure if some of the imagined possibilities I shared in the top message from today might have been offensive, but they weren't meant to be. I'm sure that many GrapheneOS users are distrustful of other parties: that's probably why they appreciate the efforts, time, and money spent by GrapheneOS folks towards extra privacy and security. The imaginary scenarios were intended to be aligned with other scenarios that I've read in other discussions. They weren't accusations, which is why I used the word "imagined." I appreciate your kind response ("no such thing") to one of them, which provides clarity for the community and for the curious.

    I am a software developer, since roughly 1991. I am also a person who has major struggles with UI changes. I'm sure that there are many reasons for why much software these days mashes UI changes with security changes, but that causes me no end of grief. Please forgive me for occasionally voicing this concern to other software developers, at relevant times. Some day, maybe they'll be received well. I'd be delighted to enjoy the latest fruits of GrapheneOS, relative to security. Unfortunately, these do not appear to come separately from UI changes. (As an example, the unlock-code entry-dots are circles on my old GrapheneOS, but changed to pointy shapes in the latest Pixel 6a GrapheneOS in October.)

    In response to "third party sourced Google Play apps": I've tried to clarify the situation, above: I did try the latest GrapheneOS and thus the latest Google Play software, in October. It didn't help Maps, so I reverted GrapheneOS.

    I shared the timeline in today's first message. I disabled all Google items in either November or December. I do not perceive a relationship between that activity and my sudden grief 2 days ago, unless there was a ticking time-bomb or an exploit caused by those disabled apps.

    I thought someone in the community here might respond with something like, "Ah yes, the old PIN screen with the weird count-down numbers. This is a known malware by celebrated hacker-group X and you've surely fallen victim to it, doubtless due to your old GrapheneOS version," or with something like, "Ah yes, looking carefully, I see that this fluctuating count-down timer is still the case, today. Neat! What a minor UI quirk, though." I'm sorry if this was perceived as a gripe about GrapheneOS: it wasn't.

    In response to "Highly unlikely", as you doubtless known image-processing vulnerabilities come along, from time to time, and not even all that long ago. CVE-2023-41064 is a recent example for a different platform:

    So that imagined scenario was just a whimsical example. These imagined scenarios were just that: imagined and not projected as reality, nor accusatory of GrapheneOS incompetence.

    In response to "used to having an insecure OS," what I'm used to is laptop and desktop and data-centre computers: having trust-keys on a chip, adjusted through a password-protected interface, where those keys are used to verify boot pay-loads, which then boot an OS which requests another password for LUKS-protected data. This is a clean separation between the data and the machine and so yes, the data can be placed into any other machine and accessed, if the data-password is known. If the "standard security model" (in the context of GrapheneOS and/or Android) is that the device should be a single point of failure for the accessibility of the data, then yes, I guess I'm not used to that.

    Given some of the responses, it seems that I jumped into GrapheneOS too early: that is, I got used to the UI before backup/restore features were ironed out and now that they have been, I can't access those features without also confronting all the UI changes that will have come along for the ride.

    Why are Androids and cellular telephones appearing to depart further and further from the laptop and desktop computer ecosystem, despite these former devices also being computers? I want my data to be conveniently accessible in a non-Android Linux. SeedVault only appears to have unofficial relatives for plain Linux. Why doesn't it produce a .tar.gz.gpg file, or some other format that standard Linux tools can manipulate with ease? Why does it require an already distrustful user to download unofficial software, in order to get at their precious data? Please note that I'm not actually asking this paragraph's questions with the hope of a response to them: they probably belong in a different topic after I am positioned to satisfy the "I'm using the latest GrapheneOS" condition. What I'm trying to do is to share context about the harsh score that I gave to SeedVault. I'm sure that SeedVault developers worked and continue to work very hard, and that their efforts are enjoyed by many or even most users. That's admirable. I wish it had worked well for my goals in its 2022 iteration.

    About the secure element's retry-timer, after waiting more than 24 hours since my last attempt and trying again, the count of failed attempts has changed from 192 to 162 and the count-down message indicated that I ought to try again in "653 seconds." I took a picture. After waiting for that count-down to complete and after trying again, the message again noted "162 times" and to try again after 9XX seconds, but I didn't catch it with a picture. If it's true that the UI is reporting what the secure element reports, then perhaps this discrepancy can be explained by malware or perhaps it can be explained as unworthy of any attention because it's from a 2022 GrapheneOS version. I was expecting to be hindered by 1 attempt per day. Surely all of the newer GrapheneOS users having more than 140 attempts will be hindered at such a rate with clarity about that rate.

    In an effort to foster a shared understanding of the recent responses to my attempts for discussion, would this be a fair notice for someone considering using GrapheneOS?:

    Please note that it should be clear that GrapheneOS project participants (such as developers) have a focus on security and privacy, above all else; we're quite good at it and we certainly strive for it. Without infinite resources available to the project, the fact of the matter is that some considerations rank less than others, in priority. It's also unlikely that everyone can be satisfied by any project, so we make decisions about trade-offs and attention using our best judgment, which should go without saying.

    For example, it's convenient for us to make releases in which security enhancements, privacy enhancements, feature enhancements, and user interface changes are all bundled together. The alternative strategy to release these subjects separately would be extremely cumbersome and complicated; you wouldn't enjoy it and we wouldn't enjoy it. We're always hoping to work for your best interests.

    With this strategy, we expect, for example, that a tiny majority of GrapheneOS users might object to a seemingly trivial UI change, but still benefit from the overwhelming majority of the rest of the release. Some of our decisions are informed by considering the majority of users, as opposed to a tiny minority. Some UI changes are inherited by other parts of the Android ecosystem; outside of GrapheneOS efforts. If you are a person who suffers greatly from UI changes, GrapheneOS might not be the best choice for you. We know that some elderly folks and some folks having disabilities and even some other folks might be in such a situation. (You are unlikely to find a better alternative, though, elsewhere!)

    Also, please keep in mind that sometimes updates don't always work as planned. Sometimes a bug might strike in even the largest crowd of software users. This possibility for GrapheneOS updates is no different than for any other software updates, although we don't find it likely.

    If you do not keep up to date with GrapheneOS, not only do you expose yourself to historical risks that we address in our updates, but we're not interested in diverting resources to attend to the fall-out from your out-dated position. GrapheneOS participants want to maximize value.

    NOTE: The above is not a quotation from any GrapheneOS project participant. It is imagined by me as the type of notice that might be fair to share with people who are interested in GrapheneOS.

    Please try to read what I type with openness to charitable interpretations. I might not be an expert at writing frankly and leading to positive interpretations, such as light-hearted responses. I always hope for those, however. I apologize if what I typed included not-well-received criticism.

  • In PIN Ordeal

    Facts:

    October 1st, 2022: I purchased a Google Pixel 6a, after researching GrapheneOS and then choosing that device. At some point very shortly after that purchase, I installed GrapheneOS "TP1A.220905.004.A2"; probably the "2022092800" iteration:

    I set up a lock-screen code that was different than my previous cellular telephone. I set up the "instant lock" so that this code would be required immediately after I press the multi-purpose top button to lock the device.

    I disabled all automatic updates that I could identify. It is simply the case that in the industry, the vast majority of software development does not make efforts to keep UI changes separate from security-related changes, so I do sometimes forfeit security in favour of a stable UI. (A case of "beggars trying to be choosers," one could argue.)

    All was well until Google decision-makers ruined one of my favourite features in Google Maps, for my GrapheneOS scenario:

    September 9th, 2024: After updating to the latest GrapheneOS and finding that (predictably) the UI had changed and that there was no Maps improvement, I reverted to "TP1A.220905.004.A2". At that time, I probably chose the same lock-screen code as before, but perhaps I chose a different one.

    It seems that the GrapheneOS feature for installing Google-related features was no longer supported by GrapheneOS infrastructure, by this point, for this older version of GrapheneOS. I was forced to seek a "less reputable" source for the Google-related features. After reviewing many of them, I found a source which seemed to be the least offensive to my distrust and I installed it. All seemed well.

    At some point in November or December, YouTube UI changes and the broken Maps feature yielded enough frustration that I disabled all Google apps and features that I could identify, including the Play Services and another related "background" app. After that, all was well...

    March 19th, 2025: I unlocked my phone many times, but at some point in the afternoon, I tried to unlock my phone and my code was not accepted. I tried several times, then rebooted the phone. I have tried many times, since then, but without success. I believe the last note I saw reported that I've tried 192 times.

    After reaching 9XX seconds for the retry-timer that appears after a failure, very rarely I see that the retry-timer indicates a very low number that I'd seen when my count of attempts was much lower, such as 120 seconds. Most of the time, the number that appears is 9XX seconds. If I then reboot the phone and try to enter a code, it seems that the retry-timer that appears is something like a continuation of the time remaining from the previous attempt: sometimes in the 8XX range.

    Sometimes I see that the final digit of the retry-timer appears to switch back and forth a couple of times very quickly, as it counts down. For example, "3 2 3 2, 2 1 2 1, 1 0 1 0, 0 9 0 9, 9 8 9 8," etc. This isn't consistently observable, however; apparently random. This could be a simple UI flaw, although I can't quite imagine how that flawed logic might be.

    Imagined possibilities for what has happened:

    Perhaps because I use an older GrapheneOS, a specially-crafted image at a popular "free online sound meter" web-page (visited shortly before the problem) introduced bad software onto my phone and changed the lock-code software so that the phone accepts no code and logs all codes that I try and submits those codes to a malicious collector of codes. I've seen at least 2 other discussions in which a person having a comparable experience shares that "after a [few hours / few days], the code was suddenly accepted!" If the "bad software" includes such a timer and then releases the phone back to the relieved owner, then it seems likely to be imagined to be an owner error, all along, but having collected code-attempts from that owner.

    Perhaps because I unlocked another phone (having a different code) shortly before the problem, this scrambled up my memory of my usual code, but somehow this scrambling-up persists beyond 72 different codes that I've tried. (All of them "phone muscle-memory bells ringing" and not PIN codes for anything else I might have PIN codes for.) I've unlocked both phones multiple times within the same day before without becoming scrambled up, however.

    Perhaps a blood-vessel in my brain broke and neurons responsible for the "muscle-memory" of unlocking my phone were destroyed.

    Perhaps GrapheneOS decision-makers became aware of a security-concern so severe that they issued an unconditional software update through an emergency band, but this has broken my code-entry process.

    Perhaps one or more cosmic rays reached the innards of the Titan M2 chip and ruined the bits of certain keys, so even if my unlock code is correct, it'll never work.

    Thoughts about this ordeal, so far:

    Write down your unlock-code. (Some readers might respond, "Well, duh," but some readers might respond, "Oh, I'm going to do that, right now.") Maybe not literally, in case you're worried about an unauthorized person obtaining it from a search of your papers, but maybe in a password management system that isn't on your phone, or with a trusted party, or requiring multiple trusted parties to reveal it. Having certainty about the correct code permits this bisection of the problem-space:

    • Yes, I know the code is correct, so the problem is that the phone is broken or hacked.
    • No, I don't know the code is correct, so I could be the problem, or the phone could be broken or hacked.

    All of this modern security is a double-edged sword: it's great at keeping people out of your data. Sometimes you are one of those people.

    The Google Pixel 6a does not appear to support booting an alternative kernel. Normally in a case of potentially catastrophic data-loss, I'd take a DD copy of the storage block-device and deal with it later. For example, with other, older phones, I could boot TWRP, make a DD copy, install a new operating system on the phone (erasing data), then if the new OS seems unsuitable, I could once again use DD to restore the phone to the previous state, with all data intact. Not only does the Pixel 6a not appear to support 'fastboot boot <kernel>', but TWRP doesn't support the Pixel 6a, anyway. Having no DD, I can have no "snapshots" of known-good states, for this phone. Not only that, but the fancy chips (like Titan M2) imply that storage-keys might not even be stored on the disk: having the disk is not enough to represent the state of the device.

    During the October Maps ordeal, because I could not use DD, I used SeedVault to try to back up my data, before I upgraded the GrapheneOS version. Since I do not have 2 Pixel 6a devices, I was unable to fully test a restoration and I had to cross my fingers. I was disappointed by the results: most of the apps (including Google apps) did not correctly restore to an installed state. Some apps were restored, but their data wasn't restored. The content of a SeedVault backup is not at all easy to work with from a computer: an unofficial extraction-tool exists, but one doesn't get a directory of files as they appeared in the FS on the phone. I would score SeedVault at a notch above useless, since I believe it did restore some pictures. For contrast, when I restore a DD backup of an old phone to that phone, that phone is as it was on the day I took the backup. Fortunately, at least one popular, privacy-oriented messaging app has decent backup and restore features, although not for their computer-based variant. I was also surprised to learn that Vanadium history isn't something that can be backed up nor restored, by design.

    Back up your data at least once per week. Also during that October ordeal, I decided to back up my data more frequently than I had been. That frequency wasn't great enough, since I now have no access to recent data that I wish I had access to.

    Maybe the "unlock timer" UI isn't representing whatever timing representations the "Titan M2" is keeping track of, so maybe many some of my attempts have failed because the UI did not indicate a distinction between "retry-timer is still in effect" versus "the attempt has been tried and rejected by Titan M2."

    I've read about the retry-timer, here:

    It's not clear to me why the UI isn't indicating "Retry in 1 day" to me, after my 192 attempts, but is indicating 9XX seconds, at the most. Either I've misunderstood something or that article isn't applicable to my device or the UI isn't accurate or the phone has been hacked and the code-entry is malicious software. Assuming that there is a flaw with the UI which is misleading me, I will ensure that I wait a full 24 hours, in-between my next attempts.

    Despite 2 nights of sleep so far, I haven't woken up with the unlock-code muscle-memory suddenly restored with great certainty. Assuming that I've forgotten for now, maybe it'll come to me some day in the future, but it seems that if I want to preserve this data, I'll have to set this phone aside and use another phone, for productivity. I must have unlocked this phone at least 40 times per day since I bought it, so it's very surprising to suddenly "lose" this.

    Maybe if I had "fingerprint unlock," I'd have some alternative. Why would anyone ever want to submit their fingerprint to any software that they hadn't written themselves, though, or lack imagination regarding finger-choppers breaking down the door?

    I appreciate many features of GrapheneOS.

    Here is another, similar discussion:

    • In Google Maps Dec. 8th, 2024 Timeline Dead-Line

      safeandsecure8373: Yes, I should've mentioned that I had already encountered that discussion you've linked to.

      To follow up:

      Just before the cut-off time, I tried one final update of Google Maps and the problem persisted. After that, I disabled all Google apps (including Play Services and the other "background" app) and I put Maps on an older phone which I take with me when I want to track my position for an adventure. This is inconvenient.

      Also, Google Maps asked me a couple of times in surveys about what I think about Google respecting security and/or privacy of user data. (I can't remember the exact wording.) These surveys were surely consistent with a hypothesis that this Timeline change business was a response to privacy concerns. Perhaps there were millions of voices complaining about being tracked (by governmental insistence towards Google, perhaps) and perhaps only a handful of voices complaining that a feature that has been enjoyed as a favourite feature for over a decade was being ruined.

    • In Google Maps Dec. 8th, 2024 Timeline Dead-Line

      Good day.

      As some of you know, Google Maps' Timeline feature is undergoing a change: data will be transitioned away from Google-hosted and towards each device having the Maps app. Google is issuing warning e-mail and visiting the Timeline feature outside of the app (inside of a web-browser) yields a prominent warning. One of the articles is here. That article indicates that a "push-notification" will be received when using the app, which will presumably present the "opt-in" choice to move/store the data on one's device.

      Firstly, if one's Maps app is too old, one must update to at least the minimum version specified in the article: 11.106.

      Secondly, if one updates the app (I updated to the latest-available Maps; beyond the version mentioned above) to satisfy the aforementioned, those push-notifications appear to have no greater than a weekly schedule, so one might need to wait for that long before receiving the "notification."

      Thirdly, for my GrapheneOS device, upon activating (tapping) the notification, the Maps app will load the Timeline feature (I see it "Going back in time...") but just as soon as it's loaded, a "Can't open Timeline on this type of device" message appears, along with other text explaining that the device isn't supported. This message is incorrect because the Timeline feature works just fine. It seems that this message is simply what is yielded when something goes wrong while using the Timeline feature.

      Presumably, what's supposed to happen is after loading the Timeline feature, some page will arrive and will probe about whether or not I want to move/store my Timeline history on my device. I've never seen the actual step, so I don't know for certain. I can't reach that stage.

      I tried using logcat to investigate and it seems that Maps tries to engage with a Vanadium web-view and experiences an error:
      [...]
      09-05 23:14:03.589 1281 1723 I ActivityManager: Start proc 22807:app.vanadium.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1/u0i79 for {com.google.android.apps.maps/org.chromium.content.app.SandboxedProcessService0:1}
      [...]
      09-05 23:14:03.731 22807 22807 W app.vanadium.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1: ART APEX data files are untrusted.
      [...]
      09-05 23:14:03.823 22807 22807 D app.vanadium.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1: Time zone APEX ICU file found: /apex/com.android.tzdata/etc/icu/icu_tzdata.dat
      09-05 23:14:03.823 22807 22807 D app.vanadium.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1: I18n APEX ICU file found: /apex/com.android.i18n/etc/icu/icudt70l.dat
      [...]
      09-05 23:14:03.867 22807 22807 E app.vanadium.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1: Unable to find pattern file or unable to map it for am
      [...]
      09-05 23:14:03.943 22807 22807 W app.vanadium.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1: unable to execute idmap2: Permission denied
      09-05 23:14:03.944 22807 22807 W OverlayConfig: 'idmap2 create-multiple' failed: no mutable="false" overlays targeting "android" will be loaded
      09-05 23:14:03.952 22807 22807 W ziparchive: Unable to open '/product/app/TrichromeLibrary/TrichromeLibrary.dm': No such file or directory
      09-05 23:14:03.952 22807 22807 W ziparchive: Unable to open '/product/app/TrichromeLibrary/TrichromeLibrary.dm': No such file or directory
      09-05 23:14:03.952 22807 22807 W app.vanadium.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1: Entry not found
      09-05 23:14:03.955 22807 22807 D nativeloader: classloader namespace configured for unbundled product apk. library_path=/product/app/TrichromeWebView/lib/arm64:/product/app/TrichromeWebView/TrichromeWebView.apk!/lib/arm64-v8a:/product/app/TrichromeLibrary/TrichromeLibrary.apk!/lib/arm64-v8a:/product/lib64:/system/product/lib64
      09-05 23:14:03.974 22807 22807 D nativeloader: classloader namespace configured for unbundled product apk. library_path=/product/app/TrichromeWebView/lib/arm64:/product/app/TrichromeWebView/TrichromeWebView.apk!/lib/arm64-v8a:/product/app/TrichromeLibrary/TrichromeLibrary.apk!/lib/arm64-v8a:/product/lib64:/system/product/lib64
      09-05 23:14:03.998 22807 22807 I LoadedApk: No resource references to update in package app.vanadium.trichromelibrary
      [...]
      09-05 23:14:04.005 22807 22807 I cr_WebViewApkApp: Launched version=106.0.5249.65 minSdkVersion=29 isBundle=false processName=app.vanadium.webview:sandboxed_process0:org.chromium.content.app.SandboxedProcessService0:1
      [...]
      09-05 23:14:04.018 22807 22807 E WebViewLibraryLoader: can't load with relro file; address space not reserved
      [...]

      I'm not certain of the relevance of the above, but it was consistent for each attempt. Other detail was also present, including an SQLite "unique constraint" error.

      I reluctantly tried updating my Google Pixel 6a to the latest version of GrapheneOS, but the situation did not change, after that. (As usual, every software change can result in a cascading failure: software developers seem mostly ignorant of how UI changes are not universally desirable. After reverting my GrapheneOS to get back to the UI that is already burned into my brain, it seems the Apps and [updated to] App Store apps no longer show the Google software, so it was a battle to obtain the few sand-boxed Google item again. I also learned about how Vanadium book-marks are not part of a SeedVault backup, so those 90 items were lost. I do not understand why security, non-quite-security-related bug-fixes, UI changes and feature-additions/feature-changes aren't separate update-tracks; the state of modern, limited-resource software engineering, it seems.)

      If anyone recognizes some of the logcat output above or if anyone has some suggestions, I welcome feedback, please. I am interesting in continuing to use Google Maps' Timeline feature and to preserve my history, but it seems that I am blocked by an incompatibility between Maps' "opt-in" process and GrapheneOS, with the Dec. 8th, 2024 dead-line soon approaching.

      Thank you for your time and reading-effort.

      • In DevTools with Vanadium

        "Try It And See" seems to yield "yes," I've now discovered.

        I've had lots of DevTools crashes while doing so, but that's not to lay any blame.

        • In DevTools with Vanadium

          Good day.

          Does Vanadium on GrapheneOS support being "debugged" by a Google Chrome DevTools running on a nearby computer, if USB debugging is enabled? This is a common feature for Google Chrome on "mobile" devices. I searched and found one forum-item that seemed similar, but its results appeared to have a focus on a "Brave" browser, instead of Vanadium.

          Thank you for your time.