Digitalisaatio - hyvät ja huonot puolet

  • Keskustelun aloittaja Keskustelun aloittaja Sompi
  • Aloitettu Aloitettu
En ihan ymmärrä että mitä tällä ajetaan takaa, mutta jokainen tavallaan.
Epäilyttävien ohjelmien fyysinen sandboksaus ehkäpä? Moni ei tule ajatelleeksi, mutta on noissa ohjelmissa erinäistä seurantaa ja aina pyritään kiertämään puhelimen kulloinkin state of the artia edustavat blokkaukset. Esim. puhelin voi avata käyttäjää seuraavalla appsilla tietynlaiset osoitteet ja appsi voi kertoa käyttäjän identiteetistä, mitä sitten voi seurata vaikka netistä käsin ja yhdistää muuhun nettipresenssiin esim. erilaisten sormenjälkien avulla. Pelkkä oikeuksien estäminen uusissa Androideissa ei blokkaa kaikkea.

Osa appsien pakotuksesta on suorastaan ärsyttävän turhaa. Esimerkiksi jokin Aliexpress tai Zooplus voi tarjota alennuskupongin pelkästään appsin kautta käytettynä. No, vertailet ja kasaat ensin ostoskoria isonäyttöisellä ja ergonomisella tietokoneella ja kun saat viimein työn valmiiksi, jäljennät samat ostokset appsiin ja tilaat sieltä. Saat yhden euron tai prosentin edun. Näin kärjistäen. Etukäteen et voi tietää tietenkään, paljonko se etu tulisi olemaan. Onneksi joissain ohjelmissa ostoskori sentään siirtyy web-kälistä appsiin. Kaikissa ei. Esim. Zooplussassa oli itsellä jotain lagia ja ostoskori synkkautui vasta kun oli jo ehtinyt kerätä puolet ostoksista uudelleen koriin.

Tässä on huomattavan helppo syyttää loppukäyttäjää siitä, että on typerä kalevi/ykä, joka tekee "väärin" asiat vuonna 2023. Kun kaikkihan on mobile first ja vain idiootit käyttävät PC:tä (tai Macia) johonkin shoppailuun. Se pitäisi jo tajuta web-sivujen designista, kun verkkosivu on optimoitu kännykän aspect ratiolle ja PC:llä kaikki yli 800 pikselin menevä leveys näytöllä piirtyy vain tyhjänä tilana sivun ympärillä, mikä näyttää kohtalaisen hassulta 4k- tai 5k-näytöllä.
 
En ihan ymmärrä että mitä tällä ajetaan takaa, mutta jokainen tavallaan.
Niin kuin jo sanottiin, niin en luota siihen ettei monet ohjelmat tee arveluttuvia tekoja, yksityisyys siis syynä. Tässä toisessa puhelimessa ei ole niin paljon tietoa minusta, joten ajan softaa siinä, mihin en luota niin paljon, mutta josta voi olla jotain hyötyä minulle.
 
Eli korjataan jo ennestään toimivaa järjestelmää turhaan vaihtamalla uuteen.

Tulee mieleen tapaus omasta asuintalosta; Taloyhtiön hallituksen jäsen esittää että taloyhtiön ilmoitustaulut ja varausjärjestelmät muutetaan sähköisiksi ilmoitustauluiksi.
Minkä ongelman tämä digisiirtymä korjaa, sitä ei kukaan tiedä. Nähtävästi olemme kaikki eläneet valheessa viimeiset vuosikymmenet, ja kuvitelleet että tulostimen, paperin ja kynän pyhä kolminaisuus toimivat ilman suurempia toimintahäiriöitä saatika huoltokustannuksia verrattuna sähköisiin LCD-monitoreihin ja kosketusnäyttöihin.
 
Tulee mieleen tapaus omasta asuintalosta; Taloyhtiön hallituksen jäsen esittää että taloyhtiön ilmoitustaulut ja varausjärjestelmät muutetaan sähköisiksi ilmoitustauluiksi.
Minkä ongelman tämä digisiirtymä korjaa, sitä ei kukaan tiedä. Nähtävästi olemme kaikki eläneet valheessa viimeiset vuosikymmenet, ja kuvitelleet että tulostimen, paperin ja kynän pyhä kolminaisuus toimivat ilman suurempia toimintahäiriöitä saatika huoltokustannuksia verrattuna sähköisiin LCD-monitoreihin ja kosketusnäyttöihin.
Ideanahan tuo on loistava, mutta ainakin ne nykyiset toteutukset mihin itse olen törmännyt ovat aika kamalia ja tosiaan vaativat ylläpitoa ja ulkopuolisia (mobiili)yhteyksiä sekä sähköä eli lisää kustannuksia taloyhtiölle. Nuohan yleensä pohjautuvat johonkin ulkopuoliseen pilvipalveluun joka kuitenkin päätetään muutaman vuoden päästä lopettaa ja sitten meneekin koko systeemi uusiksi kun rauta on jotain custom-viritelmää jne. Ja tosiaan nuohan eivät yleensä ole akkuvarmennettuja joten sähkökatkon aikana ei paljon huoltoyhtiön tietoja ilmoitustaululta katsota että saisi tiedon sinne huollolle siitä sähkökatkosta.

Yleensäkin taloyhtiön viestinnässä olisi paljon muitakin juttuja mitkä kannattaisi ensin pistää kuntoon, vaikkapa joku taloyhtiön nettiportaali tai postituslista joka ajaisi asian paremmin kuin joku digi-infotaulu. Kynä ja paperi kuitenkin ainakin vielä toistaiseksi ovat paljon halvempia ja toimivampia ratkaisuita.
 
  • Tykkää
Reactions: hmb
Tulee mieleen tapaus omasta asuintalosta; Taloyhtiön hallituksen jäsen esittää että taloyhtiön ilmoitustaulut ja varausjärjestelmät muutetaan sähköisiksi ilmoitustauluiksi.
Minkä ongelman tämä digisiirtymä korjaa, sitä ei kukaan tiedä. Nähtävästi olemme kaikki eläneet valheessa viimeiset vuosikymmenet, ja kuvitelleet että tulostimen, paperin ja kynän pyhä kolminaisuus toimivat ilman suurempia toimintahäiriöitä saatika huoltokustannuksia verrattuna sähköisiin LCD-monitoreihin ja kosketusnäyttöihin.
Kuluttajariitalautakunnan mukaan esim. näyttöjen käypä käyttöikä on 4 vuotta, joten siitä voi laskea konservatiivisesti kustannuksia, jos jossain aulassa on pääte. Sitten vielä huomioitavaksi sähkölasku (gigantin kWh-lukemat lienevät keskimääräisellä olohuonekäytöllä eikä 24/7-kohteissa) ja ilkivalta jne. Esimerkiksi helmikuussa 2017 yhdessä yliopistossakin lukittuun rakennukseen tuli muistaakseni paperiton maahanmuuttaja paskomaan pesäpallomailan kanssa kosketusnäytöllisen käytäväpäätteen. Kaikkea voi sattua.
 
Yleensäkin taloyhtiön viestinnässä olisi paljon muitakin juttuja mitkä kannattaisi ensin pistää kuntoon, vaikkapa joku taloyhtiön nettiportaali tai postituslista joka ajaisi asian paremmin kuin joku digi-infotaulu. Kynä ja paperi kuitenkin ainakin vielä toistaiseksi ovat paljon halvempia ja toimivampia ratkaisuita.
Taloyhtiöissä on vielä se, että asukkaiden intressi on säästää omaa rahaa ja jollain todennäköisyydellä isossa osaa rakennuksia asuu itse hallituslainen, joka voi painaa infolaput ilmoitustaululle aina kun käy ulkona eli todennäköisesti useammin kuin kerran päivässä. Isot päätökset infotaan myös viikkoja etukäteen, joten mitään tiukan reaaliaikaista live-lähetystä ei tarvita.
 
