Mark L. Murphy's Blog, page 27

The SQLite Magellan Bug, And Your App

Recently, Tencent���s Blade Team published some notes
about a bug that they call Magellan. The underlying flaw is in SQLite and its
handling of full-text search ���shadow tables��� (FTS3, FTS4, etc.). An attacker that
can either execute arbitrary SQL or give you an arbitrary database to use might
be able to write arbitrary content to files via this bug. If that ���arbitrary content��� represents
executable code, the attacker might be able to execute it. Hence, this is characterized
by Tencent as a remote code execution (RCE) vulnerability.

Most Android apps should not be affected by this. Here are some categories of
development techniques that might be at risk.

You Execute Arbitrary SQL from Arbitrary Sources

Many places are going to describe this as a Chromium (or Chrome) bug, rather
than a SQLite bug. That is because Chromium offers WebSQL, allowing Web pages
to create and manipulate relational databases on the client side��� and Chromium���s WebSQL
is implemented using SQLite.

Most Android apps that use SQLite execute their own SQL, whether hard-coded or
generated via some library (e.g., Room). Few Android apps accept SQL statements
from arbitrary sources and execute them. If you do, your app may be at risk.

At minimum, this bug could corrupt your app���s database or other accessible files.
It is conceivable that an attacker could use this to remotely execute code,
if your app executes arbitrary code. For example, if you use the support multidex
library on Android 4.4 and older, in theory this attack could be exploited
the way that
Samsung was in 2015.

You Open Arbitrary Databases

It may be possible for an attacker to exploit this bug just using a SQLite
database file that you open and attempt to use. This will be a more difficult
avenue of attack. With WebSQL, not only do the attackers have the bug, but they
have a full programming language (JavaScript) that they can use. With the
arbitrary-SQL attack, attackers are limited to SQL expressions. With the
arbitrary-database attack, attackers are limited to how your app uses the
database. It is really unlikely that this will be able to be exploited.

That being said, if you allow the user to open a SQLite database that your app
did not create, your app may be at risk.

SQLite���s ���Defense Against Dark Arts���
page recommends that you run PRAGMA integrity_check or PRAGMA quick_check
on all foreign databases before doing anything else. Unfortunately, these were
added in SQLite 3.20.0, and so they are only available on Android 9.0 and higher,
at least in terms of the framework SQLite implementation.

You Use WebView to View Arbitrary Content

Android���s WebView supports WebSQL, apparently (I have not used it personally).
If you allow the user to view arbitrary Web content in a WebView, your app may be at risk.
If, however, you are only loading your own content (e.g., help pages packaged
as assets), you may be safe.

Google has the responsibility for updating WebView on newer Android versions
for Google Play ecosystem devices. Older devices (Android 4.x and below) will
be at risk indefinitely. Devices outside the Google Play ecosystem would need
to have their WebView implementations updated by their manufacturers or custom
ROM developers, presumably.

Depending on the nature of the app, you might consider trying to disable WebSQL
in WebView, if that is possible (again, I have no personal WebSQL experience here).

The specific bug here was fixed in SQLite 3.26.0. No current version of Android
uses that ��� even Android 9.0 is back on 3.22.0. IMHO, it is very unlikely
that Google would ship a replacement SQLite implementation in a security fix, and
at this point I am not expecting to see an Android 9.1 release. So, most likely,
the framework SQLite issue will not be fixed until the next major version of
Android, in 2019.

If your app packages its own copy of SQLite, rather than use the framework copy,
aim to upgrade to something based off of SQLite 3.26.0 or higher as soon as possible.
For example, SQLCipher for Android 4.0.0 just shipped, but it is based on 3.25.2,
so SQLCipher for Android users should keep an eye out for future updates.

The best collection of accessible information that I see about this bug is at
this Hacker News page. My understanding
is that the ���SQLite��� user there is Dr. Richard Hipp, the creator of SQLite.

How You Can Help!

This week, I released two new books, focused on ���second-generation��� Android
app development, using Jetpack/AndroidX along with Kotlin.
Those books are works in progress ��� they should reach 1.0 status sometime
early in 2019.

Eagle-eyed observers will notice that my pace has slowed a fair bit. Ordinarily,
I would have done point releases of those books long before now and might already
be to 1.0 versions.

