rozie

I don't like the bugs but the bugs like me

Dobre Uwagi

blog: https://zakr.es/blog/
homepage: https://zakr.es/

Public Key

npub13jm33heneuckx9zfgxqnal59gl6q8xvrc0zsyxfh63pdr3pwq8rshsq3xa

NIP-05 Address

Profile Code

nprofile1qqsgedccmueu7vtrz3y5rqf7l6z50aqrnxpu83gzrymagsk3cshqr3cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds4c9dv3

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub13jm33heneuckx9zfgxqnal59gl6q8xvrc0zsyxfh63pdr3pwq8rshsq3xa

Show more details

Last Notes

2026-04-03 21:23:17 UTC

- reply

Ah, you mean external ID (name? 🤔). I mean internal one. It's random in case of Firefox. But it's fixed and the same as the external external one in Chromium. That's why extension's files can be accessed.

2026-04-03 21:01:40 UTC

- reply

For what things fixed IDs are necessary? And why Firefox doesn't have fixed IDs, then?

2026-04-03 19:10:18 UTC

- reply

I'll need to take a closer look how exactly it's made.
I was aware of the technique where extension interacting with the site (so, in a way, trusting it, but only in a way) was also allowing this site to interact with own files. With fixed ID it allowed to check if extension is present. And this is one of described techniques. Those extensions probably declare interaction with LI (or any site) via web_accessible_resources.
Without fixed ID it (fetch of the file) wouldn't work.

2026-04-03 14:06:30 UTC

- reply

This is trusted website. But yes, it's feature by Google, present in Chromium for years - extensions have fixed IDs.

2026-01-18 15:07:06 UTC

- reply

Odpowiedziałem na nie i nie zamierzam się powtarzać. Którego słowa nie zrozumiałeś?
Naprawdę nie odpowiadam za to co się komu wydaje, że jest napisane, czy to w badaniach, czy w moich postach.

2026-01-17 08:14:59 UTC

- reply

"Not everything is about you." Nie zamierzam się powtarzać, więc odeślę we właściwe miejsce:
https://mastodon.online/@rozie/115905710568662567
Wyjąłeś tytuł i pojedynczy wniosek z kontekstu, pominąłeś oczywiste red flags, ignorujesz zastrzeżenia autorów, a teraz chyba zamierzasz dyskutować z ich wyrażonym wprost zdaniem. Jakiego fikoła się spodziewać? Zamierzasz znowu zignorować kontekst i twierdzić, że nie pisali tu o programowaniu? Że użyteczne nie oznacza tu szybsze?
#note1m58…fqhc

2026-01-16 17:04:44 UTC

- reply

No tak sobie tłumacz. W końcu wiesz lepiej co chcieli napisać i dlaczego się tam znalazły. A że kontekst nie pasuje? Trudno.
Autorzy wprost twierdzą, że jest prawdopodobne, że narzędzia AI są przydatne w wielu innych kontekstach, różniących się od naszego środowiska, na przykład dla mniej doświadczonych programistów lub programistów pracujących? Trudno.
Może nikt nie zajrzy...

2026-01-16 16:36:14 UTC

- reply

Bańka z badaniami trochę o czym innym, z zastrzeżeniami autorów nt. wniosków, ale co tam, jest "AI" i "mierzenie efektywności" w tytule, weźmy zdanie "LLMy powodują spadek efektywności" i argumentujmy "mamy na to badania". Może nikt nie zajrzy...

2026-01-16 16:30:55 UTC

- reply

Spoko, możesz wrócić do swojej bańki i dalszych twierdzeń "wynikających z badań", że z LLMami jest wolniej, kod czy tekst nie są tak samo dobre (bo dogfooding nie działa) i w ogóle LLMy to zło.

2026-01-16 16:26:28 UTC

- reply

Opierasz się na badaniu w którym autorzy wprost piszą, że czegoś nie twierdzą, do wyciągania dokładnie takiego twierdzenia uzasadnionego "bo mam takie badanie"?Wyborne.
"We do not provide evidence that:
AI systems do not currently speed up many or most software developers
[...]
AI systems in the near future will not speed up developers in our exact setting".
Ziew. Doczytaj tę część o "experienced open-source developers working on their own repositories" vs co ja robiłem.

2026-01-16 16:00:47 UTC

- reply