Kuluttajariitalautakunnan mukaan esim. näyttöjen käypä käyttöikä on 4 vuotta, joten siitä voi laskea konservatiivisesti kustannuksia, jos jossain aulassa on pääte. Sitten vielä huomioitavaksi sähkölasku (gigantin kWh-lukemat lienevät keskimääräisellä olohuonekäytöllä eikä 24/7-kohteissa) ja ilkivalta jne. Esimerkiksi helmikuussa 2017 yhdessä yliopistossakin lukittuun rakennukseen tuli muistaakseni paperiton maahanmuuttaja paskomaan pesäpallomailan kanssa kosketusnäytöllisen käytäväpäätteen. Kaikkea voi sattua.
Ei tuollaisiin tarkoituksiin tietenkään mitään perinteistä tv-paneelia kannata asentaa, vaan pikemminkin jokin sähköisistä kirjanlukijoista tuttu staattinen paneeli.

Jos taas on tarkoitus välittää talon asukkaille vaihtuvia mainoksia ja infoviestejä mahdollisimman selkeästi ja näyttävästi, niin sitten sitten siinä pitää olla joku perinteisempi näyttö. Ei noista isoja kustannuksia tule, mutta se on sitten arvioitava aina tapauskohtaisesti, että onko moinen tarpeen. Ei voi kuitenkaan sanoa, etteikö tuollainen olisi jossakin tapauksessa perusteltua. Minäkin tiedän pari kerrostaloa, joissa on tuollainen infonäyttö, mutta asukaslistoja siinä ei kuitenkaan ole, vaan nimenomaan muuta asukasviestintää.
 
Miksei sitä asukasviestintää voi lähettää suoraan asukkaan puhelimeen jonkun näytön sijaan?

Ei ole tullut mieleenkään että joku taloyhtiön ilmoitustaulu pitäisi sähköistää digikiimassa. Tuntuu erittäin turhalta ajatukselta.
 
Taloyhtiöissä on vielä se, että asukkaiden intressi on säästää omaa rahaa ja jollain todennäköisyydellä isossa osaa rakennuksia asuu itse hallituslainen, joka voi painaa infolaput ilmoitustaululle aina kun käy ulkona eli todennäköisesti useammin kuin kerran päivässä. Isot päätökset infotaan myös viikkoja etukäteen, joten mitään tiukan reaaliaikaista live-lähetystä ei tarvita.
Juu, meilläkin asuu vissiin kaikki hallituksen jäsenet samassa taloyhtiössä ja he kyllä jakelevat rappujen ilmoitustauluille laput ja joskus jotkut tiedotteet jopa jokaiseen postiluukkuun. Samoin huoltoyhtiö kuitenkin käy useamman kerran viikossa paikalla ja jakaa omat lappusensa ilmoitustauluille. Tuollaisessa digitaulussa pitäisi sitten antaa erilaisille tahoille käyttöoikeuksia lisäillä ilmoituksia sinne ja sitten kun henkilöt vaihtuvat niin pitäisi jonkun vielä poistellakin niitä käyttöoikeuksia. Ja mitenkäs asukkaat sinne omia ilmoituksiaan laittavat? Post-it -lapulla näytön kulmaan?

Ei tuollaisiin tarkoituksiin tietenkään mitään perinteistä tv-paneelia kannata asentaa, vaan pikemminkin jokin sähköisistä kirjanlukijoista tuttu staattinen paneeli.

Jos taas on tarkoitus välittää talon asukkaille vaihtuvia mainoksia ja infoviestejä mahdollisimman selkeästi ja näyttävästi, niin sitten sitten siinä pitää olla joku perinteisempi näyttö. Ei noista isoja kustannuksia tule, mutta se on sitten arvioitava aina tapauskohtaisesti, että onko moinen tarpeen. Ei voi kuitenkaan sanoa, etteikö tuollainen olisi jossakin tapauksessa perusteltua. Minäkin tiedän pari kerrostaloa, joissa on tuollainen infonäyttö, mutta asukaslistoja siinä ei kuitenkaan ole, vaan nimenomaan muuta asukasviestintää.
Yleensähän noissa on joku ihan infonäytöksi tarkoitettu kosketusnäyttöpaneeli joka tietty syö sähköä jonkun verran. Joku e-ink -näyttö tietty olisi fiksumpi, saisi sähkönkulutusta aika reippaasti vähemmäksi. Muutamassa valmiissa rappuun tarkoitetussa info/varausnäytössä on ainakin ollut samassa lootassa näyttö, pieni pc ja joku gsm-modeemi tiedonsiirtoa varten ja pc:ssä on ainakin parissa laitteessa pyörinyt joku wanha versio Androidista.

Aika harva asia tulee mieleen joka toimisi tuollaisella digihärvelillä paremmin kuin perinteisellä paperi-ilmoitustaululla jos kyseessä on ihan tavallinen asuintalo. Noissa digitauluissa kun eri asiat yleensä pyörivät ruutu kerrallaan eli ohi kulkiessa ei välttämättä huomaa jos on tullut joku uusi tiedote kun taas itse ainakin vanhanaikaiselta ilmoitustaululta huomaan ohi kävellessä jos siihen on ilmaantunut joku uusi lappu.
 
Miksei sitä asukasviestintää voi lähettää suoraan asukkaan puhelimeen jonkun näytön sijaan?
Koska saavutettavuus. Ei voi lähteä siitä olettamuksesta, että kaikilla änkyröillä olisi puhelin tai edes sähköpostiosoite, jolla vastaanottaa ne viestit.

Ei ole tullut mieleenkään että joku taloyhtiön ilmoitustaulu pitäisi sähköistää digikiimassa. Tuntuu erittäin turhalta ajatukselta.
Digikiima? Onko tämä joku asioiden nykyaikaistamisen vastustajien termi, jolla yritetään vähätellä digitaalisten palveluiden hyötyjä?

Joo, se ilmoitustaulu ei varmaan yksittäisen talon tapauksessa ole erityisen olennaista, mutta jos sitä hallitsee joku huoltoyhtiön sihteerikkö tms ja samat ilmoitukset pitää toimittaa 20 taloyhtiöön, niin se voikin olla ihan järkevää. Ei kannata ajatella kaikkea pelkästään sen oman kuplan kannalta, kun käyttötapauksia on niin erilaisia.

Kosketusnäyttöversioita ei ole vielä tullut vastaan.
 
Digikiima? Onko tämä joku asioiden nykyaikaistamisen vastustajien termi, jolla yritetään vähätellä digitaalisten palveluiden hyötyjä?
Ihan vaan oma heitto. Pidän digitalisaatiota yleisesti hyvänä asiana, enkä lähtökohtaisesti vastusta uudistamista, mutta tuo ylläoleva esimerkki vaan kuulostaa omaan korvaan turhalta uudistamiselta. Siinä korjataan ongelmaa jota ei ole olemassa.
 
Siinä korjataan ongelmaa jota ei ole olemassa.
Voisiko kuitenkin olla niin, että et vain tiedä ongelmasta, jota sillä voidaan korjata tai nykyaikaistaa? Kuten sanoin, ei se kaikissa yksittäisissä taloissa varmaankaan anna mitään lisäarvoa, mutta jossakin toisaalla tilanne ja tarve voi olla jotain muuta.
 