Unfortunately, I have fewer subscribers than I used to, and I have fewer
training customers than before. To make
ends meet, I took on some longer-term consulting work. While that has been wonderful,
it limits how much time I have to devote to the books.

If you would like me to be able to work faster on the books, spread the word!
The more interest there is in what I do, the more time I can spend working
on that.

If there is anything in particular that I can do to help you or your organization,
reach out!.

Where Things Go From Here

This week, I released two new books, focused on ���second-generation��� Android
app development techniques: Jetpack/AndroidX, particularly using Kotlin.

The other four books in the Warescription, at present, cover ���first-generation���
techniques: the Android Support Library, particularly using Java.

Of course, the material in those books is not obsolete at this time. Only some developers
have moved over to AndroidX, for example, in part because those libraries only shipped in a 1.0.0 state
a couple of months ago. ���Jetpack��� is a brand,
and I have been covering most of the Jetpack pieces for quite some time. But,
inevitably, the material in those four books needs to get upgraded to second-generation
approaches, before it actually does become obsolete.

Beyond continuing my work on the two new books in the Elements series,
my top upgrade priority is Exploring Android. I started that
book this year as a replacement set of hands-on tutorials. I got through most
of what I wanted��� but then Jetpack/AndroidX were released. Plus, I wrote those
tutorials in Java. So, starting early next year, I will work on rewriting
Exploring Android as a second-generation book.

The ���odd duck��� of my first-generation books is Android and GraphQL.
I wrote this book as the Architecture Components were rolling out, but I incorporated
little of them in the book. So, this book is further behind than is
Exploring Android. Also, it is more of a niche title, as GraphQL
has its fans but is not dominating the Web service space. But, it has the advantage
of being a small self-contained book. Eventually, I will
rewrite this as a second-generation book, but it is not a priority.

This leaves Android���s Architecture Components, and, of course,
The Busy Coder���s Guide to Android Development.

The problems with The Busy Coder���s Guide to Android Development are its size and
age. It will take me a few years to upgrade everything in that book to second-generation
approaches, in part because I cannot only do that ��� I need to cover new
material as well. The transition from second-generation material back
to the first-generation stuff would be fairly jarring in one (large)
book. For example, ListView is not that critical anymore, having been supplanted
by RecyclerView, but a lot of my older examples still use ListView. So while
the early chapters of a revised book could skip ListView, I would still need
it somewhere, just so people have the material to understand all those other
samples.
Compounding the problem is that I should be blending in parts of the Architecture
Components into new introductory material, rather than having it all be in a separate book.

This is why I started the Elements series, particularly Elements of Android Jetpack.
And it is why, in early 2019, I will be publishing one final update to
The Busy Coder���s Guide to Android Development and
Android���s Architecture Components, to correct some errata. Beyond that, I will
not be updating those titles, and they will remain first-generation books.

The Android material, though, will get rewritten, so long as there is interest
in my work. It just will go into Elements of Android Jetpack or other second-generation
titles. So, rather than try to monkey-patch these two first-generation books,
I will replace them with newer, better books. Similarly, coverage of new Android
versions, new tools versions, and new library versions will go into second-generation
books.

This is one of the reasons why I want to offer full-text searching across all
of the books. That way, it is easier for you to tap into the knowledge base in
The Busy Coder���s Guide to Android Development for particular topics, while
I progressively offer updated material on those topics.

This is a major change, and one that I take with quite a bit of trepidation. I
think it is the best answer for my subscribers, and I can only hope that I am
correct in my assessment. If you have concerns about this plan, please
let me know.

I mentioned ���so long as there is interest in my work���. Tomorrow, in my final post
of this series, I will explain a bit more what I mean and how you (yes, you!)
can help.

Read Online!

Elements of Kotlin (announced Monday)
and Elements of Android Jetpack (announced yesterday)
are my first two second-generation Android development books. Like my previous
books in the Warescription, subscribers can download these books
in PDF, EPUB, and Kindle/MOBI editions.

They can also read them directly online.

The Warescription site offers both download
and ���read online��� options. The latter brings up the book directly in the browser.
The reader offers:

Forward and back navigation through the major sections of each chapter

Drop-downs to navigate between the chapters and books

This may prove useful directly to some of you. It is also a stepping-stone towards
offering online full-text search across all of the books, which I hope to have up
and running in early 2019.

I will be making the first-generation books available for online reading as well,
but I wanted to start small at the outset.

