FlightAware MLAT Network Announcement

FlightAware ADS-B Flight Tracking
1

Hi everyone,

First, thank you for your support and contributions over the years. We now have (just shy of) 7,500 ground stations sharing data and growing faster than ever. If you haven’t heard, we recently released PiAware 3.0 (>25% better receiver performance, native WiFi support, new maps, and more) and are also open sourcing our Android feeder so the community can benefit from the code even though we are discontinuing support for it.

I’m writing today to discuss an issue with the FlightAware multilateration (MLAT) network. As many of you know, FlightAware not only operates a free MLAT network (currently using 136 top-of-the-line Xeon CPUs covering 113 geographic regions) for all PiAwares and FlightFeeders, but FlightAware also feeds back all the MLAT calculations that you’ve contributed to. This means that you can view the data locally on your dump1090 web interface or any other tools you have connected to your receiver. We’re the only ones that do this and it’s awesome.

Unfortunately, a very small percentage of users are re-distributing and aggregating FlightAware’s MLAT calculations, often for the purpose of tracking aircraft that have specifically requested not to be tracked and are on one or more “block lists” used by the flight tracking industry.

As a result, we have come under pressure from aircraft operators with legitimate security concerns to stop feeding MLAT data back or remove their aircraft from the feed. Specifically, a lot of the concern originates from law enforcement, military, and other government operators that appreciate our cooperation, but will otherwise solve the problem with legislation and law enforcement, impacting FlightAware and everyone else, possibly criminalizing this otherwise fun and harmless activity

We would like to solve this together as a community rather than have the government solve it for us. So, we’ve come up with a better alternative – for the small number of aircraft on this list (less than 1% of flights, most of which are in the US, and none of which are airline flights), we’ll continue to feed MLAT results to PiAware & FlightFeeder, but with an anonymized Mode S code and no ident. This means your maps will look the same and this has no impact on ADS-B flights or other Mode S data you’re tracking locally, which are decoded and displayed entirely within your device, without the involvement of FlightAware’s servers. We’ll also ask that people limit their use of the FlightAware MLAT results to themselves.

In summary, the specifics:

  • Starting today, less than 1% of MLAT flights will have anonymized mode S codes. You’ll need PiAware 3 or FlightFeeder 7 to see the anonymized MLAT results since it will not be displayed on older versions.

  • This doesn’t affect ADS-B flight tracking or your local Mode S data, which your receiver does on its own without our involvement.

  • We’ll be releasing a new license that continues to give you unlimited personal use of the MLAT data, but does not allow for redistribution. We are asking for your cooperation, support, and understanding to ensure this is honored.

Thank you for your continued support. We are expanding our efforts on ADS-B projects and are excited about the new opportunities and types of information and tools that we’ll be releasing in the coming weeks and months.

Daniel Baker
FlightAware

2

When do you guys plan on rolling out version 3 to piaware? Also does Piaware use Amazon’s Web Services for the mlat network or is it in house?

3

Piaware 3 is available now as a sdcard image, or to build from source on github. Binary packages and an upgrade path for 2.1 installs soon.

AWS is not used.

4

This is a good reason to upgrade. :stuck_out_tongue:

I did this morning, started it back up and already see a couple anonymized MLATs:

5

Will the upgrade automatically disable redistribution scripts for anyone doing so or does that have to be done manually post upgrade to prevent violating the rules?

6

Yes, and TIS-B messages (which also have a pseudo Mode S hex ID) also will be in italics since the hex ID is not from the aircraft.

7

Nothing is done currently. We’ll probably do a one-off config change to handle the obvious cases in a later version but that will not necessarily catch everything.

8

Ok. Just to be clear - I want to comply with this but I was wondering what steps I have to do so. Sounds like it would be as simple as wiping the SD card and putting version3 on it once it’s mandatory? Please confirm if you can, I’m new at this (only got my Pi 3 weeks ago) so I wanted to be sure. Thanks.

9

Thanks for your interest in helping us & the community. To answer your question…

Are you feeding data anywhere else? If so, we need to make sure the MLAT data isn’t going anywhere. If not, no worries.

If you’re not running custom scripts to feed other aggregators, it’s merely a display issue for you. In that case, yes, just installing PiAware 3 means you can see everything.

10

Hi Dan,

First of all, I appreciate the openness of your approach, and the communication on this issue. I can’t say I’m surprised by this - it was probably a matter of time.

I also want to make sure I comply with the new requirements. I don’t redistribute any MLAT data to 3rd party sites, but I do have a flight log publicly available on my website. I’ve already made changes to not display MLAT flights to public users. Just to clarify, is it all MLAT data that shouldn’t be displayed, or only non-airline data?

