2010-03-16 - No Comments!

SMS

Šiandien kažkodėl mintys nukrypo į trumpųjų žiničių sritį. Visos mobiliojo ryšio bendrovės siūlo skambučių peradresavimo paslaugą, bet kažkodėl nėra trumpųjų žinučių peradresavimo. Kodėl?

Antras pastebėjimas, o labiau idėja - SMS skaitymas per naršyklę. Šiuo metu žinutę galima išsiųsti beveik iš visų operatorių savitarnos svetainių, tačiau nei vienoje iš savitarnos svetainių nemačiau galimybės perskaityti gautas žinutes. Jei nėra galimybės peradresuoti žinutės, tai bent perskaityti ją internete manau turėtų būti galimybė.

2010-03-16 - No Comments!

Captcha reklama

Nemėgstu Captcha kodų, bet kadang vistiek juos naudoja ir naudos, kodėl gi nepanaudojus Captcha reklamos tikslams? Pvz. vietoj standartinio Captcha kodo būtų atvaizduojamas produkto reklaminis baneris ir reikėtų nurodyti koks produktas yra reklamuojamas. Vartotojams nesunku atskirti reklamos teksto nuo prekės pavadinimo ar logotipo, o robotams, mano manymu, taip pakankamai sunkus išbandymas.

UPD: Pasirodo idėja jau sugalvota. Microsoft prieš 2 metus užpatentavo šios idėjos įgyvendinimo mechanizmą.

2010-03-09 - No Comments!

Trumpųjų numerių reklama

Kaip žinoma, asociacija yra vienas geriausių būdų įsiminti tam tikrus dalykus. Idėja paprasta - trumpiojo numerio reklamai panaudoti sąryšį su istoriniais įvykiais. Pvz. turbūt beveik visi žino, kad Žalgirio mūšis įvyko 1410 m., todėl 1410 trumpojo numerio reklamai (nepriklausomai kieno šis numeris) būtų galima panaudoti Vytauto atvaizdą, karo motyvus ir t. t.

2010-03-04 - 2 komentarai

Radijas ir podcast

Galbūt aš nemoku naudotis paieška, bet nei vienoje mano klausomoje lietuviškoje radijo stoties svetainėje aš neradau galimybės užsiprenumeruoti radijo laidas podcast formatu. Susidaro toks įspūdis, kad Lietuvos radijo stotys nevertina naujųjų technologijų bei jų potencialo klausytojų ratui didinti. Pvz. ZipFM talpina laidos „Gatvės lyga“ įrašą į internetą, bet jis pasiekamas tik savaitę. Kodėl? Serverio vietos gaila? Patalpinkite į Sound Cloud ar Mix Cloud. Su malonumu pasiklausyčiau „Švelnūs tardymai“, bet nerandu kur.

Aš nesiklausau radijo laidų tiesiogiai, nes paprasčiausiai pamirštų įsijungti laiku, bet visada stengiuosi nepražiopsoti tarkim „Gatvės lyga“ įrašo internete. Bet tai nėra patogu. Mano manymu, žymiai patogiau būtų, jei galėčiau kartą įsimesti nuorodą į savo grotuvą ir kiekvieną savaitę mane džiugintų naujas laidos įrašas.

Ką manote? Kodėl nėra lietuviškų radijo stočių podcast įrašų? Gal aš išsigalvoju ir jų visai nereikia?

UPD: Mix Cloud svetainėje radau „Gatvės lyga“ įrašus.  Wee. Nėra visų, bet bent jau tiek. Podcast vistiek trūksta ;)

2010-03-04 - No Comments!

Apsaugos nuo reklamos būdai (II dalis)

Kadangi mano subjektyvia nuomone, captcha kodų naudojimas mažina naudojimosi svetainę patogumą, tęsiu galimus būdus išvengti reklamos ar flood problemas.

Alternatyvus medaus puodynių (angl. honeypot) metodas. Robotai dažniausiai stengiasi užpildyti visus rastus formos laukus. Norint apsisaugoti, yra sukuriamas žmonėms nematomas laukas su populiariu pavadinimu (pvz. email). Jei vykdant submit veiksmą, šis laukas bus užpildytas, reiškia rašo robotas ir šį veiksmą praleisti negalima. Minusas - neapsaugo nuo specialiai svetainei pritaikytų robotų.

