'Stagiair bij Apple was verantwoordelijk voor lekken iBoot-broncode'

Volgens bronnen van Motherboard is een voormalige Apple-stagiair verantwoordelijk voor het ontvreemden van de broncode van de iBoot-bootloader, die van de week op GitHub verscheen. Hij wilde de code alleen met vijf goede vrienden delen voor security-onderzoek.

De stagiair werd volgens het artikel onder druk gezet door zijn vrienden in de jailbreakinggemeenschap. Zij zouden alleen bonafide bedoelingen gehad hebben en niet van plan zijn om de broncode verder te delen. Na verloop van tijd is dit alsnog gebeurd en de mensen die de code in handen kregen, verspreidden deze weer verder. Wie van de vrienden hiermee begon, is niet duidelijk. Motherboard baseert het verhaal op gesprekken met leden van deze vriendengroep en screenshots en sms-berichten van hun gesprekken.

Ook heeft de site code en tools in kunnen zien die niet uitgelekt zijn. Nu het bij Apple duidelijk is waar het oorspronkelijke lek zit, is het onwaarschijnlijk dat deze materialen nog gaan uitlekken.

De code zou in 2016 van Apple gekopieerd zijn en is ergens in de loop van 2017 verder gaan circuleren. In de herfst van 2017 begonnen screenshots van de broncode te verschijnen op Discord-servers van jailbreakers, om anderen mee te plagen. Toen de originele groep vrienden dit vernam, besloot minstens een van de vrienden zijn kopie te verwijderen, om zich te distantiëren van de zaak. Niet veel later verscheen de code op Reddit, maar het kreeg daar nog niet veel aandacht. De bom barstte woensdag pas, toen de code op GitHub verscheen.

De broncode kan inzicht geven in bugs en kwetsbaarheden van iOS, maar de kans is aanwezig dat eventuele interessante ontdekkingen al achterhaald zijn doordat Apple zijn OS in de tussentijd verder heeft ontwikkeld. Apple stelt dan ook dat de veiligheid van zijn producten niet in gevaar is.

Door Mark Hendrikman

Redacteur

10-02-2018 • 13:19

161 Linkedin Whatsapp

Submitter: Anoniem: 63672

Reacties (162)

162
156
100
6
0
27
Wijzig sortering
Hoe dan ook, alle oproepen c.q. verwerkingen van (delen van) de broncode worden uiteraard gelogd; wie, vanwaar, wanneer en waarom een stukje code raadpleegt.

Het is bekend dat Apple een besloten bedrijf is (zo niet absolute geheimhouding vereist) en er derhalve 'n soort interne 'politiedienst' werkzaam is dat lekkages of (mogelijke) overtredingen onderzoekt. Mijn vermoeden is daarom ook dat Apple inmiddels de dader in beeld heeft, zo niet 'n zeer beperkte selectie verdachten. De verantwoordelijke zal gebrandmerkt worden en vermoedelijk een nieuwe carrière mogen verzinnen.
@hEgelia dat is er toch een beetje over, je gedachtengang.
'gebrandmerkt' 'nieuwe carriere'.
je weet niet eens in welk studie gebied hij zich gespecialiseerd, die 'stagair'.
Er zullen wel een hele hoop verschillende soorten stagairs aanwezig zijn in Apple.
Van programmeurs, tot designers, managers, ...
En zonder concrete bewijzen kan de persoon/stagair eventueel apple aanklagen wegens het 'brandmerken' en het fnuiken van z'n toekomstige carriëre.

Neen, Het is vooral een idiote move dat uberhaupt iemand van 'stagair niveau' tot de broncode van het ios is geraakt. Als dat daar maar zo beveiligd is..
Je mag er vanuit gaan dat hij geen toegang had tot die betreffende code als zijn stage-opdracht er niets mee van doen had. Bovendien heeft elke software-specialist op dat niveau bijbel-dikke NDA's. het schenden daarvan (ook al is het met 5 vrienden) kan je in potentie flink gaan kosten.
Dit grapje kan wel eens veel pijnlijker worden dan slechts wat imagoschade en wat lastige vragen bij zijn volgende sollicitatiegesprek. Terecht overigens want broncode stelen van je werkgever is seriously NO GO.

Dat het vervolgens op GIT verschijnt is ook geen 8ste wereldwonder, maar slechts een kwestie van tijd. het is wél een wonder dat het nog een jaar geduurd lijkt te hebben. maar dat zal dan wel aan een zooi egotrippertjes hebben gelegen (zie ook die opmerkingen over screenshots van de code op fora, in het artikel)
Die bijbeldikke nda's en de mogelijke boete hebben niet kunnen voorkomen dat de broncode uitgelekt is.
Een nda of anderzins geheimhoudingsverklaring is googuit een awareness en/of angst middel om zo te proberen bedrijfsongewenst gedrag te voorkomen. Controle over iemands daden is nooit af te dwingen. Als men kwaad in het zin heeft zal een nda niet helpen.
Een NDA werkt alleen maar als de ondertekenende partij slim genoeg is om te snappen dat het willens en wetens breken van de NDA het einde van z'n carrière in tech betekend. Naast een dikke boete en mogelijke gevangenisstraf.