Voisiko kuitenkin olla niin, että et vain tiedä ongelmasta, jota sillä voidaan korjata tai nykyaikaistaa? Kuten sanoin, ei se kaikissa yksittäisissä taloissa varmaankaan anna mitään lisäarvoa, mutta jossakin toisaalla tilanne ja tarve voi olla jotain muuta.
Missään yksittäisissä taloyhtiöissä tuskin on mitään järkeä tuollaisia digi-ilmoitustauluja/varausnäyttöjä asennella mutta ehkä joku Sato, Kojamo, Nuorisosäätiö tai muu vastaava isompi vuokrakämppäfirma saattaisi tuosta jotain hyötyä saadakin jos saisivat jotain tiedotteita valtakunnallisesti hallinnoitua ja omaa varausjärjestelmää pyöriteltyä. Periaatteessahan tuollaisella järjestelmällä saisi jonkun isomman talokompleksin yleisten tilojen käyttöä järkevöitettyä että esim pyykkitupaa tai saunavuoroja voisi varata vähän kauempana olevasta talosta jos omassa talossa ei olisi vapaana tms.
 
  • Tykkää
Reactions: hmb
Kosketusnäyttöversioita ei ole vielä tullut vastaan.
Muistan jossain uudiskohteessa nähneeni. Siellä sitten valikoiden takana aika geneerisiä, järjestyssäännöt, taloyhtiön uutisia, jotain tiedotteita. Olisiko ollut myös kellonaika ja sää ja joku taloyhtiön speksisivu. Ei kyllä muistaakseni ollut mitäään asukkeiden privaattia osiota vaan pelkkä julkinen puoli. Huoltoväelle mahdollisesti jotain piilotettuna. Noissa on huomattavasti enemmän järkeä uusissa kohteissa kun on talotekniikkaa mahdollisimman paljon ja myös talon puolesta nettiyhteys ja esim. pistorasiat jne. tällaisille. Jossain vanhoissa taloissa ei ole sähkön varastamisen välttämiseksi välttämättä pistorasioita käytävillä - korkeintaan siivoojalle joku yksi reikä jossain epäkäytännöllisessä paikassa. Edellisessä kämpässä taisi olla portaiden juurella ihan katonrajassa yksi pistorasia, jolla pääsi 1. ja 2. kerrokseen pingottamaan imurin johtoa. Ylimmässä kerroksessa sitten ehkä toinen.
 
Missään yksittäisissä taloyhtiöissä tuskin on mitään järkeä tuollaisia digi-ilmoitustauluja/varausnäyttöjä asennella mutta ehkä joku Sato, Kojamo, Nuorisosäätiö tai muu vastaava isompi vuokrakämppäfirma saattaisi tuosta jotain hyötyä saadakin jos saisivat jotain tiedotteita valtakunnallisesti hallinnoitua ja omaa varausjärjestelmää pyöriteltyä. Periaatteessahan tuollaisella järjestelmällä saisi jonkun isomman talokompleksin yleisten tilojen käyttöä järkevöitettyä että esim pyykkitupaa tai saunavuoroja voisi varata vähän kauempana olevasta talosta jos omassa talossa ei olisi vapaana tms.
Juuri näin. Lisäksi tiedän ainakin yhden asunto-osakeyhtiökompleksin, jossa tuollainen sähköinen ilmoitustaulu koettiin tarpeelliseksi mm. sitä kautta, että muiden hyötyjen lisäksi se nostaa pr-arvollaan asuntojen hintaa enemmän kuin mitä se kustantaa. Siinä rullaa käsittääkseni jotain saunavuorolistoja ja kaikenlaisia infoja ja tiedotteita paikallisen asukasyhdistyksen toiminnasta jne. Ei siis ole kosketusnäyttö, vaan ihan staattinen seinätaulu, jonka sisältöä hallitaan jonkun webbipalvelun kautta.

Joku tämän tyyppinen siis:

 
1676668322186.png

Danske Bankin aktivointisivu ei edelleenkään toimi. Yksi noista HTTP-requesteista palauttaa virheen 503 Service Unavailable ja yksi näyttää palauttavan virheen 401 Unauthorized, en tiedä liittyvätkö ongelmaan. Sivun sisältönä on edelleenkin vain punainen laatikko, jossa lukee "Internal Error. Please try again later."

Danske Bankin asiakaspalvelu ei suostu ottamaan ongelmasta kuvakaappauksia vastaan, koska "tietoturvasyistä" ottavat vastaan vain verkkopankkiin kirjautuneena lähetettyjä kuvakaappauksia. Ja tässähän nyt tietysti on ongelmana, että en pääse verkkopankkiin kirjautumaan ollenkaan, kun sivut heittävät vain virhettä. Käskevät käyttämään Microsoft Edgeä.

Myöskään Savonian Reppu-palveluun en pääse edelleenkään. Microsoftin Sharepoint-kirjautuminen antaa saman virheen kuin ennenkin. Koulussa on nyt viime päivinä ollut muitakin ongelmia digijuttujen kanssa näiden koko ajan jatkuvien ongelmienkin lisäksi.

Jonkun järjestelmissä olevan bugin takia minua ei lisätty automaattisesti kursseille ja kaikki pitää nyt tehdä manuaalisesti. En jaksa enää tapella näiden kanssa. Miten yksinkertaisetkin nettisivut ja kirjautumislomakkeet voidaan aina tunaroida niin pahasti, että ne eivät toimi edes Firefoxin modaamattomalla 109.0.1-versiolla?

Asensin virtuaalikoneeseen waretetun Windows 10:n ja pääsin sillä kerran kirjautumaan sisään tuonne Savonian Reppuun, mutta kun kokeilin overridettää selaimen user-agent stringin samaksi kuin Firefoxin Linux-versiossa, niin se alkoi antamaan taas virhesivua eikä korjautunut enää edes vaihtamalla user-agent stringin takaisin oletukseksi.
 
Viimeksi muokattu:
Asensin virtuaalikoneeseen waretetun Windows 10:n ja pääsin sillä kerran kirjautumaan sisään tuonne Savonian Reppuun, mutta kun kokeilin overridettää selaimen user-agent stringin samaksi kuin Firefoxin Linux-versiossa, niin se alkoi antamaan taas virhesivua eikä korjautunut enää edes vaihtamalla user-agent stringin takaisin oletukseksi.
...ja vaikka kaikilla muilla tuhansilla opiskelijoilla kaikki toimii ongelmitta joka ikinen päivä, niin vika on kaiken tämänkin jälkeen edelleen mielestäsi palveluntarjoajassa, eikä sinun omissa virityksissä?
 
Kyllä se protokolla olisi kaikesta huolimatta ihan hyvä olla paperille kirjoitetussa verkko-osoitteessa aina mukana. Se tekee asioista paljon selkeämpiä.
Tässä kai se suurin juju on siinä http vai https osaa voi myös hämmentää www puuttuminen.

Tunnuslukulaitteita käyttää myös he joilla ei ole yhteensopivaa laitetta mihin asentaa se tunnistusohjelma. jollain random selaimella random laitteella. No jos nyt käyttäjä jollain vihamielisella yhteydellä/laitteella/selaimella naputtelee pelkästään sen mitä lapussa luki, niin tuskin se olisi palastus vaikka olisi lukenut koko rimpsu.

Vaikka en nyt välttämättä kannata että aina pitäisi kirjoittaa protokolla rimpsu, mutta pidän tärkeänä että tietotekniikka ohjoissa ei mitään jätetä pois, sen varaan että käyttäjä kyllä arvaa. Mutta tuon osoitteen osalta, osa selaimista piilottaa http rimpsun ja jos osoite vielä edelleen ohjaa, sekin vielä muuttuu.
 