Minimalus formos užpildymo laikas. Robotai užpildo formas žymiai greičiau nei tai padaro žmogus, todėl priklausomai nuo formos sunkumo galima nustatyti minimalų formos užpildymui skirtą laiką. T.y. jei forma siūnčiama į serverį greičiau nei nustatytas laikas, reiškia didelė tikimybė, kad tai daro robotas. Minusai: neapsaugo nuo specialiai svetainei pritaikytų robotų, nepraleis vartotojus, kurie naudoja auto-complete įrankius.

Kodo obfuskacija arba šifravimas. Baisus žodis obfuskacija (angl. Obfuscated code) reiškia kodo apsunkinimas, norint pvz. sumažinti jo analizės galimybės. Apsaugos esmė -  kodo skanavimo apsunkinimas,  šifruojant arba taikant obfuskacijos metodą. T.y. jei robotas neras formos kodo, reiškia, jis negalės užpildyti formos ir nusiųsti jos į serverį su įrašytais duomenimis. Kita vertus, vartotojai net nepastebės, kad kodas yra šifruotas. Minusai: kodas veikia šiek tiek liečiau.

Blokavimas pagal user-agent atributą. Dažnai robotai naudoja specifinius user-agent atributus, todėl galima blokuoti visus lankytojus turinčius netinkamą arba nenurodytą user-agent parametrą. Minusas: robotai dažnai naudoja naršyklių parametrus.

Dinaminis formos kūrimas. Metodo esmė - dinaminis formos sukūrimas Javascript pagalba. Veiksmingas metodas prieš daugelį robotų, nes javascript palaikymas reikalauja didesnių resursų sąnaudų. Minusas: vis dar pasitaiko lankytojų, kurių naršyklės nepalaiko Javascript, tačiau tokių lankytojų labai ir labai mažai, todėl jiems galima panaudoti <noscript> HTML atributą.

Pagalbinių servisų naudojimas. Galima naudoti 3 šalių apsaugos nuo reklamos paslauga, pvz. Akismet.

Papildomas klausimas gimtąją kalbą. Kaip bebūtų, o lietuviškai kalbančių robotų yra pakankamai mažai (jei išvis yra), todėl apsaugai nuo botų galima panaudoti papildomą klausimą. Šis metodas ypač tinka mažoms bendruomenėms. Pvz. jau apie metus nesulaukiu reklamos forume, nes į paprastą klausimą „Du plius du?“ vis dar nesulaukiau roboto atsakymo ;) Minusas: labai lengva įveikti, jei į boto pagalbą ateina žmogus.

Hibrindinis metodas. Galima panaudoti vieną iš išvardintų viršuje metodų. Ir jei dėl kažkokių priežaščių vartotojui nepavyko jo praeiti, pasiūlyti kaip alternatyvą visų mėgstamą ir mylimą Captcha.

Pastebėjimai

  • Nei vienas iš išvardintų metodų nėra nepriekaištingas ir neapsaugos nuo nukreiptos reklamos ar flood atakos, tačiau nuo 90-99 proc., o Lietuvos atveju dar didesniu procentu, apsaugos nuo kvailų robotų-vorų.
  • Įraše paminėjau tik įdėjas. Skirtingus įgyvendimus galima aptarti komentaruose.
  • Galima naudoti iškart keletą iš išvardintų metodų.

Kokius metodus dar praleidau? Captcha nesiūlyti! :)

2010-03-03 - 3 komentarai

Apsaugos nuo reklamos būdai

Egzistuoja daug būdu kaip svetainės lankytojo neįtraukti į kovą tarp robotų ir sistemos programuotojų. Šiandien pabandysiu apžvelgti, mano manymu, geriausius. Prieš aprašant kiekvieną algoritmą ar apsaugos būdą atskirai, norėčiau dar kartą pažymėti, kad kiekvienas algoritmas turi savo minusų, tačiau visi žemiau išvardinti algoritmai turi vieną savybę - jie palengvina lankytojo dalią. Be to, vėlgi pasikartosiu, manau, kad nereikia bandyti atpažinti ar lankytojas yra robotas ar žmogus, o kovoti su tam tikrais nepageidautinais veiksmais (pvz. reklamos skleidimas). Svarbu ne kas daro, o ką daro.

Pvz. kam reikalingas Captcha kodas registracijos metu?  Tegul robotas užsiregistruoja, bet, jei jis neturės normalios galimybės parašyti komentarą, jis nepadarys didelės žalos, o po tam tikro laiko bus ištrintas dėl neaktyvumo.

