Kundedata lå åpent tilgjengelig i Rema 1000s Æ-app. – Jeg kunne lastet ned hele kundebasen

[LMH1]

Jeg fant ikke noen punkter som handler direkte om «reverse engineering, pentesting, roting i koden og den slags». Det nærmeste er kanskje: «Alle immaterielle rettigheter (inkludert, men ikke begrenset til opphavsrettigheter, varemerker og patenter) til Æ tilhører REMA 1000 i Norge AS eller REMA 1000 i Norge AS’ leverandører og samarbeidspartnere.»

 

REMA 1000 skriver videre: «Vi er ikke ansvarlig for direkte eller indirekte skade, uteblitt fortjeneste eller for annet tap som skyldes at informasjonen publisert i applikasjonen er feil, vises eller presenteres på feil måte eller helt uteblitt på grunn av feil fra oss eller andre forhold.»

 

IANAL, som det heter på engelsk, så kanskje er det overstående irrelevant for nærværende sak.

 

Så du mener hvis butikken\nettbutikken sier, vi har ingen ansvar for svindel\tap av reklamasjonsrett eller spioner ved bruk av denne appen så er butikken fri for rettsak hvis man følger seg lurt?

 

Egentlig mener jeg det burde være forbud mot å ta forbehold mot slike ting da det ikke hjelper en dritt hvis man går rettsak mot rema 1000 for krengelse av sitt personvern hvis man kan vise til at man kan finne informasjon om sin netthandel på forum eller andre steder men fremdeles i tvil om det er forumet eller rema 1000 i så fall man måtte ta saken mot. Men vi håper det ikke går så langt. Datatilsynet vil være første sted, eller domstol.

Men dog usikker i hvilken grad man ville fått igjen for en slik sak om rema 1000 kun får bøter. Men vi kunder får lite igjen kanskje 10% rabatt eller noe slikt.

 

For samme kan være tilfeller med brukernavn\passord at de blir lekket. Sammen med mye annet.

Da hadde nok både stedet der det blir lekket og rema 1000 vært ille ute.

Endret 2. februar 2017 av LMH1

[YUPDSBXI]

Det er nærmest trist å lese kommentarer fra @adeneo. At du, som selvutnevnt sikkerhetsekspert, omtaler saken slik du gjør, sjokkerer ikke meg. Det er jo ikke mange setninger bak du eksplisitt forteller hvor blåøyd du er.

 

All ære til Nygård.

[nomore]

 

Har ikke hele kortnummeret vært tilgjengelig? Det er 16 siffer i det som API'et leverte, og ett kortnummer er 16 siffer. I tillegg står det utløpsdato. Det eneste som da mangler er sikkerhetskoden.

 

Nei, flere av sifferene er byttet ut med X-er.

 

Hadde REMA levert fulle kortnummere hadde dette vært en betydelig større skandale, og hele greia hadde vært stengt ned for lengst.

 

Flott. Det var da i det minste positivt

[Trond Endrestøl]

 

Jeg fant ikke noen punkter som handler direkte om «reverse engineering, pentesting, roting i koden og den slags». Det nærmeste er kanskje: «Alle immaterielle rettigheter (inkludert, men ikke begrenset til opphavsrettigheter, varemerker og patenter) til Æ tilhører REMA 1000 i Norge AS eller REMA 1000 i Norge AS’ leverandører og samarbeidspartnere.»

 

REMA 1000 skriver videre: «Vi er ikke ansvarlig for direkte eller indirekte skade, uteblitt fortjeneste eller for annet tap som skyldes at informasjonen publisert i applikasjonen er feil, vises eller presenteres på feil måte eller helt uteblitt på grunn av feil fra oss eller andre forhold.»

 

IANAL, som det heter på engelsk, så kanskje er det overstående irrelevant for nærværende sak.

 

