@kowalkowskij: mozesz coś wincyj na ten temat?

@wrocilem_bo: Nic nie kopali, tylko ppdmieniali linki do rejestracji na Biance na swój reflink. Już to usunęli.

@MrStealYourGirI: A to nie było tematu. ( ͡° ͜ʖ ͡°)

@MrStealYourGirI: pytanie co jeszcze się chowa xD

@MrStealYourGirI: a dalej pcha tam jakieś swoje chujumuju i jakieś punkty/żetony?

@tellet: tak, przez rok zarobiłem na tym 20 zł xD

@PuszkaMielonki: no taką kasę to na PPK odłóż!

a dalej pcha tam jakieś swoje chujumuju i jakieś punkty/żetony?

@tellet: chyba dalej ma to dziadostwo, a teraz dojdzie jeszcze robienie za jelenia i hostowanie cudzych plików.
Na pewno ucieszą się wszyscy, którzy mają limitowane pakiety danych, np w sieciach komórkowych ( ͡º ͜ʖ͡º)

@MrStealYourGirI: cały czas mają w kodzie (sic!) przeglądarki zaszyte linki do binance:
https://github.com/brave/brave-core/blob/master/components/omnibox/browser/suggested_sites_provider_data.cc

@kowalkowskij: Haha myślałem ze wszyscy zapomnieli. Tak, brave miał wbudowanego minera w przeglądarce i robil w c@$#@ tysiące użytkowników. Wycofali się z tego ale niesmak pozostał, bo niby reklamują się jako przeglądarka dbająca o prywatność.

@kosciej: https://brave.com/binance/ po prostu trzeba poczytać, sprawdzić do czego się łączy i ew. poblokować, ale faktycznie takie akcje powinny być jawne.

@PuszkaMielonki: tylko nie rozwal na głupoty

@tellet: Punkty żetony w postaci krypto są za wyświetlanie reklam (możesz później wymienić to na hajs)

@Januszowy: A to nie mówiłem, że sprawy nie ma, robili to "cichaczem" i o ile uważam że przeglądarka sama w sobie jest spoko o tyle taka podmiana linków na własne refy to niebezpieczny precedens

@kosciej: Tego nie wiedziałem, dzięki za info!

@apo: Ale po co mam to czytać jako zwykły użytkownik? (żeby było jasne - przeczytałem) Spodziewam się, że przeglądarka która reklamuje się jako skupiona na bezpieczeństwie nie będzie robić takich numerów.

@kosciej: Na stronie głównej brave masz biance. ¯\_(ツ)_/¯

źródło: obraz_2021-01-21_101930.png

@apo: a nie, jak tak to spoko ( ͡° ͜ʖ ͡°)

@WielkiElektronig: czemu?

@NPC_358034: bo nie zastąpi.
( ͡° ͜ʖ ͡°)

@WielkiElektronig: @NPC_358034: @LiSzajFuj: Bo nie i huj.
( ͡° ͜ʖ ͡°)

@WielkiElektronig: @NPC_358034: @LiSzajFuj

@MobrayOswaldo: @WielkiElektronig: @NPC_358034: @LiSzajFuj
Czas zakończyć ten spór koronnym argumentem

pokaż spoiler nie zesrajcie się ( ͡° ͜ʖ ͡°)


@NPC_358034: Bo po prostu IPFS i HTTP to sa inne protokoły i dla obu znajdzie się miejsce. Ponadto samo IPFS ma API po HTTP -__-

@NPC_358034:
1. Już 2-3 lata temu chciałem zacząć korzystać z IPFS, ale jak tylko się okazało że nie ma żadnych mechanizmów "fair-use" to podziękowałem - mam taryfę 20GB i youtube oglądam w 144p ( ͡° ͜ʖ ͡°) a mi tu ktoś bezkarnie jeszcze będzie ssał ile wlezie - nope ;-)
2. Implementacja w GO to był błąd, wszystkie porty kuleją, a GO nie ma targetów dla systemów wbudowanych
3. Praca z IPFS wymaga nieco gimnastyki umysłowej, a na to wielu nie stać

(to moja subiektywna lista "nie zastąpi")

@NPC_358034: bo wykopek tak powiedział

Cokolwiek pan @LiSzajFuj powie, to ja to uznaję za prawdę objawioną. I nawet z tym nie dealujcie.

@NPC_358034: Bo (prawie) nikomu nie będzie się chciało hostować cudzych plików. Było już wiele podobnych pomysłów i nie było zbyt wielu chętnych do ich używania.

@megawonsz9: zaraz, to IPFS to taki internet w torrentach?