Znaczy przykładasz wyniki "badań" gdzie piszą o doświadczonych programistach działających na swoim kodzie, gdzie autorzy wprost piszą, żeby nie ekstrapolować na ogół, do mojego przypadku, gdzie działam w nieznanym obszarze i nie jestem doświadczonym programistą. Cool.
Pisałem o oszczędzaniu energii, nie o zastępowaniu ludzi (w ogóle nie było tego tematu). Narzędzia (tym są LLMy) nie zastąpią ludzi. Tak jak nie zastąpiły ich komputery (takie obawy też były).

2026-01-16 15:27:01 UTC

- reply

Ma do rzeczy, bo mam wrażenie, że wypowiadasz się o jakichś zaszłościach, które w dodatku znasz z opowieści z drugiej ręki.
Jaki związek ma trafność estymacji czasu przez ludzi (specyficznych ludzi, w specyficznych warunkach, autorzy podkreślają) do jakości/trafności generowanych treści[1]? (Żaden)
Narzędzi trzeba umieć używać.
[1] Disclaimer, bo czuję, że zaraz zrobisz "pisałeś, że LLMy się nie mylą": czasem, to się mylą i halucynują, jak obserwuję.

2026-01-16 12:56:57 UTC

- reply

"Czasem wygenerują" - kiedy ostatnio używałeś jakiegoś komercyjnego LLMa w stylu ChatGPT, Gemini, Perplexity? Bo brzmi trochę jak 2023.

2026-01-16 12:35:43 UTC

- reply

Ślepa agitacja jest w części pierwszej. To, że wynik LLMów nie nadaje się na materiał treningowy dla LLMów nie znaczy, że nie kod czy tekst nie jest równie dobry (lub lepszy) niż wytworzony przez człowieka.
Hint: nie tworzymy kodu/tekstu do tego, by trenować na nim LLMy.

2026-01-16 12:21:32 UTC

- reply

Moja alergia na ślepą agitację przeciw LLMom dorównuje alergii agitacji ślepego pchania LLMów wszędzie. 🤷‍♂️

2026-01-16 12:03:38 UTC

- reply

Regarding coding, there is a lot of documentations, examples of code etc. They often follow the same patterns (think: REST API). LLM will generate skeleton of the program faster, with execption handling etc. so programmer can focus on parts requiring creativity, not repeatable ones.
Regarding dogfooding - it's probably just a matter of stucking in local optimum/cost. No point in wasting CPU cycles in learning things that model already "knows".

2025-12-12 16:49:55 UTC

- reply

Może krótka forma, która tu obowiązuje (a dodatkowo macie niski limit wpisów na instancji, podobnie jak ja), nie sprzyja precyzji wypowiedzi, ale czytając te wpisy wygląda, jakby przedstawiały one niepełną i/lub nieprecyzyjną wersję.
We wpisach, które linkujecie, sami przyznajecie, że możliwość odwołania się od decyzji platformy będzie fikcją ("standardy społeczności").
Teraz jeszcze dowiedziałem się, że decyzja prezesa UKE/KRRiT będzie wstrzymana wniesieniem sprzeciwu tylko...

2025-12-11 17:56:34 UTC

- reply

...tak jak obecnie, wykonana od razu. I nawet jeśli użytkownik uda się po pomoc do prezesa UKE/KRRiT, to treści/konto pozostaną zablokowane. Nic się tu nie zmieni. Poza tym, czy ustawa określa obowiązki platform i jakiego rodzaju ma to być pomoc, w jakim trybie?
Z mojego punktu widzenia, jako użytkownika platform, w kwestii odwołania od decyzji platform nie zmienia się wiele (dochodzi niejasna pomoc). Za to pojawia się kolejne źródło blokad.

2025-12-11 17:51:51 UTC

- reply

Czytam to wszystko powyżej i mam wrażenie, że mamy do czynienia z pewną manipulacją.
Obecnie o nałożeniu blokady decyduje platforma. Użytkownik może się odwołać do platformy (nie, nie musi wyłączać telefonu).
Po zmianach, blokować będzie mogła i platforma, i prezes UKE/KRRiT. W drugim przypadku użytkownik ma mieć możliwość wniesienia skargi do sądu i do czasu rozpatrzenia treści(/konto?) nie zostają zablokowane. Natomiast w przypadku blokady przez platformę, nadal będzie ona...

2025-12-08 13:53:58 UTC

- reply

Przeczytałem art. na Panoptykonie. Podają dwa przykłady usuniętych profili. Oba zostały przywrócone po sprawach w sądzie. Jak to szło? Don't fix it if it ain't broken?

2025-12-08 12:20:48 UTC

- reply

Znaczy "nie możemy pozwolić, by sąd decydował o blokadach, bo będzie to procedował 5 godzin" za to "dajmy możliwość wniesienia sprzeciwu do decyzji i wtedy sąd (po pięciu latach) zadecyduje, czy jej nie wstrzymać"? Genialne.

