Hacker News Reader

Comment by gioele | Hacker News Reader

For years I refrained from doing a post like this because I feared (and still fear) that somebody at Google will notice what is going on and shut the old APIs down.

"What? server XYZ still works!? Mel was supposed to turn it off in 2010!"

The J2ME midlet has been very useful in the past years and I really don't want to lose it. (Ah, the pain and sorrow of relying on somebody else's service.)

View on HN

I know this feeling all to well. My friends and I created a facebook group in 2005 that doesn't have a name- we managed to sneak some null characters through their filters. Our nameless group occasionally causes problems, including crashing the IOS Facebook app for about a year, but we didn't want to make a bug report because we thought they'd just give the group a name (ultimately one of our friends at Facebook filed a bug report and got it fixed without outing us).

I recall there being a Twitter account with a username zero characters long. I've only seen retweets of it, because of course, https://twitter.com// is treated the same as https://twitter.com/.

Not 0 characters long, just full of unicode whitespace that got stripped out of most rendering layers. It was right up there with people like this: https://twitter.com/_

"Married to @__, Dad of @___" (!)

Wow, and that's not even a joke!

Hm. That handle checks out as valid perl. Now I probably should not attempt things that'll waste my entire Sunday afternoon.

My twitter name is just two underscores followed by a single character.

One of the first things I'll do if I notice any unsanitized input causing problems is to find as many examples as I can of the broken/malicious data and use them as test cases while fixing the bug. Obviously I don't stop at what's already in the system, but it's a good starting point.

In other words, I wouldn't be surprised if Facebook knows now.

The big list of naughty strings is a good place to start when digging up input issues: https://github.com/minimaxir/big-list-of-naughty-strings

Thanks, I think I've used that before but I hadn't bookmarked it yet.

My guess is they likely know and that it's tied to business applications that still rely on older software/hardware. Vendor agreements, etc. - just a theory.

It's super impressive.

I forgot how much the APIs changed, but yeah, Google Maps used to be 2d image tiles, huh? It's vector-based now, which I think saves bandwidth. How else has it changed?

Could this kind of backwards compatibility really be accidental?

No. New clients use vector data, but even the web version will go back to bitmap tiles if your browser does not support WebGL, the GPU is slow or busy, etc.

There was a whole MapReduce (which Jeff Dean used for years in public talks to explain the concept), part of a larger pipeline, that converted the road and POI network into bitmap tiles. It didn't run by accident or maintain itself, so this is probably not a coincidence. :-)

Actually, with the push toward edits going live quickly and the styling/multilingual support in the Maps API, it's likely that a good chunk of tile traffic is rendered on the fly now, but the HTTP requests to the servers would look the same and there would still be enough demand for the stock tiles.

Even on modern versions of Maps, South Korea uses bitmap tiles. On a phone, scroll so Pyongyang and Seoul are in the same viewport and observe what happens to them if you try to rotate the map.

For anyone unwilling to open maps and check: the South Korean tiles are bitmaps (you see this because the city labels rotate along with the map in SK but not in NK).

That's interesting though,why does South Korea use bitmaps?

South Korea has this brain-dead law that prohibits any map data on South Korea from being exported: the data must physically remain in a server located in South Korea.

Obviously, this is a huge problem for Google, who wants to keep the world's map data in multiple data centers across the world. So... imagine what kind of horrible kludges some unfortunate developers had to write just to comply with that law.

Every time someone from outside of South Korea looks at it that map data is exported. But don't tell them.

I think the law distinguishes between an end-user accessing map data and transferring the whole data overseas. But as you pointed out, that's not really a meaningful distinction. Anybody who's interested in a particular place in Korea (be it CIA or North Korea) can simply visit map.naver.com or buy commercially available satellite photos.

I don't know about whether it is deliberate, but I know it's much more complicated than just retaining old APIs. It's incredibly easy to break legacy compatibility. You only need to provide a server that serves images. What can possibly go wrong?

