Delen van broncode Twitter zijn uitgelekt op GitHub

Delen van de broncode van Twitter zijn op GitHub uitgelekt. Dat blijkt uit rechtbankdocumenten over een rechtzaak tussen Twitter en Github. Het is niet bekend wat de grootte van het uitgelekte deel van de broncode is.

De broncode zou al een tijd op GitHub te vinden zijn, maar het is niet duidelijk hoe lang precies. Dat een deel van de broncode was uitgelekt op GitHub, blijkt uit rechtbankdocumenten die als eerste werden opgemerkt door The New York Times. Afgelopen vrijdag liet Twitter aan GitHub weten dat de code daar gepost was, waarna het platform de code direct verwijderde. GitHub heeft het takedown request wel online gezet.

Het bedrijf van Elon Musk wil dat GitHub vrijgeeft wie de delen van de broncode heeft gedeeld en wie het allemaal gedownload hebben. Bronnen melden aan The New York Times dat Twitter denkt dat het om een ex-medewerker gaat die vorig jaar het bedrijf heeft verlaten. Die persoon zou de gebruikersnaam FreeSpeechEnthusiast hebben.

Het management van Twitter is bang dat de uitgelekte code voor beveiligingsproblemen kan zorgen. Op welke manier dat dat het geval zou zijn, is niet bekend.

Reacties (114)

[Verwijderd]

Het argument "security by obscurity" wordt weer veel gebezigd, alsof het publiceren van interne broncode, processen en procedures allemaal maar moet kunnen, en alsof het realistisch is dat je 100% bestand bent tegen een dergelijke disclosure. Dat is nog nooit zo geweest, dat is nu niet zo, en dat gaat ook nooit zo zijn.

Of je het nou leuk vindt of niet, een disclosure van je broncode van enige omvang is rampzalig. Want lang niet al die extra oogjes die (net zoals bij open source?) mee kunnen kijken en securityproblemen kunnen spotten zullen die problemen ook bij jou melden. Dus nu wordt je geconfronteerd met een grote groep experts die jou vijandig gezind is en de broncode van jouw product te pakken heeft. Hoe moet je je daar tegen weren? Door 100% veilig te zijn? Ik heb juist op Tweakers geleerd dat dat nooit kan.

Dat APT's of andere threats "toch wel" binnen komen betekent ook niet dat je het ze makkelijker hoeft te maken, of hoeft te accepteren dat dat zo is. Het is met een reden dat je de broncode van een product niet nodig hebt om toch wel security issues te vinden.

Voor heel veel producten is het geheim houden van de broncode een significante bijdrage aan de veiligheid van het product. Los nog even van alle in-house innovatie en USP's die dergelijke code met zich meedragen die je nu zomaar weggeeft, gratis en voor niks.

Dat Elon Musk roept dat-ie de source openbaar wil maken is gewoon een leugen. Die man liegt zo vaak. Als hij iets openbaar gaat maken wordt het iets niet-relevants zoals de API docs generator of de Twitter app. De core van Twitter gaat nooit significant openbaar worden.

[djwice]

In 2017 hebben we bron code van onze API Gateway laag publiek gemaakt, 40% van de code was nieuwe code van ons.
Binnen enkele weken kregen we pull-requests met security en bug fixes met een waarde groter dan de investering die we gedaan hebben in de API laag.

De code is daarna bij meerdere grote internationale bedrijven geïmplementeerd.

De code is nu onderdeel van het API Gateway product van Google.

Het open maken van de code heeft ons heel veel voordelen gebracht. Onderandere waardering in alle lagen van de organisatie voor de betrokken ontwikkelaars. En heel makkelijk nieuwe super goede ontwikkelaars aan kunnen trekken. En een API laag die tot nu toe geen hack heeft door gelaten. We hebben meerdere keren per week aanvallen.

[miitjohn]

Vermoedelijk is deze reactie op te vatten als: ¨het kan ook voordelen hebben in een andere context¨

En dat is ook zo. Alleen, in jouw voorbeeld werd de code bewust vrijgegeven. Vermoedelijk na de nodige audits en interne afspraken en met de nodige opvolging nadien: dat kan al beginnen met te controleren dat er geen fouten gemaakt zijn bij het vrijgeven zelf. Maar bv. ook: welke feedback krijgen we? Als er een ernstig lek wordt gevonden wordt zal dit ook direct aandacht gekregen hebben.

In dit geval is de source code ongewild gelekt. Dus er heeft geen interne controle plaatsgevonden en men doet ook geen actieve opvolging.

martijn.vw heeft 100% gelijk. Het leaken van source code is een security risico hoe veilig je ook bezig bent. Het is gewoon, als de rest van je security deftig is uitgebouwd een extra layer of defense. Denk ook naar indirecte security zoals Phishing.

[Reactie gewijzigd door miitjohn op 22 juli 2024 14:12]

[djwice]

We hebben geen extra audit van de code gedaan voordat we de code op GitHub hebben gezet. We hadden de code al in productie draaien en daardoor had de code al voldoende standaard controles.

Wel heb ik vooraf een internationale standaard laten vaststellen binnen het bedrijf dat we als organisatie alle wijzigingen die wij doen aan open source tools, libraries, applicaties etc. terug zullen geven aan de gemeenschap onder dezelfde licentie voorwaarden. En dat de ontwikkelaars dat op eigen naam mogen doen (ere wie ere toekomt). En dat de ontwikkelaars in hun profiel kenbaar mogen maken (niet verplicht) dat ze voor ons werken.
In die standaard is ook opgenomen welke open source licenties wij als organisatie accepteren voor intern gebruik, met daarbij dus de terug commit verplichting.

Ook heb ik afgesproken dat de ontwikkelaars elke sprint tijd krijgen om de pull-requests af te handelen. En indien relevant door te voeren naar productie.

