[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

Read binary file

Herbert Kleebauer

3/16/2016 10:21:00 PM

There is a picture (1.jpg) on web server A and I want to make
a modified version available using a web server B. Because
of copyright I can't just copy the picture, modify it and
store it on server B. Instead a html file (test.htm) and
a data file which describes how the picture has to be
modified (diff.dat) is stored on server B. When a user
loads the html file into his browsers, the javascript code
loads the original picture from server A and the modification
file from server B, changes the picture and displays it.

I'm not familiar with javascript, but with help of Google
I hacked together a few lines of code. But it only works if
all three files are on the same server:

http://ikomi.de/tes...
http://ikomi.de/...
http://ikomi.de/tes...


If the picture is on a different server, there seems to be
an access violation. How can I avoid this violation or in
which other way can I read a binary file from a different
web server into a javascript array.



<html><head><title>jpg</title>
<script type="text/javascript">

function load_binary_resource(url) {
var req = new XMLHttpRequest();
req.open('GET', url, false);
req.overrideMimeType('text\/plain; charset=x-user-defined');
req.send(null);
if (req.status != 200) return '';
return req.responseText;}

var original = load_binary_resource("http://ikomi.de/...");
var diff = load_binary_resource("http://ikomi.de/tes...");

data='';
for (i = 0; i < diff.length; i++) {
m=i%original.length;
data += String.fromCharCode((original.charCodeAt(m)^diff.charCodeAt(i))&0xff);}

document.write('<img src="data:image/jpg;base64,');
document.write(btoa(data));
document.write('">');

</script></head><body></body></html>
47 Answers

Thomas 'PointedEars' Lahn

3/17/2016 12:05:00 AM

0

Herbert Kleebauer wrote:

> There is a picture (1.jpg) on web server A and I want to make
> a modified version available using a web server B. Because
> of copyright I can't just copy the picture, modify it and
> store it on server B. Instead a html file (test.htm) and
> a data file which describes how the picture has to be
> modified (diff.dat) is stored on server B. When a user
> loads the html file into his browsers, the javascript code
> loads the original picture from server A and the modification
> file from server B, changes the picture and displays it.

Your logic is flawed. Either there it is a copyright violation to create a
modified version of the original, or there is not. If there is a copyright
violation, then no matter how you create the modified version, the issue
remains: publishing the modified version would be a copyright violation.
If there is no copyright violation with copying and modifying the original,
then there is no need to go to great lengths to do the modification.

I suggest that you at least read <https://en.wikipedia.org/wiki/Cop...
to get an idea if the publication of the modified version would constitute a
copyright violation in the first place (I would suggest consulting a
copyright lawyer as well depending on the presumed value of the original
work and the fees to be expected from you or the organization you are
working for in case of a possible copyright violation).

> I'm not familiar with javascript,

There is no javascript.

> but with help of Google
> I hacked together a few lines of code. But it only works if
> all three files are on the same server:
>
> http://ikomi.de/tes...
> http://ikomi.de/...
> http://ikomi.de/tes...
>
>
> If the picture is on a different server, there seems to be
> an access violation. How can I avoid this violation

You cannot. The whole point of the Same Origin Policy is to prevent people
from doing things like what you attempted.

> or in which other way can I read a binary file from a different
> web server into a javascript array.

I know how (it is actually trivial if you think it through), but until I am
certain that you are not attempting a copyright violation through the back
door, I will not say.

IANAL.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

ram

3/17/2016 12:16:00 AM

0

Herbert Kleebauer <klee@unibwm.de> writes:
> How can I avoid this violation or in
>which other way can I read a binary file from a different
>web server into a javascript array.

The server can responds with »Access-Control-Allow-Origin: *«,
which means that the resource can be accessed by any domain
in a cross-site manner.

See

developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

.

Thomas 'PointedEars' Lahn

3/17/2016 1:24:00 AM

0

Stefan Ram wrote:

> Herbert Kleebauer <klee@unibwm.de> writes:
>> How can I avoid this violation or in
>>which other way can I read a binary file from a different
>>web server into a javascript array.
>
> The server can responds with »Access-Control-Allow-Origin: *«,
> which means that the resource can be accessed by any domain
> in a cross-site manner.
>
> See
>
> developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Context is important. AIUI, he wants to access on *his* site B a *foreign*
resource A without its authorâ??s knowledge, meaning that the foreign resource
does not have this header field set, and the original author cannot be
convinced to have it set. If it had it set, he would not have the SOP
problem, and would not look for alternatives, in the first place.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Stefan Weiss

3/17/2016 1:35:00 AM

0

On 03/17/2016 01:04, Thomas 'PointedEars' Lahn wrote:
> Herbert Kleebauer wrote:
>> If the picture is on a different server, there seems to be
>> an access violation. How can I avoid this violation
>
> You cannot. The whole point of the Same Origin Policy is to prevent people
> from doing things like what you attempted.

The same-origin policy is a security feature; it has nothing to do with
copyright.

>> or in which other way can I read a binary file from a different
>> web server into a javascript array.
>
> I know how (it is actually trivial if you think it through), but until I am
> certain that you are not attempting a copyright violation through the back
> door, I will not say.

I'm curious. Without CORS, I can't think of a way to get a byte array
from an image on a different server. XHR won't work, and neither will
image â?? canvas â?? data. What's the trivial solution?


- stefan

Thomas 'PointedEars' Lahn

3/17/2016 6:56:00 AM

0

Stefan Weiss wrote:

> On 03/17/2016 01:04, Thomas 'PointedEars' Lahn wrote:
>> Herbert Kleebauer wrote:
>>> If the picture is on a different server, there seems to be
>>> an access violation. How can I avoid this violation
>>
>> You cannot. The whole point of the Same Origin Policy is to prevent
>> people from doing things like what you attempted.
>
> The same-origin policy is a security feature; it has nothing to do with
> copyright.

Learn to read.

>>> or in which other way can I read a binary file from a different
>>> web server into a javascript array.
>>
>> I know how (it is actually trivial if you think it through), but until I
>> am certain that you are not attempting a copyright violation through the
>> back door, I will not say.
>
> I'm curious. Without CORS, I can't think of a way to get a byte array
> from an image on a different server. XHR won't work, and neither will
> image â?? canvas â?? data. What's the trivial solution?

Nice try.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Herbert Kleebauer

3/17/2016 7:32:00 AM

0

On 17.03.2016 01:04, Thomas 'PointedEars' Lahn wrote:
> Herbert Kleebauer wrote:
>
>> There is a picture (1.jpg) on web server A and I want to make
>> a modified version available using a web server B. Because
>> of copyright I can't just copy the picture, modify it and
>> store it on server B. Instead a html file (test.htm) and
>> a data file which describes how the picture has to be
>> modified (diff.dat) is stored on server B. When a user
>> loads the html file into his browsers, the javascript code
>> loads the original picture from server A and the modification
>> file from server B, changes the picture and displays it.
>
> Your logic is flawed. Either there it is a copyright violation to create a
> modified version of the original, or there is not. If there is a copyright
> violation, then no matter how you create the modified version, the issue
> remains: publishing the modified version would be a copyright violation.

You didn't understand the scenario. Server B only provides the
information where to find the original picture and how to
modify it. Server B never downloads a version of the picture
nor stores a modified version of it. It is the web user on
his own PC who downloads this information and the original
picture and does the modification on-the-fly (no version of
the modified picture is written to the hard disk on the
users PC). Suppose the Server B provides this information:
"download the picture http://ikomi.de/... and
increase brightness by 10% and decrease contrast by 5%".
Why does this violate any copyright?

Instead I could provide a batch script on Server B, which,
when executed on the users PC, will use wget to download the
picture and then use a scriptable image editor (like ImageMagicks
convert.exe) to do the modification. But it would be much
simpler to just use a web browser.

>> I'm not familiar with javascript,
>
> There is no javascript.

???????????


>> or in which other way can I read a binary file from a different
>> web server into a javascript array.
>
> I know how (it is actually trivial if you think it through),

I'm not even sure what the problem is. Does the browser refuse
to read data from a different server than the html file was read
for security reasons or does server A refuse to deliver the
picture because of a referer header.

Herbert Kleebauer

3/17/2016 7:42:00 AM

0

On 17.03.2016 01:16, Stefan Ram wrote:


> developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Thanks for the link.

Thomas 'PointedEars' Lahn

3/17/2016 6:11:00 PM

0

Herbert Kleebauer wrote:

> On 17.03.2016 01:04, Thomas 'PointedEars' Lahn wrote:
>> Herbert Kleebauer wrote:
>>> There is a picture (1.jpg) on web server A and I want to make
>>> a modified version available using a web server B. Because
^^^^^^^
>>> of copyright I can't just copy the picture, modify it and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> store it on server B. Instead a html file (test.htm) and
^^^^^^^^^^^^^^^^^^^^^
>>> a data file which describes how the picture has to be
>>> modified (diff.dat) is stored on server B. When a user
>>> loads the html file into his browsers, the javascript code
>>> loads the original picture from server A and the modification
>>> file from server B, changes the picture and displays it.
>>
>> Your logic is flawed. Either there it is a copyright violation to create
>> a modified version of the original, or there is not. If there is a
>> copyright violation, then no matter how you create the modified version,
>> the issue remains: publishing the modified version would be a copyright
>> violation.
>
> You didn't understand the scenario.

ACK, your claim confused me (see below), therefore I misread.

> [â?¦]
> Suppose the Server B provides this information:
> "download the picture http://ikomi.de/... and
> increase brightness by 10% and decrease contrast by 5%".
> Why does this violate any copyright?

Of itself it does not. You were the one claiming that it would. However,
whether the whole use-case could constitute a copyright violation depends
on the extent of the modification and who has access to the modified
version.

> Instead I could provide a batch script on Server B, which,
> when executed on the users PC, will use wget to download the
> picture and then use a scriptable image editor (like ImageMagicks
> convert.exe) to do the modification. But it would be much
> simpler to just use a web browser.

The Canvas API appears to be what you are looking for:

<https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Pixel_manipulation_with_...

(CORS obviously cannot help you there as you do not control the server of
the original work.)

>>> I'm not familiar with javascript,
>> There is no javascript.
>
> ???????????

See the reference to the â??ES Matrixâ? in my signature.

>>> or in which other way can I read a binary file from a different
>>> web server into a javascript array.
>> I know how (it is actually trivial if you think it through),

(JFTR: Canvas is not what I meant with this. I had not thought of that
possibility at the time.)

> I'm not even sure what the problem is. Does the browser refuse
> to read data from a different server than the html file was read
> for security reasons or does server A refuse to deliver the
> picture because of a referer header.

No. STFW for â??Same Origin Policyâ?.

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.

Stefan Weiss

3/17/2016 6:59:00 PM

0

Thomas 'PointedEars' Lahn wrote:
> Herbert Kleebauer wrote:
>> Suppose the Server B provides this information:
>> "download the picture http://ikomi.de/... and
>> increase brightness by 10% and decrease contrast by 5%".
[...]

> The Canvas API appears to be what you are looking for:
>
> <https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Pixel_manipulation_with_...
>
> (CORS obviously cannot help you there as you do not control the server of
> the original work.)

As I mentioned earlier, this does not work cross-origin without CORS.
Adding image data from server A to the canvas will taint it, preventing
data extraction and manipulation.

>>> I know how (it is actually trivial if you think it through),
>
> (JFTR: Canvas is not what I meant with this. I had not thought of that
> possibility at the time.)

So, now that the copyright situation has been explained, what's the
trivial solution?


- stefan

Thomas 'PointedEars' Lahn

3/17/2016 8:39:00 PM

0

Stefan Weiss wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Herbert Kleebauer wrote:
>>> Suppose the Server B provides this information:
>>> "download the picture http://ikomi.de/... and
>>> increase brightness by 10% and decrease contrast by 5%".
> [...]
>
>> The Canvas API appears to be what you are looking for:
>>
>> <https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Pixel_manipulation_with_...
>>
>> (CORS obviously cannot help you there as you do not control the server of
>> the original work.)
>
> As I mentioned earlier, this does not work cross-origin without CORS.

Indeed. The Canvas tutorial should be updated with that information.

> Adding image data from server A to the canvas will taint it, preventing
> data extraction and manipulation.

Yes, but:

The Same Origin Policy (SOP) does not depend on the server; it depends on
protocol and domain names, and port numbers.

Therefore:

> >>> I know how (it is actually trivial if you think it through),
> > (JFTR: Canvas is not what I meant with this. I had not thought of that
> > possibility at the time.)
>
> So, now that the copyright situation has been explained, what's the
> trivial solution?

Transparent HTTP proxying with mod_rewrite, mod_proxy, mod_proxy_http &
friends. If the Web browser does not know that a resource has a different
origin, the SOP does not apply. WFM with Apache/2.4.18 (Debian) in Chrome
â??46.0.2490.71 Built on 8.2, running on Debian stretch/sid (64-bit)â? (which
would without proxying and CORS block access precisely as you described).

--
PointedEars
FAQ: <http://PointedEars.... | SVN: <http://PointedEars.de...
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-...
Please do not cc me. / Bitte keine Kopien per E-Mail.