And you should even take pride in doing less

Guter Schlaf ist wichtig. Das wissen auch Hotels – und versprechen mehr davon, wenn man schon vor Ankunft online eincheckt. Natürlich ist es auch günstiger für die Betreiber, Personal an der Rezeption einzusparen und stattdessen eine Maschine hinzustellen. Oder noch besser: den Check-In einfach komplett durch die Gäste auf ihren Smartphones erledigen zu lassen. Das ist schon auch komfortabel, aber spätestens seit die Sicherheitslücken bei der Hotelkette Numa bekannt wurden, haben wir bei der Kombination aus “Online-Check-In” und “mehr Schlaf” aber doch ein paar Fragezeichen im Kopf. Denn uns interessiert natürlich: Wie funktioniert der Check-In technisch und können wir ihm vertrauen? Spoiler: Nope, leider nicht… Kommt mit auf eine Datenreise. ## Can I have a little Urlaub? 👉👈 Sommerzeit heißt Reisezeit. Auch wir waren viel unterwegs, haben das ein oder andere Hotelsystem verwendet und irgendwann ist es passiert – uns sind Daten, Rechnungen und Ausweiskopien der anderen Hotelbesucher*innen entgegen gefallen. Vorbei war es dann mit dem guten Schlaf. Aber von vorne: Nach einer längeren Zugreise schon vor der Ankunft im Hotel online einchecken kann sehr bequem sein. Mitunter verlangen Check-In-Formulare aber eine ganze Menge Daten, die gar nicht unbedingt nötig wären. So auch in unserem Fall: Ohne Name, Geburtsdatum, Anschrift, eine Unterschrift und sogar ggf. Fotos von den Ausweisdokumenten kein Zimmerschlüssel. Praktisch: Während des Aufenthalts kann dann über das gleiche Portal auch gleich ein Wasserkocher für’s Zimmer dazugebucht werden – und nach dem Aufenthalt gibt es dort dann auch direkt Zugriff auf die Rechnung. ## Kleine Web-App, große Wirkung Die Software, um diese Daten zu erfassen, schreiben die Hotels in der Regel nicht selbst, sondern das machen Softwaredienstleister (wie in vielen anderen Bereichen auch). Im heutigen Fall die Firma _likeMagic AG_ aus der Schweiz🍫. Diese bietet eine Plattform, über die Hotelmitarbeitende sämtliche Arbeiten, die in so einem Hotel anfallen, mit einer Web-App verwalten. Und weil es natürlich ~~bequemer~~ billiger ist, wenn die Gäste sich selbst einchecken und den Zimmerschlüssel aufs Telefon bekommen, gibt es noch eine weitere WebApp für die Gäste. Damit diese für jedes Hotel bzw. jede Hotelkette auch in den Markenfarben (und -Domains) des Hotels erstrahlt, ist die Gäste-WebApp unter einer Subdomain der Hotelwebseite erreichbar. Damit ist auch von _likeMagic_ als Serviceanbieter erstmal nichts zu sehen. Als Beispiel-URL für diesen Blogpost nehmen wir `https://my.examplehotel.invalid`. ## Check-In? Check-Out! Ein paar Tage vor unserem heiß erwarteten Hotelbesuch ist es dann soweit: Wir bekommen eine E-Mail mit dem Check-In-Link für unseren Aufenthalt. Also los, Check-In-Formular geöffnet und mit Daten befüllt. Nachdem wir alles eingegeben haben, müssen wir unseren virtuellen Meldeschein “unterschreiben”. Das geht entweder per Rumkritzeln auf dem Smartphone oder als Kunstwerk per Maus, aber _likeMagic_ bietet auch eine Komfort-Funktion an und generiert automatisch eine Unterschrift: einfach den eigenen Namen in traumhaft schöner Schreibschrift. Und damit sind wir auch schon fertig mit dem Check-In. Wir haben uns dann doch fürs rumkritzeln entschieden 🖍️. Und ja: Der Hinweis mit dem Gesetzgeber steht da wirklich so ☝️ Aber als gute zerforschis haben wir natürlich schon laaaaaange vorher die Entwicklungstools unseres Browsers geöffnet 👩‍🔬. Die protokollieren unter anderem die ganze Zeit mit, welche Daten die Website so an ihre Server sendet. Zuerst werden die eingegebenen Daten losgeschickt, und dann zum Schluss unsere “Unterschrift” hochgeladen. Das ganze quittiert der Server und sagt uns zur hochgeladenen Unterschrift gleich noch, unter welchem Dateinamen er sie abgespeichert hat und wie groß sie ist.1 { "createdAt": "2025-09-05T12:34:51.123456789Z", "updatedAt": "2025-09-05T12:34:51.123456789Z", "version": 0, "tenant": { "id": 69, "name": "zerdreams", "description": "ZER Hotels für Guten Schlaf und Sichere Daten", "createdAt": "2020-09-21T01:23:45.123456Z", "updatedAt": "2020-09-21T01:23:45.123456Z", "version": 0 }, "id": 2342420, "blobCreatedAt": "2025-09-05T12:34:51.123456789Z", "fileName": "ABCDEFGH-1/SIGNATURE_DOCUMENT.png", "contentType": "image/png", "contentLength": 2342, "metaData": { "ownerId": "ABCDEFGH-1", "magicFileType": "SIGNATURE_DOCUMENT", "originalFilename": "SIGNATURE_DOCUMENT.png" }, "ownerId": "ABCDEFGH-1", "tenantName": "zerdreams" } Das ist natürlich sehr freundlich vom Server, aber keine Information, die wir eigentlich benötigen. Diese Redseligkeit macht uns schon etwas stutzig – also gucken wir in den Code. ## Was will uns der Server damit sagen? Als klassische sogenannte “Single-Page-Applikation”2 wird auch hier wieder schon beim Öffnen der WebApp ganz viel Code für den Browser geladen – unabhängig davon, ob die Funktionen für diesen User/Einsatzzweck relevant sind, oder nicht. Dabei taucht dann auch beim groben Drüberlesen schnell eine Funktion namens `downloadFile` auf: Diese nimmt einen Dateinamen und versucht, die Datei vom Server abzurufen. Der Endpunkt, um Dateien abzurufen ist `https://my.examplehotel.invalid/api/guest-journey-service/{magicId}/files?fileName={name}`. Die `magicId` ist dabei eine längere zufällige Zeichenkette, die im Check-In-Link enthalten ist, den wir anfangs per Mail bekommen haben. Beim ersten Versuch diese URL direkt aufzurufen, bekommen wir nur eine Fehlermeldung, dass wir nicht angemeldet sind. Denn dieser Endpunkt braucht als Authentifizierung einen `Bearer`-Token von einem eingeloggten Nutzer. Na gut, dann müssen wir den wohl zuerst besorgen… Wir haben zwar keinen Account bei dem Hotel, klicken aber trotzdem auf den großen “Login”-Button auf der Hauptseite. Und siehe da: Auf der Login-Seite gibt es auch gleich einen Registrierungslink und nur wenige Sekunden später halten wir unseren neuen Account (und den dazugehörigen `Bearer`-Token) in den Händen und können es nochmal probieren. Mit dem Account klappt es dann direkt und wir können unsere wunderbar generierte Unterschrift nochmal betrachten. Dabei fällt unser Blick genauer auf den Dateinamen: `ABCDEFGH-1/SIGNATURE_DOCUMENT.png`. Der besteht aus drei Teilen: `ABCDEFGH-1` ist unsere Buchungsnummer, `SIGNATURE_DOCUMENT` die Art der Datei und `png` natürlich die passende Dateiendung für das Unterschriften-Bild, das wir hochgeladen haben. ## Die einzige Form von weltoffen, die nicht okay ist Doch als wir eine mitreisende Person nach ihrem Buchungscode fragen (sagen wir mal `STUVWXYZ-1`) und diesen ausprobieren, sind wir schockiert: Auch `STUVWXYZ-1/SIGNATURE_DOCUMENT.png` können wir abrufen und sehen … die automatisch generierte Unterschrift mit dem Namen unserer mitreisenden Person. Selbst den hochgeladenen Ausweis der Person können wir abrufen, direkt unter `STUVWXYZ-1/IDENTIFICATION_DOCUMENT.jpg` – dass die Datei so heißen müsste, wissen wir aus dem Code. Uff. Puh. Belastend. Wir haben gerade erst eingecheckt und schon finden wir so etwas? Datei für Datei die Buchungsanhänge runterladen zu können, ist schon schlimm – und eigentlich könnten wir hier auch schon aufhören. Die Erfahrung zeigt aber, dass Sicherheitslücken Rudeltiere sind und meist zusammen auftreten. Dann schauen wir mal lieber genauer hin. ## Zimmerservice? Einmal alles bitte. _likeMagic_ stellt praktischerweise eine gute API-Doku bereit, sodass wir gleich nachlesen, welche weiteren Schnittstellen wir uns anschauen könnten. Das ist gute Praxis, allerdings müssen die dort beschriebenen Schnittstellen (genauso wie grundsätzlich **alle** Schnittstellen) ausreichend sicher sein. So erfahren wir, dass `https://my.examplehotel.invalid/api/guest-journey-service/files/{BOOKING_CODE}/list` eine Liste aller Dateien zurück gibt, die zu einer Buchungsnummer gehören. Das ist die Unterschrift, ggf. das Ausweisfoto sowie am Ende die Rechnung 💸😭. ## 🎶 A, B, C, D, E, F, G… 🎶 Auch für diesen Endpunkt müssen wir zwar angemeldet sein, aber auch hier gilt: Welcher Nutzeraccount die Anfrage stellt, ist offensichtlich völlig egal. Unser erster Gedanke: Naja, dann muss man ja immerhin die Buchungsnummer (8 Großbuchstaben + eine Zahl) kennen, die kann man wenigstens nicht sofort erraten. Die Realität holt uns leider sofort ein: Die Software wirft einem anscheinend _sämtliche_ Dateien zurück, bei denen die Buchungsnummer mit den angegebenen Zeichen anfängt. Gäben wir also beispielsweise die Buchstaben `ZER` als Buchungscode an, bekämen wir wohl _alle_ Dateien zu _allen_ Buchungen, die mit `ZER` anfangen – inklusive ihrem Inhalt. Oh no! GET https://my.examplehotel.invalid/api/guest-journey-service/files/ZER/list [ { "fileName": "ZEROHNOO-1/ZEROHNOO-1-1.pdf", "contentType": "application/pdf", "contentLength": 12345, "blobCreatedAt": "2025-01-01T01:01:01.123Z", "metaData": { "ownerId": "ZEROHNOO-1", "folioId": "ZEROHNOO-1-1", "magicFileType": "INVOICE" }, "ownerId": "ZEROHNOO-1", "content": "[...]", "signedUrl": null }, // ... (weitere 23MB JSON-Daten 🤯) ] Weil die Buchungsnummern immer mit einem Großbuchstaben beginnen und schon ein Buchstabe reicht, um die Suche zu starten, könnte man mit nur ganzen _*checks notes*_ 26 Anfragen die Dateien aller Buchungen abrufen3. Mist 🍞. ## Wir würden dann gerne Zählen, bitte. Wir schätzen, dass alleine bei der Hotelkette, bei der wir selbst waren – McDreams – mehr als 500.000 Dateien von rund 200.000 Buchungen abrufbar gewesen wären – inklusive 90.000 Ausweisdokumenten. Und das war nur eine Hotelkette. Eine schnelle Suche liefert eine Liste von fast 50 Instanzen der _likeMagic_ -WebApp, die mutmaßlich ebenso betroffen waren. ## Vor dem Schlafen, nach dem Essen, Lückenmeldung nicht vergessen Nun haben wir Lücken gefunden, die sogar gleich eine ganze Reihe von Hotels betreffen. Damit geht die eigentliche Arbeit für uns erst los: alles sauber aufschreiben und dokumentieren. Diesen Report über die gefundenen Lücken schicken wir dann an den Hersteller und das CERTBund beim BSI. Der Hersteller antwortet (trotz Meldung an einem Sonntagabend!) prompt: bereits nach 2 Stunden bekommen wir eine Antwort und die Bestätigung, dass die Lücken geschlossen seien – was bei einem kurzen Test auch zu stimmen scheint. Auch der Hinweis, dass wir keinen Sicherheitskontakt finden konnten, wurde dankend aufgenommen. Wir empfehlen grundsätzlich immer allen, einen Sicherheitskontakt mittels des security.txt-Standards bereitzustellen. Ein paar Tage später tauchte zwar keine security.txt, aber immerhin eine frische Vulnerability Disclosure Policy in ihrem Helpcenter auf. Das ist eine gute Reaktion, die wir an dieser Stelle auch mal explizit loben wollen – auch wenn es nie zu einer solchen Lücke hätte kommen dürfen. Ganz positiv fällt unser Fazit zum Umgang mit der Lücke jedoch nicht aus: Bis heute wissen wir von keiner Information an die betroffenen Hotelgäste. Diese sollten darüber informiert werden, dass ihre Daten gefährdet waren, so wie es die DSGVO auch vorsieht. ## Warum liegen hier überhaupt Ausweise rum? Zum 01.01.2025 wurde das Bundesmeldegesetz angepasst, die “besondere Meldepflicht in Beherbergungsstätten” aus §29 und §30 BMG wurde für deutsche Staatsangehörige aufgehoben – aber halt auch nur für diese. Menschen, die nicht aus ‘schland 🇧🇪 stammen, müssen weiterhin ihre Daten und Wohnanschrift abgeben und ihren Ausweis zum Vergleich bereitstellen. Üblicherweise reicht da der Vergleich durch einen kurzen Blick auf den Perso an der Rezeption. Sobald aber der Check-In online passiert, kommen Hotels und Softwareanbieter auf interessante Ideen, wie man das denn über das Internet bewerkstelligt. Was jetzt Deutsche weniger gefährlich macht als alle anderen Menschen können wir uns (außer mit einer gehörigen Portion ~~Rass~~ Patriotismus) nicht erklären. Deshalb gilt hier wie immer: Daten, die nicht zwingend benötigt werden, sollte man gar nicht erst erfassen. Und ist der Grund für bereits erfasste Daten weggefallen, sollten die auch schnellstmöglichst gelöscht werden. Besonders diese personenbezogenen Daten sind nunmal kein Öl, sondern toxischer Abfall. Und Daten die man nicht (mehr) hat, können auch nicht unbeabsichtigt wegkommen :) Die allerbeste Lösung für das Problem ist aber eine Anpassung des Bundesmeldegesetzes: einfach keinerlei Datenerfassung mehr. Denn wer sie nicht von Menschen mit einer bestimmten Staatsbürgerschaft braucht, braucht sie von allen anderen auch nicht. Das ist auch die Position des Hotelverband Deutschland. ## Schluss. Schlafen. Liebe Hotels, ab jetzt bitte keine Lücken mehr, damit wir endlich wieder ruhig schlafen können. Wir machen das alles ehrenamtlich in unserer Freizeit. Guter Schlaf ist wichtig. Auch für uns… 😴4 ## Timeline * 2025-09-05: Beginn der Analyse, Erste Lücke entdeckt * 2025-09-06: Zweite Lücke entdeckt; Bestätigt, dass auch andere Hotelketten betroffen sind * 2025-09-07 20:23 Uhr: Meldung der Lücke an das Unternehmen und das CERTBund * 2025-09-07 22:34 Uhr: Antwort des Unternehmens, Lücke geschlossen ## 🤝 Unsere Recherchen haben wir mit Jacob von der ZEIT geteilt, den Artikel findet ihr hier. An solch einem Artikel sitzen wir als Kollektiv deutlich länger als eine Woche, vom Finden der Lücken, über das Schreiben der Reports, den Umgang mit den betroffenen Unternehmen bis zur Veröffentlichung dieses Posts. Falls euch dieser Artikel gefallen hat, könnt ihr uns gerne unterstützen. Und wer uns bereits unterstützt - nochmals vielen Dank! (Kleiner Hinweis: Wir mussten schon wieder unsere IBAN austauschen) * * * 1. Die Inhalte des folgenden JSON-Snippets haben wir fiktionalisiert, die Struktur ist beibehalten. ↩︎ 2. https://de.wikipedia.org/wiki/Single-Page-Webanwendung ↩︎ 3. Falls ihr euch fragt, warum der letzte Blogpost so lange her ist: Wir haben uns fortgebildet und können jetzt nicht nur Zahlen hochzählen, sondern auch das ganze Alphabet (in Schrift und Gesang). ↩︎ 4. Dieser Satz wurde sehr müde mitten in der Nacht geschrieben. ↩︎