Probleem met een stagiair is dat sommige niet op dat niveau zijn en dus duidelijk de NDA hier geen effect heeft gehad.
Die stagiairs zijn alleen in Cupertino, rest van de wereld neemt Apple in ieder geval geen technische stagiairs aan, dat zijn vooral marketing en verkoopposities.
Met dit nieuws wordt het al iets eenvoudiger natuurlijk om de dader op te sporen. Maar met honderden mensen die regelmatig toegang hebben tot deze code is het niet zo eenvoudig om door de logs te gaan zoeken wie het gedaan heeft, al zeker niet als je niet wanneer exact.

Daarnaast kan het goed zijn dat deze persoon voor zijn werk wel degelijk toegang tot deze code nodig had. En dan is het zelfs geen anomalie meer en wordt het nog een stuk moeilijker om hem/haar op te sporen. Alleen omdat we nu weten dat het vermoedelijk een stagair is wordt het zoekresultaat weer wat overzichtelijker.
Misschien kunnen ze wel achterhalen welke versie/build het exact is en dan valt er nog wel wat te snijden in de lijst van mogelijke verdachten.
Anoniem: 857639
@hEgelia10 februari 2018 18:03
Dan wel niet een flinke geldsom op mogen hoesten.
Dan kan hij of zij wellicht een goede carrière in open source software starten.
Ik begrijp niet helemaal goed hoe het mogelijk is dat een Stagiair in het bezit kan komen van zeer gevoelige broncode in de eerste plaats?

Je zou toch verwachten dat Apple wel iets bedacht heeft om het lekken van dit soort informatie te voorkomen?
Ik begrijp niet helemaal goed hoe het mogelijk is dat een Stagiair in het bezit kan komen van zeer gevoelige broncode in de eerste plaats?
Kan natuurlijk zo geweest zijn dat de stagiair onbedoeld toegang kreeg tot de broncode. Misschien verantwoordelijk voor herinstallatie van ontwikkelmachines, systeembeheerder of als servicedesk medewerkers. Daarnaast is er waarschijnlijk een vrij grote groep van ontwikkelaars, testers en zelfs geautomatiseerde systemen (build-, test- en deployment servers) die toegang hebben tot de broncode.

Overigens heeft Motherboard het zelf niet over een stagiaire, maar een werknemer in een low-level positie. The Verge heeft het wel over een stagiaire. Geen idee of zij meer informatie hebben of gewoon het artikel van Motherboard verkeerd begrepen hebben.
Ook Motherboard spreekt over een stagiair:
“He pulled everything, all sorts of Apple internal tools and whatnot,” a friend of the intern told me.
Op de eerste dag dat ik bij mijn huidige werkgever aankwam heb ik mijn gebruikersaccount gekregen. En met dat account kan ik aan zowat alle data aan die we in huis hebben. Ik kan voor miljarden aan bedrijfsgeheimen stelen en heb nooit een NDA moeten ondertekenen.

Maar ook de stagaires (en dan zitten we niet meer in het IT gedeelte van de onderneming) die soms enkele weken blijven, soms 6 maanden aan 1 stuk krijgen vanaf hun eerste dag toegang tot enorm veel informatie waar je enorm veel schade mee kunt aanrichten. Voor hen is er wel iets meer logging.

Je zou ervan versteld staan in hoeveel bedrijven men enorm veel vertrouwen plaatst in mensen die tijdelijk langskomen om hun skills te verbeteren en de job eigenlijk te leren. En bijna altijd gaat dat goed. Het is in zeer uitzonderlijke gevallen dat je een situatie krijgt zoals hier waarbij het vertrouwen geschaad wordt.

En in een bedrijf als Apple kan ik perfect aannemen dat er stagairs komen die gedurende enkele maanden bepaalde development teams komen versterken. Waarom niet? Geeft hen de mogelijkheid om te leren hoe zulke projecten gemanaged worden en hoe er mee omgegaan wordt en voor het bedrijf kan het nooit kwaad om eens iemand een verse blik op een project te laten werpen. Misschien komt er wel een nieuw, goed idee uit.
NDA staat gewoon in je contract hoor. Bijna elk bedrijf heeft dat er standaard inzitten tegenwoordig. Voordeel in NL is wel, dat zodra ze stoppen met het uitbetalen van je loon. Ze niet meer geldig zijn. Net als die anti-voor-de-concurentie-werken onzin.
Een geheimhoudingsbeding in je contract kan ook na beëindigen van de arbeidsovereenkomst geldig blijven.
In beginsel geldt het geheimhoudingsbeding voor de periode dat de arbeidsovereenkomst van kracht is en ook voor de periode daarna. De werkgever doet er echter verstandig aan dit uitdrukkelijk overeen te komen. Ook een redelijke uitleg van een geheimhoudingsbeding brengt meestal met zich mee dat het geheimhoudingsbeding bovendien geldt voor de periode na het einde van de arbeidsovereenkomst. Voorgaande is van belang omdat juist een ex-medewerker zich schuldig kan maken aan het schenden van de geheimhoudingsplicht. bron