zaraz, to IPFS to taki internet w torrentach?
@auCwSlorpoaSh5TGXogPfUDhO8s9EJ99ecW: tak :-)

@headge: spór to jest w twojej głowie, ja się chciałem dowiedzieć jakie są wady, na szczęście znalazło się paru mirków z rigczem co wyjaśnili zamiast kręcić inbe

@dramatdramatyczny: zero stron

@MobrayOswaldo: @dramatdramatyczny: No trochę mają integracji, którymi się chwalą, ale na ile to prawda to nie wiem
https://ipfs.io/images/ipfs-applications-diagram.png

@dramatdramatyczny: Żeby jakieś strony zaczęły obsługiwać ten protokół, najpierw potrzeba przeglądarki która będzie go obsługiwać ¯\(ツ)/¯

@dramatdramatyczny:

https://www.reddit.com/r/ipfs/comments/63ev6h/list_of_ipfs_websites/

Wszystkie linki odwołują się do localhosta. Czyli lokalnie musi być odpalony jakiś serwer.

@tombeczka: Ten serwer (lokalny) chyba służy do celów demonstracyjnych, gdy przeglądarka nie obsługuje takiego protokołu. Czyli przeglądarka używa "starego" HTTP (ale z nowymi linkami), a serwer łączy się z internetem używając nowego protokołu i zwraca dane do przeglądarki.

PS. Sam używam czegoś takiego (przeglądarka + serwer na localhost), gdy potrzebuję warstwy pośredniej między przeglądarką a siecią.

@FredOnizuka: Logika protokołu zakłada decentralizację i istnienie nodów sieci. Każdy użytkownik protokołu musi więc również hostować dane. Jest to nieco zbliżone do działania Torrentów.

@tombeczka: Ja zakładałem, że jak przeglądarka obsługuje IPFS, to ma już wszystko wbudowane. A to by sugerowało, że do działania potrzebny jest też lokalny serwer.
PS. Te linki wyglądają na takie, które może obsługiwać dowolna przeglądarka (oczywiście musi być też serwer na localhoście).

@FredOnizuka: IPFS to zupełnie inny protokół niż HTTP, udostępnia natomiast bramkę HTTP która pozwala z niego korzystać z poziomu chyba każdej przeglądarki. Najbezpieczniej użyć lokalnego węzła który jednocześnie sprawdza sumy kontrolne, ale nic nie stoi na przeszkodzie aby użyć bramki udostępnionej przez kogoś innego np. Cloud Flare: https://developers.cloudflare.com/distributed-web/ipfs-gateway . Można użyć również HTTPS/TLS jak zrobił to Cloud Flare. Dla zwykłego użytkownika działa jak każda inna strona, natomiast dla tych którzy mają wspierającą IPFS przeglądarkę lub rozszerzenia, bramka udostępnia nagłówki HTTP zwierające CID które umożliwiają przeglądarce przełączenie się na lokalny węzeł.

Skorzystałem z IPFS już w kilku projektach (bardzo specyficzne rozwiązania, nie są dostępne publicznie, to nie są zwykłe stronki). Zasoby w IPFS adresowane są po CID, które bazują na hash'ach contentu. Tak więc wchodząc dzisiaj na stronę poprzez dany CID, mam pewność że robiąc to jutro po tym samym CID nic nie mogło zostać zmodyfikowane (zakładam, że strona została została sprawdzona i nie ładuje niczego z zewnątrz, np. kodu JS). O ile HTTPS szyfruje połączenie i uwierzytelnia dostawcę (wiem, że po drugiej stronie jest np. infrastruktura Banku) to w żaden sposób nie zabezpieczają przed zmodyfikowaniem treści czy kodu w strony pomiędzy wejściami kiedy moim wymaganiem jest, aby nic nie zostało zmienione. Jeżeli kogoś drażni CID który ciężko raczej zapamiętać, istnieje IPNS który pozwala tworzyć przyjazne nazwy wskazujące na konkretny CID a sam wpis zabezpieczony jest kluczem prywatnym. Trochę taki DNS wbudowany w protokół.

Padło też stwierdzenie, że ludzie nie będą hostować cudzego contentu, zapewne tylko swój. W wielu przypadkach jest to tożsame. IPFS dzieli dane na bloki. Więc jeżeli moja strona korzysta z jakiejś biblioteki JS czy CSS z której korzystają inne strony, to tym samym wspieramy transferem te strony i vice versa. Tutaj odsyłam do dokumentacji IPFS i tego czym są bloki, Merkle tree oraz cały mechanizm adresowania contentu.

