Re: Examining the 'no server modification' requirement

The no-server-modification requirement originally arose in the voice browser working group due to the practical experience of the participant companies that in many large IT-based companies, the website environment is a shared environment that supports segmented ownership of documents and content, but not segmented ownership of website configuration.  Given this is a per-resource policy, it made sense to associate the policy meta-data directly with the resource.  This is why the original NOTE only focused on the Processing Instruction and did not include the HTTP headers.  

Further, there are a number of cases that voice browser working group participants identified where the resources are static and can be properly cached.  Proper HTTP caching was heavily used for static-only content in the voice browser realm given the tighter response time requirements expected on the phone.  Therefore, requiring server validation would potentially require sites to invoke a dynamic pathway for static XML data, or worse eliminate effective caching altogether.  

The alternative server-based security model hadn't been proposed at that time, and the prevailing assumption in 2005/2006 was that the browser was responsible for the sandboxing, and any modification to same-origin was a modification to browser sandboxing and therefore should be addressed entirely on the browser-side.  In my observation, trends in the security space and the greater prevalence of fraudulent behavior on the web has lead to a greater emphasis on protection at the server rather than the client in the past 2 years.  Site-keys, captcha, etc being good examples.  

I think the other correlated requirement was that the existing assumptions about browser sandboxing remain valid.  Particularly, that if the server does nothing it can assume that the same-origin policy is still protecting those resources from improper access by a third-party application executing on a browser inside a protected network zone.  

I wonder to some extent if this entire debate could be addressed by including functionality in the access-control specification that would allow the server to also perform the validation if it choose?   A solution where both the browser and the server are enforcing the policy may ultimately be the strongest.  This would enable webmasters to feel like they have some control, but also prevent the browser vendors for being blamed when webservers accidentally expose all their data by improperly implementing the server-side gate.

Brad

Mark Nottingham <mnot@yahoo-inc.com> wrote: 
I'd like to take a closer look at the 'no server modification'  
requirement, because the more that I look at it, the more I don't  
understand why it should drive the architecture here.

As I understand it, the motivation for this is where a publisher wants  
to make data available cross-site, but doesn't have access to the  
server except to upload files; they cannot modify server configuration.

Looking around at the current Web hosting landscape, this is a pretty  
small set of resources. Consider;
    - Almost every commodity Web hosting provider (e.g., pair.com,  
dreamhost, 1&1, etc.) allows shell access and .htaccess modifications  
for mod_rewrite, as well as scripting, for a very small amount of money.
    - Those that don't offer shell access often still provide  
scripting (e.g., Perl, PHP). Both Moveable Type and Wordpress can be  
deployed using FTP only.
    - Even University accounts offer shell access (that's the point of  
a university account, after all), and usually offer .htaccess.

So, AFAICT, the only use case that really drives this requirement is  
for free shared hosting providers, a la GeoCities. It's not an  
adoption argument; as mentioned, MT and WP can both be deployed with  
just FTP, and their need to run an executable hasn't hindered  
deployment at all.

I'm struggling to imagine a situation where someone would want to host  
cross-site data on this type of site, being unable to do it elsewhere.  
What am I missing?

Also, from a policy standpoint, I do wonder if a site that doesn't  
allow modification of server configuration, shell access, etc. would  
want to allow cross-site requests to the things they host; AIUI most  
of these services spend considerable resources working to assure that  
their accounts aren't used for "bandwidth stealing" by already  
checking referers, etc.

Any illumination would be most appreciated.

Cheers,

--
Mark Nottingham       mnot@yahoo-inc.com