Användare uppdaterar inte sina system

Andra dåliga vanor hos användare inkluderar att inte uppdatera mjukvarorna de använ- der. WannaCry är nog det bästa exemplet på detta på senaste tid, där hackare utnyttjade ett säkerhetshål i Server Message Block (SMB) protokollet i Windows som redan hade fixats av Microsoft, men som användare inte hade installerat på sina system [57]. WannaCry hade även påverkat hårdvara hos företag, vilket kan antas inkludera företag som tillhandahåller tjäns- ter på Internet. Problemet blir vid detta skede mycket allvarligare, eftersom att farlig kod nu kan spridas till miljontals användare via Internet. Därför är det extra viktigt för företag att de uppdaterar sin mjukvara, för deras egna och deras användares skull. I detta fall innebär det att ha en server som är kompatibel med TLS 1.3. Användare kan istället använda sig av webbläsare som är kompatibel med TLS 1.3, vilket alla moderna webbläsare som är uppda- terade borde stödja. För det extra steget säkerhet kan webbläsaren konfigureras till att endast använda TLS 1.3 och aldrig nedgradera.

C.7

Slutsats

Vi har lärt oss vad MITM är och hur vi drabbas av det. Vi har också lärt oss olika tillväga- gångssätt för att skydda sig mot MITM, både på serversidan och klientsidan, men att det största skyddet mot MITM och andra typer av attacker är ibland användaren själv. I detta fall ska användaren vara noga med att acceptera certifikat och läsa igenom samt fastställa att ett certifikat är giltigt. Vi har också lärt oss att det är av värde att uppdatera den mjukva- ra som används som ett ytterligare skydd mot MITM, eftersom att uppdateringar innehåller ofta säkerhetsuppdateringar.

Det som rekommenderas för kunden – och därmed detta projekt – är att strikt använda sig av TLS 1.3, samt att implementera två-vägs autentisering. Eftersom att säkerhet är av yttersta vikt för kunden blir två-vägs autentisering en stor fördel, trots mer overhead i implemen- teringen. Anledningen till detta är för att utöver servern måste klienten också ha ett giltigt

C.7. Slutsats

certifikat, vilket fungerar som en typ av autentisering och skyddar webbapplikationen mot obehörig åtkomst. Kunden kan i detta fall ha flera lager av autentisering, där giltigt certifikat samt inloggning ingår.

D

Jämförelser av Google Maps API

med andra API av Joakim Tao

D.1

Inledning

Idag är kartläggning ett av de vanligaste verktygen på internet. Kartläggning används i dags- läget för att hitta till olika platser, för vägbeskrivning och mycket annat. På internet an- vänds webbaserade kartläggningsverktyg till allt från simpla hemsidor som visar informa- tion på kartan till komplicerade hemsidor som visar många funktionaliteter som vägbeskriv- ning [58]. Enligt Hu och Dai har användningen av webbaserade kartläggningsverktyg ökat på senaste tiden, dessa verktyg brukar benämnas Map API. De mest kända Map API:na är Goog- le Maps API som projektet använder, Microsoft Bing Maps API och Yahoo! Maps API [58]. API står för application programming interface vilket är som en specifikation för hur kommu- nikationen mellan applikationen och programvaran sker. Användningen av olika Map API påverkar utvecklingen av produkten och i denna text undersöks detta.

D.1.1

Syfte

Denna litteraturstudie har som syfte att jämföra Google Maps API med andra API:n, genom att jämföra kostnadsfri användingsmängd, kostnaden efter gratisanvänding samt fördelar och nackdelar med olika API:ers funktionalitet. Denna jämförelse kommer göras med kunden och framtida projekt i åtanke för att visa vilket Map API som skulle passa bäst i vilken typ av projekt.

D.1.2

Frågeställning

1. Vad finns det för för- och nackdelar med att använda Google Maps API samt vad är kostnaden jämfört med ?

a) Mapquest API

b) Microsoft Bing Maps API c) Mapbox API

D.2. Bakgrund

D.1.3

Avgränsningar

Denna studie kommer endast vara en litteraturstudie, där källor hämtas från publicerade artiklar och eventuellt icke-publicerade artiklar ifall en brist på informationsrika publicerade artiklar finns. Studien kommer därför endast ta hänsyn till det som står skrivet i artiklarna, och ej ta hänsyn till egna erfarenheter.

D.2

Bakgrund

Denna litteraturstudie som jämför olika Map API görs i samband med kandidatkursen TDDD96 som läses vid Linköpings universitet. Projektet använder sig av Google Maps API vilket gör jämförelsen relevant. Vid bestämmelsen av Map API spenderades nästan ingen tid på att kolla upp vilket Map API som skulle användas utan Google Maps API valdes enbart på grund av popularitet. Om Google Maps API visade sig vara icke användarvänligt och ha nackdelar kring vad projektgruppen försöker utveckla hade detta kunnat leda till svårighe- ter. Det är därför viktigt och göra jämförelse av olika Map API:n innan ett beslut tas för att se vilket API som är mest fördelaktigt för projektet.