2025-12-07 23:00:13 UTC

- reply

Przed chwilą narzekałeś, że sąd 5 lat, a teraz nie ma problemu, że każdy zgłosi sprzeciw i trzeba jednak czekać na decyzję sądu?

2025-12-07 22:20:49 UTC

- reply

Ale o tym, czy doszło do złamania powinien decydować sąd, prawda?

2025-10-16 06:56:47 UTC

- reply

Dalej było podobnie. Były wymienione wszystkie wady i zagrożenia AI, ekologia, wykorzystanie przeciw pracownikom (spotkanie organizowały organizacje związkowe).
Dokładnie to samo, tylko z odwrotnym zwrotem, jest na spotkaniach entuzjastów AI. Kod sam się pisze, wystarczy powiedzieć "chcę appkę, która robi to i to", AI zamówi nam jedzenie, streści dokumentację.
Było nagrywane, ale nie wiem czy będzie publicznie dostępne. Jeśli ktoś potrzebuje podsycać lęki związane z AI - można.

2025-10-16 06:40:40 UTC

Wczoraj byłem na webinarze "Czy AI odbierze Ci pracę? Sztuczna inteligencja, prawdziwa praca" prowadzonym przez @npub1afm…5gp4
Disclaimer: bardziej słuchałem w tle niż pełne skupienie, jak radio.
Wrażenia: prowadzenie bdb.
Treść... No cóż, było mocno z tezą i generalnie lobbing anty AI. Zaczęło się od nieobowiązkowej ankiety, gdzie można było albo bać się AI, albo "nie boję się, mam pracę fizyczną". Opcji, że pracownicy umysłowi się nie boją nie przewidziano...

2025-07-23 15:27:55 UTC

- reply

Nie jest OK z innych powodów. Tzn. przeczytałem ten artykuł i motywacja jest totalnie z dupy. Jeśli chcą mieć AI "w urzędach" to niech dostarczą łatwo przetwarzane dane. Kto chce, ten sobie skorzysta z rozwiązań, które będą dopracowane, a nie z kulawych "ale naszych". No i dopuszczenie LLM do danych prywatnych to IMHO przepis na katastrofę. Cóż, przynajmniej będzie wesoło...

2025-07-23 15:10:58 UTC

- reply

Nieustające pasmo sukcesów:
1. Polacy robio AI!
2. Innowacja w mObywatelu, każdy ma AI!
3. Wyłączamy nieużywane funkcjonalności. Tniemy koszty i oszczędzamy energię!

2025-07-23 14:19:32 UTC

- reply

A ten VOD co go obiecali to już działa?

2025-05-04 10:49:00 UTC

- reply

Po pierwsze, raczej się to nie wydarzy. Po drugie, co za różnica?

2025-04-27 14:34:05 UTC

- reply

Czyli nie masz problemu z nieanonimową weryfikacją wieku przy pomocy dowodu osobistego, z masą nadmiarowych danych, utrwalanego cyfrowo w nieregulowany sposób, plus podobne utrwalenie wizerunku, bo ćwierć wieku temu było "efemeryczne", ale to samo (lub nieco mniej) w kontekście weryfikacji w sieci już boli? Nie rozumiem.

2025-04-27 14:16:20 UTC

- reply

No to mamy rozwiązanie! Strona P robi zdjęcie usera i zdjęcie zdjęcia w jego dowodzie. Jeśli się zgadza - wpuszcza usera.

2025-04-27 14:13:53 UTC

- reply

PESEL, podobnie jak dowód, jest nadawany raz, do wielokrotnego wykorzystania. Nie jest wydawany uznaniowo w danej chwili.

2025-04-27 14:09:28 UTC

- reply

Ale masz świadomość, że w sklepach są kamery? Często z dobrą rozdzielczością, wystarczającą do odczytu danych z dokumentu. Sprzedawców z fotograficzną pamięcią, dedykowane kamery 'nielegalne' pomijam. A jak wchodzisz do sklepu, to nagrywają twarz. Wszystko cyfrowo.

2025-04-27 14:01:55 UTC

- reply

KYC ma tę zaletę, że jest tylko pomiędzy stronami umowy. Operator strony i tak może już całkiem dobrze identyfikować usera (IP, fingerprinty na początek), dołóż reklamy i masz z dokładnością do profilu w socjalach, często.
Odpowiesz, że Tor, że user może się bronić. Bo może, jeśli ma wiedzę. Tylko przypomnę wtedy jak twierdzisz, że userzy nie będą umieli obejść "zlych" rozwiązań.