Ik zou bij de volgende keer dat je een arbeidsovereenkomst niet van het standpunt "zodra ze stoppen met het uitbetalen van je loon. Ze niet meer geldig zijn." uit gaan, dat is namelijk niet zo, ook niet voor een eventueel concurrentiebeding, dat kan vervallen, of door een rechter ongeldig verklaart worden, maar dat hoeft lang niet altijd zo te zijn.
Excuses, ik dacht echt dat het allemaal maar weinig voorstelde, zelfs simpel uitzendkracht werk in een kas heeft een geheimhoudingsbeding. Het zit overal. En als het wel geld is half Nederland in overtreding :/
Geheimhoudingsverplichting
Je dient geheimhouding te bewaren over alles wat jou bij de uitoefening van je functie bekend wordt
Nooit meer buiten werk over werk kunnen praten, dat kan toch geen stand houden?
Excuses, ik dacht echt dat het allemaal maar weinig voorstelde, zelfs simpel uitzendkracht werk in een kas heeft een geheimhoudingsbeding. Het zit overal. En als het wel geld is half Nederland in overtreding :/


[...]


Nooit meer buiten werk over werk kunnen praten, dat kan toch geen stand houden?
Reken er maar op dat het stand houd. Geheimhouding kan gewoon worden afgedwongen voor een periode na beëindiging contract. En rechters zijn tegenwoordig niet meer zo coulant tegenover werknemers die concurrentiebeding en geheimhoudingsverklaring bewust naast zich neerleggen. Straffen zijn niet mals.

Bovendien kan je best wel over werk praten, maar even een stuk code delen is een stap te ver. Je kan zeggen "ik heb een oplossing voor dit en dat geschreven en in grote lijnen komt het neer op", maar je kan geen exacte details geven. Houdt er rekening mee, dat wanneer een 3e partij een geheim stuk bedrijfsinformatie kam ontrafelen je al fout zit.
Hangt van het concurrentie beding af... als die bij jou veroorzaakt dat je geen andere baan kunt aan nemen zal de rechter oordelen dat deze onredelijk is. Een geheimhouding is wat anders. Wel moet in een nda een tijds limiet worden aangegeven. Een limiet voor het uitwisselen van informatie en hoe lang dit vervolgens geheim gehouden moet worden.
Klopt, maar je moet het altijd aanvechten. Heb ooit zelf gehad dat ik in een straal van 192km (rare afstand) geen programmeur mocht zijn. Bij nameten was dat dus heel Nederland. Uitspraak van rechter was dat het onwerkelijk was en werd het gehele beding van tafel geveegd. Maar dat kwam doordat het onredelijk was.
Net als die anti-voor-de-concurentie-werken onzin.
Die blijft ook geldig na het beeindigen van je contract tot een bepaalde tijd. Als je een tijdelijk contract hebt is het illegaal om die clausule erin te hebben. Ik had een tijdelijk contract waar die clausule in stond, ik heb hem vrolijk getekend en hen zelfs verteld dat die clausule onzinnig was, maar ze wilden niet luisteren.
Logisch dat ze niet wilden luisteren, het is wel degelijk mogelijk een concurrentiebeding op te nemen in een tijdelijk contract, mits het gepaard gaat met een schriftelijke motivering van de werkgever, waaruit blijkt dat het beding noodzakelijk is vanwege zwaarwegende bedrijfs- of dienstbelangen.
Bron
Wellicht was in jouw specifiek geval de regeling onzinnig, maar met dit soort dingen is het beter goed je huiswerk te doen, dit soort info is relatief eenvoudig op internet te vinden, en te verifiëren aan de hand van de openbare teksten van de diverse wetboeken.
Die schriftelijke motivering, die staat er dus nooit (=meestal nooit) bij, ook in mijn geval niet.
Naast de rechtsgeldige zaken die in een contract staan, is ook jouw interpretatie van belang. Als jij *denkt* dat wat er staat klopt dan zul je daar eerder gevolg aan geven. Genoeg mensen die niet weten dat zoiets totaal onzinnig is, waardoor een werkgever bereikt dat die zich onthouden van dingen die de werkgever onprettig vindt. Zoals gaan werken bij de concurrent aan de overkant van de straat.

Dat jij dan de uitzondering bent die het wel doet is jammer voor het bedrijf, maar absoluut geen reden om alle andere (ex-)werknemers wijzer te maken dan ze al zijn.
Ik vraag me af waarom voor de vaste medewerkers de logging niet op hetzelfde niveau is. Ik zou juist zoveel mogelijk op willen slaan als we het over miljarden hebben en als het toch al mogelijk is. Het is ook niet echt privacygevoelig.
Ja, die opmerking van @Blokker_1999 is ook een beetje onzin: je logt op bestandsnivo; niet op usernivo
Fijn bedrijf. De vraag is dan niet meer óf er een datalek plaatsvindt, maar wanneer. Ben benieuwd hoe ze met de GDPR zullen omgaan.
Een ontwikkelaar zal toch code moet kunnen halen van de repos en hiermee lokaal aan de slag gaan, dus dan is diefstal snel gebeurd. Je kunt wel het hele internet gaan blokkeren, externe drives verbieden, laptops/workstations helemaal op slot zetten en enkele sites gaan whitelisten, maar daar heb je als ontwikkelaar weinig aan en irriteer je je werknemers mee. Een contract en geheimhoudingsverklaring helpt meestal prima met het voorkomen van dit soort zaken, maar 100% onontkoombaar is het niet. Deze stagiair (of de opleiding) krijgt het dus flink met Apple aan de stok, en waarschijnlijk wordt het moeilijk voor deze persoon om nog een baan te krijgen als developer bij bedrijven die niet alles op 't net willen hebben :+
Ik denk niet alleen een probleem als developer. Het lekken van gevoelige informatie wordt nergens op prijs gesteld.
Ja, maar, precies zoals Apple zegt, het is geen gevoelige info. Als de code voldoende doet waar hij voor gemaakt is, en er zitten geen private Keys bij, dan is de waarde vooral educatief.