Så du mener hvis butikken\nettbutikken sier, vi har ingen ansvar for svindel\tap av reklamasjonsrett eller spioner ved bruk av denne appen så er butikken fri for rettsak hvis man følger seg lurt?

 

Egentlig mener jeg det burde være forbud mot å ta forbehold mot slike ting da det ikke hjelper en dritt hvis man går rettsak mot rema 1000 for krengelse av sitt personvern hvis man kan vise til at man kan finne informasjon om sin netthandel på forum eller andre steder men fremdeles i tvil om det er forumet eller rema 1000 i så fall man måtte ta saken mot. Men vi håper det ikke går så langt. Datatilsynet vil være første sted, eller domstol.

Men dog usikker i hvilken grad man ville fått igjen for en slik sak om rema 1000 kun får bøter. Men vi kunder får lite igjen kanskje 10% rabatt eller noe slikt.

 

For samme kan være tilfeller med brukernavn\passord at de blir lekket. Sammen med mye annet.

Da hadde nok både stedet der det blir lekket og rema 1000 vært ille ute.

Hva jeg selv mener, har jeg ikke uttalt meg om. Og, nei, jeg jobber ikke for REMA 1000. Jeg har bare gjengitt uttalelsene fra REMA 1000 og tydelig indikert at jeg ikke har juridisk embetseksamen. Jeg håper at du klarer å se forskjellene.

[tintin77]

Det enkle er ofte det beste: Æ gir faan!

[Paynster]

Er litt morsomt at Rema og utviklerne ikke ser forskjell på kryptert data og kryptert trafikk. Hadde de kryptert data, ville vedkommende "hacker" kun fått tilgang til sine egne opplysninger i ytterste tilfelle. Hadde de gjort det korrekt, ville ikke "hackeren" fått tilgang til egne data heller.

Men godt å vite at Shortcut lever opp til navnet

[Civilix]

Er litt morsomt at Rema og utviklerne ikke ser forskjell på kryptert data og kryptert trafikk. Hadde de kryptert data, ville vedkommende "hacker" kun fått tilgang til sine egne opplysninger i ytterste tilfelle. Hadde de gjort det korrekt, ville ikke "hackeren" fått tilgang til egne data heller.

Men godt å vite at Shortcut lever opp til navnet

 

Sjeldent/aldri krypteres hele databaser, ytelsestapet er for stort og det er også mange praktiske utfordringer. Man krypterer bare data som man må.

 

Eller så finner jeg det spennende at du foreslår at data skal krypteres så brukeren ikke selv kan lese sine data, kanskje tenke gjennom det forslaget en gang til

 

Eller så tilbake til saken synes jeg det er litt overaskende at så mange ser ut til å ville gjøre Nygård til en helt i dette.

Han hentet ut data for 3400 kunder, så mye data er ikke nødvendig for å lage "proof of concept". Skal ikke spekulere for mye om hvorfor han valgte å hente ut så mye data, men det er ingen god grunn til at han skulle gjøre det.

[Gjest Slettet+9817324]

Loven står uansett over avtalevilkår, så effekten av en slik ansvarsfraskrivelse er begrenset.

Richard Nixon : They are bigger crooks than me !

[0laf]

Det er nærmest trist å lese kommentarer fra @adeneo. At du, som selvutnevnt sikkerhetsekspert, omtaler saken slik du gjør, sjokkerer ikke meg. Det er jo ikke mange setninger bak du eksplisitt forteller hvor blåøyd du er.

 

All ære til Nygård.

 

For det første er jeg vel ikke selvutnevnt sikkerhetsekspert, det nærmeste jeg har skrevet er at jeg selv mener jeg har over gjennomsnittet kunnskap om informasjonssikkerhet.

 

For det andre, ser det ut til at enkelte ikke helt klarer å lese, så å si den aller første setningen jeg skrev i denne tråden var

 

Det riktige av REMA 1000 etter min mening, ville selvfølgelig være å takket Nygård for hjelpen, fikse problemet, å få saken ut av verden så raskt som mulig.

 