Be abejo, kovoti galima keliais frontais - neleisti robotams rašyti, registruotis kol nebus įrodyta, kad rašo žmogus bei atlikti tam tikrų veiksmų prevenciją (pvz. reklamos skleidimas), bet turėtų visiems būti aiškus vienas faktas - lankytojo geriausia neįtraukti į šią kovą.

Pirmasis būdas yra Bajeso teoremos naudojimas. Bajeso filtrai gali savarankiškai, nedaug nusileisdami žmogaus sugebėjimams, atpažinti „blogą“ žinutę. Šį metodą kartais naudoja elektroninio pašto žinučių šlamšto (angl. spam) filtrams sukurti. Metodas yra pakankamai geras, tačiau reikalauja pakankamai didelio įdirbio. Vikipedijos skelbia, kad po mokymo ir didelio įdirbio pasiseka atrinkti iki 95 –97 proc. spamo.

Blokavimas pagal žodį ar jo kaukę - internetinės cenzūros mechanizmas kaip blokuojami tam tikri pranešimai turintys nepageidaujamų žodžių. Šis metodas dažnai nepasiteisina (žr. Scunthorpe problem) kai yra naudojamas vienas, tačiau jo panaudojimais kartu su kitais metodais gali atnešti pakankamai gerų rezultatų.

UPD: Atsiprašau, netyčia paskelbiau viešai šį įrašą, nors jis nebuvo iki galo pabaigtas. Šiek tiek vėliau pratęsiu apie galimus alternatyvius Captcha kodams apsaugos nuo reklamos ir fludo būdus. Laukite pratęsimo ;)

2010-03-03 - 8 komentarai

Filosofija ir Captcha kodai

Nekenčiu Captcha!  Nenoriu būti karo tarp robotų ir programuotojų dalyvis!

Žvelgiant į situaciją filosofiškai, Captcha ir panašių kodų naudojimo perspektyvos vis dar miglotos. Captcha kodai, kurie turėtų būti skirti apsaugoti svetaines nuo nepageidaujamo reklamos robotų aktyvumo, dažnai apsaugo ir nuo nepatyrusių interneto vartotojų. Apibendrinant, gaunasi, kad Captcha geba įveikti tik „protingi“ žmonės ir „protingi“ robotai.

Galiausiai, yra indai, kinai ir kitų tautybių žmonės, kurie padeda reklamos robotams įveikti bet kokio sudėtingumo Captcha kodus. Todėl reklamos ar užtvindimo pranešimais (angl. flood) problemos išlieka nepriklausomai ar naudojamas Captcha kodas ar ne.

Visi Captcha ir panašus robotų nustatymo testai veikia daugmaž vienodu principu, kuris realybėje būtų panašus į bandymą nuspėti ar į buto duris beldžiasi pažįstamas ar nusikaltėlis. Esmė, kad dabartinis dirbtinis intelektas (DI) yra panašaus lygio kaip ir nepatyrusieji interneto vartotojai. Kaip bebūtų gaila, reikia pripažinti, kad egzistuoja interneto vartotojų grupė, kurie pagal internetinio intelekto lygį ir patirtį, yra žymiai „kvailesni“ už robotus (nepamirštam, kad robotus rašo protingi žmonės). Todėl, mano manymu, Captcha kodai yra netiesioginės diskriminacijos pagal internetinę patirtį apraiška. Be to, Captcha ir panašus kodai turi ir kitų problemų:

  • atima ar sumažina neįgaliųjų galimybes naudotis svetaine. Ar kada pagalvojote kaip žmogus su regos sutrikimu turėtų įveikti Captcha? Analogija realiame pasaulyje - Jungtinių Tautų Organizacijos Generalinės Asamblėjos patvirtintos Lygių galimybių neįgaliems žmonėms teikimo bendrosios taisyklės.
  • atima iš sąžiningų vartotojų daugumos galimybę patogiai naudotis svetaine. Gaunas, kad visi vartotojai suprantami kaip robotai iki tol, kol jie neįrodo, kad yra žmonės. Analogija realiame pasaulyje - Nekaltumo prezumpcija, t.y. asmuo laikomas nekaltu, kol jo kaltumas nėra įrodytas įstatymo numatyta tvarka ir pripažintas įsiteisėjusiu teismo nuosprendžiu.
  • Captcha neatlieka savo paskirties, nes neapsaugo nuo neigiamos informacijos pateikimo. Mitai apie Captcha neįveikiamumą jau seniai paneigti.

Yra daug būdų apsaugoti svetainę nuo nepageidaujamos reklamos. Apie jos veikiausiai parašysiu ateityje.