A single-node analytical database engine with geospatial as the first-class citizen - apache/sedona-db

Supply chain attacks are malicious updates that sneak into open source code used by many apps. Here's how we design Obsidian to ensure that the app is a secure and private environment for your thoughts. ### Less is safer It may sound obvious but the primary way we reduce the risk of supply chain attacks is to avoid depending on third-party code. Obsidian has a low number of dependencies compared to other apps in our category. See a list of open source libraries on our Credits page. Features like Bases and Canvas were implemented from scratch instead of importing off-the-shelf libraries. This gives us full control over what runs in Obsidian. * **For small utility functions** we almost always re-implement them in our code. * **For medium modules** we fork them and keep them inside our codebase if the licenses allows it. * **For large libraries** like pdf.js, Mermaid, and MathJax, we include known-good, version-locked files and only upgrade occasionally, or when security fixes land. We read release notes, look at upstream changes, and test thoroughly before switching. This approach keeps our dependency graph shallow with few sub-dependencies. A smaller surface area lowers the chance of a malicious update slipping through. ### What actually ships in the app Only a handful of packages are part of the app you run, e.g. Electron, CodeMirror, moment.js. The other packages help us build the app and never ship to users, e.g. esbuild or eslint. ### Version pinning and lockfiles All dependencies are strictly version-pinned and committed with a lockfile. The lockfile is the source of truth for builds so we get deterministic installs. This gives us a straightforward audit trail when reviewing changes. We do not run postinstall scripts. This prevents packages from executing arbitrary code during installation. ### Slow, deliberate upgrades When we do dependency updates, we: 1. Read the dependency's changelog line-by-line. 2. Check sub-dependencies introduced by the new version. 3. Diff upstream when the change set is large or risky. 4. Run automated and manual tests across platforms and critical user paths. 5. Commit the new lockfile only after these reviews pass. In practice, we rarely update dependencies because they generally work and do not require frequent changes. When we do, we treat each change as if we were taking a new dependency. ### Time is a buffer We don't rush upgrades. There is a delay between upgrading any dependency and pushing a release. That gap acts as an early-warning window: the community and security researchers often detect malicious versions quickly. By the time we're ready to ship, the ecosystem has usually flagged any problematic releases. * * * No single measure can eliminate supply chain risk. But choosing fewer dependencies, shallow graphs, exact version pins, no postinstall, and a slow, review-heavy upgrade cadence together make Obsidian much less likely to be impacted, and give us a long window to detect problems before code reaches users. If you're curious about our broader approach to security, see our security page and past audits.

