Da etterretningstjenesten NSAs masselagring av data om amerikaneres telefonsamtaler ble kjent gjennom graderte dokumenter lekket til mediene av Edward Snowden, leverte flere aktivister i USA søksmål mot staten med påstand om at masselagringen krenker deres grunnlovfestede personvern.

I går kom den første kjennelsen i disse søksmålene.

Dommer Richard Leon ved distriktsretten i USAs hovedstad – US District Court for the District of Columbia – skrever at masselagringen «høyst sannsynlig krenker grunnloven».

Kjennelsen inneholder en rettslig forføyning om at masselagringen må opphøre fram til det foreligger en endelig avklaring om hvorvidt grunnloven faktisk er krenket.

Slike forføyninger trer normalt i kraft umiddelbart. Leon utsetter iverksettelsen med seks måneder, med henvisning til at betydelige nasjonale sikkerhetsinteresser står på spill, og til behovet for en grundigere diskusjon av de konstitusjonelle problemstillingene saken reiser. Han truer med «tilhørende straffetiltak» dersom staten skulle finne på å be om en ytterligere utsettelse.

Kjennelsen utfordrer hele det juridiske grunnlaget for NSAs masseinnsamling og masselagring av telefondata.

Den utfordrer også de 15 dommerne som ved 35 ulike anledninger – alle i den hemmelige domstolen Foreign Intelligence Surveillance Court (FISC) – har slått fast at virksomheten er lovlig. Det er første gang masselagringen er vurdert juridisk av en uavhengig og fri domstol. Kjennelsen har følgelig stor symbolverdi, selv om den ikke får umiddelbare praktiske følger.

Kjennelsen omfatter to søksmål mot den amerikanske staten, fra en konservativ aktivist, Larry Klayman, gründer i den ideelle organisasjonen Freedom Watch. Organisasjonen har publisert hele kjennelsen (pdf, 68 sider).

Kjennelsen er også publisert av New York Times. Denne artikkelen siterer videre en uttalelse fra Edward Snowden, distribuert av frilansjournalist Glenn Greenwald: Snowden sier han lekket NSA-dokumentene fordi han var overbevist om at masseovervåkningen er grunnlovsstridig, og at amerikanske borgere fortjener at spørsmålet behandles i en åpen rett. Han tror kjennelsen vil bli den første i en lang serie med samme syn.

Andre ideelle organisasjoner som har levert liknende søksmål er American Civil Liberties Union (ACLU) og Electronic Frontier Foundation (EFF). Begge er i et tidlig stadium av rettslig prosess.

En fjerde gruppe, Electronic Privacy Information Center, prøvde å gå direkte til USAs høyesterett med sin utfordring til masseovervåkningen. Høyesterett avviste å behandle dette i november.

Det er flere juridiske spissfindigheter i dommer Leons kjennelse. Leon må argumentere for at han faktisk har myndighet til å vurdere hvorvidt han, som distriktsdommer, har myndighet til å behandle en konstitusjonell utfordring til NSA, siden etterretningstjenesten sorterer under den hemmelige domstolen FISC. Han må også argumentere for at Klayman er gyldig utfordrer som vil lide uopprettelig skade dersom masseovervåkningen fortsetter.

Det gjør han til gangs. Selv om den holder seg strengt til tørr juridisk terminologi, er kjennelsen en harmdirrende kritikk av NSAs praksis. Leon viser til grunnlovens fjerde tillegg («Fourth Amendment») som verner amerikanske borgere mot urimelig ransaking og beslag. Han argumenterer for at NSAs masseinnsamling, masselagring og analyse av telefondata utgjør en ransaking og et beslag i grunnlovens forstand, og skriver at Klayman med stor sannsynlighet vil vinne fram med en påstand om at ransakingen og beslaget også er urimelig. Han viser til at FISC-domstolens behandling av dette hviler på en høyesterettskjennelse fra 1979: Teknologi og personvern har gjennomgått så store endringer de siste 34 årene at dette er et utilstrekkelig grunnlag å vurdere masseovervåkningen på, ifølge Leon.

