MSP's four helicopters:

• N822PP
• N823JM
• N824AH
• N825MM

And the four victims of the 1995 crash in Cambridge?

• MSP Trooper Paul Perry (PP)
• MSP Trooper James Mattaliano (JM)
• AT&T Technician Arthur Howell (AH)
• AT&T Technician Michael McCarthy (MM)

Confusingly, at least for someone like me not too familiar with the exact area, the helicopter (N20SP) crashed onto Harvard University's Sailing Pavilion, but MIT's rescue team was first to arrive as they were training across the street.

In the worst PR move in history, Harvard sought damages from the state for damage to its boathouse, citing "negligence of the Mass. State Police."

The idea is that there's a chip on the batteries giving them some "smarts." Particularly in the days of Ni-Cd batteries, their "reconditioning" step could help minimize the impact of the memory effect, with the charger periodically running the battery down all the way and then refilling it.

It turns out there's a lot more going on behind the scenes. During the reconditioning step, the charger also keeps track of how much of a charge the battery takes and calculates what percentage of its rated capacity remains. Some of the fancier gang chargers have LCDs and will display this information, but even the simpler chargers will start giving you a flashing red-and-green light to let you know the battery is wearing out. It seems like the "killer app" here is public safety applications–it's a minor annoyance for me if a radio I'm effectively using as a scanner starts to only last a few hours before I have to swap batteries. But for something like law enforcement, being able to know whether your battery will last your full shift seems like a much bigger deal.

I recently picked up an Impres "Battery Data Reader," which looks a lot like a standard charger, but it has a USB port on the back and doesn't charge. It reports data like this:

This is the case of a totally dead battery, and which seems to have suffered some data corruption. (Not a great example, Matt!) The red/pink fields couldn't be read due to corruption, but we can see that the battery was rated for 2100 mAh, but now only supports a "potential capacity" of 474 mAh.

It also reveals that Motorola's "rated capacity" is actually conservatively rated; it's apparently the minimum spec for warranty purposes. This one apparently took 2781 mAh when it first went into use (April 10th, 2014).

Reading a bit about this and the extended user guide, the battery also has a real-time clock and some memory. It appears that the clock is set at the factory and only needs to be accurate to within months, so periodic syncing isn't supported (AFAICT), except for the special case when the battery has been "overdischarged" and, I infer, the RTC stops ticking. The reader is seemingly the only way to reset it.

The memory supports more than just a simple count of charge cycles; it differentiates Impres from non-Impres cycles, and even keeps a histogram of the battery's charge level when first inserted into the charger:

You can see that this one tended to be put back in the charger when it was still 50-60% full. I'm not sure what you're supposed to do with that data; the whole idea of Impres batteries is that you shouldn't need to run the batteries out before charging them. This particularly battery looks like (based on its labels) like it came out of a prison facility; perhaps what the graph shows is that the battery was typically listing more than a shift, with the user presumably dropping it in a charger at the end of the day with 50-60% charge still left?

I've learned from reading a bit that the "potential capacity" (474 mAh in this case) is computed when the radio goes through a reconditioning cycle, and is used by the "fuel gauge" on radios to show how full the battery is. This also matches my experience with some old batteries that came from a lot of radios I bought at a hamfest–capacity indications were all over the place until a few conditioning cycles.

Also interesting–at least to me–the application keeps a running CSV file of everything it reads. It'd be interesting to write a little app that would take that file and track this data over time.

As an aside, the gang chargers have what's apparently an HD15 port on the back (which looks suspiciously like, but is not, a VGA port). There's not a whole lot of information out there except for this Batboard thread about it. There's apparently this adapter for it that will hook up to a PC, which can integrate with their "Fleet Management Software." The Impres reader app also supports sending data there. It appears that there's a trial at https://www.motorolasolutions.com/en_us/products/two-way-radio-accessories/batteries/impres.html, but what I'm really interested in is what's reported off the back of the charger. You could rig up something with a Raspberry Pi to grab the data without all this stuff?

In conclusion, I lead a pretty exciting life.

This is a published work in progress.