2025-04-27 13:53:45 UTC

- reply

Może i ostro, ale chyba słusznie. Bo wiesz, teraz zaczniemy od stron internetowych, a zaraz skończymy na tym, że bez potwierdzenia czegoś tam przez rząd tym samym sposobem nie będziesz uznawany za pelnoprawnego obywatela w lepszym przypadku, a człowieka w gorszym.
Dostęp do świadczeń medycznych uzależniony od potwierdzenia przez R. Zatrzymanie na demonstracji do czasu potwierdzenia tożsamości. A telefon wziął się i rozbił, co za pech.

2025-04-27 13:45:59 UTC

- reply

Czy to będzie wygląd, czy inna cecha umozliwiajaca +-jednoznaczne powiązanie to już chyba kwestia wtórna? Skoro sprzedający zna tę charakterystyczną cechę, to może później +-jednoznacznie zidentyfikować tę osobę w przyszłości (a czasem i w przeszłości).
Czy chcesz zaproponować fikołka pt. "P nie zna tożsamości U, ma tylko jego zdjęcie i zdjęcie jego zdjęcia z dowodu"?

2025-04-27 13:37:20 UTC

- reply

Ale to bez znaczenia, bo okazywanie dowodu jako sposób weryfikacji wieku działa tylko gdy P zna tożsamość U. Czy też pewne części tożsamości, typu wygląd, wracając do sprzedaży alkoholu.

2025-04-27 13:34:50 UTC

- reply

To może warto odrzucać rozwiązanie w całości, zamiast legitymizować je i próbować pudrować i pomagać tworzyć rozwiązania?

2025-04-27 13:08:51 UTC

- reply

To zamieniam się w słuch. Bo 2 to jest dokładnie osoba w kominiarce kupującą alkohol.
Wg mnie zasadniczy problem to fakt, że znowu zamiast edukacji próbuje się stosować kontrolę, zakazy i zmierzamy prostą drogą w kierunku totalitaryzmu.
1 jest rozwiazane już teraz. R wydaje dokument, który U może pokazywać komukolwiek, bez wiedzy R.

2025-04-27 11:54:14 UTC

- reply

Myśl uboczna: w sumie jeśli chcą sobie wymyślić, że wejście na stronę wymaga podpisu, identyfikacji i notariusza, to czemu im w tym przeszkadzać? Ustrój będzie jawniej totalitarny (jakieś tam parę kolejnych punktów dla kraju w rankingach mniej), a więcej ludzi nauczy się jak obchodzić bzdurne wymogi.

2025-04-27 10:52:08 UTC

- reply

Nie możesz nie wiedzieć, kim jest U, jeśli chcesz weryfikować, czy posiada jakąś wiedzę/właściwość. To nie przejdzie nawet w ZKP i wersji z labiryntem. Bo odpowiednim wyjściem ma wychodzić U a nie dowolna osoba.

2025-04-27 10:49:59 UTC

- reply

Pytanie pomocnicze: skoro nie wiesz, kogo weryfikujesz, to jak chcesz weryfikować? Rozpisz to sobie na wersji bez krypto/IT najpierw... Jeśli coś sensownego wymyślisz, to można to przekładać na IT/krypto.

2025-04-27 10:47:09 UTC

- reply

No nie chce mi się rozkminiać całego algorytmu uwierzytelniania. Pewnie wystarczy, żeby URL był.
Tj. "potwierdź żądanie wejścia na URL P" jako treść do usera.
User odpowiada, "ja U potwierdzam wejście na P" podpisane swoim kluczem prv oraz szyfruje kluczem P pub.
Z dostaje zaszyfrowane kluczem P, więc nie jest wstanie przedstawić wersji do zweryfikowania kluczem U.

2025-04-27 10:42:15 UTC

- reply

> a, co do klucza prywatnego juzera – no właśnie nie chcemy przecież, żeby Z (ani P) znały U.
Nie, nie. To dodatkowy warunek, który teraz wprowadzasz. Odkąd się https://mastodon.online/@npub1afm…5gp4/114403897919764108 zaczęło, nie było o tym mowy.
Z takim ograniczeniem wracamy do oryginalnego zagadnienia i mojego "nie da się". Bo wiesz, bez podpisu U, to Z w ogóle nie musi U angażować tylko mówi "jestem U, weryfikuję się na P". Facet w kominiarce.

2025-04-27 10:36:05 UTC

- reply