Leon begrunner videre at den offentlige interesse og faren for at overvåkningen også skader andre enn saksøkerne taler for at den må opphøre.

En talsperson for USAs justisdepartement, Andrew Ames, sier til amerikanske medier at departementet er i ferd med å sette seg inn i kjennelsen, og at man inntil videre holder fast ved at NSAs virksomhet er i samsvar med grunnloven.

DEBATT: Etter drøye 10 år med stort fokus på automatisert testing, ønsker jeg å vurdere hvor dette har tatt oss, og om omfanget av automatisert testing legges på et fornuftig nivå.

Jeg har opplevd at dette er et tema som kan være vanskelig å diskutere med mange utviklere, da det har en lei tendens til å oppstå litt «religiøsitet» hos endel. Å argumentere for mindre bruk av automatisert testing kan lett bli som å argumentere for mindre «sikkerhet» på flyplasser.

Det skal betydelig argumentasjon til for at folk vil lytte, og det er mye lettere å få gjennomslag andre veien, for folk ønsker jo sikkerhet. Men man må spørre seg om alle rutinene på dagens flyplasser gir mer sikkerhet, eller om noen av rutinene er fåfengte forsøk på å få det.

I flere anbudsforespørsler de senere årene har det vært krav om at systemet skal ha «100 prosent testdekning».

Jeg er usikker på om de som krever dette vet hva de ber om. I en bokstavelig, teknisk forstand betyr dette at hver eneste kodede funksjon og «vei» i hver enkelt funksjon skal testes at den virker som forutsatt. Man ender da raskt opp med betydelig større mengder testkode enn reell kjørekode. Det synes også implisitt forutsatt at det ikke vil være feil i testkoden…

Jeg etterlyser et mer edruelig forhold til automatiserte tester. Jeg mener testing bør holdes på et nivå hvor den gjør mer nytte enn skade.

I Ciber Norge har vi vært gjennom mange Java-prosjekter med ulik grad av automatisert testing, og brukt ulike rammeverk for dette. Eksempler er jUnit, Selenium og FitNesse, og noen prosjekter har benyttet verktøy som Cobertura for å vurdere testdekningen i prosjektet. Våre prosjekter er ofte i en mellomstørrelse, total prosjektstørrelse mellom 1 000 og 10 000 timer, og gjerne for kunder i offentlig sektor. Prosjektene våre har brukt Test Driven Development (TDD) i varierende grad. Noen prosjekter har vært utført helt uten TDD, men har valgt å skrive tester for utvalgte deler av koden i etterkant.

Hva er fordelene med automatisert testing? Jeg vil her forsøke å trekke frem de viktigste. Vær oppmerksom på at jeg ikke her fokuserer på fordeler ved bruk av TDD, da dette kan være andre.

• Man kan videreutvikle koden og være rimelig sikker på at det man gjør ikke bryter med de forutsetningene som er gjort i koden.
• Bedre støtte ved vedlikehold av koden i ettertid. Dette gir spesielt store fordeler når utviklere byttes ut.
• Man får gradvis luket ut feil ettersom man legger til nye tester når feil forekommer.
• Man kan enkelt kjøre en «suite» av tester som gjør manuell regresjonstesting mindre omfattende.
• Testene forenkler samkjøring av flere utviklere som jobber mot samme kodebase.

De fleste utviklere er enige om at automatiserte tester gir fordelene nevnt ovenfor. Men ulik bruk av automatiserte tester gir ulik grad av disse fordelene i forhold til hvor mye tid eller arbeid som legges ned i å utvikle og vedlikeholde testene.

