Apparently, it is very difficult to create an accessible, collapsible nav menu on the web without JavaScript. Recent browsers make it possible without hacks though. This was an interesting read: https://adrianroselli.com/2026/07/link-popover-navigation.html #web #accessibility

adrianroselli.com

Logan Magee @lberrymage@infosec.exchange

· 2w ago

Replying to

@adamhotep@infosec.exchange It's possible to do that, but that approach has some accessibility issues and other quirks that make it less than ideal. This article talks about some of them: https://www.smashingmagazine.com/2017/11/building-accessible-menu-systems/#sidenote-the-checkbox-hack

Smashing Magazine

Building Accessible Menu Systems — Smashing Magazine

Creating inclusive experiences is a question of using the right menu patterns in the right places, with the right markup and behavior. In design, we often make the mistake of giving different things the same name. They appear similar, but appearances can be deceptive. In terms of inclusion, it may lead you to repurpose a semantically and behaviorally inappropriate component. Users will expect one thing and get another. In this article, Heydon Pickering will give you an insight into inclusive men

Logan Magee @lberrymage@infosec.exchange

· 12mo ago

Another day of Accrescent, another AOSP bug report: https://issuetracker.google.com/issues/447174551

You might say, "Why are you making file names more than 255 characters long? Do you really need to do that?"

No, no I don't. But someone had to try.

For those curious, I actually came across this because Accrescent was using APK URLs as its APK names to uniquely identify them. Those URLs obviously aren't valid file names, so an exception is thrown (for no clear reason). I "fixed" it locally by hex-encoding the URLs since I suspected it had to do with URLs not being valid paths. That worked locally, but failed in our testing environment which has longer APK URLs. The final fix was to hash the APK URL to ensure the APK name is a constant length and thus always a valid file name. At that point, I figured I should file a bug report.

#android #accrescent

issuetracker.google.com

Google Issue Tracker

Logan Magee @lberrymage@infosec.exchange

· 10mo ago

Replying to

@grote No, it doesn't. I think the program and its introduction have significant issues, but we (Accrescent) are trying to improve it where we can before it becomes more solidified.

Logan Magee @lberrymage@infosec.exchange

· 20mo ago

Replying to

@network_is_reliable@mastodon.social @normplum@fosstodon.org @celenity@infosec.exchange @accrescent@infosec.exchange For what it's worth, Accrescent does require domain ownership verification for all new apps now so that you can verify the app ID is published by its respective developer. It is also possible to verify that an app's signing key matches the developer's and is thus cannot be modified by someone else. However, I do acknowledge that it's not very transparent in the UI where an app came from or who submitted it, and that's something we hope to change eventually. We also intend to have more strict and clear policies about impersonation.

Logan Magee @lberrymage@infosec.exchange

· 20mo ago

I always get excited for new bundletool releases. This time: for device group targeting

https://github.com/google/bundletool/releases/tag/1.18.0

#android #appstore #accrescent

GitHub

Release 1.18.0 · google/bundletool

Updated bundletool help to include all commands. Open-sourced the code which is used for building APKs with build-mode ARCHIVE. Implemented support for device group targeting. Bundles which use dev...

Logan Magee @lberrymage@infosec.exchange

· 20mo ago

Replying to

@network_is_reliable@mastodon.social @normplum@fosstodon.org @celenity@infosec.exchange @accrescent@infosec.exchange Yes. One can download the app's APKs as well as the repository metadata and verify that the signing certificate fingerprints match using apksigner. This is effectively what Accrescent does itself, but it's possible to do outside of Accrescent.

Logan Magee @lberrymage@infosec.exchange

· 20mo ago

Replying to

@network_is_reliable@mastodon.social @normplum@fosstodon.org @celenity@infosec.exchange @accrescent@infosec.exchange You're right in part at least: an app ID can be arbitrary, and domain verification is not a holistic solution to verifying developer identities. However, it does prevent a malicious actor uploading, say, app.organicmaps to make it seem as if they own organicmaps.app when they don't really control that domain (not to mention the namespacing/collision issues it mitigates). This approach is also taken by other package repositories using reverse domain ID formats such as Maven Central, Flathub, and the Gradle Plugin Portal. There's a chance they could sneak a malicious copy past review with a different app ID. That's why, as I said, it's not a complete solution. But I do think it's a step in the right direction.