Warning: Missing argument 2 for wpdb::prepare(), called in /home/stromber/public_html/kryptoblog/wp-content/plugins/wp-super-edit/wp-super-edit.core.class.php on line 109 and defined in /home/stromber/public_html/kryptoblog/wp-includes/wp-db.php on line 1222
Internet » Kryptoblog

Archive for the ‘Internet’ category

Busiga säkerhetsfrågor

May 14th, 2010

Bruce Schneier postade för några dagar sedan om att hitta på bus med säkerhetsfrågor – den typ av frågor man måste ge ett svar på för att sedan kunna användas för att autenticera sig om det skulle behövas. Några av Schneiers förslag på frågor och svar är:

Q: Do you know why I think you’re so sexy?
A: Probably because you’re totally in love with me.

Q: Need any weed? Grass? Kind bud? Shrooms?
A: No thanks hippie, I’d just like to do some banking.

Q: The Penis shoots Seeds, and makes new Life to poison the Earth with a plague of men.
A: Go forth, and kill. Zardoz has spoken.

Q: What the hell is your fucking problem, sir?
A: This is completely inappropriate and I’d like to speak to your supervisor.

Q: I’ve been embezzling hundreds of thousands of dollars from my employer, and I don’t care who knows it.
A: It’s a good thing they’re recording this call, because I’m going to have to report you.

Q: Are you really who you say you are?
A: No, I am a Russian identity thief.

Naturligtvis hakar en massa läsare på och kommentarerna till Schneiers postning innehåller en del riktigt roliga – och en del riktigt bra frågor. För själva poängen är att om dessa frågor och svar skall vara bra säkerhetsmässigt skall dom inte vara enkla att gissa.

Naturligtvis var det mer än en som kom på att man skulle kunna använda dessa frågor som ett sätt att försöka attackera en tjänst, detta då det man matar in antagligen skickas rätt in i en databas. En som redan tänkt i dessa banor är Randall Munroe, skaparen av serien XKCD:
XKCD - Litte Bobby Tables.

Men nu visar det sig att detta antagligen hänt i verkligheten. BoingBoing har en postning om att banken The Sacramento Credit Union har följande information om vad som gäller för hemliga fraser:

The answers to your Security Questions are case sensitive and cannot contain special characters like an apostrophe, or the words “insert,” “delete,” “drop,” “update,” “null,” or “select.”

Gissningsvis har dom lärt sig detta den hårda vägen…

Phonekey – phoney säkerhet

May 13th, 2010

(Tipstack till Jakob.)

Computer Sweden skriver om Phonekey, ett svenskt företag som har en ny säkerhetslösning.

Enligt artikeln fungerar Phonekeys säkerhetslösning så här:

Tekniken innebär att du måste ringa ett speciellt nummer från din telefon innan det går att använda ditt betalkort, logga in på ditt konto på den sociala nätverkssajten eller komma åt någon annan tjänst som använder sig av det hänglås Phonekey innebär.

– Tekniken säkrar enkelt all korthantering och inloggning, säger Tonie Söderström, mannen bakom tekniken och en av grundarna.

Det företag som vill använda säkerhetsmekanismen installerar Phonekeys mjukvara på en server, låter användarna registrera sina telefonnummer och ger sedan användarna varsitt speciellt nummer att ringa när de vill använda företagets tjänster.

Användaren ringer två signaler till det anvisade numret och lägger på. Ett tidsfönster öppnas och användaren kan logga in eller använda sitt betalkort.

Enligt artikeln kan tekniken användas som en extra säkerhetsfunktion, eller som ersättning för lösenord eller pin-koder.

Visst låter det bra? Eller kanske inte. Låt oss göra en analys. (Jag vill poängtera att jag inte sett Phonekeys patent, utan bara det som står i artikeln.)

Vid en säkerhetsanalys gäller det att identifiera vilka premisser, förutsättningar och (ofta implicita) antaganden säkerheten bygger på. Och sedan funderar man på vad som händer om dessa premisser inte gäller – när det skiter sig (för att tala Dalsländska.)

Om vi tolkar artikeln rätt skall man innan man använder en tjänst som skyddas av Phonekeys lösning första gången, först registrera ett visst telefonnummer, exempelvis din mobil. Du får även ett speciellt telefonnummer att ringa upp med ditt registrerade telefonnummer för att aktivera den tjänst du vill använda när du vill använda den.

