W dniu 2013-11-12 12:54, Andrzej Lawa pisze:
> W dniu 12.11.2013 12:07, Tomasz Kaczanowski pisze:
>
>> Np do grafiki, bo te, jeśli chce się używać w pełni sprzętu wymagają
>> większej ilości informacji co do tego, jak je wykorzystać. I tak -
>> działać wbudowane działają, jednak, jeśli chcemy mieć akcelerację, to
>> już trzeba raczej szukać sterowników spoza tych tworzonych przez
>> linuksowców. I ciekawe zachowania mogą być przy aktualizacji w
>
> SOA#1
>

A czy ja napisałem, że nie działa w ogóle? Pokazałem nawet przykład, na
jednym sprzęcie działa bezproblemowo, ale tez i przykład, że na drugim
niekoniecznie. Pomijam już problemy przy architekturach innych niż x86,
no ale to ułamek rynku i nie o tym rozmawiamy, bo tam windowsa też nie
ma, a większość tych architektur jest juz leciwa...


--
Kaczus
http://kaczus.ppa.pl

do góry

W dniu 12.11.2013 12:17, Wojciech Bancer pisze:
>> ie ma sensu tworzyć niepublicznej specyfikacji, bo "security
>> >by obscurity" nie bez powodu ma kiepską prasę, działa tylko
>> >od biedy na *małą* skalę, nie w czymś dostępnym publicznie.
> Nie chodzi o kwestię security w sensie błędów w ablikacji, tylko o kwestię
> zaufania do autora aplikacji. Dane jakie latają w takim płatniku pozwalają
> na autoryzację "się" w dowolnym chyba banku telefonicznie i przejście
> procedury "odzyskania konta", tudzież na wymyślenie bardziej wymyślnych
> metod zaszkodzenia komuś.
>
> Brak też jest potwierdzenia że urząd dane oprogramowanie akceptuje,
> przetestował i że dane które otrzymał i potwierdził są rzeczywiście
> tymi danymi które wysyłasz.
>
> Można to oczywiście rozwiązać inaczej niż "pełnym zamknięciem",
> ale cokolwiek spodziewałbym się utrzymania nad tym kontroli, a nie
> puszczenia publicznej dokumentacji "i cześć".
>

Nie rozumiem w jaki sposób puszczenie publicznej dokumentacji "i cześć"
formatu wymiany danych płatnika miałoby grozić dostaniem się tego w
niepowołane ręce.

Popatrz na to co się wysyła mailem - dane często stokroć bardziej
wrażliwe, a jednak protokół IMAP/POP/SMTP jest od zawsze jawny.

p. m.

do góry

On 2013-11-12, m <m...@g...com> wrote:

[...]

> Nie rozumiem w jaki sposób puszczenie publicznej dokumentacji "i cześć"
> formatu wymiany danych płatnika miałoby grozić dostaniem się tego w
> niepowołane ręce.
>
> Popatrz na to co się wysyła mailem - dane często stokroć bardziej
> wrażliwe, a jednak protokół IMAP/POP/SMTP jest od zawsze jawny.

Patrzę i widzę, i znam wiele przypadków wykorzystania tego do zaszkodzenia
firmie, wykradzenia informacji wrażliwych, podszywania się itd.
Znakomity wręcz przykład.

--
Wojciech Bańcer
p...@p...pl

do góry

W dniu 12.11.2013 13:07, Wojciech Bancer pisze:
> On 2013-11-12, m <m...@g...com> wrote:
>
> [...]
>
>> Nie rozumiem w jaki sposób puszczenie publicznej dokumentacji "i cześć"
>> formatu wymiany danych płatnika miałoby grozić dostaniem się tego w
>> niepowołane ręce.
>>
>> Popatrz na to co się wysyła mailem - dane często stokroć bardziej
>> wrażliwe, a jednak protokół IMAP/POP/SMTP jest od zawsze jawny.
>
> Patrzę i widzę, i znam wiele przypadków wykorzystania tego do zaszkodzenia
> firmie, wykradzenia informacji wrażliwych, podszywania się itd.
> Znakomity wręcz przykład.

