2011-09-16 13 views
6

Mi chiedo come le applicazioni Metro HTML5/JavaScript saranno impacchettate e protette contro lo storno.In che modo le applicazioni HTML5/JavaScript in stile Metro WinRT sono pacchettizzate e protette

Per il confezionamento Mi aspetto una sorta di firma zip/jar (nessuna menzione su .appx su MSDN), ma per la protezione, al di fuori di offuscamento pesante per JavaScript non riesco a immaginare nessun altro modo (forse un nuovo precompilato/formato binario?)

Se la protezione non è buona, la scrittura di app HTML5/JavaScript non farà prosperare troppo IMHO.

risposta

0

mi chiedevo la stessa cosa e sono d'accordo sul fatto che la criptazione dell'offuscamento sarà fondamentale, sicuramente ai primi tempi della protezione delle app in stile metropolitano.

a quanto pare tutto il codice verrà accuratamente esaminato da parte di MS prima che venga offerto per il download, anche codice offuscato, utilizzando strumenti di scansione del codice. Immagino quanto bene questo funziona resta da vedere. sono sicuro che ci saranno singhiozzi e problemi di sicurezza nei giorni precedenti.

qui c'è una guida abbastanza completa alla sicurezza, che menziona "guard rail" ecc. Che sembrano molto interessanti.

http://www.microsoft.com/download/en/details.aspx?id=27408

rubare Ganly

+0

Ma pensa alle app di Metro distribuite fuori dal Windows Store (o locali/offline) ... Come verrà verificato e protetto il codice? – devstonez

+0

@devstonez Non c'è ancora nessuna storia per "app Metro fuori dal negozio di Windows". –

+0

@pavel Se stai osservando le sessioni di BUILD, potresti vedere che le app possono essere impacchettate per il consumo "locale" risultando un .appx, .cer e un pip per la registrazione del certificato. – devstonez

6

Invece di cripto-offuscamento, un'altra opzione è quella di implementare la proprietaria algoritmi/logica all'interno di un componente WinRT 3rd party. In questo modo, puoi avere la certezza che il tuo algoritmo proprietario è protetto in virtù della sua compilazione. Concesso se si sceglie di implementare in. NET c'è qualche possibilità da parte di qualcuno di decodificarlo.

L'idea è di scrivere il client in JS/HTML5, presumibilmente questo sarebbe un po 'semplice in cui non si dispone di un'enorme quantità di informazioni proprietarie. Quindi scrivi il tuo componente WinRT in C#/C++ che contiene il tuo "processo di produzione di salsicce" proprietario. Si chiama in questo componente WinRT per creare alcune "salsicce" con alcuni dati immessi. Questo approccio significa che la tua ricetta segreta per la salsiccia è sicura, pur continuando a offrirti la semplicità della piattaforma.

È una soluzione appetibile?

+0

Quindi questa sarebbe una libreria di salsiccia collegata in modo dinamico (!)? O mi manca qualche nuovo legame tra JS e una libreria C++? – Bob77

+0

Non sono sicuro di seguire quello che stai chiedendo. Proprio come Windows Runtime fornisce librerie con il sistema operativo stesso, puoi anche scrivere le tue librerie e distribuirle con la tua applicazione. Il componente WinRT può essere scritto in C++ o C#. Questo sarebbe distribuito con l'applicazione ed è richiamabile in modo naturale, proprio come le API di Windows Runtime di 1a parte. –

+0

Scusate, vieni coinvolto nella metafora. Stavo solo cercando di capire se JS avrebbe creato oggetti COM e usando i loro metodi e proprietà o usando qualcosa di nuovo che permettesse di chiamare il codice JS in librerie non COM convenzionali. – Bob77

Problemi correlati