Het zou kunnen helpen bij een tethered jailbreak, maar dat is zonder code ooit ook al gelukt.

Pas als er de #nsabackdoor in gevonden wordt zijn de poppen aan het dansen.. 😋
Wie zegt dat Apple niet zelf deze broncode heeft uitgelekt om men het gevoel te geven dat er echt geen #nsabackdoor in de bootloader zit, terwijl dat in de echte code misschien zit. #aluhoedje ;-)
Kan die altijd nog aan websites met openbare info gaan knutselen. Daar is dit geen enkel probleem voor.
Anoniem: 890159
@ikt10 februari 2018 13:58
Zolang hij goede ransomwarekan schrijven zijn er altijd mogelijkheden om betaald te programmeren.
Ik zou iemand die geen geheimen kan bewaren niet aanraden om malware te gaan schrijven. Hij mag z’n beweegredenen dan vrij snel aan de FBI en een rechter uitleggen.
Aangezien hij nu de advocaten van Apple achter zich aan heeft kan hij beter niet in Amerika blijven. En er zijn zat landen waar de FBI niks te zeggen heeft en die ook niet meewerken aan hun vuile methoden (of die methoden backfiren, zoals ze nu in Nieuw Zeeland met Dotcom merken).
Natuurlijk, want het is ook zo lekker om je eigen familie en je vrienden en je geboorteplaats nooit meer te zien, omdat je naar een land vluchtte waar ze geen uitleveringsverdrag met de VS hebben.
Altijd nog minder erg dan volkomen de grond in geprocedeerd worden door ht Amerikaanse "rechts" systeem.
"Man up and face the consequences of your actions."
Waarom moet het van een repos naar een lokale machine?
Ik snap dat dogma niet. Het is ooit ontstaan met website bouw en het offshoren downsizen naar lokale machines vanuit een falende ICT op server omgevingen wat betreft support, time to deliver en kosten.

Een te onderhouden versie va een artifact kun je uitstekend server-based op een aparte plek (locked shared use of personal isolated) neerzetten en vandaar naar een te testen object uitrollen.
Het hebben van een goed gedefinieerde versie in productie door een goed release management proces wordt te vaak verward met het neerzetten van een versiebeheertool voor bouwers.

Dat een goede beveiliging een kostenpost is waar bij voorkeur niets aan gedaan wordt omdat het wel werkt, is een vrij gangbaar management prio-stelling.
Bij bijna elk bedrijf is het redelijk eenvoudig om code te kopiëren. Men doet het niet snel maar ik werk bij een bank en ik zou zo code kunnen publiceren. Minder makkelijk van applicaties waar de geld stroom door gaat maar toch.
Zo spannend is die software vaak niet. Dat kun je wel kopiëren maar dat betekent niet dat iemand anders er iets mee kan. Het is vaak maatwerk en specifiek gemaakt voor de processen van dat ene bedrijf.
Als je de processen kent, weet je ook waar de checks en balances zitten. Maatwerk lijkt me juist een voordeel als je kwaadwillend bent.
Klopt het ging me vooral om het feit dat het gemakkelijk te kopiëren is. Een bank lijkt me een goed voorbeeld van een type bedrijf dat z'n geheimen als encryptie/decryptie keys enz niet graag op straat terug vind. Maatwerk is soms ook een reden waarom het makkelijker is om in te breken als ex medewerker of iemand met kennis van zaken.
NDA.
Niet nageleefd.
Stagiair in problemen.
Dat is wat ik verwacht.
dat wordt inderdaad een dure boete :$
En dat terwijl Apple's legal department zich niet realiseert dat de bootmanager juist alleen maar veiliger wordt, nu ze weten dat security by obscurity geen optie meer is. Dat in mijn visie nml de enige reden om zó krampachtig alles bij je te willen houden.

[Reactie gewijzigd door _Thanatos_ op 10 februari 2018 22:16]

Dat is een wassen neus. Je kan niet hard maken dat het openbaar maken van een code de veiligheid absoluut ten goede komt. Er zijn teveel lui (criminelen en geheime diensten) die maar al te graag hun bevindingen voor zich houden en meevaren op de bekendmaking van fouten.
Apple criminalseert het in bezit hebben v/d code. Dat maakt het juist onveilig.
Je hebt helemaal gelijk dat blackhats geen gaten in de code melden aan Apple.
Whitehats doen dat wel maar durven dat nu niet meer omdat Apple die goedwillende mensen keihard juridisch zal aanpakken.
En door die manier van handelen brengt Apple haar gebruikers doelbewust in (potenieel) gevaar.
Het niet openbaar maken van je code zal natuurlijk niets te maken hebben met het risico dat anderen gratis je software nabouwen.
Na misschien omdat de software duur is om constant te upgraden. Nu doen ze dat wel maar als je code openbaar is wordt het toch lastiger om hackers voor te blijven
Ik begrijp niet waar het idee vandaan komt, dat obscurity, ook wel vertaald als onbekendheid in deze betekenis, niet bij zou dragen aan de veiligheid.