> Moment. Z wysyła żądanie weryfikacji na Z. Użytkownik myśli, że loguje się na Z. Apka użytkownika szyfruje kluczem Z.
Nie. Opisałem wcześniej, że user/appka bierze klucz nie z miejsca do którego się łączy, tylko z żądania, które podpisuje, jak w GPG.

2025-04-27 10:13:46 UTC

- reply

No to jeszcze raz. Z wysyła userowi U żądanie weryfikacji od strony P. User bierze to żądanie, pobiera klucz publiczny P. Następnie podpisuje żądanie swoim kluczem prywatnym i szyfruje kluczem publicznym P. Odsyła (do Z). Z ma dane, ale nie umie ich odszyfrować. Żeby potwierdzić, że user U był na P trzeba zweryfikować potwierdzenie przy pomocy jego klucza publicznego. Zrobić to można tylko z kluczem prywatnym P (bez tego nie odszyfrujesz).

2025-04-27 07:03:03 UTC

- reply

Pobieram z tej strony (.well-known choćby). Albo serwera kluczy (jak w GPG).
Kluczowe jest żeby to weyfikujący sam łączył się i pobierał klucz, a nie wierzył w to, co mu podsunie inicjujący.
Czyli przychodzi komunikat z AAA (udającej XYZ) "strona XYZ chce weryfikacji". Z komunikatu pobierane jest XYZ, następuje połączenie do XYZ/.well-known/pubkey, szyfrowana jest wiadomość "byłem na XYZ" przy pomocy tego klucza, odesłanie do AAA. Bez klucza prv nie odczyta.

2025-04-26 11:18:32 UTC

- reply

No ale gdzie tu problem? Dostaję zapytanie "strona X chce uzyskać Twoje dane". Biorę klucz publiczny strony X, udzielam odpowiedzi szyfrując ją tym kluczem. Nawet, jeśli strona Z przechwyci udzieloną odpowiedź, to nie jest w stanie jej odszyfrować bez znajomości klucza prywatnego strony X.

2025-04-26 10:50:12 UTC

- reply

No gdzieś tam pisałem pod screenem, że to chyba inny przypadek - tam weryfikujący "zna" weryfikowanego.

2025-04-26 10:47:14 UTC

- reply

Jestem od lat włączony. https://zakr.es/blog/2010/01/ipredatror-czyli-jak-olac-ustawe-hazardowa-za-5-euro-miesiecznie/

2025-04-26 10:40:50 UTC

- reply

No KYC jest sensowny. Oczywiście ma wady, ale w kontekście "weyfikujemy czy osoba X to osoba X" jest sensowny.

2025-04-26 10:35:10 UTC

- reply

No to może warto podnieść ten temat, na zasadzie "weryfikacja wieku już istnieje (button na stronie), wszytko inne to ściema i nieskuteczne bzdury"?

2025-04-26 10:32:37 UTC

- reply

Czemu nie są OK? Bo okazanie dowodu tożsamości weryfikującemu jest standardową praktyką, od zawsze. Może problem jest gdzie indziej, zwł. w sposobie, w jaki są przesyłane/przechowywane i wykorzystywane te dane?
Bo *gdyby* dane były przesyłane do społecznościówki w sposób bezpieczny, nie były zapisywane, a jedynie wykorzystane do weryfikacji "osoba ze zdjęcia jest osobą z dokumentu, ma ukończone przynajmniej 13 lat" i zapisania tej informacji w bazie?

2025-04-26 10:26:50 UTC

- reply

O naganianiu klientów firmom od VPN i kryptowalut pisałem już wcześniej. Zaraz jeszcze Tor dostanie rykoszetem. :D

2025-04-26 09:46:25 UTC

- reply

Ale państwo ma swoją propozycję? Działającą, tj. faktycznie weryfikującą? Bo jeśli tak, to proponowanie niedziałającej jest... słabe. Nie widzę szans powodzenia.
Jeśli obie mają ten sam problem, ale jedna sprzyja prywatności, to jest godną uwagi alternatywą.

2025-04-26 09:35:20 UTC

- reply

A w drugą stronę - wszelkie finansówki mają KYC. Dane nie lecą do państwa. Warunek na to, by dane nie były w 2 miejscach jest spełniony.

2025-04-26 09:30:35 UTC

- reply

No ale fasadową weryfikację już mamy. Button na stronie "mam 18 lat". Równie skuteczne, prądu mniej, po co komplikować? KISS

2025-04-26 09:23:47 UTC

- reply

