Tweakers introduceert responsible-disclosurebeleid

Het is al jaren gebruikelijk dat bezoekers die een beveiligingsprobleem vinden op onze site, dat bij ons melden. We zijn daar uiteraard heel dankbaar voor, maar we hebben er nooit een formeel beleid voor opgesteld. Strikt juridisch gezien is het ontdekken en melden van beveiligingsprobemen namelijk best lastig. Om (voor jezelf) te bevestigen dat het probleem inderdaad bestaat, of groter is dan het mogelijk lijkt, moet je vaak handelingen verrichten die uit te leggen zijn als computervredebreuk of die anderszins niet zomaar wettelijk zijn toegestaan.

Een responsible-disclosurebeleid is bedoeld om de melders van beveiligingsproblemen te laten weten onder welke voorwaarden wij geen juridische stappen ondernemen en wat ze juist van ons mogen verwachten. Het is uiteraard niet zo dat we voorheen standaard onze jurist aan het werk zetten, maar door dit vast te leggen weet een melder waar de grenzen liggen en wat wij van hem of haar verwachten. Denk daarbij aan het niet misbruiken van de verzamelde informatie, het niet moedwillig veranderen of verwijderen van informatie, de melding niet met anderen delen voordat wij een kans hebben gekregen het probleem op te lossen, enzovoort.

Dingen die je als melder van ons mag verwachten zijn onder andere dat we je op de hoogte houden, dat we toelaten dat je het publiceert en dat we je publiekelijk bedanken. Daarnaast hebben we nu ook formeel afgesproken wanneer je van ons een cadeau naast het bedankje krijgt. Uiteraard geldt dat alleen voor meldingen van problemen die ons nog niet bekend waren. Dat kan trouwens ook een nieuwe kijk op een bestaand probleem zijn of een oplossing die wij niet kenden.

De daadwerkelijke en wat drogere tekst van ons responsible-disclosurebeleid kun je op onze site lezen.

Reacties (83)

[ATS]

Maak het probleem niet openbaar en deel het niet met anderen totdat het is opgelost.

Die is behoorlijk beperkend. Daar zou een tijdslimiet aan moeten zitten wat mij betreft. Nu kan Tweakers gewoon zeggen "Ok, ja, je hebt gelijk. We zetten het op de ToDo lijst." en daarmee is de kous af en moet de melder verder zijn mond houden. Dat lijkt me niet de bedoeling.

[Firefly III]

In het kader van responsible disclosure kan het zijn dat je strafbaar bezig bent geweest (computervredebreuk). Je hebt een lek gevonden; je bent binnen; strafbaar.

Uit de tekst van het ministerie:

Een partij die een responsible disclosure policy vaststelt kan zich bijvoorbeeld binden aan het principe om geen aangifte te doen als aan de volgens het beleid geldende spelregels wordt voldaan

Dat betekent dat Tweakers jou de ruimte geeft om "in te breken" binnen de grenzen van het vinden van beveiligingslekken. Daar staat tegenover dat je Tweakers de tijd en de ruimte gunt om het probleem op te lossen.

Als je van mening bent dat Tweakers niet coulant is, staat het je natuurlijk vrij om ze te chanteren met een deadline. Maar dan is de responsible disclosure policy ook van tafel en kan het best zijn dat ze alsnog aangifte doen.

[Verwijderd]

Maar tweakers.net bepaald niet wat wettelijk toegestaan is. Zij hebben geen inspraak in wat het OM doet. Die kunnen overgaan tot vervolging en het feit dat Tweakers.net een coulante opstelling heeft voor 'white hackers' in zekere zin, is voor het OM niet relevant.

Nu zal het OM er niet bij betrokken worden. Maar de wet is een ding dat zaken vooraf regelt zodat de verhoudingen duidelijk zijn. Iets waar je op terug valt als er een geschil ontstaat. In de meeste gevallen zal dit allemaal gladjes verlopen neem ik aan. Maar de wereld is een gek ding. Op een dag gaat het fout. Tweakers.net is niet blij, of de hacker is niet blij. Ze komen er samen niet uit. En na aangifte heeft Tweakers het niet meer voor het zeggen.

[Tosty_82]

Als ik in mijn winkel Iedereen uitnodig om proberen te stelen (test van mijn beveiliging), en als je het lukt dan mag je het zonder gevolgen houden kan het OM daar niet tegenin gaan Volgens mij.
De Wet stelt een grens om je als bijv. Winkelier te beschermen. Jij mag die grens niet nog strakker maken, omdat het jou nog beter uitkomt. Maar als jij die losser maakt, Ten nadele van jezelf, dan mag dat Volgens mij wel.