Kolejna sprawa, że IPFS jest można powiedzieć częścią większego planu a mianowicie projektu FileCoin który ma wynagradzać użytkowników za hostowanie cudzych treści. Wyzwanie jest dosyć spore, ponieważ trzeba było zbudować algorytm który automatycznie sprawdzałby i karał użytkowników którzy twierdzą, że hostują dany content a tego tak naprawdę nie robią. Projekt warty uwagi, bo sami chyba wszyscy widzimy co wyrabia chociażby Amazon na swojej chmurze, więc decentralizacja jest krokiem w dobrą stronę i dla części projektów może być jedynym rozwiązaniem. Ale to już zupełnie inna dyskusja.

@wrocilem_bo: Widzę że propaganda działa wspaniale.

@alex512: 60gr od wpisu, nie powiesz, że byś się nie skusił...

@wrocilem_bo: to polowa stron nie bedzie wchodzić

@loyboy: będzie, jak FF wykrywa, że strona nie oferuje HTTPS to ostrzega i pyta czy na pewno chcesz wejść? Na szczęście nie natykam się na czyste http często

@loyboy: Większość stron używa HTTPS z prostego powodu - lepiej się indeksują w Google. Dodatkowo sama obsługa HTTPS jest darmowa, a nie ma chyba po co robić stron na czystym HTTP

@wrocilem_bo: https to tez jest http tylko szyfrowane wiec nie blysnales ( ͡° ͜ʖ ͡°)

@wrocilem_bo: Pyta o to, ale na stronach z mieszaną zawartością już trzeba ten tryb wyłączać, bo inaczej się obrazki nie załadują.

nie ma chyba po co robić stron na czystym HTTP

@fervi: stron się nie robi "pod" protokół, na obu protokołach działa tak samo.

@wrocilem_bo: no ale czy wszystkie strony potrzebują https?

@kuriozalny_prestydygitator: Tu nie chodzi o to czy potrzebują czy nie, bo zapewne nie jest to potrzebne. Natomiast ostatecznie HTTPS jest lepszy i nie ma sensu używać HTTP

@CryptoPump: Możesz zrobić, że na HTTP nie działa w ogóle - tylko po co :P Chociaż chyba CORS czy coś tam nie działa z HTTP

@fervi: powiedz prosze w czym jest lepszy, po za tym ze ma szyfrowanie. nie znam sie na tym

@kuriozalny_prestydygitator: wszystkie. Bez https ktoś może po drodze wstrzyknąć złośliwą zawartość, na przykład malware wykorzystujący dziurę w przeglądarce (zdarzają się tacy, którym się nie aktualizuje) albo skrypt kopiący kryptowaluty, ostatecznie zasrać stronę reklamami. Łącząc się przez niezaufaną sieć dostawca ma wgląd w treść i może ją modyfikować. Przy https nie jest to możliwe.

@TheRealMikz: ok to ma sens, to dlaczego nie wszystkie strony go uzywają? to jest drogie ?

@fervi: jest po co - jak najbardziej. HTTPS nie jest za darmo (moc obliczeniowa) - więc z punktu widzenia dostawcy - jeśli ktoś nie oferuje niczego dynamicznego - a np. hostuje "stronę domową jakiegoś produktu" czy też "blog" (ale wygenerowany za pomocą statycznego generatora).
wg mnie nie ma powodów by po HTTPS pchać statyczny HTML.

@kuriozalny_prestydygitator: jest jeden dostawca darmowych certyfikatów - Let's Encrypt, jednak jest z tym kilka problemów, przeczytaj niżej moją odpowiedź do fervi, inni biorą kasę, często niedużą, ale zawsze

obsługa HTTPS jest darmowa

@fervi Let's encrypt jest jedynym dostawcą darmowych certyfikatów (o którym wiem). Niestety wygenerowanie certyfikatu od nich wykracza poza umiejętności początkującego admina (takiego starej daty często też), poza tym jeśli korzystasz z darmowego gównohostingu to tam często nawet się nie da.
Płatni dostawcy dostarczają Ci po prostu plik z certyfikatem. LE ma swój ACME system, z którym musisz synchronizować swoje oprogramowanie. Ja to umiem, być może Ty też, ale pan Wiesław który studiował w latach 80 telekomunikację na WAT i obsługuje sieć Januszex SC na Windows Server 2007 niestety nie ogarnie.

@komio: szyfrowane czyli bezpieczne ¯\_(ツ)_/¯ http nie jest bezpiecznym protokołem...

@kuriozalny_prestydygitator: te które wamagaja logowania użytkownika oczywiście, a spotykam jeszcze takie fora gdzie jest tylko http... Strach się bać ;)