Kaip bebūtų, manau, kad reikia saugoti svetainę ne pagal tai ar vartotojas yra robotas ar žmogus, o pagal vartotojo atliekamus veiksmus. O prašyti vartotojus įvedinėti Captcha kodus, t.y. vykdyti netikslingus veiksmus, norint parašyti pranešimą ar užsiregistruoti, yra resursų naudojimas (laikas, programiniai sprendimai). Be to, kaip minėjau - tai ne tik diskriminacijos apraiška, bet ir savotiškas totalitarizmas iš svetainės kūrėjų. Vienintelis Captcha pliusas - DI vystymo skatinimas.

Ką jus manote šia tema?

2010-03-01 - 10 komentarų

Apie vartotojo vardus ir slaptažodžius (100 tinklaraščio įrašas)

Ar kada nors bandėte paaiškinti vartotojo vardo ir slaptažodžio sąvokas apie internetą ir kompiuterius mažai išmanančiam žmogui? Vakar apturėjau tokią laimę, nes teko mamai aiškinti kaip užsiregistruoti viename iš puslapių. Norėjau, kad išmoktų, todėl leidau jai užsiregistruoti pačiai. Mano mama nėra apie kompiuterius ir internetą nieko nenutuokiantis žmogus. Ji bendrauja Skype, moka rasti reikiamą informaciją Google, žiūri filmus tokiose svetainėse kaip intv.ru ir t. t. Iki šiol, jai nereikėjo niekur pačiai registruotis, nes Skype vartotoją, e. pašto adresą ir kitus būtinus internetinio žmogaus atributus sukuriau aš.  Tačiau atėjo diena, kai jai prireikė užsiregistruoti vienoje svetainėje apie maisto gaminimą.

Vakar man paaiškėjo kokios nepatogios yra registracijos formos.

Bendrai, registracijos forma, mano manymu, yra pakankamai paprasta: vardas, pavardė, prisijungimo vardas, slaptažodis (2 kartus), e. pašto adresas (2 kartus), svetainė, miestas ir gimimo metai ir captcha.

Vardo ir pavardės laukai nesukėlė kažkokių sunkumų, nors iš esmės nesuprantu jo būtinybės registracijos formoje.  Priėjus prie lauko prisijungimo vardas neradau logiško paaiškinimo dėl kokios priežasties po vardo ir pavardė įvedimo reikia sugalvoti dar kažkokį prisijungimo vardą. Be abejo, aš žinau ir suprantu, kad kiekvienas vartotojas turi būti unikalus ir tai bandžiau paaiškinti, tačiau gavau logišką klausimą: „O kodėl e. pašto adresas netinka? Jis gi unikalus.“. Iš tiesų, o kam reikalingas vartotojo vardas?

Kai galiausiai paaiškinau ir perėjom prie slaptažodžio, gavau porciją klausimų:

  • Kodėl nematau ką rašau į slaptažodžio lauką? Paaiškinus apie saugumą, sulaukiau atsakymo: „Aš gi čia vieną ir neturiu ką slėpti.“. Logiškas atsakymas, ar ne? Mano manymu, naršyklėje turėtų būti galimybė vienu paspaudimu įjungti arba išjungti slaptažodžio slėpimą įvedimo laukuose.
  • Kodėl reikia kartoti slaptažodį du kartus? Paaiškinus apie klaidos galimybę, sulaukiau klausimo: „Ar slaptažodį man atsiųs į e. paštą?“. Kai gavo teigiamą atsakymą, dar kartą sužybėjo logiką: „Taigi, jei suklysiu įvedinėdama slaptažodį, vistiek žinosiu koks jis, nes gausiu e. laišku“. Neturiu argumentų prieš šį pasisakymą. Mama teisi.
  • Kodėl man rašo, kad slaptažodis per trumpas? Dar kartą paaiškinau apie saugumą ir vėl sulaukiau kontrargumentų: „Man jokio skirtumo ar parinks slaptažodį ir pavogs mano prisijungimo vardą. Dar kartą užsiregistruosiu.“. Mama eilinį kartą buvo teisi. Jei vartotojui nesvarbu, kad pavogs jo vartotojo vardą ir jis nori tiesiog naudotis paslauga ir turėti lengvai įsimenamą slaptažodį, kodėl puslapio kūrėjai turėtų jam uždrausti tai daryti?
  • Kodėl man rašo, kad slaptažodyje naudojami neleistini simboliai? Paklausiau kokį slaptažodį jį panaudojo. Pasirodo mama buvo įrašiusi slaptažodį rusiškomis raidėmis ir vienoje vietoje buvo tarpas. Vėlgi pritrūkau logiškų argumentų. Kodėl beveik visuose puslapiuose negalima naudoti nelotyniškų raidžiu ir tarpų? Mano manymu, slaptažodis „Myliu mamą“ yra patogesnis už „das754dAs7daswe“, o šių slaptažodžių saugumo lygiai yra daugmaž vienodi. Gal laikas keisti slaptažodžius į slaptas frazes?

