eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plFinanseGrupypl.biznes.bankiLukas - dziadostwo
Ilość wypowiedzi w tym wątku: 56

  • 21. Data: 2002-12-07 09:57:16
    Temat: Re: Lukas - dziadostwo
    Od: "bwwald" <b...@p...onet.pl>


    Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
    news:aspri2$dg2$1@topaz.icpnet.pl...
    > In news:aspqn4$h07$1@korweta.task.gda.pl, allman wrote:
    >
    > Ja mam od ponad 2 lat i jestem zadowolony. Problemy z logowaniem (token)
    > zdarzają się sporadycznie,
    U mnie ostatnio jest to nagminne, chociaz jeszcze nie zablokowalem sobie
    konta. :-) Jesli na tokenie jest "łatwy" do zapamietania ciag cyfr (np:
    224488, lub333445 itd), to nawet nie probuje go "wklepywac" w klucz. System
    praktycznie zawsze odpowiada, ze klucz jest niepoprawny. Z ciagiem cyfr, w
    ktorych latwiej sie pomylic, np. 549617, taki problem jest rzadkoscia. O
    dziwo w systemie transakcyjnym nigdy nie mialem problemow z akceptacja
    klucza, obojetnie czy ciag cyfr to 333344, czy 967346.

    >eksperymentalnie stwierdziłem, że najczęściej
    > ponowna próba logowania z *kolejnym* wskazaniem tokena problem rozwiązuje.
    W moim przypadku, jesli tylko ciag cyfr jest "trudny" do zapamietania,
    sytuacja jest analogiczna.

    > Podejrzewam, że w ten sposób system dokonuje cichej synchronizacji.
    Mam to samo odczucie.

    > Jak prowadzą jakieś prace to nawet 3 nieudane logowania pod rząd nie
    > powodowały zablokowania kanału.
    Rowniez potwierdzam.

    Pozdr,
    Waldek



  • 22. Data: 2002-12-07 10:19:03
    Temat: Re: Lukas - dziadostwo
    Od: "Robert" <s...@o...pl>

    In news:assglt$2l9$1@flis.man.torun.pl, bwwald wrote:
    > Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
    > news:aspri2$dg2$1@topaz.icpnet.pl...
    > > In news:aspqn4$h07$1@korweta.task.gda.pl, allman wrote:
    > >
    > > Ja mam od ponad 2 lat i jestem zadowolony. Problemy z logowaniem
    > > (token) zdarzają się sporadycznie,
    > U mnie ostatnio jest to nagminne, chociaz jeszcze nie zablokowalem
    > sobie konta. :-) Jesli na tokenie jest "łatwy" do zapamietania ciag
    > cyfr (np: 224488, lub333445 itd), to nawet nie probuje go "wklepywac"
    > w klucz. System praktycznie zawsze odpowiada, ze klucz jest
    > niepoprawny. Z ciagiem cyfr, w ktorych latwiej sie pomylic, np.
    > 549617, taki problem jest rzadkoscia.

    Podejrzewasz istnienie jakiegoś filtru wstępnego w algorytmie, który odrzuca
    zbyt regularne sekwencje?
    Ciekawa teza, od teraz zwrócę uwagę.
    Przyznam, że odnoszę się do niej sceptycznie:

    > O dziwo w systemie
    > transakcyjnym nigdy nie mialem problemow z akceptacja klucza,
    > obojetnie czy ciag cyfr to 333344, czy 967346.

    To mogłoby oznaczać jedną z dwóch rzeczy:

    1. o ile faktycznie istnieje coś takiego, co sugerujesz wyżej - to cudo
    działa tylko przy logowaniu
    2. podwójny token przy logowaniu służy synchronizacji; ponieważ ona już
    nastąpiła przy logowaniu, nie pojawia się przy akceptacji transakcji (upływ
    czasu od logowania do tej jest u mnie i pewnie u Ciebie pomijalnie niewielki
    :) )

    > > Podejrzewam, że w ten sposób system dokonuje cichej synchronizacji.
    > Mam to samo odczucie.

    No czekaj, bo się tu pogubiłem - wydawało mi się, że sugerujesz tę skłonność
    do odrzucania regularnych liczb jako alternatywę do wytłumaczenia
    synchronizacji?
    Zatem powiadasz, że obie te przyczyny zachodzą?

    Z ostatniej chwili: w czasie pisania tego posta zalogowałem się dwukrotnie
    pierwszą próbą takimi wskazaniami tokena:
    787875
    600165
    Nie wiem, czy są one wystarczająco "regularne", ale rozumiem, że jesli choc
    raz uda mi się zalogować z bardzo łatwym numerkiem za pierwszym razem, to
    tezę uznasz za obaloną?
    Zapraszam Lukas Tokenowców do testów :)


    --
    Robert
    To reply by email, use ->mkarta<- in place of ->spamtrap<-
    Emaile adresuj do ->mkarta<- zamiast do ->spamtrap<-



  • 23. Data: 2002-12-07 10:48:00
    Temat: Błędny (?) klucz. Było: Lukas - dziadostwo
    Od: "Robert" <s...@o...pl>

    In news:asshv1$uc5$1@topaz.icpnet.pl, Robert wrote:

    > Z ostatniej chwili: w czasie pisania tego posta zalogowałem się
    > dwukrotnie pierwszą próbą takimi wskazaniami tokena:
    > 787875
    > 600165
    > Nie wiem, czy są one wystarczająco "regularne", ale rozumiem, że
    > jesli choc raz uda mi się zalogować z bardzo łatwym numerkiem za
    > pierwszym razem, to tezę uznasz za obaloną?
    > Zapraszam Lukas Tokenowców do testów :)

    Pierwszy korzystam z zaproszenia. Następujące wskazania tokena dały wynik
    sukces w pierwszej próbie (od czasu ostatniego posta):

    183444
    036090
    633555

    Człowiek ma dużą skłonność do strukturyzowania percepcji: widzenia
    regularności, gdzie faktycznie jej nie ma...

    --
    Robert
    To reply by email, use ->mkarta<- in place of ->spamtrap<-
    Emaile adresuj do ->mkarta<- zamiast do ->spamtrap<-



  • 24. Data: 2002-12-07 10:55:47
    Temat: Re: Lukas - dziadostwo
    Od: "bwwald" <b...@p...onet.pl>


    Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
    news:asshv1$uc5$1@topaz.icpnet.pl...
    > In news:assglt$2l9$1@flis.man.torun.pl, bwwald wrote:
    > > Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
    > > news:aspri2$dg2$1@topaz.icpnet.pl...
    > > > In news:aspqn4$h07$1@korweta.task.gda.pl, allman wrote:
    > Podejrzewasz istnienie jakiegoś filtru wstępnego w algorytmie, który
    odrzuca
    > zbyt regularne sekwencje?

    Podejrzewam, ze synchronizacja nastepuje dla latwych do zapamietania
    cyfrach. Te jest szybciej zapamietac i system synchronizujacy "wie", ze na
    tokenie przewaznie jest jeszcze duzo kresek, wowczas latwiej zsynchronizowac
    token. Rzczej wiekszosc zaczyna wpisywac klucz z chwila zmiany wskazania
    tokena, a rzadko z chwila, gdy na tokenie pozostala 1-2 "kreseczki", bo nie
    ma sie pewnosci jak dlugo bedzie wedrowal pakiet.

    > > O dziwo w systemie
    > > transakcyjnym nigdy nie mialem problemow z akceptacja klucza,
    > > obojetnie czy ciag cyfr to 333344, czy 967346.
    >
    > To mogłoby oznaczać jedną z dwóch rzeczy:
    >
    > 1. o ile faktycznie istnieje coś takiego, co sugerujesz wyżej - to cudo
    > działa tylko przy logowaniu

    Dziala rowniez wtedy, gdy dlugo bezskutecznie (kilka razy) odswiezam stan
    konta, chociaz nie przekroczyłem stanu bezczynności, powodujacego utracenie
    lacznosci z serwerem. Wowczas rowniez musze ponownie wpisywac klucz aby sie
    "re-logowac".

    > 2. podwójny token przy logowaniu służy synchronizacji; ponieważ ona już
    > nastąpiła przy logowaniu, nie pojawia się przy akceptacji transakcji
    (upływ
    > czasu od logowania do tej jest u mnie i pewnie u Ciebie pomijalnie
    niewielki
    > :) )
    Ale już przy odswiezaniu stanu konta był nawet godzinny i sytuacja sie
    powtarza.
    (w czasie długiego odswiezania wykonuje inne czynnosci aby pozostac w
    systemie)

    > Z ostatniej chwili: w czasie pisania tego posta zalogowałem się dwukrotnie
    > pierwszą próbą takimi wskazaniami tokena:
    > 787875
    > 600165
    A logowales sie dzisiaj wczesniej?

    > Nie wiem, czy są one wystarczająco "regularne", ale rozumiem, że jesli
    choc
    > raz uda mi się zalogować z bardzo łatwym numerkiem za pierwszym razem, to
    > tezę uznasz za obaloną?
    Nie, bo nie jest to regularnosc, zalezy to czasu od ostatniego logowania.
    Poza tym kazda regula ma wyjatki ;-). W moim przypadku jest to "jedynie"
    zbyt czeste. Zawsze bowiem przy logowaniu bez wzgledu na latwy, czy
    trudniejszy ciag cyfr, wpisuje je w tym samym czasie wskazan tokena. Nie ma
    wiec mowy o zmiennych warunkach z mojej strony.
    I na koniec bardzo dla mnie zastanawiajace: dlaczego od ponad roku nie
    popelnilem bledu przy logowaniach do bankow bez tokena, a tu jest to takie
    czeste? Nie mozna przeciez tak czesto popelniac bledow przy wpisywaniu ciagu
    6 cyfr (haslo wklepuje z zamknietymi oczami), szczegolnie gdy sa one latwe
    do zapamietania.



  • 25. Data: 2002-12-07 11:13:03
    Temat: Re: Błędny (?) klucz. Było: Lukas - dziadostwo
    Od: "bwwald" <b...@p...onet.pl>


    Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
    news:assjla$v8u$1@topaz.icpnet.pl...
    > In news:asshv1$uc5$1@topaz.icpnet.pl, Robert wrote:
    > Pierwszy korzystam z zaproszenia. Następujące wskazania tokena dały wynik
    > sukces w pierwszej próbie (od czasu ostatniego posta):
    > 183444
    > 036090
    > 633555

    Moze Robercie masz stary, dobry, wysynchronizowany token? ;-) Moj nie ma
    jeszcze 3 miesiecy. Wiem, ze moze moje spostrzezenie to spiskowa teoria
    dziejow, ale algorytm synchronizacji nie musi dzialac caly czas. W kazdym
    razie, rzeczywiscie moze tak byc, jak sugerujesz, ze jesli czlowiek cos
    sobie wmowi (falsz), to po pewnym czasie jest gotow w to uwierzyc :-)

    Waldek



  • 26. Data: 2002-12-07 11:29:19
    Temat: Re: Lukas - dziadostwo
    Od: "Robert" <s...@o...pl>

    In news:assk3k$6tt$1@flis.man.torun.pl, bwwald wrote:

    > Podejrzewam, ze synchronizacja nastepuje dla latwych do zapamietania
    > cyfrach.

    Chyba zle Cie zatem wczesniej zrozumialem.
    Zatem nie przypuszczales, ze system *generalnie* odrzuca "latwe" liczby,
    tylko preferencyjnie wybiera je do synchronizacji, tak?

    Łatwych liczb w każdym razie nie odrzuca na pewno, bo wlasnie zalogowalem
    sie sekwencją 000888 (chyba zacznę grać w Totka :)) )

    > Te jest szybciej zapamietac i system synchronizujacy "wie",
    > ze na tokenie przewaznie jest jeszcze duzo kresek, wowczas latwiej
    > zsynchronizowac token.

    Byc moze ktos tak to wymyslil, ale nie jest to zbyt przekonujace. Po
    pierwsze, mam watpliwosci, czy wpisanie liczby wiaze sie z wczesniejszym jej
    zapamietaniem. Ja przepisuje po jednej cyfrze patrzac na token. Byc moze to
    ja jestem nietypowy, niemniej warto zauwazyc, ze 6 cyfr to juz jest na
    granicy pojemnosci typowej short-term memory, zatem byloby to utrudnienie.
    Dlatego nie przekonuje mnie, ze wpisywanie "latwego" numeru jest jakos
    znaczaco szybsze, a tym bardziej ze to przyspieszenie jest kosztem
    "szybszego zapamietywania" - jak piszesz.

    > Rzczej wiekszosc zaczyna wpisywac klucz z
    > chwila zmiany wskazania tokena, a rzadko z chwila, gdy na tokenie
    > pozostala 1-2 "kreseczki", bo nie ma sie pewnosci jak dlugo bedzie
    > wedrowal pakiet.

    Jestem sklonny sie zgodzic, ze jest takie myslenie, choć oczywiście nie ma
    to praktycznego znaczenia, bowiem występuje synchronizacja.
    Najkorzystniejszym zachowaniem (o ile zegar dobrze chodzi) jest
    konsekwentność.

    Co do zalet szybkiego wpisywania dla dokładności synchronizacji, to przecież
    zegar może się spieszyć i spóźniać, a "nietypowo szybkie" wpisanie tak samo
    nie umożliwia dobrej synchronizacji jak nietypowo wolne. Przecież
    synchronizacja i sama weryfikacja nigdy nie następuje bezpośrednio z
    tokenem, a jedynie jego odpowiednio opóźnionym śladem (odczekanie, odczyt,
    wklepanie, przesył). Zatem wybieranie ekstremalnych wartości jako wzorcowych
    jest delikatnie mówiąc nieuzasadnione - zgodzisz się?

    > (w czasie długiego odswiezania wykonuje inne czynnosci aby pozostac w
    > systemie)
    Wiesz oczywiście, że możesz się wylogować, a odświezanie następuje sobie na
    serwerze?

    > A logowales sie dzisiaj wczesniej?
    Tak. Testowałem tezę, której chyba nie postawiłeś, tylko ja tak zrozumiałem,
    patrz wyjaśnienie u góry.

    > strony. I na koniec bardzo dla mnie zastanawiajace: dlaczego od ponad
    > roku nie popelnilem bledu przy logowaniach do bankow bez tokena, a tu
    > jest to takie czeste? Nie mozna przeciez tak czesto popelniac bledow
    > przy wpisywaniu ciagu 6 cyfr (haslo wklepuje z zamknietymi oczami),
    > szczegolnie gdy sa one latwe do zapamietania.

    Dlaczego przypuszczasz, że popelniasz błąd (tak często)? Moim zdaniem system
    celowo pyta w celu synchronizacji. Ale uzależniałbym to nie od łatwości
    liczb, ale raczej od tego, że system widzi, że wpisałeś jego kod sąsiedni (w
    czasie).

    Ja kiedys mialem faktycznie takie zjawisko i bylo wytlumaczenie.
    Wiekszosc innych hasel skladala sie gl. z liter i kilku cyfr, ktore
    wpisywalem z klawiatury glownej.
    Haslo Lukasa wpisuj z klawiatury glownej, potem biore do lewej reki Token, a
    prawa umieszczam na klaw. numerycznej.
    Problem polegal na tym, ze NumLock byl czasami wylaczony (sporadyczny bład
    przy budzeniu z hibernacji - nie odzyskiwal statusu NumLock sprzed
    uspienia).

    W tej sytuacji faktycznie klucz do Lukasa byl czesto bledny, znacznie
    czesciej niz do innych bankow :)

    --
    Robert
    To reply by email, use ->mkarta<- in place of ->spamtrap<-
    Emaile adresuj do ->mkarta<- zamiast do ->spamtrap<-



  • 27. Data: 2002-12-07 11:39:22
    Temat: Re: Błędny (?) klucz. Było: Lukas - dziadostwo
    Od: "Robert" <s...@o...pl>

    In news:assl3v$7qp$1@flis.man.torun.pl, bwwald wrote:

    > Moze Robercie masz stary, dobry, wysynchronizowany token? ;-) Moj
    > nie ma jeszcze 3 miesiecy.
    Mam stary, dogorywający, rozstrojony token :))
    Jakies 2 lata go mam.

    > Wiem, ze moze moje spostrzezenie to
    > spiskowa teoria dziejow, ale algorytm synchronizacji nie musi dzialac
    > caly czas. W kazdym razie, rzeczywiscie moze tak byc, jak sugerujesz,
    > ze jesli czlowiek cos sobie wmowi (falsz), to po pewnym czasie jest
    > gotow w to uwierzyc :-)

    Nie ocenialbym tego w tak negatywnych kategoriach.
    Umysl ludzki ma niebywała zdolnosc ekstrahowania regularnosci, ulatwien,
    ktore oszczedzaja ograniczone zasoby neurologiczne.
    Byc moze jest tak, ze Ty, będac osobą wnikliwą, po zaskakujaco nieudanym
    logowaniu (jestes prawie pewien, ze dobrze wpisales), stawiasz szereg
    szybkich hipotez (niekoniecznie calkiem swiadomie). Jedna z nich jest "moze
    za łatwa liczba"?
    Spojrzales na token, wykryles _jakąś_ regularność i uzyskałeś potwierdzenie,
    ze jest latwa... Popatrz sobie tak przez parę minut na wskazania tokena -
    czy co najmniej 50% ze wskazań nie daje wrażenia przyjemnej
    nieprzypadkowości? Jeśli tak, to mogłeś - utrzymując tę hipotezę - zyskiwać
    dane potwierdzające w dużej części nieudanych logowań. Były też dane
    zaprzeczające, ale tych się tak dobrze nie zapamiętuje, bowiem
    zapamiętywanie zależy m.in. od afektu - dane potwierdzające były przyjemne,
    bowiem karmiły Twoje ego potwierdzając Twoją hipotezę. Znasz pojęcie
    "experimenter bias", prawda?

    No, rozgadałem się ... :)


    --
    Robert
    To reply by email, use ->mkarta<- in place of ->spamtrap<-
    Emaile adresuj do ->mkarta<- zamiast do ->spamtrap<-



  • 28. Data: 2002-12-07 12:34:50
    Temat: Re: Lukas - dziadostwo
    Od: "bwwald" <b...@p...onet.pl>


    Użytkownik "Robert" <s...@o...pl> napisał w wiadomości
    news:assm2p$10j$1@topaz.icpnet.pl...
    > Łatwych liczb w każdym razie nie odrzuca na pewno, bo wlasnie zalogowalem
    > sie sekwencją 000888 (chyba zacznę grać w Totka :)) )
    U mnie dzisiaj tez bezproblemowo przyjmuje kazdy ciag cyfr (kilkanaście
    prob) :-)

    > Dlatego nie przekonuje mnie, ze wpisywanie "latwego" numeru jest jakos
    > znaczaco szybsze
    Znaczaco nie (chyba, ze kilka sekund to znaczacy czas), ale jest szybsze w
    wielu przypadkach. Dla kogos kto nie przeszedł kursu maszynistek łatwiej
    jest wpisac 111222 niż 195203.
    .
    >, a tym bardziej ze to przyspieszenie jest kosztem
    > "szybszego zapamietywania" - jak piszesz.
    W moim przypadku tak własnie jest. Ja zapamietuje wskazanie tokena podobnie
    jak numer telefonu i przy tym jestem wzrokowcem, jak wiekszosc osobnikow
    plci brzydkiej. Sekwencja 2 lub 3 cyfrowa. Upraszczajac, przy trudnej
    sekwencji musze ja powtorzyc 1 raz, przy latwej nie musze powtarzac.

    > > Rzczej wiekszosc zaczyna wpisywac klucz z
    > > chwila zmiany wskazania tokena, a rzadko z chwila, gdy na tokenie
    > > pozostala 1-2 "kreseczki", bo nie ma sie pewnosci jak dlugo bedzie
    > > wedrowal pakiet.

    > Jestem sklonny sie zgodzic, ze jest takie myslenie, choć oczywiście nie ma
    > to praktycznego znaczenia, bowiem występuje synchronizacja.
    > Najkorzystniejszym zachowaniem (o ile zegar dobrze chodzi) jest
    > konsekwentność.
    I o to właśnie chodzi. Nietypowy ciag cyfr niektorzy zapamietaja i wpisza
    szybciej (tak jak łatwy ciag), niektorzy wolniej. Przy łatwym ciagu cyfr
    czas zapamietywania i "wklepania" jego bedzie bardziej zblizony do siebie
    dla wiekszej ilosci populacji.

    > Co do zalet szybkiego wpisywania dla dokładności synchronizacji, to
    przecież
    > zegar może się spieszyć i spóźniać, a "nietypowo szybkie" wpisanie tak
    samo
    > nie umożliwia dobrej synchronizacji jak nietypowo wolne. Przecież
    > synchronizacja i sama weryfikacja nigdy nie następuje bezpośrednio z
    > tokenem, a jedynie jego odpowiednio opóźnionym śladem (odczekanie, odczyt,
    > wklepanie, przesył).
    No i moze o to chodzi, aby czas od wskazania tokena do wykonania operacji
    mial najmniejsze odchylenie standardowe, co IMHO wystepuje dla cyfr
    "łatwych" lub tylko "trudnych", a nie "łatwych+trudnych".

    > Wiesz oczywiście, że możesz się wylogować, a odświezanie następuje sobie
    na
    > serwerze?
    Tak, ale ja nie chce się powtornie logowac, szczegolnie kiedy mam z nim
    problemy.

    > Dlaczego przypuszczasz, że popelniasz błąd (tak często)? Moim zdaniem
    system
    > celowo pyta w celu synchronizacji. Ale uzależniałbym to nie od łatwości
    > liczb, ale raczej od tego, że system widzi, że wpisałeś jego kod sąsiedni
    (w
    > czasie).
    I przewaznie wowczas, gdy na tokenie mam ciag cyfr typu 223344, a nie
    758451? Zobacz ponizej.

    > Ja kiedys mialem faktycznie takie zjawisko i bylo wytlumaczenie...
    Ja zawsze mam wpisana pierwsza czesc klucza. Po zmianie wskazan tokena
    wpisuje cyfry z gornej czesci klawiatury. _Zawsze_ wysylam wskazanie klucza
    _po zniknieciu pierwszej kreski_, bez wzgledu na trudnosc zapamietania cyfr
    (10 sekund wystarcza). Praktycznie tylko przy latwych cyfrach wystepuje blad
    kucza (klawiatura sie nie zacina ;-)) i tylko przy logowaniu.

    PS.
    Chyba zakonczymy, bo modemowcy nas zjedza :-)
    Odpowiadajac jednoczesnie na nastepna wiadomosc: moglo tak byc, przyznam,
    ale nie mam na to wystarczajacych dowodow. Parafrazując, jest tak jak
    mowisz, ale ja mam troche przeciwne zdanie :-)



  • 29. Data: 2002-12-07 13:04:38
    Temat: Re: Lukas - dziadostwo
    Od: "Robert" <s...@o...pl>

    In news:asspt9$d8j$1@flis.man.torun.pl, bwwald wrote:

    > I o to właśnie chodzi. Nietypowy ciag cyfr niektorzy zapamietaja i
    > wpisza szybciej (tak jak łatwy ciag), niektorzy wolniej. Przy łatwym
    > ciagu cyfr czas zapamietywania i "wklepania" jego bedzie bardziej
    > zblizony do siebie dla wiekszej ilosci populacji.

    Różnice między osobami nie powinny mieć znaczenia, poniewaz dane są
    oddzielne dla każdego tokena.

    > No i moze o to chodzi, aby czas od wskazania tokena do wykonania
    > operacji mial najmniejsze odchylenie standardowe, co IMHO wystepuje
    > dla cyfr "łatwych" lub tylko "trudnych", a nie "łatwych+trudnych".

    Nie moge sie oprzec wrazeniu, ze zapominasz o tym, ze porownanie wskazan
    nastepuje zawsze, glownie dla celow weryfikacji. Gdyby synchronizacja byla
    jedynym celem w ogole (a nie weryfikacja), to powyzsze byloby prawdziwe.
    Glownym celem jest jednakze weryfikacja, ktora jest dokonywana na populacji
    wpisow wszelkiem maści (trudnych, łatwych, mieszanych). Synchronizacja to
    wzorcowanie narzędzia. Przy wzorcowaniu korzystniej jest zebrać informację
    na temat wartości typowych, nie ekstremalnych. A jeśli system byłby na tyle
    skomplikowany, że oprócz miary tendencji centralnej dopasowywałby też
    osobniczo parametry rozrzutu, to musiałby zbierać informacje o łatwych i
    trudnych w tym samym stopniu.

    > Chyba zakonczymy, bo modemowcy nas zjedza :-)
    Juz teraz możemy ;)

    > Odpowiadajac jednoczesnie na nastepna wiadomosc: moglo tak byc,
    > przyznam, ale nie mam na to wystarczajacych dowodow. Parafrazując,
    > jest tak jak mowisz, ale ja mam troche przeciwne zdanie :-)

    Przyczynę tego przeciwnego zdania wskazałem w tym poscie, ktorego nie
    cytujesz ;P

    (tym razem wolowina :)) )

    --
    Robert
    To reply by email, use ->mkarta<- in place of ->spamtrap<-
    Emaile adresuj do ->mkarta<- zamiast do ->spamtrap<-



  • 30. Data: 2002-12-08 15:48:48
    Temat: Re: Lukas - dziadostwo
    Od: "Beniowa" <b...@p...wp.pl>


    Użytkownik "Gall" <s...@o...pl> napisał w wiadomości
    news:asqc7v$27t$1@foka.acn.pl...
    > Człowieku zastanów się co piszesz! W tabeli opłat i prowizji jest jak byk
    > napisane "średnie miesięczne saldo" a nie "średnie saldo w danym
    miesiącu".
    > No chyba że miesiąc u Lukasa liczy sobie 2 dni, bo konto założyłem 28
    > listopada i do grudnia nie zdołałem przelać na nie żadnych pieniędzy. Mogę
    > cię zapewnić że tego rodzaju tłumaczenie jest nie do obrony przed
    > jakimkolwiek sądem. Tylko kto by się sądził o 7 zł.

    a czy to nie jest tak, ze:
    1) prowizja 7 zl wywolala u Ciebie nielegalny debet,
    2) skasowali kolejna prowizje w wysokosci 30 zl za nielegalny debet,
    3) wyslali Info do BIKu
    4) przekazali pismo windykatorowi i skasowali kolejne 50 zl za wyjazd
    windykatora...

    Grzegorz


strony : 1 . 2 . [ 3 ] . 4 ... 6


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1