Man kan se denna mekanism som en separat autenticeringskanal för tjänsten. Att tjänsten inte är aktiv för en given användare om den först inte autenticerat sig via den separata kanalen är det som skall ge den extra säkerheten. Den som vill attackera en sådan tjänst behöver alltså både kunna ringa upp med det korrekta numret till den speciella numret innan det går att komma åt tjänsten (som i sin tur kanske skyddas av en identitetskod tillsammans med PIN-kod eller lösenord).

Pudelns kärna är att man litar på att det telefonnummer som ringer upp ett givet annat telefonnummer går att lita på. Tyvärr är det kanske inte något som är skrivet i sten. I USA är det relativt enkelt att utföra Caller ID Spoofing, dvs förfalska det uppringande numret. I Sverige är det svårare, men att det finns folk (som jobbar hos teleoperatörer) med kunskap, förmåga och möjlighet att förfalska ett uppringande nummer är nog inget falskt påstående.

Vidare, det nummer man får att ringa upp kan man knappast utgå ifrån att det är en hemlighet. Även om det är så att alla användare får ett eget, unikt nummer, vilket låter otroligt, är det svårt att se att det numret skulle kunna betraktas som en hemlighet att lita på.

Men det mest bekymmersamma med hela systemet är att det (att döma av artikeln) blir svårt att hantera säkerhetsproblem. Vad skall man göra om något så trivialt som att en användares mobil vars nummer har registrerats för en tjänst blir stulen? Att en användares mobil någon gång blir stulen är inte bara ett mer troligt scenario än att någon fejkar caller-ID, det är antagligen något som kommer att vara relativt vanligt.

Jag anser att bra säkerhet bygger på så få hemligheter som möjligt – och att dessa hemligheter är så lätta att byta ut som möjligt. En PIN-kod eller ett lösenord är bara en sekvens av tecken. Kan du inte lita på dom är det relativt lätt att byta ut dom. Att byta telefonnummer för att du inte kan lita på den längre för att logga in på din tjänst är inte alls lika enkelt.

Det vore intressant att veta hur Phonekey tänkt lösa dessa problem – hur spärrar man, byter nummer. Kan någon annan enkelt skicka in ett meddelande om att telefonen blivit snodd och att nu gäller ett annat nummer? Kan man säga att en given telefon blivit stulen och därmed orsaka ett DoS-problem för en användare?

Phonekeys mekanism kan ses som ett sätt att försöka krångla till accessen till en given tjänst genom att införa ett extra moment. Men att ersätta en PIN-kod med detta förfarande är fel. Det är snarare så att för att Phonekeys teknik över huvud taget skall ge en ökad säkerhet skulle dom behöva införa en PIN-kod som kopplar ett givet nummer (något du ev har) till kunskap om något (något du vet). Detta blir en så kallad tvåfaktors säkerhetslösning.

Och om det nu skulle visa sig gå fel – att caller-ID inte går att lita på, kommer Phonekey att täcka upp – vilka garantier lämnar dom?

Så tyvärr, jag tror inte på Phonekeys säkerhetslösning. Att dom får patent på den är ok, det finns många dumheter som patenterats. Det som vore tråkigt är om Phonekeys lösning används istället för bra, väl fungerande säkerhetsmekanismer. Att Fredrik Åhgren, VD för säkerhetsföretaget SE46 inte kan göra en vettig bedömning av Phonekeys hemmasnickrade säkerhetslösning är tyvärr lite skrämmande.

Draft med referensbeskrivning för ECC

May 11th, 2010

Det finns en intressant Internet Draft (I-D) av (David) McGrew från Cisco och Igoe från USAs National Security Agency.

David McGrew
David McGrew.

Draften Fundamental Elliptic Curve Cryptography Algorithms (draft-mcgrew-fundamental-ecc-02.txt) ger en referensbeskrivning av Elliptic Curve-krypto (ECC).

Varför är nu detta intressant? Jo – som författarna själva skriver:

The adoption of ECC has been slower than had been anticipated, perhaps due to the lack of freely available normative documents and uncertainty over intellectual property rights.
...
...
This note contains a description of the fundamental algorithms of ECC over fields with characteristic greater than three, based directly on original references. Its intent is to provide the Internet community with a summary of the basic algorithms that predate any specialized or optimized algorithms, which can be used as a normative specification. The original descriptions and notations were followed as closely as possible.
...
...
These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B.
(Notera att jag flyttat om ordningen på styckena.)

