There might be a workaround, but that would depend on specifics. Quality of signal is lost in relation to distance.
Assuming you used Dropbox to transfer files, and both you and your friend were 1.000 Km of their main servers, then, the total distance run by your data would be 2.000 Km. That would mean that data would be sent slowly and received slowly.
If you can shorten that distance to the bare minimum, by using a local server (or a direct connection), then that might increase your speed, assuming it isn't low from start (i.e. if in a speedtest between the two islands, you got low speeds).
However, keep this as a rule of thumb, and not as a general rule or an absolute rule, because of what I try to explain next.
xstnc pointed out to me that this reasoning is somewhat misleading, due to the concept of Round-trip delay time (RDT) being at work. To simplify things a lot, let's assume that you're trying to transfer files using a stream-like connection. According to Beej's Guide to Network Programming:
Stream sockets are reliable two-way connected communication streams. If you output two items into the socket in the order "1, 2", they will arrive in the order "1, 2" at the opposite end. They will also be error-free. I'm so certain, in fact, they will be error-free, that I'm just going to put my fingers in my ears and chant la la la la if anyone tries to claim otherwise.
How do stream sockets achieve this high level of data transmission quality? They use a protocol called "The Transmission Control Protocol", otherwise known as "TCP" (see RFC 793 for extremely detailed info on TCP.) TCP makes sure your data arrives sequentially and error-free.
That quality has a price though. The following is referring to the second protocol used commonly on data transfer called UDP.
Why would you use an unreliable underlying protocol? Two reasons: speed and speed. It's way faster to fire-and-forget than it is to keep track of what has arrived safely and make sure it's in order and all that. If you're sending chat messages, TCP is great; if you're sending 40 positional updates per second of the players in the world, maybe it doesn't matter so much if one or two get dropped, and UDP is a good choice.
In TCP, you essentially send a neat packet of data to the other user. Then you expect him to send you a piece of information confirming that he got that packet. And so forth until the file has been received. This obviously is an incredibly slow process, that suffers from the problem of round-trip delay time (RDP).
RDP is, in a nutshell, the propagation times between the two points of a signal. In the context of computer networks, the signal is generally a data packet, and the RTD is also known as the ping time.
So, it's this delay, and not distance in itself, that is responsible for the quality of signal you get while transferring files. UDP can also suffer from the same problem, but it is offset by the sending of countless packages without regard to order or error checking, as explained in the last quote.
As Arjan pointed out, the speed your ISP delivers is a significant factor. Ultimately, your friend can't go over it's download speed and you can't go over your upload speed. Since most Internet connections tend to favor downloading to uploading (ADSL type networks), the bottleneck is on the upload speed.