If you are a subscriber and you run into problems with the online reading
option, let me know!. The more bugs I can
get fixed now, the smoother it will be to offer full-text searching in the future.

Tomorrow, I���ll talk more about those first-generation books, and what my plan is for
them.

"Elements of Android Jetpack" Version 0.1 Released

Subscribers now have
access to Version 0.1 of Elements of Android Jetpack,
in PDF, EPUB, and MOBI/Kindle formats. Just log into
your Warescription page to download it,
or set up an account and subscribe!

As I noted in yesterday���s Elements of Kotlin release,
I am working on books for the second generation of Android app development:

First-generation techniques revolved around the Android Support Library and
were mostly based in Java

Second-generation techniques center on the Jetpack and AndroidX libraries, with
more code written in Kotlin

Elements of Android Jetpack is an introductory book for Android app developers,
with Version 0.1 covering up to some basic UI construction (widgets and ConstraintLayout).
Over the next several months, I will expand it to cover much of the core pieces
of Android app development, as the table of contents illustrates.

Compared with The Busy Coder���s Guide to Android Development,
Elements of Android Jetpack:

Features parallel samples in Java and Kotlin, to help ease the transition to
developers new to both Android and Kotlin

Focuses on the Jetpack components, including relevant bits of the
Architecture Components (e.g., ViewModel, LiveData, Room)

Employs the AndroidX libraries, as opposed to the Android Support Library

Drops most of the legacy stuff: very little on RelativeLayout, ListView, etc.

(of course, a lot of this is still to be done, as this is merely Version 0.1)

Elements of Android Jetpack is my long-term introductory book on
Android app development��� and I���ll talk more about what that means for
The Busy Coder���s Guide to Android Development and
Android���s Architecture Components on Thursday.

If you are already a subscriber, and you have already worked through the core
chapters of The Busy Coder���s Guide to Android Development, Elements of Android Jetpack
is not for you��� yet. Give me a few more months, and there will be a few topics
that might be new for you, such as the Navigation library (if it ships in final form).

In addition to the two new books, subscribers got something else yesterday: a new
way to read the books. I will talk more about that tomorrow.

"Elements of Kotlin" Version 0.1 Released

Subscribers now have
access to Version 0.1 of Elements of Kotlin,
in PDF, EPUB, and MOBI/Kindle formats. Just log into
your Warescription page to download it,
or set up an account and subscribe!

This is my initial book for what I have been calling ���second-generation���
Android app development:

First-generation techniques revolved around the Android Support Library and
were mostly based in Java

Second-generation techniques center on the Jetpack and AndroidX libraries, with
more code written in Kotlin

While there are other books on Kotlin out there, I wanted to ensure that subscribers
had access to one. As the book evolves, you will see that I���m also taking some
different approaches towards covering Kotlin.

Part of that is because while I appreciate Kotlin as a programmer, as an educator
I find Kotlin to be very ���busy���. It has lots of keywords, lots of syntax rules,
and lots of specialized capabilities.

From what I can tell, most of that complexity is there to allow simple Kotlin to
be as simple as it is, and to allow library developers to offer similarly simple
APIs. This is wonderful for experts, and the results are wonderful for everyone.
However, the vast majority of developers are not writing libraries ��� they
are the consumers of sophisticated APIs, not the producers. As
a result, a lot of Kotlin seems to fall into YAGNI (You Aren���t Going to Need It)
for ordinary developers.

But, along the way, they may wind up seeing aspects of complex Kotlin and have
to make sense of it.

For example, the kotlinx.html library
offers a DSL for HTML generation. With that DSL, you can do stuff like this:

val docs = "https://kotlinlang.org/docs/reference..."

val div = document.create.div("my-css-class") {
p {
+"This is preceded by a unary plus operator. "
a(docs) { +"(no, seriously)" }
}
}

Is having a unary-plus operator (+foo) unreasonable? No. Is offering operator
overloading unreasonable? No. Is allowing the unary-plus operator be overloaded
for String unreasonable? No.

But the result (+"huh?") winds up being something that an ordinary developer is likely to
to respond with ���Kotlin, WTF?���. As an educator, I dread languages that make
learners go ���WTF?���.

(plenty of things in Android app development cause developers to say ���WTF?��� ���
I don���t need a language adding to the pile of sources of ���WTF?���)

My objectives with Elements of Kotlin are:

Help developers be able to read any Kotlin that they might encounter

Help developers be able to write ordinary Kotlin

Help curious developers discover what some of that unusual syntax or keywords are called, in case
they wish to dive more deeply into how to use it for their own work

Some of this will involve finding ways to help developers find out the terms
behind some of this syntax. Searching Google for kotlin +,
for example, does not help much.

Right now, in Version 0.1, the book covers a lot of the core Kotlin syntax and
features. There are a few core items that I need to get into, such as coroutines
and Java interoperability. But a lot of what remains is covering the ���WTF?��� ���
I am expecting 40+ short chapters on things like:

Why is a certain generic declared out? Is this a baseball thing?

What is reified? Does that imply that originally the code was only ified, and
we did something a second time to make it be reified?

Is crossinline some form of 1990���s ���eXtreme��� type of inline? And what does inline skating have to do with Kotlin, anyway?

And so on

Over the next several months, I will build to a Version 1.0 that covers everything
in Kotlin 1.3. After that, updates will proceed largely based on new Kotlin releases.

Subscribers will also notice a few other new things in the Warescription. I will
be explaining what else is new, and the plan for the Warescription, over the course
of this week.

WorkManager, App Widgets, and the Cost of Side Effects

WorkManager is ���a nice piece of kit���. It has a
fairly clean and easy API and hides a lot of the complexity of scheduling
background work that is not time-sensitive.

However, it has side effects.

To be able to restart your scheduled work after a reboot, WorkManager registers
an ACTION_BOOT_COMPLETED receiver named androidx.work.impl.background.systemalarm.RescheduleReceiver.
To be a good citizen, WorkManager only enables that receiver when you have
relevant work and disables it otherwise. That way, your app does not unnecessarily
slow down the boot process if there is no reason for your app to get control at
boot time.

However, enabling and disabling a component, such as a receiver, triggers an
ACTION_PACKAGE_CHANGED broadcast. Few apps directly have any code that watches
for this broadcast, let alone would be harmed by having that broadcast be sent
more times that might otherwise be necessary.

App widgets, though, are affected by ACTION_PACKAGE_CHANGED. Specifically,
ACTION_PACKAGE_CHANGED triggers an onUpdate() call to your AppWidgetProvider.

That too may not be a problem for most app widgets. Ideally, your AppWidgetProvider
makes no assumptions about when, or how frequently, it gets called with onUpdate().

This bug report points out one
area where this is a problem: with an AppWidgetProvider scheduling work
in onUpdate(). The flow then becomes:

A ���regular��� onUpdate() call comes in
Your AppWidgetProvider schedules some work with WorkManager
WorkManager enables RescheduleReceiver
That triggers ACTION_PACKAGE_CHANGED, which triggers an onUpdate() call
Your AppWidgetProvider schedules some work with WorkManager again
WorkManager eventually gets through those two pieces of work
WorkManager disables RescheduleReceiver, since it is no longer needed
That triggers ACTION_PACKAGE_CHANGED, which triggers an onUpdate() call
Your AppWidgetProvider schedules some work with WorkManager
WorkManager enables RescheduleReceiver
And we���re in an infinite loop

The recommendation from Google is
to avoid unconditionally scheduling work with WorkManager from onUpdate().
Instead, only do it if you know that the work is needed and that it is safe to do
so, meaning that you will not get into the infinite loop.

That advice may be difficult for some to implement.

Beyond that, WorkManager is the one causing the side effect. In principle,
WorkManager should provide options to avoid or manage that side effect.
Side effects from libraries are ���negative externalities���, to use an economics term.
They are like pollution: the developer of the library does not bear the cost, whereas
users of the library do, and sometimes users of the apps using the library do.
If your library has the potential for side effects, be sure to document those
side effects and, to the greatest extent possible, give ways for developers
to manage or mitigate the side effects.

IOW, library developers need to ���give a hoot ��� don���t pollute���.

Reference Platforms, Please!

Maybe you work at a device manufacturer that has come up with a new form factor
for Android. Perhaps you have a spherical display, or a display that is a
M��bius strip, or something like
that. You are working with Google to ensure that Android has first-class support
for your new form factor, addressing tough questions like ���where do the status
bar and nav bar go when the screen has no edges?���.

Eventually, you���re probably going to want apps on those devices, beyond those
that your staff and your contracted partners create to show off your edgeless
displays.