Jag håller med om att det länge behövts en bra beskrivning av ECC. Men att det Just är patenträttigheter på ECC som hållit tillbaka utvecklingen verkar de flesta vara överens om. Som någon på Cryptography-listan konstaterade ger draften inte bara en normativ beskrivning av ECC, den sammanställer även en referens som är mer än 15 år gammal och föregår därmed de patent som idag finns på ECC.

Längd på nycklar och säkerhet

May 10th, 2010

Jag har den senaste tiden fått flera frågor om längder på kryptonycklar – frågor om vad som är säkert, hur lång en assymetrisk nyckel skall vara för att motsvara en symmetrisk nyckel av en viss längd osv.

Det finns flera källor för information om nyckellängder. Den som ofta förekommer är den i idag något gamla boken Applied Cryptography av Bruce Schneier som i kapitel sju har ett längre resonemang om olika nycklar och längder.

Vidare har NIST publicerat rekommendationer om nyckellängder, deras rekommendationer är dock från 2007. Även IETF har publicerat en RFC, RFC 3766 - Determining Strengths For Public Keys Used For Exchanging Symmetric Keys som innehåller ett längre resonemang om nycklars styrka, hur nyckellängder behöver skala med tiden, samt rekommendationer för assymetriska nycklar.

Det många av dessa källor tyvärr har gemensamt är att dom inte uppdateras speciellt ofta (alls). Webb-baserade källor borde därför vara av intresse att titta närmare på.

WIkipedia har förvirrande nog (minst) två sidor i ämnet, dels en sida om nyckellängder och en sida om kryptonycklar, båda med text om nycklar och längder. Borde nog slås samman och städas upp för att det skall bli användbart.

När jag letat runt efter olika referenser hittade jag att belgiska konsultfirman BlueKrypt har en fin sida som sammanställer rekommendationer om nyckellängder.

Den i mitt tycke bästa källan är dock en rapport. ECRYPT Yearly Report on Algorithms and Key Lengths, utgiven av det EU-finansierade ECRYPT II-projektet.

Som namnet antyder är det här en rapport som uppdateras en gång om året. Den senaste versionen kom ut sommaren 2009. Rapporten innehåller ett ordentligt resonemang om hur nycklars styrkor bör värderas (inklusive diskussioner om metoder som NIST, IETF och andra använder). Resonemanget leder så småningom fram till ett antal rekommendationer.

En viktig sak man gör i ECRYPT II-dokumentet är att sätta in styrkan i nycklar i hur kostsamt (rent ekonomiskt) det är att attackera en viss längd:
Bild 2

Jämför dom sedan olika typer av nycklar – symmetriska, assymetriska baserade på RSA, logaritmer eller ellitic curves får kommer dom med följande rekommendationer:
Bild 3

Slutligen sätter dom in längderna i ett tidsperspektiv – hur lång tid kan man anta att en nyckel med en viss längd ger ett skydd:
Bild 1

Vill du skydda något i 10 år från idag bör du alltså välja minst 96 bitars symmetrisk nyckel eller en RSA-nyckel på drygt 2400 bitar.

Allt detta förutsätter dock att algoritmerna som används inte har några svagheter. Den andra delen av ECRYPTS rapport innehåller en genomgång av de vanligaste algoritmerna inom olika kategorier – krypton, hashfunktioner, signaturer etc (DES, 3DES, AES, RSA, MD5, SHA etc). För varje kategori och specifik algoritm presenterar ECRYPT aktuell status vad gäller säkerhet och kommer med rekommendationer om vad man bör och inte bör använda. Mycket bra läsning.

En sista sak: exportreglerna för krypto i Sverige säger maximalt 56 bitar symmetrisk kryptering och maximalt 512 bitars assymetrisk kryptering (antagligen RSA) eller 112 bitar (antagligen elliptic curve).

Ny Internet Draft: Test vectors for the stream cipher RC4

May 4th, 2010

Igår kväll släppte Simon Josefsson och jag den första versionen av en ny Internet Draft vi hackat på ett litet tag.

Test vectors for the stream cipher RC4 (draft-josefsson-rc4-test-vectors-00) försöker lösa ett problem vi ser finns när man försöker implementera varianter av strömkryptot RC4.