Als ik een stuk software nodig heb om een apparaat te laten draaien, en ik heb de code niet en er is om te beginnen al niet aan te komen, moet ik het dus zelf op één of andere manier gaan reverse-engineeren. Of iemand anders het laten doen. Aangezien niet iedere uitzendkracht dit kan, zal dit heel wat tijd en of geld kosten, als het je al lukt / lukt om het uit te besteden.

Voorbeeldje: Als ik een CMS installeer, verander ik de standaard gebruikersnaam en de standaard login pagina. Ik schat dat 99,99% van alle hackpogingen alleen al daardoor strandt.

Absolute veiligheid bestaat niet, maar het wordt een stuk lastiger om bij iemand in te breken als je het adres niet weet dan ook nog de deur niet kunt zien.
Op zich heb je gelijk, security by obscurity is een vorm van veiligheid. Het punt is dat het een antipatroon is. Het probleem ermee is dat je schijnveiligheid creëert: zolang je de voordeur niet ziet, hoef je em ook niet op slot te doen, maar mensen die hem wél kunnen vinden lopen zo naar binnen.

Als je security by obscurity toepast, doe jezelf dan een lol en zorg dat dat niet de enige vorm van veiligheid voor dat specifieke gat is. Zorg ook voor beveiliging die niet omzeild kan worden mochten mensen de deur wél weten te vinden, wat ook buiten jouw medeweten kan gebeuren.
Dan zijn we het eens. Obscurity op zichzelf is niet genoeg, dat lijkt me logisch. Dat is toch met elke vorm van beveiliging?

Alleen een wachtwoord is ook niet genoeg, want dan is het een kwestie van alle combinaties uitproberen. Daarom gebruikt men vaak een combinatie van wachtwoord + tijdslimiet. Dan wordt brute force hacken al een meerjarenplan. Zo stapel je maatregelen om tot een steeds betere beveiliging te komen. Desnoods voeg je een verplicht IP-adres door voor de admin-pagina's. Dat scheelt ook een hoop energieverspilling van de server bij een serieuze poging tot brute-forcen.
Hebben ze ook. Maar met iedere informatie-beveiliging: Als beveiliger moet je alle lekken voorkomen, de aanvallers hoeven maar 1x geluk te hebben.
Ik heb jaren geleden met iemand gesproken die een pasjes systeem voor toegang bij bedrijven installeerd.
Hier in Nederland wordt naar de persoon gekeken waar je wel of geen toegang mag hebben. Dat bedrijf gebruikte een Amerikaans systeem hiervoor en kon niet genoeg codes generen om hier landelijk overal tegelijk toegang te krijgen.
Hij vertelde dat in Amerika vaak maximaal 10 codes, dus niveaus, gebruikt worden. Hierdoor heeft bv management toegang tot alles, niveau daar onder een beetje minder, etc
Het kan dus zijn dat Apple zo’n zelfde simpel systeem gebruikt waardoor de stagair de zelfde rechten heeft als iedere andere werknemer op dat niveau om zijn werk te kunnen doen.
Dat maakt het dan ook zeer lastig zoeken naar de juiste dader.
Stagiair? Waar staat dat precies?
Was gewoon een werknemer.
daarmee proberen ze het minder erg te laten lijken, als in een 'echte' werknemer zou dit niet doen.
Dat maakt het nog veel erger, dan is het onzorgvuldig van een echte werknemer die hem begeleid. Ook die zal hier consequenties van voelen.
Een stagiair is ook gewoon een werknemer vanuit het oogpunt van bedrijven. Het verschil zit hem erin dat de stagiair nog in opleiding is (en dan meestal ook wel verzekerd is voor bepaalde zaken) en dan ook een begeleider heeft, vanuit het bedrijf.

[Reactie gewijzigd door CH4OS op 10 februari 2018 16:41]

Nee, het belangrijkste is vanuut het oogpunt van bedrijven (nagenoeg) gratis werk, en overuren zijn ook enorm goedkoop danwel gratis.
Moet ook gezegd worden dat de kwaliteit van die prestaties vaak ook "niveau gratis" zijn en de meeste stagiairs vergeten ook graag de indirecte kosten die ze meebrengen (begeleiding ed).
In de tekst van het artikel hebben ze het er eenmalig over, misschien dat Tweakers het hierop baseerde:
a friend of the intern told me
Intern is Engels voor stagiair, echter is een intern rol niet persen gekoppeld aan een studie zoals hier. In dit geval zou het kunnen dat de persoon een internship vrijwillig doet, dit betekend vaak dat je veel begeleiding krijgt maar weinig betaald.

In Nederland worden dit soort constructies eigenlijk alleen misbruikt bij Architecten zover ik weet (voor gebouwtjes Enzo bedoel ik dan)
In NGO's is het ook vrij gebruikelijk.
Anoniem: 686983
@Gopher11 februari 2018 09:57
gebouwtjes?
inderdaad, staat gewoon in het artikel:
A low-level Apple employee
Een low-level employee kan nog steeds een stagaire zijn ;)
Het een sluit het andere niet uit

[Reactie gewijzigd door mschol op 10 februari 2018 17:36]