Dit werkt nog steeds zo tot op de dag van vandaag. Het voordeel is dat het een zeer volwassen team is, die alle testen automatiseert en meerdere keren per week productie releases (keer honderden API's) heeft en dat onder andere geautomatiseerd alle api input én output parameters test op bekende kwetsbaarheden én ook de kwetsbaarheden lijst test op wijzigingen etc. etc. dat vol automatisch met duizenden nodes tegelijk, zodat in een paar minuten alles door getest is.

En ik ben het zeker met je eens dat het fijt dat we bewust de code publiek hebben gemaakt en dat we altijd mankracht beschikbaar hebben om pull-requests / updates te verwerken we minder risico lopen, wel denk ik dat het testgedrag, de mindset en architectuur ontwerpen van het team doorslaggevend zijn in de reden dat aanvallen tot nu toe altijd zijn afgeslagen.

En aangezien we in het begin direct al de security pull-requests kregen, ook al was de code door al onze procedures en testen heen gekomen, geeft inderdaad aan dat een andere set ogen altijd wel iets kan vinden. Dus ongecontroleerd publiceren van code kan een verhoogd security risico zijn. Al is het alleen al dat een aanvaller kan achterhalen waar de 'duurste' functie zit en hoe je die kunt triggeren, je server zou maar net niet goed kunnen schalen op dat component en je gaat zo onderuit.

[Reactie gewijzigd door djwice op 22 juli 2024 14:12]

[Boy]

Wat een gaaf verhaal! Is daar iets over te lezen op een blog of zo?

[Aldy]

Ik begrijp niet wat mensen tegen open source hebben. Veiliger kan haast niet. Hebben jullie jullie code open source gemaakt of alleen online gezet?

[Mellow Jack]

Beide situaties hebben 2 kanten

Closed source kan veiliger zijn omdat niemand je code kan zien. Het kan ook onveilig zijn omdat het code is vol kwetsbaarheden

Open source kan veiliger zijn omdat je iets ontwikkeld wat gaaf is, veel mensen het willen gebruiken en mensen daardoor actief gaan bijdragen aan de kwaliteit. Het is alleen geen garantie. Het kan ook zijn dat niemand je code bekijkt en daaraan bijdraagt behalve die ene hacker die jou wilt hacken

Of dat ene stukje code, librarie of programmatje wat ooit is verwerkt in bijvoorbeeld Linux distributies waarna de developers ermee zijn gekapt en niemand het meer heeft opgepakt waarna er na 15 jaar ontdekt is dat het flinke kwetsbaarheden bevat.

Eigenlijk is closed en open gewoon vergelijkbaar. Closed is super veilig maar het kost je een hoop geld (bijv externe audits). Open is super veilig mits je een goede community hebt (en je iets doet met de hulp die je krijgt)

[Aldy]

Helemaal mee eens met wat je geschreven hebt, maar als jouw closed source opeens in de openbaarheid komt, dan loopt het volgens mij toch dun je broek.... En dan hoop je maar dat alles goed is dichtgetimmerd. Alhoewel ik niet denk dat dit laatste Elon Musk interesseert, die is met heel andere dingen bezig.

[SunnieNL]

veiliger kan haast niet??
Ik meen mij te herinneren dat er in OpenSSL aardige bugs zaten die er echt jaren in zaten. Dat had niemand opgemerkt. Log4j, nog zo'n voorbeeld van opensource die toch echt niet zo veilig was met mega gevolgen toen er een security probleem in werd blootgesteld.

Open source houdt niet in dat het gelijk veel veiliger is. Net als closed source er niet direct voor zorgt dat iets veiliger is. Open source is zo veilig als de hoeveelheid mensen die zin hebben er naar te kijken. Daarnaast kan het gewoon een bad actor zijn die iets opmerkt en voor zichzelf houdt. Als niemand anders hetzelfde probleem opmerkt is open source net zo onveilig als closed source.

Daarnaast is veel opensource ook weer afhankelijk van closed source libraries en is veel closed source weer afhankelijk van opensource libraries.

[jdh009]

Zeer herkenbaar verhaal en heb vergelijkbare ervaringen meegemaakt. Zowel bij het delen van code zodat iedereen erbij kon als alleen toegankelijk voor (alle) collega’s of met partners/klanten. Kreeg daardoor niet alleen bugmeldingen maar ook suggestie om zaken net wat anders te verwerken zodat het sneller of efficiënter gebeurd. Super fijn en andersom gebeurt het ook nog wel eens als ik zelf iets tegenkom.

Toch merk ik dat bepaalde niche producten of producten waarbij de gebruikersgroep groter is maar minder technische is code niet altijd word gebruikt/gelezen of response terug geeft. Daarbij vraag ik me soms wel af of het handig is om code te delen. De ‘potentiële’ fout zit er natuurlijk al in maar door het publiek te delen is de aandacht die je er aan geeft door het publiek vindbaar te maken mogelijk groter dan het risico dat iemand de bug vind op eigen houtje. Ook kunnen klanten waarvoor je het product schrijft/maakt onwelwillend tegenover het idee van publieke code staan.

Twitter is publiekelijk toegankelijk dus veel features zou je als concurrent, via een gratis gebruikersaccount, kunnen testen en overnemen voor gebruik in eigen software. Iets waar je bij nichemarkten nog wel eens rekening mee moet houden, gezien je de directe concurrent niet wijzer wilt maken. Al denk ik dat dit bij Twitter waarschijnlijk geen obstakel zou zijn gezien ik het idee heb dat enthousiastelingen, (hackers), reclame-/marketingbureaus en journalisten staan te popelen om een keer onder de motorkap te kijken bij dit bedrijf en nu na het lekken van deze code. Ik kan me zo voorstellen dat die groepen graag zouden willen weten hoe o.a. het algoritme precies in elkaar steekt.

Dat kunnen redenen zijn om er voor te kiezen de code niet vrij inzichtelijk te maken. Zoiets is uiteindelijk altijd een afweging tussen voordelen, openheid, belangen en risico’s.

Voor Twitter zal het nu wel te laat zijn om verdere verspreiding tegen te gaan. Ben benieuwd of je als bedrijf dit punt dan zou kunnen gebruiken om de knop om te zetten en het zelf te publiceren. Maakt het ontvangen van feedback een stuk gemakkelijker gezien, iemand die de code nu gezien en iets gevonden heeft, nu actief contact moet opnemen als ze het willen melden. Met ook nog eens het risico dat deze feedback nooit bij de juiste persoon in de organisatie komt.

[Tjidde]

Het enige nadeel is van een platform als Twitter met openbare code is dat er ook mogelijk gespiekt kan worden naar het algoritme. Hier zouden concurrenten, gebruikers en/of reclamemakers misbruik van kunnen maken om of het systeem te gainen. Zodat bijvoorbeeld je op Twitter ineens veel posts ziet van gebruik nu Facebook om traffic weg te halen bij hun.

Voor security zolang je geen extreem domme dingen doet zoals hardcoded wachtwoorden of andere security issues die je als major(of erger) moet het lekken van code geen probleem zijn voor een platform als Twitter. Maar als je dit soort dingen hebt, heb je grotere problemen dan dat iemand je code ziet.

Het feit dat Linux opensource is en de wereld draait op Linux, haalt elk argument onderuit qua security en code in house houden.

Voor games is het wat anders, maar niet als security maar het ontwikkelen van exploits/hacks is wel een stukje makkelijker als je de code hebt.

[NoobishPro]

Dat van Linux is een klein beetje een strawman natuurlijk.

Linux is SUPER oud en relatief simpel. Het is een 'core' waar andere mensen dingen aanbouwen.
Een hoop van deze dingen zijn ook al heel lang 'stable'.

Nu is het zo dat Linux een erg traag ontwikkelend iets is. Er worden geen "onnodige zaken" ingebouwd en het is vooral een kern. Wanneer er dingen nodig zijn, wordt er snel een module gebouwd en deze geïnstalleerd om op said Linux te draaien. Daarvoor wordt Linux zelf niet aangepast. Deze modules zijn vervolgens "Use at your own risk". Je kunt wel stellen dat 'de wereld draait op Linux', maar het draait voornamelijk op een enkel tal van erg populaire modules welke meermaals security issues hebben gehad en ook gefixt moesten worden. Hier zaten behoorlijk serieuze issues tussen. Om te doen alsof dit niet zo is, is óf onoplettendheid óf jezelf voorliegen. Er gaan absolute bakken met geld om in het managen van deze Linux servers, wat voor een groot gedeelte zit in security.

Daarnaast wordt Linux voornamelijk "professioneel" gebruikt (Servers e.d.) en gemanaged door mensen die ook écht heel goed weten wat ze doen. Microsoft's Windows Server is wat dit betreft, debateerbaar, net zo veilig als Linux.

Feit is dat wanneer 99% van de wereld Linux zou gebruiken i.p.v. andersom, die hele security zeer waarschijnlijk ook opeens om zou draaien. Tenslotte is het bijna altijd de schuld van de gebruiker, wanneer er een beveiligingslek is.

Dan hebben we het nog niet eens gehad over hoe 'traag' Linux zich ontwikkeld tegenover de rest van de wereld. Je vergelijkt het hier met programmatuur als Twitter, iets wat onderhevig is aan constante veranderingen en updates. Het moet mee met de tijd. Het dient "simpele" massa's aan gebruikers, niet enkel de professionals.

Ik beheer zelf een vrij groot enterprise product en om deze code openbaar te maken zou één groot beveiligingsrisico zijn. Het product krijgt praktisch wekelijks updates en maandelijks wel één of twee grote nieuwe features. Er worden continu zaken veranderd en hoewel ik graag geloof dat het niet gebeurd en dat alles is afgevangen, vergroot iedere nieuwe feature en update weer de kans dat er een kleine security hole boven water komt. Dit wordt echter grotendeels afgevangen door het feit dat niemand kan zien wat er gebeurt op mijn servers.

zoals de comment waar je op reageerde al stelde (in mijn eigen woorden); 100% security is een pipe-dream. Al helemaal wanneer je andere mensen toestaat om iedere letter van jouw code te analyseren.

TL;DR:

Een traag bewegend, voor professionals bedoeld iets als Linux vergelijken met een super snel ontwikkelend stukje software waar honderden tot duizenden developers aan werken, van niveautje "stagiair" tot "super pro 1337", bedoeld voor een zo groot mogelijke doelgroep, gaat gewoon niet op.

[Aldy]

Dat er in Linux geen onnodige zaken worden ingebouwd, lijkt mij alleen maar een positief punt.
Daarnaast werd er alleen aangetipt dat Linux open source is. Linux werd hier als voorbeeld aangereikt, maar jij gaat in op uitsluitend Linux, terwijl open source toch wel iets meer is, dacht ik. En te beweren dat er geen super pro's werken aan open source is ver bezijden de waarheid.

[NoobishPro]

Oké, sta mij toe even te verduidelijken:

Daarnaast werd er alleen aangetipt dat Linux open source is. Linux werd hier als voorbeeld aangereikt, maar jij gaat in op uitsluitend Linux

Daar ben ik het niet mee eens. Er werd letterlijk gezegd:

Het feit dat Linux opensource is en de wereld draait op Linux, haalt elk argument onderuit qua security en code in house houden.

Linux werd niet aangetipt als voorbeeld. Linux werd gebruikt als argument dat er geen enkele (security-related) reden is om je code niet open-source te maken. Dat is toch écht heel wat anders dan het benoemen als een voorbeeld van een succesverhaal.

En te beweren dat er geen super pro's werken aan open source is ver bezijden de waarheid.

Dit heb ik nooit beweerd. Waar ik specifiek op in ging was:

Het feit dat Linux opensource is en de wereld draait op Linux

En dit, laten we het even de "infrastructuur" van de digitale wereld noemen, wordt wel degelijk gemanaged en gebruikt door professionals.

De gemiddelde Henk om de hoek die Linux heeft omdat het draait op z'n oude pentium 2 of omdat hij denkt dat Bill Gates hem anders in de gaten houdt (minder dan 1% iig) mag dan professional zijn, maar is ook zeer zeker niet van invloed mbt "waar de wereld op draait".

Daarnaast durf ik er bijna geld op te zetten dat deze mensen meer security holes hebben dan gatenkaas ondanks het gebruik van Linux en ook nog eens een user-friendly distro gebruiken in tegenstelling tot waar de pro's mee werken voor zaken "waar de wereld op draait", wat dan wel regelmatig een distro zal zijn, maar niet een windows-like GUI.

In andere woorden; Ik concentreerde me op waar de comment over ging; professionele Linux. Niet de consumenten distro's waar jij het over hebt.

Edit: Sorry, deze vergeten:

Dat er in Linux geen onnodige zaken worden ingebouwd, lijkt mij alleen maar een positief punt.

Daar ben ik het 100% mee eens! Maar dan kom je weer op wat ik ook al in mijn comment aangaf; Dit is voor Linux niet nodig wegens de doelgroep (professionals).
Praktisch mijn hele comment ging erover dat dit dus niet realistisch is voor een evoluerend product zoals Twitter, wat voor de gemiddelde consument is en up-to-date moet blijven. Wat regelmatig feature updates e.d. krijgt. Linux kan er mee weg komen juist omdat het een gigantisch specifiek doel heeft.

[Reactie gewijzigd door NoobishPro op 22 juli 2024 14:12]

[Aldy]

Dat stukje over de pro's was in de laatste alinea:

Een traag bewegend, voor professionals bedoeld iets als Linux vergelijken met een super snel ontwikkelend stukje software waar honderden tot duizenden developers aan werken, van niveautje "stagiair" tot "super pro 1337", bedoeld voor een zo groot mogelijke doelgroep, gaat gewoon niet op.

Maar wellicht heb ik het niet begrepen. Krijg ook mijn quote niet goed.

[Reactie gewijzigd door Aldy op 22 juli 2024 14:12]

[batjes]

Er worden geen "onnodige zaken" ingebouwd en het is vooral een kern.

De dagen dat Linux puur een eenvoudige kernel was, ligt ver achter ons. Er zit zo ontzettend veel meuk in die kernel tegenwoordig. De enorme lading aan drivers alleen al. Of al die meuk voor de cloud platformen.

NT is tegenwoordig een mini-kernel in verhouding met Linux, terwijl dat 20 jaar geleden eerder andersom was.

[kodak]

Alleen al het feit dat we niet weten hoe de code geschreven is zorgt er al voor dat zomaar beweren dat het alleen om een nadeel van spieken naar een algoritme gaat.

Ook valt het niet te bagatelliseren naar als ze maar geen extreem domme dingen gedaan hebben. Want ook gewoon ontwikkelen kan al voor flink wat problemen zorgen. Terwijl je niet alles maar extreem dom kan gaan noemen wat voor problemen zorgt, dat zou te makkelijk zijn.

Dat er opensource bestaat toont niet aan dat aan code die niet geschreven is om te publiceren dus maar weinig risico's geeft. Je kan omgekeerd ook niet stellen dat opensource alleen maar kansen voor een bedrijf als twitter geeft. Risico en kansen zijn namelijk niet voor alles maar gelijk. Zelfs onderling niet.

[Verwijderd]

Het feit dat Linux opensource is en de wereld draait op Linux, haalt elk argument onderuit qua security en code in house houden.

Paar kanttekeningen:
Het bedrijfsleven draait vaak RHEL of Ubuntu, daar krijg je extra software en patches vanuit RedHat, SUSE en Canonical, evenals extensies op software die EoL is. Die krijg je als gratis plebe niet, want je hebt geen toegang tot hun repos zonder een sleutel. Er word ook maandelijks genoeg in Linux gevonden, ook al zijn er zoveel ogen op de broncode.

Voor security zolang je geen extreem domme dingen doet zoals hardcoded wachtwoorden of andere security issues die je als major(of erger) moet het lekken van code geen probleem zijn voor een platform als Twitter.

Dit is erg kortzichtig. Er is meer te vinden dan hardcoded passwords. De wereld en alle developers zijn niet perfect en er zijn wel zwakheden te vinden in code die niks te maken heeft met wachtwoorden. Denk aan een debug header die per ongeluk naar productie is gepusht of een externe package die gebruikt is en een security-probleem heeft.. Serieuze ontwikkelaars laten hun code professioneel auditen. Waarom zou ik als bedrijf wachten tot GitHub-gebruiker Jantje1983 een kritiek lek vindt als ik professionals kan inhuren om problemen te voorkomen?

[YouGotLittUp]

Voor security zolang je geen extreem domme dingen doet zoals hardcoded wachtwoorden of andere security issues die je als major(of erger) moet het lekken van code geen probleem zijn voor een platform als Twitter. Maar als je dit soort dingen hebt, heb je grotere problemen dan dat iemand je code ziet.

Op het moment dat ik je broncode heb kan ik toch gaan zoeken naar bugs in je code om die vervolgens in productie te exploiteren?

[Rabb]

Geen idee waarom Tweakers hier niet over bericht heeft, maar volgens Musk word het Twitter algoritme open source vanaf 31 maart.

https://www.nu.nl/tech/62...evelingen-verbeteren.html

[Rafe]

Dat zullen we maar moeten zien want dat had oorspronkelijk een maand geleden al moeten gebeuren. Vergeet niet dat hij ook al vijf jaar op een rij zegt dat volgend jaar Tesla's compleet zelfstandig kunnen rijden...

[kuurtjes]

Natuurlijk wil je niet dat je broncode op straat ligt.

Maar security by obscurity is ook gewoon een norm die gebruikt wordt zonder dat er zaken publiek moeten zijn. Het is belangrijker dat je bijvoorbeeld services opzet of code schrijft die uiteindelijk gevonden en bezien kan worden door anderen, en dán moet het nog veilig zijn.

[Verwijderd]

Ja dat zal allemaal wel, maar dat is gewoon niet de realiteit. Kan je wel vinden dat dat zou moeten maar het is nu niet zo, is vreselijk moeilijk en voor de meeste organisaties niet haalbaar.

[n4m3l355]

De essentie in security through obscurity zit er natuurlijk wel in dat de code permanent obscure blijft, een zekerheid die geen enkel bedrijf heeft zoals we hier zien. Omgekeerd als men altijd open werkt zoals sommige platformen zal een plotselingen publicatie van diens code weinig effect hebben immers die extra oogjes kunnen altijd meekijken. Ik denk dan ook dat jou argument een reden te meer is om juist niet je code closed te houden. Zeker nu waar we steeds vaker delen code van zelfs grote gerenomeerde bedrijven op straat vinden, is die veiligheid gewoon een desillusie.

Overigens is de reactie van Musk natuurlijk lachwekkend dat Github maar informatie moet prijsgeven wie de code heeft geupload maar nog waanzinniger wie die code gedownload heeft. En wat dan nog, stel je voor dat dit bekend wordt, alsof dit nog verder relevant is.

[Luchtbakker]

Dit zal vermoedelijk nog wel veel vaker gaan gebeuren na alle medewerkers die ontslagen zijn. Je zult nooit exact kunnen achterhalen wie nou wat gelekt heeft.

Dat krijg je als je mensen zonder pardon op straat gooit.

[matty___]

En Musk zei zelf dat Twitter code open source ging maken.

[Luchtbakker]

En Musk zei zelf dat Twitter code open source ging maken.

Je kan, ook Elon niet, een platform zo groot als twitter 100% open source maken. Dat levert voor iedereen een te groot beveiligingsrisico op.

Het kan, maar dan moet je ook mensen hebben die lekken direct kunnen dichten en een bug bounty programma hebben om mensen te stimuleren ze lekken te melden. Dat kost allemaal geld, en dat is waar Elon juist van af wilt.

[rolandlub]

Het bekende security trough obscurity argument.
De enige reden om je code niet openbaar te maken zou het verdienmodel moeten zijn.
Beveiliging zeker niet, je geeft dan eigenlijk al toe dat je het niet voor elkaar hebt.

[HannoOttens]

Goede code én obscurity blijft veiliger dan alleen goede code. Het is veel makkelijker een aanvalshoek te vinden als je exact weet hoe de beveiliging in elkaar zit.

[davince72]

Het hele idee achter "security through obscurity" is dat je denkt secure te zijn, maar omdat het niet out-in-the-open is kan niemand het verifiëren of zwakheden opsporen.
Dus bij closed-source kan het heel goed zijn dat er actief kwetsbaarheden misbruikt worden zonder dat je het weet.

[Caayn]

Opensource is net zo min een garantie dat je geen lekken hebt. Je hebt geen enkele garantie dat een gevonden lek gemeld wordt.

[davince72]

Ik beweer nergens dat opensource geen lekken kent. Alle code heeft kwestbaarheden.
Maar laat je alleen handje eigen developers je code reviewen, of gebruik je daarvoor de community?

[MsG]

De grap is dat bij open source iedereen denkt dat iemand anders de review wel doet, oftewel niemand doet het uiteindelijk. https://www.explainxkcd.com/wiki/index.php/2347:_Dependency is toch veelvuldig waar gebleken.

[davince72]

Daarom is Linux ook zo 'slecht'
Het opensourcen zorgt er niet voor dat automagisch je bugs ontdekt en opgelost worden. Je moet nog steeds zelf zorgdragen dat je code veilig is. Maar het beschikbaar stellen geeft aan dat jezelf vertrouwen hebt (al een pluspunt) en anderzijds dat een willekeurig ander dit kan verifiëren.

[Reactie gewijzigd door davince72 op 22 juli 2024 14:12]

[Caayn]

Ook closedsource kan je laten controleren buiten/naast "handje eigen developers".

[Reactie gewijzigd door Caayn op 22 juli 2024 14:12]

[davince72]

Dat beweer ik toch ook nergens? Ook opensource kun je door israëlisch bedrijf laten PEN testen dus dit is geen onderscheidend verschil dan toch?
Voor nog meer duidelijkheid heb ik in mijn orginele bericht "ander" veranderd in "willekeurig ander" want dat is het idee als je bij opensource refereert aan "ander" die het kan verifiëren.

[Reactie gewijzigd door davince72 op 22 juli 2024 14:12]

[lenwar]

Ik heb precies over dit hele onderwerp jaren lang opbouwende discussies gehad met mensen. Ik vind het hele concept van Open Source vs Closed Source heel interessant.

Mijn persoonlijke visie is dat Open Source niet 'echt' iets toe voegt aan beveiliging. Even los van individuele zaken die over de jaren heen, pas na vele jaren aan het licht kwamen (OpenSSL e.d.), want dat is natuurlijk cherrypicken, dus daar wil ik zeker niet naar refereren. Uitzonderingen houd je altijd (voor beide kanten natuurlijk).

Het gaat mij primair om het feit dat als je je code openbaar maakt, dat in de praktijk vrijwel niemand vrijwillig uren lang gaat zitten spitten door de code heen op zoek naar beveiligingsfouten. De betreffende code is over het algemeen al complex genoeg dat er slechts een handje vol mensen (relatief) die code kunnen lezen, laat staan 'echt doorgronden' danwel echt kunnen interpreteren. Er moet gigantisch veel tijd en geld in gaan zitten om dat te doen.

Ik ben oprecht van mening dat het voor beveiliging veel zinvoller is om je code door meerdere gespecialiseerde bedrijven te laten auditen. Daar haal je veel en veel meer uit dan dat 'de community' er uit zal halen.

Vanuit een maatschappelijk oogpunt ben ik overigens wel heel erg voor Open Source. De code teruggeven aan 'de community' zodat zij er door geïnspireerd kunnen worden om andere (mooie) producten te maken. Ik zie Open Source dan ook niet als 'doel' (wat het voor sommigen lijkt te zijn, ik suggereer niet dat jij er zo in zit voor het geval ), maar echt als maatschappelijk middel.

Vanuit een comercieel oogpunt snap ik dat bedrijven niet zomaar hun code publiek willen maken. Het is de code waar een bedrijf erg veel tijd en energie (en dus geld) in heeft gestoken. Het is dan heel zuur dat jouw directe concurrent even een kopietje maakt van jouw arbeid, een dikkere marketingmolen er tegen aan zet en jouw product uit de markt duwt. Dat is natuurlijk superzuur.

(( En er zijn natuurlijk ook zat bedrijven die code beschikbaar maken, omdat zij weten dat andere organisaties dat nodig hebben om tegen aan te programmeren. Hier heeft het bedrijf dus zelf ook een commercieel belang bij het beschikbaar maken van de code ))

[davince72]

Jammer dat je na jaren opbouwende conclusies niet tot ontdekking komt dat het wel 'iets' toevoegt aan beveiliging ;-)
In eerdere posts heb ik al duidelijk willen maken dat het niet het middel is om code veilig te krijgen. Initieel ging mijn punt over het onterechte gevoel van veiligheid bij security by obscurity.
Maar de discussie kwam elke keer uit op closed vs open
Wat ik belangrijk vind is transparantie. Het idee om te kunnen controleren ipv aan te nemen dat het goed is. Neem als voorbeeld de WOB verzoeken van de overheid. Niet iedereen bekijkt alle info, maar toch zijn er wel eens interessante dingen naar boven gekomen, zoals bizarre declaraties van bewindslieden etc.

