Re: Pure Maps
Quote:
Quote:
IMHO, we should get a better TTS engine before worrying and hacking around very limited TTS support that we have. Mimic2 and others are developed, but I have not looked into them (https://github.com/MycroftAI/mimic2). If someone wants to look into it and bring better TTS to the platform - that would be great! |
Re: Pure Maps
Looks like someone used my keys for MapQuest for DDOS attack or some other use. While we are using "Open" versions of geocoder and router, someone used their regular geocoding and directions service. As a result, instead of ~150 calls by Pure Maps users, 16000 were done in addition wiping out monthly quota.
Osmo, MartinK: has something like it happened for you? For now, please use some other service for routing and search. I would prefer not to think about how to start securing the keys and focus on other aspects. Right now they are available as a part of the source, but that has been like that for other projects as well. |
Re: Pure Maps
Quote:
|
Re: Pure Maps
Quote:
|
Re: Pure Maps
Quote:
By the way you didn't really answer the question for a liberapay alternative, or have they found a solution for there problems meanwhile? |
Re: Pure Maps
1.3.0 is out.
Its mainly polishing Valhalla's router and exposing its options, including, as requested, consideration of tolls and preference for the shorter route. In addition to earlier types of transportation, you could specify if you go by bus or high-occupancy vehicle. In future, after new OSM Scout Server maps are imported (coming in a week or two), motor scooter and motorcycle will be enabled too (relevant code is commented out right now). Due to the lack of access to MapQuest for at least about a month now, I have set Stadia Maps as a default router. Use that if you prefer to use online routers. Anyway, Valhalla, the router behind Stadia, is supported the best by the application. Translations have been updated - thank you all who have worked on it! Quote:
|
Re: Pure Maps
Quote:
But, I have thought about this, the obvious first thing to do is to revoke the key and get a new one. The next step would be to remove the keys from the source and when running qml/qmlscene, read them from environment variables and when building the RPM, write them from environment variables into JSON. The keys would still be installed as plain text, but getting them away from GitHub might help. Plain text files in RPMs and on devices could still be a problem, but that seems more difficult to solve. |
Re: Pure Maps
Quote:
For users: I probably would have to do it relatively fast, just to be sure that some other vital service will not be lost. So, if suddenly all online services will stop working, please check whether there is a new version with new access codes is released. |
Re: Pure Maps
Quote:
Indeed, one possibility is to inject the key at package build time, but each user will still have to get a copy as part of the package. Not to mention that ideally all the package build source artifacts & the build system would be open (as when building packages in Fedora) so there would be no place to hide the key - every user should be able to audit the package build and rebuilt the package, so needs all of the input artifacts. For that reason I prefer "public" APIs that don't use API keys where possible and that apply IP base rate limiting (IIRC geonames and Nominatim work that way). Another possibility is to add an option for users to add they own API keys, so they can get stuff working if the default one goes bad or even by default if you want to use an API with so low rate limit a shared key is unusable. |
Re: Pure Maps
@MartinK: well said. For now, I have removed the keys from the source and made new ones for services that allow multiple keys. Keys are injected at rpm build time by a small script
Let's see if this will help and whether such accident was one-off. |
All times are GMT. The time now is 21:37. |
vBulletin® Version 3.8.8