[cap-talk] Rich Sharing and Clusterken videos come to YouTube
stay at google.com
Mon Mar 19 15:15:31 PDT 2012
On Mon, Mar 19, 2012 at 1:59 PM, David Bruant <bruant.d at gmail.com> wrote:
> Le 19/03/2012 20:19, Stiegler, Marc D a écrit :
>>> First, there is the URL bar. Indeed, it just shows the URL, which is
>>> annoying when you wish the URL to be kept secret. If the secret is kept
>>> location.hash = "yo"
>> This is a fascinating possibility I hadn't known about before. Since the webkeys inside a page that suffer from hovering are generally more attenuated than the webkey of the parent page, the url in the url bar is often the greatest vulnerability. I shall experiment with this in the next app I do. One issue with changing the fragment in the url in the bar is, what if the user then does a refresh?
> My understanding of the webkeys using fragments explanation  is that
> (may) become:
> to be dynamically loaded
> Obviously, if you change the fragment and refresh, the new fragment will
> be used as secret by default of a naive algorithm.
> Something more elaborate would use the local storage and add some logic
> around that. Something along the lines of (untested code, not even run
> var currentFragment = location.hash; // save the fragment
> location.hash = ''; // remove the fragment whatever it is.
> var lastFragment = localstorage.getItem('lastFragment');
> // Decide which of the current fragment and last fragment is used
> var secret = decide(currentFragment, lastFragment);
> var contentPromise = getContent(secret);
> localstorage.getItem('lastFragment', secret); // Save fragment of
> current content
> Now, when the user refreshes the page, it can look up in local storage
> and "in the URL bar" and try to compete both to choose which to load
> from. I don't have perfect suggestions for the 'decide' function, but
> the basic idea is here.
> If it happens that the user visits several same pages (same
> protocol+host+path+query) with different fragments, I don't have a good
> suggestion. It may be application specific, but that's definitely a
> question to be answered.
> Regarding browser support, localStorage is supported in modern browsers
> and IE8+.
> Finally, modern browsers and IE8+ have an "hashchange" event to listen
> to hash changes. This may be useful when playing with hashes.
> It has to be noted that since the URL is changed when doing
> "location.hash = something", a new entry in the browser history is
> created, meaning that pressing "back" restores the URL with the secret.
> It may be confusing for the user.
> The history API can improve the situation here since it can replace the
> current history entry, so that the URL in the URL bar changes, but no
> new history entry is created, making browsing more natural. You can just
> pick the secret, remove it from the URL and the user has barely noticed
> the change and is not frustrated to have to click twice to actualy go back.
> History API is in modern browsers and IE10 (some problem exists with
> Safari I heard)
>  http://waterken.sourceforge.net/web-key/
> cap-talk mailing list
> cap-talk at mail.eros-os.org
stay at google.com
More information about the cap-talk