Wellicht een gek voorbeeld, maar hopelijk om aan te geven dat er meerwaarde is als je transparant bent over zaken. Alleen claimen dat je veilig bent en het niet aantoont is voor mij een rode vlag.
Daarmee zeg ik niet dat alle code openbaar moet worden, maar we kennen genoeg incidenten uit het verleden (data breaches waarbij persoonlijke data afdoende beschermt is, algoritmes die posts hoger ranken dan anderen , etc, etc) dat het soms een puinhoop is bij partijen die we vertrouwden.

(( En er zijn natuurlijk ook zat bedrijven die code beschikbaar maken, omdat zij weten dat andere organisaties dat nodig hebben om tegen aan te programmeren. Hier heeft het bedrijf dus zelf ook een commercieel belang bij het beschikbaar maken van de code ))

API's beschikbaar stellen is nou niet het beste voorbeeld van open-sourcen. Microsoft deelde vroeger bij windows ook al zijn SDK

[lenwar]

Wat ik belangrijk vind is transparantie. Het idee om te kunnen controleren ipv aan te nemen dat het goed is.

Nou ja. Het stukje transparantie vind ik ook wel een groot goed hoor. Het toont in elk geval aan dat je code 'netjes' is. Althans. De meeste bedrijven zullen dat doen.