Som i eksemplet ovenfor om sikkerhet på flyplasser, vil det alltid være mulig å legge til nye og mer omfattende rutiner for å skape sikkerhet, men på et eller annet nivå vil den økte sikkerheten ikke stå i forhold til ulempene det medfører for passasjerene å gjennomføre de aktuelle rutinene. Man kunne for eksempel nekte all form for glassprodukter eller metallbestikk etter sikkerhetskontrollen, slik at disse ikke kan benyttes til å kapre fly. Dette vil medføre betydelige problemer for restauranter og taxfreesalg, og vil neppe gi den helt store sikkerhetseffekten. Dette avspeiler seg i «Law of diminishing returns». Se illustrasjonen øverst i denne artikkelen: Kurven som viser når det er hensiktsmessig å avslutte innsatsen, fordi økt innsats ikke vil gi økt utbytte.

Det er ikke nødvendigvis slik at behovet for kontroll er det samme i alle prosjekter. Det som kan gi god og ønsket kontroll i et stort prosjekt med mange utviklere, kan være en hemsko i et mindre prosjekt med få utviklere. Et eksempel her kan være et webprosjekt med et lite og oversiktlig brukergrensesnitt som tar kort tid å teste manuelt. Hvis man i en slik situasjon benytter et webtestrammeverk for å teste frontend, kan det skape betydelige merkostnader ved videreutvikling eller modernisering, uten at testoppsettet nødvendigvis ga så mye merverdi selv når det ble satt opp første gang.

En omfattende «suite» av automatiserte tester kan også gjøre det mer arbeidskrevende å refaktorere moduler i koden.

Noen vil nok innvende at man med fornuftig strukturering av koden vil kunne kjøre de samme testene på modulen når den er ferdig refaktorert. I en ideell verden ville jeg vært enig, men ofte er årsaken til refaktoreringen nettopp at modulen eller grensesnittet til denne ikke ble strukturert og utviklet på beste vis i første runde. Full testdekning i modulen vil da gjøre refaktoreringen mer arbeidskrevende, og i mange situasjoner vil det i tillegg til refaktorering av selve koden være nødvendig med omfattende refaktorering av testkoden.

Arbeidet som utføres for å forhindre feil, i dette tilfellet automatisert testing, bør også til en viss grad ses opp mot konsekvensen av feil.

I noen prosjekter, for eksempel ved utvikling av IT-systemer for sykehusene som i verste fall kan bety liv eller død for pasientene, må man ha et annet forhold til konsekvensene av feil enn hvis man utvikler spill for barn. Jeg mener ikke å bagatellisere feil i mindre kritiske systemer, og jeg er helt innforstått med prinsipper for «craftsmanship», men det må alltid gjøres avveininger i forhold til økonomi i prosjektet eller om man skal prioritere funksjonalitet fremfor utvidet testsuite.

En innvending mot automatisert testing har vært at testene gir en slags falsk trygghet for de som skal videreutvikle koden. Dette er mulig, uten at jeg har sett klare tegn til det.

Uansett er det en forutsetning at de som skal videreutvikle koden har full forståelse for hvordan koden henger sammen. En solid testsuite kan gi en god «dokumentasjon» av koden, slik at det er lettere å få forstå hvordan den er ment å virke. En middels god eller utdatert testsuite kan skape mer forvirring enn oversikt. Man må derfor være klar over at testene og mockede objekter må videreutvikles i parallell med koden. En slurvet holdning her vil fort føre til at testsuiten forvirrer mer enn den hjelper.

Kvaliteten på testkoden er like viktig som kvaliteten på kjørekoden.

Jeg har sett eksempler på at man for å kunne teste deler av koden, åpner opp koden mer enn man ellers ville gjort. I slike tilfeller fører testingen til at man har mindre kontroll enn man ville hatt uten testene. Kvalitetssikring av testkoden er altså viktig, og må ikke nedvurderes i forhold til kvalitetssikring av kjørekoden.

