Re: Global Namespaces

[Chris Travers <..hidden..>]

On Sat, Mar 13, 2010 at 1:09 PM, Luke <..hidden..> wrote:
> On Sat, 13 Mar 2010, Chris Travers wrote:
>
>> On Sat, Mar 13, 2010 at 12:12 PM, Luke <..hidden..> wrote:
>>
>> Furthermore, if we agree that data shouldn't be saved to the db on a
>> GET request, then the XSRF benefits are the same.
>
> I guess I was thinking more along the lines of packet sniffing and
> logging.
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3

If you can sniff packets, you can pull POST data out as easily.
Really, that's an argument for using SSL, which we document as
extremely highly recommended.  Logging is discussed more below.

>
>> I guess there is a question why
>> reports/trial_balance.html?from=2009-01-01&to=2009-12-31&ignore_yearend=none
>> would be any less secure than requiring a post.
>
> In that particular case, it wouldn't.
> What about user additions and such?
> What about customer contact info?  Some of it may not be private, but if
> storing of email addresses, phone numbers, etc., or searching on them,
> causes an entry to be stored in an access log containing all of that info,
> it could potentially open up some data mining opportunities for somebody.
>
> I can't be sure that anyone would ever face a problem from any of this,
> but can you be sure that they won't?
> That aside, might there not be some compliance issues that are avoided if
> such data does not have the potential to be logged?

The logging is an issue, mostly for cases involving credit card
numbers.  I don't believe that sensitive data should ever be a part of
the URI just because that is routinely logged.  But there are so many
areas where this can happen esp. if more RESTful approaches get
implemented.....

However, one thing that John is asking for is an ability to have both
Query String parameters and post data available on the same request.
Hence getting rid of GET doesn't necessarily get rid of query-string
parameters.

Best Wishes,
Chris Travers