D.3

Teori

Detta avsnitt kommer att beskriva teori kring de olika Map API:na samt lite teori kring hur kartläggning fungerar. Avsnittet kommer även introducera kostnader samt för- och nackdelar med de olika Map API:n.

D.3.1

Geocoding

Enligt Dramowicz finns det tre standardmetoder som används för att Geokoda data [59]. Des- sa tre metoder bygger på vilken typ av information som associeras med platsen [59]. De tre vanligaste informations typer är gatuadresser, postnummer och regioner, men även områden och landet kan användas för som informationstyp. Geocoding handlar om att omvandla be- skrivning av en plats, med hjälp av gatuadress, postnummer eller annat, till en faktisk plats eller rättare sagt ett koordinatpar (lat,long) [60]. Det finns även en metod som kallas reverse geocoding som gör motsatsen till vad en geocoding gör, det vill säga från ett koordinatpar hittar en fysisk adress.

D.3.2

Geocoding process

En geokodningsprocess börjar med en inmatning av en adress. Adressen analyseras och delas upp i olika adresselement som adressnummer, gata, stad m.fl. Sedan skapas variabler för var- dera element. Efter listan med alla adresselement skapats genereras en lista med matchande potentiella platser som ges en poäng på 0-100. Poängen är beroende på antalet matchan- de adresselement men även stavningen i adressen poängteras. Efter detta filtreras platserna med minst poäng bort och den plats med mest poäng blir vald som den korrekta platsen och koordinater för platsen finnes. En reverse geocoding skulle fungera på samma sätt bara att koordinater få som indata och adressen fås som utdata [61], se Figur D.1.

D.3. Teori

Figur D.1: Geocoding process

Denna process brukar även kallas en Geocoding API request [5]. Det är i denna process de olika Map API:na skiljer sig, från hur snabb processen är, vilken typ av geocoding som görs till hur bra adressen analyseras men även hur API:n poängsätter de potentiella platserna.

D.3.3

Gorilla Index

Gorilla Index kommer från det amerikanska uttrycket 800-pound gorilla, det är ett uttryck för en person eller organisation som är så kraftfull att den kan agera hur den vill [62]. I denna litteraturstudie representerar det hur stort inflytande det företaget har [63]. DuVander säger även att Gorilla Index är ett betyg mellan ett och tio för hur stor marknadsandelen är för ett företag [63]. En hög siffra innebär att företaget är The 800-pound gorilla för sin marknad eller med andra ord att företaget är ledande inom sin marknad [63].

D.3.4

DX index

DX index står för Developer Experience index som är ett betyg mellan 1-10 beroende på utveck- larens upplevelse av produkten [64]. Ett högt DX index hjälper utvecklaren förstå vad som är

D.4. Metod

möjligt att göra men även hur det skulle kunna göras [64]. DuVander säger även att problem som programmerare sitter med i flera timmar ofta kan lösas med en bra dokumentation, med andra ord resulterar en bra dokumentation i en bra Developer experience [64]. Indexet ser efter 13 olika kriterier och varje kriterium är viktade beroende på sin betydelse. Av de 13 kriterier- na är de viktigaste elementen [64]:

1. Bibliotek tillgängliga i de populära språken. 2. Välgjorda, fördjupade startguider.

3. En öppen lösning (som inte är demo eller dylikt). 4. Tydliga priser för utvecklaren.

D.3.5

Statiska kartor

En statisk map är bara en bild och är därför inte interaktiv, vilket betyder att det inte går att zooma, panorera eller liknande [65].

D.3.6

Dynamiska kartor

En dynamisk karta är ett interaktivt objekt där användaren kan zooma in och detta görs exempelvis genom att visa ett kartbojekt i Javascript på en hemsida [65].

D.4

Metod

Information och kunskap som krävs för att svara på frågeställningarna kommer erhållas ge- nom att främst använda Google Scholar för att hitta publicerade artiklar och kvalificerad käl- lor. För att hitta relevant information gjordes sökningarna med textsträngar som Google Maps API, Map API comparison o.s.v . Men utöver dessa källor kommer andra publicerade artiklar användas som stödjer de primära källorna. Dessa källor har hittats med hjälp av Google som sökmotor med samma textsträngar som i Google Scholar. Källorna kan vara skrivna i digitala tidningar eller publicerade på någon form av blogg. Dessa källor kan räknas som trovärdiga om artiklarna är skrivna av utvecklare som har goda erfarenheter inom området. Söksträngar som användes var de Informationen och kunskapen som har hittats kommer sammanfattas för att ge läsaren grundläggande kunskaper inom Map API. Kunskapen kommer sedan an- vändas i diskussionen för att dra slutsatser.

En strikt litteraturstudie gjordes då ingen hade erfarenheter av Bing Maps API, Mapbox API eller Mapquest. För att hålla resultatet opartiskt uteslöts all egen erfarenhet med att an- vända Google Maps API.

D.5

Resultat

I detta avsnitt presenterars resultaten av litteraturstudien som jämför de olika API:na.