[cap-talk] Rich Sharing and Clusterken videos come to YouTube

Mike Stay stay at google.com
Mon Mar 19 15:15:31 PDT 2012


https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history

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
>>> on the fragment part, this one can be changed in JavaScript doing:
>>>
>>>     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 [1] is that
> the secret is extracted in JavaScript order to retrieve the actual content.
>    http://www.bla.com/page#s=azertyuiop
> (may) become:
>    http://www.bla.com/page?s=azertyuiop
> 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
> once):
>
>    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);
>    contentPromise.then(update);
>
>    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)
>
> David
>
> [1] http://waterken.sourceforge.net/web-key/
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk



-- 
Mike Stay
stay at google.com



More information about the cap-talk mailing list