1676668322186.png

Danske Bankin aktivointisivu ei edelleenkään toimi. Yksi noista HTTP-requesteista palauttaa virheen 503 Service Unavailable ja yksi näyttää palauttavan virheen 401 Unauthorized, en tiedä liittyvätkö ongelmaan. Sivun sisältönä on edelleenkin vain punainen laatikko, jossa lukee "Internal Error. Please try again later."

503 favicon.ico-pyynnölle on aika yleistä. Tossa virheen 401 savassa oleellisempaa kuin response headerit olisi request headerit, joissa epäilisin ettei sinulla ole kaikki kohdallaan. Siellä pitäisi olla mm. tällaista, jonka jo edellisellä sivulla laitoin:

Cookie2595d2670965f08157d1e78683d94c59=f95c76d7af27e4dc88f0739ac7f34ab8; NSC_JOf1ljofbzlnbmid4qjq1abjjxoujbU=ffffffff098dde0745525d5f4f58455e445a4a42378b; NSC_JOnnnq1xcc3wxsndb4nwnhbud3waadQ=14b5a3d915babb449bcd361bf51d5f47286e362a517dd99b112fc56b43cc3013a11163d2; __Host-SID=5a3f0cbb-c096-4cc8-9561-62ea7f5920f7; NSC_JOthsdcpcosvsgrbxassunczsycgzdT=ffffffff098dde0445525d5f4f58455e445a4a42378b; __Host-NSSID.nonce=1910a5377934bf9ec67de3ac2df8af40346ee95b5e0a23913ba6fad8785b4c28

Oletan, että sinulla tuo rimpsu on lyhyempi. Sivu toimii ihan hyvin Firefoxin 109.0.1-versiolla.
 
Tässä kai se suurin juju on siinä http vai https osaa voi myös hämmentää www puuttuminen.

Tunnuslukulaitteita käyttää myös he joilla ei ole yhteensopivaa laitetta mihin asentaa se tunnistusohjelma. jollain random selaimella random laitteella. No jos nyt käyttäjä jollain vihamielisella yhteydellä/laitteella/selaimella naputtelee pelkästään sen mitä lapussa luki, niin tuskin se olisi palastus vaikka olisi lukenut koko rimpsu.

Vaikka en nyt välttämättä kannata että aina pitäisi kirjoittaa protokolla rimpsu, mutta pidän tärkeänä että tietotekniikka ohjoissa ei mitään jätetä pois, sen varaan että käyttäjä kyllä arvaa. Mutta tuon osoitteen osalta, osa selaimista piilottaa http rimpsun ja jos osoite vielä edelleen ohjaa, sekin vielä muuttuu.
Melko harvassa ovat sellaisen suurten käyttäjämassojen varteenotettavat palvelut, joissa osoitteen alku olisi pakollinen. Pääsääntöisesti kaikissa nykyaikaisissa palveluissa on yksi simppeli markkinointiosoite tyyliin domain.com, josta sitten tapahtuu taustalla sopiva edelleenohjaus halutulle verkkosivulle ja salausmenetelmälle, riippumatta siitä kirjoittaako käyttäjä selaimeensa minkä tahansa seuraavista:

Koodi:
http://domain.com
https://domain.com
http://www.domain.com
https://www.domain.com
domain.com

Näin on myös tässä tapauksessa ja jos ei toimi, vika on suurella todennäköisyydellä käyttäjän päässä. Se että piilottaako selain käyttäjältä epäolennaisen osan osoitteesta, ei ole merkittävää.
 
503 favicon.ico-pyynnölle on aika yleistä. Tossa virheen 401 savassa oleellisempaa kuin response headerit olisi request headerit, joissa epäilisin ettei sinulla ole kaikki kohdallaan. Siellä pitäisi olla mm. tällaista, jonka jo edellisellä sivulla laitoin:

Cookie2595d2670965f08157d1e78683d94c59=f95c76d7af27e4dc88f0739ac7f34ab8; NSC_JOf1ljofbzlnbmid4qjq1abjjxoujbU=ffffffff098dde0745525d5f4f58455e445a4a42378b; NSC_JOnnnq1xcc3wxsndb4nwnhbud3waadQ=14b5a3d915babb449bcd361bf51d5f47286e362a517dd99b112fc56b43cc3013a11163d2; __Host-SID=5a3f0cbb-c096-4cc8-9561-62ea7f5920f7; NSC_JOthsdcpcosvsgrbxassunczsycgzdT=ffffffff098dde0445525d5f4f58455e445a4a42378b; __Host-NSSID.nonce=1910a5377934bf9ec67de3ac2df8af40346ee95b5e0a23913ba6fad8785b4c28

Oletan, että sinulla tuo rimpsu on lyhyempi. Sivu toimii ihan hyvin Firefoxin 109.0.1-versiolla.
Minulla on siellä vain kaksi NSC_JO-alkuista keksiä ja sitten yksi tuollainen __Host-SID-alkuinen.

Melko harvassa ovat palvelut, joissa osoitteen alku olisi pakollinen. Pääsääntöisesti kaikissa nykyaikaisissa palveluissa on yksi simppeli markkinointiosoite tyyliin domain.com, josta sitten tapahtuu taustalla sopiva edelleenohjaus halutulle verkkosivulle, riippumatta siitä kirjoittaako käyttäjä selaimeensa minkä tahansa seuraavista:

- Website Domain Names, Online Stores & Hosting - Domain.com
- Website Domain Names, Online Stores & Hosting - Domain.com
- Website Domain Names, Online Stores & Hosting - Domain.com
- Website Domain Names, Online Stores & Hosting - Domain.com
- domain.com

Näin on myös tässä tapauksessa ja jos ei toimi, vika on suurella todennäköisyydellä käyttäjän päässä. Se että piilottaako selain käyttäjältä epäolennaisen osan osoitteesta, ei ole merkittävää.
Idea tuossa protokollan lisäämisessä linkkiin on siinä, että tunnistaa, mikä on osa linkkiä ja mikä ei. Samasta syystä se linkki on hyvä myös alleviivata. Se lisää selkeyttä huomattavasti eikä ole iso asia tehdä.
 
Idea tuossa protokollan lisäämisessä linkkiin on siinä, että tunnistaa, mikä on osa linkkiä ja mikä ei. Samasta syystä se linkki on hyvä myös alleviivata. Se lisää selkeyttä huomattavasti eikä ole iso asia tehdä.
Suurinta osaa käyttäjistä ei asia kiinnosta, eivätkä ymmärrä eroa vaikka pintapuolisesti kiinnostaisikin. Olennaisempaa on että asiat toimivat turvallisesti.

Siksi siis automaattinen edelleenohjaus käyttäjän tekemisistä huolimatta ja samasta syystä myös selaimet näyttävät niitä lukko-ikoneita jne. kertomaan käyttäjille sivun turvallisuudesta kryptisten merkkisarjojen sijaan. Ei sillä kuuhun mennä, mutta on se selkeämpi silti suurille käyttäjämassoille.
 
Melko harvassa ovat sellaisen suurten käyttäjämassojen varteenotettavat palvelut, joissa osoitteen alku olisi pakollinen. Pääsääntöisesti kaikissa nykyaikaisissa palveluissa on yksi simppeli markkinointiosoite tyyliin domain.com, josta sitten tapahtuu taustalla sopiva edelleenohjaus halutulle verkkosivulle ja salausmenetelmälle, riippumatta siitä kirjoittaako käyttäjä selaimeensa minkä tahansa seuraavista:
Pointti ei ollut se, vaan se että kapulaa tilaavista voi olla laidasta laitaan kokemukseltaan. mukaan lukien ne joilla www koulun käynneet. jolle se www viestii jotain.
https taasen sen takia että nimenomaan https käyttäisi, eikä http.