Eftersom RC4 från början inte är en öppen standard har det inte funnits en tydlig specifikation med testvektorer att använda för att verifiera att implementationen är funktionellt korrekt. Vidare, då RC4 har en del säkerhetsproblem – inte minst problemet med att den läcker nyckelinformation under de första genererade värdena efter initiering finns det ett antal versioner av RC4 där ett visst antal värden skall kastas bort.

Ett exempel på en sådan standard är Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol (RFC 4345). Denna standard beskriver två versioner av RC4, arcfour128 och arcfour256. För dessa versioner skall de första 1536 värdena kastas bort.

Vår draft innehåller testvektorer genererade med två olika typer av nycklar med längder från 40 till 256 bitar. För varje nyckel och nyckellängd specificerar vi 32 Bytes runt ett flertal punkter i nyckelströmmen, exempelvis just 1536. Under arbetet har vi testat ett flertal implementationer av RC4 i exempelvis libgcrypt och andra bibliotek så väl som fristående implementationer, detta för att få så stor konfidens i att vektorerna är korrekta som möjligt.

Vi skulle uppskatta kommentarer och synpunkter på draften så om du läst igenom, ser något fel som strular, kommer på något som borde vara med, tas bort eller ändras – hör av dig till mig eller Simon!

Tack!

Beslut om förstärkt IT-incidentberedskap

April 15th, 2010

Enligt ett pressmeddelande från igår 2010-04-14 har Regeringen fattat beslut om förstärkt IT-incidentberedskap:


För att stärka samhällets informationssäkerhet och förmåga att förebygga och hantera IT-incidenter har regeringen idag beslutat om följande uppdrag till Myndigheten för samhällsskydd och beredskap (MSB) samt Försvarets radioanstalt (FRA).

Säker digital informations- och kommunikationsinfrastruktur säkerställer samhällets incidenthanteringsarbete
– I samhället finns det behov av en administrativ och teknisk infrastruktur för informationsdelning och respons där samtliga aktörer av betydelse för informationsinfrastruktur bör finnas representerade. MSB ska därför lämna förslag på hur en säker digital informations- och kommunikationsinfrastruktur för myndigheter, kommuner och landsting kan skapas. Uppdraget handlar inte om att bygga helt ny infrastruktur. Systemet ska närmast bygga på samt nyttja befintlig infrastruktur. MSB ska genomföra uppdraget i samråd med andra berörda aktörer bland andra de som ingår i SAMFI (Försvarets radioanstalt, Försvarets materielverk, Post- och telestyrelsen, Försvarsmakten och Säkerhetspolisen), Totalförsvarets forskningsinstitut, Skatteverket samt Delegationen för e-förvaltning.

Nationell plan för att hantera IT-incidenter och klargöra ansvar och roller
– Det finns behov av att klargöra ansvar och roller på nationell nivå samt att ange processer och rutiner för den nationella hanteringen av IT-incidenter. Utgångspunkten är ansvarsprincipen. MSB ska därför ta fram en nationell plan som klargör hur allvarliga IT-incidenter ska hanteras samt skapa tekniska kompetensnätverk av experter som kan stödja samhället vid allvarliga IT-incidenter för att skapa en ökad förmåga till respons. Planen ska också ta hänsyn till den viktiga roll som näringslivet och andra organisationer har. MSB ska genomföra uppdraget i samråd med andra berörda aktörer bl.a. de som ingår i SAMFI (Försvarets radioanstalt, Försvarets materielverk, Post- och telestyrelsen, Försvarsmakten och Säkerhetspolisen), Totalförsvarets forskningsinstitut, Skatteverket samt Delegationen för e-förvaltning.

Obligatorisk incidentrapportering för statliga myndigheter
– Det finns ett behov av incidentrapportering hos statliga myndigheter för att löpande kunna bidra till en aktuell lägesbild av tillståndet vid samhällsviktig verksamhet och kritisk infrastruktur. MSB därför ska utreda hur ett system för obligatorisk IT-incidentrapportering för statliga myndigheter kan utformas. Övriga aktörer i samhället bör erbjudas att på frivillig basis delta i ett sådant system.

Analysera och bedöma omvärldsutvecklingen avseende hot, sårbarheter och risker inom informationssäkerhetsområdet – bidrar till att prioritera skyddsåtgärder

