[liberationtech] Iran blocks MP3, MP4, AVI and SWF files

[Fran Parker]

Maybe this is a given but, would it be easier to just zip or tar.gz the 
mp3, mp4 or avi files, maybe even the swfs (they could then drag/drop on 
a browser window locally)? Could even password protect the zip files if 
that would be helpful and not throw up any flags.

It wouldn't help with audio streaming, or video files that can't be 
captured and saved, but could be helpful for static files and those that 
can be snagged one way or another. Many streaming video can be 
downloaded one way or another and made available as zips or tar.gz, etc.

The real problem would be any apps that depend on mp3 or video file 
links in their native condition especially in a streaming manner, I guess.



On 10/6/12 6:30 PM, Collin Anderson wrote:
>>
>> So maybe, just throwing away the Content-Type header from an HTTP
>> responses, could still allow the browser to identify/access the data, while
>> avoiding the Iranian filter to detect it?
>
>
> That is solid advice, however, I suspect most the streaming media sites
> that would pay such special attention to Iran are likely already, directly
> blocked. Moreover, another percentage of them are probably located on CDNs
> or shared hosts where they don't have such control. Such time may be more
> efficiently allocated to push people into anti-filter and anonymity tools.
>
> The value of the Toman to the American Dollar is 25% of what it was last
> year, foreign bank accounts are being closed due to US/EU sanctions, the
> government is not clear on why it blocked Google for a week, DNS is being
> hijacked and now people cannot access audio/video/flash media -- if tool
> makers cannot sell the Iranian public on their free services now, man I
> don't know.
>
>
>
> On Sat, Oct 6, 2012 at 4:45 PM, Fabio Pietrosanti (naif) <
> lists at infosecurity.ch> wrote:
>
>>   On 10/6/12 10:36 PM, Collin Anderson wrote:
>>
>>   File extension in URL requested, Content-Type or are they even finding
>>> their own Content-Type?
>>
>>
>>   You are correct, all that it took to trigger the blocking was a php file
>> with the following:
>>
>>   header("Content-Type: audio/mpeg");
>>
>> The server was adding the content-type header to the returned request
>> because of the file extension.
>>
>>
>> Ok.
>>
>> Many modern browser have their own way to detect mime content type, what
>> is called "mime sniffing", regardless of what the server say:
>>
>> * MSIE http://msdn.microsoft.com/en-us/library/ms775148%28v=vs.85%29.aspx
>> * Mozilla
>> https://developer.mozilla.org/en-US/docs/How_Mozilla_determines_MIME_Types
>> * Chrome
>> http://neugierig.org/software/chromium/notes/2009/01/mime-sniffing.html
>>
>> So maybe, just throwing away the Content-Type header from an HTTP
>> responses, could still allow the browser to identify/access the data, while
>> avoiding the Iranian filter to detect it?
>>
>> -naif
>>
>> --
>> Unsubscribe, change to digest, or change password at:
>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>
>
>
>
>
>
> --
> Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
>