Tarpeeton uudelleen ohjaus taasen sen takia että siellä osoiterivillä taasen näkyisi se osoite mikä ohjeissa neuvottiin.

Lisäksi sen osoitteen pysyminen helpottaa kirjanmerkkaamista, tai selvittelyä missä nyt ollaan.

On toki parempi että käytetään lyhyitä osoitteita jonkin "https: / /shared-logon.danskebank.com/logon/default/index.html?clientId=TokenActivation-FI-Personal']Logon[/URL]" sijaan. varsinkin silloin jos ja kun nuo kryptiset tuppaa kuolemaan aikaa myöten.

Tuosta nyt huomasi että osoite edelleen ohjaisi ihan eri juuridomainiin.

Näin on myös tässä tapauksessa ja jos ei toimi, vika on suurella todennäköisyydellä käyttäjän päässä. Se että piilottaako selain käyttäjältä epäolennaisen osan osoitteesta, ei ole merkittävää.
Toki vika on aina käyttäjän päässä.
Digatilisointia kun toteutetaan niin pitää myös muistaa se että asiakas on silloin varsin yksin, ei ole sitä asiakaspalvelijaa joka auttaa, lisäksi jos palvelun on tarkoitus olla helposti saavutettavissa niin kaikkea sillaista kannattaa välttää josta voi seurata niitä ongelmia.

Onhan tuo oma ongelmansa ja hämmentävää jos hypätään ihan eri pää domainille. Ei suurimmalle osalla, mutta haparoivalle epävarmalle, on ja samoin osaavalle ja ymmärtävälle hyvin epäilyttävää. Lisäksi ne joilla ei ole pääsyä joka paikkaan, jolloin homma ei enään käyttäjästä kiinni.

Pankkitunnistautuminen on palvelu jota ei kuulu tehdä niin että suurin osa sitä voi käyttää, vaan niin että kaikki sitä voi käyttää.

Kaikki viritykset jotka eivät ole välttämättömiä palvelun saavutettavuuden kannalta niin ollaan nopeasti heikoilla jäillä.

Perusasioiden muuttamine, käyttöliittymän muuttaminen, osoitteiden muuttaminen jne niistä seuraa ongelmia.

Edit
oki vika on aina käyttäjän päässä.
Onko?
Tuo oli sarkasmia :)
Jos homma on toiminut jossain labrassa, ja ei toimi asiakkaalla, niin se on asikkaan vika, niistä joka prosentti on sellaista minkä asiakas pystyy itse korjaamaan, omat toimisesti tai vieraan avulla. osa on sitten palveluntarjoajan päässä, eikä asiakas sitä voi korjata, näistä toki usein syyllistetään asiakasta, joka asiakkaan teko on johtanut siihen.

Asiakkaan vika myös se ettei asiakkaan osaaminen tai kekseliäisyys riittä palvelun käyttöön, asiakkaan pitkää keksi että tässä nyt pitäisi toimia näin, vaikka toisessa hetkessä nimenomaan niin ei saa toimia.
Esim nämä http vs https, osoite vaihtuu kesken surffailun jne.

Ylläoleva edelleen sarkasmia, vai oliko sittenkään...
 
Viimeksi muokattu:
Toki vika on aina käyttäjän päässä.
Onko?

Mitä esimerkiksi minä nyt tässä tapauksessa mahdan sille, että "jostain syystä" Danske Bankin sivu ei anna minun selaimelle oikeita evästeitä?

Jos joku tekee vaikkapa nettisivun, joka menee rikki vaikkapa siitä, että käyttäjän internet-yhteydessä sattuu olemaan liian pitkä latenssi ja selain avaa kaikkien sivulle sisällytettyjen dokumenttien lataamista varten enemmän soketteja kuin sivun tekijä on suunnitellut ja sivun eri osat latautuvat sitten eri järjestyksessä kuin sivun tekijä on suunnitellut ja sivu ei sen takia toimi, niin onko vika käyttäjän päässä?

Jos joku tekee nettisivun, joka jostain syystä hajoaa lopullisesti jos selaimen user-agent string ei löydy jostain tietystä listasta, niin onko vika käyttäjän päässä?

Nykyään nettisivuilla näkee kaikenlaisia päin helvettiä tehtyjä viritelmiä ja aina jostain syystä syytellään käyttäjää. Tämä on pahempaa kuin ysärillä ja 2000-luvun alussa ollut Internet Explorer -pakotus, jonka sentään pystyi melko helposti kiertämään, koska selaimen "vääräksi" tunnistaminen perustui selaimessa vain yhteen muuttujaan, jota pystyi muissa selaimissa vaihtamaan.
 
Melko harvassa ovat sellaisen suurten käyttäjämassojen varteenotettavat palvelut, joissa osoitteen alku olisi pakollinen.

Ylipäätään www:n olettaminen muuksi kuin yhdeksi mahdollisista alidomaineista on jäänne hirveän kaukaa ja sotkenut hmisten käsityksen URL-osoitteista. Tai toiselta kantilta katsottuna muista alkuajan alidomaineista ei tullutkaan sitä mitä oletettiin ja alidomainit kehittyivätkin eri suuntaan. "activation" on ihan yhtä hyvä alidomain siinä missä "www" tai "ntp". Mutta koska painolasti on valtava ja monet tekniikat laahaavat perässä, tai ehkä ennemmin niiden päivitys ihmisten toimesta, niin tilanne tuskin nopeasti muuttuu miksikään.
 
Kyllä se protokolla olisi kaikesta huolimatta ihan hyvä olla paperille kirjoitetussa verkko-osoitteessa aina mukana. Se tekee asioista paljon selkeämpiä.

Kaikki verkkopankkia käyttämään kykenevät ymmärtävät kyllä, mitä tarkoitetaan, kun annetaan ohje mennä osoitteeseen "io-tech.fi", vaikka protokollaa ei siinä lukisikaan.

Keskimääräinen tietokoneen käyttäjä ei edes tiedä, mitä protokolla tarkoittaa, ja http/https-kirjainyhdistelmänkin hän on nähnyt vain jossain linkeissä, se siitä.


Noin muuten olen monesta asiasta samaa mieltä kuin sinä. Kaiken laittaminen puhelinsovellusten varaan on arveluttavaa, ja nykyään on päässyt vakiintumaan sellainen sairas ajatus, että jollain palvelulla tai sovelluksella olisi "oikeus" saada kerätä puhelimen sarjanumero, sijanti ja muita vastaavia tietoja.

Toisaalta tietokonepuolella vastaavien tietojen kähveltäminen on ollut helpompaa kuin puhelinpuolella, kun ohjelmien toimintaoikeuksia on valvottu vähemmän. Puhelinten myötä siitä on vain tullut hyväksytympää.

Mainitsemasi user-agent samoin kuin referer ja varmaan jokunen muukin vastaava http-protokollan ominaisuus joutaisivat hävitä standardista kokonaan.


Verkkopankkiin kirjaudun paperisella tunnuslukulistalla, kun se edelleen toimii, ihan mielenilmauksenkin vuoksi. Aika pitkään on jo ollut "viimeiset hetket" ottaa tunnuslukusovellus käyttöön, mutta katsotaan, kuinka kauan tätä voi jatkaa. Verkossa maksaminen ei ole enää pitkään aikaan onnistunut paperilistalla.

