-<p>The last few days I have looked at ways to track open security
-issues here at my work with the University of Oslo. My idea is that
-it should be possible to use the information about security issues
-available on the Internet, and check our locally
-maintained/distributed software against this information. It should
-allow us to verify that no known security issues are forgotten. The
-CVE database listing vulnerabilities seem like a great central point,
-and by using the package lists from Debian mapped to CVEs provided by
-the testing security team, I believed it should be possible to figure
-out which security holes were present in our free software
-collection.</p>
-
-<p>After reading up on the topic, it became obvious that the first
-building block is to be able to name software packages in a unique and
-consistent way across data sources. I considered several ways to do
-this, for example coming up with my own naming scheme like using URLs
-to project home pages or URLs to the Freshmeat entries, or using some
-existing naming scheme. And it seem like I am not the first one to
-come across this problem, as MITRE already proposed and implemented a
-solution. Enter the <a href="http://cpe.mitre.org/index.html">Common
-Platform Enumeration</a> dictionary, a vocabulary for referring to
-software, hardware and other platform components. The CPE ids are
-mapped to CVEs in the <a href="http://web.nvd.nist.gov/">National
-Vulnerability Database</a>, allowing me to look up know security
-issues for any CPE name. With this in place, all I need to do is to
-locate the CPE id for the software packages we use at the university.
-This is fairly trivial (I google for 'cve cpe $package' and check the
-NVD entry if a CVE for the package exist).</p>
-
-<p>To give you an example. The GNU gzip source package have the CPE
-name cpe:/a:gnu:gzip. If the old version 1.3.3 was the package to
-check out, one could look up
-<a href="http://web.nvd.nist.gov/view/vuln/search?cpe=cpe%3A%2Fa%3Agnu%3Agzip:1.3.3">cpe:/a:gnu:gzip:1.3.3
-in NVD</a> and get a list of 6 security holes with public CVE entries.
-The most recent one is
-<a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-0001">CVE-2010-0001</a>,
-and at the bottom of the NVD page for this vulnerability the complete
-list of affected versions is provided.</p>
-
-<p>The NVD database of CVEs is also available as a XML dump, allowing
-for offline processing of issues. Using this dump, I've written a
-small script taking a list of CPEs as input and list all CVEs
-affecting the packages represented by these CPEs. One give it CPEs
-with version numbers as specified above and get a list of open
-security issues out.</p>
-
-<p>Of course for this approach to be useful, the quality of the NVD
-information need to be high. For that to happen, I believe as many as
-possible need to use and contribute to the NVD database. I notice
-RHEL is providing
-<a href="https://www.redhat.com/security/data/metrics/rhsamapcpe.txt">a
-map from CVE to CPE</a>, indicating that they are using the CPE
-information. I'm not aware of Debian and Ubuntu doing the same.</p>
-
-<p>To get an idea about the quality for free software, I spent some
-time making it possible to compare the CVE database from Debian with
-the CVE database in NVD. The result look fairly good, but there are
-some inconsistencies in NVD (same software package having several
-CPEs), and some inaccuracies (NVD not mentioning buggy packages that
-Debian believe are affected by a CVE). Hope to find time to improve
-the quality of NVD, but that require being able to get in touch with
-someone maintaining it. So far my three emails with questions and
-corrections have not seen any reply, but I hope contact can be
-established soon.</p>
-
-<p>An interesting application for CPEs is cross platform package
-mapping. It would be useful to know which packages in for example
-RHEL, OpenSuSe and Mandriva are missing from Debian and Ubuntu, and
-this would be trivial if all linux distributions provided CPE entries
-for their packages.</p>
+<p>The last few days I have spent some time trying to add support for
+the <a href="http://www.open311.org/">Open311 API</a> in the
+<a href="http://www.fiksgatami.no/">Norwegian FixMyStreet service</a>.
+Earlier I believed Open311 would be a useful API to use to submit
+reports to the municipalities, but when I noticed that the
+<a href="http://fixmystreet.org.nz/">New Zealand version</a> of
+FixMyStreet had implemented Open311 on the server side, it occurred to
+me that this was a nice way to allow the public, press and
+municipalities to do data mining directly in the FixMyStreet service.
+Thus I went to work implementing the Open311 specification for
+FixMyStreet. The implementation is not yet ready, but I am starting
+to get a draft limping along. In the process, I have discovered a few
+issues with the Open311 specification.</p>
+
+<p>One obvious missing feature is the lack of natural language
+handling in the specification. The specification seem to assume all
+reports will be written in English, and do not provide a way for the
+receiving end to specify which languages are understood there. To be
+able to use the same client and submit to several Open311 receivers,
+it would be useful to know which language to use when writing reports.
+I believe the specification should be extended to allow the receivers
+of problem reports to specify which language they accept, and the
+submitter to specify which language the report is written in.
+Language of a text can also be automatically guessed using statistical
+methods, but for multi-lingual persons like myself, it is useful to
+know which language to use when writing a problem report. I suspect
+some lang=nb,nn kind of attribute would solve it.</p>
+
+<p>A key part of the Open311 API is the list of services provided,
+which is similar to the categories used by FixMyStreet. One issue I
+run into is the need to specify both name and unique identifier for
+each category. The specification do not state that the identifier
+should be numeric, but all example implementations have used numbers
+here. In FixMyStreet, there is no number associated with each
+category. As the specification do not forbid it, I will use the name
+as the unique identifier for now and see how open311 clients handle
+it.</p>
+
+<p>The report format in open311 and the report format in FixMyStreet
+differ in a key part. FixMyStreet have a title and a description,
+while Open311 only have a description and lack the title. I'm not
+quite sure how to best handle this yet. When asking for a FixMyStreet
+report in Open311 format, I just merge title an description into the
+open311 description, but this is not going to work if the open311 API
+should be used for submitting new reports to FixMyStreet.</p>
+
+<p>The search feature in Open311 is missing a way to ask for problems
+near a geographic location. I believe this is important if one is to
+use Open311 as the query language for mobile units. The specification
+should be extended to handle this, probably using some new lat=, lon=
+and range= options.</p>
+
+<p>The final challenge I see is that the FixMyStreet code handle
+several administrations in one interface, while the Open311 API seem
+to assume only one administration. For FixMyStreet, this mean a
+report can be sent to several administrations, and the categories
+available depend on the location of the problem. Not quite sure how
+to best handle this. I've noticed
+<a href="http://seeclickfix.com/open311/">SeeClickFix</a> added
+latitude and longitude options to the services request, but it do not
+solve the problem of what to return when no location is specified.
+Will have to investigate this a bit more.</p>
+
+<p>My distaste for web forums have kept me from bringing these issues
+up with the open311 developer group. I really wish they had a email
+list available via <a href="http://www.gmane.org/">Gmane</a> to use for
+discussions instead of only
+<a href="http://lists.open311.org/groups/discuss">a forum<a/>. Oh,
+well. That will probably resolve itself, one way or another. I've
+also tried visiting the IRC channel #open311 on FreeNode, but no-one
+seem to reply to my questions there. This make me wonder if I just
+fail to understand how the open311 community work. It sure do not
+work like the free software project communities I am used to.</p>
+</div>
+ <div class="tags">
+
+
+
+ Tags: <a href="http://people.skolelinux.org/pere/blog/tags/english">english</a>, <a href="http://people.skolelinux.org/pere/blog/tags/fiksgatami">fiksgatami</a>, <a href="http://people.skolelinux.org/pere/blog/tags/open311">open311</a>.
+
+ </div>
+ </div>
+ <div class="padding"></div>
+
+ <div class="entry">
+ <div class="title"><a href="http://people.skolelinux.org/pere/blog/FiksGataMi___fylkesoversikt_p___kart.html">FiksGataMi - fylkesoversikt på kart</a></div>
+ <div class="date">2011-04-15 13:15</div>
+ <div class="body">
+<p>Det er morsomt å følge med hvordan bruken av FiksGataMi sprer seg
+over det ganske land. Her er lenkene til fylkesoversikt på kart over
+de (for tiden) 200 siste problemene. Bruker her GeoRSS-kilden i
+FiksGataMi og presenterer enten via Google Maps eller en
+GeoRSS-fremviser jeg fant for OpenStreetmap.</p>
+
+<ul>
+
+ <li>Østfold [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Østfold">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Østfold">OpenStreetmap</a> ]</li>
+ <li>Akershus [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Akershus">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Akershus">OpenStreetmap</a> ]</li>
+ <li>Oslo [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Oslo">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Oslo">OpenStreetmap</a> ]</li>
+ <li>Hedmark [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Hedmark">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Hedmark">OpenStreetmap</a> ]</li>
+ <li>Oppland [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Oppland">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Oppland">OpenStreetmap</a> ]</li>
+ <li>Buskerud [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Buskerud">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Buskerud">OpenStreetmap</a> ]</li>
+ <li>Vestfold [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Vestfold">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Vestfold">OpenStreetmap</a> ]</li>
+ <li>Telemark [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Telemark">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Telemark">OpenStreetmap</a> ]</li>
+ <li>Aust-Agder [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Aust-Agder">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Aust-Agder">OpenStreetmap</a> ]</li>
+ <li>Vest-Agder [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Vest-Agder">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Vest-Agder">OpenStreetmap</a> ]</li>
+ <li>Rogaland [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Rogaland">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Rogaland">OpenStreetmap</a> ]</li>
+ <li>Hordaland [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Hordaland">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Hordaland">OpenStreetmap</a> ]</li>
+ <li>Sogn og Fjordane [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Sogn%2Bog%2BFjordane">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Sogn%2Bog%2BFjordane">OpenStreetmap</a> ]</li>
+ <li>Møre og Romsdal [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Møre%2Bog%2BRomsdal">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Møre%2Bog%2BRomsdal">OpenStreetmap</a> ]</li>
+ <li>Sør-Trøndelag [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Sør-Trøndelag">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Sør-Trøndelag">OpenStreetmap</a> ]</li>
+ <li>Nord-Trøndelag [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Nord-Trøndelag">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Nord-Trøndelag">OpenStreetmap</a> ]</li>
+ <li>Nordland [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Nordland">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Nordland">OpenStreetmap</a> ]</li>
+ <li>Troms [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Troms">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Troms">OpenStreetmap</a> ]</li>
+ <li>Finnmark [ <a href="http://maps.google.com/maps?q=http://www.fiksgatami.no/rss/reports/Finnmark">Google Maps</a> ] | [ <a href="http://vgr.petschge.de/?url=http://www.fiksgatami.no/rss/reports/Finnmark">OpenStreetmap</a> ]</li>
+
+</ul>
+
+<p>Antall problemer returnert i GeoRSS-kildene justeres over tid etter
+hvert som vi får mer erfaring med hvilken belastning det gir på
+tjenesten.</p>
+
+<p>Oppdatering 2011-04-27: Endret URL til fylker med mellomrom i
+navnene fra %20 til %2B, slik at de fungerer i flere nettlesere.</p>