OAuth, HTTP and file size limitations

In the brave new world of social file sharing HTTP(s) has won. From the humble webDAV specification to Sharepoint, IBM Connections, Dropbox, UbuntuOne or the emerging industry standard CMIS all use HTTPs to access files on the backends. Since HTTP(s) is the first thing that is available when a network connection is possible and quite often (especially in public hotspots) the only thing available, this success isn't surprising
The more venerable protocols like CIFS (a.k.a. SMB), NFS or SSHFS didn't stand a chance since (rightly?) security experts block them on the corporate firewalls to prevent data leakages.
A lot of times the HTTP integration uses basic authentication, that is hazardous on HTTP, but OK on HTTPs. However providing applications with username and password makes it an update nightmare. Therefore OAuth became rapidly popular. But every fix for a problem comes with its own challenges. The challenge here is OAuth session expiry. While this is hardly an issue getting your latest tweets (140 char transmit in less that 30sec if if you only have 10 Byte/sec), is is an issue for large files.
An open bug in UbuntuOne explains it nicely: " OAuth headers used to check the validity of the request contain the timestamp of the request to prevent reply attacks .... for requests taking less than 15 minutes (the default for oauth in updown). ". If 15 min is the default you need a lot of bandwidth depending on your file size:

• 9 kb/sec for 1 MB
• 217 kb/sec for 25MB
• 870 kb/sec for 100 MB

(That's effective bandwidth, not advertised one). Of course: you don't want to wait 15 minutes for a file, so your real bandwidth requirement might be actually much higher. And that's also the reason why online access to file sharing is nothing more than a band-aid, sync is the way to go.