I learned this was called a Koopa Clown Car while searching for “bowser in his teacup”. About 20” tall.
]]>Historically, Sync has only officially supported Google Spanner as a storage backend, with MySQL working unofficially. That has been a pretty high barrier to entry for people self-hosting their own services.
With PostgreSQL support, we hope to make self-hosting more approachable and continue supporting people who want the agency of hosting their data on infrastructure they control.
There is updated documentation for running it with Docker, including a one-shot docker compose setup:
https://mozilla-services.github.io/syncstorage-rs/how-to/how-to-run-with-docker.html
Mozilla is publishing Docker images for the PostgreSQL build here:
https://ghcr.io/mozilla-services/syncstorage-rs/syncstorage-rs-postgres
If you’ve been interested in self-hosting Sync but were put off by the storage requirements, take another look. If you run into bugs or have feedback, please file issues here:
]]>Within “interactive entertainment”, we can divide things into four forms – patterns of design that, in theory, work in a certain way.
A friend told me about this theory of game forms months ago, and we eventually tracked down the source: Keith Burgan. Keith also talks more in depth about contests on his blog.
Simple examples my friend and I talked about:
We found other taxonomies but I like the simplicity of Keith’s.
]]>Anyway, I’ve decided to decline these new terms and delete my Nixplay account.
However, I don’t want to lose the functionality of the hardware. Yo-less
uploaded a detailed video on youtube demonstrating how to jailbreak the
Nixplay frame. The process
seemed straightforward, involving nothing more than plugging a cord into a W10E
frame and connecting to adbd. I found that the process for the older W10P
model was not as seamless. Since I spent a chunk my weekend working through
this, I wanted to document the steps here to help others who may face similar
issues.
The good news: You don’t have to take your frame apart at all. Both the USB port and the reset button are accessible externally.
The bad news: Unfortunately, the firmware does not include the adbd
executable in the system image, so it’s not immediately possible to connect to
the frame using adb. I am using macOS for this process, and when first
plugging in the frame, it does not show up in the system by default:
% brew install usbutils
% lsusb
Bus 000 Device 001: ID 1d6b:XHCI
XHCI
XHCI Linux Foundation USB 3.1 Bus
Hold down the reset button for about 5 seconds and try it again though:
% lsusb
Bus 002 Device 001: ID 2207:310d Fuzhou Rockchip Electronics Co., Ltd. Composite Device
Bus 000 Device 000: ID 2207:310d Fuzhou Rockchip Electronics Co., Ltd. USB 3.1 Bus
Bus 000 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
It lives! At this point, the frame is detected. The screen will go black, and Android tools will not yet be functional, but we can use this bootloader to proceed. Let’s start by getting the necessary tools.
# brew's rkflashtool. Note the syntax is slightly different than linux's...
brew install rkflashtool
# adb & friends
brew install --cask android-platform-tools
I suggest taking a full backup just in case but we actually only need the
system and recovery images. Skip the userdata.img at the end unless you have
a specific need as it takes a couple of hours to run.
#!/bin/bash
# Script courtesy of ChatGPT. Note that if you don't have a `W10P` model frame these offsets might not be right!
# Make sure rkflashtool is in your PATH or use full path
RKFLASHTOOL=rkflashtool
echo "Dumping uboot..."
$RKFLASHTOOL r 0x00002000 0x00002000 > uboot.img
echo "Dumping trust..."
$RKFLASHTOOL r 0x00004000 0x00002000 > trust.img
echo "Dumping misc..."
$RKFLASHTOOL r 0x00006000 0x00002000 > misc.img
echo "Dumping resource..."
$RKFLASHTOOL r 0x00008000 0x00008000 > resource.img
echo "Dumping kernel..."
$RKFLASHTOOL r 0x00010000 0x00006000 > kernel.img
echo "Dumping boot..."
$RKFLASHTOOL r 0x00016000 0x00006000 > boot.img
echo "Dumping recovery..."
$RKFLASHTOOL r 0x0001C000 0x00010000 > recovery.img
echo "Dumping backup..."
$RKFLASHTOOL r 0x0002C000 0x000A0000 > backup.img
echo "Dumping cache..."
$RKFLASHTOOL r 0x000CC000 0x000A0000 > cache.img
echo "Dumping metadata..."
$RKFLASHTOOL r 0x0016C000 0x00008000 > metadata.img
echo "Dumping kpanic..."
$RKFLASHTOOL r 0x00174000 0x00002000 > kpanic.img
echo "Dumping radical_update..."
$RKFLASHTOOL r 0x00176000 0x00020000 > radical_update.img
echo "Dumping keys..."
$RKFLASHTOOL r 0x00196000 0x00008000 > keys.img
echo "Dumping system..."
$RKFLASHTOOL r 0x0019E000 0x00280000 > system.img
echo "Dumping userdata (rest of flash)..."
# adjust length if you know exact remaining size
$RKFLASHTOOL r 0x0041E000 0x00C00000 > userdata.img
echo "All partitions dumped."
The next step is to add the adbd executable, which is missing from the system
image. Fortunately, it exists in the recovery image. I had to use Debian to
manage all the image modification because I didn’t want to fight OS X and ext4.
Here’s how to extract it.
# on debian
mkdir recovery_wd
cd recovery_wd
cp ../recovery.img .
# creates zImage, initrd.img, and bootimg.cfg.
# `apt install abootimg` if you need to
abootimg -x recovery.img
mkdir ramdisk
cd ramdisk
gzip -dc ../initrd.img | cpio -i
# You'll find a copy of `adbd` in /sbin/ but first we'll need to mount the system image so we have a place to put it.
cd ../..
mkdir simg
mount -t ext4 system.img simg
cd simg
# Now you're in the system image we dumped from the frame
mkdir sbin
cd sbin
cp ../../recovery_wd/ramdisk/sbin/adbd .
chmod 755 adbd
cd ../..
sync
umount simg
Now that the system image includes adbd, it’s time to write it back to the frame.
# Write to the system partition
rkflashtool w system < /path/to/system.img
# Reboot
rkflashtool b
At this point adbd is present but not auto-starting. There are multiple
conditions in the system’s init.rc file to start adbd (e.g. on
property:sys.usb.config=adb && property:sys.usb.configfs=1) and presumably one
of those doesn’t get set. I didn’t want to keep chasing this so next we’ll
patch the boot image to just start adbd directly:
# back on debian
mkdir bood_wd
cd boot_wd
cp ../boot.img .
abootimg -x boot.img
mkdir ramdisk
cd ramdisk
gzip -dc ../initrd.img | cpio -i
Add these lines within the existing on boot section of the init.rc above
the class_start default line.
setprop sys.usb.config adb
setprop sys.usb.configfs 1
setprop service.adb.root 1
start adbd
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
write /sys/class/android_usb/android0/enable 1
And then create a new boot image with this change:
find . | cpio -o -H newc | gzip > ../initrd-new.img
cd ..
abootimg --create ../boot-new.img -f bootimg.cfg -k zImage -r initrd-new.img
Transfer the new image to the frame
rkflashtool w boot < boot-new.img
rkflashtool b
After rebooting the frame adbd should fire up. adb commands (and vysor
from the original video) should be able to connect and you can follow the
directions in the video to install the apps you want.
I learned this was called a Koopa Clown Car while searching for “bowser in his teacup”. About 20” tall.
]]>If a system is going to store passwords, best practice is to hash the password with a unique salt per row. When accounts was first built we used an account’s email address as the unique salt for password hashing. This saved a column in the database and some bandwidth but overall I think was a poor idea. It meant people couldn’t re-use their email addresses and it leaves PII sitting around unnecessarily.
Instead, a better idea is just to generate a random salt. We’ve now transitioned Mozilla Accounts to random salts.
Eight years ago Ryan Kelly filed bug 1320222 to review Mozilla Accounts’ client-side key stretching capabilities and sparked a spirited conversation about iterations and the priority of the bug. Overall, this is routine maintenance - we expect any amount of stretching we do will have to be revisited periodically due to hardware improving and the value we choose is a compromise between security and time to login, particularly on older hardware.
Since we were generating new hashes for the random salts already we took the opportunity to increase our PBKDF2 iterations from 1000 to 650000 – a number we’re seeing others in the industry using. This means logging in with slower hardware (like older mobile phones) may be noticeably slower. Below is an excerpt from the analysis we did showing a Macbook from 2007 will take an additional ~3 seconds to log in:
| Key Stretch Iterations | Overhead on 2007 Macbook | Overhead on 2021 MacBook Pro M1 |
|---|---|---|
| 100,000 | 0.4800024 seconds | 0.00000681 seconds |
| 200,000 | 0.9581234 seconds | 0.00000169 seconds |
| 300,000 | 1.4539928 seconds | 0.00000277 seconds |
| 400,000 | 1.9337903 seconds | 0.00029750 seconds |
| 500,000 | 2.4146366 seconds | 0.00079127 seconds |
| 600,000 | 2.9482827 seconds | 0.00112186 seconds |
| 700,000 | 3.3960513 seconds | 0.00117956 seconds |
| 800,000 | 3.8675677 seconds | 0.00117956 seconds |
| 900,000 | 4.3614942 seconds | 0.00141616 seconds |
Dan Schomburg did the heavy lifting to make this a smooth and successful project. He built the v2 system alongside v1 so both hashes are generated simultaneously and if the v2 exists the login system will use that. This lets us roll the feature out slowly and gives us control if we need to disable it or roll back.
We tested the code for several months on our staging server before rolling it out in production. When we did enable it in production it was over the course of several weeks via small percentages while we watched for unintended side-effects and bug reports.
I’m pleased to say everything appers to be working smoothly. As always, if you notice any issues please let us know.
]]>Special thanks to Rob Hudson and Dan Schomburg for thier efforts.
]]>I was going to use TrueCharts’ borg chart but TrueNAS SCALE is phasing out support for charts completely so I opted to install a binary manually and see if a standard approach appears later. It turned out to be pretty straight forward, steps below:
borg-linuxnewer64
builds which are built for Debian 12. I used the latest stable version,
1.2.8./mnt/bin/./mnt/bin/borg -V. If you get an error saying
/mnt/bin/borg: error while loading shared libraries: libz.so.1: failed to
map segment from shared object you need to add a temp directory it can
write to. I made /mnt/tmp and then ran export TMPDIR="/mnt/tmp".Now /mnt/bin/borg -V should work and you can add it to whatever scripts you
use to backup your system. Don’t forget to set the TMPDIR in your scripts too.
Nyan Cat! A classic internet meme. I made this to put over a window. About 30” long and 6” tall.
A small Mario for me and a couple of Links to give away to friends. All about 6” tall because that’s the size scrap I have.
In 2011, when Mozilla Accounts (called “Firefox Accounts” back then) was first built it used BrowserID identity certificates in its authentication model. The BrowserID protocol never took off and Mozilla’s work on it ended in 2016. However, the sync service in Firefox continued to use BrowserID even as OAuth support was added to Mozilla Accounts as an alternative for all other relying parties.
Over time, we recognized BrowserID was becoming a maintenance liability. As a non-standard protocol it created significant complexity in our codebase. Therefore, we decided to migrate the Firefox clients off of it in favor of OAuth.
This was an enormous effort, and while much more could be written about this transition, the main takeaway is that Firefox Sync’s BrowserID support ended with Firefox 78, which shipped in June 2020 and reached its end of life in November 2021.
We’ve been waiting a long time for the usage of Firefox 78 to drop.
Aside from being an ESR version there are a couple of other reasons for its extra longevity:
With Flash now largely obsolete on the web and traffic from older operating systems becoming rarer, we’ve decided that now is the appropriate time to turn off support for this legacy protocol.
To avoid surprises and not leave anyone behind, we attempted to email anyone still using that endpoint earlier this year. We didn’t receive any feedback and we continued with the plan.
Our plan is simple: BrowserID requests are the only traffic hitting our
/v1/certificate/sign endpoint. We’ll begin returning HTTP 404 replies to a
small percentage of traffic from that endpoint and monitor for any issues.
Our testing showed no concerns but it’s challenging to be comprehensive with so
many combinations of browser versions and operating systems. Over the next few
weeks we’ll continue to ramp up the percentage of 404s until we can remove the
endpoint completely and let the traffic bounce off the front-end like any other
404.
Surprise! I’m a few weeks late with this post. We started returning 404s on May 1 and are currently up to ~66% of traffic on that endpoint. So far there haven’t been any unexpected complications. We’ll continue to increase over the next few weeks and aim to have all the code removed this summer.
]]>