W3C schetst contouren voor privacystandaarden

Het W3C heeft twee documenten vrijgegeven waarin de organisatie contouren schetst voor verbeterde privacy op websites. Het W3C zegt dat de voorstellen een reactie zijn op de toegenomen zorgen van eindgebruikers over onlineprivacy.

In een van de documenten pleit het W3C onder andere voor een zogeheten do-not-track-functie, waarmee internetgebruikers in hun browser kunnen aangeven dat ze hun persoonlijke informatie niet willen delen met adverteerders. "Deze standaard zoekt naar een manier waarmee bezoekers van websites transparantie en controle over hun gegevens krijgen", schrijft de belangenorganisatie.

Adverteerders op websites zouden in de toekomst moeten laten zien of ze persoonlijke informatie verzamelen of niet. Onder meer de voorgestelde do-not-track-header van de Amerikaanse handelscommissie FTC zou daarbij kunnen helpen, maar deze standaard wordt nog door weinig adverteerders gerespecteerd, omdat ondersteuning hiervan nog niet in de wet is vastgelegd.

Het W3C, het consortium waarvan onder andere Mozilla, Google, Microsoft en Facebook deel uitmaken, heeft een werkgroep opgericht die nieuwe privacystandaarden moet ontwikkelen. Het W3C heeft momenteel de eerste voorstellen van de werkgroep vrijgegeven. Anderen mogen ideeën aandragen voor de standaarden. De standaarden zijn naar verwachting halverwege volgend jaar af.

Onder andere Facebook wordt kritisch gevolgd vanwege zijn privacybeleid. De sociale-netwerksite maakte een paar jaar geleden onaangekondigd gegevens als naam, profielfoto, woonplaats en geslacht openbaar. Ceo Mark Zuckerberg omschreef de verandering destijds als 'een simpel controlemiddel voor de privacy'. Inmiddels heeft Facebook er naar verluidt mee ingestemd om privacywaakhonden twintig jaar lang inzage te geven in hoe het omgaat met privégegevens.

Reacties (21)

[Gamebuster]

Leuk, die privacy regels, maar juist diegene die inbreuk maken op je privacy, houden zich toch net zo makkelijk niet aan die regels?

Wie controleert of iets of iemand zich aan die regels houdt?

[Reactie gewijzigd door Gamebuster op 23 juli 2024 01:59]

[Roland684]

Precies, je moet tools hebben om het te forceren in je browser. Als je niet wil dat ze je in de gaten houden, moet je gewoon kunnen aanvinken dat je gegevens niet gecommuniceerd worden. Of beter nog, je moet (per website) aanvinken als het wel zou mogen.

Als je geen cookies wil, dan is er gewoon geen cookie, niet stiekem wel een cookie en een vinkje erbij dat de gebruiker heeft aangegeven dat hij niet wil dat je zijn cookie gebruikt.

Maar aangezien Google tegenwoording flink in de melk brokkelt (ook gezien de hoeveelheid potentieel privacy-gevaarlijke features die met html5 worden geïntroduceerd) zal dat een behoorlijke strijd worden.

[Muta]

Welke features komen mee met html5 en zijn potentieel privacy-gevaarlijk?
Ben benieuwd namelijk!

[Roland684]

Bijvoorbeeld Clients side storage (in file en/of database), het lezen/scrijven van het lokale filesystem en iets dat "browser history management" genoemd wordt.

Plots kan je browser bij je lokale filesystem en je browsing history.. why??? Dat zijn toch zaken waar je heel duidelijk zelf de controle over wil hebben en waar websites in principe niets mee te maken hebben.

* Roland684 voorziet 3 sites die er nuttig gebruik van maken en 100000 sites die er misbruik van maken.

[Reactie gewijzigd door Roland684 op 23 juli 2024 01:59]

[David Mulder]

Ok, serieus, als je geen flauw idee hebt waar je over praat, hou dan liever je mond (en ik kan me niet de laatste keer herinneren dat ik zo iets heb gezegd). Ten eerste, de nieuwe html5 specificaties zijn zo bizar strict opgesteld dat je als developer zijnde van het ene limiet tegen het andere limiet aan loopt *juist* om de gebruiker absoluut te beschermen (wat op zich ook wel goed is, daar niet van, maar blijft vaak irritant). Maja, kort lesje dan maar:

• Localstorage = Een geoptimaliseerdere vorm van cookies waarbij ze niet bij elke requests hoeven worden meegestuurd te worden en alleen client side bestaat. Kunnen alleen door de site zelf worden uitgelezen *altijd* en geven niet zelf een scope aan zoals cookies
• File system API = een set van API's die o.a. de mogelijkheid geven om in een gezandboxed gebied van je filesysteem bestanden weg te schrijven (en daarbij kwam dus ook goeie binaire support in javascript er bij). Dit is nog redelijk experimenteel zover ik weet, maar is, zoals altijd, *per site*
• Index DB(/SQL Storage) = Een lokale database *per site* waar informatie in kan worden opgeslagen. Bedoeld om applicaties mogelijk te maken die offline blijven werken. Kan dus *weer* niet worden uitgelezen door andere sites.
• History API = De mogelijkheid om history entries toe te voegen/bewerken die *van de huidige site* zijn. Dit maakt het mogelijk om bijv. als de gebruiker de terug knop klikt op een pagina die via ajax werkt, toch terug te gaan naar de vorige pagina.
• CORS = Cross Origin Resource Sharing is de kern van een systeem waardoor sites alleen dingen van andere sites mogen uitlezen als die andere site het toestaat en *niet* zomaar

Hoe dan ook, the point is, wat betreft security heb je echt niks te klagen in de nieuwe specs, de *enige* echte fout die er was gemaakt was iets in de webgl specificatie waardoor het (heel traag) mogelijk was om een afbeelding van een ander domein te reverse opbouwen. En dat vind ik toch echt meevallen met alle meuk die ze in totaal wel niet bedacht hebben. En oh jah, ook nuttig om te weten dat al die storage mogelijkheden standaard echt bizar lage limieten hebben (ook al is het aan de browser om die vast te stellen)

[Roland684]

Leuk gesproken, maar dan maak ik een local storage die ik vanuit een iframe benader en met cross-document messaging communiceer ik lekker met de rest van de site.
Hoppa, en je kunt overal waar jij "*per site*" schrijft, dat vervangen door "het hele internet".

En ja, de history api maakt het mogelijk om de back-knop eens netjes af te handelen op ajax-sites (waarbij je je eigenlijk af moet vragen of je dan geen structureel verkeerd ontwerp aan het oplappen bent), maar het is tevens een fijne tracker om te kijken welk pad de gebruiker in een site heeft afgelegd, geen gedoe meer met server side sesies en vage aannames, maar een duidelijk pad wat de gebruiker heeft gevolgd. En zoals gezegd, verwacht ik dat dat laatste duizende malen meer voor gaat komen dat het eerstgenoemde.

Google en andere handelaren in gebruikersgegevens gaan de webbouwers gewoon een scriptje geven dat een iframe maakt en alle gegevens daar naar doorsluist (en dus naar google).

[David Mulder]

Niet te geloven, je weet echt niet waar je over praat... ten eerste, als er cross domain attack vectors in een webpagina zitten kunnen die sowieso rechtstreeks worden geexploited wat totaal totaal *niks* te maken heeft met de techniek die achter de data storage ligt. Ten tweede, de meeste moderne sites hebben echt geen cross domain attack vectors meer in hun sites zitten, dus dat is sowieso irrelevant. (En zonder dergelijke vectoren is het onmogelijk, omdat alles binnen het iframe z'n eigen domain policy heeft indien er iets vanaf een ander document wordt geladen. En hetzelfde geld met afbeeldingen, webgl textures, videos etc. Zodra er iets externs in zit, is het element "tainted" en kan je er geen informatie meer over ophalen). En als het wel gewenst is (zoals je op het einde omschrijft) en een site eigenaar ***WILT*** jouw gegevens naar bijv. Google doorsluisen dan ***KONDEN ZE DAT ALTIJD AL*** EN ***HET IS HUN GOED RECHT***, dat is simpelweg de deal die jij maakt door een "gratis" website te gebruiken. In return voor het bekijken van advertenties en het versturen van jouw informatie (zover wettelijk toegestaan) krijg jij ongelovelijk goeie diensten terug (zoals Google de zoekmachine, Facebook, Gmail, tweakers.net ). En het meest belangrijke is dat dat TOTAAL NIKS TE MAKEN HEEFT MET HTML5

@pad uitlezen, daar zou je never nooit de history API voor gebruiken omdat het bizar inefficient zou zijn als je iedere request het volledige pad zou versturen In plaats daarvan track je gewoon iedere request die een gebruiker doet en vorm je op basis daarvan een "pad" of - zoals google analytics zelfs doet - je houd zelfs bij welke links er worden geklikt en linkt dat aan de requests. Wat voor een meerwaarde heeft het om dat vanuit de history api uit te lezen die zelfs concepten zoals trees e.d. totaal niet kan begrijpen.

offtopic:
En nog twee dingetjes @alle tweakers hier:
• Ten eerste, modereer inhoudelijke comments pls alleen als je begrijpt waar ze over gaan.
• Ten tweede, sorry voor het gebruik van caps lock in deze comment meestal verneder ik me niet tot dat niveau

[Reactie gewijzigd door David Mulder op 23 juli 2024 01:59]

[mystic101]

Ik ben het grotendeels met je eens. Allen je sorry, die kan ik niet serieus nemen. Ze stoot me zelfs tegen het zere been. Wanneer je verontschuldiging echt is, dan laat je deze staan maar dan haal je tevens de caps weg. Laat je de caps staan, dan maakt je 'sorry' het alleen maar erger.

[David Mulder]

offtopic:
@mystic101: Niet mee eens, die comment was gewoon een betoog dat ik schreef zoals ik het in me opkwam en die sorry was retrospectief gewoon een verklaring van "jah ik ben me er van bewust dat het niet hoort, maar ik heb het nu wel gedaan en ik besef dat het kinderachtig is", maar het is dus wel zo, zoals ik het bedoelde toen ik het schreef en het spijt me oprecht@iedereen die er (al dan niet principieel) last van heeft.

[Verwijderd]

Volgens heeft W3C die truuk allang zien aankomen en zijn bij alle browsers beperkingen ingebouwd om illegale communicatie tussen iframes tegen te gaan.

[Dr. Horrible]

Client side storage betekent niet dat de browser opeens bij je hele harde schijf kan. Je kan een stukje data opslaan op de harde schijf van de client en deze later weer uitlezen. Alleen de data die je zelf hebt opgeslagen kan je later weer uitlezen. Niet van andere sites...

Het browser history management ken ik niet.

[Roland684]

Inderdaad, client side storage is vergelijkbaar met cookies, alleen veel meer bytes en een database-interface.

Maar aan cookies kleven al een hele range van privacy-bezwaren en er zijn legio manieren om cookie zo te maken dat ook andere sites ze kunnen uitlezen, bedoeld of onbedoeld.
En cookies zijn nog relatief simpel. client side storage wordt veel complexer. Over hoe je dat als gebruiker moet gaan beheersen (ook ivm je privacy) lijkt nog weinig nagedacht.


Behalve dat komen er ook functies voor het uploaden, schrijven en manip[uleren van bestanden op het lokale filesystem. (en het zou me verbazen als er niet ook een optie komt om een listing op te vragen).

[Nas T]

dat maakt niet uit: W3C maakt standaarden, dus protocollen hoe iets werkt. Het is niet een kwestie van zich wel of niet er aan houden. Dat is hetzelfde als een schroef aandraaien met een hamer.

[Reactie gewijzigd door Nas T op 23 juli 2024 01:59]

[Standeman]

En die standaarden worden door andere geimplementeerd en implementaties kunnen nogal verschillen (IE vs FF implementatie van HTML4 / CSS bijv.) . Het is niet hetzelfde een schroef met een hamer aandraaien. W3C geeft aan dat je een schroevendraaier nodig hebt, maar als jij niet wil dat de schroef aangedraaid wordt, implenteer je gewoon de hamer.

[mystic101]

...Dat is hetzelfde als een schroef aandraaien met een hamer.

In hout nooit een probleem!

[merauder]

Dit is ook wat er in browserland gebeurt. Tegenwoordig lijkt het al iets beter, maar ten tijde van IE7 was het nodig om aanvullend CSS correcties te schrijven. In dit geval kreeg je inderdaad een hamer aangereikt om een schroef mee te draaien, maar vervolgens kies je voor een werkende, maar niet charmante oplossing in de vorm van het hameren.

[johnkeates]

Ligt het aan mij, of hoort Apple net zo goed in het rijtje van leden thuis? Met de commercialisering (qua code en management standaarden) van WebKit hebben ze toch een vrij grote impact op het www. Als je ziet hoe veel browsers de WebKit engine gebruiken (en ja, ik weet dat KHTML de basis was, en WebKit nu een zo-goed-als-open-source project is) en ook kijkt in de ledenlijst van W3C... Lijkt me een idee van de auteur om een naam weg te laten

Inhoudelijk is het natuurlijk logisch dat web privacy meer aandacht krijgt, alle 'andere' onderdelen hebben al zo lang zo veel aandacht gehad dat het er vanzelf wel op moest komen. Ik vraag me alleen af of er (zoals hierboven ook al gepost) inderdaad gebruik van gemaakt gaat worden (of een implementatie gemaakt wordt), privacy schendingen worden juist in verband gebracht met types die er niet zo veel mee hebben, die gaan zich dan echt niet aan regels houden, en vinden wel een weg om toch te doen waar ze zin in hebben.

[arjankoole]

in het artikel staat dan ook: "Het W3C, het consortium waarvan onder andere".

De hele leden lijst van W3C opnoemen is ook een beetje onzin, zo groot is Apple nou ook weer niet op webbrowser gebied. Dan zou je Opera ook moeten noemen, en nog een slordige honderd alternatieve browsers.

[David Mulder]

Nah, iOS webkit hoort tegenwoordig toch echt tussen de grote browsers thuis, hoe je het ook went of keert. (Net zoals mobile opara wrs ook ook wel... ook al kun je dat nauwelijks een browser noemen ).

[Lucb1e]

Dus als ik het goed begrijp geef je je persoonlijke gegevens aan iedereen op het web, maar vinden mensen het gek als dat vervolgens gebruikt wordt voor advertenties? Is een beetje alsof je anoniem aangeeft dat je computer zo traag is, en vervolgens een advertentie terugkomt voor nieuwe computers ofzo. In real life zouden we daar geen bezwaar tegen hebben, maar zodra google ads gepaste advertenties aangeeft ho maar.

(En ik zeg in het voorbeeld anoniem omdat aan adverteerders niet wordt doorgegeven wat je volledige voor- en achternaam is, wat je pasfoto is en waar je woont enzo).

Of je geeft je naam en leeftijd (forum profiel) aan een random website (groep personen) en vindt het gek als vervolgens iedereen het weet.

Dit do-not-track geval en cookies verbieden enzo slaat volgensmij helemaal nergens op... (Google ook eens naar 'geenstijl cookies').