This release adds two powerful building blocks that can be used to implement all sorts of new features. The new "Locators" and the "deleted callbacks" features seem simple by themselves, but they c...

I Ditched Docker for Podman (and You Should Too) (codesmash.dev) 19:56  ↑ 156 HN Points

Comments

Last weekend was the 21st birthday of _OpenStreetMap_ (OSM), and with some friends we celebrated the occasion with a little mapping party. Our plan was to combine flying drones to collect aerial imagery and collecting street-level imagery with more traditional field mapping. Due to high winds, we mostly ended up with street-level imagery and doing field mapping though, using a variety of tools. On the way home, I was reflecting on how amazing this richness and diversity of tools for contributing to OSM is. Not just in terms of methods (like collecting imagery, sharing GPS tracks, _arm-chair mapping_ or surveying). But even just within each of these realms: Yesterday we surveyed using Every Door, StreetComplete, MapComplete, and ChatMap, while recording GPS tracks with CoMaps. Before then sitting down with our computers, to make larger edits with iD and JOSM. This wide spectrum of used tools is not (just1) because each of us had different preferences for tools. But also because different tools fill different niches. Even individually, I end up using virtually all of those mentioned tools every single day that I contribute to OSM.2 Why? Because each of them excels at particular and different use cases. _Every Door_ is great for surveying when it comes to adding more complex points to the map, things like amenities or shops.3 For these objects one realistically wants to add a wide range of information in one go (opening hours, websites, phone numbers, …). _StreetComplete_ is perfect to quickly add missing data to existing objects, at least in part because it tries to gamify OSM contributions. By highlighting different types of “missing” information around one’s current location, it’s easy to find things that are both simple to verify as simple to add by the click of a button/answering a multiple-choice question (e.g. adding in the type of road surface).4 _MapComplete_ is great for adding objects to which one might want to add photos, for example art works or wayside shrines, as long as the objects are already supported.5 And CoMaps works great if find yourself without any reception (which would be needed to download the live map) but you found a place where you want to make an edit, as you can look at the offline map and still queue up an edit/note. Similarly, less surveying-based editors like iD and JOSM have their own niches they work well for. The answer to _“what is the best editor”_ thus comes back to the common _“it depends on your use case”_. While at times I’ve seen people complain about the _**complexity**_ that comes with a large number of tools, I’d argue that **this big diversity in tools is in reality a big asset to enabling contributions to OSM**. Not only does it allow people to find a tool that works best for them and their contributing-style, it also facilitates having _the right tool for the job_. If you think of _everything apps_ or _super apps_ that try combining a lot of software features, their alleged appeal is to have all the functionality you could ever need in one place, but the reality is more often that those tools become bloated, hard to navigate, and calcify as any changes to the structure are infinitely harder given the size and complexity. I often compare this to the _Swiss Army Knife_ : In a pinch, its little screwdrivers, saws, etc. will do their job to fix stuff around the house. But for any larger building project you definitely would like a toolbox with some real screwdrivers and saws.6 This is because these individual tools can focus efforts on supporting and implementing comparatively narrow use cases, without having to make extra trade-offs. Of course, the idea of having tools that “do one thing well” isn’t new. It’s part of the Unix philosophy, alongside the idea that all of these tools should work together with each other. Similarly, how different types of contributions require different tooling reminds the biologist in me of JBS Haldane’s _On Being the Right Size_, which neatly outlines why the _shape_ of organisms plays a big role in the niche they fill. And more recently, there’s been a call for _malleable software_. That is software that can adapt to user needs. And while the authors are skeptical of too specialized software, they highlight interoperability between tools as a big factor, similar to the Unix philosophy.7 So why does this approach of having a large diversity of tools work well for OSM, when otherwise we might see trends that go counter to this? I think there’s different aspects to it: First of all, there’s a **clear “interoperable target”** - that is a place where people send contributions to: the OSM database. Ultimately it doesn’t matter which tooling someone used, the changesets end up in the same place, contributing to the larger project and shared goal. Then there’s two other key aspects of _peer-produced_ systems, **having a wide _range of tasks_ that are _granular_ and _modular_**.8 In other words: There’s lots of different types of contributions that one can make to OSM, ranging from very small (e.g. Verifying that a business still exists) to very large (e.g. Adding a whole new neighborhood with streets, buildings etc. to the database). But no matter the size, all of these contributions are valid and help improve the overall database and map. And lastly, there is the elephant in the room: There is no incentive to build a _“super/everything app”_. In the commercial space, the main incentive for building these tools is to keep “your” customers locked up in a closed, proprietary ecosystem. With that, the cost of switching becomes so high that you can maintain a ‘captive audience’. But in a digital commons, that is built on cooperation rather than competition, such an approach makes little sense. Especially for tools that are open source for contributing into the commons for the community benefit. It seems that under those combined circumstances, maintaining a diversity of tools works quite well. It provides a pathway for making lots of different contributions by lots of different contributors. And just like it takes a village to raise a child, it takes a global village – with many diverse contributions – to create a map as a by-product of understanding the world. And that’s a reason to not only celebrate the birthday of OpenStreetMap, but also the huge diversity of contributors, the ways in which they contribute and the tools they use for that. ### References 1. Greshake Tzovaras, B. (2025, July 24). Making a Panoramax Mastodon Bot. Bastian Greshake Tzovaras. https://doi.org/10.59350/ad1s9-yzs02 2. Greshake Tzovaras, B. (2025, March 17). Adding wayside shrines to OSM with MapComplete. Bastian Greshake Tzovaras. https://doi.org/10.59350/tehs2-enz94 3. Kloppenborg, K., Ball, M. P., & Greshake Tzovaras, B. (2021, May 23). A peer production model for citizen science: comparative analysis of three online platforms. https://doi.org/10.31235/osf.io/rw58y 4. Litt G, Horowitz J, van Hardenberg P, and Matthews T. (2025). Malleable Software: Restoring User Agency in a World of Locked-Down Apps. Ink & Switch. https://www.inkandswitch.com/essay/malleable-software/. ### Footnotes 1. Of course that also plays a role, people do realistically have different preferences or are willing to make different trade-offs with respect to usability. ↩ 2. If you look at my contribution history, you can actually see some of that diversity, but as different editors handle how changesets are pushed differently, the raw numbers can be a bit misleading. ↩ 3. And of course it works equally well to “fully” annotate buildings (addresses, number of floors, color, roof styles, …), as the name suggests. ↩ 4. It also works great for adding in simple objects, like all the play objects on a playground! ↩ 5. If an object isn’t supported yet, one can write a custom layer like I did for the wayside shrines, but that’s slightly more advanced. Either way, images uploaded through MapComplete are automatically linked as an OSM tag and available via their own Panoramax instance. ↩ 6. In the OSM universe, the _OsmAnd_ map/navigation/editing app is maybe an example of such a _Swiss Army Knife_ : Stuffed with features, it is very powerful and can do a lot of things, but comes close to requiring an advanced degree to really use all of those possibilities. As a result, for many/most use cases (think of doing a simple hike) there will be other, simpler, more specialized tools that will get the job done in a simpler/better way. ↩ 7. Thanks to Helge Rausch, who had pointed me towards the article initially and also highlighted the similarity to the Unix philosophy! ↩ 8. If you look at page 5 of the preprint you’ll find a longer list of characteristics that are found in peer-production. The examples given are from Wikipedia, but are easily translatable to OSM ↩