Nie no, to czy akurat Ty byś tego użył, czy nie to już Twój problem. Obowiązku korzystania nie ma. Podobnie jeśli ktoś ma problem z pójściem do monopolowego i kupnem flaszki, bo się wstydzi (czy tego, że pije, czy tego, że ma nazwisko Psikuta), to nie jest problem zagadnienia weryfikacji wieku.
Oraz: masa userów pewnie podaje normalnie dane identyfikujące na tego typu serwisach, czy to kart płatniczych, czy maile, czy loguje się z Google/FB.

2025-04-26 08:00:38 UTC

- reply

To chyba nie jest przedmiotem zagadnienia. ;-)

2025-04-26 07:57:17 UTC

- reply

Pozwoliłem sobie zebrać wnioski z dyskusji we wpisie na blogasku https://zakr.es/blog/2025/04/potwierdz-moj-wiek-anonimowo/

2025-04-26 07:02:04 UTC

- reply

Poprawka jest prosta i jest powrotem do normalnej weryfikacji wieku z czasów "fizycznych" - weryfikujący zna (może poznać) tożsamość weryfikowanego. Tak było zawsze (zakup alko).
W przypadku usług wirtualnych jest już podobnie - wszelkie finansówki mają KYC.

2025-04-26 06:55:39 UTC

- reply

Nie da się. W tym przypadku user robi pełny MITM, ponadto nie ujawniając tożsamości.
To jest przypadek, gdzie osoba w kominiarce pokazuje na telefonie zdjęcie dowodu osobistego. I weryfikuj wiek na tej podstawie. ;-)

2025-04-26 06:44:18 UTC

- reply

Dokładnie. I nie rozwiązuje zasadniczego problemu, tj. nadal strona nie wie, czyj tak naprawdę wiek został potwierdzony.
Oraz: wcale nie trzeba shared accounts. Można wystawić N serwisów, (0001-X, 0002-X, 0003-X) na każdym tylko raz dany dowód autoryzować.

2025-04-26 06:38:01 UTC

- reply

OK, ale to nie głosowanie w wyborach, że ma być tylko raz. Jak rozumiem weryfikacja miałaby się odbywać przy każdej wizycie (urządzeniu, etc), więc ten sam dowód musi dać się używać wielokrotnie.

2025-04-26 06:13:30 UTC

- reply

Podaję legityny przypadek, gdzie user ma 5 urządzeń i dla każdego się weryfikuje. Pamiętaj, że strona ma nie wiedzieć, kim jest user, więc każde nowe urządzenie (a w zasadzie - sesja, ale uprośćmy dla non-IT) to dla serwisu X "nowy użytkownik". Więc to, że jeden dowód posłuży wielokrotnie jest normalne.

2025-04-26 05:53:16 UTC

- reply

Rząd akurat może wprowadzić wymóg, że ma być weryfikacja wieku/tożsamości na zasadzie "okazania dowodu". Nieanonimowa. Dokładnie to, co jest obecnie w mObywatelu. Mechanizm już jest.
Strony, które tego nie implementują - blokowane. Podobnie jak masz z bukmacherami/kasynami obecnie. Tam zdaje się o podatki poszło, ale mechanizm już jest.
Anonimowości chcesz Ty, nie rząd.

2025-04-25 20:42:15 UTC

- reply

Co ma do tego unikatowość? User ma 5 urządzeń, korzysta z nich naprzemiennie. Dla systemu to powinno być 5 niezależnych userów, potwierdzanych jednak tym samym KVAC.
Chyba, że chcesz mieć wymóg logowania i weryfikować tylko przy zakładaniu konta. Ale to jeszcze gorzej - będzie można sprzedać zweryfikowane konto.

2025-04-25 20:19:15 UTC

- reply

No ale moment. Skąd będzie wiadomo, że to osoba, która loguje się do portalu wygenerowała MAC a nie portal 18aaS?

2025-04-25 17:52:58 UTC

- reply

Pomyślałem jeszcze trochę i wydaje mi się, że to jest zagadnienie bardzo podobne do wyborów przez internet. Tajnych oczywiście.
X - serwis, gdzie oddaje się głos, żąda potwierdzenia, czy user może głosować. odnotowuje wartość głosu i weryfikuje, czy potwierdzenie jest dobre
user, appka - bez zmian
eid - serwis, który potwierdza, że dany user może głosować (musiałby odnotowywać, że już raz potwierdził w danych wyborach danego usera, ale to detal)

2025-04-25 15:37:39 UTC

- reply

Wg mnie bez wzajemnego uwierzytelniania X i zaufanej appki (czyli utraty prywatności) będzie ciężko.

2025-04-25 15:35:43 UTC

- reply