wat weet jij nu over het zeilen binnen apple ... het gaat hier over 1 alleenstaand feit... niet over de algemene gang van zaken...
en jah, in development hebbenok mensen van developmen soms toegang tot zulke dingen, bv tot bepaalde recente broncode, om te kunnen backtracken waarom bijvoorbeeld bepaalde dingen niet werken als hun eigen code iets niet doet wat verwacht wordt..

en low level employee wil gewoon zeggen dat de persoon in kwestie geen leiding-gevende functies heeft... in het grote gros van alle werknemers zijn low level, nietrs mis mee ..
l
Wat is het probleem daar juist mee? Als je low level bent dan ben je dat en so what? Als je een bedrijf hebt met duizenden werknemers moet je ze wel onderverdelen voor beveiligingsdoeleinden alleen al. "Low level" duidt voor mij aan dat hij geen toegang mocht hebben tot de broncode en niet iets denigrerends.

Ik weet dat jullie in Nederland heel handig zijn in sterke benamingen voor low level job functies. Ik dacht dat jullie zelfs wat wij in Belgie gewoon zonder gene een wc-madam noemen jullie daar een sanitair manager of zoiets van maken. Dat romantiseren van low level functies is volgens mij toch echt wel een Nederlands gegeven hoor. Geen kritiek op de Nederlanders erover want het getuigd van creativiteit maar het wekt soms wel eens een lachspier op ook.
Eerste alinea was ik het nog met je eens. 2de alinea ga je ons een beetje lopen discrimineren door te zeggen dat je weet wat zowel gebruikelijk is hoe wij hier omgaan met functie benamingen. Later probeer je het af te zwakken door te zeggen dat je er geen kritiek op hebt. Kom op zeg laat die vooringenomenheid even voor je.
Ik geef je groot gelijk.

Je kan natuurlijk niet alle Nederlanders over een kam scheren, maar ik merk en hoor het in mijn omgeving ook. Nog een voorbeeld: Een schoonmaakster heeft veelal de functie "interieurverzorgster".
Low-level employee kan ook gewoon betekenen dat de werknemer werkte aan de laagste delen van de OS die tegen de hardware/firmware aan ligt. Een senior low level employee zou dus zomaar kunnen, eentje die de software op het ijzer maakt waarvoor je juist een waardevol ervaren iemand voor nodig hebt. In dat geval zegt low-level employee helemaal niets over de pikorde maar over het soort werk.

Low level is een boot procedure zeker, dat moet alles initialiseren en voorbereiden om het OS af te trappen en de eerste stukken van die code moeten vaak ook nog super compact zijn. Er zit nog maar 1 laag onder en dat is de Open Firmware of EFI of wat een Apple ook gebruikt tegenwoordig voor het opstarten van haar producten. Dus dat een low-level employee de code gelekt heeft is in dat opzicht geen gekke gedachte.
Elk bedrijf heeft low level employees.

Als jij in een bedrijf binnenkomt krijg je beperkte rechten, beperkt toegang tot bestanden en beperkte verantwoordelijkheden. Als je opklimt in het bedrijf krijg je 'hoger level, van verantwoordelijkheid met de daarbij behorende toegang. Denk jij echt dat ik elke nieuweling in mijn bedrijven meteen een bedrijfs credit card en toegang tot alle financieele data geef?

In de US is het absoluut niet abnormaal om dat 'low level access' te noemen en je commentaar is daarom absoluut ongepast. Daarnaast is Apple een van de beste firma's om voor te werken als elk jaar weer blijkt bij onderzoek van sites die vacatures ordenen. Apple, Google en Microsoft scoren altijd bijzonder hoog.

Ik begrijp best dat jij geen fan bent van Apple maar als je niets zinnigs te melden hebt, post dan gewoon niets.
Ik weet niet of je wel eens ergens gewerkt hebt, maar in een beetje groter bedrijf is het zonder meer gebruikelijk om onderscheid te maken tussen functies. Low level kan slaan op het loon, de verantwoordelijkheden, de security clearance of gewoon de inhoud van de baan zelf.

[Reactie gewijzigd door mae-t.net op 11 februari 2018 00:40]

Motherboard heeft het over een low level employee. Dit zegt niets over hoe Apple over hun spreekt, maar alleen hoe Motherboard de desbetreffende persoon noemt.
Het kan zijn dat Apple het had over een stagair, maar dat Motherboard daar low-level employee van heeft gemaakt. In de mediawereld worden zulk soort dingen zo makkelijk verdraaid.