Finnes det noe alternativ til automatisert testing? Nei, ikke noe som oppnår helt det samme, men det er fremdeles mulig å benytte mange kjente, kjære teknikker og prinsipper for å utvikle kode som har liten sannsynlighet for feil. I endel tilfeller vil dette være godt nok, i hvert fall på deler av koden.

Hva er så et fornuftig nivå for automatisert testing?

Som nevnt er dette avhengig av systemet som skal utvikles, dets størrelse og i hvilken grad konsekvensen av feil er kritisk. Hvis man forutsetter at prosjektet skal utvikle et system som ikke dreier seg om liv og død ved feil, og er i en størrelsesorden 5 000 til 10 000 timer, vil jeg anbefale følgende strategi for (automatisert) testing og kvalitet:

• Legg forretningslogikken i modellen, og test denne.

Sørg for at så mye som overhodet mulig av forretningslogikken ligger i domenemodellen. Ha denne som en separat del av koden (for eksempel som eget prosjekt i utviklingsverktøyet). Etterstreb høy testdekning (med jUnit eller lignende) av den viktige koden i denne delen av systemet (det vil si ikke test «gettere og settere» og slikt, men der hvor det finnes kode med risiko for feil).

• Trekk ut generelle funksjoner, og test disse.

Sørg for at alle funksjoner som kan generaliseres på fornuftig vis, blir generalisert, og at resten av koden benytter denne mer generelle koden. Hvis du så sørger for at denne koden blir testet, unngår du mange feil uten å utforme mengder av testkode.

• Bruk «Single Responsibility Principle», og lukk koden.

Strukturer koden din slik at klassene i så stor grad som mulig har et rent og oversiktlig grensesnitt mot resten av applikasjonen. Sørg for å beskytte klassevariable for påvirkning utenfra. Hvis det er vanskelig å teste all funksjonaliteten i klassen uten å åpne opp med ekstra metoder eller å gjøre klassevariable tilgjengelige utenfra, er det ofte et tegn på at det kan være fornuftig å omstrukturere klassen til mindre klasser.

• Gjør det lett å finne ut hva en feil kommer av.

Sørg for nullsjekking av parametere, slik at man lett kan identifisere hva som forårsaker feil. Hvis du er i tvil om en feilsituasjon noengang vil oppstå, og om du trenger å ta hensyn til den, kast alltid en exception som beskriver hva som har skjedd.

• Kvalitetssikre all testkode på samme nivå som kjørekoden.
• Vurder om enkelte deler av applikasjonen er godt nok testet.

I mange applikasjoner er det funksjoner som er kritisk i sin natur. I en nettbutikk er det for eksempel kritisk å ha på plass rutiner som sørger for at ikke priser er null eller betydelig lavere enn det korrekte tallet. Vurder om det finnes slike caser i din applikasjon, og om det trengs ekstra rutiner som forhindrer slike feil.

Jeg mener man ved en slik tankegang vil kunne utvikle systemer som er rimeligere, og hvor automatisk testing står i et fornuftig forhold til systemets behov.

Det kommer fram i et innslag som tirsdag skal sendes i programmet Ekot på Sveriges Radio. Blant dem som har følt seg presset, er toppsjefen i det svenske selskapet Bahnhof, Jon Karlung. Han har selv gjort opptak med skjult mikrofon under møtet med Säpo.

– Nå smeller det
Når Karlung stiller spørsmål ved om Säpo virkelig må ha direkte tilgang til hundretusener av svenskers aktivitet på mobiltelefon og internett, får han dette svaret:

– Vi mistenker et terrorangrep i Stockholm sentrum og får inn informasjon som gjør at det er verdifullt for oss å eliminere. Og dette får vi fredag kveld klokka 20 utenom kontortid. Svaret, med manuell håndtering, innebærer at vi får leveransen mandag formiddag. Da smeller det i Stockholm sentrum med 800 døde, sier Säpos signalstrategiske rådgiver Kurt Alavaara.