Minua ärsyttää jatkuva palautteen kysely. Digitalisaatio on tehnyt siitä aivan liian halpaa. Ei voi edes lähikaupassa käydä ruokaostoksilla ilman että kysellään sähköpostissa tai kauppaketjun apissa palautetta. Kaupan sovelluksia ei tietenkään ole pakko asentaa. Mutta niiden avulla saa jopa 10-30% alennuksia tuotteisiin. Ja jos sallii datankeruun, ne tuotteet ovat vieläpä sellaisia mitä tulee ostettua. Kaikki pitää erikseen yrittää kieltää. Jos et kiellä, tulee ensin operaattorin myyntipuhelu, pyytämättä. Sitten kun olet sulkenut puhelun, tulee viestillä kysely "miten onnistuimme?". Tilaat netistä 4 halpaa AA-paristoa. Tulee pyyntö kirjoittaa arvostelu ostamastasi tuotteesta.

Lähikaupan osalta tähän on sentään helppo ratkaisu, maksu käteisellä ja ilman bonuskortteja, niin ei joudu digitaalisen ahdistelun kohteeksi niin helposti. :smoke:

Netistä tilatessa on hieman hankalampaa välttyä tällaiselta, mutta nettikaupoissakin kannattaa esim. tehdä tilaus ilman pysyvää käyttäjätiliä, jos mahdollista, ja jos perään edelleen huudellaan, voi käyttää vaikka GDPR-oikeuksia.
 
Verkkopankkiin kirjaudun paperisella tunnuslukulistalla, kun se edelleen toimii, ihan mielenilmauksenkin vuoksi. Aika pitkään on jo ollut "viimeiset hetket" ottaa tunnuslukusovellus käyttöön, mutta katsotaan, kuinka kauan tätä voi jatkaa. Verkossa maksaminen ei ole enää pitkään aikaan onnistunut paperilistalla.

? Mulla ainakin toimii halutessa kaikki verkkomaksut myös paperisen avainlukulistan kanssa edelleen ihan vanhaan malliin. Tai no tulee siitä se tekstiviestikoodi kyllä, että ihan pelkkä paperi ei riitä, mutta mitään sovelluksia ei kuitenkaan tarvitse. Säästöpankki kyseessä.
 
Viimeksi muokattu:
? Mulla ainakin toimii halutessa kaikki verkkomaksut myös paperisen avainlukulistan kanssa edelleen ihan vanhaan malliin. Tai no tulee siitä se tekstiviestikoodi kyllä, että ihan pelkkä paperi ei riitä, mutta mitään sovelluksia ei kuitenkaan tarvitse.

Riippuukohan tuo pankista sitten. Nordealla ei onnistu.
 
Noin muuten olen monesta asiasta samaa mieltä kuin sinä. Kaiken laittaminen puhelinsovellusten varaan on arveluttavaa, ja nykyään on päässyt vakiintumaan sellainen sairas ajatus, että jollain palvelulla tai sovelluksella olisi "oikeus" saada kerätä puhelimen sarjanumero, sijanti ja muita vastaavia tietoja.

Tuo ei todellakaan ole vakiintunut ajatus. Vaan päinvastoin, niin Android kuin iOS estävät pääsyn puhelimen sarjanumeroon (tai muihin siihen verrattaviin uniikkeihin hardistunnisteisiin, kuten IMEI tai Wifin MAC-osoite).

Sijantidatan käyttökin alkaa olemaan aika hyvin paimennettua, periaatteena, että sitä saa käyttää vain silloin kun sille on oikeasti syy, ja softan pitää toimia vaikka käyttäjä ei anna lupaa (poislukien se osa toiminnasta mikä vaatii sen sijaintidatan)
 
Viimeksi muokattu:
...ja vaikka kaikilla muilla tuhansilla opiskelijoilla kaikki toimii ongelmitta joka ikinen päivä, niin vika on kaiken tämänkin jälkeen edelleen mielestäsi palveluntarjoajassa, eikä sinun omissa virityksissä?
Aika harva tosiaankin vaihtaa tarkoituksella user agentin nimeä. Joskus tätä on tarvinnut esim. estosääntöjen kiertämiseen, kun palvelu voi estää sisällön rekursiivisen kopioinnin wget- tai curl-työkalulla. Palvelulla voi olla hyviä syitä tukea esim. vain Edgeä tai IE:tä. Jos esimerkiksi kehityskuluista on haluttu säästää, voidaan taata tuki vain tietylle selaimelle, joka usein on Microsoftin kehittämä tuote, macOS:n Safari, Androidin integroitu selain (monissa puhelimissa silti eri kuin Chrome) tai iOS:n integroitu selain. Ei ole kauaa aikaa (ehkä viime vuonna) kun vastaan tuli, että SAP:n matkalaskunäkymä julkisella puolella tuki pelkästään IE 11:ta.
 
Pankeista kun oli puhe, just huomasin, että osuuspankin säästöpankin salasana voi olla miten pitkä tahansa, paitsi että ainoastaan 8 ensimmäistä merkkiä merkitsee ja loput on ihan samantekevää, kirjoittaako niitä vai ei. Huomasin kun vahingossa typotin ja silti meni läpi.
 
Viimeksi muokattu:
Pankeista kun oli puhe, just huomasin, että osuuspankin salasana voi olla miten pitkä tahansa, paitsi että ainoastaan 8 ensimmäistä merkkiä merkitsee ja loput on ihan samantekevää, kirjoittaako niitä vai ei. Huomasin kun vahingossa typotin ja silti meni läpi.
Ei varmaan yllättänyt ketään, että pankit harrastavat tätä. Veikkaan että oppilaitosten ja viranomaisten järjestelmissä voi löytyä samaa.

Toisenlainen esimerkki on Huawei. Niiden puhelimissa sai joskus näytön lukittua kahdeksan merkin mittaisella koodilla. Sitten tuli myyntiin uudempia, missä sai vain kuusi merkkiä. Asiaa ei toki mitenkään piiloteltu käyttäjältä, ihan muuten vain parannettiin tietoturvaa kiinalaisittain rajoittamalla koodin pituutta.
 
Ei varmaan yllättänyt ketään, että pankit harrastavat tätä. Veikkaan että oppilaitosten ja viranomaisten järjestelmissä voi löytyä samaa.
No ei tuo mitenkään ennenkuulumatonta kyllä tosiaan ole. Mielellään sitä kyllä uskoisi ja näkisi, että pankki jos joku hoitaisi nämä asiat parhaalla mahdollisella tavalla.
Tässäkin voi jollain olla salasanana esimerkiksi "salasana12höpölöpölööetvarmanaarvaa", pituutensa puolesta hyvinkin hyvä salasana, paitsi että nyt se aukeaa ensimmäisten joukossa kun "salasana" on taatusti ensimmäisiä kokeiltavia sanoja jos joku käy koputtelemassa ja 8 merkkiä ei kauaa kestä vaikka ne ensimmäiset merkit olisi mitä tahansa. Onhan siinä sitten sen jälkeen muitakin varmistuksia vielä olemassa, mutta hölmöä "mokata" näinkin perustavanlaatuisessa asiassa.
 
