подавать mp3 на локальный плеер без отображения местоположения mp3

Я занимаюсь обновлением существующего приложения, написанного на флэш-памяти, для воспроизведения mp3-файлов телефонных звонков. Цель приложения — обучение сотрудников работе с клиентами. Некоторые из звонков являются «негативными» звонками и используются для обучения сотрудников тому, что НЕЛЬЗЯ делать.

Причина, по которой мне не нужно указывать местонахождение mp3, заключается в том, что если кто-то рассердится, покинет компанию и решит взять с собой некоторые негативные звонки, это будет плохо. Я никогда не хотел бы недооценивать интеллект наших пользователей, поэтому я уверен, что некоторые из них могли бы найти способ получить их, несмотря ни на что.

Текущая реализация, как я уже сказал, была написана во флэш-памяти, и она загружает все mp3-файлы по мере того, как swf-файл загружается на клиенте, тем самым уменьшая необходимость когда-либо обращаться к серверу для получения нового mp3-файла. Ни один из этих mp3-файлов не имеет большого размера, потому что все они состоят всего из 30-секундных клипов телефонных звонков.

Есть ли способы предотвратить прямую загрузку mp3 с сервера IIS. Могу ли я передать их с помощью С# в виде файла aspx, для воспроизведения которого требуется определенный хэш или соль?

Я действительно не хочу, чтобы все они были перенесены в swf, как текущая реализация, если я могу этого избежать.

любые предложения приветствуются.

ТИА


person Christopher Johnson    schedule 17.09.2013    source источник
comment
Даже с помощью приложения для флэш-памяти кто-то все еще может использовать wireshark для определения местоположения файлов. Знающий пользователь всегда сможет получить файл, потому что он должен быть локальным, чтобы иметь возможность играть локально.   -  person Daniel Hilgarth    schedule 17.09.2013


Ответы (1)


Честно говоря, если пользователь полон решимости получить данные, он это сделает. Я считаю, что баланс здесь заключается в том, в какой момент указанный гипотетический сотрудник почувствует, что выгода от получения данных не стоит усилий для их получения. И сколько усилий вам нужно пройти по сравнению с тем, сколько это стоит для компании.

Если звук всегда будет воспроизводиться в вашем приложении, одним из простых уровней безопасности будет шифрование файлов. Для простоты вы можете использовать симметричный ключ, хранить его в приложении и расшифровывать файл в памяти перед его воспроизведением (таким образом, он не сохраняется во временном файле, который пользователь может просто взять). Конечно, пользователь с 3/4 мозга, вероятно, мог бы выудить ключ из исполняемого файла, но, честно говоря, звук воспроизводится на их динамиках, и я уверен, что у них есть смартфон. Они могли так же легко записывать звук с помощью Sound Recorder, как и воспроизводить его.

Проще говоря, я считаю, что минимальный уровень технологической безопасности в сочетании с обязывающим соглашением о конфиденциальности должен дать вам достаточную защиту. Служба безопасности будет поддерживать честность тех, кто хочет быть честным, и отпугивать ленивых, а также даст вам возможность доказать, что сотрудник получил аудио нечестным путем (т. е. оно не было просто «доступно для прослушивания»).

person lc.    schedule 17.09.2013
comment
Я ценю идеи. +1. Меня интересует ваше предложение хотя бы зашифровать файлы. Я все еще нахожусь на грани того, что я хочу использовать в качестве mp3-плеера в браузере пользователя. Я действительно не хочу писать флеш-решение (я бы предпочел использовать что-то из коробки где-нибудь (например, jplayer или что-то подобное)). Я не совсем уверен, как я мог включить механизм расшифровки на стороне клиента, а затем подключить файл к системе проигрывателя. - person Christopher Johnson; 17.09.2013