Blir presset
Flere teleoperatører har fortalt om lignende press. Blant annet har de fått beskjed om at de løper terroristenes ærend hvis de ikke leverer ut opplysninger. Samtidig blir de lovet at kundene aldri vil få greie på at de samarbeider.

Tele2s sjefjurist Stefan Backman bekrefter overfor TT at selskapet er blitt presset.

– Absolutt. Og det er direkte ubehagelig for oss, som forsøker å ta kundenes integritet på alvor, å bli utsatt for slikt press fra svenske myndigheter, sier Backman.

Han sier at Säpo også i andre saker har brukt en lignende retorikk, og han er spesielt kritisk til Säpos argument om at kundene ikke vil få vite noe.

Ifølge juristen ville kundene ha vært de første som fikk vite det hvis Säpo ble gitt det han kaller «en motorvei» inn til selskapets system.

– Ubehagelig
Professor i kriminologi, Janne Flyghed, har lyttet gjennom de i alt fire timer lange opptakene. Hun mener at teleoperatørene åpenbart blir utsatt for press.

– Det føles litt som man holder på med en stor markedsføringskampanje. Man må få igjennom dette, og her opererer man både med løfter og delvis med trusler for å få disse operatørene til å gå med på dette. De blir åpenbart presset. Det føles ubehagelig å høre på denne type kommunikasjon, sier Flyghed til Ekot. (©NTB)

Anonyme kilder med angivelig kjennskap til Microsofts planer for Wndows Phone 8.1 forteller til The Verge at den kommende oppdateringen vil inkludere funksjonalitet som bringer systemet mer opp på høyde med Android og iOS når det gjelder funksjonalitet.

Det ene er en Siri-lignende personlig assistent med kodenavnet Cortana. Navnet stammer forøvrig fra spillet Halo, i likhet med Threshold-navnet som trolig refererer til en framtidig bølge med Windows-oppdateringer. I Halo er Cortana en rollefigur med kunstig intelligens som kan lære og tilpasse seg. Cortona er altså et ganske passende navn på denne kommende funksjonen.

Ryktet om Cortana er forøvrig ikke helt nytt.

Siri kom til iOS i 2011. Googles variant, Google Now, kom nesten et år senere. De har sine ulike styrker og svakheter, men regnes for tiden som omtrent like gode og betydelig bedre enn for et år siden. Google Now tilbys forøvrig også til iOS.

Den andre store nyheten som trolig kan ventes i Windows Phone 8.1, er et varslingssenter som kan dras ned fra toppen av skjermen, slik man lenge har kunnet i Android og senere også i iOS. Her vises varslene fra både operativsystemet og de ulike applikasjonene på ett og samme sted.

Andre nyheter som ifølge disse kildene kan ventes i den kommende oppdateringen, er separate kontroller for lydstyrken til ulike funksjoner, for eksempel ringetonen og medieavspillingen. Det antydes også at Bing Smart Search vil komme på plass, slik det er i Windows 8.1. Dessuten skal det innebygde musikknavet erstattes med separate apper.

Alt tyder på at Windows Phone 8.1 vil bli gitt ut i tidsrommet rundt Microsofts kommende Build-konferanse, som arrangeres i San Francisco i april.

Ifølge Georgia Institute of Technology, også kjent som Georgia Tech, er det en virkelig stor utfordring knyttet til nanomaskiner – virkelig små datamaskiner egnet for å utføre enkle oppgaver, for eksempel å overvåke og utveksle sensordata – nemlig antennen.

Dersom også antennen lages i nanometerstørrelse og i kobber, vil radiosignalene måtte ha en frekvens på hundrevis av terahertz. Med så høye frekvenser har signalene bare noen få mikrometer. I tillegg kreves det mye effekt, noe nanomaskiner sjelden vil kunne levere, siden noe av målet er at de skal kunne kjøre på energi hentet fra omgivelsene.

