Apple, nessuna app al di fuori di App Store: il sideloading è troppo pericoloso

[mmorselli]

Originariamente inviato da giuliop

ma semplicemente perché MS è in posizione dominante.

O meglio, perché è in abuso di posizione dominante. Il successo non è un reato, dipende sempre da come lo raggiungi e da come lo mantieni. Se hai il 99% del mercato, ma ce l'hai solo perché il tuo prodotto è il migliore e non hai creato ostacoli ai tuoi concorrenti che non siano altro che la tua superiore qualità o convenienza, non c'è abuso e non c'è condanna.

I problemi nascono sempre quanto tu metti in atto delle pratiche che ai tuoi concorrenti sono precluse. Per esempio se Microsoft fa un browser il doppio più veloce di tutti gli altri non è abuso, se il browser va veloce il doppio perché usa delle API non pubbliche del sistema operativo è abuso.

[cdimauro]

Originariamente inviato da mmorselli

Perché dovrebbe?

Non chiedermelo a me, ma alle autorità antitrust che comminano sanzioni.

E poi con che metro di misura decido quando un'applicazione è abbastanza avanzata?

Giusto un esempio: quando è in grado di sostituire una parte consistente delle altre applicazioni esistenti che si occupano della stessa cosa?

Dipende sempre da come lo fai. Anche per la questione Windows Media Player il problema non era che Media Player fosse troppo buono (il contrario se mai), ma che non pubblicava le API per comunicare in modo corretto con il suo stesso server multimediale, e quindi altri programmi installati su Windows, come Real Player che diede inizio alla causa, non avrebbero mai potuto raggiungere gli stessi risultati.

Quella delle API private fu una parte dell'accusa, ma a giudicare dalla sentenza nemmeno la più importante, se leggi le notizie dell'epoca.
Ecco qui:
https://www.repubblica.it/online/lf_...7/757/757.html
Infatti Microsoft fu obbligata a rilasciare la documentazione E vendere una versione di Windows senza Media Player.
Estraggo dalla notizia il commento proprio di Real Player al riguardo:

Realnetworks ha detto che la decisione è "molto importante poichè la commissione ue ha formalmente affermato che la strategia di Microsoft di integrare Media Player è illegale e ha posto paletti" anche per il futuro.

Ma anche la parte finale dell'articolo è interessante, e non parla di API e documentazione.

Si, vabbè... senti che razza di argomenti mi tocca sentire. Io ho scritto

"Il fatto che possa eseguire solo software firmato da lei mi pare evidente che sia un blocco, la crittografia è un blocco, e che sia per controllare l'ecosistema, e che sia stato fatto apposta e non per caso"

Ora, come questa frase possa assumere un significato differente scrivendo solo crittografia invece di crittografia a chiave pubblica, mi sfugge. La crittografia a chiave pubblica è il metodo più comune per firmare un file, posso anche lasciarlo sottinteso, ma che cambia?

Cambia che NON è quella che si usa per firmare i file, visto che viene usata per crittografarli.

Non è che scrivi sti messaggi chilometrici solo per dare l'impressione che stai argomentando, sapendo che pochi avranno la pazienza di andare non solo a leggere i tuoi argomenti, ma anche ad andare a verificare a ritroso la corrispondenza con quello che ha scritto il tuo interlocutore?

Non è un mio problema se continui a non capire la differenza fra firma digitale e crittografia (a chiave pubblica o meno, è indifferente: è il concetto che non afferri), come hai dimostrato ancora una volta qui sopra.

Ma quale sistema semplice? Basterebbe fare come Android che ti consente di installare un apk usando "adb install" da linea di comando. Nessun gestore di applicazioni, semplicemente uso le API del sistema operativo che ovviamente devono essere presenti, TOGLIENDO il controllo di firma. Probabilmente in Apple possono già farlo, figurati se loro internamente passano per appstore per testare un'app di sistema.

Cosa non t'è chiaro del fatto che non esista nulla del genere, e che Apple dovrebbe APPOSITAMENTE implementarlo?

Difatti, e te lo ripeto nuovamente, i tool di jailbreak installano un gestore dei pacchetti, altrimenti non potresti farci niente col tuo dispositivo "rootato". Secondo te lo fanno per sport, o perché c'è un'esigenza concreta a riguardo?

Lo ripeto ancora una volta: non ho mai detto che Apple dovrebbe fornire agli utenti un sistema semplice, anzi, se lo facesse andrebbe a diminuire la sicurezza in modo significativo, basterebbe un sistema complicato, ma ufficiale, come quello che fornisce Android.

Il punto è che il jailbreak, usando i permessi di root, mina la sicurezza della piattaforma, com'è scritto in praticamente tutti i pezzi che ho letto a riguardo.

Sul resto ti ho già risposto sopra: non c'è ciò che chiedi, e Apple dovrebbe scriverlo apposta.

Bravo, security by obscurity, tu si che sei un esperto di sicurezza...

Ma infatti non ho mai detto di esserlo, visto che mi occupo di altro.