Det som ville være blåøyd, var jo å la mine egne synspunkter om hvordan REMA burde håndtert denne saken påvirke hvorvidt jeg mener Nygård bør få belønning eller straff.

 

I min verden kan det ikke være slik at folk roter rundt i datasystemer de har ikke noe med å rote rundt i, og så få belønning for det, uansett om sikkerheten er dårlig eller ikke.

 

Svært mange selskaper gir tillatelse til å teste deres systemer, andre ønsker ikke uvedkommende i sine systemer, og REMA er tydeligvis en av disse, og jeg har ingen problemer med å respektere det.

 

Jeg registrerer at de fleste mener det bør være fritt frem å hente ut data fra kilder man egentlig ikke skal ha tilgang til, og at selskapet til og med bør betale belønning til den som brøt seg inn i deres systemer.

 

I utgangspunktet er jo det å avlytte trafikken til appen, finne api-kallene, forsøke andre api-kall med diverse nye payloads, selve definisjonen av hacking, selv om det i dette tilfellet var relativt enkelt utført. At så mange mener det er greit å hacke REMA 1000 fordi de har dårlig sikkerhet, og at REMA 1000 skal betale for gleden, er helt hårreisende for meg.

 

For det tredje er det generelt retningslinjer om hvordan man skal teste og rapportere feil.

Google har for eksempel et veldig enkelt mantra : "When investigating a vulnerability, please, only ever target your own accounts. Never attempt to access anyone else's data and do not engage in any activity that would be disruptive or damaging to your fellow users", og vanlig kotyme er at man følger reglene om ansvarlig varsling, venteperioder osv.

 

Jeg registrerer at Nygård nå har lagt ut flere skjermbilder av dataene, denne gangen "med tillatelse", og jeg regner med den tillatelsen er fra REMA, som tross alt eier dataene, ikke fra brukeren det gjelder? 

Endret 2. februar 2017 av adeneo

[Gjest Slettet+9817324]

Det mest bekymringsverdige her er i mine øyne Remas tilbakemelding. Den er ikke tillitsvekkende.

 

AtW

KM Bondevik : I får rett og slett en depressiv reaksjon av Rema , i !

[Hardrocktarzan]

Så hvis noen har fått tak i 10 av 16 siffer i kortnummeret mitt i tillegg til utløpsinfo. Da har de snevret kortnummer mitt ned til 1 million kombinasjoner. I tilegg er det 1000 mulige ccv koder noe som gir en milliard kombinasjoner totalt. Er det noen datakyndige her som vet om dette er en nevneverdig risiko?

[PgUp]

Så hvis noen har fått tak i 10 av 16 siffer i kortnummeret mitt i tillegg til utløpsinfo. Da har de snevret kortnummer mitt ned til 1 million kombinasjoner. I tilegg er det 1000 mulige ccv koder noe som gir en milliard kombinasjoner totalt. Er det noen datakyndige her som vet om dette er en nevneverdig risiko?

Send meg ditt kortnummer og CCV så skal jeg skjekke hvor utsatt du er.

[endrebjo]

Så hvis noen har fått tak i 10 av 16 siffer i kortnummeret mitt i tillegg til utløpsinfo. Da har de snevret kortnummer mitt ned til 1 million kombinasjoner. I tilegg er det 1000 mulige ccv koder noe som gir en milliard kombinasjoner totalt. Er det noen datakyndige her som vet om dette er en nevneverdig risiko?

Enkelte store nettsider (husker ikke om det er Amazon, Ebay, eller noen andre) har i hvert fall tidligere brukt de fire siste sifrene i kortnummeret ditt som sikkerhetsspørsmål hvis du vil resette passordet ditt ("Glemt passord", etc.). Gjengivelsen min er ikke nøvendigvis 100% riktig, men faktum er i hvert fall at også _deler_ av kortnummeret ditt i noen tilfeller kan være nok til å få tilgang til andre tjenester.

 

