Burning-After-Reading Element
Author:
DONG Wenyu, Chinamobile
1, Requirements
In services like social web, e-commerce or web-based messaging, people need browsers to make sure that some specific sensitive data will be destroyed after being presented for a period of time and cannot be recovered by the recipient users. Such data are called to be Burning-After-Reading. Obviously Burning-After-Reading data shall not be downloaded, stored or forwarded. Exemplar cases can be sharing private photos between intimate friends, copyright protection, and sharing bank accounts or other certificates in e-commerce.
Burning-After-Reading requires native support of browsers, and shall not rely on JavaScript since JavaScript can be manually disabled.
2, Procedure
It requires two phases to fetch a Burning-After-Reading element.
(1) Phase 1: Metadata Declaration
To prevent feeding non-applicable browsers with Burning-After-Reading elements, web servers shall place metadata in the original HTML instead of Burning-After-Reading contents.
(2) Phase 2: Fetching Burning-After-Reading elements
Browser gets metadata of Burning-After-Reading elements.
a) If the browser supports Burning-After-Reading, by analyzing the metadata, it can derive the real URI of the Burning-After-Reading elements, issue a subsequent HTTP request which will succeed in the verification process by the web server, and fetch, present and then destroy the Burning-After-Reading elements.
b) Otherwise, the browser cannot derive the URI, or the URI is incorrect and will fail in the verification process by the web server. Thus the browser cannot get the desired Burning-After-Reading elements
3, Specification
(1) Metadata
A new element is introduced as metadata of Burning-After-Reading.
< Burning-After-ReadingMeta URIBase=âxxxxâ version= âyyyâ challenge=âzzzâ />
URIBase: URI base of the Burning-After-Reading element.
Version: relating to policies to fetch Burning-After-Reading elements. For example
VersionâŚPolicies
1.0âŚSimplified Burning-After-Reading. Fully rely on the browserâs willingness and cooperation to achieve Burning-After-Reading, no challenge-response required.
2.0âŚTestified Burning-After-Reading (solution XXX). Ensure the browserâs capability to support Burning-After-Reading by employing challenge-response (solution XXX)
3.0âŚTestified Burning-After-Reading (solution YYY). Ensure the browserâs capability to support Burning-After-Reading by employing challenge-response (solution YYY)
Challenge: challenge parameters
< Burning-After-ReadingMeta> shall support attributes like âhiddenâ to make it invisible.
(2) Subsequent HTTP request
The browser derives the real URI with necessary results for challenging, from the version and challenging parameters. The browser issues a subsequent HTTP request like:
http://âŚ/derived-uri?BARResp=derivedresp
BAFResp: the results as response to the challenging, which will be used by the web server to testify.
(3) Burning-After-Reading elements
A new element is introduced to represent Burning-After-Reading contents. For example,
< Burning-After-Reading disptime=âxxxâ >
< DIV>âŚâŚ< /DIV>
< / Burning-After-Reading >
disptime: the time period of displaying before the content is destroyed.
It is recommended that < Burning-After-Reading> shall be only accessible by the browser itself, and shall not be accessible by JavaScript exploring the DOM tree.
4, Use cases
(1) Simplified Burning-After-Reading
The simplified Burning-After-Reading policy does not require challenging-response procedure. So relevant fields are optional.
a) Original HTML:
< !âwhen version=1.0, challenge can be neglected. This element is invisible -->
< Burning-After-ReadingMeta URIBase=âxxxxâ version= â1.0â hidden=âtrueâ/>
b) Subsequent HTTP request:
In this case, no response result is required.
c) http://âŚ/derived-uri
d) Burning-After-Reading content:
< !-- destroy after 10 sec of displaying -->
< Burning-After-Reading disptime=â10â >
< DIV>âŚâŚ< /DIV>
< /Burning-After-Reading>
(2) Testified Burning-After-Reading
The testified Burning-After-Reading policy requires challenging-response procedure.
a) Original HTML:
< !âwhen version=2.0, challenge can be neglected. This element is invisible -->
< Burning-After-ReadingMeta URIBase=âxxxxâ version= â2.0â challenge=âabcdefg1234567â hidden=âtrueâ/>
Note: âabcdefg1234567â is the mock example of challenge parameter.
b) Subsequent HTTP request:
In this case, the response result is required.
http://âŚ/ derived-uri?BARResp=7654321gfedcba
Note: â7654321gfedcbaâ is the mock example of response result.
c) Burning-After-Reading content:
< !-- destroy after 10 sec of displaying -->
< Burning-After-Reading disptime=â10â >
< DIV>âŚâŚ< /DIV>
< /Burning-After-Reading>