Alternativet er større antenner, men da vil antennene være langt større enn datamaskinene, og dermed forsvinner mye av vitsen.

Grafén
Men nå kan forskere ved Georgia Tech ha funnet en løsning basert på «vidundermaterialet» grafén, som har en rekke svært interessante egenskaper. Grafén består av et lag med karbonatomer som danner et bikake-lignende gitter. Dette kan danne en elektrisk overflatebølge som gjør det mulig å lage antenner som bare er 1 mikrometer lange og 10 til 100 nanometer brede, og som kan gjøre den samme jobben som mye større antenner.

Til tross for størrelsen mener forskerne at den vil kunne operere i den nedre enden av terahertz-området, mellom 0,1 og 10 terahertz.

Dette oppnås ved hjelp av det som kalles for en SPP-bølge (Surface Plasmon Polariton).

– Når elektroner i grafénet blir eksitert av for eksempel en innkommende, elektromagnetisk bølge, begynner å de å bevege seg fram og tilbake. På grunn av de unike egenskapene til grafén, resulterer denne globale oscilleringen av elektrisk ladning i en avgrenset bølge på toppen av grafénlaget, forteller Ian Akyildiz, professor i telekommunikasjon ved Georgia Techs School of Electrical and Computer Engineering, i en pressemelding.

Forplantning av SPP-bølger er ikke noe unikt ved grafén. Det kan også støttes av en del edle metaller, slik som gull og sølv, men ifølge Georgia Tech skjer dette ved langt høyere frekvenser enn det som man mener er tilfellet med grafén. For det er nemlig ikke slik at forskerne har demonstrert dette ennå. Antagelsen er basert på modellering og simulering.

Forskerne er likevel svært optimistiske når det gjelder mulighetene disse egenskapene kan bidra til. I pressemeldingen opplyses det at effektbehovet kan reduseres med fire størrelseordener i forhold til kobberbaserte antenner. Men det sies ingen ting om rekkevidden, selv om reduksjon av frekvensen med 99 prosent nok betyr ganske mye.

– Vi tror at dette bare er begynnelsen på en nytt paradigme for nettverk og kommunikasjon basert på grafén, sier Akyildiz.

Science fiction?
Dette handler ikke bare om kommunikasjon internt i et nettverk av nanodatamaskiner. Man ser nemlig også for seg at samlinger med hundre- eller tusenvis av knøttsmå transceivere, utstyrt med grafénantenner, kan gi mer tradisjonelle datamaskiner mer trådløs båndbredde.

– Terahertz-båndet kan øke dagens datarater i trådløse nettverk med mer enn to størrelsesordner. Dataratene i dagens mobilsystemer er på opptil én gigabit per sekund i LTE Advanced-nettverk og 10 gigabyte per sekund i såkalte millimeter-bølge- eller 60 gigahertz-systemer. Vi venter datarater i terabit per sekund-størrelsen i terahertz-båndet, sier Akyildiz.

Nøyaktig hvordan dette er tenkt å fungere, er ikke oppgitt, men omtales kanskje i en vitenskapelig artikkel om forskningen som er planlagt publisert i IEEE Journal of Selected Areas in Communications.

Neste mål for forskerne vil være å lage en faktisk nanoantenne i grafén og bruke den sammen med en transceiver som også er laget av grafén.

Som digi.no har skrevet om i en rekke kommentarer og artikler har de indiske IT-gigantene, med Tata Consultancy Services og HCL i spissen, snappet flere store kontrakter i Norge.
Men også i Danmark opplever de etablerte aktørene i IT-markedet konkurranse fra de indiske aktørene.

Den danske forsikringskjempen Tryg, som også er tungt representert i det norske markedet, rapporterer mandag at de har sagt opp sin avtale med CSC Danmark. En ny IT-driftsavtale forventes å bli inngått med TCS. I pressemeldingen fra Tryg fremgår det ikke hvor stor verdi avtalen har.

