Firefox3/ContentManagement:Scenarios: Difference between revisions

Line 36: Line 36:


== Security Privacy ==
== Security Privacy ==
Since the mechanisms are largely the same, it seems the biggest potential differences between GET vs. POST as far as security and privacy are concerned is precisely what data can be "leaked" to a third party.  Each has it's pro's and cons
Since the mechanisms are largely the same, it seems the biggest potential differences between GET vs. POST as far as security and privacy are concerned is precisely what data can be "leaked" to a third party.  Each has its own risks:
 
* '''GET'''  
* '''GET'''  
** "Origin" -- The recipient web may know where the data originated from
** ''Origin'' -- The URI exposes where the data come from
** ''File Name'' -- In some cases, the URI could give some indicaiton of the contents of the document, e.g, "http://witehouse.gov/Bin_Laden_Determined_to_Attack_Inside_US.doc"
** ''File Name'' -- The path or filename in the URI may give some indication of its contents (e.g, "http://witehouse.gov/Bin_Laden_Determined_to_Attack_Inside_US.doc")
** '''Credentials''--  In some cases, a username and password may be embedded within a URI.
** '''Credentials''--  URI may contain a username and/or password
* '''POST'''
* '''POST'''
** ''File Contents'' -- The user may set a default handler for a file type, thinking it was fine for most cases, and then click to open a sensitive document, forgetting that it will get sent to a web app.  
** ''File Contents'' -- It is obviously the user's intent to expose the file contents... however they may have set a default web app for a file type for personal data and then later click to open a sensitive document, forgetting that it will get sent to that web app.  


   Both GET & POST need some strategy for communicating potential data leakage to user
   Both GET & POST need some strategy for communicating potential data leakage to user


= Implementation Approaches =
= Implementation Approaches =
12

edits