Kitus laukus mes gan greitai užpildėm ir be jokių kazusų. Reikėjo pabaigoje paaiškinti kas yra captcha kodas ir kodėl sistemai reikia įrodinėti, kad nesi kupranugaris robotas.

Iš mano patirties, galiu pasakyti, kad registracijai užtektų tik e. pašto ir slaptažodžio laukų. Visą kitą vartotojas turėtų supildyti jau užsiregistravęs, o captcha kodai išvis, mano manymu, nereikalingi. Sistema turi atpažinti žmogų, jam nedalyvaujant.

Straipsniai

2010-02-28 - No Comments!

12 patarimų e. parduotuvės kūrėjams

Mano galvoje kaip visada chaosas. Todėl šiame įraše pabandysiu į vieną surinkti visus techninius pamąstymus apie e. parduotuvės kūrimą. Manau, tai bus naudinga ir man ir jums.

  1. Išsaugokite į cache (atsiprašau kalbininkų, tačiau man sąžinė neleidžia naudoti žodį podėlis) viską ką tik galite: prekių aprašymų puslapius, paieškos rezultatus, prekių krepšelius ir t. t. ir panašiai. Tai padės sumažinti duomenų bazės apkrovimą bei pagreitins sistemos veikimą.
  2. Sumažinkite užklausų į duomenų bazę skaičių.
  3. Naudokite saugomas procedūras (angl. stored procedures). Duomenų bazė tampa izoliuota nuo besikeičiančių verslo taisyklių. Be to, šių procedūrų naudojimas stimuliuoja pakartotinį procedūros naudojimą bei modulumą (angl. modularity). O taip, leidžia padidinti duomenų bazės saugumą. Plačiau: MySQL 5.0 New Features: Stored Procedures.
  4. Išskirkite e. parduotuvę į du skirtingus serverius: viename sistema, kitame - duomenų bazė.
  5. Darykite atsargines kopijas. Banalu, bet patirtis rodo, kad apie atsarginių kopijų darymą kūrėjai pamiršta.
  6. Tikrinkite formas:
    • vartotojui privaloma pasakyti, kad jis kažką padarė blogai;
    • visi užpildyti  laukai po patikrinimo privalo likti užpildyti;
    • peržiūrėkite ar nėra SQL injekcijų.
  7. Apgalvokite veiksmus nulužus serveriui ar užpuolus programišiams (taip pat žinomi kaip hakeriai).
  8. Naudokite SSL sertifikatą tik atsiskaitymų ir kitiems puslapiams, kur reikalingas padidintas saugumo lygis. Kodėl? Tyrimai rodo, kad SSL naudojimas visoje sistemoje padidina kreipimųsi į serverį skaičių, bet nesuteikia papildomos naudos. Be to, gali kilti problemų su Google Analytics.
  9. Pasistenkite nenaudoti ar sumažinti sesijos unikalaus parametro (SSID) naudojimą formuojant svetainės adresą. Šis parametras teršia svetainės adresą, bet nesuteikia kažkokios aiškios naudos. Iškyrus atvejus, kai reikia išsaugoti prekių krepšelio turinį.
  10. Paruoškite e. parduotuvę analizei. Neužtenka į kodą įdėti Google Analytics kodo gabaliuką, pati svetainė turi būti paruošta šio įrankio naudojimui. Plačiau: How to Use Ecommerce Tracking in Google Analytics.
  11. Sudarykite prielaidas standartizuotam turiniui. Plačiau: Canonicalization Defined.
  12. Rašykite dokumentaciją:
    • kitiems programuotojams - žinau, kad programuotojai nekenčia rašyti dokumentacijos, tačiau tai būtina. Prisiminkite, kiek kartų teko keikti programerius, kad jie nepaliko normalios dokumentacijos.
    • e. parduotuvės administratoriams - neužtenka apsaugoti pačią sistemą nuo kvailų vartotojų bei sukurti suprantamą pagalbos sistemą, būtina po savęs palikti vartotojo naudojimosi instrukciją.