Jammer dat je na jaren opbouwende conclusies niet tot ontdekking komt dat het wel 'iets' toevoegt aan beveiliging ;-)

Ik zeg niet 'echt' iets. Het is uiteraard wel een 'iets iets', maar niet echt doorslaggevend voor mij. Het 'idee' dat men het kan controleren op veiligheid van de code vind ik juist weer een beetje richting 'vals gevoel van veiligheid' geven, dus daar trek ik me niet zo veel van aan. Althans. Als het 'alleen' daar op gebaseerd moet zijn.

Neem als voorbeeld de WOB verzoeken van de overheid.

Tegenwoordig zijn dat WOO-verzoeken (Wet open overheid), maar dat even terzijde #muggenziftenmettussenN ;-) . Die WOO-verzoeken zijn denk ik wel een goed voorbeeld. Maar van mij had het ook prima geweest als alleen organisaties met een juridische, journalistieke, enz, enz licentie/registratie de WOO-verzoeken zouden mogen doen. (( Uiteraard meer registraties, maar je snapt wat ik bedoel )).

API's beschikbaar stellen is nou niet het beste voorbeeld van open-sourcen.

Ik doel ook niet (open) API's, maar aan bedrijven die met dat doel hun code beschikbaar stellen. (ook eventueel zaken als 'shared source' projecten vind ik goed idee)