@wrocilem_bo: tak jasne, zastanawialem sie nad sensem https przy np stronie pizzeri

@kuriozalny_prestydygitator: no właśnie w tym jest lepszy, że ma szyfrowanie :)HTTPS używa SSL, połączenie jest bezpieczne - każda strona banku używa HTTPS, natomiast HTTP nie używa certyfikatów SSL, brakuje mu tej warstwy, co jest furtką dla nieautoryzowanych użytkowników...

stron się nie robi "pod" protokół, na obu protokołach działa tak samo.

@CryptoPump: Nie każda strona HTTP się poprawnie załaduje przy HTTPS.

@kuriozalny_prestydygitator: teraz już nikt nie publikuje stron w HTTP, najczęściej tego protokołu używają strony prywatne lub takie, które są nieaktualizowane od lat ale nadal dostępne w sieci... Migracja do HTTPs wymaga zmian w kodzie strony, nie każdy zdaje sobie sprawę z tego, że jego strona jest potencjalnie zagrożona, nie każdy potrafi lub ma kasę, żeby zapłacić komuś za pomoc w migracji...

@TheRealMikz, @kuriozalny_prestydygitator: HTTPS ma też jedną wadę: jest wolniejszy, ze względu na szyfrowanie, co szczególnie widać przy stronach o bardzo krótkim czasie ładowania. Dla mnie (jako Web Deva), to spora wada.

@secret_passenger: @kuriozalny_prestydygitator: Mniej więcej napisałem. Google stronom z HTTP obniża ranking, dodatkowo takie rzeczy jak CORS (wczytywanie zasobów z innych stron) może działać chyba tylko po HTTPS. Oczywiście łatwiej taką stronę zaatakować "po drodze" (czyli ktoś dostarczy ci fałszywą), jeśli wymaga autoryzacji to twoje hasło idzie w formie "otwartej", więc jak ktoś podsłuchuje łącze to może zdobyć dane poufne.

Od strony ogólnej nie ma jakiś przeciwwskazań by korzystać z HTTP. Dla przeciętnego użytkownika jest to transparentne

@TheRealMikz: Ja używam Cloudflare. Może nie najlepiej, ale jako tako :P

@wrocilem_bo: jakie zmiany w kodzie strony masz na mysli?

@fervi: problem też w tym, że wielu nawet nie wie, że jest taka możliwość, trzeba czasu żeby cała branża zaakceptowała zmianę. I tak od czasu, gdy pojawiła się możliwość darmowych certyfikatów, to olbrzymia część serwisów się przesiadła na https.

@FredOnizuka: i o ile Ci ten https spowalnia?

@kuriozalny_prestydygitator: a tutaj masz wypunktowane

https://www.artefakt.pl/blog/seo/o-czym-nalezy-pamietac-wdrazajac-protokol-https-i-certyfikat-ssl

@fervi: dla mnie takie podejście HTTPS only jest nieco dziwne - sporo developerów ma swoje blogi postawione z uzyciem statycznych generatorów strony. statyczne generatory stają sie dość popularne w pewnych zastosowaniach i naprwadnie enie widzę powody by taką zawartość koniecnie pchać po HTTPS.

skoro jesteśmy tacy "eko" to policzmy ile w skali globalnej prądu idzie w "gwizdek" tylko dlatego że wszystko musi iść po HTTPS - czy to jest potrzebne czy nie.

dla wszelakich stron gdzie podaje się jakiekolwiek dane - rozumiem wymuszanie HTTPS. ale nie dajmy się zwariować.

i o ile Ci ten https spowalnia?

@TheRealMikz: W przypadku stron, które serwer jest w stanie wygenerować w czasie pojedynczych milisekund, to szyfrowanie zajmuje sporo czasu. Nie potrafię teraz podać konkretnych liczb (tym bardziej, że to zależy od wydajności serwera i czy szyfrowanie jest sprzętowe), ale miałem sytuacje, gdy szyfrowanie zajmowało więcej czasu, niż samo wygenerowanie strony.

@FredOnizuka: dobry ping za pośrednictwem internetu wynosi 50 milisekund. Opóźnienie dostrzegane przez człowieka wynosi jakieś 15 milisekund, różnica pomiędzy 50 a 65 milisekundami jest więc na granicy percepcji. Tak samo jak atak man in the middle.

@TheRealMikz: Tak, w przypadku jednego użytkownika to nie ma praktycznie znaczenia. Ale jak jednoczesnych użytkowników jest wielu, to przy stronie zoptymalizowanej pod kątem obsłużenia jak największego obciążenia (a więc bardzo szybkiej), czas potrzeby na szyfrowanie zauważalnie zmniejsza maksymalną liczbę użytkowników, jaką jest w stanie strona obsłużyć.
PS. No i ping 50ms, to raczej bardzo słabo (ja na łączu bezprzewodowym, czyli kiepskim, mam w tej chwili - przed chwilą zmierzyłem - średnio 35ms do serwerów Google).