Tuollaiset salasanojen lyhyysvaatimukset viittaavat myös siihen, että ne salasanat tallennetaan sellaisenaan plaintextinä. Jos ne tallennettaisiin esim. md5- tai sha-tarkistussummana, niin pitkäkään salasana ei veisi "tallennettuna" sen enempää tilaa kuin lyhytkään. Toki tarkistussummana tallennetussa salasanassa on se ongelma, että saman tarkistussumman palauttavia salasanoja on rajaton määrä, mutta käytännössä tarkistussumman laskeminen satunnaiselle merkkijonolle on sen verran hidasta verrattuna satunnaisen merkkijonon vertaamiseen toiseen merkkijonoon, että salasanan tulee olla todella pitkä (hattuvakiolta arvioituna useampia megatavuja), jotta se murtuu keskimäärin nopeammin tarkistussummana tallennettuna verrattuna plaintextinä tallennettuun salasanaan. Niin pitkiä salasanoja harvemmin kukaan käyttää. Sellaisenaan plaintextinä tallennetut salasanat ovat kuitenkin valtava tietoturvariski, jos salasanatietokanta sattuu joskus joutumaan vääriin käsiin.
 
Tuollaiset salasanojen lyhyysvaatimukset viittaavat myös siihen, että ne salasanat tallennetaan sellaisenaan plaintextinä. Jos ne tallennettaisiin esim. md5- tai sha-tarkistussummana, niin pitkäkään salasana ei veisi "tallennettuna" sen enempää tilaa kuin lyhytkään. Toki tarkistussummana tallennetussa salasanassa on se ongelma, että saman tarkistussumman palauttavia salasanoja on rajaton määrä, mutta käytännössä tarkistussumman laskeminen satunnaiselle merkkijonolle on sen verran hidasta verrattuna satunnaisen merkkijonon vertaamiseen toiseen merkkijonoon, että salasanan tulee olla todella pitkä (hattuvakiolta arvioituna useampia megatavuja), jotta se murtuu keskimäärin nopeammin tarkistussummana tallennettuna verrattuna plaintextinä tallennettuun salasanaan. Niin pitkiä salasanoja harvemmin kukaan käyttää. Sellaisenaan plaintextinä tallennetut salasanat ovat kuitenkin valtava tietoturvariski, jos salasanatietokanta sattuu joskus joutumaan vääriin käsiin.

Käyttäjätunnus-kohtaisella suolauksella pystytään ratkaisemaan tämäkin ongelma.
 
Käyttäjätunnus-kohtaisella suolauksella pystytään ratkaisemaan tämäkin ongelma.
Mikä ongelma? Ei suolaus vähennä saman tarkistussumman palauttavien salasanojen määrää mihinkään rajalliseen joukkoon. Suolauksen tarkoitus on, että jos salasanatietokanta joutuu vääriin käsiin, niin mistään valmiista tarkistussummalistasta katsomalla ei voi suoraan tietää salasanaa.
 
Mikä ongelma? Ei suolaus vähennä saman tarkistussumman palauttavien salasanojen määrää mihinkään rajalliseen joukkoon. Suolauksen tarkoitus on, että jos salasanatietokanta joutuu vääriin käsiin, niin mistään valmiista tarkistussummalistasta katsomalla ei voi suoraan tietää salasanaa.

Luinkin tuon viestisi hiukan huolimattomasti.
 
Mitä esimerkiksi minä nyt tässä tapauksessa mahdan sille, että "jostain syystä" Danske Bankin sivu ei anna minun selaimelle oikeita evästeitä?

en tiedä mitä käyttistä ja selainta käytät, mutta ainakin minulla verkkoasetusten private wifi address ja limit ip tracking -asetukset rikkovat joitakin nettisivuja. eli vika ei ole välttämättä selaimessa, vaikka oire siellä näkyykin.
 
Tuo ei todellakaan ole vakiintunut ajatus. Vaan päinvastoin, niin Android kuin iOS estävät pääsyn puhelimen sarjanumeroon (tai muihin siihen verrattaviin uniikkeihin hardistunnisteisiin, kuten IMEI tai Wifin MAC-osoite).

Sijantidatan käyttökin alkaa olemaan aika hyvin paimennettua, periaatteena, että sitä saa käyttää vain silloin kun sille on oikeasti syy, ja softan pitää toimia vaikka käyttäjä ei anna lupaa (poislukien se osa toiminnasta mikä vaatii sen sijaintidatan)

Tuon lähteen mukaan "lue puhelimen tila ja identiteetti" -oikeudella sovellus näkisi mm. puhelimen IMEI-koodin (käytännössä sarjanumeron). Onko tuo vanhentunutta tietoa?


En näe oikein hyväksyttäviä syitä sille, että mikään sovellus saisi ikinä kerätä tällaista yksilöivää tietoa.
 
Tuon lähteen mukaan "lue puhelimen tila ja identiteetti" -oikeudella sovellus näkisi mm. puhelimen IMEI-koodin (käytännössä sarjanumeron). Onko tuo vanhentunutta tietoa?

Android SDK:n API level 29:stä (eli Android 10) lähtien nuo on siirretty priviledged permissionin alle, joka tarkoittaa, että 3rd party appiksilla ei ole pääsyä siihen.
Joten jos on tarpeeksi vanha appis, niin sitten sillä voi vielä olla pääsy tuohon. Mutta Google tasaisin väliajoin nostaa Play Storen minimi API leveliä. Tällä hetkellä vaatimus uusille appiksille on 31, ja jos vanhat appikset ovat alle 30, niin sitten ne eivät enää näy Play Storen haussa.
Eli jos nyt lataat applikaation Play Storesta, sillä applikaatiolla ei ole enää pääsyä IMEI:hin (tai muihin uniikkeihin HW identifiereihin).
 
Tuon lähteen mukaan "lue puhelimen tila ja identiteetti" -oikeudella sovellus näkisi mm. puhelimen IMEI-koodin (käytännössä sarjanumeron). Onko tuo vanhentunutta tietoa?

https://android.stackexchange.com/questions/48709/read-phone-state-and-identity

En näe oikein hyväksyttäviä syitä sille, että mikään sovellus saisi ikinä kerätä tällaista yksilöivää tietoa.
Totta kai on hyväksyttäviä syitä miksi sovellus keräisi yksilöiviä tietoja, jos ja kun sille on tarve niin isojen alustojen ongelma on se että sitä on vaikeutettu, tai jopa estetty.

Erottaisin, kaksi asiaa, oikea tarve, jotta tuote palvelu, asia voidaan toteuttaa, siitä että asia asia voidaan tehdä ilman ja varsinkin siitä että jotain asiaa käytetään muuhunkin kuin siihen mihin se on välttämätön.

Voisi tietenkin ajatella että riittäisi se että käyttäjä päättää, mutta koska kehittäjät eivät ajattele käyttäjää, vaan päinvastoin. Eli jos esimerkin IMEI tietoa vaatisi käyttäjältä luvan, niin kehittäjät kyllä keksii miten se lupa saadaan, jos käyttäjä vastaa ei, niin sitten sitä kysytään uudestaan niin kauan että käyttäjä antaa luvan. Sen jälkeen se ei ole enään käyttäjän käsisissä miten sitä käytetään. Eli sinänsä ihan ymmärettävää miksi alustanylläpitäjät rajoittaa.

Alustan ylläpitäjät voivat tarjota kehittäjille muita rajapintoja joilla voivat saavuttaa saman tavoitteen, mihin ehkä olisivat sitä IMEItä käyttäneet



Se aasinsilta aloitukseen on tuossa kehittäjät ei ajattele käyttäjää, eli keinotekoisesti rakentavat himmeleitä joilla vaikeutetaan käyttöä, itsekkäistä syistä.
 
Totta kai on hyväksyttäviä syitä miksi sovellus keräisi yksilöiviä tietoja, jos ja kun sille on tarve niin isojen alustojen ongelma on se että sitä on vaikeutettu, tai jopa estetty.