Edit: Jeg fant i hvert fall ett eksempel på exploit med fire siste siffer: https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/all/

Endret 2. februar 2017 av endrebjo

[tommyb]

Tipper utviklerne hos Shortcut har hatt en hektisk uke og at noen har gått på en stygg karrieresmell. 

 

Navnet man velger på sin bedrift gjenspeiler hvem man ønsker å være og hva man ønsker å si til potensielle kunder. I navnet "Shortcut" leser jeg noe helt annet enn jeg ønsker i en potensiell partnerbedrift. Med mindre de selger frisørtimer, da.

 

 

Rema har jo foråvidt rett i at man trenger "spesifikk kunnskap" for å hente ut dataene. Det er ikke noe hvem som helst får til.

 

Jeg vil komme med en morsom motpåstand; at jeg tror alle google-kyndige personer er i stand til å lære seg dette på en kveld, dersom de

1) har fått tanken (som de kanskje får når de leser dette innlegget), og

2) har hørt at apper har trafikk til og fra internett (som de kanskje fikk med seg når de leste denne artikkelen).

 

Jeg tror at alle i denne tråden som klarer finne informasjon gjennom google, klarer finne nok informasjon til å klare å gjennomføre et kall til et API i løpet av en lang kveld. Nå er dette APIet sikret siden det ble oppdaget, men den "spesifikk kunnskap" man trenger her er å google, ikke forståelse av informasjonssikkerhet. Hvis noen fikk det for seg å teste noen andres app på samme måte, tror jeg rett og slett at de kommer å få det til. Så kunnskapsnivået man skal opp på for å snuble over snarveien tror jeg er ganske raskt forsert.

 

Håper ikke noen nå føler seg fristet til å teste, for de vil ikke kunne falle tilbake på samme begrunnelse som Nygård. Uansett bør apputviklere tenke litt lengre - et API er et grensesnitt, forvent at noen vil gå opp grensen!

 

 

 

 

"Med bot eller fengsel inntil 2 år straffes den som ved å bryte en beskyttelse eller ved annen uberettiget fremgangsmåte skaffer seg tilgang til datasystem eller del av det." Spørsmålet er altså om framgangsmåten - handlingen eller måten man har fått tilgang til datene - er uberettiget

 

Forarbeidene sier følgende om innholdet i begrepet i Ot.ptrp. 28 (2008-2009) på side 22:

Det er de nærmere omstendighetene som avgjør om handlingen er straffverdig og bør kriminaliseres, for eksempel av hvem og under hvilke forutsetninger handlingen er utført.

 

[...]

 

Er det å teste om et system man selv bruker har noen form for sikkerhetsmekanismer for å beskytte egne data, er det uberettiget?

 

Det er ihvertfall ikke mulig å svare et så klart ja på det som enkelte har gjort. Selv om det ikke lenger er noe krav til at man har brutt sikkerhetsmekanismer, er det naturlig nok en del av vurderingen. I kommentarene til bestemmelsen sies det også "Men selv om beskyttelsesinnbrudd ikke gjeninnføres som et nødvendig vilkår for straff, ønsker departementet likevel å fremheve at beskyttelsesbrudd vil være det mest praktiske, jf. lovforslaget § 204." Departementet sier da også i forarbeidene at elektornisk kartlegging neppe kan sies å være straffbart etter bestemmelsen.

(...)

Den gamle bestemmelsen krevde vel forresten at en sikkerhetssperre var brutt? Jf forarbeidene som sier at fortolkningen av "uberettiget" må ”ses i sammenheng med kravet om at gjerningsmannen må ha overskredet en eller annenform for beskyttelse eller hindring.

 

 

Ugh, sitatkaos. Beklager, som vanlig. Ser ut til at noen av sitatene lot seg rydde opp...

 

