Chcą, by Google płacił wielomiliardowe odszkodowanie za śledzenie w trybie incognito
Przed sądem federalnym w San Jose złożono pozew zbiorowy przeciwko Google'owi. Autorzy pozwu oskarżają wyszukiwarkowego giganta o to, że zbiera informacje o internautach mimo iż używają oni trybu prywatnego przeglądarki. Uważają, że Google powinien zapłacić co najmniej 5 miliardów dolarów grzywny.
Zdaniem autorów pozwu problem dotyczy milionów osób, a za każde naruszenie odpowiednich ustaw federalnych oraz stanowych koncern powinien zapłacić co najmniej 5000 USD użytkownikowi, którego prawa zostały naruszone.
W pozwie czytamy, że Google zbiera dane za pomocą Google Analytics, Google Ad Managera i innych aplikacji oraz dodatków, niezależnie od tego, czy użytkownik klikał na reklamy Google'a. Google nie może w sposóby skryty i nieautoryzowany gromadzić danych na temat każdego Amerykanina, który posiada komputer lub telefon, piszą autorzy pozwu.
Do zarzutów odniósł się Jose Castaneda, rzecznik prasowy koncernu. Za każdym razem, gdy użytkownik uruchamia przeglądarkę w trybie prywatnym, jest jasno informowany, że przeglądane witryny mogą śledzić jego poczynania, stwierdził.
Specjaliści ds. bezpieczeństwa od dawna zwracają uwagę, że użytkownicy uznają tryb prywatny za całkowicie zabezpieczony przez śledzeniem, jednak w rzeczywistości takie firmy jak Google są w stanie nadal zbierać dane o użytkowniku i, łącząc je z danymi z publicznego trybu surfowania, doprecyzowywać informacje na temat internautów.
Komentarze (46)
Felipesku, 4 czerwca 2020, 09:39
Nazwa incognito mowi sama za siebie, śledzenie ma być usunięte z kodu a kara jest zbyt niska, ktoś powinien iść siedzieć bo kasa to za mały straszak.
tempik, 4 czerwca 2020, 10:28
ale to jest tylko tryb przeglądarki o czym sama przeglądarka ostrzega czyli dotyczy tylko twojego kompa, czyli działa tylko na np. żonę i innych domowników
. tryb incognito tuż za twoim routerem już jest niemożliwy do realizacji
cyjanobakteria, 4 czerwca 2020, 13:38
Incognito oznacza, że nie ujawniasz swojej tożsamości, czyli w czasie internetu przeglądarka nie wysyła ciastek z identyfikatorami sesji i nie jesteś zalogowany. Nie zapisuje też ciastek na dysku. Wszyscy, włącznie z ISP, właścicielami witryn i deweloperami rozszerzeń mogą śledzić użytkowników. Google niewiele może z tym zrobić.
peceed, 16 września 2020, 23:03
Incognito to beznadziejna i myląca nazwa dla tego trybu. Nie oddaje funkcjonalności.
Powinni to nazwać "Amnesia".
Przeglądarka nie pamięta co robiła wcześniej i nie będzie pamiętać tego, co robisz teraz.
Programiści często nie przywiązują uwagi to tworzenia dobrych nazw traktując je jako prawie randomowe identyfikatory.
Osobiście wyznaję zasadę "code speak to you", tworząc kod powinniśmy dbać o maksymalną łatwość w jego zrozumieniu i szybkość czytania, dobre nazwy są kluczowe.
Jajcenty, 16 września 2020, 23:12
Wolałem stary paradygmat komentowania kodu, a przede wszystkim korzystanie z automatycznego dokumentowania. W tej chwili mój kod jest pełen potworów typu
List<Document> documents = new List<Document>();
pewnie żeby choć trochę zamieść to pod dywan moge se napisać:
var documents = new List<Document>();
co za ulga.
peceed, 17 września 2020, 00:05
Językom programowania brakuje dobrych elips.
Można chyba było pisać List<Document> documents = new List<>(); //ignorujemy że List to interface:AI dobierze najlepszą implementację
Osobiście nie lubię utraty regularności i wolałbym:
List<Document> documents = new();
Ale jest to bez różnicy, mózg uczy się szybko parsować dowolny język w 2 tygodnie.
Na rozwlekły kod najlepszym rozwiązaniem jest czcionka 8 (tylko trzeba zainstalować specjalne o zwiększonej czytelności) i długość linii 320 (nie bierzemy jeńców).
Są jednak ludzie którzy nie procesują kodu tak jak w technikach szybkiego czytania i muszą przejechać po wszystkich linijkach po kolei, w pewnym sensie odtwarzając wykonanie programu. Zauważyłem że takie osoby znacznie lepiej pamiętają kod z którym pracują, bo muszą go zapamiętywać w pamięci długotrwałej aby móc pracować w ogóle (podobnie jak osoby pracujące z małym obszarem edytora). Za to mają wielkie problemy z refaktorowaniem.
Ja nie pamiętałem kodu tylko to co robił.
Komentuje się wysokopoziomowe intencje: w ten sposób łatwiej zrozumieć program i łatwiej o znajdywanie błędów.
cyjanobakteria, 17 września 2020, 00:25
Static typing ma swoje zalety, jak i wady. Zawsze możesz pisać w Ruby albo Pythonie. Ruby jest ciekawe, bo składnie przypomina zdania po angielsku. Jeżeli chodzi o długość kodu to Ruby i Python wymagają znacznie mniej klepania i mniej komentowania.
peceed, 17 września 2020, 01:53
Jeśli się rozumie, że programy pisze się przede wszystkim dla ludzi to typowanie statyczne jest niezbędne.
1. Straciłem umiejętność programowania.
2. Wciąż korzystam z powłoki pythona jako kalkulatora.
3. W Ruby programowałem zanim było to modne (2002).
GL&HF
cyjanobakteria, 17 września 2020, 03:14
No to jeżeli programowałeś to wiesz, że najpopularniejsze i najbardziej lubiane języki programowania są dynamicznie typowane
Większość kodu który widziałem w Ruby On Rails ma niewiele komentarzy, bo są one zbędne. Każdy end-point w RoR ma te same metody: index, show, edit, update, i tak dalej. Oczywiście to jest specyfika tego języka i tego frameworka oraz generatorów, które trzymają się uzgodnionego stylu. W przypadku tasiemców w C++ czy Java jest większa potrzeba komentarzy, nie wspominając o sieczce, którą jest kod w czystym C.
peceed, 17 września 2020, 13:30
Jest to równie prawdziwe jak stwierdzenie, że najwięcej gównianego kodu powstaje w językach dynamicznie typowanych.
Informacje o typach zmiennych a zwłaszcza parametrów są kluczowe i nie do zastąpienia przez cokolwiek: to najważniejsza informacja o kontrakcie.
Brak takich informacji spowalnia rozumienie kodu.
Żeby było jasne: od strony teoretycznej usunięcie typów niszczy gwarancje poprawności wykonania których zapewnienie w przypadku ogólnym jest nierozstrzygalne.
Mózg stara się wykonać dokładnie taką samą robotę samemu.
Cały postęp w rozwoju narzędzi dla języków bez statycznego typowania jest kierowany na odtworzenie takowego automatycznie. Te języki nie bez powodu nazywały się kiedyś skryptowymi: nie nadawały się do tworzenia wielkich aplikacji.
I praktycznie każdy taki język dostał rozszerzenia/rozwinięcia które umożliwiają statyczne typowanie, nawet te najlepiej predysponowane jak Smalltalk czy Lisp.
Nie mieszajmy różnych systemów walutowych. Nie należy porównywać kodu z frameworku bazującego na konwencjach do generycznego, bo mamy porównywać języki.
Czysty c pozwala na pisanie równie zrozumiałych programów co C++, nie wiem o co chodzi z sieczką. Brak szablonów, przeładowania operatorów, dziedziczenia itp. powoduje, że pewne rzeczy pisze się trudniej/dłużej, ale nie że kod z automatu staje się mniej zrozumiały.
Sieczka w C jest prawie 1:1 prawidłową sieczką w C++, a jeśli ktoś preferuje tę technikę pisania to jest ona wspierana przez każdy język programowania.
cyjanobakteria, 17 września 2020, 14:25
Jeżeli chodzi o ilość podatności, błędów związanych z bezpieczeństwem, szczególnie z operacjami na pamięci, to niekwestionowanym(!) liderem jest C - język statycznie typowany
Ciężko uczciwie porównywać różne języki, bo często mają swoje nisze, a ja nie specjalizuje się w teoretyzowaniu. Przykładowo w C powstało dużo niskopoziomowego kodu, na przykład sterowniki, kernel Linuksa, czy biblioteki OpenSSL, które trudno zrozumieć. W Ruby, głównie Ruby on Rails, to stosunkowo lekkie API dla web aplikacji. A JavaScript to jeszcze do niedawna głównie domena web aplikacji po stronie klienta. Wspominając o JS, warto przypomnieć, że API przeglądarek było bardzo silnie rozwijane i niedawno zostało ustandaryzowane, w związku z czym środowisko przestało przypominać dziki zachód.
darekp, 17 września 2020, 14:43
Hm, aż ciekawości zagooglowałem i pierwszy link jaki znalazłem mówi coś innego:
https://developers.slashdot.org/story/18/01/01/0242218/which-programming-languages-are-most-prone-to-bugs
Nie czytałem pracy źródłowej (mocne niedobory w zasobie o nazwie czas;)) ale z tego króciutkiego wpisu wynika, że niespecjalnie jest ważny rodzaj typowania, za to liczy się funkcyjność.
Jajcenty, 17 września 2020, 15:33
A jak ma być? Przecież to praktycznie asembler jest. Przy okazji: C bardzo awansował przez lata, na polskiej wiki napisali, że to język wysokiego poziomu, a przecież mam w pamięci obraz strony
https://archive.org/details/TheCProgrammingLanguageFirstEdition/page/n8/mode/2up
darekp, 17 września 2020, 16:04
Nie wiem, czy to ma związek, ale sam język też się rozwinął, pierwsze wersje miały jakiś mechanizm domyślnego przyjmowania typu int (gdzieś czytałem, że po to, żeby ułatwić kompilowanie starego kodu Unixa pisanego w języku B), możliwość opuszczania listy parametrów w deklaracji funkcji. A potem weszło solidniejsze sprawdzanie typów i takie rzeczy jak void i void *
Szczerze mówiąc mnie czasem nachodzi chęć, żeby wrócić do tego C i jeszcze coś w nim poprogramować. Bardziej niż do C++.
peceed, 17 września 2020, 18:36
Tego nie rozumiem. Ręczna gospodarka pamięci, brak izolacji błędów które stają się "magiczne"...
Chyba że to na takiej
Błędy są związane z ręcznym zarządzaniem pamięcią i brakiem systemu wyjątków czego statyczne typowanie nie wymusza.
Typowanie statyczne umożliwia za to szybką kompilację do kodu maszynowego i stosowanie semantyki zmiennej jako wartości co pozwala alokować większość danych na stosie i zapewnia szybsze działanie.
Jajcenty, 17 września 2020, 19:03
I dlatego Python jest taki najlepszy na świecie. Bo moduły ma popisane c/c++
cyjanobakteria, 17 września 2020, 20:00
Nie twierdzę, że jest inaczej tylko odniosłem się do stwierdzenia, że najwięcej gównianego kodu jest pisanego w językach dynamicznie typowanych
Całkiem sporo, czy najwięcej to nie wiem, gównianego kodu jest napisanego w C, wliczając w to błędy które wstrząsnęły internetem w ciągu ostatnich kilku lat, jak Heartbleed czy CloudLeak. Inna rzecz, że błędy po stronie JS, mogą co najwyżej utrudnić korzystanie z web aplikacji czy witryny, sporadycznie polecą ciastka sesyjne 
Ale to błędy po stronie serwera są najniebezpieczniejsze.
Chodziło o ilość CVE w bazie. Jestem praktycznie pewien, że dane nie są znormalizowane. Z drugiej strony C jest w niekorzystnej sytuacji, bo wymaga ręcznej obsługi pamięci, co generalnie nie ma miejsca w innych językach. Język jest insecure by design, a jest to spowodowane postawieniem na wydajność. W czasach kiedy powstawał, a jest to stary język, to miało znaczenie. Więc nie wieszam na nim psów.
Jajcenty, no bez przesady, tu masz hello world w ASM zdekompilowane przez radare2. Wrzuć kilka if'ów i już masz materiał na fototapetę po wydruku
peceed, 17 września 2020, 22:06
Błędy to nie jedyne kryterium jakości kodu. W znaczeniu o które mi chodziło mogą być nieistotne, bo są one wyznacznikiem jakości całego procesu tworzenia programowania. Chodziło mi w kontekście dyskusji o łatwość zrozumienia i czytelność. Ale jest to skorelowane z innymi metrykami jakości: gdy ktoś kto nie jest w stanie napisać czytelnego i zrozumiałego kodu, są wielkie szanse że sam go nie ogarnia do końca i działa on miejscami przez przypadek.
Node.js
Rak odbytu dał przerzuty.
darekp, 18 września 2020, 06:22
Po prostu sprawia mi frajdę pisanie czegoś, co jest wydajne. Ręczna gospodarka pamięci nie zawsze jest taka straszna, zazwyczaj można sobie tak zorganizować kod, że ryzyko błędów z nią związanych jest nieduże. Fakt, że w C++ pod tym względem są "luksusy", bo można używać smart-pointerów itp.
Kwestia obsługi błędów chyba nigdzie (w żadnym jęz. programowania) nie została dobrze rozwiązana (może po prostu nie da się). Try...catch jest dobre w przypadku, gdy można w nie wsadzić cały kod obsługi czegoś i w catch-u zalogować/wyświetlić treść błędu i potem iść dalej albo zatrzymać proces. Jeśli wdepnąć w coś bardziej skomplikowanego (np. zagnieżdżone try...catch) to rychło dochodzi się do poczucia, że szkoda, że nie można tego łatwo przerobić na coś w rodzaju discriminated union z języków funkcyjnych (explicite wymienione wszystkie możliwości, kompilator pilnuje, żebyś je wszystkie obsłużył). Przynajmniej takie mam doświadczenie - niedawno gdzieś przeczytałem, że w Pythonie często używa się wyjątków, może warto byłoby żebym więcej używał Pythona, może wtedy by mi się wyklarowało jakieś inne spojrzenie na sprawę, ale na razie mam wrażenie że te wyjątki w Pythonie są używane do jakichś specyficznych zastosowań (widziałem przykład użycia wyjątku do przerwania iteracji i to wyglądało tam na uzasadnione użycie).
cyjanobakteria, 18 września 2020, 08:22
A kto to przyszedł? Pan maruda, niszczyciel uśmiechów i dobrej zabawy!
Moim zdaniem Python jest najbliżej ideału pod względem ilości kodu do klepania, czytelności, przenośności, wydajności i bezpieczeństwa. Cieniem kładzie się brak wstecznej kompatybilności pomiędzy 2.7 i 3, ale nie jest to duży problem. Aktywne projekty deweloperskie i paczki zostały poprawione do Python 3, ale w mojej branży jest masa narzędzi, napisanych 10 lat temu w 2.7, które po prostu działają i nikt nie będzie tego ruszał. Da się z tym żyć. Od biedy można postawić Dockera z 2.7 albo maszynę wirtualną.
Z mainstreamowych języków, programowałem głównie w JS, Python i Ruby oraz w mniejszym stopniu (wiele lat temu) w PHP i C++. Ostatnio odświeżyłem C w wydaniu pod Linuksem. Jakbym miał znać tylko jeden, uniwersalny język, to bym się nauczył tylko Pythona z wielu powodów. Jeżeli tylko jeden do komercyjnego zastosowania to JavaScript ze względu na mnogość ofert. Jeżeli natomiast wydajność byłaby absolutnym priorytetem, co nigdy nie miało miejsca w moim w przypadku, albo gdybym pracował w gamedev, to C/C++.
JS jest ciekawym językiem, bo jest wszędzie, chociaż ma swoje niedociągnięcia. Chyba zdecydowana większość napisanego kodu chodzi na co dzień w przeglądarkach internautów. Ze dwa lata temu czytałem, że CloudFlare pracował nad umożliwieniem wykonania JS w środowisku serverless na obrzeżach ich infrastruktury, co pozwala odciążyć klientów i serwery oraz skraca czas. Podejrzewam, że już to wdrożyli.
peceed, 18 września 2020, 14:46
Nie liczy się ilość ofert, tylko stawki w tych ofertach. Tutaj nie liczyłbym na JavaScript. Już wolałbym COBOLa.
PHP i Javascript to języki stworzone przez amatorów.
Najważniejsze jest to, że błędy i problemy uniwersalnie rzucają wyjątki, w ten sposób można świadomie zignorować problem, ale nie odwrotnie.
Błędów nie trzeba obsługiwać, ważne jest aby je zawsze wykryć.
Nie należy z tym przesadzać, taka java cierpi z powodu wyjątków sprawdzanych, a dokładniej źle zaprojektowanej hierarchii wyjątków (bo wyjątki sprawdzane to mógł być feature a nie bug) która w praktyce nie pozwala ignorować obsługi błędów, co często prowadziło do ignorowania błędów. Hierarchia wyjątków powinna raczej wyglądać jak Exception<-CheckedException, a wyjątki sprawdzane być specjalnym przypadkiem.
Do tego obsługa wyjątków była strasznie "przegadana", problem częściowo rozwiązał multi-catch, ale wciąż chciałoby się móc napisać (catch !RuntimeException ).
cyjanobakteria, 18 września 2020, 16:40
No, a jakie są te stawki? Też słyszałem te historie o jednorożcach klepiących w COBOLu za astronomiczne stawki, ale nigdy żadnego nie widziałem na własne oczy. Na szybko sprawdziłem w Google i zarobki nie robią na mnie wrażenia, bo nie odbiegają od średniej. Zakładam, że mogę się mylić i że faktycznie gdzieś płacą więcej.
Skoro sam przestałeś klepać kod w 2002, to mnie nie dziwi, że wolisz COBOLa. Analizowałem kiedyś kod źródłowy takiej aplikacji i podszedłem do tego entuzjastycznie, ale szybko mi przeszło, bo COBOL wygląda trochę jak nieślubne dziecko BASIC i Assemblera
To już wolę bawić się w inżynierię wsteczną w czystym ASM, co jest generalnie czasochłonne i bywa frustrujące, ale przynajmniej daje poczucie posiadania nadprzyrodzonych mocy, bo mało który z deweloperów w dzisiejszych czasach ogarnia języki niskopoziomowe 
Za PHP nie przepadam, ale akceptuję, że 3/4 internetu na tym chodzi. Podobnie jest z JS, przy czym tutaj to praktycznie 100% po stronie przeglądarek. Ma swoje niedociągnięcia, ale to jedyny język, który chodzi na back-end + front-end oraz build pipeline jest w tym napisany. A teraz do tego doszły aplikacje desktopowe oraz mobilne. Witam w świecie, gdzie cyfrowa ewolucja wypromowała nieperfekcyjne (nie-peceedowe w domyśle) narzędzie
Torvalds w momencie, kiedy publikował pierwszą wersję kernela Linuksa w 1991, miał 21 lat i był studentem informatyki.
Jajcenty, 18 września 2020, 17:38
Stallman jedzie Ci przylać za herezję. GNU to cały system i dziecię Stallmana, Linux to tylko jądro. GNU miało być na mikrojądrze, ale Linux był nieco szybciej więc go użyto. W efekcie rozwój mikrojądra znacznie zwolnił. Nie wiem czy i kiedy Stallman porzucił ideę budowania mikrojądra, ale faktycznie niewiele się słyszy już o tym pomyśle.
Jajcenty, 18 września 2020, 17:44
A mnie i owszem, dziwi. Pisałem w COBOLu przez ponad 18 lat i w mojej opinii lubienie tego zakrawa na syndrom sztokholmski. Ale trzeba przyznać, że miał ładne struktury danych, choć przy niskich poziomach trzeba było uważać, bo kompilator lubił coś dosunąć do granicy słowa dorzucając w strukturę parę gap bajtów.