Alleen claimen dat je veilig bent en het niet aantoont is voor mij een rode vlag.

Dit is waar wat mij betreft die auditers naar voren komen. Ik heb persoonlijk meer vertrouwen in 5 audit rapporten die aantonen dat iets "veilig is", dan dat het op Github staat.

En nogmaals. Vanuit een transparantieoogpunt ben ik het helemaal met je eens.


Maar goed. Ik denk dat wij het niet eens gaan worden op dit onderwerp ;-)

[davince72]

Tegenwoordig zijn dat WOO-verzoeken (Wet open overheid), maar dat even terzijde #muggenziftenmettussenN ;-)

Klopt, per 1 mei 2022 heet het WOO, maar mijn aanname was dat dit verwarrend zou werken

Dit is waar wat mij betreft die auditers naar voren komen. Ik heb persoonlijk meer vertrouwen in 5 audit rapporten die aantonen dat iets "veilig is", dan dat het op Github staat.

Helemaal eens, iets op github plaatsen ontslaat niemand om dan niets meer aan veiligheid te doen.
maar eerlijk is eerlijk...welke idioot bedrijf zet zijn code op github zonder gedegen (pen) test(en)?
Ook leuke test: Vraag je security mensen of je de code mag openbaren als ze aangeven dat alles spik en span en veilig is

[lilmonkey]

Het overgrote deel van open source code heeft geen notabiliteit en dus weinig tot geen extra ogen die meekijken. Die community is er alleen voor een beperkt aantal projecten.

[davince72]

Ja dus? Zo werkt het toch met alles. Hoe groter en bekender je bent hoe meer aandacht iets krijgt, dus dat is betrekkelijk zelf regulierend.
Als ik stukje code opensource en niemand gebruikt het en of bekijkt het.....wat is dan het probleem dat er een gigantische bug in zit?
Het gaat hier over Twitter waarvan code is uitgelekt en ze nu bang zijn dat er kwetsbaarheden ontdekt gaan worden......dat is in essentie security by obscurity.....ze maken zich blijkbaar erg ongerust....dan zal de kwaliteit wellicht te wensen overlaten.

[Tjidde]

Het voordeel van open-source is wel dat de kans dat je lek gevonden en gemeld zal worden een stuk groter is. Er zijn best veel developers die bij open-source projecten voor hun plezier code reviews doen.

Als de volledige codebase van Twitter open-source zou zijn, zullen er nog developers dat doen. Al is het maar om hun ego te strelen om te kunnen zeggen ik heb een bug gevonden bij Twitter 🥳

[sspiff]

Voor een platform als Twitter betwijfel ik dit.

De tegenstanders voor zo'n grote platformen hebben geen moeite om door die obscurity heen te raken. Obscurity helpt enkel tegen kleine vissen en hobbyhackers at best.

[Verwijderd]

De tegenstanders voor zo'n grote platformen hebben geen moeite om door die obscurity heen te raken.

Dan hebben ze dus ook nul belangstelling voor de gepubliceerde code en kan deze rechtzaak wel stoppen?

[Tjidde]

Jij denkt dat die code nu van het internet af is?

Meta zal als ze de code willen hebben de code nu al wel hebben. Want toevallig gevonden op het internet.

Als Meta de verplichting krijgt om het te verwijderen, zullen ze dat denk ik wel doen. Maar alle analyse over de code? Dat zal een ander verhaal zijn.

Dat soort bedrijven hebben gewoon mensen in dienst die constant bezig zijn om dit soort dingen te vinden. Via veel tools en bots kan je veel vinden van je concurrent als je de resources hebt.

[RefriedNoodle]

Goede code én obscurity blijft veiliger dan alleen goede code. Het is veel makkelijker een aanvalshoek te vinden als je exact weet hoe de beveiliging in elkaar zit.

Niet per sé.

Ik denk ten eerste dat een ontwikkelaar misschien een andere mindset heeft bij het schrijven van code, als hij weet dat de code publiek wordt en potentieel door de hele wereld gescreend kan worden. Er is geen obscurity om je dan achter te verschuilen. Ik denk dat dit aan het eind van de dag veiligere code oplevert.

Ten tweede gaat het niet alleen om de security van de code, maar ook om het vertrouwen erin. De wereld zal meer vertrouwen in de veiligheid van code hebben, als het inzichtelijk is in plaats van gesloten en blind het woord van iemand (zoals Musk) te vertrouwen.

