I just discovered #brouter .
It's a routing engine that can use #openstreetmap data and your own preferences for #cycling roads if you want.

Certainly beats #graphhopper on the #OSM website.

https://brouter.de/brouter-web/

Is there a GUI for #Linux ?

#bike #bicycle #maps

@dcz there is an app for Android, although it's just the routing engine, I believe. But it does work offline and can be used with osmand, maybe something else too

@Dave My phone is using GNU/Linux, so I'm rather interested in that.

@dcz
Have a look here. You might need to run the server on your phone then and use a browser to interact? Don't know if that's a practical option though

https://github.com/abrensch/brouter

@Dave Thanks! The brouter website might be the worst organized website for a community project I've ever seen. I still don't know how to find the sources from there.

@dcz regarding graphhopper: do you have examples?

@karussell An easy example is telling the routing engine to prefer/ignore cycle paths. There's no such switch for graphhopper on osm.org.

@karussell That being said, that's not a point against the routing engine :)

If I can run one on my phone, that will currently make an instant winner.

@dcz @Dave Check out monav. Thats an app and has very fast routing engine. It worked fast even on n900.

@dcz why not use it on graphhopper.com where you have this feature? https://www.graphhopper.com/blog/2020/05/31/examples-for-customizable-routing/

Here is our app: https://f-droid.org/packages/com.graphhopper.maps/

@karussell Thanks, I'll try out the web interface!

I won't be checking out the app though. It won't run on my #linuxmobile .

@pavel @Dave Considering that I still do most of my route checking on the N900, this sounds promising.

@dcz If you can get the JVM running on your phone you could use GraphHopper even directly on the phone.

@karussell That's useful, but only half of the equation. A GUI is still needed for a solution that's actually useful.

I guess a web solution would hit the mark, but it's annoying to set up and insecure - those localhost sockets need to be firewalled to only accept blessed requests somehow.

@dcz the graphhopper server comes with the same web GUI. Don't understand what you mean regarding the localhost setup annoyance.

@karussell Good to know about the GUI. I might check it out.

localhost problem:

https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser

This is going to keep happening as long as localhost sockets are a globally shared resource. They are hard to firewall, so typically the security is outsourced to the application like the browser, with unsurprising outcomes.

@dcz
Was hat dieses Problem jetzt mit einem Server auf localhost zu tun hat? Also was sollen denn Angreifer mit einem routing service auf localhost anfangen? Insbesondere weil "This means public websites can access any open port on your host, without the ability to see the response"

btw: das sollte auch kein Problem mehr sein mit einem aktuellen Browser: https://www.theregister.com/2024/08/09/0000_day_bug/

@karussell The problem appears to be with the browser because we let the browser determine security policies for the system. No administrator writes firewall rules for the browser, despite that it's the interface between remote and localhost.

As to what people would do with a server running on localhost: the same as with any server. Find exploits.

I like the solution by someone on lwn: use local, not network sockets. Those have transparent, adjustable access controls.

https://lwn.net/Articles/984841/

@dcz Sorry for my German reply.

Ok "Finding exploits" is an argument, but if our GraphHopper service would be exploitable we would have a bigger problem than someone running GraphHopper on the phone :)

The "local" solution from lwn I'm not sure I fully understand if this would be applicable to our routing service which is intended for network sockets.

@karussell No worries, I only replied in English to make sure you understand my reply :P

The routing service is meant to operate in a different threat model. The attackers come from the outside network because there's no browser on localhost running malicious code. So the firewall on a server is actually doing its job protecting against attacks. It's not on a browser-equipped computer.

@karussell
The AF_INET socket and the network socket are created different but have the same API, so it works. You might know this from configuring reverse proxies: you can forward connections to an application over a local socket (/var/run/my_wsgi_app), or a network socket (http://another_host:8909).

They are so similar even ssh supports forwarding them:

ssh -L 9091:/var/run/transmission-rpc.sock 192.168.4.4