I przyczyną jest otwarta specyfikacja protokołu? A nie przypadkiem może
brak szyfrowania bądź niedostatki samego protokołu (SMTP)?

Czy sądziesz że jakby ukryć specyfikację SMTP, to by podszywanie sie za
jego pomocą było trudniejsze?

p. m.

do góry

On 2013-11-12, m <m...@g...com> wrote:

[...]

>> Patrzę i widzę, i znam wiele przypadków wykorzystania tego do zaszkodzenia
>> firmie, wykradzenia informacji wrażliwych, podszywania się itd.
>> Znakomity wręcz przykład.
>
> I przyczyną jest otwarta specyfikacja protokołu? A nie przypadkiem może
> brak szyfrowania bądź niedostatki samego protokołu (SMTP)?

Poddaję w wątpliwość nie istotę otwartości protokołu, tylko brak
możliwości stwierdzenia _wiarygodności_ dostawcy danego rozwiązania
i brak kontroli nad tymże. W przypadku płatnika za jego wiarygodność
odpowiada urząd który z firmą umowę podpisał.

Maile to trochę inna klasa problemu, przede wszystkim nie każdy mail
zawiera dane wrażliwe, a do ich analizy trzeba posadzić człowieka.
Nie każdy mail wywołuje też skutki prawne.

--
Wojciech Bańcer
p...@p...pl

do góry

W dniu 12.11.2013 13:50, Wojciech Bancer pisze:
> On 2013-11-12, m<m...@g...com> wrote:
>
> [...]
>
>>> >>Patrzę i widzę, i znam wiele przypadków wykorzystania tego do zaszkodzenia
>>> >>firmie, wykradzenia informacji wrażliwych, podszywania się itd.
>>> >>Znakomity wręcz przykład.
>> >
>> >I przyczyną jest otwarta specyfikacja protokołu? A nie przypadkiem może
>> >brak szyfrowania bądź niedostatki samego protokołu (SMTP)?
> Poddaję w wątpliwość nie istotę otwartości protokołu, tylko brak
> możliwości stwierdzenia_wiarygodności_ dostawcy danego rozwiązania
> i brak kontroli nad tymże. W przypadku płatnika za jego wiarygodność
> odpowiada urząd który z firmą umowę podpisał.

Ale co ma wiarygodności urzędu bądź Prokomu do bezpieczeństwa danych
które latają?

Jeżeli protokół jest kiepski, np. nie jest szyfrowany, to urząd choćby
nie wiem jak był wiarygodny - nie ustrzeże mnie przed wykradnięciem
moich danych.

p. m.

do góry

On 2013-11-12, m <m...@g...com> wrote:

[...]

>> Poddaję w wątpliwość nie istotę otwartości protokołu, tylko brak
>> możliwości stwierdzenia_wiarygodności_ dostawcy danego rozwiązania
>> i brak kontroli nad tymże. W przypadku płatnika za jego wiarygodność
>> odpowiada urząd który z firmą umowę podpisał.
>
> Ale co ma wiarygodności urzędu bądź Prokomu do bezpieczeństwa danych
> które latają?
>
> Jeżeli protokół jest kiepski, np. nie jest szyfrowany, to urząd choćby
> nie wiem jak był wiarygodny - nie ustrzeże mnie przed wykradnięciem
> moich danych.

Ok. To ja (albo jakaś bliżej mi znana, a Tobie nieznana) napiszę apkę
która będzie listować i robić przelewy z konta Twojego banku. Rozumiem
nie będziesz miał *żadnych* problemów z używaniem takiej aplikacji,
bo przecież protokół z jakim będzie się program łączyć będzie szyfrowany
(https), czy tak?

--
Wojciech Bańcer
p...@p...pl