Obscurity is niet een extra laagje bovenop de beveiliging maar een inherent deel ervan, en het is niet per sé een positief iets. Zie ook Kerckhoff's principle.

[HannoOttens]

Mijn uitgangspunt is wel onder de aaname van gelijke code. Of code beter is als het open source is, is een discussie die ik regelmatig langs zie komen op tweakers.

Ik denk ook dat er twee verschillende definities van obscurity bespreken: Je code niet openbaar maken en zo 'obscure' houden én het maken van een soort obsecure 'puzzel code' die door de onleesbaarheid en verwarring veiliger zou moeten zijn.

Dat tweede zie ik ook zeker als bad practice. Het eerste is wmb geen slechte praktijk.

[Byron010]

Security through obscurity is opzich niks mis mee zo ver ik weet, alleen mag het niet je enigste beveilgingslaag zijn. Zolang je je eerst security zelf in orde hebt (zo goed mogelijk), en vervolgens obscurity toevoegd, lijkt het mij ook alleen toegevoegde waarde te geven,

[svennd]

ATP's gaan wel degelijk achter niet-open broncode (java, adobe, ...) omdat ze dan eenvoudiger exploits kunnen vinden. (0days) Het puur dumpen van code zonder ondersteunende programma's is compleet van de pot gerukt. Er zijn security problemen bij zo'n platform en een rogue ex-employee die zijn deel online gooit is duidelijk niet de manier.

[Maurits van Baerle]

Sowieso kan Twitter niet van de ene op de andere dag alle code open source maken. Een deel van de code zal geen eigendom zijn van Twitter maar gelicenseerd van andere partijen. Die kun je niet zomaar op eigen houtje publiceren zonder toestemming.

[TheVivaldi]

Klopt, maar die kun je wel vervangen door vrije onderdelen, zoals
HP destijds met webOS heeft gedaan toen ze de broncode opensourceden.

[Tjidde]

Je kunt zelfs je code open-source maken zonder alle code van andere zelf al ontwikkeld te hebben.

Stel je gebruikt een stukje code van Oracle dat je gebruikt. Je zou dit stukje code in een aparte methode kunnen zetten. Waarbij je duidelijk aangeeft ik stop er dit in en wil er dit uit.

Bijvoorbeeld :
[HTTPGET]
public GetAllTweetsOfUser(Authuser user){
_Authservice.ValidateUser(user);
}
public ValidateUser(Authuser user){
OracleCode.DoSomething();
return true;
}
Dat dan op GIT (of waar dan ook) de code achter OracleCode niet publiekelijk is, zou geen probleem moeten zijn. Zeker als de documentatie goed op orde is. Zou iemand in de community(of een dev in de toekomst) een open-source variant kunnen ontwikkelen van DoSomething();

Dat zou helemaal makkelijk zijn als OracleCode een interface is, dan zou je eigenlijk gewoon de implementatie kunnen vervangen in de toekomst.

[TheVivaldi]

[...]


Je kan, ook Elon niet, een platform zo groot als twitter 100% open source maken.

Dat zei men ook toen HP aankondigde heel webOS open source te willen maken en eventuele properitiare onderdelen te vervangen door opensource-onderdelen. Maar HP heeft doorgezen waardoor het dus inderdaad 100% open source geworden is. Dus waarom zou het met Twitter dan anders zijn?

[Tjidde]

Als er dingen in je code staan die bij lekken zorgen voor een security issue, heb je slechte code.

Dingen die te maken hebben met security bijvoorbeeld wachtwoorden. Set je met een config file lokaal op de server of iets dergelijks (er zijn 100miljoen manieren en ze hebben allemaal hun voor en nadelen)

Een security issue in je code moet je altijd zien als publieke informatie zeker bij een platform als Twitter. Er zijn mensen die niets anders doen dan proberen de API's/client van grote bedrijven te gebruiken op een manier hoe het niet bedoeld is. Dus je moet elke issue zien als publiekelijk, niet alle mensen die de exploits vinden zullen dit ook melden.

[blorf]

Het ligt aan de methode voor authenticatie. Als Digid open inzichtelijk was, was dat waarschijnlijk geen probleem. Wat naar mijn idee juist een enorme vergissing is, is denken dat het gesloten zijn van je software iets toevoegt aan je veiligheid. Bewijs dat maar eens. Probleempje...

[Reactie gewijzigd door blorf op 22 juli 2024 14:12]

[DamirB]

Alleen het algoritme.

[84hannes]

En zelfs dat zal nooit gebeuren. Zodra het algoritme openbaar is hebben bepaalde partijen maar een paar uur nodig om hun posts zo te schrijven dat ze bovenaan vrijwel alle feeds staan. Dan krijg je een verschrikkelijke race tussen adverteerders en trollen om zoveel mogelijk aandacht te krijgen en binnen weken is Twitter een racistische, gewelddadige SCAM-karikatuur op zichzelf geworden waardoor je terug gaat verlangen naar Twitter hoe het nu is. En verlangen naar hoe Twitter nu is is misschien wel de naarste dystopie die ik me op korte termijn voor kan stellen.

[nallath]

Ik betwijfel dat. Het algoritme kan dan wel open zijn, maar dat wil niet zeggen dat de parameters dat zijn.

[k995]

Het algoritme niet noodzakelijk alles

[HollowGamer]

Nee, hij ging bepaalde algoritmes open source maken.

[SuperDre]

Maar dat geeft (ex)werknemers niet het recht om dan maar zonder toestemming de code te publiceren.

[Verwijderd]

Zover ik begrijp heeft Elon Musk enkel geroepen dat hij de broncode voor de algoritmes wilt opbaren, dus de reden waarom jij zekere tweets wel of niet te zien krijgt.

https://twitter.com/elonmusk/status/1628122949185159168


A new tweet by Twitter owner Elon Musk suggests the company is preparing to open source its algorithm as soon as next week — unless, of course, it’s all a joke. (One never knows these days!) However, Musk has been a longtime proponent of the idea that Twitter’s recommendation algorithm should be open sourced, having repeatedly stated that belief even before he took the helm of the social network and again when announcing his intention to acquire Twitter in April 2022.

Dat is nogal een groot verschil met Twitter in zijn geheel open source willen maken...

[AW_Bos]

Nee, het gaat om het algoritme. Het zal mij niks verbazen als er wat in de functionaliteit gesnoeid zal zijn vanwege bedrijfsgeheimen.

[Verwijderd]

Waarom zou dat niet exact te achterhalen kunnen zijn? Ik neem aan dat ze dit soort dingen uit logs kunnen halen.

"Dat krijg je als je mensen zonder pardon op straat gooit" is ook wel wat kort door de bocht. Zou jij zoiets doen uit wraak? Ik niet hoor.

[MoonRaven]

Account aanmaken met een tijdelijk email adres en uploaden via een openbaar netwerk is altijd een optie.

[Verwijderd]

Maar vanuit het bronsysteem moet je de code nog steeds downloaden of minimaal kopieren. Dat zijn acties die ook gelogd worden.

[Kriekel]

Als het een voormalige programmeur was die de code toch al x maal per dag ophaalde en dat gaat in de log niet opvallen, eventueel de methoden waarop hij de code naar zijn privé computer heeft gehaald. Maar als de dader in de big data zat valt dat ook in het niets met de hoeveelheid data die Twitter verwerkt en analyseert.

[aap]

mensen zonder pardon op straat gooit" is ook wel wat kort door de bocht. Zou jij zoiets doen uit wraak? Ik niet hoor.

Jij niet, maar als je duizenden mensen ontslaat, zit er altijd wel eentje bij die slecht om kan gaan met afwijzing. Net als mensen die hun ex-partner stalken (of erger): de meeste mensen doen dat niet, maar dat wil niet zeggen dat niemand het doet.