I notice that many text-only websites don't even work with old phones/computers now. It's because some older browsers don't do HTTP/1.1. More importantly, they don't do modern encryption standards, and web servers don't like that at all. Or maybe you have expired (root) certificates on the client, and the OS/your app doesn't provide a way to override/upgrade the certificates. I have seen more legacy apps break because of encryption than any other cause. You patch/upgrade the server software or you renew your certificate, and suddenly the legacy support is gone.

It's very tricky. I don't know, but I bet part of what made Gmaps clients so compatible is because the legacy clients didn't do HTTPS, and Google's servers don't require HTTPS.

> they don't do modern encryption standards, and web servers don't like that at all

Yes, and come July 1st, many websites will only allow TLS 1.1 and TLS 1.2 to be PCI compliant, which will knock out a bunch of old clients.

> I bet part of what made Gmaps clients so compatible is because the legacy clients didn't do HTTPS, and Google's servers don't require HTTPS.

That's my hunch too.

Those old clients can have security advantages. For example, my MPC7400 processor is immune to meltdown and spectre. It also isn't supported by a typical javascript JIT, so that wipes out lots of other potential exploits. I'm pretty sure the RAM is old enough to be immune to rowhammer; it is PC133 in slots specified for PC100.

The web browser is of course obsolete. Newer ones run slower, take more RAM than the 512 MiB that the system has, expect a GPU, and have lots of dependencies.

Of course! With some defensive programming, e.g, the client ignoring unrecognized elements in the XML response while still reading the ones it does recognize, and not changing the API endpoint URLs, so long as the API output contains the values the client is looking for, there shouldn't be any reason why this stuff would break.

If the client used tilemaps versus vector data, I would expect the tilemap data to be out of date, but the directions would still be valid.

Well, they're probably reading proto buffers instead of xml[1]. And proto deserialization automatically drops unrecognized fields. So yeah, as long as you continue shipping your core data in already-established fields, and don't radically change the interpretation of those fields, backwards compatibility is going to be built in.

[1] - So goes the standard joke: Some people think Google is an advertising company. Techies recognize Google as an advertising company. But in reality Google is a company which turns protobuffers into more differenter protobuffers.

Proto deserialization does not drop unrecognized fields. There was a change that made proto3 do this, and that has now (thankfully) been reversed.

https://github.com/google/protobuf/issues/272#issuecomment-2...

I agree it could be, usually.

But this is Google. They deprecate things with last week's milk. I feel like they have a pretty good idea of what's still running, and shut it down if it doesn't make them at least half a billion a year. I still miss many products, and I wasn't even a Reader user (so no, it's still other stuff I'm disgruntled about).

These days you can't even do a Youtube search without an account, and an account needs a phone number of course, so you have to resort to HTML scraping to do simple stuff like just using the top hit (so you can fire off a tab with some song in the background, without waiting for it to load and click a result with the mouse). There used to be an API for simple things like that.

> These days you can't even do a Youtube search without an account

Hyperbole or...?

https://youtube.com/results?q=never%20gonna%20give%20you%20u...

seems to work fine without an account.

Sorry, I was unclear. I meant they used to provide an API for it but that has been deprecated, just like many other useful things have been. See:

> so you have to resort to HTML scraping to do simple stuff like just using the top hit [...] There used to be an API for simple things like that.

If it's not costing like > $5MM / yr, it's unlikely someone would waste the time to turn it off, TBH.

Right, but if it requires maintenance, and it doesn't bring in enough money to cover the costs of that, turning it off might be more cost-effective than doing the maintenance.

Look at Google Finance, for example - uses Adobe Flash, which is 2 years away from EOL. Presumably it's not making any money and doesn't have a maintenance budget; if it did, they'd have moved away from Flash when the iPhone came out. But when Flash hits EOL, maintenance is mandatory.

Turning it off is what I'd do in that situation.

This is exactly what everyone thought about Reader, and Wave, and Picnik, and Revolv...

If Reader was running on old infrastructure, it's very possible it could have cost more than that just to maintain status quo.

I'm guessing they're keeping it going because I bet there's still a decent amount of traffic.

Last year Yahoo shut down their API that allowed you to download historical stock price data.

http://www.financial-hacker.com/bye-yahoo-and-thank-you-for-...

Reply on news.ycombinator.com