Trochę tak, jak piszesz. Ale system powinien być bezpieczny kryptograficznie, bo tu się łatwo skaluje i automatyzuje. Więc jak najbardziej jest to kwestia technologii.
Limity zapytań nic nie dadzą. 18aaS może brać 5 gr od zalecającego potwierdzenie i płacić 4 gr potwierdzajacemu.

2025-04-25 15:13:43 UTC

- reply

18aaS będzie miał na backendzie powiedzmy appkę twórcy. Appkę jakby grzeje czy dostała zapytanie z serwisu X czy 18aaS. Zresztą, nie jest w stanie wiarygodnie określić źródła, bo 18aaS ma komplet danych.

2025-04-25 14:57:44 UTC

- reply

Wydaje mi się, że przedstawiony algorytm zawiera błąd. Wystarczy, że zapytanie zamiast do swojej zaufanej appki przekażę do serwisu (18aaS), który użyje danych innego usera (ale będzie odpowiadał tylko na pytanie o wiek), on zdobędzie potwierdzenie wieku i podpis z eid i... już. Zwrócę do serwisu prawidłowo podpisaną odpowiedź, że mam 18 lat.

2025-04-24 21:32:22 UTC

- reply

Rozpatrywać? Nie sądzę. Jest umowa międzynarodowa, która umożliwia żądanie usuwania treści pod pewnymi warunkami. Wystarczy sprawdzić, czy dane państwo ją ratyfikowało i powołać się na nią.
Oczywiście admini instancji mogą sobie sprawdzać i rozpatrywać, nikt im nie broni.

2025-04-24 21:20:35 UTC

- reply

No jeśli jest umowa międzynarodowa, to ma do wyboru albo zastosowanie się do żądania usunięcia, albo ryzykuje konfrontację z aparatem prawnym swojego państwa. Który zapewne będzie oceniał wyłącznie kwestie formalne, nie zasadność (bo umowa międzynarodowa). Polecam lekturę http://bs-blog.clouds-forge.eu/index.php?post=2024_11_04_00_Jak_nie_zostalem_Zuckerbergiem to jest dość pesymistyczne i czarnowidztwo i wg mnie nie trzeba prewencyjnie, ale ogólnie całkiem nieźle.

2025-04-24 20:59:33 UTC

- reply

Żądanie dotyczy usera czy treści? Polecam https://sip.lex.pl/akty-prawne/dzienniki-UE/rozporzadzenie-2021-784-w-sprawie-przeciwdzialania-rozpowszechnianiu-w-69442972/art-3 (nie, nie wiem czy ta podstawa była użyta). I tu podajesz powiedzmy dla mastodon.online https://mastodon.online/@npub153t…7ycd/ w ramach 4c i sayonara.
Oczywiście admini mogą powiedzieć cokolwiek, że nie zrozumieli maila itd. I na pewno już się ustawiają w kolejakch do konfrontacji z lokalnymi wymiarami sprawiedliwości. ;>

2025-04-24 20:27:59 UTC

- reply

Tylko w praktyce to będzie wyglądać mniej więcej tak, że organ w Turcji, który wysłał żądanie do BS, weźmie listę instancji masto w cywilizowanych krajach i wyśle żądanie usunięcia treści usera XYZ + jego blokady do wszystkich tych instancji.

2025-04-24 19:43:13 UTC

- reply

Rządu czy sądów? W artykule jest mowa o sądach (court orders oraz legal pressure).
I już widzę jak większe instancje masto ignorują wyroki sądów. Jasssne.
Tylko ktoś musiałby się pofatygować, a póki co nie bardzo jest się po co schylać.

2025-03-27 07:44:43 UTC

- reply

Wiele firm ma pocztę na gmail pod swoją domeną. Płatna usługa dla firm.
Argument, że korzystasz z innego rozwiązania średnio utwierdza mnie w przekonaniu, że email to dobre, działające rozwiązanie. ;) I o ile "nie mam problemu z X, bo go nie używam" ma sens z logicznego punktu widzenia, to "X działa dobrze, bo go nie używam" już niezbyt.
Threads jest akurat dobrym przykładem na separację w "świecie fedi".

2025-03-26 21:28:44 UTC

- reply

To skomplikowane. Znaczy sytuacja, nie używanie innej poczty. Ogólnie dostarczanie poczty do "większych" tak, żeby nie trafiła do spamu, zwł. jak masz więcej do dostarczenia to nie jest taka trywialna sprawa.
Przy czym serwery pocztowe jednak ze sobą generalnie "gadają", po spełnieniu warunków technicznych. Serwery w fedi - nie, tzn. już teraz tną się.