[beantherio]

Iemand die bij de sourcecode van Twitter kan komen zal ook wel de knowhow hebben om te weten hoe hij geen sporen moet achterlaten bij het downloaden en vervolgens uploaden van die code bij Github.

[Verwijderd]

Vind dat ook persoonlijk een vreemde strekking, dat je op social media nog negatief uitlaat over je vorige werkgever tot daaraan toe, maar om delen van de broncode te lekken, waarvan niet duidelijk is of dit gevolgen kan hebben voor de gebruikers is gewoon zwaar verkeerd.

Want die persoon heeft niet enkel Twitter en indirect Musk daarmee, maar met name de gebruikers als dankzij deze lekken inbraak tot een account en/of lekken van persoonlijke gegevens hiermee bewerkstelligd kan worden.

[redfightjuh]

Toch eigenlijk belachelijk dat je hier al vanuit gaat.....

Privacy technisch hoop ik niet dat de naam van deze persoon bekend word. rechts technisch weer wel. Lijkt me een ingewikkelde zaak.

[litebyte]

Dat krijg je als je mensen zonder pardon op straat gooit.

Ah..okay, benieuwt hoe dit dan zal gaan bij Google, Microsoft, Amazon en facebook die er recent 50.000 uit hebben gegooid. En zonder pardon is nogal relatief

[CH4OS]

Dit zal vermoedelijk nog wel veel vaker gaan gebeuren na alle medewerkers die ontslagen zijn. Je zult nooit exact kunnen achterhalen wie nou wat gelekt heeft.

Want? De aanvaller die Tweakers aanviel, is uiteindelijk ook in de kraag gebat, dus ik zie niet waarom dat nu niet zou kunnen.

Dat krijg je als je mensen zonder pardon op straat gooit.

Ook hier: waarom? In Amerika kan een bedrijf (Twitter is nog altijd een Amerikaans bedrijf) zelfs mondiaal je per direct de laan uit sturen, daar heeft een bedrijf wat meer vrijheden dan hier in Europa. Dus een 'dat krijg je' terwijl dit in Amerika 'normaal' is, vind ik wat vreemde conclusie.

[Reactie gewijzigd door CH4OS op 22 juli 2024 14:12]

[SuperDre]

Nouja, 'zonder pardon op straat gooien' is nogal overdreven, en het geeft ze niet het recht om code dan maar te publiceren. En het is wel degelijk mogelijk om te achterhalen wie die code geplaatst heeft, en die zal er behoorlijk spijt van krijgen dat die het gedaan heeft. Als je nieuwe werkgever er achter komt dat jij het gedaan hebt dan kun je vaak genoeg ook wel gedag zeggen tegen je baan daar.

[Verwijderd]

Zonder pardon houdt toch in dat diegene die ontslagen is wat misdaan heeft. Zover zou ik nooit durven gaan met dat te schrijven over iemand die niet voor mij werkt of beter gezegd voor mij heeft gewerkt.

Dat de broncode is ontvreemdt en dan publiek gemaakt is wordt tegenwoordig als een soort Robin Hood handeling gezien. Dat is het niet en ik zie het hier als een poging tot het beschadigen en in diskrediet brengen van Twitter.

[jip_86]

Dat krijg je als je mensen zonder pardon op straat gooit.

Of met rancuneuze medewerkers die vinden dat het hun morele plicht is om ongehoorzaam te zijn aan je CEO:

Tweeps that are still employed, at this time:

If your personal situation allows for it, it is your moral duty to disobey. To strike. To protest. To quote tweet Elon when he lies on Twitter. To keep looking after each other.

https://twitter.com/nickrw/status/1592517896731000834

[Verwijderd]

En gelijk hebben ze, met een vijandige madman als CEO, waar ze ook niet voor gekozen hebben.

[jip_86]

En precies daarom word je er zonder waarschuwing uitgetieft

[WillySis]

Mensen zonder pardon op straat gooien is in Amerika normaal. Medewerkers in loondienst hebben daar totaal geen bescherming.

Github moet zeker wel kunnen achterhalen wie de code online heeft gezet. Ze hebben minimaal een e-mailadres en een ip-nummer.

Eigenlijk zou het gebruik van anonieme accounts zo min mogelijk moeten worden toegepast. Wanneer een gebruiker de wet overtreed moet die ook de gevolgen accepteren. De anonieme accounts maken het achterhalen van de personen achter illegale of verboden content flink lastiger. Het internet moet geen vrijplaats worden waar normale wetten niet gelden.

[litebyte]

In de VS (niet Amerika) hebben mensen in loondienst wel enige bescherming, maar de meesten werken op basis van "at-will" en zijn daar ook uitgebreid bekend mee. Daarnaast hebben sommige staten extra bescherming.

[Raymond Deen]

Dat was toch de bedoeling? Of is dit een ander deel van de source?

[Zodiac]

Als Twitter dit zelf had gepubliceerd, dan was het niet uitgelekt.

[Metal spoon]

Volgensmij was de bedoeling dat de source code van het algoritme dat bepaald welke tweets populair worden openbaar zou worden gesteld.

[Bulls]

Vertrouw zulke algoritmes voor geen meter. Ze kunnen op die manier iets “populair” maken omdat ze het willen.

Zoals op Netflix of in de Steam store / PlayStation store iets hoog in de lijst zetten dat het zogenaamd hot is op het moment. En dan niet omdat het daadwerkelijk veel gekocht of gekeken wordt maar omdat ze daarmee de illusie wekken dat het zo is en dan extra verkeer creëren.

[Metal spoon]

Dat is ook precies de reden waarom Elon het openbaar wou maken.

[Loller1]

Het bedrijf van Elon Musk wil dat GitHub vrijgeeft wie de delen van de broncode heeft gedeeld en wie het allemaal gedownload hebben.

Laten we hopen dat Microsoft hier duidelijk op zegt: "None of your business".

Ook een nogal erg ironische/hypocriete vraag komende van een CEO die express interne documenten lekt aan een "journalist" voor zijn "Twitter files" en iedere keer een groot schandaal van die lekken probeert te maken die puure common-sense moderatie tonen...

[Orangelights23]

Laten we hopen dat Microsoft hier duidelijk op zegt: "None of your business".

Waarom moeten we dat hopen? Als er iemand bewust gevoelige informatie zoals sourcecode lekt, is dat strafbaar. Ongeacht het handelen van Elon Musk.

[wiseger]

Het gaat hier om de vraag of MS degenen die de code gedownload moet rapporteren aan Twitter.
Dat de uploader fout zit, daar is geen twijfel over.

[Bender]

Laten we hopen dat Microsoft hier duidelijk op zegt: "None of your business".

Als het duidelijk is dat het illegaal is om te downloaden, waarom zou je dat dan niet delen (na gerechtelijke uitspraak uiteraard).
Wij willen toch ook dat bij illegaal materieel (ik zal het niet verder benoemen) de achterhalen is wie allemaal dat soort dingen op zijn kerfstok heeft?

[Loller1]

Omdat het in de eerste plaats al vaak gewoon niet illegaal is om iets te downloaden. En ten tweede; nadat Musk meer dan een jaar heeft lopen roepen dat hij (delen van) Twitter open source zou maken en zelfs datums daarvoor aankondigde (waarna er niks gebeurde) is het dus juist helemaal niet duidelijk dat het om illegaal materiaal zou gaan.

[Bender]

al vaak gewoon niet illegaal is om iets te downloaden

Hoe kom je daar nou weer bij?
Auteursrechtelijk beschermd materiaal downloaden is illegaal, maar ook zaken als zaken die te maken hebben met 'persoonlijke' aard.