Tidligere i vinter meldte DNB om at de kaster ut Evry som IT-driftsleverandør på bekostning av indiske HCL. DNB skal etter planen melde hvem som får avtalen for drift av stormaskin-miljøet, men dersom Evry ikke vinner denne er de radert ut som en stor leverandør til Norges desidert største bank.

CSC er på mange måter det danske svaret på Evry. Selskapet mistet tidligere i år en viktig stor-kontrakt for flyselskapet SAS til nettopp TCS. Ifølge Computerworld Danmark skal også TDC, tidligere telemonopolet i Danmark, ha sagt opp sin avtale med CSC.

I 1996 kjøpte amerikanske CSC 75 prosent av aksjene i «Datacentralen I/S af 1959» som var offentlig eid. De har en rekke danske offentlige etater på kundelisten, samt at de hadde en rekke private storselskaper som oppdragsgivere.

Telenors sikkerhetssenter i Arendal, Security Operations Center (TSOC), advarer i et nyhetsbrev om angrep mot sårbare PHP-installasjoner.

De har «observert en formidabel økning» i skanninger etter Linux-maskiner med sårbar installasjon av kombinasjonen Apache webserver med PHP 5.x de siste dagene.

– Dersom en maskin lar seg utnytte, lastes det ned en IRC-basert DDoS-bot. Det settes også opp en cron-jobb for å søke etter ukentlige oppdateringer, skriver Telenor.

Eldre feil
Den aktuelle sårbarheten ble registrert for halvannet år siden (CVE-2012-1823) og åpner for injisering av kode i PHP versjon 5.4.1 og eldre.

Hullet ble lukket i etterfølgeren 5.4.2 som ble lansert allerede i mai 2012. Rådet Telenor gir er å oppfordre alle som benytter Apache og PHP på Linux om å forsikre seg at systemet er oppdatert med de seneste versjonene.

Den internasjonale elektrotekniske kommisjonen IEC (International Electrotechnical Commission) publiserte i dag den første globale spesifikasjonen for en standard lader for bærbare pc-er. IEC har arbeidet med å utforme standarden siden 2010.

I 2009 ble store leverandører av mobiltelefoner enige om å innføre en felles standard for mobiltelefonladere. Denne standarden ble publisert av IEC 1. februar 2011. Siden har nær sagt alle nye mobiltelefoner, med unntak av Apple iPhone, fått lader i samsvar med standarden. iPhone har proprietær plugg, men laderen er ellers konform med standarden. Det finnes adaptere som gjør at også iPhone kan lades fra standardladere.

IEC 62700 spesifiserer standardlader for bærbare pc-er, inklusiv ledning og plugg. Standarden omfatter også krav til sikkerhet, ytelse og miljø. IEC tror standarden kan legge et grunnlag for at alle nye bærbare pc-er vil kunne bruke samme lader.

Generalsekretær Frans Vreeswijk i IEC tror universalladeren for bærbare pc-er vil være et vesentlig bidrag til å redusere mengden elektronisk søppel som må behandles hvert år. IEC anslår at det hvert år kastes over 500 000 tonn for alle typer IKT-utstyr.

Kort tid etter at Android 4.3 ble gjort tilgjengelig i juli, oppdaget brukere en skjult og deaktivert funksjon i operativsystemet som kalles for App Ops. Denne kunne lokkes fram ved hjelp av et tredjepartsverktøy og brukes til å begrense tilgangen til applikasjoner har til ulike funksjoner i operativsystemet, for eksempel tilgang til kontaktlisten. App Ops gir også en oversikt over når hver enkelt applikasjon sist utnyttet tilgangen til hvert av privilegiene.

Men nå er det slutt. I Android 4.4.2-oppdateringen, som ble gjort tilgjengelig for omtrent en uke siden, er App Ops angivelig helt borte. Dette har vekket en viss oppsikt.