The problem is that Android apps might not work well on your form factor ���out of the box���.
You need to decide how to handle that scenario.

One option is to go with an opt-in model. Apps distributed through the Play Store
are not eligible for your form factor unless they do something to say that they
should be compatible with edgeless displays. For example, they might need a
<uses-feature android:name="android.hardware.screen.edgeless" /> element in their
manifest. The good news is that developers are unlikely to opt into your form
factor without having tested it. The bad news is that few developers will do so
quickly, meaning that your form factor���s corner of the Play Store will be rather
empty.

But if you want to say that all apps on the Play Store are automatically available
for your form factor, it is incumbent on you to ensure that every developer is
in position to test on that form factor. Otherwise, you are just hoping that
your own compatibility testing is sufficient and that users will not be faced
with lots of apps that fail on your edgeless display for one reason or another.

You might offer an emulator, either something custom-made or perhaps an emulator image
for the standard Android SDK emulator. That is better than nothing. However,
emulators only emulate so well. Given that most desktop and notebook screens are
neither spherical nor M��bius strips, they will have difficulty representing
your form factor well, even in an emulated fashion. While this might be part
of your developer support plan, it cannot be the only option.

Of course, you could hope that developers are so enamored with your edgeless displays
that they pay the 1,770 USD price tag
for one of their own. Frankly, that is unrealistic and somewhat exclusionary
(���we only want rich developers!���).

Ideally, you would release a reference platform for that form factor. It would be
reasonably priced and show off the critical feature but perhaps is not something
that most consumers would want. For example, it would need your edgeless display, but
you might go with cheap camera modules and offer only modest RAM and storage.
Instead of a case made of gold-pressed latinum
the way your high-end device is, perhaps the reference platform is just plastic.
You might even skip the headphone jack. For the purposes of many developers, these
cost-cutting measures do not matter all that much, as the developers��� goal is
to confirm that their apps can ���go edgeless��� and delight your users. And, sure,
some consumers will snap up a reference platform device on eBay, but few of them
are likely to have spent the money for the high-end device anyway.

If reviewers and consumers conclude that your device is cool but has few apps
that work well on it, that is going to depress sales of your device and cast doubt
on the form factor overall. Form factors are tough sells to developers ��� for example,
Google���s biggest TV success is the one that didn���t involve apps on a new form factor (Chromecast).
Releasing a new form factor without a clear plan for ensuring that any developer
can test on that form factor is going to be trouble.

Regardless, I wish you luck with your new form factor!

Unless yours involves a
screenless device that users interact with via a series of high-pitched whistles.
I draw the line there.

Foldables and Developers

As you probably heard, Google has announced
official support for ���foldable��� phones.
You can unfold a foldable phopne and have access to a larger touchscreen,
but still have access to a smaller touchscreen when the phone is folded. That announcement
ties into Samsung���s shrouded unveiling of a foldable phone,
scheduled to be released in 2019. Lots of excited noises came out of the
Android Developer Summit about foldables, as Google tries to get developers
interested in YAFF (Yet Another Form Factor).

Google has gone the YAFF route previously, of course:

Chrome OS
Android Things
Android Auto
Android TV
Android Wear/WearOS
Google TV
Tablets

On the whole, app developers have not paid a lot of attention to YAFFs. Big-brand
apps are more likely to support more YAFFs, because with a huge user base they will
have quite a few users on all of these (except long-dead Google TV). Certain apps
might get support for certain YAFFs, as the form factor lends itself to that
particular app���s category (e.g., jogging apps for wearables, streaming media players
for TVs). Overall, though, for YAFFs where developers need to opt into being available (TV, wearables,
cars, things), few developers bother. For YAFFs where developers need to opt out
(tablets, Chrome OS, and soon foldables), few developers bother with that either,
but also do not necessarily take steps to ensure that their apps work well on
those YAFFs.

IMHO, the foldable YAFF is unlikely to change that, for a few reasons:

It is not different enough for many apps to want to target it specifically.
Whereas wearables, cars, and TVs have affinities for certain app types, phones
and tablets are more ���general purpose���. A phone that can transmogrify into a small
tablet is still a general-purpose device. Off the top of my head, I cannot think
of an app category that would be specifically useful for a foldable but not
for a regular tablet or Chrome OS device. As a result, few developers will race
towards foldables to be ���a big fish in a small pond��� with apps specifically aimed
for foldables.

