Read-Only Web (ROW) is an initiative to provide users with the option to provide read-only access to Web Applications using Blue Coat Application Controls. Several of Blue Coat’s customers, primarily financial institutions, understandably have very strong Data Loss Prevention (DLP) concerns. ROW is Blue Coat’s initiative to address these concerns.
Read-only operations are all actions an end user might take that do not change application state in a meaningful way. For example, reading an email, browsing posts, or downloading files typically do not present a DLP concern, although a user may also choose to block the downloading of files for security reasons. Write-only operations are all actions an end user might take that do change application state in a meaningful way. For example, posting comments, naming an object, sending an email, or uploading a file all present a serious DLP concern.
What ROW means, in practical terms, is that users will be limited to performing read-only operations. For example, they would be able to check their external inboxes for new messages, follow social networking posts, or browse photos online, but they would not be able to send private messages through external email applications like Gmail or Yahoo! Mail, or post messages and comments in social networking applications like Facebook or Twitter.
The first Read-Only Web strategy is based on a common convention in many popular Web Applications (Desktop Browser) where read operations are denoted by the HTTP GET
, TRACE
, HEAD
, or OPTIONS
request methods and write operations are denoted by the HTTP POST
, PUT
, or DELETE
request methods. Read and write request methods are defined in the HTTP 1.1 specification (specifically RFC 2616).
Blocking write request methods has the following advantages:
Blocking write request methods has the following disadvantages:
POST
request method for both read and write operations.Blocking write operations has the following advantages:
POST
request method for both read and write operations.Blocking write operations has the following disadvantages:
*For an up-to-date list, please see Operation Descriptions.
Blocking write request methods is a suitable DLP solution if an application meets two criteria:
Based upon these criteria, Blue Coat has identified the following Web Applications (Desktop Browser) that support ROW by request method. In addition to the Web Apps noted below, any application that meets the above criteria can implement ROW using straightforward policy (see the policy examples below).
Apps that Support ROW by Request Method | ||
Application Name | Overblocks | Underblocks |
Yes | No | |
Yes | Yes | |
No | No | |
YouTube | Yes | Yes |
Rationale: Blocking write request methods renders this application read-only with minimal overblocking.
Underblocks: N/A
Overblocks:
Rationale: Blocking write request methods renders this application read-only with minimal overblocking and underblocking.
Overblocks: Breaks group “Choose your View” selector.
Underblocks: Doesn’t block joining a group.
Rationale: Blocking write request methods renders this application read-only with no overblocking or underblocking.
Overblocks: N/A
Underblocks: N/A
Rationale: Blocking POSTs renders this application read-only with minimal overblocking and underblocking.
Overblocks: Can’t see messages, contacts.
Underblocks: It is possible to upload videos from a webcam when blocking POSTs. Block the “Upload Videos” operation in addition to write request methods to compensate.
;Read-only Facebook: allows login, but denies write request methods
<proxy>
ALLOW url.application.name="facebook" url.application.operation="login"
DENY url.application.name="facebook" http.method=POST
DENY url.application.name="facebook" http.method=PUT
DENY url.application.name="facebook" http.method=DELETE
;Read-only LinkedIn: allows login, but denies write request methods
<proxy>
ALLOW url.application.name="linkedin" url.application.operation="login"
DENY url.application.name="linkedin" http.method=POST
DENY url.application.name="linkedin" http.method=PUT
DENY url.application.name="linkedin" http.method=DELETE
;Read-only Twitter: allows login, but denies write request methods
<proxy>
ALLOW url.application.name="twitter" url.application.operation="login"
DENY url.application.name="twitter" http.method=POST
DENY url.application.name="twitter" http.method=PUT
DENY url.application.name="twitter" http.method=DELETE
;Read-only YouTube: allows login, but denies write request methods & the “Upload Videos” operation
<proxy>
ALLOW url.application.name="youtube" url.application.operation="login"
DENY url.application.name="youtube" http.method=POST
DENY url.application.name="youtube" http.method=PUT
DENY url.application.name="youtube" http.method=DELETE
DENY url.application.name="youtube” url.application.operation=
This set includes every other defined application (see Application and Operation Controls for a current listing). Technically, none of these applications has an operations defined for every possible write operation, but the most significant operations are covered, such as sending email, uploading attachments, posting on social networking sites, and file uploads.
;Read-only Gmail: blocks sending email, attaching uploads, and non-cosmetic settings changes
<proxy>
DENY url.application.name="gmail" url.application.operation="send email"
DENY url.application.name="gmail" url.application.operation="upload attachments"
DENY url.application.name="gmail" url.application.operation="manage settings"
ALLOW url.application.name="gmail"
;Read-only Tumblr: blocks message posting and media uploads (picture & video)
<proxy>
DENY url.application.name="tumblr" url.application.operation="post messages"
DENY url.application.name="tumblr" url.application.operation="upload media"
ALLOW url.application.name="tumblr"
Solution