SpaceX shut down part of Dishy's API | Hacker News Reader

SpaceX shut down part of Dishy's API

tysonpower.de

93 pointsfortran7725 comments

> You could also triangulate ground stations with data from enough Dishys etc. what can all be used against them

The ground stations locations are public information since they require FCC licenses so this is a bit of a moot point.

They aren’t all public globally — there seems to be at least one in Austria based on this data, the location of which is presently unknown.

A station in China might be able to bypass the great firewall using this now it is gone? Makes me wonder if there were ever any anonymous clandestine stations or is that precluded, or does any data draw get fed to reduce latency? Or would Starlink know and preclude their operation?

A station in China would be _behind_ the firewall. If Starlink had a downlink station in China it probably would have been for factory testing.

Companies like Iridium and Inmarsat have already played this game and figured out that it is best to just not sell devices in countries that don't want it. Downlink frequencies are well known, and repressive countries tend to jam transmissions they don't like. This negatively impacts users in the same region.

Future versions of this technology are working towards not needing the ground stations, by transmitting satellite-to-satellite. That would (theoretically) make it technically possible to use a dish in a country with no ground stations.

It's fun to see the data and it is a cool project.

But running speedtest every 15 minutes sounds like a bad idea. It's going to fully saturate the connection for ~1 minute and is likely to interfere with whatever the connection is being used for. Things like gaming/streaming/video chat are likely going to suffer.

Running the status check only during the night would probably be a better idea, and would probably generate data that was still useful.

  */15 2-6 * * * ~/path/to/starlinkstatus_client.sh -k 'YOURAPIKEY' -s -d >/dev/null 2>&1

Fast.com goes for 15 seconds and speedtest.net goes for 15 each way, and you can get reasonable values from a 5 second test if you're worried about causing congestion. It could cause a slight annoyance but the connection's imperfect to start with and I'm sure a lot of people on this beta are interested in the info.

Yeah but you don't want night only data. You want to know what the speed is while people are actually using it

In my personal opinion, you could consider using passive bandwidth estimation approaches, like in Chrome's Network Quality Estimator.

See, for example: https://lists.w3.org/Archives/Public/public-networks-ig/2020...

(This is my opinion and not that of my employer.)

A combination of periodic speed tests to multiple reliable endpoints and local netflow statistics are needed to understand network performance. It's relatively easy to set up things like librenms, cacti, and iperf hosted on a vps with dedicated throughput. There's a slew of open source and easily accessible software available.

Public speed tests are inaccurate at best, and very often downright misleading.

They're good enough for a quick test to see if you're online and a very rough indication of throughput. Even repeated tests to higher quality services though, like fast.com, are not a good benchmark.

Set up your own network monitoring stack - once you've built that, you have an anchor point for your home networks that you can riff on instead of being dependent on your isp's default setup.

In this case, you could track real-time performance of starlink and be able to trust the data without wondering if there's congestion between fast.com or speedtest.com servers and the local starlink ground station. If you can talk to the datacenter owners in your local fiber hotel where the starlink ground station connects to. They may have an iperf server, or allow you to host one there, giving you another test point when diagnosing an issue.

Also, when is night for a global satellite network?

As the network doesn't have any satellite interlinks yet, and each bird covers something like a 1500km (if I recall correctly) diameter ground circle - local night is very easy to determine.

Very cool project. Good thing on Starlink for only removing the potentially sensitive API. Once I'm back to where my Starlink is I'll have to update my system to report to this as well.

I was kind a curious of the security they have on these satellites. What if you made a worm that spread from satellite to satellite. Spoof the handshake/take control... be interesting. I'm not in the space of pentest or anything but seems like more and more of these satellite constellations for internet are going up.

The Air Force actually sponsored a CTF at Defcon (a hacker conference in Las Vegas) where the goal was to hack a live satellite:

https://www.wired.com/story/air-force-defcon-satellite-hacki...

This seems more like the plot of Swordfish 2 than an actual attack vector.

Yeah also curious how they can keep this secure. I guess there must be a reliable way all sat makers have figured out for this.

Should be "shut down", two words. One word makes it a noun and makes the title confusing.

The rule on HN is to use the original title.

The rule, as I understand it, is to avoid editorializing/putting a spin on it/misleading people. Not fixing grammatical errors. But I could be wrong.

I regularly see people completely change the meaning of the title in the name of fixing what they think is a grammar error. I'd much rather everyone just use the original title and put a [sic] if they feel like it.

He’s not a native speaker, dude, chill.

I can’t say I’m surprised… they probably aren’t too happy to have enthusiasts data mining their high profile internet service.

> Many people, especially competitors of Starlink, could try and use that data to do things against SpaceX, what would be bad for all Starlink users.

Oh no, one of the most visible, outspoken libertarians of the day might face some competition...and somehow that competition will hurt starlink users?

This is some strange pearl clutching.

I doubt the API was revealing anything not already known by researchers both academic and commercial. Probably half of it is in some FCC filing somewhere.

Yeah this whole post makes absolutely no sense. None of this information is problematic in any way and none of the explanations as to why the author thinks it could be bad are at all sound.

Reply on news.ycombinator.com