[wiseger]

En hoe zou een downloader van de code moeten weten dat het illegaal was?
Twitter kondigd zelf aan delen van de broncode te publiceren. Delen verschijnen op Github. Belangstellende downloaden dat. En dan blijkt het illegaal te zijn en eist Twitter hun gegevens op.

[Bender]

En hoe zou een downloader van de code moeten weten dat het illegaal was?

Vandaar dat ik het aangeef, als dat in de repo stond of juist weer niet.
Echter is het natuurlijk zo dat je zelden kunt beroepen op het argument dat je het niet wist.

[wiseger]

Daarom is het hier belangrijk dat Twitter zelf aankondigde dat men broncode ging openbaren.
Dat maakt het geloofwaardig dat code beschikbaar komt op Github.
Dat je het niet wist wordt dan ineens wel aannemelijk.

[SuperDre]

Ik mag hopen dat Microsoft dat dus niet doet en gewoon netjes de informatie die zij hebben verstrekken, want het gaat hier om een strafbaar feit.

[wiseger]

Dat de downloaders een strafbaar feit hebben gepleegd is zeer arbitrair. Zeker gezien de eerdere uitlatingen van Twitter.

[kodak]

Het is eerder zeer aannemelijk als de downloader maar het minste vermoeden kon hebben dat deze code gelekt is en je toestemming had moeten hebben van de rechthebbende.

Dat auteursrechtelijk beschermde code online staat is al jaren niet genoeg om aan te nemen dat je het dus maar mag downloaden. Dat gaat net zo goed op voor het meenemen van andermans werk of eigendom wat je in het openbaar tegen komt, dat mag je ook niet zomaar meenemen omdat het kan. Daarbij is overduidelijk dat er tal van gegevens te downloaden zijn waar je de rechten niet over hebt en ook niet van weet of het wel de bedoeling van de eigenaar was dat een ander het online heeft geplaatst. Dus dan kom je waarschijnlijk niet weg met een excuus dat je het niet wist, of graag in eigen voordeel maar aan wilde nemen dat je het wel mocht downloaden. En dat kan oplopen tot flinke schadevergoeding als de eigenaar er werk van maakt en kan aantonen dat jij het gedownload hebt.

[wiseger]

Nogmaals, de rechthebbende kondigde zelf aan om broncode te gaan publiceren. Zo raar is het dan niet om dan te denken dat de code rechtmatig gepubliceerd is.

[kodak]

Het is dan hooguit redelijk om eerst af te vragen of het al publiek is gemaakt. Zeker als een of ander willekeurig account de software online heeft geplaatst zonder duidelijk teken dat de eigenaar dat ook gedaan heeft. Dit soort aannemen in eigen voordeel klinkt vooral als geen zin hebben zelf moeite te willen doen of andermans rechten te willen respecteren.

[wiseger]

Dat kan je omgekeerd ook zeggen van het Twitter dat maar te pas en onpas roept we gaan broncode delen. Die zouden ook wel eens goed mogen nadenken voordat men maar wat roeptoetert.

Als ze dat niet van plan zijn om broncode te openbaren, roep het dan ook niet in de media. Ontstaat er ook geen verwarring of broncode nu rechtmatig gedeeld was of niet.

[kodak]

Er is verschil tussen misschien en zeker. Vaak een bewering doen dat er misschien iets zal veranderen zorgt er hoe dan ook al niet zomaar voor dat het zekerheid geeft. De verwarring bij een downloader alsof misschien dus maar opgevat kan worden als zekerheid is daarmee dan ook onredelijk.

En zelfs al zou er een datum zijn genoemd wanneer ze mogelijk iets zouden doen, dan nog is het je eigen verantwoordelijkheid om dat op tijd te controleren.

Natuurlijk kan je het irritant vinden dat een ander geen zekerheid geeft, maar dat geeft nog niet zomaar minder recht op hun werk of jou recht om hun werk te downloaden.

[crazyboy01]

Ik denk dat de doorsnee Githubber zich dat sowieso totaal niet afvraagt en de downloaders gewoon een stel hobbyïsten zijn die de code wel interessant vonden. Dat maakt het zeker niet minder illegaal om auteursrechtelijk materiaal te downloaden, maar ik denk dat het 'minste vermoeden' vaak oprecht uitblijft en ze zich totaal niet bewust zijn van het zelf illegaal bezig zijn wanneer ze op die downloadknop rammen.

Als je dit van ThePirateBay download ben je je er heel bewust van dat je op een plek zit waar alles niet zo zuiver is, op Github zie ik wel vaker dat mensen er totaal niet mee bezig zijn omdat het zo'n legitieme plek is met allerlei legale projecten. Het voelt allemaal heel onschuldig aan, wat voor projecten het ook zijn. Ik zie trouwens best vaak auteursrechtelijk beschermd materiaal in projecten voorbij komen daar. Of dat nou complete cliënts van games, afbeeldingen, logo's of stukken code zijn. Lijkt ook vaak gedoogd te worden, want soms zijn die projecten al jarenlang actief en vrij populair.

[Aldy]

Dus die fiets die niet op slot stond toen ik hem vond moet ik weer terugzetten?
Maar zelfs als de eigenaar de broncode publiek maakt is het dan de bedoeling dat je dit zonder toestemming van de eigenaar downloadt?

[Slashdotter]

Het bedrijf van Elon Musk wil dat GitHub vrijgeeft wie de delen van de broncode heeft gedeeld en wie het allemaal gedownload hebben.

Github houdt bij wie er allemaal een download doet? Lijkt me sterk... 🤔

[TimDJ]

mogelijk wel een ip log?

[ArachneNet]

Het management van Twitter is bang dat de uitgelekte code voor beveiligingsproblemen kan zorgen. Op welke manier dat dat het geval zou zijn, is niet bekend

Security by Obscurity? Ik neem aan dat er toch geen keys oid in source code staan?

[Bender]

Het openbaar maken van broncode maakt het wel aanzienlijk makkelijker om een beveiligingsissue te kunnen ontdekken.

[Dark Angel 58]

Het openbaar maken van broncode maakt het wel aanzienlijk makkelijker om een beveiligingsissue te kunnen ontdekken.

Dat is waar, maar moeten ze de code niet eerst draaien om de fouten eruit te pikken?
Want code lezen is zeker ontzettend moeilijk, omdat andere delen van de code ontbreken, want ik weet zeker dat de code heleboel verwijzingen heeft. Als ze andere delen van de code ontbreken dan past een puzzel niet meer.

[Bender]

Nee, code hoef je niet persee te draaien.
Als er bijvoorbeeld bekendheden zijn van vulns van packages, of standaard functies, waarvan niet bekend was dat ze gebruikt worden dan weet je door het opzoeken van een naam al waar een mogelijke leak zit.

Maar als je veel programmeert, dan hoef je code niet persee te draaien om het te kunnen lezen en begrijpen wat het doet.
Even als heel simpel voorbeeld, als ik html lees visualiseer ik automatisch in mijn hoofd hoe die html in de browser gerenderd zou worden.

[Aldy]

Het is toch zeer logisch dat als je zoveel duizenden mensen van de ene dag op de andere op straat zet, dat er ongetwijfeld iemand tussen zit die wraak neemt.
Ondanks dat de winstgevendheid omhoog moest, o.a. door minder personeel, wordt Twitter met de dag minder waard.

[crazyboy01]

Het valt natuurlijk wel te verwachten, maar echt logisch vind ik het niet. Dit is dan ook gewoon strafbaar.

[Aldy]

Natuurlijk is het strafbaar, maar zo ga je niet met mensen om. En je kunt erop wachten dat er iemand is die wraak neemt.