I was recently asked to help with a RISC project. After wondering if that meant I'd finally get a SPARCstation, I was relieved to learn that the acronym now refers to Risk Incident Sharing and Coordination at the OpenID foundation.

My relief soon turned to panic as I saw how ethereal and acronym-heavy the available documentation was. RISC is one of two applications implementing SSE (Shared Signals and Events), the other being CAEP (Continuous Access Evaluation Protocol). It describes a framework for Transmitters to send information about Events about Subjects to Receivers, over a Stream. The "streams" are formatted as SETs (Security Event Tokens), which are implemented as JWTs. Quoting the RFC, "A SET describes statements of fact from the perspective of an issuer about a subject.  These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject."

Any remaining questions you have can be answered by the RFCs.

Unless your question is, "Huh?", which is where I found myself. Maybe we can figure this out together.

Google Does It

Google implements this as Cross-Account Protection, and provides a succinct introduction that's helpful.

So let's start somewhere nice and concrete. We use Gmail / Google Apps for email at work. Beyond email, the Google account is used for authentication, via their Sign in With Google feature. Logging into our software for scheduling interviews, for example, I just sign in with Google. A lot of other software works the same way.

But what if my Google account was compromised? Sure, IT at work can lock the account or force a password reset–after I figure out how to contact them without being able to look up their info in my email account. But what about all the SaaS services I've logged into?

Sites using Sign In With Google (aka Google Identity) can request that Google notify them via a webhook of important security events. For example:

• If a Google account is compromised, a site can expire that user's session cookies in our app.
• If Google closes the account for being a spammer, we can get an account-disabled event with the reason=bulk-account attribute set, and we probably want to do something on our side to see if they're sending spam in our app.

And suddenly, this all feels less ethereal. Google even calls out near the top that this is an implementation of RISC. Those webhooks/callbacks are the Security Event Tokens, submitted to a Receiver endpoint.

This also helps me understand something else: what stops me from creating a malicious Receiver and requesting notice of what happens with all Google accounts? Isn't this a security risk?

It's not actually addressed, but the concrete example makes this easier to reason about. If I implement Sign In With Google on my site, Google already knows who's used Google to log into my site. It would only be reasonable for them to ignore requests for events concerning unrelated third parties.

Microsoft does it

We saw RISC at Google. Microsoft's Azure AD implements the other half of SSE, the Continuous Access Evaluation Protocol.

.gov does it

login.gov, providing OpenID Connect access to various government sites, also implements Security Events – bidirectionally. Sites using login.gov can receive SETs, but they also accept incoming events. (One presumes a greater degree of trust exists between .gov sites than with random sites letting people log in via Google.)

Event Types

The full list of supported event types in RISC is here:

Anyway, here's Wonderwall. Err, an almost-2-hour Smashing Pumpkins concert from 1993:

As someone who generally resents the live version of songs, this whole set is a rare exception. In particular, the version of Starla here is incomprehensibly better.

Delightfully, the concert opens with Rocket, one of my favorites but for some reason not a chart-topper. It also led to me discovering the charming story behind Spaceboy, which is really relatable for me.

As an aside, the explanation for Hummer I've since learned makes me laugh. Lots of theories have been advanced for what it might mean for someone to be "a hummer," and the answer is delightfully matter-of-fact:

Ever since I wrote that song I’ve heard many definitions for the word 'hummer'. I’ve heard that there’s a car called a Hummer, I heard that Monica gave Bill a hummer in the White House, but quite honestly in my innocent youth, I  imagined it being someone who just walked around humming a song to himself.

OpenWeather

Сurrent weather and forecast - OpenWeatherMap

Get current weather, hourly forecast, daily forecast for 16 days, and 3-hourly forecast 5 days for your city. Historical weather data for 40 years back for any coordinate. Helpful stats, graphics, and this day in history charts are available for your reference. Interactive maps show precipitation, c…

OpenWeatherMap.orgOpenWeatherMap

Registration is required, but their free plan allows 60 API calls a minute, up to a million a month. They have a current weather API, air pollution API, and a "One Call" API that returns current weather and a forecast.

