1. Hallo Metalab 2. Selbstgebasteltes DRM für Mediendateien
Hallo, Ich war unlängst erstmals im Metalab anlässlich des Mediawiki-Workshops, es hat mir alles sehr gut gefallen und jetzt wollte ich mich mal listenmäßig bei euch einklinken! :-) Kleine Frage vorab zu dieser Liste: Auf der Anmeldeseite steht, die Liste wird öffentlich indexiert - die E-Mailadressen sind aber nicht sichtbar, oder? Wenn ich mich ein wenig vorstellen möchte, aber nicht dem ganzen Internetz, sondern nur dem Publikum von Metalab, dann nicht hier...? Mein aktuelles Thema: Ich habe eine momentan noch sehr vage Idee für eine kleines Deutschlernprojekt für Jugendliche, gemischt mit Geocaching, Openstreetmaps, mobile Apps... Kurz erklärt, man soll eine Audiodatei, die z.B. eine Deutschlektion enthält von einem Geocache irgendwo in Wien abholen. Dort spielt man sie per NFC/Bluetooth aufs Telefon. Der Geocache macht nix anderes, als diese Audiofiles auszuspucken (manchmal hats schon im öffentlichen Raum schon Plakatwände gegeben, die sowas gemacht haben). Das Problem dabei ist, jeder, der an der Sache teilnimmt, soll sich persönlich dorthin begeben um seine Datei abzuholen. Ich möchte verhindern, dass einfach einer der Schüler dorthin fährt und die Datei dann an den Rest der Gruppe weiterverteilt. Die Datei soll also auf dem Gerät bleiben, mit dem man sie geholt hat bzw. nur dort abspielbar sein. In anderen Worten, wie baue ich mir mein eigenes Mini-DRM? Ich habe quasi keine Programmierfähigkeiten - mein Kollege, der vielleicht mitbasteln wird, kann einige Basics - ich arbeite, soweit es geht, auf Linuxgeräten und kann mit guter Dokumentation einfachere CLI-Programme bedienen. Ich habe kein Geld für teure kommerzielle Lösungen (obwohl habe etwas gefunden mit einer gratis 90-Tage-Testversion:http://3.drm-x.com/Register.aspx). Es macht nichts, wenn es leicht zu hacken ist. Mein Publikum hat da tendenziell sehr beschränkte Fähigkeiten (diese zu erweitern ist auch Ziel des Projekts) und kann zudem schlecht Deutsch und nur selten gutes Englisch. Alle können ein Smartphone bedienen, einen PC eher selten. Es gibt Ausnahmen, die problemlos eine Lösung ergooglen und umsetzen könnten. Wenn die sich lieber die Mühe machen möchten, das DRM zu hacken statt mit der Straßenbahn zu dem Geocache zu fahren, dann soll es so sein (dann haben sie auch etwas gelernt) :-) Es soll einfach nur die allerbequemste Art, sich um eine Öffi-Fahrt/einen Spaziergang zu drücken, verhindern. Das DRM sollte also die erlaubten Kopiervorgänge auf 0 reduzieren. Soweit ich weiß, sollte es nicht schwierig sein, die Files zu verschlüsseln - aber wo tue ich den privaten Schlüssel hin? Mir scheint, Musikdownloaddienste (nicht Streaming) wie iTunes liefern den gleich mit - aber was verhindert, dass der zusammen mit der Datei weiterverteilt wird? Wird bei jeder Ausgabe ein neuer Schlüssel generiert? Während ich dies schreibe, kommt mir die Idee, dass es einfacher sein könnte, wenn es sich um lauter verschiedene Audiofiles handelt (was genau deren Inhalt sein soll und wie damit weiter verfahren wird, ist noch eine andere Frage)... naja, so weit reicht mein Latein einfach noch nicht. Wer hat Ideen oder etwas möglichst konzises zum Nachlesen? Vielen Dank fürs Lesen und liebe Grüße, Benjamin
On Fri, Apr 14, 2017 at 04:38:48PM +0200, Benjamin Oppermann wrote:
Hallo, Ich war unlängst erstmals im Metalab anlässlich des Mediawiki-Workshops, es hat mir alles sehr gut gefallen und jetzt wollte ich mich mal listenmäßig bei euch einklinken! :-)
Willkommen im Metalab und auf der Liste!
Kleine Frage vorab zu dieser Liste: Auf der Anmeldeseite steht, die Liste wird öffentlich indexiert - die E-Mailadressen sind aber nicht sichtbar, oder? Wenn ich mich ein wenig vorstellen möchte, aber nicht dem ganzen Internetz, sondern nur dem Publikum von Metalab, dann nicht hier...?
Email-Adressen werden nur leicht verschleiert, um es den Email-Harvestern nicht allzu leicht zu machen (haha). https://lists.metalab.at/pipermail/metalab/
In anderen Worten, wie baue ich mir mein eigenes Mini-DRM?
DRM ist unmöglich, solang der User über das Abspielgerät bestimmt…
Das DRM sollte also die erlaubten Kopiervorgänge auf 0 reduzieren. Soweit ich weiß, sollte es nicht schwierig sein, die Files zu verschlüsseln - aber wo tue ich den privaten Schlüssel hin? Mir scheint, Musikdownloaddienste (nicht Streaming) wie iTunes liefern den gleich mit - aber was verhindert, dass der zusammen mit der Datei weiterverteilt wird? Wird bei jeder Ausgabe ein neuer Schlüssel generiert?
…und hier hast Du in einem Absatz wunderbar zusammengefaßt, wieso das so ist :)
Während ich dies schreibe, kommt mir die Idee, dass es einfacher sein könnte, wenn es sich um lauter verschiedene Audiofiles handelt (was genau deren Inhalt sein soll und wie damit weiter verfahren wird, ist noch eine andere Frage)... naja, so weit reicht mein Latein einfach noch nicht. Wer hat Ideen oder etwas möglichst konzises zum Nachlesen?
Das müßte das Problem ganz gut erklären, wenn ich mich nicht irre: https://www.theguardian.com/technology/2007/sep/04/lightspeed lG!hop -- Q.E.Duh.
Willkommen im Metalab und auf der Liste!
hi!
DRM ist unm�glich, solang der User �ber das Abspielger�t bestimmt�
ich schliesse mich dem an aber.. kannst du fuer jeden request neue daten generieren? falls ja: client schickt: "hallo ich hab will das file, hier ist mein key" server macht was mit dem key und schickt das file. client entschluesselt das file und kanns nun lokal abspielen. du kannst fertige libraries dafuer nehmen, du kannst aber auch was total simples machen wie 512bytes random data generieren, lokal speichern, dem server genau dieses ding geben, der server macht dann ein XOR ueber die daten und fertig. beim abspielen wird das file dann on the fly mit dem geheimnis noch einmal ge-XORd. ist das sicher? nein. richtig sicher gibts ohnehin nicht. -- wo sollen die daten denn herkommen? hast du vor so raspberry pi zeros oder ESP module oder sowas zu verstecken? wo bekommen die den strom her? :* -flo
Danke für die schnellen Antworten! :-) Am Fr, 14. Apr 2017, um 18:19, schrieb overflo:
Willkommen im Metalab und auf der Liste!
hi!
DRM ist unmöglich, solang der User über das Abspielgerät bestimmt…
Nein, Millionen von Musikdownloads wurden und werden noch immer an User verkauft, die das Abspielgerät in der Hand haben. Sie alle permanent daran zu hindern, dass sie diese Files woandershin kopieren ist unmöglich. Es ihnen etwas unbequemer zu machen ist möglich. DRM, das für meine oben geschilderten Zwecke ausreicht, ist möglich. Wie machen es MS und Apple?
kannst du fuer jeden request neue daten generieren?
falls ja:
client schickt: "hallo ich hab will das file, hier ist mein key" server macht was mit dem key und schickt das file. client entschluesselt das file und kanns nun lokal abspielen.
du kannst fertige libraries dafuer nehmen, du kannst aber auch was total simples machen.
Etwas total simples ist super!
wie 512bytes random data generieren, lokal speichern, dem server genau dieses ding geben, der server macht dann ein XOR ueber die daten und fertig.
XOR über die Daten: über die zufälligen 512 Bytes, oder über die Audiodatei? Wie stehen die zufälligen 512 Bytes mit dem Audiofiles in Zusammenhang? Was bringt das, sie zu XORen?
beim abspielen wird das file dann on the fly mit dem geheimnis noch einmal ge-XORd.
ist das sicher? nein. richtig sicher gibts ohnehin nicht.
Ja, eh. Sicher genug ist die Frage.
wo sollen die daten denn herkommen? hast du vor so raspberry pi zeros oder ESP module oder sowas zu verstecken?
Ja so ähnlich, noch nicht überlegt.
wo bekommen die den strom her?
Sehr gute Frage! :-( Es muss wohl so stromsparend sein, dass eine fette Batterie mindestens 2 Tage durchhält. _____________________________________________
Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
On Fri, Apr 14, 2017 at 07:53:41PM +0200, Benjamin Oppermann wrote:
DRM ist unmöglich, solang der User über das Abspielgerät bestimmt…
Nein, Millionen von Musikdownloads wurden und werden noch immer an User verkauft, die das Abspielgerät in der Hand haben. Sie alle permanent daran zu hindern, dass sie diese Files woandershin kopieren ist unmöglich. Es ihnen etwas unbequemer zu machen ist möglich. DRM, das für meine oben geschilderten Zwecke ausreicht, ist möglich. Wie machen es MS und Apple?
Eigentlich führt das viel zu weit weg vom eigentlichen Thema, aber what-the-hey. 1. Wie Cory sagen würd: "It's like telling tall people to be tall." Meint: die selben User würden die Musik sowieso kaufen. 2. Niemand umgeht Apples DRM wegen eines Musikdownloads im iTunes-Store. Wozu, wenn es piratebay und Co gibt, und nur eine einzige Person ins Gschäft gehen muß, eine CD (ohne DRM!) kaufen, rippen und online stellen. hop -- Q.E.Duh.
Am Fr, 14. Apr 2017, um 18:19, schrieb overflo:
kannst du fuer jeden request neue daten generieren?
Wenn DRM, dann hoffe ich ja! Aber hoffe auch eine Lösung zu finden, bei der das nicht nötig ist...
falls ja:
client schickt: "hallo ich hab will das file, hier ist mein key" server macht was mit dem key und schickt das file.
Hier gehst du davon aus, dass der User schon einen Schlüssel bei sich hat, wenn er hinkommt? Und der private Schlüssel (ich finde ja, der sollte Schloss heißen, dann würden viel mehr Leute das verstehen) ist dazu da, die Dateiausgabe zu schützen? Das hat dann mit dem Kopierschutz nix zu tun, oder? Weil wer die Dateien bekommt, ist mir eigentlich wurscht, die können auch bei GCHQ, Sobotka und sonstwem landen.
Hallo, Ich kann mich aus Erfahrung den bisherigen Meinungen nur anschließen. Wenn ihr nicht ausgiebig Programmiererfahrung habt würde ich auch aufpassen das Projekt so einfach wie möglich zu halten! Ansonsten läuft ihr größte Gefahr euch in technischen Details zu verlieren die nicht wirklich notwendig sind und nie fertig werden. Ich denke eine mobile App zu implementieren, die On-Demand die Soundfiles aus dem Netz raus-streamed wäre schon einmal recht einfach, angenommen der Server spuckt einfach den Audiostream unverschlüsselt aus. Oder mit einem fixen vorprogrammierten Secret-Key obfuscated. Aber aufpassen -- alle Apps können sehr einfach reverse engineered werden und vorausgelieferte Secret Keys können immer ausgelesen werden. Es wäre wohl das einfachste, die files einfach mit einem gewissen secret zu XOR-en und als File auf der SD Karte zu hinterlegen. Das ist sehr wenig Aufwand, braucht aber schon technisch etwas know-how um die Daten zu de-obfuscaten und mit anderen zu sharen. Ich denke da ist für euch der Sweet-Spot zwischen Geheimhaltung und Aufwand nicht explodieren lassen. Einfach obfuscaten mit einem in der app vorprogrammieren Secret-Key. Dieser Secret Key könnte auch bei App-Start generiert werden, und von der App in einem vom OS bereitgestellten Secret-Storage hinterlegt werden. LG, Chris 2017-04-14 16:38 GMT+02:00 Benjamin Oppermann <ben.opp@eml.cc>:
Hallo, Ich war unlängst erstmals im Metalab anlässlich des Mediawiki-Workshops, es hat mir alles sehr gut gefallen und jetzt wollte ich mich mal listenmäßig bei euch einklinken! :-) Kleine Frage vorab zu dieser Liste: Auf der Anmeldeseite steht, die Liste wird öffentlich indexiert - die E-Mailadressen sind aber nicht sichtbar, oder? Wenn ich mich ein wenig vorstellen möchte, aber nicht dem ganzen Internetz, sondern nur dem Publikum von Metalab, dann nicht hier...?
Mein aktuelles Thema: Ich habe eine momentan noch sehr vage Idee für eine kleines Deutschlernprojekt für Jugendliche, gemischt mit Geocaching, Openstreetmaps, mobile Apps... Kurz erklärt, man soll eine Audiodatei, die z.B. eine Deutschlektion enthält von einem Geocache irgendwo in Wien abholen. Dort spielt man sie per NFC/Bluetooth aufs Telefon. Der Geocache macht nix anderes, als diese Audiofiles auszuspucken (manchmal hats schon im öffentlichen Raum schon Plakatwände gegeben, die sowas gemacht haben). Das Problem dabei ist, jeder, der an der Sache teilnimmt, soll sich persönlich dorthin begeben um seine Datei abzuholen. Ich möchte verhindern, dass einfach einer der Schüler dorthin fährt und die Datei dann an den Rest der Gruppe weiterverteilt. Die Datei soll also auf dem Gerät bleiben, mit dem man sie geholt hat bzw. nur dort abspielbar sein.
In anderen Worten, wie baue ich mir mein eigenes Mini-DRM?
Ich habe quasi keine Programmierfähigkeiten - mein Kollege, der vielleicht mitbasteln wird, kann einige Basics - ich arbeite, soweit es geht, auf Linuxgeräten und kann mit guter Dokumentation einfachere CLI-Programme bedienen.
Ich habe kein Geld für teure kommerzielle Lösungen (obwohl habe etwas gefunden mit einer gratis 90-Tage-Testversion:http://3.drm-x.com/Register.aspx).
Es macht nichts, wenn es leicht zu hacken ist. Mein Publikum hat da tendenziell sehr beschränkte Fähigkeiten (diese zu erweitern ist auch Ziel des Projekts) und kann zudem schlecht Deutsch und nur selten gutes Englisch. Alle können ein Smartphone bedienen, einen PC eher selten. Es gibt Ausnahmen, die problemlos eine Lösung ergooglen und umsetzen könnten. Wenn die sich lieber die Mühe machen möchten, das DRM zu hacken statt mit der Straßenbahn zu dem Geocache zu fahren, dann soll es so sein (dann haben sie auch etwas gelernt) :-) Es soll einfach nur die allerbequemste Art, sich um eine Öffi-Fahrt/einen Spaziergang zu drücken, verhindern.
Das DRM sollte also die erlaubten Kopiervorgänge auf 0 reduzieren. Soweit ich weiß, sollte es nicht schwierig sein, die Files zu verschlüsseln - aber wo tue ich den privaten Schlüssel hin? Mir scheint, Musikdownloaddienste (nicht Streaming) wie iTunes liefern den gleich mit - aber was verhindert, dass der zusammen mit der Datei weiterverteilt wird? Wird bei jeder Ausgabe ein neuer Schlüssel generiert?
Während ich dies schreibe, kommt mir die Idee, dass es einfacher sein könnte, wenn es sich um lauter verschiedene Audiofiles handelt (was genau deren Inhalt sein soll und wie damit weiter verfahren wird, ist noch eine andere Frage)... naja, so weit reicht mein Latein einfach noch nicht. Wer hat Ideen oder etwas möglichst konzises zum Nachlesen?
Vielen Dank fürs Lesen und liebe Grüße, Benjamin
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
Manche Bluetooth-Low Energy Beacons k�nnen s.g. ephemeral IDs (zb Eddystone) erzeugen. dh, man hat zb alle 30-60 sekunden eine neue ID (generiert aus einem start-Seed, �hnlich wie RSA tokens). Damit kann eine App (bzw der Server) �berpr�fen, dass jemand tats�chlich zum entsprechenden Zeitpunkt Vor-ort war, und bekommt evt auch andere Dateien ausgeliefert. Fr�her ging das nur via APP, aber neuerdings sollte das sogar via Bluetooth-API aus dem Chrome funktionieren. Afaik, aber beides nur auf Android. F�r NFC kenne ich bisher keine L�sung mit Ephemeral IDs, und QR codes w�ren sowieso statisch. Wenn du keine App verwendest (sondern nur einen Webbrowser) kannst du ja ein Login fordern und dann personalisierte Dateien zur�ckliefern; du kannst dir aber nicht sicher sein, dass jemand sein Passwort weitergegeben hat (evt statistisch untersuchen, ob gleiches Handy, usw). Wenn du 100% DRM haben m�chtest, dann gibt es das nicht - du kannst nur daf�r sorgen, dass die Umgehnung deiner Verschleierungsma�nahmen in keinem vern�nftigen Verh�ltnis zum potentiellen Gewinn steht. Dann ist es automatisch uninteressant den Aufwand f�r ein bisschen Schummeln zu betreiben. lg, Adrian On 2017-04-14 19:35, Chris Hager wrote:
Hallo,
Ich kann mich aus Erfahrung den bisherigen Meinungen nur anschlie�en.
Wenn ihr nicht ausgiebig Programmiererfahrung habt w�rde ich auch aufpassen das Projekt so einfach wie m�glich zu halten! Ansonsten l�uft ihr gr��te Gefahr euch in technischen Details zu verlieren die nicht wirklich notwendig sind und nie fertig werden.
Ich denke eine mobile App zu implementieren, die On-Demand die Soundfiles aus dem Netz raus-streamed w�re schon einmal recht einfach, angenommen der Server spuckt einfach den Audiostream unverschl�sselt aus. Oder mit einem fixen vorprogrammierten Secret-Key obfuscated. Aber aufpassen -- alle Apps k�nnen sehr einfach reverse engineered werden und vorausgelieferte Secret Keys k�nnen immer ausgelesen werden. Es w�re wohl das einfachste, die files einfach mit einem gewissen secret zu XOR-en und als File auf der SD Karte zu hinterlegen. Das ist sehr wenig Aufwand, braucht aber schon technisch etwas know-how um die Daten zu de-obfuscaten und mit anderen zu sharen.
Ich denke da ist f�r euch der Sweet-Spot zwischen Geheimhaltung und Aufwand nicht explodieren lassen. Einfach obfuscaten mit einem in der app vorprogrammieren Secret-Key. Dieser Secret Key k�nnte auch bei App-Start generiert werden, und von der App in einem vom OS bereitgestellten Secret-Storage hinterlegt werden.
LG, Chris
2017-04-14 16:38 GMT+02:00 Benjamin Oppermann <ben.opp@eml.cc <mailto:ben.opp@eml.cc>>:
Hallo, Ich war unl�ngst erstmals im Metalab anl�sslich des Mediawiki-Workshops, es hat mir alles sehr gut gefallen und jetzt wollte ich mich mal listenm��ig bei euch einklinken! :-) Kleine Frage vorab zu dieser Liste: Auf der Anmeldeseite steht, die Liste wird �ffentlich indexiert - die E-Mailadressen sind aber nicht sichtbar, oder? Wenn ich mich ein wenig vorstellen m�chte, aber nicht dem ganzen Internetz, sondern nur dem Publikum von Metalab, dann nicht hier...?
Mein aktuelles Thema: Ich habe eine momentan noch sehr vage Idee f�r eine kleines Deutschlernprojekt f�r Jugendliche, gemischt mit Geocaching, Openstreetmaps, mobile Apps... Kurz erkl�rt, man soll eine Audiodatei, die z.B. eine Deutschlektion enth�lt von einem Geocache irgendwo in Wien abholen. Dort spielt man sie per NFC/Bluetooth aufs Telefon. Der Geocache macht nix anderes, als diese Audiofiles auszuspucken (manchmal hats schon im �ffentlichen Raum schon Plakatw�nde gegeben, die sowas gemacht haben). Das Problem dabei ist, jeder, der an der Sache teilnimmt, soll sich pers�nlich dorthin begeben um seine Datei abzuholen. Ich m�chte verhindern, dass einfach einer der Sch�ler dorthin f�hrt und die Datei dann an den Rest der Gruppe weiterverteilt. Die Datei soll also auf dem Ger�t bleiben, mit dem man sie geholt hat bzw. nur dort abspielbar sein.
In anderen Worten, wie baue ich mir mein eigenes Mini-DRM?
Ich habe quasi keine Programmierf�higkeiten - mein Kollege, der vielleicht mitbasteln wird, kann einige Basics - ich arbeite, soweit es geht, auf Linuxger�ten und kann mit guter Dokumentation einfachere CLI-Programme bedienen.
Ich habe kein Geld f�r teure kommerzielle L�sungen (obwohl habe etwas gefunden mit einer gratis 90-Tage-Testversion:http://3.drm-x.com/Register.aspx <http://3.drm-x.com/Register.aspx>).
Es macht nichts, wenn es leicht zu hacken ist. Mein Publikum hat da tendenziell sehr beschr�nkte F�higkeiten (diese zu erweitern ist auch Ziel des Projekts) und kann zudem schlecht Deutsch und nur selten gutes Englisch. Alle k�nnen ein Smartphone bedienen, einen PC eher selten. Es gibt Ausnahmen, die problemlos eine L�sung ergooglen und umsetzen k�nnten. Wenn die sich lieber die M�he machen m�chten, das DRM zu hacken statt mit der Stra�enbahn zu dem Geocache zu fahren, dann soll es so sein (dann haben sie auch etwas gelernt) :-) Es soll einfach nur die allerbequemste Art, sich um eine �ffi-Fahrt/einen Spaziergang zu dr�cken, verhindern.
Das DRM sollte also die erlaubten Kopiervorg�nge auf 0 reduzieren. Soweit ich wei�, sollte es nicht schwierig sein, die Files zu verschl�sseln - aber wo tue ich den privaten Schl�ssel hin? Mir scheint, Musikdownloaddienste (nicht Streaming) wie iTunes liefern den gleich mit - aber was verhindert, dass der zusammen mit der Datei weiterverteilt wird? Wird bei jeder Ausgabe ein neuer Schl�ssel generiert?
W�hrend ich dies schreibe, kommt mir die Idee, dass es einfacher sein k�nnte, wenn es sich um lauter verschiedene Audiofiles handelt (was genau deren Inhalt sein soll und wie damit weiter verfahren wird, ist noch eine andere Frage)... naja, so weit reicht mein Latein einfach noch nicht. Wer hat Ideen oder etwas m�glichst konzises zum Nachlesen?
Vielen Dank f�rs Lesen und liebe Gr��e, Benjamin
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at <mailto:Metalab@lists.metalab.at> https://lists.metalab.at/mailman/listinfo/metalab <https://lists.metalab.at/mailman/listinfo/metalab>
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
On Fri, Apr 14, 2017 at 08:00:15PM +0200, Adrian Dabrowski wrote:
Wenn du 100% DRM haben möchtest, dann gibt es das nicht - du kannst nur dafür sorgen, dass die Umgehnung deiner Verschleierungsmaßnahmen in keinem vernünftigen Verhältnis zum potentiellen Gewinn steht. Dann ist es automatisch uninteressant den Aufwand für ein bisschen Schummeln zu betreiben.
Aber reden wir nicht von Jugendlichen? Da kann sich die Bewertung von "vernünftig" schon ganz schön in absurde Höhen versteigen ;) hop -- Q.E.Duh.
Am Fr, 14. Apr 2017, um 20:10, schrieb Christoph Schindler:
Aber reden wir nicht von Jugendlichen? Da kann sich die Bewertung von "vernünftig" schon ganz schön in absurde Höhen versteigen ;)
Haha, gutes Argument! Kann aber auch in absurd niedrige Tiefen gehen - da liegt eher meine Sorge. Wie gesagt, wenn jemand irgendeinen größeren Aufwand treiben möchte, dann ist mein Ziel eh erreicht. Es soll nur nicht einer mit ein paar lässigen Tastendrücken die Aufgabe für alle lösen. Wenn er das wirklich möchte, soll ihn das mindestens eine Stunde Getüftel kosten.
Am Fr, 14. Apr 2017, um 20:00, schrieb Adrian Dabrowski:
Manche Bluetooth-Low Energy Beacons können s.g. ephemeral IDs (zb Eddystone) erzeugen. dh, man hat zb alle 30-60 sekunden eine neue ID (generiert aus einem start-Seed, ähnlich wie RSA tokens). Damit kann eine App (bzw der Server) überprüfen, dass jemand tatsächlich zum entsprechenden Zeitpunkt Vor-ort war, und bekommt evt auch andere Dateien ausgeliefert.
Sind die halbwegs leistbar, solche Bluetooth-Beacons?
Früher ging das nur via APP, aber neuerdings sollte das sogar via Bluetooth-API aus dem Chrome funktionieren. Afaik, aber beides nur auf Android.
Nur Chrome oder auch andere Browser? Chromium, Firefox? Hm, also mindestens iOS muss auch klappen. Was in Android klappt, geht dann wahrsch. auch in Blackberry, Sailfish etc (eh nur für mich selbst relevant, haha). Nur Windows Phone wird wohl außen vor bleiben (diese Deppen mit ihren hartnäckigen Alleingang-Technologien).
Für NFC kenne ich bisher keine Lösung mit Ephemeral IDs, und QR codes wären sowieso statisch.
Wenn du keine App verwendest (sondern nur einen Webbrowser) kannst du ja ein Login fordern
Oder evtl einen personalisierten Link, der nur einmal geht? LG Ben
Hi! Unsere Firma hat so eine App/Ecosystem gebaut, die recht genau das können sollte was ihr braucht. Unsere Annahme war aber a bissi anders: die Abenteuer/Geschichten und die Integration müssen so gut sein, dass die Leute, die schwindeln halt die Immersion einbüßen. Meiner Meinung nach sollte das Geld, dass ihr in DRM stecken wollts, lieber in guten Content investieren. Gute Geschichtenschreiber, Grafiker und Sprecher sind ihr Geld wert und die ehrlichen "Endkunden" haben davon auch was :) Hab die noch eine andere Mail vom Firmenaccount geschrieben. Für alle anderen: die Firma heißt Locandy und mein Chef hat da mal eine "Pub Tour Wien" gebaut. Grüße aus Innsbruck, LG Romedius On 2017-04-14 20:42, Benjamin Oppermann wrote:
Am Fr, 14. Apr 2017, um 20:00, schrieb Adrian Dabrowski:
Manche Bluetooth-Low Energy Beacons können s.g. ephemeral IDs (zb Eddystone) erzeugen. dh, man hat zb alle 30-60 sekunden eine neue ID (generiert aus einem start-Seed, ähnlich wie RSA tokens). Damit kann eine App (bzw der Server) überprüfen, dass jemand tatsächlich zum entsprechenden Zeitpunkt Vor-ort war, und bekommt evt auch andere Dateien ausgeliefert.
Sind die halbwegs leistbar, solche Bluetooth-Beacons?
Früher ging das nur via APP, aber neuerdings sollte das sogar via Bluetooth-API aus dem Chrome funktionieren. Afaik, aber beides nur auf Android.
Nur Chrome oder auch andere Browser? Chromium, Firefox?
Hm, also mindestens iOS muss auch klappen. Was in Android klappt, geht dann wahrsch. auch in Blackberry, Sailfish etc (eh nur für mich selbst relevant, haha). Nur Windows Phone wird wohl außen vor bleiben (diese Deppen mit ihren hartnäckigen Alleingang-Technologien).
Für NFC kenne ich bisher keine Lösung mit Ephemeral IDs, und QR codes wären sowieso statisch.
Wenn du keine App verwendest (sondern nur einen Webbrowser) kannst du ja ein Login fordern
Oder evtl einen personalisierten Link, der nur einmal geht?
LG Ben
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
Am Fr, 14. Apr 2017, um 19:35, schrieb Chris Hager:
Hallo,
Ich kann mich aus Erfahrung den bisherigen Meinungen nur anschließen.
Wenn ihr nicht ausgiebig Programmiererfahrung habt würde ich auch aufpassen das Projekt so einfach wie möglich zu halten!
Ja, Bitte! Weniger ist mehr!
Ich denke eine mobile App zu implementieren
Oder eine mobile Website? Hätte auch den Vorteil von X-platform... Glaube nicht, dass wirs schaffen, eine App selber zu bauen.
die On-Demand die Soundfiles aus dem Netz raus-streamed
streamT (bin Lehrer, bitte entschuldige...)!
wäre schon einmal recht einfach, angenommen der Server spuckt einfach den Audiostream unverschlüsselt aus.
Klingt eigentlich genial!!! Aber der Stream sollte schon auf demselben Gerät wiederholt (unendlich oft) abspielbar sein. Kann man dann nicht trotzdem einfach einen Link zu dem Stream per Whatsapp versenden?
Oder mit einem fixen vorprogrammierten Secret-Key obfuscated. Aber aufpassen -- alle Apps können sehr einfach reverse engineered werden und vorausgelieferte Secret Keys können immer ausgelesen werden.
Solche Maßnahmen sind schon aufwändig genug für meine Zwecke, d.h. die Implemetierung ist sicher genug, wenn spezielle Apps fürs Auslesen des Schlüssels oder sogar Reverse Engineering (!!) nötig sind! :-)
Es wäre wohl das einfachste, die files einfach mit einem gewissen secret zu XOR-en und als File auf der SD Karte zu hinterlegen. Das ist sehr wenig Aufwand, braucht aber schon technisch etwas know-how um die Daten zu de-obfuscaten und mit anderen zu sharen. Ich denke da ist für euch der Sweet-Spot zwischen Geheimhaltung und Aufwand nicht explodieren lassen. Einfach obfuscaten mit einem in der app vorprogrammieren Secret-Key. Dieser Secret Key könnte auch bei App- Start generiert werden, und von der App in einem vom OS bereitgestellten Secret-Storage hinterlegt werden.
Also lässt sich so eine Lösung nicht via Web machen, nehme ich an? Zwei Apps für iOS UND Android machen kommt nicht in Frage (Aufwand: "KABOOOM!").
Hey, Es ist immer schön neue Leute mit interessanten Ideen kennen zu lernen, vielleicht läuft man sich im Metalab ja mal über den Weg. Der Begriff DRM hat nicht nur eine technische sondern leider auch politische Komponente. Die damit verbundenen substantiellen Eingriffe in die Grundrechte der Konsumenten/Anwender ist mit der Hacker-Ethik meiner Auffassung nach keinesfalls vereinbar. [1][2][3] Es wäre deutlich weniger verfänglich technische Begriffe wie z.B. obfuscation oder Kryptographie zu verwenden. Eine gute Herangehensweise wäre zum Beispiel die Projektidee in eine Richtung zu entwickeln, sodass obfuscation von der Spielmechanik her nicht mehr erforderlich ist. Vielleicht wäre es sogar pädagogisch sinnvoll dieses Projekt als Gelegenheit zu nutzen Medienkompetenzen zu fördern. lg. uniq [1] http://www.catb.org/jargon/html/H/hacker-ethic.html [2] https://www.defectivebydesign.org/what_is_drm_digital_restrictions_managemen... [3] https://en.wikipedia.org/wiki/Digital_rights_management#Opposition On 14.04.2017 16:38, Benjamin Oppermann wrote:
Hallo, Ich war unlängst erstmals im Metalab anlässlich des Mediawiki-Workshops, es hat mir alles sehr gut gefallen und jetzt wollte ich mich mal listenmäßig bei euch einklinken! :-) Kleine Frage vorab zu dieser Liste: Auf der Anmeldeseite steht, die Liste wird öffentlich indexiert - die E-Mailadressen sind aber nicht sichtbar, oder? Wenn ich mich ein wenig vorstellen möchte, aber nicht dem ganzen Internetz, sondern nur dem Publikum von Metalab, dann nicht hier...?
Mein aktuelles Thema: Ich habe eine momentan noch sehr vage Idee für eine kleines Deutschlernprojekt für Jugendliche, gemischt mit Geocaching, Openstreetmaps, mobile Apps... Kurz erklärt, man soll eine Audiodatei, die z.B. eine Deutschlektion enthält von einem Geocache irgendwo in Wien abholen. Dort spielt man sie per NFC/Bluetooth aufs Telefon. Der Geocache macht nix anderes, als diese Audiofiles auszuspucken (manchmal hats schon im öffentlichen Raum schon Plakatwände gegeben, die sowas gemacht haben). Das Problem dabei ist, jeder, der an der Sache teilnimmt, soll sich persönlich dorthin begeben um seine Datei abzuholen. Ich möchte verhindern, dass einfach einer der Schüler dorthin fährt und die Datei dann an den Rest der Gruppe weiterverteilt. Die Datei soll also auf dem Gerät bleiben, mit dem man sie geholt hat bzw. nur dort abspielbar sein.
In anderen Worten, wie baue ich mir mein eigenes Mini-DRM?
Ich habe quasi keine Programmierfähigkeiten - mein Kollege, der vielleicht mitbasteln wird, kann einige Basics - ich arbeite, soweit es geht, auf Linuxgeräten und kann mit guter Dokumentation einfachere CLI-Programme bedienen.
Ich habe kein Geld für teure kommerzielle Lösungen (obwohl habe etwas gefunden mit einer gratis 90-Tage-Testversion:http://3.drm-x.com/Register.aspx).
Es macht nichts, wenn es leicht zu hacken ist. Mein Publikum hat da tendenziell sehr beschränkte Fähigkeiten (diese zu erweitern ist auch Ziel des Projekts) und kann zudem schlecht Deutsch und nur selten gutes Englisch. Alle können ein Smartphone bedienen, einen PC eher selten. Es gibt Ausnahmen, die problemlos eine Lösung ergooglen und umsetzen könnten. Wenn die sich lieber die Mühe machen möchten, das DRM zu hacken statt mit der Straßenbahn zu dem Geocache zu fahren, dann soll es so sein (dann haben sie auch etwas gelernt) :-) Es soll einfach nur die allerbequemste Art, sich um eine Öffi-Fahrt/einen Spaziergang zu drücken, verhindern.
Das DRM sollte also die erlaubten Kopiervorgänge auf 0 reduzieren. Soweit ich weiß, sollte es nicht schwierig sein, die Files zu verschlüsseln - aber wo tue ich den privaten Schlüssel hin? Mir scheint, Musikdownloaddienste (nicht Streaming) wie iTunes liefern den gleich mit - aber was verhindert, dass der zusammen mit der Datei weiterverteilt wird? Wird bei jeder Ausgabe ein neuer Schlüssel generiert?
Während ich dies schreibe, kommt mir die Idee, dass es einfacher sein könnte, wenn es sich um lauter verschiedene Audiofiles handelt (was genau deren Inhalt sein soll und wie damit weiter verfahren wird, ist noch eine andere Frage)... naja, so weit reicht mein Latein einfach noch nicht. Wer hat Ideen oder etwas möglichst konzises zum Nachlesen?
Vielen Dank fürs Lesen und liebe Grüße, Benjamin
_______________________________________________ Metalab mailing list Metalab@lists.metalab.at https://lists.metalab.at/mailman/listinfo/metalab
Teilnehmer (7)
-
Adrian Dabrowski -
Benjamin Oppermann -
Chris Hager -
Christoph Schindler -
overflo -
Romedius Weiss -
uniq