Zie jij overigens quote haakjes eromheen staan? Nee, inderdaad, Dus Motherboard kan daar gewoon hun eigen invulling aangeven.
En hierbij blijft toch steeds de mens een zwakke schakel. Eigenlijk zouden ze bij het iedere keer toegang krijgen tot zulke informatie een tag moeten toevoegen zodat ze meteen weten wie de schuldige is. Eigenlijk is het wel heel gemakkelijk om dus zulke info naar huis toe te krijgen.
Anoniem: 890159
@itsalex10 februari 2018 13:54
Een tag bij plain text sourcecode? Hoe wilde je dat doen? Een extra comment in de code als
/* Opgevraagd door werknemer abcd */ ? En je denkt dat dat niet makkelijk verwijderd wordt?
Een beetje versiebeheersysteem houdt bij wie iets in- en uitcheckt en wie iets ophaalt. Dan weet je nog niet wie er heeft gelekt, maar op een personeelsbestand van meer dan 100.000 man zullen er maar weinig zijn die de specifieke code recentelijk hebben geopend. Dat maakt het onderzoek wat makkelijker.
Dat zegt mij alleen maar dat dit echt wel bewust gedaan is, en met bepaalde redenen, en echt niet omdat iemand druk op hem uitoefende.. het ging niet naar 1 maatje, het ging naar 5+ en een community erachter. Hij wist heus wel wat ie deed.
Denk ik ook man, wat gaan 5 mensen uit een jailbreak community doen als ze de broncode krijgen? Precies.
Dat gaat in veruit de meeste gevallen niet helpen. Bij mijn laatste opdracht werkte ik steeds maar aan kleine delen maar ik moest wel alle code uitchecken om het te kunnen bouwen.
Waarmee je aangeeft dat versiebeheersystemen gewoonlijk falen in het isoleren van de artifacts waaraan gewerkt wordt. Men gelooft in de techniek als oplossing en denkt niet na over het proces en alle handelingen met hun impact.
Anoniem: 890159
@karma411 februari 2018 16:26
Nou niet echt, ik werkte aan een Androidapp en moest natuurlijk de hele app bouwen om te kunnen testen of mijn aanpassingen werkten.Anders kon ik alleen maar zeggen "het compileert", maar dat zegt niet veel natuurlijk.
Je kunt met een build systeem prima jouw 20 regels fris ingecheckte code samenvoegen met de rest van de app en vervolgens een package downloadbaar stellen. Dan heb jij geen toegang tot de rest van de broncode van de app nodig hoor. :)
Anoniem: 890159
@Johnsel12 februari 2018 21:40
Ha ja, dat werkt ook zo geweldig ja. We hadden daar een buildserver staan die builds voor het automatische unit en duurtest systeem maakte, maar elke build duurde 20 minuten. Tegen het einde van elke sprint was het file op die machine. Omdat voor elke regel code die je wilt aanpassen te gebruiken is onwerkbaar.
Thanks Johnsel, het stelt wat eisen met realisatie en planningaar dan krijg je ook wat.
Als je de sprints met tijd deadlines leidend laat zijn dan gaat des kwaliteit leiden onder de kwantiteit.
Kga er van uit dat de source ergens in een cms achtig iets staat, met logging danwel check in/out methodiek. Meeste IDE's hebben okk wel zulke functionaliteit, of ondersteunen 3rd party tool die het kunnen.
Beheer van sourcecode zit meestal in een VCS, zoals git of svn. Logging wie, wat, wanneer en vanaf waar bekeek zit daar niet in, iemand die geen toegang nodig heeft tot een repository heeft gewoon de toegang niet, zo simpel werkt het.

[Reactie gewijzigd door CH4OS op 10 februari 2018 16:37]

Het zou op dezelfde manier kunnen als subtitles maar dan voor #comments.
Ik ga ervan uit dat ze ook van alles loggen en al heel snel kunnen zien wie het gedaan heeft.

Je kunt de boel beveiligen zoveel je wilt, maar informatie is 'onzichtbaar'. Als je elke medewerker elke dag moet gaan scannen wordt het onwerkbaar. Dat is altijd het dilemma van de informatiebeveiliging. Ik kan ook bij productiedata als ik wil. Ik heb daar niets te zoeken, maar in het kader van probleemoplossing moet je soms erbij. Dus kan dat. Elke toegang wordt dan wel gelogd, maar dat is dan altijd after the fact. Een systeem waarbij je expliciet toegang moet vragenop basis van een servicedesk call of werkopdracht zou op zich goed kunnen werken, maar dan moet het hele systeem echt soepel lopen. Anders zit je een uur te wachten tot je ergen bij kan terwijl de boel plat ligt. Informatiebeveiliging en werkbaarheid zijn eigenlijk altijd in gevecht met elkaar. Je moet de juiste balans vinden zonder tè paranoïde te worden.

Je moet je mensen kunnen vertrouwen natuurlijk, maar sommige mensen (zoals deze meneer) had in principe geen kwade intenties, maar wel een slecht beoordelingsvermogen. Hij had er natuurlijk op kunnen rekenen dat iemand een keer een steekje zou laten vallen. Heel erg dom van 'm. Maar ja...dat zijn mensen.

Wie een waterdicht systeem kan bedenken dat ook nog prettig werkt mag het zeggen. Die gaat zijn zakken zeker vullen...
Je moet het ook niet kapotbeveiligen maar gewoon fatsoenlijke contracten en NDA's met medewerkers afsluiten. Dat, in combinatie met professioneel gezond verstand, is al voor 99% voldoende.
Misschien is 99% niet voldoende, en was hij de honderdste stagiaire. :)
in dit geval zou je toch verwachten dat zulke gevoelige data toch minstens op encrypted storage staat met DLP, waardoor je exact kan volgen wie wat gekopieerd heeft. Apple is al lang het stadium van garagebedrijfje voorbij
Contracten, afspraken en wetten helpen niet tegen domme mensen of echte kwaadwillenden. Je moet het wel doen, maar tegen iemand die kwaad wil, of zo dom is dat ie denkt dat het wel kan, beschermd het niet. Daarvoor heb je beveiliging nodig, maar dat gaat ook maar zo ver.

