- From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 15 Jul 2009 10:53:58 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/webstorage
In directory hutz:/tmp/cvs-serv10178
Modified Files:
Overview.html
Log Message:
Split Web Storage into two: Web Storage and Web Database. (whatwg r3418)
Index: Overview.html
===================================================================
RCS file: /sources/public/html5/webstorage/Overview.html,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -d -r1.51 -r1.52
--- Overview.html 13 Jul 2009 11:16:28 -0000 1.51
+++ Overview.html 15 Jul 2009 10:53:56 -0000 1.52
@@ -174,7 +174,7 @@
<h1>Web Storage</h1>
<!--ZZZ:-->
<!--<h2 class="no-num no-toc">W3C Working Draft 23 April 2009</h2>-->
- <h2 class="no-num no-toc" id="editor-s-draft-date-1-january-1970">Editor's Draft 13 July 2009</h2>
+ <h2 class="no-num no-toc" id="editor-s-draft-date-1-january-1970">Editor's Draft 15 July 2009</h2>
<!--:ZZZ-->
<dl><!-- ZZZ: update the month/day (twice), (un)comment out
<dt>This Version:</dt>
@@ -242,7 +242,7 @@
specification's progress along the W3C Recommendation track.
<!--ZZZ:-->
[...1017 lines suppressed...]
another domain for targeted advertising; or a user's
work-in-progress confidential documents stored by a word-processing
- site could be examined by the site of a competing company.<p>Letting third-party sites write data to the storage areas of
+ site could be examined by the site of a competing company.<p>Letting third-party sites write data to the persistent storage of
other domains can result in <em>information spoofing</em>, which is
equally dangerous. For example, a hostile site could add items to a
user's wishlist; or a hostile site could set a user's session
identifier to a known ID that the hostile site can then use to track
the user's actions on the victim site.<p>Thus, strictly following the <span>origin</span> model described
- in this specification is important for user security.<h3 id="sql-and-user-agents"><span class="secno">7.4 </span>SQL and user agents</h3><p>User agent implementors are strongly encouraged to audit all
- their supported SQL statements for security implications. For
- example, <code title="">LOAD DATA INFILE</code> is likely to pose
- security risks and there is little reason to support it.<p>In general, it is recommended that user agents not support
- features that control how databases are stored on disk. For example,
- there is little reason to allow Web authors to control the character
- encoding used in the disk representation of the data, as all data in
- JavaScript is implicitly UTF-16.<h3 id="sql-injection"><span class="secno">7.5 </span>SQL injection</h3><p>Authors are strongly recommended to make use of the <code title="">?</code> placeholder feature of the <code title="dom-sqltransaction-executeSql"><a href="#dom-sqltransaction-executesql">executeSql()</a></code> method,
- and to never construct SQL statements on the fly.<h2 class="no-num" id="references">References</h2><p class="big-issue">This section will be written in a future
+ in this specification is important for user security.<h2 class="no-num" id="references">References</h2><p class="big-issue">This section will be written in a future
draft.<!--XXX-->
Received on Wednesday, 15 July 2009 10:54:08 UTC