2025-03-08 09:34:19 UTC

- reply

Jakie to jest pięknie PRowo sformułowanie! Po pierwsze, wzrost o 8% łatwo pomylić z procentami PKB. Po drugie, jak pójdę kupić bułki, to również przyczyniam się do wzrostu PKB. Po trzecie, w oryginale było, że tyle zakładają. No to ja zakładam, że moje kupno bułek przyczyni się do wzrostu PKB o 2%. Talk is cheap.

2024-12-12 17:59:00 UTC

- reply

Well, they can buy new computers. Don't like this option, but may be better - at least in short term - than investing time in learning Linux.

2024-12-12 09:23:32 UTC

- reply

This. Plus a lot of software just doesn't exist/run on Linux.
As a many years Linux user I still don't like this recommendation to Windows users. Easy Ubuntu is false promise for most of them, unfortunately. It will require a lot of learning and changing habits, even if it's even possible.

2024-11-17 17:37:52 UTC

- reply

Z tego opisu wygląda na proste https://github.com/bluesky-social/pds i jakby powszechnie dostępne.

2024-11-17 15:24:33 UTC

- reply

Przecież w decentralizacji BS nie chodzi o spięcie ze światem fedi, tylko o możliwość uruchomienia własnego serwera BS.

2024-09-14 08:23:09 UTC

- reply

Ad. 1 Pewnie tak, ale nie każdą informację mogą tak wykorzystać legalnie. Np. ładowanie fontów Google nie powinno być tak wykorzystane. Warto sprecyzować zagrożenie (i znowu: wytyczne).
Ad. 2 To jest jeszcze inny aspekt i bym go w dyskusję o prywatności nie mieszał.

2024-09-14 07:37:21 UTC

- reply

Jakieś przykłady dostawców reklam kontekstowych, którzy nie wymagają płacenia Google'owi? Chętnie przetestuję, jeśli jest coś godnego uwagi/polecenia.

2024-09-14 07:00:56 UTC

- reply

Artykuł ciekawy, czy jest petycja do podpisania w wersji online?
Wady, które widzę:
1. strona o uzależnieniach jest typowo informacyjna, w oddzielnej domenie i nie przetwarza danych, więc wyciek danych wrażliwych nie wygląda na możliwy.
2. Ślad węglowy a CDNy - zupełnie pomijalne dla sprawy, mała skala. No i w końcu trudne do określenia. Wg mnie ten fragment obniża wagę poruszonych tematów.

2024-08-22 18:08:44 UTC

- reply

Wrong info on the support page is clearly Google fault.
Another thing is that support page wasn't even mentioned in this thread before I did so.

2024-08-22 17:28:11 UTC

- reply

I guess a year of support for EOL product is not bad, huh?
But that's true that Google does not provide support timeline for OSes other than Windows. Also: looking on the reqs website, it never did, so users choosing Chrome knew it in advance and I have no clue why they suddenly expect to be notified.

2024-08-22 16:27:26 UTC

- reply

As I stated previously, this page has obvious mistake. They should correct it ASAP.
At the same time I find faith that Chrome will be supported on EOL systems, which is based only on that one page... bold at least.

2024-08-22 16:18:17 UTC

- reply

That's of course interesting option. But I rather thought about detecting installed packages during the upgrade and notifying user about those not covered by ESM.

2024-08-22 15:53:27 UTC

- reply

It's not their job to warn anyone that system produced by another company is getting EOL.
Srsly, it's Canonical who sells support (or illusion of it). I believe they should be asked for help/blamed as they take money for ESM. They should even warn users that system with their support has 3rd party software installed.

2024-08-22 15:28:07 UTC

- reply

For me it's perfectly acceptable. You would like to force them to run EOL system to build and test their software, which they provide for free.
No one, even big corp, should be forced/expected to do so.

2024-08-22 15:02:38 UTC

- reply

Honestly, I'd not expect that software is supported on EOL systems unless such support is clearly announced.
This reqs page is IMHO classic case of forgotten and not updated docs. The simplest fix is to change 18 to 20 there. It should be made a year ago. And BTW Debian should be changed from 10+ to 11+.

2024-08-22 07:44:31 UTC

- reply

I think you should not blame Google. Ubuntu 18.04 LTS is end of life system. You can have ESM from Canonical, but it's not Google's business.
Blame Canonical if they provided broken package, or yourself if you use 3rd party repos on EOL system and expect it to work.

2024-08-22 07:31:50 UTC

- reply

They had very little time to prepare this patch, so cutting corners on testing is justified!