Ma ho la presunzione di aver DIMOSTRATO, tra l'altro proprio qui un po' di anni fa (in una discussione sull'argomento con Erovitlas_Turbo o qualcosa del genere), che:

un software chiuso è ALMENO "sicuro" quanto uno open.

E per dimostrato intendo alla maniera che insegnano all'università: formulo l'ipotesi, poi la tesi, e infine fornisco una dimostrazione.

Per cui scusa la falsa modestia, ma se un esperto in sicurezza mi venisse a dire che no, un sistema aperto è più "sicuro" (notare sempre le virgolette) di uno chiuso, dall'alto (è qui la mia falsa modestia) del mio teorema io non posso che farmi delle grasse risate.

Se sei interessato vatti a ricercare la discussione in oggetto.

Il programma open source è più sicuro di quello closed, perché il controllo viene fatto da molte più persone.

Peccato che la "sicurezza" è una proprietà intrinseca del software, e NON dipende dal numero di occhi e controlli sul codice che possano essere fatti, come ho dimostrato nel mio teorema.

Poi ciò che riporti è la cosiddetta "Legge di Linus" che è stata formulata da Eric Raymond nel suo libro "La cattedrale e il bazaar".

Ovviamente non ha alcunché di legge, non ha dimostrato nulla: si tratta di una semplice asserzione, e basta.

D'altra parte è banale mettere in evidenza che il fatto che ci siano tanti occhi a guardare dei sorgenti non vuol dire necessariamente che si trovino falle in esso, o che la probabilità di trovarne aumenti, visto che non si fa nemmeno assunzione sulle qualità / professionalità degli osservatori. Si tratta, dunque di idee che il soggetto in questione s'è fatto. Idee e basta.

Nulla a che vedere con la forza di un teorema, quale il mio.

Quando un cracker trova un exploit in un programma open source lo trovano anche gli altri,

Peccato che questa sia una tua asserzione priva di fondamento, che non hai dimostrato, non ha dimostrato Raymond, e nemmeno sarete mai in grado di dimostrare.

Ma la tesi è tua (perché tu l'hai qui esposta), dunque: accomodati pure.

perché è un'operazione semplice, alla portata di tante persone, mentre quando lo trova in un programma closed source di norma se lo tiene per sé o lo fa girare a pagamento negli ambienti underground, perché si tratta di una scoperta complessa o fortuita alla portata di poche persone.

Di norma chi? Non lo sai che gli exploit vengono anche fatti girare nell'ambiente dark, spesso a pagamento? Ci sono cracker che vendono addirittura toolkit belli e pronti.

Lo vedi che continui a parlare di cose che non conosci, soltanto per difendere la tua traballante tesi?

Tra l'altro mentre nel programma open una persona può verificare come viene fatta una certa cosa anche solo per tranquillità personale,

E infatti si vede com'è finita con il mitico bug di OpenSSL, che è stato trovato dopo ANNI.

Ed è finita che ci hanno pure realizzato dei meme:

nel programma closed saranno solamente i malintenzionati a perdere tempo per trovare gli exploit, a meno che non sei un ricercatore che lo fa di mestiere.

Ti svelo un segreto: il mondo è strapieno di malintenzionati, a cui i ricercatori (che evidentemente non sono così tanti) non riescono a star dietro.

Originariamente inviato da giuliop

Per parafrasare un famoso slogan, "Never underestimate the power of cdimauro"

Il problema è che la mancanza di voglia di cambiare porta uno svantaggio ai concorrenti; la gente usa meno i loro prodotti, loro perdono quote di mercato e poi finiscono nell'oblio, il che porta alla mancanza di libertà di scelta: con Netscape è successo proprio così.
E c'è voluto un colosso come Google, che non aveva bisogno di basare il proprio business sul browser, per contrastare veramente MS, anche con IE ridotto male: e colossi come Google non ne vengono fuori ogni giorno.

Appunto: "ciao ciao Sublime Text, è stato bello conoscerti", ma non perché Sublime Text faccia schifo, ma semplicemente perché MS è in posizione dominante.

Verissimo.

E ti sembrerà paradossale, essendo io uno sviluppatore, ma il punto per me è che vorrei essere libero di proporre i miei software come voglio io, sebbene si possa arrivare a casi come questo.

Ovviamente come voglio = senza che metta appositamente i bastoni fra le ruote agli altri sviluppatori.

Adesso di corsa a lavoro, che sono in ritardo...

[cronos1990]

Originariamente inviato da mmorselli

Il programma open source è più sicuro di quello closed, perché il controllo viene fatto da molte più persone. Quando un cracker trova un exploit in un programma open source lo trovano anche gli altri, perché è un'operazione semplice, alla portata di tante persone, mentre quando lo trova in un programma closed source di norma se lo tiene per sé o lo fa girare a pagamento negli ambienti underground, perché si tratta di una scoperta complessa o fortuita alla portata di poche persone. Tra l'altro mentre nel programma open una persona può verificare come viene fatta una certa cosa anche solo per tranquillità personale, nel programma closed saranno solamente i malintenzionati a perdere tempo per trovare gli exploit, a meno che non sei un ricercatore che lo fa di mestiere.

Il controllo è "potenzialmente" fatto da più persone, non c'è scritto da nessuna parte che qualcuno andrà a controllare il codice sorgente. Può essere plausibile per alcuni software molto diffusi, d'altro canto è plausibile che quelli meno diffusi siano poco o per nulla controllati da queste "persone in più". Di sicuro non hai alcuna sicurezza a riguardo, come di sicuro non puoi sapere se queste "persone in più" stiano giocherellando col codice sorgente per risolvere bug/exploit piuttosto che per aggiungere funzioni o semplicemente cambiare il colore dello sfondo in rosa shocking (e quando ho frequentato la comunità di Firefox anni fa, mettendo anche mano ad alcune estensioni, guarda caso l'impegno maggiore era proprio rivolto a queste ultime cose).
Questo tralasciando le competenze: in linea di massima mi fido di più di 3 tecnici Microsoft che lavorano su Windows e lo conoscono a menadito, piuttosto che di 100 persone che mettono mano al codice di un qualunque programma open-source senza sapere neanche se sono capaci di scrivere due righe di codice.

Oltretutto le tue argomentazioni sono (chiedo il permesso a giuliop e cdmauro di usare il termine ) fallaci. Se come dici tu la scoperta di un bug/exploit su un closed-source è complessa nonchè fortuita (parole tue), di fatto confermi quello che ha detto cdmauro: che software di questo tipo sono più sicuri perchè molto più difficile trovare tali bug di sistema.

Tra l'altro non si capisce perchè i malintenzionati non sarebbero portati a crackare un open-source, laddove quasi tutti questi simpaticoni della domenica lo fanno sulla base della diffusione di un software, perchè ci si divertono o per lanciare messaggi che possono essere di qualunque tipo. Anzi, proprio per come funziona un open-source, parimenti a come ci sono più persone in grado di poterlo migliorare ci sono molto più cracker che possono metterci le mani perchè l'accesso è molto più facilitato.

[mmorselli]

Originariamente inviato da cronos1990

Il controllo è "potenzialmente" fatto da più persone, non c'è scritto da nessuna parte che qualcuno andrà a controllare il codice sorgente.

No, ma almeno si può fare, e in genere lo si fa, anche perché i progetti open source vengono usati da sempre dai programmatori per risolvere gli stessi problemi in ambiti analoghi.

Questo tralasciando le competenze: in linea di massima mi fido di più di 3 tecnici Microsoft che lavorano su Windows e lo conoscono a menadito, piuttosto che di 100 persone che mettono mano al codice di un qualunque programma open-source senza sapere neanche se sono capaci di scrivere due righe di codice.

Onestamente, se proprio volessi appellarmi al principio di autorità, non prenderei Microsoft come esempio

Tra l'altro non si capisce perchè i malintenzionati non sarebbero portati a crackare un open-source

Facciamo finta che la frase "crackare un open-source" abbia senso... Diciamo se mai che i malintenzionati possano cercare l'exploit all'interno dell'open source. E' un processo molto più semplice rispetto a cercarlo in un closed, ma proprio per via della relativa semplicità prima o poi la stessa scoperta la farà anche il ben intenzionato. Nessun software ti garantisce che nascerà senza exploit, ma con l'open hai più speranza che nel tempo verranno corretti tutti... almeno finchè non si aggiungeranno nuove funzionalità e quindi nuovi possibili exploit.

Con il closed source invece potrebbero esserci exploit noti ad un piccolo gruppo di criminali che lo sfruttano e che non verrà mai scoperto da nessun altro. Inoltre il closed non sappiamo quando e se sia stato abbandonato dal suo sviluppatore, il quale quindi non si prenderà più cura di verificare il codice, mentre per l'open questa possibilità rimane sempre aperta.

Un altro fattore a favore dell'open è che quando lo scrivo non posso fare ragionamenti del tipo "qui è sicuro perchè nessuno saprà come l'ho fatto", devo partire dall'idea che tutti sapranno come sto facendo le cose e quindi sono obbligato ad usare metodi che presuppongono un avversario, sempre, senza possibilità di prendere scorciatoie. Un buco di sicurezza in un open source è un errore, una svista, in un closed potrebbe anche essere una scelta frettolosa e poco lungimirante.

[giuliop]

Originariamente inviato da mmorselli

O meglio, perché è in abuso di posizione dominante. Il successo non è un reato, dipende sempre da come lo raggiungi e da come lo mantieni. Se hai il 99% del mercato, ma ce l'hai solo perché il tuo prodotto è il migliore e non hai creato ostacoli ai tuoi concorrenti che non siano altro che la tua superiore qualità o convenienza, non c'è abuso e non c'è condanna.

I problemi nascono sempre quanto tu metti in atto delle pratiche che ai tuoi concorrenti sono precluse. Per esempio se Microsoft fa un browser il doppio più veloce di tutti gli altri non è abuso, se il browser va veloce il doppio perché usa delle API non pubbliche del sistema operativo è abuso.

Il "browser ballot" è stato messo semplicemente perché MS includeva IE in Windows e dalla sua posizione dominante metteva i concorrenti in svantaggio, non era una questione di API.

Originariamente inviato da cronos1990

Oltretutto le tue argomentazioni sono (chiedo il permesso a giuliop e cdmauro di usare il termine ) fallaci.

Permesso concesso

A parte gli scherzi, qualcuno (o meglio, uno) nell'altro thread è evidentemente convinto che queste cose me le sia inventate io, il che perplime molto

[marcram]

Originariamente inviato da Svelgen

Ma infatti...c'è questa credenza popolare a credere che open-source sia migliore di closed.
Ma se devo rubare, scelgo l'obbiettivo più indifeso possibile oppure quello supercontrollato da sistemi di allarme e polizia che staziona all'entrata?

C'è un canale Youtube dove un esperto cerca di scassinare tutte le serrature che gli inviano, mostrando i punti deboli.
Meglio scegliere una serratura che lui non ha recensito (per te rimane "closed", ma magari i ladri sanno benissimo come aprire), o una che ha aperto, mostrato come funziona, e ti ha fatto vedere perché è difficilmente scassinabile?
Io preferisco la seconda...

[mmorselli]

Originariamente inviato da Svelgen

Ma se devo rubare, scelgo l'obbiettivo più indifeso possibile oppure quello supercontrollato da sistemi di allarme e polizia che staziona all'entrata?

Ma cosa ti fa pensare che open voglia dire indifeso? Quando il tuo codice è aperto difenderti non è un'opzione. Tutti i più importanti algoritmi di crittografia, su cui si basa praticamente ogni cosa importante della nostra società, da Internet alla finanza, sono open source. Questo forse li rende insicuri? Questa è l'unica cosa che li rende sicuri.

Per altro è bello vedere come i simpatizzanti Apple siano anche, per forma mentis, simpatizzanti del closed source, quando Apple è una delle aziende che ha dato i contributi più importanti nel mondo open source.

[mmorselli]

Originariamente inviato da giuliop

Il "browser ballot" è stato messo semplicemente perché MS includeva IE in Windows e dalla sua posizione dominante metteva i concorrenti in svantaggio, non era una questione di API.

Che è quello che ho scritto io.. Ma perché è così complicato far passare dei concetti?

Il "crimine" di Microsoft non è stato fare un browser migliore degli altri, ma approfittare della sua posizione per metterlo più in vista degli altri. Se il confronto è solo sulla tecnologia e i concorrenti hanno gli strumenti (non per forza le risorse) per proporsi nel tuo stesso modo, nessuno ti può dire nulla.

[giuliop]

Originariamente inviato da mmorselli

Che è quello che ho scritto io..

A me non sembrava, ma se dici che è così, ti credo.

Originariamente inviato da mmorselli

Ma perché è così complicato far passare dei concetti?

Forse perché c'è sempre una certa ambiguità nella lingua, o forse perché i tuoi interlocutori non sono particolarmente svegli

[mmorselli]

Originariamente inviato da giuliop

o forse perché i tuoi interlocutori non sono particolarmente svegli

Non lo credo, secondo me è perché quando la gente legge ciò che ricava è 50% cioè che c'è scritto, 50% anticipazione sulla base di un proprio preconcetto. Se si legge velocemente capita a chiunque, nessuno è immune.

[cdimauro]

Originariamente inviato da cronos1990

Oltretutto le tue argomentazioni sono (chiedo il permesso a giuliop e cdmauro di usare il termine ) fallaci. Se come dici tu la scoperta di un bug/exploit su un closed-source è complessa nonchè fortuita (parole tue), di fatto confermi quello che ha detto cdmauro: che software di questo tipo sono più sicuri perchè molto più difficile trovare tali bug di sistema.

Ovviamente sono d'accordo su tutto quello che hai scritto, ma quoto soltanto questo perché è il nodo centrale della "Security through obscurity".

E la prossima frontiera, che metterà una pietra tombale sulla presunta miglior sicurezza dei sistemi aperti, sarà quando anche tutta la memoria sarà crittografata (ci stiamo arrivando ormai) e i cracker non potranno nemmeno disassemblare e fare ingegneria inversa del codice (con sistemi com Sucure Enclave soltanto l'autore del codice è in grado di poter debuggare il codice potendo anche disassemblare gli eseguibili da lui prodotti).

Allora voglio vedere come faranno ad andare a caccia di falle si sicurezza.

Non gli resterà altro che puntare ai sistemi aperti, che quindi vedranno aumentare le fila di malintenzionati a caccia di falle zero-day da sfruttare.

Il tutto in barba agli espertoni che affermano che i sistemi aperti sono migliori dei sistemi chiusi in termini di "sicurezza"...

Originariamente inviato da mmorselli

No, ma almeno si può fare, e in genere lo si fa, anche perché i progetti open source vengono usati da sempre dai programmatori per risolvere gli stessi problemi in ambiti analoghi.

E chi lo fa? In genere solo chi ci lavora (sviluppatori o ricercato di sicurezza), e qualche altro appassionato.

Tu l'hai mai fatto? Hai mai dato almeno un'occhiata veloce ai sorgenti di Linux? Non credo, e se proprio l'avessi fatto dubito che ti saresti prego la briga di spulciarti tutte le decine di milioni di righe di codice di cui è composto E capirne il funzionamento E cogliere potenziali falle di sicurezza.

Onestamente, se proprio volessi appellarmi al principio di autorità, non prenderei Microsoft come esempio

E ancora una volta sbaglieresti: Microsoft per i suoi prodotti ha meno bug trovati per migliaio di righe di codice. Se non ricordo male quello al secondo posto (non ricordo chi c'era, mi spiace) ne aveva il doppio.

Fonte: uno studio che è stato mostrato qualche anno fa in un talk a una conferenza su RISC-V (il talk era ovviamente incentrato sulla sicurezza). C'è il video su youtube, ovviamente, ma non chiedermi quale, perché non metto nei segnalibri roba che ho visionato, e dopo tanti anni è difficile per me recuperarlo.

Facciamo finta che la frase "crackare un open-source" abbia senso... Diciamo se mai che i malintenzionati possano cercare l'exploit all'interno dell'open source. E' un processo molto più semplice rispetto a cercarlo in un closed, ma proprio per via della relativa semplicità prima o poi la stessa scoperta la farà anche il ben intenzionato. Nessun software ti garantisce che nascerà senza exploit, ma con l'open hai più speranza che nel tempo verranno corretti tutti... almeno finchè non si aggiungeranno nuove funzionalità e quindi nuovi possibili exploit.

La differenza fra open e closed è l'audience, e siccome ci lavorano più o meno sempre le stesse persone, non c'è alcuna differenza per i buoni che vanno a caccia di exploit.

La differenza, però, c'è per i malintenzionati, che con l'open hanno le porte spalancate, mentre col closed devono darsi da fare per "scassinarle". Infatti vedi sopra la mia risposta a chronos.

Con il closed source invece potrebbero esserci exploit noti ad un piccolo gruppo di criminali che lo sfruttano e che non verrà mai scoperto da nessun altro.

Assolutamente falso. Chi lavora coi progetti closed ha ovviamente a disposizione i sorgenti a bella vista, e può trovare le falle di sicurezza, esattamente come chi lavora con progetti open source.

Inoltre il closed non sappiamo quando e se sia stato abbandonato dal suo sviluppatore, il quale quindi non si prenderà più cura di verificare il codice, mentre per l'open questa possibilità rimane sempre aperta.

E' soltanto una possibilità teorica, esclusivamente sulla carta. Anche perché la stessa cosa vale per i progetti open source che vengono abbandonati, e se non frega a nessuno di mantenerli e/o di migliorarli, ancor meno interessanti saranno per i ricercatori di falle.

Un altro fattore a favore dell'open è che quando lo scrivo non posso fare ragionamenti del tipo "qui è sicuro perchè nessuno saprà come l'ho fatto", devo partire dall'idea che tutti sapranno come sto facendo le cose e quindi sono obbligato ad usare metodi che presuppongono un avversario, sempre, senza possibilità di prendere scorciatoie. Un buco di sicurezza in un open source è un errore, una svista, in un closed potrebbe anche essere una scelta frettolosa e poco lungimirante.

La realtà è ben diversa. Infatti ciò che hai scritto cozza con i minor bug per migliaio di righe di codice che ho riportato prima.

Si vede, quindi, che nei progetti closed lavorino più professionisti / più professionalmente che in quelli open.

Altrimenti quei numeri non si spiegherebbero.

Originariamente inviato da marcram

C'è un canale Youtube dove un esperto cerca di scassinare tutte le serrature che gli inviano, mostrando i punti deboli.
Meglio scegliere una serratura che lui non ha recensito (per te rimane "closed", ma magari i ladri sanno benissimo come aprire), o una che ha aperto, mostrato come funziona, e ti ha fatto vedere perché è difficilmente scassinabile?
Io preferisco la seconda...

Infatti è ben noto che chi metta allarmi in casa pubblicizzi quali abbia usato, o magari metta pure gli schemi di tali allarmi sull'uscio di casa.

Il lavoro di quell'esperto non fa che rendere la vita molto più facile ai malintenzionati, che avranno già pronto il necessario per scassinare l'allarme. Difficile non equivale a impossibile.

Originariamente inviato da mmorselli

Ma cosa ti fa pensare che open voglia dire indifeso? Quando il tuo codice è aperto difenderti non è un'opzione. Tutti i più importanti algoritmi di crittografia, su cui si basa praticamente ogni cosa importante della nostra società, da Internet alla finanza, sono open source. Questo forse li rende insicuri? Questa è l'unica cosa che li rende sicuri.

Premesso che si parla di codice di applicazioni, in generale, e non soltanto di algoritmi di crittografia, questi ultimi sono così piccoli per cui gli esperti si possono permettere di realizzare verifiche formali della loro consistenza / validità / sicurezza.

Cosa ovviamente impossibile per software che sono costituiti da DI GRAN LUNGA più righe di codice, e che peraltro sono l'oggetto della discussione.

Originariamente inviato da mmorselli

Che è quello che ho scritto io.. Ma perché è così complicato far passare dei concetti?

Il "crimine" di Microsoft non è stato fare un browser migliore degli altri, ma approfittare della sua posizione per metterlo più in vista degli altri. Se il confronto è solo sulla tecnologia e i concorrenti hanno gli strumenti (non per forza le risorse) per proporsi nel tuo stesso modo, nessuno ti può dire nulla.

No. Tu hai scritto questo:

"Dipende sempre da come lo fai. Anche per la questione Windows Media Player il problema non era che Media Player fosse troppo buono (il contrario se mai), ma che non pubblicava le API per comunicare in modo corretto con il suo stesso server multimediale, e quindi altri programmi installati su Windows, come Real Player che diede inizio alla causa, non avrebbero mai potuto raggiungere gli stessi risultati."

Sia io sia giuliop ricordiamo bene.

[mmorselli]

Originariamente inviato da cdimauro

E la prossima frontiera, che metterà una pietra tombale sulla presunta miglior sicurezza dei sistemi aperti, sarà quando anche tutta la memoria sarà crittografata (ci stiamo arrivando ormai) e i cracker non potranno nemmeno disassemblare e fare ingegneria inversa del codice (con sistemi com Sucure Enclave soltanto l'autore del codice è in grado di poter debuggare il codice potendo anche disassemblare gli eseguibili da lui prodotti).

Sogni un mondo orribile, ma su questo non metto bocca, c'è chi vorrebbe il ritorno del fascismo, figurati se mi preoccupo per chi sogna la fine di ciò che ha creato il mondo del software come lo conosciamo oggi...

Comunque questo è ciò che speri tu per il futuro, ne parleremo quando ci sarà, non puoi portarlo come argomento.

Tu l'hai mai fatto? Hai mai dato almeno un'occhiata veloce ai sorgenti di Linux?

Di Linux no, non è certo nel mio campo d'interesse, ma ho diversi amici che hanno scritto patch per Debian perché invece era nel loro. Io spesso modifico programmi open source per adattarli alle mie esigenze, oppure copio ampie porzioni per imparare come si fanno certe cose, per esempio nel campo di OpenVR su cui ho investito del tempo. Poi il tuo discorso non deve essere smentito da me, come se quello che non faccio io non lo facesse nessuno, è smentito dal fatto che il mondo open source funziona così da sempre, e funziona.

Non credo, e se proprio l'avessi fatto dubito che ti saresti prego la briga di spulciarti tutte le decine di milioni di righe di codice di cui è composto E capirne il funzionamento E cogliere potenziali falle di sicurezza.

Hai un modo di argomentare davvero poco onesto intellettualmente. Nessuno "spulcia milioni di righe di codice", non funziona così, funziona che milioni di persone guardano centinaia di righe di codice in base al campo d'interesse. Hai un dubbio su un modulo di nginx e vuoi capire meglio come funziona? Ti prendi il codice di quel modulo e lo segui se hai le competenze per farlo, e magari mentre lo fai ti accorgi che una parte è scritta nel modo sbagliato, o potenzialmente insicuro, anche solo per una distrazione del programmatore nell'usare un puntatore, capita a tutti.

Chi lavora coi progetti closed ha ovviamente a disposizione i sorgenti a bella vista, e può trovare le falle di sicurezza, esattamente come chi lavora con progetti open source.

Fino ad ora non te l'ho mai chiesto, però a sto punto devo: tu sei un programmatore?

Perché c'è una ragione per cui i programmi li facciamo testare ai nostri utenti invece che sistemare il bug leggendo e rileggendo il codice, ed è che le cose che per il nostro cervello sono ovvie le abbiamo già sistemate, mentre le scrivevamo. Il test da parte di gente diversa ci serve per evidenziare quelle cose con i nostri schemi mentali non avremmo mai notato, ci serve che il programma venga usato in modi che a noi non sarebbero mai venuti in mente.

Premesso che si parla di codice di applicazioni, in generale, e non soltanto di algoritmi di crittografia, questi ultimi sono così piccoli per cui gli esperti si possono permettere di realizzare verifiche formali della loro consistenza / validità / sicurezza.

Nei tuoi sogni, la crittografia è materia così complessa che normalmente passano molti anni prima che venga scoperto un bug, eppure il codice è sempre stato lì, sotto gli occhi degli "esperti", i quali però proprio perché esperti della materia hanno sempre immaginato che il codice venisse usato nel modo in cui l'hanno progettato, e non in un modo diverso, che è ciò che normalmente porta all'exploit.

Cosa ovviamente impossibile per software che sono costituiti da DI GRAN LUNGA più righe di codice, e che peraltro sono l'oggetto della discussione.

Forse questa è già una risposta alla mia domanda "sei un programmatore?" - No, direi di no, perché non sai com'è fatto un progetto software. Non è un foglio con 100.000 righe di codice, ma un albero di classi e funzioni ben divise in cartelle che si occupano di cose specifiche. Non puoi pensare di creare un progetto collaborativo portato avanti da più persone se ti aspetti che queste si leggano "milioni di righe di codice". La cosa su cui hai deciso di intervenire è più probabile che sia composta da tre o quattro file con poche centinaia di righe ognuno, anche su un progetto molto grande.

No. Tu hai scritto questo:

"Dipende sempre da come lo fai. Anche per la questione Windows Media Player il problema non era che Media Player fosse troppo buono (il contrario se mai), ma che non pubblicava le API per comunicare in modo corretto con il suo stesso server multimediale, e quindi altri programmi installati su Windows, come Real Player che diede inizio alla causa, non avrebbero mai potuto raggiungere gli stessi risultati."

Sia io sia giuliop ricordiamo bene.

Magari se oltre a ricordare ti sforzassi anche di capire...

Nel pezzo quotato si parla di Windows Media Player e delle ragioni per cui la cosa rappresentava un abuso. Nel momento in cui mi si risponde "No, guarda che il ballot è stato creato per questa ragione" io sono obbligato a ricordare che il ballot si riferisce al browser, non a Media Player, per cui le due motivazioni sono diverse, anche se uguali nel concetto di fondo. In entrambi i casi il problema non era che Microsoft aveva creato un player migliore o un browser migliore, ma che usava dei mezzi, diversi nei due casi in esame, per mettersi in una posizione di vantaggio rispetto ai concorrenti che non riguardavano la qualità del prodotto. Se mi rispondi che "Il browser ballot ... non era una questione di API" significa che probabilmente non hai capito nulla del discorso, hai letto senza dedicare l'attenzione necessaria mescolando due cose diverse.

[giuliop]

Originariamente inviato da mmorselli

[...]Se mi rispondi che "Il browser ballot ... non era una questione di API" significa che probabilmente non hai capito nulla del discorso, hai letto senza dedicare l'attenzione necessaria mescolando due cose diverse.

Una frase posso anche mal interpretarla, però dire "non hai capito nulla" è tutta un'altra cosa.
Sinceramente volevo evitare il "hai detto" "no, ho detto", ma visto che mi tiri in ballo in questo modo:

Originariamente inviato da mmorselli

[....] Se hai il 99% del mercato, ma ce l'hai solo perché il tuo prodotto è il migliore e non hai creato ostacoli ai tuoi concorrenti che non siano altro che la tua superiore qualità o convenienza, non c'è abuso e non c'è condanna.

Quindi: ho il 99% del mercato (ipotizziamo io sia Windows), metto un editor come Sublime Text, e ho successo "solo perché il mio prodotto è il migliore e non hai creato ostacoli ai miei concorrenti che non siano altro che la mia superiore qualità o convenienza" (e includerlo *non è un ostacolo*): per questo "non c'è abuso e non c'è condanna": è il contrario di quello che ho detto io, e di quello che hai detto dopo.

Io posso anche credere che tu non ti contraddica così palesemente, ma magari prendere in considerazione di non essere stato particolarmente chiaro, no?

[mmorselli]

Originariamente inviato da giuliop

Quindi: ho il 99% del mercato (ipotizziamo io sia Windows), metto un editor come Sublime Text, e ho successo "solo perché il mio prodotto è il migliore e non hai creato ostacoli ai miei concorrenti che non siano altro che la mia superiore qualità o convenienza" (e includerlo *non è un ostacolo*): per questo "non c'è abuso e non c'è condanna": è il contrario di quello che ho detto io, e di quello che hai detto dopo.

Sbagliato, perché se tu includi Sublime Text in Windows il prodotto ha successo per la sua qualità E perché è di serie nel sistema operativo più diffuso al mondo, per cui diventa anche difficile dire per quale delle due ragioni ha avuto successo.

Dopo si ragiona in termini pratici, il libero mercato non è filosofia, è un modo per far girare i soldi nel modo più conveniente alla società. Un browser e un media player sono prodotti strategici su cui puoi generare miliardi di fatturato, in particolare il browser, che raccoglie dati personali e veicola pubblicità. Se Windows incorpora un'ottima calcolatrice frega nulla a nessuno, ci sarà sempre spazio per una calcolatrice migliore destinata ad un mercato molto verticale, inoltre la calcolatrice è fine a sé stessa, non è la porta d'ingresso per la vendita di contenuti multimediali e pubblicità. Conta anche quante persone vai a coinvolgere, un browser lo usa chiunque.

Ciò che è importante nel discorso, però, è che se il browser può avere successo per la sua qualità E per la sua visibilità, dove si interviene è la visibilità, non si chiederà mai a Microsoft di farlo peggiore per risolvere il problema, che sia migliore o peggiore è irrilevante, anzi, se è peggiore il danno è persino più grave.

Io posso anche credere che tu non ti contraddica così palesemente, ma magari prendere in considerazione di non essere stato particolarmente chiaro, no?

Quello sempre, infatti sempre disponibile a spiegare meglio, però a volte ho proprio la sensazione che si legga anche in fretta.

[randorama]

Originariamente inviato da mmorselli

Quello sempre, infatti sempre disponibile a spiegare meglio, però a volte ho proprio la sensazione che si legga anche in fretta.

si, però tu sei davvero sfortunato.
su qualunque argomento, immancabilmente, ti interfacci con persone che non capiscono il significato di quanto affermi.
per carità, solo su queste pagine

[mmorselli]

Originariamente inviato da randorama

si, però tu sei davvero sfortunato.
su qualunque argomento, immancabilmente, ti interfacci con persone che non capiscono il significato di quanto affermi.
per carità, solo su queste pagine

Ma non è vero nemmeno questo, trovo abbastanza normale che quando ci si confronta sia soprattutto chi non è d'accordo e chi non ha capito a risponderti, perchè dovrebbe farlo chi è d'accordo con te? Per fare gruppo? Al massimo chi è d'accordo con me esprimerà il suo punto di vista aggiungendo del suo, rivolgendosi a te, non a me.

Ho un amico fascio-leghista che quando capita di parlare di politica finisce sempre dicendo "Tu non mi hai mai dato ragione una volta!" - E a me fa sorridere, perché questo implica ovviamente che lui abbia fatto la stessa cosa, altrimenti ci saremmo dati ragione a vicenda in quelle occasioni. Però non glielo dico, è fascio-leghista, non capirebbe un concetto con così tanti passaggi logici

[giuliop]

Originariamente inviato da mmorselli

Sbagliato, perché se tu includi Sublime Text in Windows il prodotto ha successo per la sua qualità E perché è di serie nel sistema operativo più diffuso al mondo, per cui diventa anche difficile dire per quale delle due ragioni ha avuto successo.

Oh, quindi volevi dire:
"Se hai il 99% del mercato, ma ce l'hai solo perché il tuo prodotto è il migliore e non hai creato ostacoli ai tuoi concorrenti che non siano altro che la tua superiore qualità o convenienza e non hai sfruttato la tua posizione dominante, non c'è abuso e non c'è condanna."

Così quadra: t'eri solo dimenticato la frase più importante.

[cdimauro]

Originariamente inviato da mmorselli

Sogni un mondo orribile, ma su questo non metto bocca, c'è chi vorrebbe il ritorno del fascismo, figurati se mi preoccupo per chi sogna la fine di ciò che ha creato il mondo del software come lo conosciamo oggi...

Non so che film ti sia fatto, perché sei partito "per arrivare là dove nessuno è mai giunto prima" (ossia fuori dalla realtà e completamente immerso nella tua fervida immaginazione).

Primo, quando quello che ho scritto si verificherà non ci sarà assolutamente nessun cambiamento nel mondo del software: quello open continuerà a essere sviluppato allo stesso modo, idem quello closed, ed entrambi pubblicati e/o commercializzati come al solito.
Non vedo cosa ci sia di così apocalittico che dovrebbe o potrebbe mai capitare. Ma a questo punto me lo spiegherai tu, visto che il regista di questo film horror sei proprio tu.

Secondo, e come ho già detto, con questa protezione sarà praticamente impossibile (l'unico modo sarebbe aggirare la protezione, che però è hardware) per i cracker eseguire ingegneria inversa sul codice, per cui il codice closed sarà senz'altro MOLTO, MA MOLTO più "sicuro", visto che sarà estremamente difficile trovare falle (l'unico modo per i cracker sarebbe andare alla cieca, cercando di passare valori sballati alle API di sistema, e roba del genere).
Penso che sia evidente l'enorme MIGLIORAMENTO per la "sicurezza", e mi auguro che tu NON sia dalla parte di chi vorrebbe, invece, facilitare la vita ai malintenzionati.

Terzo, gli autori del codice sarebbero enormemente più tutelati riguardo ai loro diritti, perché nessuno potrebbe ficcarci il naso e copiare il loro lavoro. Anche qui sarebbe un grandissimo miglioramento rispetto alla situazione attuale.

Quarto, come corollario del precedente, i brevetti sul software diventerebbero del tutto inutili, visto che gli inventori di nuovi algoritmi et similia non sarebbero costretti a ricorrervi per tutelare le loro invenzioni.
E qui i simpatizzanti del software open source dovrebbero stappare la bottiglia di spumante buono, visto che generalmente non vedono di buon occhio i brevetti e li osteggiano.

Quinto, come conseguenza del precedente, la tutela della proprietà intellettuale non sarà più appannaggio di benestanti e/o aziende, visti i costi che ci sono dietro. Questo renderà più democratico lo sviluppo e la tutela del software.

Ora, come tu sia potuto arrivare a tirare fuori scenari apocalittici o addirittura fascisti è una cosa che sono molto curioso di sapere, visto che, come vedi sopra, ci sono innegabili vantaggi per tutti da queste future protezioni. Ma, come al solito, tua è la tesi e, dunque, tuo anche l'onere della prova.

Comunque questo è ciò che speri tu per il futuro, ne parleremo quando ci sarà, non puoi portarlo come argomento.

Non è che ci spero io: è la direzione che sta prendendo l'informatica, se t'informassi sui suoi progressi e i prodotti che arrivano sul mercato.

Tecnologie di Secure Enclave sono già presenti da diversi anni, come pure hanno già fatto capolino tecnologie di sicurezza che si occupano crittografare in tempo reale la memoria. Dalla combinazione delle due, unita alla loro diffusione a tutti i livelli, si arriverà a quanto ho prospettato prima. Dunque è soltanto una questione di tempo.

Ciò precisato, non era, quindi, un argomento a favore delle mie tesi, quanto semplicemente un'anticipazione degli scenari futuri.

Anche perché ho già detto di aver DIMOSTRATO che i software closed sono ALMENO "sicuri" quanto quelli open, per cui capisci bene che con un teorema in mano mi posso permettere il lusso di ignorare qualunque critica (la matematica, di cui l'informatica è una branca, ha il suo fascino in questo: un teorema è inattaccabile, ed eterno).

Di Linux no, non è certo nel mio campo d'interesse, ma ho diversi amici che hanno scritto patch per Debian perché invece era nel loro. Io spesso modifico programmi open source per adattarli alle mie esigenze, oppure copio ampie porzioni per imparare come si fanno certe cose, per esempio nel campo di OpenVR su cui ho investito del tempo. Poi il tuo discorso non deve essere smentito da me, come se quello che non faccio io non lo facesse nessuno, è smentito dal fatto che il mondo open source funziona così da sempre, e funziona.

Il fatto che il mondo open source funzioni così non implica, logica elementare alla mano, che quanto dicevo prima sia stato smentito.

A meno che, ovviamente, non lo DIMOSTRI, ma finora non mi sembra che tu sia stato particolarmente incline a dimostrare le tue asserzioni. Quanto, invece, a tagliare parti delle discussioni che ti siano state scomode.

Hai un modo di argomentare davvero poco onesto intellettualmente.

Soltanto perché descrivo come funziona la realtà? Allora preferisco essere intellettualmente poco onesto che un sognatore che ne vive fuori.

Nessuno "spulcia milioni di righe di codice", non funziona così, funziona che milioni di persone guardano centinaia di righe di codice in base al campo d'interesse. Hai un dubbio su un modulo di nginx e vuoi capire meglio come funziona? Ti prendi il codice di quel modulo e lo segui se hai le competenze per farlo, e magari mentre lo fai ti accorgi che una parte è scritta nel modo sbagliato, o potenzialmente insicuro, anche solo per una distrazione del programmatore nell'usare un puntatore, capita a tutti.

E capita per qualunque tipo di software, sia esso open che closed.

Il problema di quest'approccio è che ci si fa una visione limitata di un software, ovviamente a ciò di cui ci si sia occupati.

E ciò può portare al famigerato bug di OpenSSH, in cui una modifica a una piccola parte del codice, che è stata ispezionata da centinaia e centinaia di sviluppatori nonché esperti (la famigerata "Legge di Linus"), abbia generato un enorme buco di sicurezza di questo famosissimo nonché usatissimo componente.

Infatti ci sono voluti ANNI per scoprire che quella piccola modifica a una parte minuscola del codice generava mostruosi problemi da tutt'altra parte.

Serve, quindi, una maggior conoscenza del codice, che porta a una miglior visione d'insieme, per capire meglio se ci possano essere problematiche non locali.

Se esistono diversi livelli di testing, a livelli di astrazione via via più elevati, andando dai mattoncini base dello unit testing, al component testing, all'integration testing, e infine al product validation, è proprio per questo motivo.

Fino ad ora non te l'ho mai chiesto, però a sto punto devo: tu sei un programmatore?

Guarda la mia firma. Noterai pure che abbia messo mano anche a progetti open source (e non è stata una bella esperienza).

Adesso che hai potuto misurare quanto ce l'abbia lungo non svenire.

Perché c'è una ragione per cui i programmi li facciamo testare ai nostri utenti invece che sistemare il bug leggendo e rileggendo il codice, ed è che le cose che per il nostro cervello sono ovvie le abbiamo già sistemate, mentre le scrivevamo. Il test da parte di gente diversa ci serve per evidenziare quelle cose con i nostri schemi mentali non avremmo mai notato, ci serve che il programma venga usato in modi che a noi non sarebbero mai venuti in mente.

Se sei il solo a leggere e rileggere il codice è ovvio che sia così, e mostri di avere già un grosso problema di base, visto che il software scritto professionalmente (con ciò NON intendo esclusivamente a livello professionale) DOVREBBE passare per un processo di revisione dei pari, proprio per cercare di evitare o almeno minimizzare le problematiche che hai descritto.

Per il resto da ex Senior QA Engineer per Intel e poi Principal QA Engineer per BMW trovo a dir poco agghiacciante ciò che hai appena scritto: NON si fanno testare i prodotti ai clienti!

Il software lo si testa PRIMA di rilasciarlo, facendo il più possibile uso di test automatici (che dovrebbero controllare per te ciò che sfugge ai tuoi occhi, SE sono fatti bene. E per fatti bene intendo che chi scrive i test NON SIA ASSOLUTAMENTE anche lo stesso che abbia scritto il codice) E, se non è sufficiente, da test manuali.

NON devono essere gli utenti a fare da cavie, e testare un prodotto: nella maniera più assoluta!

Il bello è che hai la faccia tosta di chiedere a me se fossi un programmatore.

Ma a questo punto lo chiedo io a te, cosa tu abbia fatto nella tua vita da programmatore, a parte giocare coi visori. Quali esperienze professionali hai avuto? Con quali progetti? Ma anche quale formazione hai avuto (laurea in informatica? O diploma)?
Perché in te non trovo né la mentalità matematico/informatico di chi abbia seguito il giusto percorso di studi né la professionalità di abbia sviluppato codice per tanto tempo.

Nei tuoi sogni,

Io non sogno affatto: ho riportato esattamente come stiano le cose.

E non prendo lezioni da chi non è nemmeno in grado di comprendere la differenza fra firma digitale e crittografia.

la crittografia è materia così complessa che normalmente passano molti anni prima che venga scoperto un bug, eppure il codice è sempre stato lì, sotto gli occhi degli "esperti", i quali però proprio perché esperti della materia hanno sempre immaginato che il codice venisse usato nel modo in cui l'hanno progettato, e non in un modo diverso, che è ciò che normalmente porta all'exploit.

Stai mischiando cose diverse in un grande calderone qualunquista, perché è evidente che tu non abbia idea di ciò di cui stai parlando (e dovresti rifletterci seriamente, se arriva a dirtelo persino uno che non è esperto in materia).

La crittografia è materia complessa nella misura in cui gli scienziati si sbattano le corna nell'inventare sistemi di cifratura sempre più robusti. Qui non stiamo ancora parlando di codice, ma dell'idea che sta alla base di un sistema crittografico. Ed è roba da matematici / informatici teorici et similia.

Nel momento in cui l'idea si concretizza, arrivando quindi in forma di algoritmo (come pseudocodice o simile), si passa alla fase implementativa, e questa non richiede molto: non esistono algoritmi crittografici che richiedano centinaia di migliaia di righe di codice. Se sei a conoscenza di algoritmi crittografici che richiedano parecchie righe di codice per la loro implementazione, non hai che da portarli.

Una volta implementato l'algoritmo, si passa poi al "contorno" (e anche questo non richiede vagonate di righe di codice). Il "contorno" è quello che ha causato l'enorme falla di sicurezza in OpenSSH di Debian. A questo punto nemmeno ti dico cos'è il contorno, perché è evidente che non hai le basi in materia. Se t'interessa farti finalmente una conoscenza, prenditi il caso Debian in oggetto (che è perfetto allo scopo), te lo studi, e magari arrivi a capire da solo di cosa stia parlando.

Una volta implementato il contorno, tutto ciò che attiene di per sé al sistema crittografico è stato implementato, e le applicazioni lo possono usare.

Come vedi ci sono ben 3 livelli di astrazione in ballo, e i primi, tra cui quello più importante che è il primo, sono quelli più semplici.

Ecco perché, come dicevo prima, è più facile che per un algoritmo crittografico se ne possa realizzare una dimostrazione formale della sua "sicurezza". Mentre per un'intera applicazione (ed era questo l'oggetto della discussione, se te lo fossi perso per strada) questo è praticamente impossibile.

Forse questa è già una risposta alla mia domanda "sei un programmatore?" - No, direi di no, perché non sai com'è fatto un progetto software. Non è un foglio con 100.000 righe di codice, ma un albero di classi e funzioni ben divise in cartelle che si occupano di cose specifiche.

Appunto. Non capisco perché tu debba prendermi a randellate quando non stai facendo altro che darmi ragione.

Infatti un progetto software è qualcosa di molto complesso, per il quale non è possibile effettuare una verifica formale, visto che l'enorme numero di entità coinvolte, e le loro relazioni.

Non puoi pensare di creare un progetto collaborativo portato avanti da più persone se ti aspetti che queste si leggano "milioni di righe di codice".

Per caso ho detto o anche soltanto lasciato intendere qualcosa del genere?

Mi sa che hai perso completamente il filo della discussione. Vatti a rileggere ciò di cui stavamo parlando, che è meglio (cit.).

La cosa su cui hai deciso di intervenire è più probabile che sia composta da tre o quattro file con poche centinaia di righe ognuno, anche su un progetto molto grande.

Il che, come dicevo sopra, ti dà soltanto una visione limitata. E quindi può portare, e ha portato effettivamente, a casi come la falla di OpenSSH.

Magari se oltre a ricordare ti sforzassi anche di capire...

Nel pezzo quotato si parla di Windows Media Player e delle ragioni per cui la cosa rappresentava un abuso. Nel momento in cui mi si risponde "No, guarda che il ballot è stato creato per questa ragione" io sono obbligato a ricordare che il ballot si riferisce al browser, non a Media Player, per cui le due motivazioni sono diverse, anche se uguali nel concetto di fondo. In entrambi i casi il problema non era che Microsoft aveva creato un player migliore o un browser migliore, ma che usava dei mezzi, diversi nei due casi in esame, per mettersi in una posizione di vantaggio rispetto ai concorrenti che non riguardavano la qualità del prodotto. Se mi rispondi che "Il browser ballot ... non era una questione di API" significa che probabilmente non hai capito nulla del discorso, hai letto senza dedicare l'attenzione necessaria mescolando due cose diverse.

Ti è stato già risposto da altri.

Visto che hai problemi a farti capire non pensi che sarebbe meglio che scrivessi in maniera più intellegibile? E possibilmente senza cambiare discorso, passando anche da palo in frasca (vedi sopra).

[mmorselli]

Originariamente inviato da giuliop

Oh, quindi volevi dire:
"Se hai il 99% del mercato, ma ce l'hai solo perché il tuo prodotto è il migliore e non hai creato ostacoli ai tuoi concorrenti che non siano altro che la tua superiore qualità o convenienza e non hai sfruttato la tua posizione dominante, non c'è abuso e non c'è condanna."

Così quadra: t'eri solo dimenticato la frase più importante.

"creato ostacoli ai tuoi concorrenti..." = "sfruttato la tua posizione dominante"

Sono la stessa cosa. Tieni sempre presente che nell'esempio che stiamo analizzando è WINDOWS ad avere la posizione dominante, non Sublime Text o comunque si voglia chiamare il Super Editor di Microsoft.

La bontà del mio prodotto non è un ostacolo per i miei concorrenti, al contrario, è il limite che ci aspettiamo vogliano superare facendo un prodotto ancora migliore.

Se io però già controllo il sistema operativo più diffuso non è realistico dire ai concorrenti "prima ti fai un sistema operativo, poi lo rendi il più diffuso, e alla fine sarai libero di metterci l'editor che ti pare e farlo diventare l'editor più diffuso"

Cioè torniamo al caso dei documenti comodamente disponibili su Alpha Centauri.


Nel nostro interesse non c'è avere l'editor più diffuso, ma l'editor migliore, per cui anche nell'ipotesi in cui il concorrente sia davvero riuscito a rendere il suo ecosistema il più diffuso, non avremmo comunque la garanzia che il suo editor sia il migliore, al contrario ce l'abbiamo se costringiamo chi ha il sistema più diffuso a concedere pari visibilità ai principali editor del mercato. O browser, che ovviamente è più strategico di un editor.


Sarei curioso di vedere come si comporterebbe l'antitrust se Microsoft includesse l'intera suite office, gratuitamente, in Windows.

[mmorselli]

Originariamente inviato da cdimauro

Non vedo cosa ci sia di così apocalittico che dovrebbe o potrebbe mai capitare. Ma a questo punto me lo spiegherai tu, visto che il regista di questo film horror sei proprio tu.

Il reverse engineering è fondamentale in tante situazioni, per esempio quando un driver non viene sviluppato per un certo sistema operativo, o quando informazioni utili a creare nuovo software, aggiungere funzionalità ad uno esistente o implementare un protocollo non vengono svelati per motivi futili (es. non abbiamo tempo da perdere su questa cosa) oppure semplicemente perché lo sviluppatore originale non esiste più.

Quarto, come corollario del precedente, i brevetti sul software diventerebbero del tutto inutili, visto che gli inventori di nuovi algoritmi et similia non sarebbero costretti a ricorrervi per tutelare le loro invenzioni.
E qui i simpatizzanti del software open source dovrebbero stappare la bottiglia di spumante buono, visto che generalmente non vedono di buon occhio i brevetti e li osteggiano.

Brevetto e segreto industriale sono due cose completamente diverse. Il brevetto lo fai perché l'idea che hai avuto sai che potrebbe venire anche a qualcun altro, ma tu l'hai avuta per primo e quindi ritieni di avere il diritto di sfruttarla. Il brevetto ha come rovescio della medaglia la necessità di pubblicare in modo dettagliato l'idea, più è dettagliato, più sarà semplice impedire a qualcuno di fare la stessa cosa, nello stesso modo. Il segreto industriale lo fai quando l'idea che hai avuto ha un'implementazione molto complessa e speri nessuno riuscirà a replicarla. Aumentare la sicurezza nel segreto industriale non annulla la necessità di brevetto, che si fa per ragioni differenti.

NON devono essere gli utenti a fare da cavie, e testare un prodotto: nella maniera più assoluta!

Infatti il programma Windows Insider non è rivolto agli utenti. Infatti i giochi in Early Access o in Open Beta non vengono rilasciati per farli testare dagli utenti...

Mi sembri quelli che dicono "non voglio fare il vaccino perché è ancora poco testato" - Ma dopo il trial clinico, su chi lo dovrebbero testare, secondo loro?