Electronic Frontier Foundation (EFF), en frivillig organisasjon som kjemper menneskers digitale rettigheter, kom onsdag i forrige uke med en hyllest til App Ops.

Men dagen etter var EFF blitt gjort kjent med at App Ops ikke lenger er tilgjengelig.

Ikke ment for sluttbrukere
På spørsmål fra Google+-brukeren Danny Holyoake om hva som har skjedd, svarer Android-utvikleren Dianne Hackborn at App Ops ikke aldri var ment for sluttbrukere.

– Først og fremst er det til for plattformingeniører – et verktøy for å undersøke, debugge og teste tilstanden til den delen av systemet. Det var ikke ment å være tilgjengelig, skriver Hackborn.

Hun forklarer at grensesnittet er en del av arkitektur som brukes av stadig mer funksjonalitet, blant annet kontroll over varslene fra hver enkelt applikasjon. Men det var ikke ment å brukes til å tilby en rekke brytere som brukeren etter eget forgodtbefinnende kan stille inn.

Men i diskusjonstråden er det lite forståelse for Hackborns argumenter. Det vises blant annet til at iOS har tilsvarende funksjonalitet og at dette er noe som burde ha vært tilgjengelig i Android for lengst, i alle fall for avanserte brukere.

EFF skal ha blitt fortalt av Google at App Ops kan føre til at applikasjoner sluttet å fungere. For mindre erfarne brukere kan dette naturlig nok være et problem, dersom de ikke forstår sammenhengen mellom App Ops-innstillingene og applikasjonssvikten.

Dårlig forklaring?
EFF skriver i blogginnlegget at de ikke helt kjøper denne forklaringen. Organisasjonen mener at man i operativsystemet kan lede applikasjoner til tomme eller falske dataområder, i stedet for å blokkere dem helt. Da vil ikke applikasjonene nekte å fungere.

Google oppfordres til å gjeninnføre funksjonen, etter å ha forbedret den.

– For et øyeblikk siden så det ut til at Google brydde seg om dette massive personvernproblemet [applikasjoners unødvendige tillatelser, red. anm.]. Nå har vi våre tvil. Den eneste måten til å fordrive dem, er rett og slett at Google raskt gjenopprettet App Ops-grensesnittet, samt gjør noe finpussing og fullfører de fundamentale delene som mangler, skriver EFF.

Organisasjonen skriver videre at den likevel ikke uten videre kan fraråde brukerne å installere Android 4.4.2-oppdateringen, fordi den også inkluderer viktige sikkerhetsfikser, blant annet til et meldingsproblem som ble omtalt av digi.no for to uker siden.

Fra 1. januar innføres det elektroniske skattekortet, som det har vært snakket om og planlagt for i flere år. Det betyr at arbeidsgiver selv henter skattekortet ditt ut fra Skatteetatens databaser.

Når landets arbeidstakere i disse dager får tilsendt brev fra Skatteetaten, så inneholder dette kun informasjon om den nye ordningen samt hvordan ditt skattetrekk for 2014 er utregnet.

Alt går imidlertid ikke automatisk. Du må selv kontrollere at skattetrekket ditt er regnet ut korrekt. Stemmer det, behøver du ikke å foreta deg noe. Oppdager du feil, er det ditt ansvar å si ifra.

– Det er viktig at du sjekker at tallene vi har lagt til grunn for å beregne skattetrekket ditt, er riktige. Er tallene feil, risikerer du å bli trukket for mye eller for lite i skatt gjennom året, sier skattedirektør Hans Christian Holte.

Hvis du har hatt store endringer i inntekt, formue eller fradrag, bør du, på samme måte som tidligere, endre skattekortet ditt for å få et mest mulig korrekt skattetrekk.

Noen arbeidsgivere har testet ut ordningen i 2013, og tilbakemeldingene har vært såpass gode at Holte er trygg på at innføring av den permanente ordningen vil bli smertefri.