@FredOnizuka: 35 ms to bardzo dobry ping, prawdopodobnie mieszkasz w dużym mieście i dostawca ma akurat mało obciążoną sieć.
Jak użytkowników zaczyna się robić tak wielu, że w loadbalancerze zaczyna brakować zasobów i wydajność szyfrowania spada, to odpalasz drugi loadbalancer. Przy takiej skali, w której loadbalancer na porządnym sprzęcie przestaje wyrabiać, serwis powinien przynosić takie dochody, że dostawienie drugiego jest pomijalnym kosztem.

@secret_passenger: Równie dobrze mogę powiedzieć, że skoro strony są statyczne to czemu nie hostować ich u Google czy gdzieś na Github.

@fervi: tyle że nawet hostując na github pages jest to hostowane przez HTTPS (domyślnie tak jest chyba ustawione - nie jestem teraz pewien czy da się przełączyć na HTTP). naprawdę IMO szkoda prądu - w wielu przypadkach.

@secret_passenger: No to masz dwie opcje:
- Szyfrować
- Nie być w Google ( ͡° ͜ʖ ͡°)

@secret_passenger: dostawca wstrzykujący swoje reklamy, cenzurujący treść (tak, internet jest nie tylko w wolnych krajach), ostatecznie publiczny access point, który wstrzykuje kod z malwarem albo skrypty kopiące kryptowaluty. Wszystko w Twoje statyczne HTMLe, których nie warto serwować po HTTPS bo szkoda prądu.

@FredOnizuka: to prawda. Każde żądanie poprzez protokół https to koszt szyfrowania. Ale czy to spora wada? W dobie JWT? Zawsze możesz zaimplementować komunikację klient-serwer poprzez websockety - autoryzowanie certyfikatu odbywa się wtedy tylko raz przy nawiązaniu połączenia. A odpowiednia technologia pozwoli ci na utrzymanie całkiem sporej liczby żądań konkurencyjnych.

@FredOnizuka: A jeśli masz spora liczbę assetow (i załóżmy, ze nie możesz jej zredukować), to wybor jest oczywisty - skorzystać z dobrego CDN.

@kuriozalny_prestydygitator: a tutaj masz wypunktowane

https://www.artefakt.pl/blog/seo/o-czym-nalezy-pamietac-wdrazajac-protokol-https-i-certyfikat-ssl

@wrocilem_bo: czyli przy dobrze napisanej stronie nic nie trzeba robić.

na jakieś zasadzie to działa? że jeśli Ktoś odwiedział daną stronę, to jest ona zapisyswana u niego na dysku? i wtedy łaczać się przez Brave łączymy sie nie z głownym serwerem na któym jest ta strona tylko z róznmi kompuerami które wcześniej były na tej stronie?? w przypadku stron szybko zmieniających treść jak portale czy nawet taki wykop to bez sensu przecież - po 20 minutach juz jest to nieaktualne.. poza tym dlaczego miałbym trzymać tyle śmieci na swoim kompie i udostepniac komuś transfer??

@ZawzietyRobaczek: Z grubsza to co opisałeś jest poprawne.
A odpowiadając na pytanie po co - po to, żeby nie było centralnego punktu który może cię zablokować

@ZawzietyRobaczek: no to sie zdecyduj - albo jestes zwolennikiem centralizacji i cenzury albo chcesz pomoc sieci P2P udostepniajac czesc swoich zasobow. nie mozna zjesc ciastka i miec ciastka :) druga sprawa pewnie bedziesz mogl okreslic jaki rozmiar dysku chcesz przeznaczyc na ipfs. 3 sprawa - nie hostujesz calych plikow tylko ich fragmenty ktore sa porozrzucane po roznych wezlach sieci IPFS

czy nawet taki wykop to bez sensu przecież

@ZawzietyRobaczek: ogólnie wykop jest bezsensu, a to jest dla stron z sensem ;)

@ZawzietyRobaczek: Dokładnie dlatego nigdy takie rozwiązania nie zastąpią tego co jest teraz. Jasne że decentralizacja ma swoje plusy, ale minusów jest o wiele więcej. Największy to moim zdaniem koszty (po stronie użytkownika), podatność na manipulacje, oraz spora szansa że na naszym komputerze będą przechowywane nielegalne treści (które mogą być potem znalezione i wykorzystane przeciwko nam).