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

[Collin Anderson]

>
> 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.


Same situation exists, if a site is inclined to go through all that trouble
for Iran, it's probably blocked. Time would be well spent pushing users
into privacy tools. Although, this is useful advice for people trying to
post files to places like 4shared.

Really though, there is a much more simple and universal lesson: every site
should offer SSL to its visitors. If an intermediary cannot read HTTP
headers, they have to go through a great deal of pain and barbarism to
block specific content.


On Sun, Oct 7, 2012 at 10:22 AM, Fran Parker <lilbambi at gmail.com> wrote:

> 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<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<https://developer.mozilla.org/en-US/docs/How_Mozilla_determines_MIME_Types>
>>> * Chrome
>>> http://neugierig.org/software/**chromium/notes/2009/01/mime-**
>>> sniffing.html<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<https://mailman.stanford.edu/mailman/listinfo/liberationtech>
>>>
>>>
>>
>>
>>
>>
>> --
>> Unsubscribe, change to digest, or change password at:
>> https://mailman.stanford.edu/**mailman/listinfo/**liberationtech<https://mailman.stanford.edu/mailman/listinfo/liberationtech>
>>
>>  --
> Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/**mailman/listinfo/**liberationtech<https://mailman.stanford.edu/mailman/listinfo/liberationtech>
>



-- 
*Collin David Anderson*
averysmallbird.com | @cda | Washington, D.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20121007/496a0f02/attachment.html>