Jeg har lært at lovligheten av f.eks. portscanning, sniffing etc., er forskjellig fra land til land, og det er også forskjellig fra lovrevisjon til lovrevisjon. Intensjon kan også utgjøre en forskjell på lovlighet. Det jeg lærte på skolen er nok utdatert, men i disse sitatene er det endel technicalities (som dog neppe gjenspeiler intensjonen med loven) som jeg kan ha lyst til å peke ut.

 

Jeg kan ikke se at HN har brutt noen beskyttelse. Han har bedt et API om informasjon, men APIet er bygget for å gi denne informasjonen.

 

Den eneste gangen han skaffet seg tilgang til et datasystem eller en del av dette, var når han installerte Æ-appen. Tilgangen ble da delt ut, og han fikk rett til å kommunisere med APIet. Det er en mulighet for at han uberettiget har hentet ut data avhengig av hva lisensteksten spesifiserer, men jeg tviler på at lisensteksten gir noen konkret begrensning på direktekall til APIet.

 

Det eneste jeg vil kritisere ham på er at han hentet ut data om ukjente personer. Der burde han ha spurt en person om å få bruke kundeidentifikasjonen til denne i stedet. Etter mitt moralske kompass er det ikke koscher å hente ut fremmede folks data, selv om de er ubeskyttet.

 

 

 

Det som ville være blåøyd, var jo å la mine egne synspunkter om hvordan REMA burde håndtert denne saken påvirke hvorvidt jeg mener Nygård bør få belønning eller straff.

 

I min verden kan det ikke være slik at folk roter rundt i datasystemer de har ikke noe med å rote rundt i, og så få belønning for det, uansett om sikkerheten er dårlig eller ikke.

 

Svært mange selskaper gir tillatelse til å teste deres systemer, andre ønsker ikke uvedkommende i sine systemer, og REMA er tydeligvis en av disse, og jeg har ingen problemer med å respektere det.

 

Jeg registrerer at de fleste mener det bør være fritt frem å hente ut data fra kilder man egentlig ikke skal ha tilgang til, og at selskapet til og med bør betale belønning til den som brøt seg inn i deres systemer.

 

I utgangspunktet er jo det å avlytte trafikken til appen, finne api-kallene, forsøke andre api-kall med diverse nye payloads, selve definisjonen av hacking, selv om det i dette tilfellet var relativt enkelt utført. At så mange mener det er greit å hacke REMA 1000 fordi de har dårlig sikkerhet, og at REMA 1000 skal betale for gleden, er helt hårreisende for meg.

 

For det tredje er det generelt retningslinjer om hvordan man skal teste og rapportere feil.

Google har for eksempel et veldig enkelt mantra : "When investigating a vulnerability, please, only ever target your own accounts. Never attempt to access anyone else's data and do not engage in any activity that would be disruptive or damaging to your fellow users", og vanlig kotyme er at man følger reglene om ansvarlig varsling, venteperioder osv.

 

 

- Belønning for å avdekke sikkerhetshull bør ikke anses som noe annet enn en ren anerkjennelse på lik linje med "takk for at du sa i fra". Det bør aldri bli en forventning om at man skal ha betalt for å si i fra, det ville vært en svært negativ utvikling. Da er man på ei glatt plate der man balanserer mellom å kreve respekt og litt utydelig utpressing.

 

- Et API er et grensesnitt mot det ukjente, usikkerhet er implisitt. Og HN hadde eksplisitt tillatelse til å kommunisere med APIet, gjennom appen. Tilgangen er gitt fra Rema (via Shortcut) til HN, og HN testet tilgangen. Jeg sliter med å akseptere at dette er å rote rundt i et datasystem, og våre egne kunder kunne ha gitt slike tilbakemeldinger uten at jeg hadde blitt sur på andre enn utviklerne. Jeg sier ikke at det er okay å kikke på andres data, men jeg sier det er okay å sjekke at egne data ikke ligger åpent på nett. Det ser ut til at Shortcut la våre data åpent på nett, det er verre enn at HN oppdaget dette og så varslet fra om det.

 

- Nei, en forventing til at dette skal føre til utbetalinger liker jeg ikke. Og jeg tror ofte slike utbetalinger er for å feie under teppet. I tilfelle Google og rewards er rekkefølgen vesentlig annerledes, og de har et større mål der enn bare å lukke egne feil. Det betyr ikke at Googles retningslinjer kan overføres til andre, de kan dog være en rettesnor.

 

- Min "selve definisjonen" slår inn et hakk etter å lese egen trafikk og bytte en ID. Det ser jeg på som en visuell inspeksjon utført av kunden for å sjekke Remas tjenesteleveranse. Nå tar ikke jeg denne vurderinga for Rema (eller min egen bedrift for den saks skyld) men jeg synes Rema og næringslivet generelt gjør seg selv en bjørnetjeneste om de ikke aksepterer at APIer kommer til å bli utforsket, og da bør andelen av whitehats helst være større enn blackhats.

Endret 2. februar 2017 av tommyb

[0laf]

Jeg vil komme med en morsom motpåstand; at jeg tror alle google-kyndige personer er i stand til å lære seg dette på en kveld

 

At man lærer seg dette på en kveld, tror jeg ikke noe særlig på.

 

Nå har ikke jeg sett på denne appen, men dersom man tar utgangspunkt i at den er installert på en iOS eller Android telefon, så skal man jo først sette opp noe for å overvåke trafikken og dekryptere TLS og den slags.

Nå er vel også denne handleappen tilgjengelig direkte på REMA sine nettsider, noe som gjør det lettere, men likevel.

 

Man skal altså først forstå hvordan det settes opp et lokalt nettverk som proxy for telefonen, hvordan programmer som Fiddler fungerer for å se dataene som sendes over nettverket, hvordan TLS fungerer, og hvordan man setter Android og Fiddler til å dekryptere slik at man kan se dataene som sendes.

 

Deretter skal man ha en grunnleggende forståelse for HTTP for å vite hvordan man endrer forespørslene og sender andre data til serveren, deretter skal man i det minste ha en grunnleggende forståelse for JavaScript for å lese JSON å forstå sammensetningen av dataene.

 

Når noen først har oppdaget feilen og dokumentert hvordan lenkene er bygget opp, så kan man nok sikkert lære seg på en kveld hvordan man gjør enkle forespørsler med wget, cURL, powershell eller lignende til api dot rema dot no.

 

Du er dog særs intelligent dersom du kan starte fra scratch, finne adressen til den api'en ved å overvåke nettverkstrafikken, finne ut hvordan forespørslene gjøres osv. og lære alt dette på en kveld, de fleste bruker betydelig lengre tid på å tilegne seg den kunnskapen.

[bmork]

 

Jeg vil komme med en morsom motpåstand; at jeg tror alle google-kyndige personer er i stand til å lære seg dette på en kveld

 

At man lærer seg dette på en kveld, tror jeg ikke noe særlig på.

 

Nå har ikke jeg sett på denne appen, men dersom man tar utgangspunkt i at den er installert på en iOS eller Android telefon, så skal man jo først sette opp noe for å overvåke trafikken og dekryptere TLS og den slags.

Et enkelt søk etter "listening on app api communication over https" ga denne som treff nr 3:

https://www.toptal.com/back-end/reverse-engineering-the-private-api-hacking-your-couch

 

Den inneholder all informasjonen du trenger for jobben, og burde kunne leses på en halvtime.  Du har resten av kvelden tilå teste det ut.  Evt finnes det sikkert enda bedre manualer om du bruker mer enn 10 sekunder på google-søket.

 

Nå ble det vel strengt tatt bare sagt at man kan lære seg dette på en kveld.  Du må nok regne med å bruke et par-tre kvelder på å sette det ut i praksis for første gang.  Men at det er overkommelig for alle med litt basiskunnskaper er hevet over enhver tvil.

 

Og proffe utviklere burde kjenne til at veldig mange, både av de snille og de andre, gjør denne typen analyser.  Hvis appen din er populær nok, så må den tåle såpass grundige øyne.  Det er ekstremt usannsynlig at Nygård er den eneste som har gått løs på Æ, og han var nok neppe den første heller.  Man han var altså den første som var Ærlig nok til å si fra, og det står det stor respekt av.

[0laf]

 

Den inneholder all informasjonen du trenger for jobben, og burde kunne leses på en halvtime.  Du har resten av kvelden tilå teste det ut.  Evt finnes det sikkert enda bedre manualer om du bruker mer enn 10 sekunder på google-søket.

 

Nå ble det vel strengt tatt bare sagt at man kan lære seg dette på en kveld.  Du må nok regne med å bruke et par-tre kvelder på å sette det ut i praksis for første gang.  Men at det er overkommelig for alle med litt basiskunnskaper er hevet over enhver tvil.

 

 

Nå har man vel strengt tatt ikke lært seg det før man klarer å sette opp en proxy, dekryptere TLS, avlytte trafikken, forstå dataene og hvordan de sendes osv.

Det er da ikke så lett å gjøre dette som enkelte ser ut til å tro, eller?

 

Nå vet ikke jeg hva du mener med "basiskunnskaper", men jeg kan ikke helt se for meg at noen med null kunnskap om utvikling og nettverkstrafikk klarer å få til dette på en kveld etter å ha lest den artikkelen.

Det er dog mulig jeg tar feil, og at det er enklere enn det ser ut, og for ordens skyld, jeg vet hvordan man gjør dette, men jeg lærte det ikke på en kveld.

[quantum]

 

 

Det ser ut til at enkelte tror man automatisk har lov til å hente alt man finner på nett, kun fordi dataene ikke er beskyttet særlig godt, noe som ikke er tilfelle.

 

 

 

Det ser også nærmest ut til at enkelte tror det motsatte er tilfelle. 

 

Vi kan ikke ha det slik at en må anta ethvert tilgjengelig api inneholder informasjon man ikke skal ha tilgang til. Da vil på en måte verden stoppe opp. Lovteksten er, som vi har sett, temmelig tåkete og rettspraksis tynn. Men det vil være rimelig å anta, eller ihvertfall håpe, en domstol vil ta ibruk en viss realitetsorientering av denne typen...

[quantum]

 

Så du mener hvis butikken\nettbutikken sier, vi har ingen ansvar for svindel\tap av reklamasjonsrett eller spioner ved bruk av denne appen så er butikken fri for rettsak hvis man følger seg lurt?

 

 

 

Tror nok de forbeholdene Rema tar er knytta til f.eks. logoer, tekster, varemerker osv. som presenteres i appen og eventuelle ulemper som måtte følge av at appen presenterer feil priser, rabatter osv., de er nok ikke så kørka at de prøver å ta forbehold i tilfelle de skulle bryte norsk lov, f.eks. vedrøerende sensitive personopplysninger.

[quantum]

 

Eller så tilbake til saken synes jeg det er litt overaskende at så mange ser ut til å ville gjøre Nygård til en helt i dette.

Han hentet ut data for 3400 kunder, så mye data er ikke nødvendig for å lage "proof of concept". Skal ikke spekulere for mye om hvorfor han valgte å hente ut så mye data, men det er ingen god grunn til at han skulle gjøre det.

 

 

 

Snedig å bare spekulere akkurat tilstrekkelig til å mistenkeliggjøre Nygård. Jeg føler meg litt sprø og går lenger; Kanskje det var for å verifisere at omfanget var stort? Noe Rema selvfølgelig ellers ville kunne benektet.