I’d recommend taking a look at Maplibre GL JS[0], which is a fully open source map library. It was forked from Mapbox GL JS just before licence change, therefore it’s also fully compatible with the style spec etc.
It’s also actively maintained and has a strong community behind it.
Shameless plug: I’ve also made a solver, written in Rust. Main goal was to learn the language, 2nd the trie structure behind the search: https://github.com/jutaz/wordle-search
While this is a nice initiative on many levels (from reducing emissions to getting people on bikes/scooters etc.), but I can't see it working well for few reasons:
- We have pretty harsh winters (well not the last one), so any biking/scooter'ing isn't really possible for at least 3 months, thus one still needs a car.
- Only few (I'd say only 3 largest) cities have kind of an infrastructure for scooters/bikes and only for major travel paths - outer-most city rings aren't well suited for such traffic.
- Local traffic culture (which goes both ways BTW) - car drivers aren't really well adjusted to bikes, and scooter/bike riders also have some not-so-great attitude on pedestrian walkways.
TL;DR - this probably would work really well _somewhere_, just not sure Lithuania is the best candidate for something like this, even if I personally still appreciate this.
I've known their `ladmin` password for a looong while - it was available online at least since 2015. And as far as I'm aware - the same password was used for multiple Telia routers' models (ADB-branded ones) - not just a single model.
There also was a user called `tadmin`, but I wasn't able to figure out the password for that one.
In the past BMW model names were correlated to the chassis type & the engine inside. So 530d would mean it’s a 5 series chassis, with 3.0 liter diesel engine and so on. These days, AFAIK, that’s no longer the case and model numbers are a bit arbitrary
There are easily multiple locks that could be put in place internally.
Encrypt the signal from the host to cash dispenser, have a debugger process that is connected to the host process that also stores the encryption keys and or talks to an HSM. Mitigates tampering of a live system, makes flashing new firmware problematic.
Physically limit the cash dispenser from outputting k bills over n seconds. Have those limits be session based, again signaled by main host process. Would require a full login/logout cycle for k bills.
Most likely, the systems are left wide open internally to ease development and mask bugs.
My ending blanket statement is that finance people know how to be cheap, they can optimize along one axis, replacing a 5$ with a 2$ part, but the really good ones optimize the whole system over a long time horizon.
Your comment is coming from a good place but it’s rooted in ignorance. Most ATM machines are made by NCR and not financial institutions. Majority are also quite old (runnning windows XP old).
NCR is focused on profits not security, even though they sell POS (point of sale), ATM machines, and airport kiosks.
From my personal dealings with NCR, I can confirm that they care very little for security, regardless of what their corporate line.
To put this in perspective: if you go to a grocery store, restaurant, or quick service (fast food) establishment and use a credit card then your full account number, name, and exp is recorded in their system. This information is accessible by anyone with store level admin (not windows admin, but think a manager with manager card).
This violates PCI but hey, fuck PCI, hard sending the system takes resources and who wants to do that?
On HN, folks keep talking about security and other such nonsense, however, anyone who has seen the other side isn’t very optimistic. Between ease of use, profit margins, and no pushback on insecure systems, all loses are just write offs.
On a less concrete note, my bank switched from Diebold to NCR and the difference is very apparent to the ATM user. The design is overall clean and bright, and it's much faster. The Diebold has long UI pauses for no apparent reason where the NCR seems not.
Their losses are just write offs...until they aren't, and something major happens. Maybe it will take a company completely going out of business due to poor security standards for others to wake up.
As one of the engineers initially responsible for achieving PCI compliance on these ATMs, this isn’t strictly true - of course it needs to know your account info, but it’s sent to your bank - it’s not stored on the machine at all - certain digits of your card number are written to a paper log but it’s never written in full - can’t speak for POS machines, but would imagine it’s the same
They should probably hire some people from microsoft's xbox department, or sony's playstation department.
A lot of money has gone into locking this hardware down, and I think for the xbox 360, which was released in 2005(!) there is still only one hack they couldn't solve with a software update, and that's soldering to the CPU and glitching it on a specific compare instruction.
I would bet, this "sophisticated malware" is a lot more trivial than glitching the CPU on one specific intruction and having to take a soldering iron to the ATM, then fiddling trying to get the timing exactly right.
Building a chain of trust and authenticate commands to the cash dispenser really shouldn't be an issue.
Really, just put a fucking xbox in these ATMs. Lots of people attacking those while being able to do whatever they want to the hardware with limited to no success. (I don't think anyone has managed to open up the xbox one?)
The problem with hardware lockdown is that at the end of the day x-boxes and PlayStations are only interacting with a screen to display media.
ATMs on the other hand are designed to interact with physical hardware that sucks money up and spits it out. Locking down the operating system is easy, but if the hardware is controlled by serial interfaces then you've got a weak point there unless the serial interfaces are encrypted (spoiler, they are not!). To encrypt them you'd need to put something at the OS side and something at the hardware (pneumatics/motors) side and ensure they aren't accessible (ie, located inside the safe part of the ATM). Its not impossible to do, but I somehow doubt they'll do it anyway.
No, it's not. Look at pretty much every console ever made except for the xbox 360/one.
> unless the serial interfaces are encrypted (spoiler, they are not!)
Yeah and that's obviously a problem. Nitpick though, the interface doesn't need to be encrypted, messages just need to be authenticated. Confidentiality of these messages isn't really important since you'll see the cash comming out, and you actually probably need some kind of challenge/response protocol to avoid replay attacks.
But you want them authenticated by a key that is very difficult to get out of the thing controlling the cash dispenser/serial/whatever. Which is why I said put a gaming console inthere, millions of dollars have already been spent, and are still being spent making sure nobody is getting secret keys out of them, even with full access to the hardware.
> To encrypt them you'd need to put something at the OS side and something at the hardware (pneumatics/motors) side and ensure they aren't accessible (ie, located inside the safe part of the ATM). Its not impossible to do, but I somehow doubt they'll do it anyway.
Well no, that's the point. You only need to make sure the pneumatics/motors only take authenticated commands, and that nobody can mess with those. For the OS side you piggy back off console security.
Microsoft and Apple have put a lot of thought into the security architectures of their consumer hardware. I've made this exact argument before -- just put the ATM app into a console title. It's the most secure hunk of readily available computing hardware, right off the shelf at Target.
But breaches happen, and lead to lawsuits, and I can just imagine trying to impress a jury about the security of your ATM while the other side cracks jokes about gold coins in Super Mario and speculates about your low Halo ranking.
Lithuanians call tea as "arbata", and it's boiled in "arbatinis". It also has nothing to do with "herbs". AFAIK, there is no reference to the word tea or cha anywhere in terms of tea.
This would appear to be confirmed based on regional dialects from this area.
In the Samogitian dialect of Lithuanian it's spelled "erbata", however the first "a" in modern Lithuanian isn't stressed, so it's very similar. Also in Kashubian (spoken in parts of northern Poland, often considered a dialect of Pomeranian) it is the same as modern Lithuanian.
On the other hand in Sambian Prussian it is "tejs", which is similar to "teja" in modern Lativan. It's interesting how two different forms emerged in the same geographic area.
A while ago I also made a Slack bot that calculates the amount of pushups based on open Pull Requests on GH on our private repos: https://github.com/robinpowered/swolebot
It’s also actively maintained and has a strong community behind it.
0: https://github.com/maplibre/maplibre-gl-js