When designing software systems, do the simplest thing that could possibly work. It’s surprising how far you can take this piece of advice. I genuinely think…

Has anyone here successfully connected GeoServer with Keycloak? Any experiences or advice to share? #GISchat

Everything I know about good API design (www.seangoedecke.com) 03:10  ↑ 113 HN Points

OpenStreetMap data to PostgreSQL/PostGIS converter

Manage your saved coordinates locally. Contribute to altilunium/sakumaps development by creating an account on GitHub.

The Mapbox Vector Tile (MVT) format is widely considered the leading open standard for large-scale map visualization, as evidenced by its widespread adoption by major technology companies such as AWS, Meta, and Microsoft for their products and services. However, MVT was developed nearly a decade ago and, consequently, does not fully align with the capabilities of new geospatial data sources that are characterized by rapidly increasing data volumes due to advancements in geospatial sensors and automated detection through artificial intelligence. In this paper, we introduce the MapLibre Tile (MLT) format, a novel vector tile specification designed from the ground up to address the limitations of MVT. Our experiments, simulating user sessions on widely used basemap datasets, demonstrate that MLT achieves up to three times better compression ratios compared to MVT on encoded tilesets, with over six times better on certain large tiles. Additionally, MLT offers decoding speeds that are up to three times faster and significantly enhances processing performance. MLT also introduces new functionalities and is specifically designed to lay the foundation for the next generation of map renderers, which we expect to entirely offload processing to the GPU, thereby overcoming the stagnation of Moore`s law.

Comments

If you have recently visited thedownload site for Photon dump filesyou may have noticed the new site layout. The site has received a complete overhaulwith ne...

DuckDB v1.3.0 significantly improved the scalability of geospatial joins with a dedicated SPATIAL_JOIN operator.

Debian 13 "Trixie" (www.debian.org) 02:18  ↑ 120 HN Points

Sorry Wplace.live

Recently the CEO of Github wrote a blog post called Developers reinvented. It was reposted with various clickbait headings like GitHub CEO Thomas Dohmke Warns Developers: "Either Embrace AI or Get Out of This Career" (that one feels like an LLM generated summary of the actual post, which would be ironic if it wasn't awful). To my great misfortune I read both of these. Even if we ignore whether AI is useful or not, the writings contain some of the absolute worst reasoning and stretched logical leaps I have seen in years, maybe decades. If you are ever in the need of finding out how not to write a "scientific" text on any given subject, this is the disaster area for you. But before we begin, a detour to the east. # Statistics and the Soviet Union One of the great wonders of statistical science of the previous century was without a doubt the Soviet Union. They managed to invent and perfect dozens of ways to turn data to your liking, no matter the reality. Almost every official statistic issued by USSR was a lie. Most people know this. But even most of those do not grasp _just how much_ the stats differed from reality. I sure didn't until I read this book. Let's look at some examples. ## Only ever report percentages The USSR's glorious statistics tended to be of the type "manufacturing of shoes grew over 600% this five year period". That certainly sounds a lot better than "In the last five years our factory made 700 pairs of shoes as opposed to 100" or even "7 shoes instead of 1". If you are really forward thinking, you can even cut down shoe production on those five year periods when you are not being measured. It makes the stats even more impressive, even though in reality many people have no shoes at all. The USSR classified the real numbers as state secrets because the truth would have made them look bad. If a corporation only gives you percentages, they may be doing the same thing. Apply skepticism as needed. ## Creative comparisons The previous section said the manufacturing of shoes has grown. Can you tell what it is not saying? That's right, growth over what? It is implied that the comparison is to the previous five year plan. But it is not. Apparently a common comparison in these cases was the production amounts of the year 1913. This "best practice" was not only used in the early part of the 1900s, it was used far into the 1980s. Some of you might wonder why 1913 and not 1916, which was the last year before the bolsheviks took over? Simply because that was the century's worst year for Russia as a whole. So if you encounter a claim that "car manufacturing was up 3700%" some year in 1980s Soviet Union, now you know what that actually meant. ## "Better" measurements According to official propaganda, the USSR was the world's leading country in wheat production. In this case they even listed out the production in absolute tonnes. In reality it was all fake. The established way of measuring wheat yields is to measure the "dry weight", that is, the mass of final processed grains. When it became apparent that the USSR could not compete with imperial scum, they changed their measurements to "wet weight". This included the mass of _everything_ that came out from the nozzle of a harvester, such as stalks, rats, mud, rain water, dissidents and so on. Some people outside the iron curtain even believed those numbers. Add your own analogy between those people and modern VC investors here. # To business then The actual blog post starts with this thing that can be considered a picture. What message would this choice of image tell about the person using it in their blog post? 1. Said person does not have sufficient technical understanding to grasp the fact that children's toy blocks should, in fact, be affected by gravity (or that perspective is a thing, but we'll let that pass). 2. Said person does not give a shit about whether things are correct or could even work, as long as they look "somewhat plausible". Are these the sort of traits a person in charge of _the largest software development platform on Earth_ should have? No, they are not. To add insult to injury, the image seems to have been created with the Studio Ghibli image generator, which Hayao Miyazaki described as an abomination on art itself. Cultural misappropriation is high on the list of core values at Github HQ it seems. With that let's move on to the actual content, which is this post from Twitter (to quote Matthew Garrett, I will respect their name change once Elon Musk starts respecting his child's). Oh, wow! A field study. That makes things clear. With evidence and all! How can we possibly argue against that? Easily. As with a child. Let's look at this "study" (and I'm using the word in its loosest possible term here) and its details with an actual critical eye. The first thing is statistical representativeness. The sample size is 22. According to this sample size calculator I found, a required sample size for just one thousand people would be 278, but, you know, one order of magnitude one way or another, who cares about those? Certainly not business big shot movers and shakers. Like Stockton Rush for example. The math above assumes an unbiased sampling. The post does not even attempt to answer whether that is the case. It would mean getting answers to questions like: * How were the 22 people chosen? * How many different companies, skill levels, nationalities, genders, age groups etc were represented? * Did they have any personal financial incentive on making their new AI tools look good? * Were they under any sort of duress to produce the "correct" answers? * What was/were the exact phrase(s) that was asked? * Were they the same for all participants? * Was the test run multiple times until it produced the desired result? The latter is an age old trick where you run a test with random results over and over on small groups. Eventually you will get a run that points the way you want. Then you drop the earlier measurements and publish the last one. In "the circles" this is known as _data set selection_. Just to be sure, I'm _not_ saying that is what they did. But if someone drove a dump truck full of money to my house and asked me to create a "study" that produced these results, that is exactly how I would do it. (I would not actually do it because I have a spine.) Moving on. The main headline grabber is "Either you embrace AI or get out of this career". If you actually read the post (I know), what you find is that this is actually a quote from one of the participants. It's a bit difficult to decipher from the phrasing but my reading is that this is not a grandstanding hurrah of all things AI, but more of a "I guess this is something I'll have to get used to" kind of submission. That is not evidence, certainly not of the clear type. It is an opinion. The post then goes on a buzzwordsalad tour of statements that range from the incomprehensible to the puzzling. Perhaps the weirdest is this nugget on education: > Teaching [programming] in a way that evaluates rote syntax or memorization of APIs is becoming obsolete. It is not "becoming obsolete". It has been considered the wrong thing to do for as long as computer science has existed. Learning the syntax of most programming languages takes a few lessons, the rest of the semester is spent on actually using the language to solve problems. Any curriculum not doing that is just plain bad. Even worse than CS education in Russia in 1913. You might also ponder that if the author is _so_ out of touch with reality in this simple issue, how completely off base the rest of his statements might be. In fact the statement is so wrong at such a fundamental level that it has probably been generated with an LLM. # A magician's shuffle As nonsensical as the Twitter post is, we have not yet even mentioned the biggest misdirection in it. You might not even have noticed it yet. I certainly did not until I read the actual post. Try if you can spot it. Ready? Let's go. The actual fruit of this "study" boils down to this snippet. > Developers rarely mentioned “time saved” as the core benefit of working in this new way with agents. They were all about increasing ambition. Let that sink in. For the last several years the main supposed advantage of AI tools has been the fact that they save massive amounts of developer time. This has lead to the "fire all your developers and replace them with AI bots" trend sweeping the nation. Now even this AI advertisement of a "study" can not find any such advantages and starts backpedaling into something completely different. Just like we have always been at war with Eastasia, AI has never been about "productivity". No. No. It is all about "increased ambition", whatever that is. The post then carries on with this even more baffling statement. > When you move from thinking about reducing effort to expanding scope, only the most advanced agentic capabilities will do. Really? Only the most advanced agentics you say? That is a bold statement to make given that the leading reason for software project failure is scope creep. This is the one area where human beings have decades long track record for beating any artificial system. Even if machines were able to do it better, "Make your project failures more probable! Faster! Spectacularer!" is a tough rallying cry to sell. To conclude, the actual findings of this "study" seem to be that: 1. AI does not improve developer productivity or skills 2. AI does increase developer ambition This is strictly worse than the current state of affairs.