Foldables are likely to be expensive in the short term. I cannot imagine that Samsung will
sell theirs for less than they sell their current flagship devices, at least at
the outset. As a result, I am expecting prices to be 1200 USD or higher. Eventually,
perhaps foldables will become common enough that they become a standard feature
of flagship devices. With luck, foldables will become commonplace and available
at lower price points. However, in 2019 and 2020, I expect foldables to be pricey.

Foldables might be marketed as luxuries in the short term. Foldables are
bling. Nobody is going to look at a car and say, ���Wow! That���s a really cool
container for Android Auto!���. By contrast, foldables are the sort of thing
that people will pull out of their pocket/purse/pouch/pontoon just for the sake
of showing off. Samsung, in particular, might lean into this approach, specifically
pricing their foldable very high and skipping any carrier marketing deals, with
an eye towards having their foldable become a status symbol.

Foldables are likely to be a small niche in the short term. There are tens
of millions of users of Chrome OS and Android tablets��� and lots of
app developers yawn at those figures. It will be a wonderful day when we can
say that there are tens of millions of users of foldables. Depending on pricing
and marketing, in 2019 and 2020, it might be closer to tens of thousands of users
of foldables. As such, as Gertrude Stein once wrote of the city of Oakland,
���there���s no there there��� ��� few developers will be inspired to support foldables
when there are so few users.

The good news is that supporting foldables is likely to be not that different
than supporting multi-window and configuration changes in general.
It appears that we will simply get a configuration change for a new screen
size (and perhaps density) when the device moves from a folded to an unfolded
state. We already should be dealing with that for existing form factors ��� the
foldable YAFF just adds a few more users that would benefit from our work.
If anything, Samsung���s foldable might be simpler than scenarios like Chrome OS,
as it appears that Samsung is going to limit the number of simultaneous
windows (3 at a time, based on their initial statements).

Foldables might cause other headaches ��� Samsung���s device has an unusual
21:9 aspect ratio when folded ��� but these are headaches that we have had to
deal with from time to time for years. The fewer assumptions that you make
about the device that you run on, the more likely it is that your app will
hold up nicely, even when faced with strange device specifications.

It appears that the way that Android is going to handle foldables from an architecture
standpoint is to consider them as having two displays, with activities moving
from one display to another when unfolded. We have had support for this sort
of behavior since Android 8.0, though it has not been that widely used. However,
this puts additional pressure on developers to do the right thing: if it involves
your UI, always get the information from an Activity. In particular, do not
work with resources, Display, or similar objects that you get from an Application
singleton. The Activity knows which display it is on and will give you the
right resources and display metrics for that display. Application, by constrast,
will only know to use the default display (whatever that default might be), which
may be substantially different than the display that your Activity appears on.

I am somewhat nervous about ���multi-resume���. With current multi-window support
on Android, only the window that the user is interacting with is considered
to be resumed. All other windows, and their top-most activities, are paused.
With ���multi-resume���, that distinction vanishes: all windows��� top-most activities
are resumed. This is an opt-in behavior for Android 9.0 ��� both the manufacturer
and the developer (via a manifest <meta-data> element) have to agree to
allow for multi-resume. However, in an Android Developer Summit presentation,
Google indicated that they expect this to be mandatory in Android Q. This will
introduce more weird edge cases that we have to deal with, and it does not appear
to be really tied to foldables at all.

It is possible that, in the long term, we will look back on the days with rigid
non-folding displays the same way that we look back on CRT monitors, dot-matrix
printers, and dial-up Internet access. Near-term, foldables are unlikely to
���move the needle��� much in terms of the characteristics of the Android user base.
However, foldables are yet another reason to try to support a wider range
of Android devices than simple phones, and the work that you might do with foldables
in mind will help many more users than just those who elect to buy a foldable.

New Warescription Site

A quick note for subscribers: the Warescription site
is now on a new server and a from-scratch rewite of the Web app.

Right now, subscribers will not see a lot of benefits from the new Web app.
However, after about 5 years of code cruft buildup, I needed to rewrite it to have a
stable base going forward for new features. This also was a fine opportunity to upgrade
the tech stack, including Bootstrap 4 and Kotlin.

I have a few small bugs to work out (courtesy of 10 years��� worth of database cruft).
If you run into any problems with the site, let me know!.