I also have a VRS instance that is public, and I’ve started looking into how to restrict MLAT flights from that as well. I posted a note about this in the VRS forums to make other people (including the author of VRS) aware of your post.

Thanks,

Andy

11

Just wondering what’s going to happen in 2020 when everything is ADSB? Or do these “agencies of concern” have exemptions to ADSB? This seems like a 3.5 year band aid.

12

Hi Andy, thanks for your support. Your plan sounds good and to clarify, it’s just the MLAT data (for any type flight) that needs to stay with you personally. Daniel

13

Valid point and there’s always more focus on a current problem than a future one. The FAA has a variety of options as their disposal, including support from lawmakers, although I’m optimistic that we can solve this as a community. I don’t speak for anyone else, but I don’t think there’s much concern over folks receiving ADS-B of what’s overhead; the trouble starts when people are aggregating the data on a wide scale with reckless disregard for problems it might cause other people. Perhaps in an ideal world, everything would be available to satisfy my curiosity, but I’m rational and have to prioritize my whims below other people’s actual issues.

14

Can you please clarify which part of PiAware 3 is responsible for displaying the anonymized MLAT results and what exactly will not work on older versions? In my case, I have upgraded PiAware to 3.0.3 but I’m using an early-2016 (Jan or Feb) version of dump1090-mutability 1.15~dev. Will this combination show those flights or to I need to upgrade to more recent dump1090 versions, either FA or mutability flavours?

15

The bit that is needed is a fa-mlat-client version (packaged with piaware) that is recent enough to understand the extra flag in mlat results that says “this is an anonymized result” and knows to turn it into an appropriately-formatted DF18-with-non-icao-address message, rather than a DF18-with-icao-address message. Without that change there is a risk that the effectively random hexids could be interpreted by other software consuming the results as real addresses, which tends to make people unhappy if they are e.g. collecting databases of aircraft.

see github.com/mutability/mlat-clie … fe938df9c3 (advertising the capability to do so)

The dump1090 version shouldn’t matter at all (it might influence how anonymized positions are shown exactly since that went through a few iterations too)

16

I knew that web site was going to cause trouble and mess up everything…

17

Yeah, people have been sharing ADS-B for the better part of a decade with no drama. Then he thought he was going to come along and use all the tech/data from FA which his value-add being ignoring the rules. It couldn’t last. And then here we are. Can’t wait until the next “innovation” that will stir the pot a bunch and not work in the long run anyway. :unamused:

18

Many of the aircraft that FA scrambles the ICAOs for are visible in the clear on other websites, and the vast majority seem to be corporate/private operators, not government or law-enforcement aircraft. So, unless I’m missing something, what’s the big deal?

I can understand FlightAware not wanting to have their MLAT data used by others since there is obviously an infrastructure investment, sure, but I’m not sure the security posture is accomplishing much. There are iPhone apps out there that re-broadcast police scanner traffic. Surely the police don’t like those, but in the years they’ve been around, nobody has proposed any legislation to prevent them, much less has any been passed.

Can the government really put the genie back in the bottle via laws? This appears to be a “problem” that needs a technical solution. Plus, once 2020 rolls around, any common criminals will be able to see exactly when they’re being surveilled using only a single receiver, and all the high-end jet operators will be broadcasting their movements. Security was purposefully ignored when designing ADS-B. I wonder why that was?

Rick

19

The nature of the types of scrambled flights depends on what kind of traffic is near your receiver. We compile a number of block lists from the FAA and militaries and implement the scrambling for all of them. Certainly near major US cities, the odds of seeing a scrambled bizjet is greater than law enforcement or military. And lots of sites hide some of the military stuff entirely, so you don’t know what you’re not seeing. Plus there’s no other site that redistributes MLAT data back to you, so it’s hard to make an apples to apples comparison.

To your point around ADS-B making this even worse, it’s really the same problem since the issues raised are not related to individual people using receivers to see what’s overhead; the issue is around aggregating on a wide scale and publicizing it with zero controls. So, yes, the government could regulate aggregators, particularly those that redistribute. And I’ve seen drafted language to do so.

I’m not saying what we’ve done is a perfect solution or even a great solution. I’m in agreement that there is no real solution. Our intentions and goals over the last >year of MLAT were pretty clear, so it’s not our preference to do this. But we have to be pragmatic.

20

Re - the ADSB issue, I was assuming the law enforcement concerns would be something like “hey, we’re watching/chasing this suspect with a helicopter and we don’t want him to know” kind of thing. That’s the main issue I could envision, and all the criminal would need would be a single receiver to pull that off, nothing with aggregation. The fix for that would have to be technical.

If they haven’t made the police scanner apps illegal, I just can’t see how this could possibly be (effectively) outlawed, especially since any aggregation website could easily operate in another jurisdiction outside of the US…?

Rick