Of die 99% gehaald wordt durf ik niet te garanderen.
"Wie een waterdicht systeem kan bedenken dat ook nog prettig werkt mag het zeggen. Die gaat zijn zakken zeker vullen..."
Je noemt het al bijna:
- logging met service accounts voor beheerhandelingen.
- goede controle achteraf op activiteiten met de verantwoording aangebrachte changes.
- terugbrengen in containers (nee niet docker dat is in faal in deze context) van bij elkaar horend artifacts dan wel die een gelijksoortige klassificatie hebben.
- Bij veranderingen en onderhoud alleen die zaken oppakken die veranderd moeten worden. De rest kopieer je niet heen en weer je gebruikt het hooguit. Dat laatste is programmatuur uit productie in bouw gebruiken in combinatie met aangepaste delen. Je voelt de weerstand al.

Daar ga je zeker geen zakken mee vullen. De zakken worden gevuld door het neerzetten van tools omdat iedereen die heeft. Dan de feestjes van succesvolle implementatie van het tool. Het echte doel, ach dat was nu jammer en helaas.
Ik bedoel een systeem dat die ellende voorkomt. Achteraf kun je altijd alles zien, maar dat is te laat. Leuk om die gast op te sporen, maar zoals met dit geval is het kwaad al geschied. Net als weten wie de aanslagplegers zijn als hun aanslag al geweest is en er 100 man dood zijn...
Daar heb je gelijk in.
De consequentie is dat je een veiligheidsdienst een bepaalde ruimte moet bieden.
Wordt hierdoor iOS op Android apparaten mogelijk?
Ja, maar de kans dat het gebeurd is erg klein, hoewel andersom (Android draaien op Apple devices) nu ook tot de mogelijkheden behoort, en daar zullen waarschijnlijk meer geïnteresseerden voor zijn.

[Reactie gewijzigd door 434365 op 10 februari 2018 15:09]

Anoniem: 998261
@43436510 februari 2018 15:53
Waarvoor zou je dat willen? Als je Android wilt koop je een Android telefoon.
Omdat je met een lichter OS langer kan doen met een oude (dure) telefoon?

Ik kan mij daarom goed voorstellen dat een lightweight Android op een iPhone 6 nog goed mee kan komen.

[Reactie gewijzigd door CH4OS op 10 februari 2018 16:44]

Lang niet zo goed als het volledig geoptimaliseerde iOS denk ik. Plus waar ga je je drivers vandaan toveren :P
Het is niet dat veel apparatuur Apple / iOS only is. De CPU natuurlijk wel, maar de rest niet.
CPU, GPU, secure enclave (nxp custom microcontroller), power management ic dus dat wordt nog een aardige klus
praktisch alle rand componenten welk Apple gebruikt in haar toestellen zijn terug te vinden bij bepaalde (android) toestellen. wifi chipsets, DACs, modems, lcd drivers, touch, sensors, cmos camera's et cetera waarvan vaak driver binaries beschikbaar zijn online.

Enkel de cpu/gpu touchID en die show zal een probleem gaan vormen.
Vooral voor de laatste generatie iPhones.

Wellicht haalbaar, maar of er veel animo voor is.. denk het niet

[Reactie gewijzigd door osmosis op 10 februari 2018 23:49]

Anoniem: 998261
@Manke10 februari 2018 15:52
Waarom zou je dat willen? Als je iOS wilt koop je een iPhone.
Wat als je ios wilt met een 6.5" scherm? Of iOS met 3.5mm jack?
"[...] door een aaneenschakeling van de broncode toch delen met personen die tegen de originele intentie in de code weer verder deelden. Wie hiermee begon, is niet duidelijk."

Wel, uiteindelijk was het dus de stagiair, die is er mee begonnen. Wie het verder deelde is niet duidelijk, maar dat is ook niet het belangrijkst, toch?
Jij neemt je "beste" vriend in vertrouwen, hij weer zijn beste vriend en deze weer zijn beste vriend. Voor je het weet, weet iedereen er van.
Beetje naïef om te denken dat je verhaal niet/nooit naar buiten komt.

Weinig mensen zijn dusdanig te vertrouwen dat je "geheim" ook geheim blijft.
Wat een held, jammer dat ze al weten wie het is :)


Wie wilt nu niet in afgsechermde cult cultuur als Apple kijken :P

Niet dat je enorm veelkan met een (2?) Jaar oude bootloader??

[Reactie gewijzigd door Bjorn89 op 10 februari 2018 16:36]

"Zij zouden alleen bona fide bedoelingen gehad hebben"

Boeie, je hebt een contract met een geweldig bedrijf en je weet dondersgoed hoe ze zijn met security en trademark-protection. Het is belachelijk dat je het respect van je contract uit het raam gooit als je toegang hebt tot iets, zodat je het met je vrienden kan delen. Goede bedoelingen of niet, je bent verantwoordelijk voor je positie - en je breekt bewust het contract. Gewoon de consequenties van het breken van het contract toepassen.
Anoniem: 1037073
10 februari 2018 16:38
Daarvoor ben je stagiaire, om te leren. Denk dat deze stagiaire wel iets heeft opgestoken.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee