Applicaties in Mac App Store moeten vanaf maart in sandbox

Apple wil dat alle apps in de Mac App Store vanaf maart volgend jaar in een sandbox draaien. Oorspronkelijk zou de fabrikant die eis al in november stellen, maar de deadline is verschoven. Sandboxes moeten de veiligheid verbeteren.

De verschuiving van de deadline wordt gemeld op de developersite van Apple. Oorspronkelijk zou de eis vanaf november gaan gelden. Een reden voor het verschuiven van de deadline wordt niet gegeven, maar veel developers hadden kritiek op de eis, meldt TUAW. Waarschijnlijk wordt de sandbox-eis uitgesteld om developers extra tijd te gunnen. In een e-mail aan developers schrijft Apple dat ze tijdelijk een soort ontheffing kunnen aanvragen als ze een app opnieuw moeten opbouwen om aan de eis te kunnen voldoen. Die regeling verdwijnt echter op een niet nader aangeduid tijdstip.

Het draaien van applicaties in een sandbox moet een betere beveiliging bieden. De ontwikkelaar van een app moet aangeven welke rechten deze moet hebben, zoals het accepteren of opzetten van een internetverbinding en het gebruik van de webcam. Voor het lezen en schrijven van bestanden is een aparte deamon ingebouwd: Powerbox, dat een applicatie tijdelijke toegang tot bestanden geeft als een gebruiker daar toestemming voor heeft.

Voor developers betekent sandboxing op Mac OS X dat ze in hun applicaties rekening moeten houden met het nieuwe permissiesysteem, als ze hun applicatie in de Mac App Store willen houden. Ontwikkelaars maken zich echter zorgen omdat de restricties op het lezen en schrijven van bestanden ernstige belemmeringen zouden opleveren. Zo zou het gebruik van AppleScript, dat tot doel heeft om dergelijke taken te automatiseren, minder aantrekkelijk worden. Ook bevat de Powerbox-deamon bugs bij de ondersteuning van de Carbon-api, die C-applicaties toegang biedt tot systeemresources van Mac OS X. Dat stelt Real Software.

Reacties (53)

[morrowyn]

Krijgen we dan 10 popups voor onze kiezen, waar misschien 1% op Not Allow zal drukken?

Lijkt me eerder dat je een mix moet doen, van hoe android permissies werken en opt-out in de settings.

[arjankoole]

Krijgen we dan 10 popups voor onze kiezen, waar misschien 1% op Not Allow zal drukken?

Nee, apple weet dat dat niet werkt. Je kan wel hoger in het systeem instellen wat applicaties per default wel/niet mogen. En uitzonderingen daarop maken. Ideaal voor bedrijven.

[vgroenewold]

Zoals Arjan aangeeft, juist niet... precies dat probleem is in de WWDC aangegeven als de reden waarom beveiliging gewoon niet werkt. Dit proberen ze dus zo op te vangen.

[Anoniem: 340068]

Ontwikkelaars maken zich echter zorgen omdat de restricties op het lezen en schrijven van bestanden ernstige belemmeringen zouden opleveren. Zo zou het gebruik van AppleScript, dat tot doel heeft om dergelijke taken te automatiseren, minder aantrekkelijk worden. Ook bevat de Powerbox-deamon bugs bij de ondersteuning van de Carbon-api, die C-applicaties toegang biedt tot systeemresources van Mac OS X. Dat stelt Real Software.

Nu hopen dat Apple snel de zaakjes in orde heeft, anders zie ik behoorlijk wat devvers er mee stoppen

[arjankoole]

Nu hopen dat Apple snel de zaakjes in orde heeft, anders zie ik behoorlijk wat devvers er mee stoppen

het is 1 partij die klaagt, ik heb nog niemand anders er over gehoord. En bovendien is Carbon al jaren deprecated, ontwikkelaars wordt al jaren verteld om Cocoa te gebruiken (dat is ook 64-bit, wat Carbon niet is).

Dat deze ontwikkelaar hun framework (dat is hun business, lijkt) niet op orde heeft voor Cocoa, lijkt me niets om Apple te verwijten.

[Reactie gewijzigd door arjankoole op 27 juli 2024 21:47]

[Schramowski]

Dat deze ontwikkelaar hun framework (dat is hun business, lijkt) niet op orde heeft voor Cocoa, lijkt me niets om Apple te verwijten.

Het gaat het er niet om wie het te verwijten valt, want het is uiteindelijk de developer die kiest of hij wel of niet voor Mac wil (blijven) ontwikkelen.

[arjankoole]

[...]

Het gaat het er niet om wie het te verwijten valt, want het is uiteindelijk de developer die kiest of hij wel of niet voor Mac wil (blijven) ontwikkelen.

Alleen maakt de developer van een bepaald (commercieel) framework nu de nodige stampij, omdat ze eigelijk gewoon hun eigen zaakjes niet op orde hebben. Uit hun eigen blog:

We realize that our Cocoa framework, in its current state, may not be stable or complete enough for some of your applications. However, we have not stopped working on it and it is improving with each release.

Kortom: wij hebben onze zaakjes niet op orde, maar dat komt allemaal door Apple!

[vgroenewold]

Precies, bovendien heb ik als ontwikkelaar gemerkt dat het vrij simpel te integreren is. Het is even beter nadenken over hoe je bestanden e.d. kan uitwisselen en benaderen, maar ik ben meteen geswitched, ik vind het sandbox idee namelijk uitstekend.

[Wolfos]

Ik gebruik nog steeds Carbon, maar alleen maar voor command line applicaties.
Alleen omdat ik nog niet wist dat je daar ook Cocoa voor kon gebruiken toen ik mijn C++ template schreef.

[Anoniem: 368883]

Waarom? Ze zijn toch niet verplicht om die store te gebruiken?

[kmf]

Het heeft wel de voorkeur als je je app een beetje populair wilt houden/krijgen.

Ik merk dat ik bv eerst in de app store kijk.
Zijn er meerdere apps (in en buiten de store) die hetzelfde doen, dan heeft de instore-app mijn voorkeur.

[Wolfos]

Ik eigenlijk niet, ik Google en kijk daarna pas in de app store.

[Anoniem: 297376]

Als je een app in de store koopt, mag je 'm gebruiken op al je persoonlijke computers (every Mac that you personally own and use.)

Niet op elke computer in je bedrijf, natuurlijk. Daarvoor geldt het 'honor system'. Het kan, maar het mag niet:

While there's no technical impediment to you installing them on multiple Macs at work, you'll be violating the license agreement. It's the same scenario as if you buy a single-user copy of iWork and install it on ten Macs at work—you can do it, but you're violating the license agreement, making the act ethically questionable.

http://www.macworld.com/article/156962/2011/01/mac_app_store_faq.html

Welk bedrijf durft z'n klanten nog zo te vertrouwen?

En als je onverhoopt je app's molt of kwijtraakt, kun je ze kostenloos opnieuw downloaden.

[Reactie gewijzigd door Anoniem: 297376 op 27 juli 2024 21:47]

[Anoniem: 368883]

Kom nu, er zijn genoeg websites die zich bezig houden met OSX software te reviewen. Deze bestonden al lang voor de OSX AppStore, en zullen nog altijd gebruikt worden.

De meeste software die ik op mijn mac heb draaien, heb ik zo leren kennen...

[ronaldmathies]

Wat een overtroken reactie ook meteen. Als iedereen overal zo op reageerde gebeurt er nooit wat.

[Anoniem: 428562]

Alle apps in de appstore zijn toch door apple gescreend waarom is het dan nog nodig ze in een sandbox te plaatsen?

[ronaldmathies]

Screening is niet de broncode bekijken of er gekke dingen gebeuren. De screening vangt een aantal punten en eisen af maar kan natuurlijk nooit alles afdekken.

Daarnaast is de sandbox niet alleen voor de betreffende App. Stel je maakt een browser en bied die via de AppStore aan. Dan heb je nog zoiets als Javascript / Flash / Silverlight / Java applets die erin kunnen draaien.

De sandbox zorgt er dan ook voor dat die apps ook niet zomaar iets kunnen doen. Buiten browsers bestaan er ook zoiets als scripting talen in applicaties. Denk aan macro talen e.d.
die kunnen vaak ook vrij veel. Daar wordt dus ook een extra bescherming aan toegevoegd.

[John]

Apple bekijkt en controleerd de broncode van de applicaties ook.

[ZpAz]

Incorrect je stuurt een binairy op. Er wordt wel gekeken dmv een daarvoor ingerichte server welke api's worden aangeroepen.

[ashemedai]

Gegeven de roots van Mac OS X vraag ik me af of deze sandbox gelijk een FreeBSD jail is.

[arjankoole]

Gegeven de roots van Mac OS X vraag ik me af of deze sandbox gelijk een FreeBSD jail is.

Meer een chroot denk ik. Een jail is meer een compleet afgescherm geheugen voor een mini-versie van het OS. (alhoewel je dat ook voor applicaties kunt gebruiken, wordt het vaak meer voor virtualisatie achtige toepassingen gebruikt, volgens mij)

[ashemedai]

Mmm, ja, da's waar, lijkt me stug dat ze de gemiddelde gebruiker, zelfs via een daemon, willen opzadelen met elke app een mini OS te geven. Een chroot zou dan logischer zijn. Of wellicht zelfs kleine dingen uit het TrustedBSD project overgenomen.

[Anoniem: 264902]

De ontwikkelaar van een app moet aangeven welke rechten deze moet hebben, zoals het accepteren of opzetten van een internetverbinding en het gebruik van de webcam.

Is dit dan vergelijkbaar met Android waar je een popupscherm krijgt met welke rechten een app moet draaien? Of is er al zoiets op iPhone?

[watercoolertje]

Zoals ik het lees is het inderdaad vergelijkbaar met hoe Android het gebruikt Of de melding van de rechten te vergelijken is weet ik trouwens niet, dat weten ze enkel nog bij Apple...

Het idee is dus 1:1 vergelijkbaar als het dat bij Android gaat, of de uitvoering gelijk is kunnen we enkel zien als het zo ver is...

[Reactie gewijzigd door watercoolertje op 27 juli 2024 21:47]

[coptician]

Dat vind ik trouwens een briljant idee, het geeft je echt een gevoel van wat een app kan mis-doen. Altijd een fan van!

[HellFury]

Daar heeft de gemiddelde PC-gebruiker of telefoongebruiker geen behoefte aan... Ik begrijp je mening, en het IS interessant om zulke dingen te weten, maar mijn ouders of grootouders hebben hier geen behoefte aan en zullen het alleen maar zien als een waarschuwing en schrikken bij het minste of geringste terug...

[mashell]

zullen het alleen maar zien als een waarschuwing en schrikken bij het minste of geringste terug...

Dan is daarmee toch het doel bereikt? De gebruiker maakt een afgewogen keuze of deze het wel een goed idee vindt dat een spelletje toegang krijgt tot een adresboek oid.

[BlackOwl]

Daarmee is in sommige gevallen het doel voorbijgeschoten : e-mail aps die geen toestemming krijgen internet op te gaan enzo...

[vgroenewold]

Als ik mij niet vergis moet bij Android de gebruiker de rechten geven, wat eigenlijk nog steeds niet het probleem aanpakt van een gebruiker die standaard op "alles ok" klikt, wat vrijwel iedereen doet. Hier gaat het om dat de developer kiest voor wat een app mag en kan, de gebruiker kan daar verder niets aan veranderen. Apple screened vervolgens of de apps niet onzinnige rechten vragen voor het in de store mag.

[Anoniem: 66451]

Dit artikel gaat over de Mac AppStore. Maar onder iOS heb je ook al zo iets, daar draaien apps voorzover ik weet al sandboxed.

[Metten]

Nee het kan van Apple uit nooit de bedoeling zijn dat de gebruiker geconfronteerd wordt met technische zaken als rechten voor bestandstoegang. Dat soort dingen vinden ze bij Apple juist extreem not-done.

Hoe het precies gaat werken weet ik niet, maar ik zou het echt zeer onwaarschijnlijk vinden dat er voor gebruikers veel gaat veranderen.

[Dreamvoid]

Nee het kan van Apple uit nooit de bedoeling zijn dat de gebruiker geconfronteerd wordt met technische zaken als rechten voor bestandstoegang. Dat soort dingen vinden ze bij Apple juist extreem not-done.

Niet genoeg "not done" om deze optie prominent in de Preference Pane te zetten.

[Schramowski]

"gewone" gebruikers komen niet in het preference pane terecht als het goed is

[Rinzwind]

Sandbox: Een applicatie geef je rechten om bepaalde handelingen te mogen doen (netwerk, camera, bestanden, ...).
Afhandeling van bestandopslag/wijziging wordt opgepikt door een vertrouwd proces/dialoogvenster zodat alleen de gebruiker kan aangeven of in gedeelde bestanden gewijzigd mag worden.

http://arstechnica.com/ap...11/07/mac-os-x-10-7.ars/9

[Obbut]

Van wat ik heb begrepen van de presentaties (voor developers) van Apple is dit geïntegreerd in een soort venster wat nu ook al gebruikt wordt voor bijvoorbeeld opslaan als of openen, waar je je bestand 'aanwijst'. Het op 'Open' of 'Opslaan' drukken in dit venster geeft de app toestemming om daarheen te schrijven. Apps houden onbeperkte rechten in hun library-directory om eigen gegevens op te slaan en te lezen.

[Strokjer2]

Apple moet eens gewoon wat meer openheid verschaffen. Goedkeuring van een app duurt soms ook gewoon een week of twee. En al die voorwaarden.. die voornamelijk ten gunste van Apple zijn..
Als er alleen meer beperkingen komen 'veiligheid' noemen zij het.. zal een 2de muis de kaas pakken.

[Obbut]

Heb jij de iOS app review guidelines ooit gelezen? Zo te zien niet. Die vallen hard mee. Ik ben iOS developer en mag ze niet publiceren, maar er staan echt geen belachelijk rare of strenge dingen in. Ze zijn niet voornamelijk ten gunste van Apple, maar voornamelijk ten gunste van de gebruiker. Die krijgt er een opgeruimde store zonder al te veel meuk en maar half werkende apps voor terug.

[Metten]

En dat ze in het voordeel van de gebruiker zijn moge duidelijk zijn: Voor de appstore bestond had je natuurlijk wel mobiele apps voor symbian en windows mobile, maar die waren vaak dramatisch van kwaliteit. Zowel qua interface design als qua bugs. Om nog maar te zwijgen over de popupschermpjes om bijvoorbeeld een internetverbinding toe te staan op symbian, elke keer dat je een app startte.

De Appstore is juist succesvol geworden door van ontwikkelaars toch een bepaald kwaliteitsniveau te eisen.

[BlackOwl]

Ik vind het eerlijk gezegd al verdacht klinken dat je de iOS app review guidelines niet mag publiceren.

[johnkeates]

Anders ga je gewoon niet voor een appstore ontwikkelen en zeur je er niet over? Het is alsof jij in je eentje het beter zou weten dan een complete multinational... lijkt me stug.

Ga eens bij RIM kijken, om te huilen...

[mashell]

Goedkeuring van een app duurt soms ook gewoon een week of twee

Dat is toch niet lang?

[Anoniem: 297376]

Twee weken (of langer) kan soms lang zijn, bijvoorbeeld als het om een bug fix gaat.

Klanten blijven dan -uiteraard- klagen dat de boel niet werkt, jij hebt de fix allang de deur uit gedaan, maar hij staat nog niet in de store...

[kmf]

Apps buiten de mac store zullen dus nog steeds buiten de sandbox werken?

Ik vind het prima. "alles van de store is veiliger" lijkt de motto.

[Keypunchie]

Ja. Ik denk/hoop dat het model van Apple een beetje gaat worden dat je huis-, tuin- en keukenapps via de store binnenhaalt, maar dat je "poweruser"-apps, waarmee je op systeemniveau wijzigingen moet kunnen maken, via buiten de store kan installeren.

Voor een groot gedeelte van de gebruikers levert dit een betere gebruikservaring en meer veiligheid op.

Zodra het ecther, zoals standaard iOS, helemaal niet meer mogelijk gaat zijn om buiten de Store apps te installeren, dan zou dat een slechte zaak zijn.

Wat dat betreft vind ik Android's benadering, waarbij je via de store apps kunt kopen, maar ook kunt "sideloaden", wat default uit staat, een veel betere. Die benadering is misschien voor OS X ook een goede.

[arjankoole]

Apps buiten de mac store zullen dus nog steeds buiten de sandbox werken?

Dat kan, maar het is goed mogelijk dat ontwikkelaars ook buiten de Mac App Store die methodieken zullen omarmen.

[Anoniem: 190996]

Het hele idee is dat de app box vanuit beveiligingsoogpunt zo aantrekkelijk moet zijn dat je als gebruiker nergens anders heen wilt. Die situatie is nu al aan het ontstaan en Apple zal dat willen vasthouden en uitbouwen.