Erottaisin, kaksi asiaa, oikea tarve, jotta tuote palvelu, asia voidaan toteuttaa, siitä että asia asia voidaan tehdä ilman ja varsinkin siitä että jotain asiaa käytetään muuhunkin kuin siihen mihin se on välttämätön.

Voisi tietenkin ajatella että riittäisi se että käyttäjä päättää, mutta koska kehittäjät eivät ajattele käyttäjää, vaan päinvastoin. Eli jos esimerkin IMEI tietoa vaatisi käyttäjältä luvan, niin kehittäjät kyllä keksii miten se lupa saadaan, jos käyttäjä vastaa ei, niin sitten sitä kysytään uudestaan niin kauan että käyttäjä antaa luvan. Sen jälkeen se ei ole enään käyttäjän käsisissä miten sitä käytetään. Eli sinänsä ihan ymmärettävää miksi alustanylläpitäjät rajoittaa.

Alustan ylläpitäjät voivat tarjota kehittäjille muita rajapintoja joilla voivat saavuttaa saman tavoitteen, mihin ehkä olisivat sitä IMEItä käyttäneet

Se aasinsilta aloitukseen on tuossa kehittäjät ei ajattele käyttäjää, eli keinotekoisesti rakentavat himmeleitä joilla vaikeutetaan käyttöä, itsekkäistä syistä.

Yksilöivä (pseudoanonyymi) ID kyllä löytyy, Androidissa se on GAID ja iOS:ssa IDFA. Mutta nuo ovat "soft id:eitä", eli käyttäjä voi resetoida ne ja ne eivät ole sidottuja rautaan. Ja ainakin iOS:ssa käyttäjä voi aina kieltää tuon IDFA:n käytön. Tai voi olla, että Androidissakin voi, mutta iOS:ssa sen käyttö pitää erikseen hyväksyä jokaisen appiksen kohdalla.
Hardis ID:lle on aika paha keksiä validia tarvetta kuluttajakäytössä. B2B puolella taaskin tuo olisi usein kätevä, ja itsekin olen kironnut kun siihen ei pääse käsiksi.

Ja nykyään niin iOS:ssa kuin Androidissa on periaate, että jos käyttäjä kerran kieltää jonkun käytön, niin sitten se pitää enabloida laitteen asetuksista. Eli applikaation sisältä ei voi pyytää uudestaan ja uudestaan.
 
Tuo ei todellakaan ole vakiintunut ajatus. Vaan päinvastoin, niin Android kuin iOS estävät pääsyn puhelimen sarjanumeroon (tai muihin siihen verrattaviin uniikkeihin hardistunnisteisiin, kuten IMEI tai Wifin MAC-osoite).
Tilanne on muuttunut paljon. Muistan joskus reilu 10v sitten kun ZTE Bladen IMEI-tunnuksen pystyi ohjelmallisesti jopa vaihtamaan. En muista enää oliko tuo clockworkmodilla tai jollain root-ohjelmalla.
 
Tilanne on muuttunut paljon. Muistan joskus reilu 10v sitten kun ZTE Bladen IMEI-tunnuksen pystyi ohjelmallisesti jopa vaihtamaan. En muista enää oliko tuo clockworkmodilla tai jollain root-ohjelmalla.
Siis sen verkkoon näkyvän? Tuohon "anonyymeissä" tarpeissa kätevää, jos ihan apilla onnistu. (no ilmeisesti ei ollut ainoa)

Tosin pitää olla vahva luotto toimivuuteen, jos ei itse pääse tarkistaan millään tavalla.
 
Siis sen verkkoon näkyvän? Tuohon "anonyymeissä" tarpeissa kätevää, jos ihan apilla onnistu. (no ilmeisesti ei ollut ainoa)

Tosin pitää olla vahva luotto toimivuuteen, jos ei itse pääse tarkistaan millään tavalla.
Joo - tosiaan en osaa sanoa, miten oikeasti toimi, mutta siihen aikaan sai vaikutelman että olisi onnistunut. Tuohon IMEI:n vaihtoon on löytynyt appsejakin, mitä äsken googlailin hiukan. Ei ollut silleen alamaailman tarpeita hoidettavaksi agenttipuhelimella :D
 
Danske on nyt korjannut aktivointisivunsa. Pitkään siinä kestikin.

Koululla systeemit ovat edelleen rikki.
 
Tuollaiset salasanojen lyhyysvaatimukset viittaavat myös siihen, että ne salasanat tallennetaan sellaisenaan plaintextinä. Jos ne tallennettaisiin esim. md5- tai sha-tarkistussummana, niin pitkäkään salasana ei veisi "tallennettuna" sen enempää tilaa kuin lyhytkään. Toki tarkistussummana tallennetussa salasanassa on se ongelma, että saman tarkistussumman palauttavia salasanoja on rajaton määrä, mutta käytännössä tarkistussumman laskeminen satunnaiselle merkkijonolle on sen verran hidasta verrattuna satunnaisen merkkijonon vertaamiseen toiseen merkkijonoon, että salasanan tulee olla todella pitkä (hattuvakiolta arvioituna useampia megatavuja), jotta se murtuu keskimäärin nopeammin tarkistussummana tallennettuna verrattuna plaintextinä tallennettuun salasanaan. Niin pitkiä salasanoja harvemmin kukaan käyttää. Sellaisenaan plaintextinä tallennetut salasanat ovat kuitenkin valtava tietoturvariski, jos salasanatietokanta sattuu joskus joutumaan vääriin käsiin.
Jonkun verran softakehityksen ja autentikoinninkin kanssa pelanneena en oikoisi ihan noin mutkia suoriksi. Aika harva palvelu tallentaa salasanat plaintekstinä, onneksi. Mun projekteista ei yksikään, itse en antais julkaista moista softaa. Kyllä ne hashina yleensä on. Noi minimi/maksimi/monimutkaisuus-rajoitukset tulee yleensä webuin validointisäännöistä. Se miten validointisäännöt speksataan, on toinen juttu.
Asiaa liipaten: kun joku palvelu kertoo ”salasanasi on liian samanlainen kuin aiemmin käyttämäsi” soittaa itsellä kelloja.
 
Jonkun verran softakehityksen ja autentikoinninkin kanssa pelanneena en oikoisi ihan noin mutkia suoriksi. Aika harva palvelu tallentaa salasanat plaintekstinä, onneksi. Mun projekteista ei yksikään, itse en antais julkaista moista softaa. Kyllä ne hashina yleensä on. Noi minimi/maksimi/monimutkaisuus-rajoitukset tulee yleensä webuin validointisäännöistä. Se miten validointisäännöt speksataan, on toinen juttu.
Asiaa liipaten: kun joku palvelu kertoo ”salasanasi on liian samanlainen kuin aiemmin käyttämäsi” soittaa itsellä kelloja.
Toki nykyäänkin vielä plaintext-kantoja on. Hyvä keino on kokeilla salanan palautusominaisuutta palvelussa. Tai sitten lukea noita vihjetekstejä liiasta samanlaisuudesta. Muutenhan tuo tallennusmuoto ei välttämättä selviä mitenkään.

UI-validoinnissa pituudesta valittaminen ei myöskään lopulta eroa käytännössä siitä, että palvelu katkaisisi pois tietystä kohtaa loput merkit. Voi melkein olla huonompi leikata, sillä joku voi näppäillä vaikka alkuun hyväuskoisena jotain matalan entropian sanoja/roskaa.
 

Statistiikka

Viestiketjuista
258 744
Viestejä
4 497 427
Jäsenet
74 278
Uusin jäsen
Mikat89

Hinta.fi

Back
Ylös Bottom