do góry

W dniu 2013-11-12 14:09, Wojciech Bancer pisze:
> On 2013-11-12, m<m...@g...com> wrote:
>
> [...]
>
>>> Poddaję w wątpliwość nie istotę otwartości protokołu, tylko brak
>>> możliwości stwierdzenia_wiarygodności_ dostawcy danego rozwiązania
>>> i brak kontroli nad tymże. W przypadku płatnika za jego wiarygodność
>>> odpowiada urząd który z firmą umowę podpisał.
>>
>> Ale co ma wiarygodności urzędu bądź Prokomu do bezpieczeństwa danych
>> które latają?
>>
>> Jeżeli protokół jest kiepski, np. nie jest szyfrowany, to urząd choćby
>> nie wiem jak był wiarygodny - nie ustrzeże mnie przed wykradnięciem
>> moich danych.
>
> Ok. To ja (albo jakaś bliżej mi znana, a Tobie nieznana) napiszę apkę
> która będzie listować i robić przelewy z konta Twojego banku. Rozumiem
> nie będziesz miał *żadnych* problemów z używaniem takiej aplikacji,
> bo przecież protokół z jakim będzie się program łączyć będzie szyfrowany
> (https), czy tak?


Ale przecież ma takie appki - dowolne przeglądarki http wystarczą do
tego aby połączyć się do większości banków, zazwyczaj wymaganiem jest
połączenie szyfrowane.


--
Kaczus
http://kaczus.ppa.pl

do góry

W dniu 12.11.2013 14:13, Tomasz Kaczanowski pisze:
> W dniu 2013-11-12 14:09, Wojciech Bancer pisze:
>> On 2013-11-12, m<m...@g...com> wrote:
>>
>> [...]
>>
>>>> Poddaję w wątpliwość nie istotę otwartości protokołu, tylko brak
>>>> możliwości stwierdzenia_wiarygodności_ dostawcy danego rozwiązania
>>>> i brak kontroli nad tymże. W przypadku płatnika za jego wiarygodność
>>>> odpowiada urząd który z firmą umowę podpisał.
>>>
>>> Ale co ma wiarygodności urzędu bądź Prokomu do bezpieczeństwa danych
>>> które latają?
>>>
>>> Jeżeli protokół jest kiepski, np. nie jest szyfrowany, to urząd choćby
>>> nie wiem jak był wiarygodny - nie ustrzeże mnie przed wykradnięciem
>>> moich danych.
>>
>> Ok. To ja (albo jakaś bliżej mi znana, a Tobie nieznana) napiszę apkę
>> która będzie listować i robić przelewy z konta Twojego banku. Rozumiem
>> nie będziesz miał *żadnych* problemów z używaniem takiej aplikacji,
>> bo przecież protokół z jakim będzie się program łączyć będzie szyfrowany
>> (https), czy tak?
>
>
> Ale przecież ma takie appki - dowolne przeglądarki http wystarczą do
> tego aby połączyć się do większości banków, zazwyczaj wymaganiem jest
> połączenie szyfrowane.

I protokół jest jawny.

p. m.

do góry

On 2013-11-12, Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> wrote:

[...]

>> Ok. To ja (albo jakaś bliżej mi znana, a Tobie nieznana) napiszę apkę
>> która będzie listować i robić przelewy z konta Twojego banku. Rozumiem
>> nie będziesz miał *żadnych* problemów z używaniem takiej aplikacji,
>> bo przecież protokół z jakim będzie się program łączyć będzie szyfrowany
>> (https), czy tak?
>
> Ale przecież ma takie appki - dowolne przeglądarki http wystarczą do
> tego aby połączyć się do większości banków, zazwyczaj wymaganiem jest
> połączenie szyfrowane.

Nie tego dotyczył mój opis. Proszę przeczytaj ze zrozumieniem
co napisałem.

--
Wojciech Bańcer
p...@p...pl

do góry