[Verwijderd]

Wel, dat kunnen ze dus wel. Je kunt de wet niet even uitschakelen omdat ie even niet van pas komt. De wet is de wet is de wet. De wet is er niet om de winkelier te beschermen. De wet is er om de samenleving als geheel te voorzien van verantwoordelijkheid voor eenieder die iets fout doet.

Je kunt een wet niet oprekken of krimpen. Stel dat jij gechanteerd wordt. En je bent bang. De dader zet je onder druk. En de politie komt het op het spoor. Uit angst zeg jij dan dat het wel goed zit. Dan kan het OM toch vervolgen, het is niet aan jouw om de wet die van toepassing is op chantage te annuleren omdat jij het allemaal zogenaamd wel okay vindt.

Dat zou willekeur zijn.

[kwakzalver]

Kijk samen werken om op te lossen (Tweakers & 'us prutsers') -of- vechten om het op te lossen (Google vs. Microsoft/Apple).

De kern van de tekst dat als je geen misbruik maakt van de situatie dit geen juridische gevolgen heeft. Ik ben nog steeds van mening dat een constructieve samenwerking sneller tot oplossingen leidt en dit een prima beleid is.

En ja we moeten vertrouwen hebben dat de 'issue' tracker prima werkt bij Tweakers.
Misschien moet Tweakers aan troostprijzen denken voor degene die bijna gelijktijdig een bug melden.....

[Reactie gewijzigd door kwakzalver op 24 juli 2024 10:20]

[Firefly III]

Dat laatste vooral. Helemaal mee eens.

"Ja maar er is geen deadline!"

Kom eerst maar eens met een voorbeeld dat Tweakers een probleem niet binnen vijf minuten wist te fixen. Ok, 10 minuten, want hij moest nog ff langs acceptatie.

En als ACM iets bijzonders vindt dan jast ie dwars door alle environments heen en past-ie het live aan.

Dat geknor altijd over niet-bestaande problemen..

[sfranken]

ACM is dan ook een baas..

[twilex]

Even off-topic maar als ik je naam zie krijg ik gelijk de indruk dat je niet serieus genomen wilt worden

[Vexxon]

Dat is wel een lastige grens die wordt gesteld. Je kan dus wel op 'onderzoek' uitgaan en lekken vinden maar melden is misschien niet zo'n goed idee want tweakers kan dat als strafbaar zien. Met als gevolg dat het lek niet gedicht wordt.
Dat je geen misbruik mag maken van het feit dat je binnen ben gekomen bent is logisch.

[Firefly III]

[..]want tweakers kan dat als strafbaar zien. Met als gevolg dat het lek niet gedicht wordt.

Lol wut. Het ene is echt totaal geen gevolg van het andere. Plus, dat Tweakers het als strafbaar ziet is een door mij gefabriceerd verzinsel dat alleen relevant zou worden in mijn verzinsel als jij Tweakers chanteert met een deadline tot disclosure. Wat dus al totaal niet responsible is waardoor de hele policy uberhaubt niet op zou gaan.

[Vexxon]

Tuurlijk wel.
Als ik een lek vind bij tweakers, maar ik ben er niet helemaal zeker van of ik daar problemen mee ga krijgen (want tweakers kan de wijze waarop ik het lek gevonden heb als strafbaar zien) dan zal ik het wellicht uit zelfbescherming niet melden. En dus zal het lek niet opgelost worden.

Ik heb het nog niet eens over misbruik maken of tweakers.net chanteren. Het gaat mij om het feit dat je als vinder van een lek uit zelfbehoud ervoor kan kiezen om het niet te melden als de grens niet duidelijk genoeg is

[Verwijderd]

Tweakers heeft niet de mogelijkheid iets als strafbaar te zien. Daar is ze niet toe bevoegd. Een rechter beslist dat. Tweakers kan alleen aangifte doen. Het OM kan dan onderzoeken of er sprake is van strafbare feiten. Tweakers kan vinden wat ze willen maar kan als rechtspersoon niet bepalen wat strafbaar is.

[Vexxon]

Je hebt uiteraard gelijk, maar toch is het als melder niet fijn als degene die je probeert te helpen aangifte doet

[regmaster]