They also implement a Geocoding API, which supports forward and reverse geocoding. This is useful for when you want to allow app users to put in, say, "Boston" and see weather, which is often best done with lat and long. (Their current weather API has some support for cities, though.)

Nominatim

OpenStreetMap's Nominatim is a free (no registration required) geocoding API based on the OpenStreetMap dataset. Do see the usage policy before hammering the API.

The neat thing is that, because it's based on, you know, Open Street Maps, they don't have the goofy "no caching allowed!" requirements that some other applications do. In fact, you can run your own Nominatim server, but it requires some beefy hardware since it's got an enormous database. But the ability is pretty nifty nonetheless.

The idea is useful: the CPAP machine can display a QR code on-screen which you can scan with a mobile app. Neat!

The app has terrible ratings, and they are deserved. It shows only very basic information; a nightly average. More baffling, although there's an "Upload" tab, there is no apparent way to actually upload the results anywhere.

Frustrated by the only-marginally-useful mobile app, and the fact that none of their software could read the data on the SD card, my doctor found some information and gave me a printout steering me to iCodeConnect (also stylized as ICODECONNECT which is how I have started referring to it, because it's impossible to discuss without screaming about it).

The instructions suggest to click "Quick Report" on the main page. Doing so brings up a page asking for a ton of information, and noting, in bold:

It is strongly recommended that you sign up for a provider account on iCodeConnect so that all of your data will be preserved and accessible from anywhere.

Signing up for a provider account required me to designate a HIPAA compliance officer (I nominated myself). This got my account rejected, with a note that patients are not allowed to register accounts.

On the "Quick report generator," it appears that basically all of the information you input is just displayed back to you. There is no apparent purpose to filling in any of your information, much less your provider or physician information, except that it will display on the next page.

And then there's this box at the bottom:

You would think you would select iCode, but this results in a comically bad experience. You are expected to type in the strings that appear on the CPAP's screen.

What you actually want to do: turn off the CPAP machine, remove the SD card ("chip"), insert it into your computer (if you have an adapter), and then press "SD card" instead of the default "iCode". This will allow you to select a file with a .USR extension on the SD card.

(Aside: the .USR file on the SD card is only 1MB for me; maybe it will expand with usage, but I suspect it's actually a circular log and will always be 1MB. In that case, a tech-savvy patient could email the .USR file to their doctor directly, rather than dealing with the SD card itself.)

You'll probably want to change the "Select date range" bit to "Select all days with data" or something useful like that, because the default appears to only be the current day.

At the bottom of that page, it displays a helpful daily chart of how your sleep went. This is what I was after, and it seems this data is only accessible from the SD card.

Now this is useful! It shows I started around midnight, at the starting 5 cmH₂O, climbing slowly over the night and peaking around 8. But more interesting:

• Several times, especially around 2-3am, I had several apnea events.
• Around 6am (and a bit earlier), the mask leaked a lot. I probably rolled over and had it come off in my sleep.

Note that the bars for apnea (red) and hypopnea (orange) are not too easily distinguished. Also, because I had to look it up:

• Apnea is loosely defined as when you stop breathing; we probably know this since we've been diagnosed with sleep apnea. The textbook definition is apparently that your airflow is reduced at least 90% for 10 seconds or more.
• Hypopnea is a lesser version: your airflow is reduced at least 30%, but less than 90%, or it would be apnea. WebMD refers to it as "shallow breaths." Like apnea, it must last at least 10 seconds.

(I presume the 10-second limit is less that a 9.9-second cessation of breathing doesn't matter, and more that your respiration rate while sleeping is pretty low, so going a few seconds without breathing is normal.)

There's a Windows software app for these called RESmart, which seems to cover machines made by both BMC and B3. It's available through ApneaBoard.com; not sure if it's available from a more official source or not. It is similarly clunky to use, but something it shows that the iCode Connect site doesn't is a breathing/airflow chart. It makes individual apneic episodes a lot more visible.

You don't have permission to access "http://www.gap.com/" on this server.

Reference #18.c6a50517.1514639126.176b29a

There are several garbage articles out there talking about this without any indication of what is actually generating this error message.

This Microsoft TechNet post reveals the answer: it comes from the Akamai CDN, a content delivery network used by large sites to speed them up.

Akamai has a helpdesk article about this, including a link to their Client Reputation lookup tool.

Microsoft, which apparently also uses Akamai, has a post of their own about it, noting:

This issue occurs because of the measures that Akamai has implemented to protect its websites from denial-of-service attacks. If a single origin or source tries to connect too frequently, these measures automatically block any IP addresses from that origin or source.

The blockage is usually temporary. As soon as the connection volume remains below the defined thresholds for a while, the block on the affected TCP/IP address is expected to be removed.

From the posts I've seen, it is perhaps a touch too sensitive and sometimes blocks legitimate users. (Perhaps triggered by rapidly opening multiple links in tabs, or multiple people in the same household browsing concurrently?) The fix is to simply wait a bit and try again, though.

“Always remember that it’s much easier to apologize than to get permission,” she said. “In this world of computers, the best thing to do is to do it.”

Her point, of course, was about avoiding bureaucracy while doing good, not about taking liberties with ethics. Especially in large organizations, I think this can be helpful advice, at least when employed with care.

Towards the end of this Repeater Builder article on NOAA weather radio is hidden an absolute gem. While it's astute advice on dealing with the Federal Communications Commission, it almost seems to double as a life lesson. Credit for the below goes to Mike, WA6ILQ.

First, he sets some good background on how the amateur radio service is regulated:

Second, please note that the USA FCC rules for ham radio are written very, very differently than any other portion of the FCC's rules. In fact, amateur radio, part 97, could have been written by a different person (or team).

In broadcast, land mobile (i.e. commercial / business 2-way), GMRS, marine radio, forestry, aircraft, paging, public safety (police, fire, etc)  and all the other services their rules are written in the format of "you can do X, you can do Y, you can do Z", and that's it. The FCC has to be petitioned for permission to do anything else.

[snip]

On the other hand the amateur rules are written in the reverse format of "you can't do A, you can't do B, you can't do C". And the amateur rules - part 97 - is the ONLY section of the FCC rules that is written that way. NO PETITION IS REQUIRED for permission to do anything else.

In other words the hams can do D, E, F, G, H, etc. without asking and we can't afford to lose this privilege. This is how innovation happens - like RTTY, FSTV (ATV), SSTV, packet, PSK, AX.25, APRS, IRLP, etc. Rule change petitions are required only if the hams want changes to A, B or C.

And then, he brings it home:

On the other hand, if you ask in advance some low level FCC flunkie will be told to send you a letter that covers everybody's ass by saying DON'T - because every other part of the FCC rules that they deal with every day is full of Thou Shalt Nots, and their day-to-day mindset is such that they can't comprehend anything else.

I repeat - the amateur radio service is the only one where the rules say "You can't do A, B or C and you CAN do anything else". The average FCC flunkie that spends their whole career handling broadcast, land mobile, public safety, aircraft, forestry, business, public safety, pagers or cellphones totally forgets that.

But from then on that "DON'T" letter becomes official policy and can be referred to in future cases - something that anybody else at the FCC can point to from the time that said flunkie wrote that letter onwards. And only because you just had to ask all hams lose one more privilege.

In short: asking permission unnecessarily can hurt not just you, but also risk establishing a bad precedent. If what you're doing is ethical and easily explained, it's better to just do it.

With that in mind, I'm going to start a series of posts with nifty things I learn about using RubyMine. (Most should probably transfer to other IntelliJ-based IDEs like PhpStorm.) Up first: Bookmarks.

I've often abused the ability to set breakpoints in the margins as a way to dog-ear the page of something I know I want to come back to:

The problem is that (1) this isn't what breakpoints are for, and (2) they're not particularly easy to find again. (Run > View Breakpoints will get you there, though.)

The right way to do this is with bookmarks!

These can be set by right-clicking in the margin and selecting "Set Bookmark", or by simply pressing F3 on your keyboard.

Then, Navigate > Bookmarks gives you a variety of options for viewing or cycling through bookmarks.

% dig app.circleci.com
; <<>> DiG 9.10.6 <<>> app.circleci.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10705
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;app.circleci.com.		IN	A
;; AUTHORITY SECTION:
circleci.com.		181	IN	SOA	ns-1572.awsdns-04.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 89 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Mar 11 15:43:15 EST 2021
;; MSG SIZE  rcvd: 129

The response that comes back shows NOERROR as a status, but there's no A record returned like I asked for. Instead, there's an unsolicited SOA record. Why is there an SOA record? And why NOERROR instead of NXDOMAIN like I'd expect?

It turns out that NXDOMAIN means the record (app.circleci.com here) doesn't exist. In this case, though, apparently it does exist; it just doesn't have an A record.

A missing A record is kind of a weird case; this all makes more sense with, say, an MX record:

% dig -t MX www.google.com

; <<>> DiG 9.10.6 <<>> -t MX www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60708
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.google.com.			IN	MX

;; AUTHORITY SECTION:
google.com.		60	IN	SOA	ns1.google.com. dns-admin.google.com. 362007607 900 900 1800 60

;; Query time: 75 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Mar 11 18:07:13 EST 2021
;; MSG SIZE  rcvd: 93

Of course www.google.com exists, so returning an NXDOMAIN in response to our query asking for an MX record would be incorrect. Instead, the response shows ANSWER: 0 because there are no MX records to return, and ADDITIONAL: 1 for the unsolicited SOA record. Because the query completed successfully, the status is set to NOERROR.

The same thing is happening with CircleCI's broken DNS when we try to find an address record. Arguably, the lack of an A record for a production website is a big error, but the DNS server cannot prognosticate about the state of the world. It's been incorrectly told that app.circleci.com exists, but doesn't have an A record, and the response reflects that.

wait, people use programming to SOLVE problems?!?!

— Yoz Grahame (@yoz) March 11, 2021

I'm extremely late to the party on this one, but this is ❤️.

And someone else put together a transcript here.

I spent a bit going through some lists and wrote a script to run scrape requests against them. I eliminated the ones that often failed to respond; some were unreliable and some just don't seem to exist anymore.

A few things to note first:

• I genuinely don't recommend using any of these for doing anything illegal. Public trackers are low-hanging fruit for lawyers to find copyright infringers.
• All of these are UDP-based. This was not intentional–I included both HTTP-based and UDP-based trackers. None of the HTTP-based ones responded reliably or could meet the 2-second timeout my script imposed. UDP is faster for you and less overhead for the tracker operators.
• I strongly recommend enabling peer exchange (PEX) and distributed hash table (DHT) to find more peers. I have seen cases where most of my peers in a swarm were located this way.
• Most UDP tracker URLs are typically shown with /announce on the end. It is unused! BEP41 would give it meaning, but it's not necessary for announce URLs. I've omitted it because it serves no purpose.

In the list below, I show the sum of peers returned from a handful of queries. As an absolute number, it's meaningless; it's a sampling of some random content. But it's useful as a relative metric. Here is the list, sorted from most peers to least:

1. udp://tracker.opentrackr.org:1337 – 4,441 peers for the searches I ran. Public stats show that it's handling something like 300,000 connections per second, which is bonkers. Apparently located in the Netherlands.
2. udp://tracker.internetwarriors.net:1337 – 2,773 peers. Apparently located in Chile.
3. udp://exodus.desync.com:6969 – 2,169 peers. Apparently located in USA.
4. udp://tracker.cyberia.is:6969 – 1,944 peers. Website. Apparently located in Ukraine.
5. udp://opentracker.i2p.rocks:6969 – 820 peers. Apparently located in the US.
6. udp://explodie.org:6969 – 764 peers. Website. Apparently located in the US.
7. udp://open.stealth.si:80 – 223 peers. Apparently located in Norway.
8. udp://tracker.tiny-vps.com:6969 – 210 peers. Apparently located in Russia.
9. udp://tracker.torrent.eu.org:451 – 200 peers. Apparently located in France.
10. udp://retracker.lanta-net.ru:2710 – 197 peers. Apparently located in Russia.

I found more, but they're all at less than 5% the number of peers discovered in my queries than the #1 entry so I don't find them particularly useful.