Turbūt šiam kartui tiek. Jei į galvą šaus daugiau minčių, pratęsiu.

2010-02-26 - No Comments!

Mobilaus ryšio operatorių socialinė atsakomybė (II dublis)

Turbūt ir patys suprantate, kad sukčiavimas mobiliojo ryšio telefonais yra opi ir sudėtinga problema. Dėl šios priežasties ją būtina spręsti kompleksiškai.

Taigi, pirmiausias ir lengviausiai įgyvendinamas būdas – klientų informavimas:

  • mikro svetainė ar operatoriaus svetainės dalyje būtina informuoti klientus labiausiai paplitusius sukčiavimo būdus bei apie paskutinius užfiksuotus atvejus, rekomenduoti kaip elgtis tam tikroje situacijoje bei kur kreiptis ištikus nelaimei;
  • nemokamas pagalbos telefonas arba bent pagalbos linijos atskira dalis;
  • informaciniai pranešimai apie galimus sukčiavimo atvejus ir būdus SMS žinutę arba e. laišku, pvz. kartu su e. sąskaita;
  • informavimas per socialinius tinklus
  • atskiras infoblokas, kurį galėtų patalpinti visi norintys savo svetainėse, apie saugumą;
  • informavimas apie suteiktus trumpuosius numerius, jų savininkus bei tarifus;
  • jaunosios kartos informavimas apie sukčiavimus ir t. t.;

Be abejo, naivu tikėtis, kad vien informavimas užskirs kelią sukčiavimams, tačiau jei nors mažą dalį žmonių nepavyks apgauti, tai jau bus didelis laimėjimas.

Žmonės dažnai kenčia ir nuo sąlyginai oficialiu „sukčiavimo“ būdų. Todėl antras žingsnis – partnerių kontrolė iš operatoriaus pusės. Patys operatoriai dažniausiai (be tam tikrų išimčių) neteikia trumpųjų numerių, informacinio ir pramoginio turinio paslaugų. Jas teikia partneriai, todėl operatorius kaip tarpininkas turėtų prižiūrėti, kontroliuoti ir esant nusiskundimams taikyti sankcijas bei apie jas informuoti viešai (suprantama, kad dažnai tai konfidenciali informacija, todėl dar prieš sudarant sutartį reikėtų apibrėžti, kad esant nusižengimams, informacija bus viešinama). Be to, mano manymu, būtina reikalauti iš partnerių, kad vartotojai būtų aiškiai informuojami apie paslaugų kainas, apmokėjimo būdus ir paslaugas, kurias gauna už pinigus. Taip pat reikėtų vartotojus informuoti kiekvieną kartą, kai pinigai nuskaičiuojami nuo jų sąskaitos. Galiausiai vartotojams turi būti suteikiama aiški ir suprantama informacija apie tai, kaip atsisakyti paslaugos.

Bendrai, būtų puiku įgyvendinti patvirtinimo ir informavimo funkcionalumus, t.y. prieš nurašant pinigus už tam tikrą paslaugą nuo sąskaitos vartotojas turėtų patvirtinti savo sutikimą SMS žinutę arba mygtuko paspaudimų. Pvz., paskambini mokamų numeriu, robotas praneša, kad šis skambutis yra didesnio tarifo ir pasako minutės ar sujungimo kainą. Taip pat kartu su kitais operatoriais būtų galima nustatyti standartą, kad nusiuntus bet kokių trumpuoju numeriu žinutę su „?“ būtų nemokamai suteikiama informacija apie paslaugą, jos teikėją ir t. t.

Trečias žingsnis – operatoriaus atsakomybė. Operatorius kaip tarpininkas turėtų aiškiai apibrėžti savo politika sukčiavimo, nusiskundimų bei bendravimo su teisėsauga atvejais.

Taip pat man kaip paprastam vartotojui būtų įdomu sužinoti atsakymus į tokius klausimus:

  • Kokiais atvejais yra kompensuojami klientų nuostoliai?
  • Ar pinigai bus grąžinami visoms išaiškinto sukčiavimo aukoms ar tik toms kas parašė prašymą ar skundą?
  • Kaip kovojama su pasikartojančiais sukčiavimo atvejais?

Manau, apibrėžus jos viešai, padidėtų tam tikras pasitikėjimo ir skaidrumo lygis. Ką Jūs manote? Ką dar turėtų padaryti operatorius, kad apsaugotų savo klientus nuo sukčiavimo?