Hoezo beperkend? Het is toch niet aan jou om te bepalen of de eigenaar van een site een lek wil dichten? Misschien vind deze het wel een geaccepteerd risico? Ik snap die houding gewoon niet, het is niet jouw site en aangezien T-net nauwelijks tot geen persoonsgegevens bevat lijkt het me niet relevant om lekken in de openbaarheid te brengen als de eigenaren van T-Net niet snel genoeg volgens jou reageren. Of moet je iets compenseren bij jezelf dat je mist?
Dat lekken gemeld kunnen worden is prima maar het is en blijft de verantwoordelijkheid van de eigenaar om er iets aan te doen. Stel dat ik bij jou thuis de deuren weet open te krijgen omdat het hang en sluitwerk niet voldoende is en ik meld jou dat, zou jij het op prijs stellen dat ik dat zou publiceren omdat ik vind dat jij niet snel genoeg het hang en sluitwerk aangepast heb? Zo nee, waarom moet dat van een ander dan wel?

[Webgnome]

Hoezo beperkend? Het is toch niet aan jou om te bepalen of de eigenaar van een site een lek wil dichten?

Dat is deels waar. Het probleem zit hem erin dat wie bepaald of dat iets urgent is? Het is vaak genoeg voor gekomen dat een bedrijf lak had aan de geldende definitie van 'urgent' waardoor mensen onnodig in gevaar gebracht werden.

de melding niet met anderen delen voordat wij een kans hebben gekregen het probleem op te lossen,

Een verlengde hierop. Wordt hier dan een tijd aan gekoppeld?

[Firefly III]

Een bedrijf. Heb je redenen om aan te nemen dat Tweakers zo'n bedrijf is?

[Webgnome]

Nee, niet direct. Maar is dat een reden om het juist niet aan te kaarten?

[Reactie gewijzigd door Webgnome op 24 juli 2024 10:20]

[Vexxon]

Heb je redenen om aan te nemen dat dat niet het geval is?

[Firefly III]

Veertien jaar Tweakers.net en de manier waarop ze met dit soort problemen om zijn gegaan.

[Vexxon]

Successen behaald in het verleden bieden geen garantie voor de toekomst.

[ATS]

Omdat Tweakers data van gebruikers in huis heeft. Data die niet perse van hen, of in elk geval niet aan hen om verder te verspreiden is. Dat heb ik thuis niet. Tweakers (of een willekeurige andere site die data over haar gebruikers beheert) heeft dus een andere verantwoordelijkheid dan een burger met een huis.

[CH4OS]

En daar is de privacy policy voor.

[ATS]

AH, juist. En uiteraard houdt een eventuele hacker zich ook aan die policy, toch?

[CH4OS]

AH, juist. En uiteraard houdt een eventuele hacker zich ook aan die policy, toch?

De privacy policy verteld ook wat Tweakers met de info doet, niet de hacker. Daar had je het immers over, want Tweakers is verantwoordelijk voor de informatie opgeslagen op hun systemen.

[Reactie gewijzigd door CH4OS op 24 juli 2024 10:20]

[CAPSLOCK2000]

Hoezo beperkend? Het is toch niet aan jou om te bepalen of de eigenaar van een site een lek wil dichten? Misschien vind deze het wel een geaccepteerd risico? Ik snap die houding gewoon niet, het is niet jouw site en aangezien T-net nauwelijks tot geen persoonsgegevens bevat lijkt het me niet relevant om lekken in de openbaarheid te brengen als de eigenaren van T-Net niet snel genoeg volgens jou reageren.

Tweakers bevat gegevens over een significant deel van IT-minnend Nederland, inclusief wachtwoorden en e-mail adressen en ook allerlei gegevens van op pricewatch aangesloten bedrijven. Als het belangrijk genoeg is om het te beveiligen dan is het ook belangrijk genoeg om er goed op te passen.
Daarnaast zijn er nog andere kwetsbaarheden zoals de mogelijkheid om malware te injecteren of trackers toe te voegen.

We kunnen discussieren over waar de grens precies moet liggen maar er zijn zeker gevallen te bedenken waarbij het in het algemeen belang is dat een kwetsbaarheid wordt gepubliceerd als de beheerder het probleem niet tijdig oplost. Gezien het enorme aantal amateuristisch beheerde sites op internet vind ik dat je die beoordeling alleen aan de beheerder van site kunt overlaten. Sterker nog, als de beheerder dat gat geen probleem vindt dan is het publiceren daarvan dat toch ook niet?