– I arbetet med att prioritera skyddsåtgärder ingår att analysera och bedöma omvärldsutvecklingen avseende hot, sårbarheter och risker inom informationssäkerhetsområdet. MSB ska därför kontinuerligt analysera och bedöma omvärldsutvecklingen avseende hot, sårbarheter och risker inom informationssäkerhetsområdet samt konsekvenser för viktiga funktioner i samhället. MSB:s rapportering ska beskriva hot, sårbarheter och risker på informationssäkerhetsområdet kopplat till de åtgärdsförslag som föreslås i den nationella handlingsplanen för informationssäkerhet.

IT-säkerhetsanalyser – hjälp för att höja säkerheten hos myndigheter
– För att skapa en tydligare koppling av informationssäkerhet till samhällets krisberedskap och arbetet med samhällsviktig verksamhet och kritisk infrastruktur ska MSB ha möjlighet att föreslå myndigheter att anlita Försvarets radioanstalt (FRA) för IT-säkerhetsanalyser. MSB ska ha möjlighet att utifrån analyser av förmågebedömningar, genomförda risk- och sårbarhetsanalyser samt bedömningar av beroendeförhållanden föreslå enskilda myndigheter att anlita FRA för IT-säkerhetsanalyser. I dag genomför FRA IT-säkerhetsanalyser hos myndigheter som efterfrågas stöd för detta.

Tidig förvarning / upptäckt av IT-intrång möjliggör snabba motåtgärder

– I dag saknas det möjlighet att skapa en helhetsbild som omfattar detektering av verkliga och potentiella intrång i informationssystem. Som ett bidrag till att stärka lägesbilden samt för att skapa möjlighet till förvarning ska MSB lämna förslag på hos vilka aktörer ett tekniskt detekterings- och varningssystem för samhällsviktig verksamhet och kritisk infrastruktur kan införas. MSB ska särskilt beakta det uppdrag till FRA som regeringen beslutat om den 14 april 2010.

Utformning av detekterings- och varningssystem mot intrångsangrepp
– I dag saknas det möjlighet att skapa en helhetsbild som omfattar detektering av verkliga och potentiella intrång i informationssystem. Som ett bidrag till att stärka lägesbilden samt för att skapa möjlighet till förvarning ska FRA lämna ett förslag på hur ett tekniskt detekterings- och varningssystem för samhällsviktig verksamhet och kritisk infrastruktur kan utformas och införas. Detta system syftar till att stärka skyddet för samhällsviktig verksamhet och kritisk infrastruktur. FRA ska särskilt beakta det uppdrag till MSB som regeringen beslutat om den 14 april 2010.

Att myndigheterna och andra offentliga aktörer kan kommunicera på ett säkert sätt är en förutsättning för god nationell informationssäkerhet. I det svenska samhället behövs en administrativ och teknisk infrastruktur vid kriser och olyckor för informationsdelning och respons i vid mening, där samtliga aktörer av betydelse för samhällets kritiska informations¬infra¬struktur finns representerade. En sådan stödorganisation och infrastruktur behöver ha en hög informationssäkerhet för att inte slås ut vid allvarliga störningar. Regeringen anger i budgetpropositionen för 2010 (prop.2009/10:1, bet 2009/10:FöU1, rskr. 2009/10:104) att rapportering av IT-incidenter som utgör hot mot eller medför allvarliga konsekvenser för samhällsviktig verksamhet och kritisk infrastruktur behöver förbättras.

Storskaliga IT-incidenter blir snabbt tvärsektoriella frågor som kräver ett samfällt agerande från många olika aktörer. Vid angrepp som drabbar kritisk infrastruktur och samhällsviktig verksamhet saknas det för närvarande möjlig¬het att skapa en samlad lägesbild. En sådan lägesbild handlar dels om att detektera verkliga och potentiella intrång, dels om att studera avvikelser från normalbilden. I dag förfogar nätoperatörerna och andra aktörer var och en över sin del av lägesbilden, men ingen av dem kan i dag se helheten.

Uppdragen ska redovisas senast 1 mars 2011 till Regeringskansliet (Försvarsdepartementet).

MSB fick alltså huvudansvar och rollen som förare.

Informationssäkerhet.se

April 12th, 2010

Myndigheten för Samhällsskydd och Beredskap (MSB) har startat en ny webbsida om informationssäkerhet kallad… Informationssäkerhet.se.

Just nu finns det inte så mycket information på webbsidan annat än beskrivning av syftet och vad som avses att komma:

Här ska du snart hitta stora delar av det stödmaterial du behöver för att arbeta med informationssäkerhet på ett systematiskt sätt. Informationsmängden på webbplatsen är i nuläget begränsad men kommer att växa efter hand.

På webbplatsen publicerar vi inte bara färdiga produkter. Det är lika viktigt att ta tillvara kunskap och erfarenhet från praktiskt informationssäkerhetsarbete. Du kan följa och delta i arbetet med att ta fram stöd genom att lämna synpunkter på dokument under framställan. Målet är att skapa praktiskt användbara och konkreta resultat med en bred förankring.

Mycket på webbsidan handlar om dokument och processer för att arbeta med Informationssäkerhet. Det finns bland annat en fin vattenfalls-figur på sidan om

Tyvärr verkar det inte gå att surfa säkert till Informationssäkerhet.se. Försöker man ta sig dit med HTTPS får man ingen kontakt.

OpelSSL når 1.0.0

March 30th, 2010

OpenSSL, Open Source-biblioteket som implementerar Secure Sockets Layer (SSL v2/v3) och Transport Layer Security (TLS v1) släpptes igår (2010-03-29) i version 1.0.0.

OpenSSL

Den nya releasen innehåller ett flertal fixar och nyheter (ChangeLog), men varför man valde att gå till 1.0.0 nu är inte helt klart. OpenSSL som projekt startade i december 1998 och första versionen var 0.9.1c(!). Sedan dess har man under nästan tolv års tid harvat med 0.9.x-inkrement.

Psykologiskt är det dock viktigt att det nu finns en 1.x-version av OpenSSL – för en utomstående kan det vara svårt att tro att något med version 0.9.8n är stabilt och lämpligt att använda i seriösa tilämpningar. Tittar man längst upp i ChangeLog ser det ut som att nästa version kommer att heta 1.1.0 så dom verkar gå mot mer normala versionsnummer.

För den som vill tanka ner version 1.0.0 av OpenSSL finns den här.

Uppdaterad 2010-03-31:
Hittade en pressrelease från OpenSSL som beskriver 1.0.0-releasen:


The OpenSSL project team is pleased to announce the release of version 1.0.0 of our open source toolkit for SSL/TLS. This new OpenSSL version is a major release and incorporates many new features as well as major fixes compared to 0.9.8n. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES .

The most significant changes are:

o RFC3280 path validation: sufficient to process PKITS tests.
o Integrated support for PVK files and keyblobs.
o Change default private key format to PKCS#8.
o CMS support: able to process all examples in RFC4134
o Streaming ASN1 encode support for PKCS#7 and CMS.
o Multiple signer and signer add support for PKCS#7 and CMS.
o ASN1 printing support.
o Whirlpool hash algorithm added.
o RFC3161 time stamp support.
o New generalised public key API supporting ENGINE based algorithms.
o New generalised public key API utilities.
o New ENGINE supporting GOST algorithms.
o SSL/TLS GOST ciphersuite support.
o PKCS#7 and CMS GOST support.
o RFC4279 PSK ciphersuite support.
o Supported points format extension for ECC ciphersuites.
o ecdsa-with-SHA224/256/384/512 signature types.
o dsa-with-SHA224 and dsa-with-SHA256 signature types.
o Opaque PRF Input TLS extension support.
o Updated time routines to avoid OS limitations.


We consider OpenSSL 1.0.0 to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible.

Riksdagen erbjuder access till data

March 26th, 2010

Riksdagen har idag lanserat ensyndikeringstjänst där man erbjuder data via API så att andra kan bygga applikationer som använder datat!

Riksdagen

Det här är kanonspännande! OpenGov börjar ta fart i Sverige. För den som är snabb startade precis ett seminare på Stockholms handelskammare om Offentliga data som plattform för utveckling av nya tjänster. Spring dit och få det senaste!

ACTA har läkt ut

March 24th, 2010

ACTA - Anti-Counterfeiting Trade Agreement, det stora, internationella avtalet om immateriella rättigheter som förhandlas fram bakom stängda dörrar har läkt ut. På The Pirate Bay finns just nu en torrent för att ladda hem avtalet.

TPB - ACTA-gubbe

Michael Geist är en person som är i full färd med att analysera ACTA-avtalet och bloggar om vad han hittar samt nyheter om ACTA.

Michael Geist
Michael Geist

Kolla in Michaels blogg, väl värd att läsa.