Overigens ben ik er van overtuigd dat Tweakers boven gemiddeld goed met dit soort zaken om gaan. Dat ze een beleid voor is ontwikkeld zegt een hoop.

[ACM]

Dat is het inderdaad niet de bedoeling, maar wat voor tijdslimiet zouden we kunnen koppelen dan? Want sommige issues zijn nou eenmaal niet triviaal om op te lossen of zijn relatief gezien niet ernstig genoeg om al het lopende werk aan kant te zetten.

Dus een vaste tijdslimiet is gewoon lastig te geven, of het wordt er dan een die zo ruim is dat je er uiteindelijk alsnog weinig mee kan.

[moozzuzz]

Als ze niet ernstig genoeg zijn, dan maakt 't ook niet uit dat ze na x tijd gepubliceerd worden toch?

[ACM]

Dat zal weer per issue afhangen. Als zo'n issue algemeen bekend wordt kan het mogelijk weer wel overlast voor andere gebruikers opleveren.

Stel bijvoorbeeld dat het mogelijk is om via e.o.a. omweg ervoor te zorgen dat iemand niet 1 maar 2 producten aan zijn wenslijst toe te voegen. Ik vermoed dat we zo'n issue niet met versnelde spoed gaan oplossen, maar in een sprint kort na de melding gaan meenemen.

Doordat onze sprints 3 weken duren is al snel mogelijk dat het dan meer dan 6 weken duurt voor het is opgelost.

Het publiek maken van de issue zal voor niemand serieuze gevolgen voor de privacy en dergelijke hebben, maar kan bij uitgebreid misbruik uiteraard wel irritatie opleveren

[Verwijderd]

kijk ook eens op de Google responsible disclosure overwegingen (http://googleonlinesecurity.blogspot.nl/2010/07/rebooting-responsible-disclosure-focus.html), met name het stukje :
Whilst every bug is unique, we would suggest that 60 days is a reasonable upper bound for a genuinely critical issue in widely deployed software.

60 dagen lijkt dus een redelijke tijd voor kritieke issues (die bijvoorbeeld meerdere gebruikers rechtstreeks raken in hun privacy etc.)

[Gomez12]

Dat klinkt leuk, maar dan moet je ook even gaan kijken hoe ermee omgegaan wordt...

Dan zie je dus dat een Google te moeilijk te fixen dingen gewoon helemaal afstoot

[Verwijderd]

Agree, het is een getal. Maar er spreekt wel uit dat er een limiet zit aan disclosure voor kritieke issues. De definitie is een probleem, maar je mag ervanuitgaan dat bij ieder "responsible disclosure" beleid er een maximum zit aan de tijd waarin kritieke issues worden gefixed.
Als voorbeeld zou ik het meer dan normaal vinden dat er binnen 60 dagen een fix is voor een issue waar willekeurige klantgegevens van Tweakers voor iedereen inzichtelijk zijn. Normaliter verwacht ik dat ook Tweakers daar geen problemen in ziet.
Het wordt discutabel als een bug ook gebruikt wordt voor bepaalde commercie-toepassingen, en fixen van die bug rechtstreeks invloed heeft op de 'bottom-line'. Dan kan de gedachte bijvoorbeeld wel eens zijn dat de fix moet worden uitgesteld totdat de 'andere belangen' zijn veiliggesteld. Dan is het goed, en eerlijk, dat een bedrijf vantevoren de tijdslimiet kenbaar maakt.
Het doel van de tijdslimiet is dan ook niet "we fixen het altijd binnen die tijd", maar "wij verplichten ons dat we het issue binnen die tijd fixen, en als we dat niet doen (om wat voor reden) dan is er een stok achter de deur". Dat laatste zal dan in 99% van de gevallen ertoe moeten leiden dat zaken als "de bottomline" op dag 59 vergeten worden, en het issue gewoon wordt gefixed.

[Vexxon]

Offtopic: Nu blijkt al heel snel dat de grens die door Google gesteld is onredelijk is.

Zouden dergelijke issue niet buiten de sprints moeten vallen? Ik kan mij niet voorstellen dat bv. Een ING grote lekken laat zitten omdat niet uitkomt met de sprints. Sommige dingen hebben nu eenmaal een hogere prioriteit dan reguliere sprints lijkt mij. Maar ik heb dan ook geen ervaring met scrum.

[Inspector]

Dat is toch precies wat ACM zegt? Tuurlijk zijn er binnen de bestaande Scrum sprints manieren om issues te escaleren. Voor security fixes met een hoge prio of grote impact zal dit ook zeker gebeuren en zullen deze direct opgepakt worden en buiten de sprint om gepatched en gereleased worden. Echter als het gaat om kleine issues die niet direct een bedreiging vormen kan het tot 6 weken duren daar ze in de reguliere sprint meegenomen worden.

[Vexxon]

Dat ligt dan waarschijnlijk aan mij, maar ik zie dat nergens in zijn post staan.

[moozzuzz]

Goed punt. Maar 6 tot 9 weken voor een niet-kritische bug lijkt me dan wel weer aanvaardbaar. En vooral het heeft een deadline; de huidige policy is daar mi te vaag.

[ACM]

Dat we de melders niet op voorhand een deadline beloven, zegt natuurlijk niet dat er helemaal geen deadlines bestaan.

Daar hebben we - al een paar jaar geleden - een interne SLA voor afgesproken. Die is gewoon nog steeds van kracht.

Ik voel er alleen niets voor om die interne SLA met jullie te delen of daar op gebaseerd weer nog meer en voorwaarden af te spreken. Dan krijgen we weer allerlei nieuwe discussie over de inhoud van onze SLA, wat onder welke situatie en/of uitzondering valt, etc... Of als we dan onze SLA willen wijzigen, moeten we ook deze procedure weer bijwerken, etc.

[Mac_Cain13]

Ja kan prima een termijn invoeren die zegt; zodra het opgelost is of na 30 of 60 dagen. Als jullie het na 90 dagen nog niet opgelost hebben heeft het blijkbaar geen prioriteit en is het ook niet zo erg als het toch publiek wordt. Het mooie is dan dat jullie jezelf ook dwingen om kritieke issues op te pakken en niet onder het vloerkleed te schuiven.

Daarnaast garandeer je de vinder dat hij er na een poosje over kan bloggen etc en hij zijn credits kan pakken. Nog belangrijker; dat voorkomt dat iemand na een paar weken gefrustreerd raakt en het alsnog publiceert terwijl je dat niet weet. Met zo'n termijn weet iemand, laat ik even die termijn afwachten dan mag het daarna gewoon zonder gezeik.

[wjn]

Ja kan prima een termijn invoeren die zegt; zodra het opgelost is of na 30 of 60 dagen. Als jullie het na 90 dagen nog niet opgelost hebben heeft het blijkbaar geen prioriteit en is het ook niet zo erg als het toch publiek wordt. Het mooie is dan dat jullie jezelf ook dwingen om kritieke issues op te pakken en niet onder het vloerkleed te schuiven.

Ik denk ook dat je behoorlijk sterk staat als je een 90 dagen na melding nog bestaand lek publiekelijk maakt.

Dan is het blijkbaar iets om je niet druk om te maken, laat staan een aangifte voor te doen.

[Standeman]

En dat is ook niet zo gek. Problemen kunnen heel simpel zijn en makkelijk te fixen, dan worden ze echt wel adequaat door Tweakers opgepakt. Ik denk dat je een patch eerder in uren kan verwachten dan in dagen.

Echter, als de lek ergens in een 3rd party library zit kan je onmogelijk een tijdsspanne geven waarin dit opgelost wordt. Denk hierbij bijv. aan de heartbleed SSL lek of ergens in het OS van een server. Dit zijn zaken die niet zelf "even" fixed omdat wanneer je met weinig kennis in een SSL library gaat rommelen je meer stuk kan maken dan oplost.
Dan ben je gewoon afhankelijk van de leverancier om het lek te dichten.

[Reactie gewijzigd door Standeman op 24 juli 2024 10:20]

[moozzuzz]

Hoe lang heeft 't geduurd eer heartbleed fixes geimplementeerd waren? 4 dagen.

[Inspector]

Het was "pas" opgelost toen Canonical de fix in de repo van Ubuntu pushte. De security updates draaien we namelijk gewoon altijd op de servers.

[ATS]

Mwah, dat is natuurlijk een keuze. Wellicht een verstandige keuze, maar toch een keuze. Je had ook de gepachde source zelf kunnen compileren in plaats van op Canonical te wachten. Ik zeg niet dat dat verstandig is, wel dat er altijd andere afwegingen te maken zijn.

[Standeman]

4 dagen? Dat heeft wel heel wat langer geduurd hoor!

Friday, March 21 or before - Neel Mehta of Google Security discovers Heartbleed vulnerability.

en

Monday, April 7 10:21:29 - A new OpenSSL version is uploaded to OpenSSL's web server with the filename "openssl-1.0.1g.tgz".

Dik twee weken duurde het voordat een nieuwe SSL versie was. De patch voor de sourcecode was toen niet eens online!

Monday, April 7 09:53 - A fix for the OpenSSL Heartbleed bug is committed to OpenSSL's Git repository (at this point private). Confirmed by Red Hat employee.

Zie ook de timeline van heartbleed.

Punt is, zodra je afhankelijk bent van derde partijen wordt het vrijwel onmogelijk om een harde datum te noemen voor het dichten van het lek (ja, ook met SLA's e.d.).
Zelfs al zit het lek in je eigen code is het verdraaid lastig om hier een standaard "fixed before" datum aan te hangen. Het ligt maar net aan de impact die het heeft op de rest van het systeem.

[Reactie gewijzigd door Standeman op 24 juli 2024 10:20]

[moozzuzz]

Hmm ik dacht altijd dat het 3 april naar buiten gekomen is, maar goed. Er zijn altijd maatregelen mogelijk om de impact van een bug te minimaliseren (uit de gelinkte timeline: eg Cloufare

At that time we had simply removed TLS heartbeat functionality completely from OpenSSL...

Ik versta zeker je punt ivm afhankelijkheid van derden, aan de andere kant is t.net nu geen breinaalden-community maar een website rond techniek. Bovendien zijn dit soort bugs (type heartbleed) niet specifiek voor t.net (waardoor de policy dus sowieso niet van tel is). Bij een volgende bug van de magnitude van heartbleed, hoop ik overigens dat het niet de community is die moet vaststellen dat de website lek is.

[Tha_Butcha]

Inderdaad, hoe vaak worden hier bedrijven niet gefileerd die wel een melding hebben gekregen en daar niks mee deden, totdat het op nieuws sites werd gepost.

Dus als ik het zou melden, zou ik het ook bij tweakers anoniem en via pgp doen.

[The Zep Man]

[...]

Die is behoorlijk beperkend. Daar zou een tijdslimiet aan moeten zitten wat mij betreft. Nu kan Tweakers gewoon zeggen "Ok, ja, je hebt gelijk. We zetten het op de ToDo lijst." en daarmee is de kous af en moet de melder verder zijn mond houden. Dat lijkt me niet de bedoeling.

Een voorbeeld: beveiligingsprobleem gemeld, waar een jaar later nog niets mee gedaan was. Het probleem kon simpelweg (tijdelijk) opgelost worden door een enkel karakter(!) toe te voegen aan de betreffende webpagina, maar moest meer dan een jaar + reacties van gebruikers kosten om het op te lossen. Dat dit een jaar blijft liggen impliceert dat T.net beveiliging niet zo serieus neemt als dat zij claimt.

En in dit geval had ik geen beveiliging doorbroken. Ik had juist beveiliging toegevoegd aan informatie die ik naar T.net verstuur. Dit moest ik zelf doen, omdat bij T.net er niemand geïnteresseerd was om de beveiliging vanuit hun kant te ondersteunen. Ik weet dat er bij T.net veel mensen zijn met hart voor de zaak, maar straal dit dan ook uit als iemand zoiets als dit bloot legt.

Overigens, vergeet dat 'dank je wel' maar. Ik kreeg hier niets voor terug. Niet dat ik er iets voor wil hebben, maar het nodigt niet uit om de volgende keer weer zoiets netjes te melden.

Wat in dit .Plan omschreven wordt (geen tijdslimiet voor T.net) is ook niet bemoedigend. Vanuit een moreel perspectief blijft het beter om zelf (anoniem) de touwtjes van responsible disclosure in handen te nemen, omdat anders het risico op doofpotten bestaat doordat te veel macht bij een enkele partij ligt.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 10:20]

[maniak]

"het niet moedwillig veranderen of verwijderen van informatie" - Ook niet als het je eigen informatie is ter test?

[Evil_Kroki]

Ik vrees dat bezoekers niet echt info bezitten op Tweakers. Alle posts, reviews, etc. die gebruikers maken zijn/worden eigendom van Tweakers

[Herko_ter_Horst]

Onzin, je hebt gewoon auteursrecht op wat je op Tweakers plaatst. Je geeft Tweakers alleen een licentie. Lees artikel 10 van de Algemene Voorwaarden er maar op na.

[Evil_Kroki]

10.4 Door het plaatsen van Content op de Website;
d. doet het Lid, voorzover wettelijk mogelijk, afstand van de op de Content rustende persoonlijkheidsrechten.

[Arnoud Engelfriet]

Dat gaat over een specifiek punt binnen het auteursrecht: je recht op naamsvermelding. Tweakers mag dus bij herpublicatie je naam weglaten. Maar het is NIET zo dat je auteursrechten an sich weg zijn of bij Tweakers liggen. Auteursrechten kun je alleen overdragen met een akte, oftewel een stuk papier met handtekening (art. 2 Auteurswet en 156 Rechtsvordering).

[Evil_Kroki]

thanks voor de verduidelijking!
Geldt dit ook voor de Facebooken en Twitters van deze wereld?

[Reactie gewijzigd door Evil_Kroki op 24 juli 2024 10:20]

[Loller1]

Dat geld voor alles.

[Arnoud Engelfriet]

Ja, dat geldt voor alles. Er wordt vaak gezegd "Facebook eist je auteursrecht op" maar juridisch gezien eisen ze 'alleen maar' een onbeperkt, eeuwig gebruiksrecht. Zeg maar: ze mogen gratis eeuwig wonen in je huis maar worden er geen eigenaar van.

[WhatsappHack]

Totdat je de content verwijderd; tenzij deze content reeds gebruikt is door Facebook; of gekopieerd is door je vrienden.

Toch een klein nuance verschil. Je foto's bijvoorbeeld mogen ze niet meer gebruiken als je ze verwijderd hebt of je hele account verwijderd hebt.

[unglaublich]

Je weet toch wat maniak bedoelt? Als hij een blog-post met het woordje test praat is er toch niets aan de hand?

[FaceDown]

Wat een onzin. Informatie die ik op t.net zet blijft van mij en is niet automatisch eigendom van t.net. Zou mooi worden mbt foto's etc.

[RadioKies]

kuch Facebook kuch
Het kan wel.

[WhatsappHack]

Ook facebook is geen eigenaar van jou foto, hebben enkel een licentie.
Arnoud legt het hierboven al uit.

[nanoChip]

Nee. Zeker niet omdat je niet weet wat de gevolgen zijn. Er wordt niet gevraagd om de website van Tweakers te testen op beveiligingsproblemen. Als je een vermoeden hebt laat het dan a.u.b. aan het ontwikkeld- testteam van Tweakers over om jou vermoedens te controleren.

[svennd]

Als je een systeem penetreert als tweakers kun je vrij zeker zijn als je een "update" doet dat je weet wat de gevolgen gaan zijn. Wat volgens mij kan :

update table blog_posts set user_name="Hax0r" where id=123;

wat duidelijk niet onder dit beleid valt :

update table blog_posts set user_name="Hax0r";

Dit is een beetje een alternatief op wat andere bedrijven doen om bugs te squashen...

[ACM]

Lees de originele tekst, als dat noodzakelijk is om het probleem aan te tonen, dan kan het uiteraard wel. Deze .plan is slechts een aankondiging met wat korte samenvattingen

Als het nodig is om te bewijzen (voor jezelf en/of ons) dat dat mogelijk is, dan zijn inderdaad je eigen gegevens de beste kandidaat om als voorbeeld te gebruiken. Maar daarbij moet je niet meer gegevens gaan wijzigen.

[maniak]

Zit nu op mijn werk, kan moeilijk hele documenten gaan lezen.. dus ik reageerde op de samenvatting

[Triblade_8472]

Heb je de link naar het beleid ook daadwerkelijk gevolgd en gelezen, of ga je alleen van de samenvatting uit?

"Ga het probleem niet misbruiken. Download bijvoorbeeld niet méér gegevens dan nodig zijn om het lek te testen. Verwijder of verander daarbij ook geen gegevens, zeker niet van anderen."

Het gaat over het misbruik van het probleem. Gezien je volgens mij al wettelijk gezien (bijna) volledige zeggenschap hebt over je eigen gegevens, vraag ik mij af of dit specifiek hierin genoemd moet worden.

[MuddyMagical]

Het gaat hier ook beetje uit van common sense denk ik.

Als je de username van 'Femme' weet te wijzigen in 'F3mm3' om aan te tonen dat je write rechten heb gekregen is dat een leuke manier.
Een "DROP tables;" of álle 'e' vervangen door '3' is teveel van het goede.

[Verwijderd]

Hackathon is on!
Wie hacked zich als eerste naar een eervolle vermelding op de frontpage?

[Suli]

Quote uit Responsible disclosure bij nog wat uitzonderingen en punten van aandacht:

Dit is geen uitnodiging om uitgebreid onze site te scannen; dat levert ons overlast op en zullen we daarom actief weren.

[Reactie gewijzigd door Suli op 24 juli 2024 10:20]

[Iblies]

Maar het is net zo goed een vorm van veiligheid.

Indien een onbekend IP in een bepaalde map snuffelt, kun/mag je die 24 uur blokkeren.

Zou wel mooi zijn als iemand die een hack vind een kleine presentie krijgt in de vorm van een bon voor vlaai en een trofee met zijn naam er op. Het zijn geen dingen die de hoofdprijs kosten.

[flipkipse]

Ik zie nog al een belangrijke restrictie in het beleid.

"Verwijder of verander daarbij ook geen gegevens, zeker niet van anderen."

alle gegevens (geen reacties) zijn doorgaans van Tweakers. Wanneer jij wil kunnen testen als je bijvoorbeeld delen van artikelen aan kan passen, pas je gegevens aan van tweakers. Maar als je dat niet doet, kan je nooit het lek testen...

Daarnaast is er een issue tracker? Hoe kan je anders als tweakers bewijzen dat iets al bekend was?

[Reactie gewijzigd door flipkipse op 24 juli 2024 10:20]

[ACM]

Zie voor je eerste deel de reactie van Triblade_8472 en andere antwoorden in die thread.

Als wij zeggen dat het al bekend was zal je daar ons in moeten vertrouwen. Als je dat niet kan of wilt, dan heeft een issue tracker volgens mij verder ook geen nut. Want dan vertrouw je er vast ook niet op dat we de rest van de zaken wel nakomen

[Reactie gewijzigd door ACM op 24 juli 2024 10:20]

[biglia]

Mijn beleid is meestal: zien en zwijgen. Dat brengt me de minste problemen op.

[svennd]

Tot iemand met minder goeie bedoelingen het ziet en je paswoord weet te decrypten plain text lezen....

[mobstaa]

Even kort door de bocht:
Ik mag truckjes als SQLInjection en XSS proberen te gebruiken op Tweakers.net, als ik er maar voorzorg dat ik niets met de data doe en het probleem direct meld bij Tweakers.net?

[ACM]

Zo ongeveer. Hoewel we natuurlijk ook verwachten dat je zo min mogelijk (liefst geen) overlast veroorzaakt voor ons en onze bezoekers

[goedt]

goed idee

[ACM]

Het is nogal frustrerend dat je blijkbaar niet meer serieus genomen wordt als je de week voorafgaand aan 1 april nog iets meldt.

Dit is in ieder geval geen grap (maar ontkennen zal bij jullie ook wel geen zin hebben).

Zelfs als het een grap is zou ik niet begrijpen wat er dan grappig aan is. We zouden onszelf nogal benadelen als we naar melders een antwoord sturen "haha, 1 april!! je krijgt geen beloning, lekker puh" ofzo...

[orange.x]

In zekere zin lijken alle 1 april alarmbellen af te gaan ja. Je kan het ook serieus lezen en opvatten alleen lijkt het op het 1e gezicht gewoon een grap als je er vluchtig over zou lezen. Aan de andere kant had dit niet een week kunnen wachten maar moest het per se net ervoor gepibliceerd worden.

Tweakers kennende worden 1 april grappen wel bijna altijd op 1 april gemaakt. Maar ik had eerlijk gelijk de 1 april grap in mijn hoofd.

[ACM]

Waarom gaan hier je alarmbellen van af dan? Wat maakt het zo grappig? Wat hadden we anders moeten beschrijven dat dat niet zou gebeuren? Of maakt dat gewoon niet uit en is alles dat ergens in de 2e helft van maart uitkomt automatisch verdacht?

Waarom had dit een week moeten wachten? Wij werken nou eenmaal in driewekelijkse sprints en het opstellen van deze tekst en coordineren met ons MT en onze bedrijfsjurist en dergelijke viel nou eenmaal in degene die op 31 maart afloopt... ik had ook tot dan kunnen wachten, maar dat was minder praktisch (en niet eens vanwege 1 april)

[Reactie gewijzigd door ACM op 24 juli 2024 10:20]