Google Chrome and cookies

[FND]

All,

As you might know, the Google Chrome browser does not store cookies for
local files - which means TiddlyWiki user options cannot be saved.*

The developers have decided not to fix this issue, for now:

> marking as WontFix. People can still comment on the bug if they feel
> it's important, and we can always revisit later on.

So you might want to alert them that this is not an insignificant issue:
http://code.google.com/p/chromium/issues/detail?id=535
(All you need is a Google account, which you probably already have for
posting on the TiddlyWiki groups.)

-- F.

* http://www.tiddlywiki.org/wiki/Google_Chrome

[Dave Gifford - http://www.giffmex.org/]

I just went in and clicked the star. I think I'll comment, too.

Dave

[Morris Gray]

Ref: http://code.google.com/p/chromium/issues/detail?id=535

A comment on cookies from a respondent says:

> Some example questions: should cookies for file:///c:/foo/ be shared with
> file:///c:/bar/? what about cookies for file://otherhost/baz? should
> cookies from ftp://example.com be shared with http://example.com? what
> about HTML files downloaded to local disk from the Internet, should they
> keep their original context, or intrude that of any HTML code installed
> locally? Lacking clear and consciously defined rules, this is a ticking
> time bomb.

This highlights a systemic problem with TiddlyWiki that anyone with
more that one TiddlyWiki has experienced from time to time. (My
backup files are a mess no matter how hard I try)

On the long term (Google Chrome won't be going away nor changing the
cookie problem) should there be consideration given to using something
like an *.ini type file section in 'store' for storing the present
cookie information?

Morris





On Sep 6, 11:16 pm, "Dave Gifford - http://www.giffmex.org/"

[Jason Cunliffe]

Morris Gray wrote:
> On the long term (Google Chrome won't be going away nor changing the
> cookie problem) should there be consideration given to using something
> like an *.ini type file section in 'store' for storing the present
> cookie information?
>

I've had wierdness with cookies and TW, upgrades, backups etc. Never
quite understood what's was going right or going wrong.
An TW option for plain old .ini files would be great.

Another approach which perhaps can be made to work now quickly for
GoogleChome woudl be to use the Flashplayers' own cookie system.
Some people love to hate Flash, but I believe it has a *lot* to offer TW
and vice versa [audio video cookies javascript flex air etcetc].
Adobe AIR for example should make it very easy to have TW truly running
as a standalone desktop web app, since AIR speaks javascript
actionscript and HTML.

Flash Cookies are known as 'local shared objects' LSO - similar to HTTP
cookies, but the default storage size is 100Kb :-)
JSON formatted data should work fine to smooth the transmission between
TiddlyWiki and Flash

some reading..

What are local shared objects?

http://www.adobe.com/products/flashplayer/articles/lso/

What are third-party local shared objects?

http://www.adobe.com/products/flashplayer/articles/thirdpartylso/

HOWTO: SharedObjects for Local Storage AS3

Shared Object Reader [in python and php]

http://www.sephiroth.it/python/solreader.php

http://drawlogic.com/2008/01/10/howto-sharedobjects-for-local-storage-as3/

Flash with Flex
http://marxsoftware.blogspot.com/2008/05/flash-cookies-with-flex.html

[Jason Cunliffe]

oops, I forgot this link from my previous reply...

HOWTO: SharedObjects for Local Storage AS3

January 10, 2008 — drawk

Using SharedObjects in Flash is very simple. Flash has SharedObjects
that have been in the player since Flash6 when the introduction of Flash
Communication Server which is now Flash Media Server which is releasing
version 3 soon (also remote SharedObjects in Red5
<http://osflash.org/red5> is an open source RTMP media server that is
based on Flash Media Server). So we can thank this release for
SharedObjects, Camera objects, Audio, lots of the NetConnections,
protocol enhancements and many other things. However to keep the tips
simple we will just touch on the local usage and post a series of posts
on these objects.

http://drawlogic.com/2008/01/10/howto-sharedobjects-for-local-storage-as3/

------
Jason

[Dave Gifford - http://www.giffmex.org/]

"COOOOO-KIIEEEEEESSSS!!!!!
cookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookies
cookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookiescookies!!!!!"

--The Cookie Monster

[Morris Gray]

It appears there was something a bit stronger in those cookies besides
sesame seeds

On Sep 7, 1:26 pm, "Dave Gifford - http://www.giffmex.org/"

[lewcid]

An alternative to an ini file is to save the settings in the
TiddlyWiki file itself. Heres a plugin I wrote a while ago, that while
far from perfect, allows you to do that:

http://svn.tiddlywiki.org/Trunk/contributors/SaqImtiaz/plugins/StickyOptionsPlugin/StickyOptionsPlugin.js

On Sep 7, 3:31 am, Morris Gray <msg...@symbex.net.au> wrote:
> Ref:http://code.google.com/p/chromium/issues/detail?id=535
>
> A comment on cookies from a respondent says:
>
> > Some example questions: should cookies for file:///c:/foo/ be shared with
> > file:///c:/bar/? what about cookies for file://otherhost/baz? should
> > cookies fromftp://example.combe shared withhttp://example.com?what
> > about HTML files downloaded to local disk from the Internet, should they
> > keep their original context, or intrude that of any HTML code installed
> > locally? Lacking clear and consciously defined rules, this is a ticking
> > time bomb.
>
> This highlights a systemic problem with TiddlyWiki that anyone with
> more that one TiddlyWiki has experienced from time to time.  (My
> backup files are a mess no matter how hard I try)
>
> On the long term (Google Chrome won't be going away nor changing the
> cookie problem) should there be consideration given to using something
> like an *.ini type file section in 'store' for storing the present
> cookie information?
>
> Morris
>

> On Sep 6, 11:16 pm, "Dave Gifford -http://www.giffmex.org/"

[Simon Baird]

I don't think we should be campaigning to make Chrome do cookies for local files. I think rather it's time we make TiddlyWiki stop using cookies for TW settings. I don't think it was a great idea to begin with.

--
simon...@gmail.com

[FND]

> it's time we make TiddlyWiki stop using cookies for TW settings.

While I generally wouldn't mind that, there are two different types of
settings: document configuration and user preferences (think authors vs.
readers).
I'd love to have an alternative to manually putting code into a
ConfigTweaks tiddler - but I how could we allow different users to have
different settings (e.g. username, animations) if not with cookies?

Either way, we should have this discussion on [twdev].

-- F.

[BidiX]

2008/9/7 Simon Baird <simon...@gmail.com>

I don't think we should be campaigning to make Chrome do cookies for local files. I think rather it's time we make TiddlyWiki stop using cookies for TW settings. 

I agree with Saq and Simon, options are mainly attached to a TiddlyWiki, not its location. 

A kind of ini tiddler that fixes default options in the TiddlyWiki but that can to be set and changed easily with a macro like <<option>> should be great.  Ideally changes could affect :

• the default option values and saved in the TiddlyWiki
• or temporary option values in the running session.
  

Also some options can't be set in the TiddlyWiki itself (for example password), but in a kind of user profile attached to a TiddlyWiki (not a location). This user profile could also supersede some default options. 

-- BidiX
http://BidiX.info

[Eric Shulman]

> A kind of ini tiddler that fixes default options in the TiddlyWiki but that
> can to be set and changed easily with a macro like <<option>> should be

See
http://www.TiddlyTools.com/#CookieManagerPlugin

The <<cookieManager>> interface includes a "bake cookies" button to
instantly generate a [[CookieJar]] tiddler containing simple
javascript assignment statements that hard-code all of the current
cookie-based settings values using a 'systemConfig' tiddler... and,
the generated code is wrapped in a conditional test, using:
if (config.options.txtUserName="...")
so that the stored settings will only be applied for the current user.

Once the <<cookieManager>> has generated a [[CookieJar]] tiddler, it
can easily be edited to change the values of the individual assignment
statements by hand, or simply re-use the <<cookieManager>> to generate
a new CookieJar based on whatever the current settings are.

By using javascript within the CookieJar instead of creating an
entirely new special-use syntax for that purpose, we get an instantly
robust syntax: not only can you assign the desired values to option
settings, you can also use the CookieJar to reconfigure *any* TW
settings that might have user-specific preference values...

and, if someone knows a little bit of javascript, they can even add
conditional assignments or other programmatic logic to calculate
various option settings dynamically, based on current conditions.

enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios

[Simon Baird]

On Sun, Sep 7, 2008 at 7:47 PM, FND <FN...@gmx.net> wrote:

> it's time we make TiddlyWiki stop using cookies for TW settings.

While I generally wouldn't mind that, there are two different types of
settings: document configuration and user preferences (think authors vs.
readers).
I'd love to have an alternative to manually putting code into a
ConfigTweaks tiddler - but I how could we allow different users to have
different settings (e.g. username, animations) if not with cookies?

Personally I don't care about different users having different settings. For me TW is a single user app hence username doesn't serve much purpose. And if I was publishing something, inconsistent user experience is a negative thing IMO.

Simon.

--
simon...@gmail.com

[Simon Baird]

On Sun, Sep 7, 2008 at 9:21 PM, Eric Shulman <elsd...@gmail.com> wrote:

> A kind of ini tiddler that fixes default options in the TiddlyWiki but that
> can to be set and changed easily with a macro like <<option>> should be

See
  http://www.TiddlyTools.com/#CookieManagerPlugin

The <<cookieManager>> interface includes a "bake cookies" button to...

My wish is that such a thing would not be required. And that a new user can configure TiddlyWiki in an intuitive way.


Simon.


--
simon...@gmail.com

[Morris Gray]

Coincidently, before the Google Chrome was released I was
experimenting with ways to overcome the irritations caused by cookies
controlling so much and being carried over from one TiddlyWiki to
another (I have a lot of them). I have been using ConfigOptionsMacro
in a few TWs, was trying out Eric's CookieManagerPlugin and had
already loaded StickyOptionsPlugin and finally tried it out today when
the post here reminded me..

With the option "Trigger autosave when an option is saved" ticked;
StickyOptionPlugin seemed to be dragging its feet while I typed a
backup file folder name. It quite humorously was creating a backup
folder for every letter of the name I typed, 'StickyBackup' 12 folders
in all. That's as far as I got. Either it or I needs some tweaking.

ConfigOptionsMacro seems to be reasonably stable but there are a few
things that won't stick like the TiddlySpot password. The backup
folder is not stable it seems to be almost random about using the
folder assigned and keeps adding the backup folder name in front of
every individual TiddlyWiki backup, very odd maybe other TiddlyWikis
are interfering.

Eric's solution works fine however it's a several step process
designed to overcome a built in problem which makes saving/changing
options not as straightforward as it would be if designed into
TiddlyWiki from scratch.

I tried SettingsPlugin a year or more ago, had some problems with it
but never got any replies so I dropped it.

There is no reason why users shouldn't expect to tick options in a
TiddlyWiki without them disappearing when it's uploaded, or affecting
more than one TiddlyWiki, or options disappearing when they clear
their cookies, or finding after creating several dozen tiddlers they
were all done by UserName :-)...... yet again!!

Perhaps if Eric's cookie baking operation could be made automatic and
transparent to the user to the point no secondary actions at all are
required for setting or resetting options we could have the best of
both worlds.

Morris

On Sep 7, 5:45 pm, lewcid <lew...@gmail.com> wrote:
> An alternative to an ini file is to save the settings in the
> TiddlyWiki file itself. Heres a plugin I wrote a while ago, that while
> far from perfect, allows you to do that:
>

> http://svn.tiddlywiki.org/Trunk/contributors/SaqImtiaz/plugins/Sticky...

>
> On Sep 7, 3:31 am, Morris Gray <msg...@symbex.net.au> wrote:
>
> > Ref:http://code.google.com/p/chromium/issues/detail?id=535
>
> > A comment on cookies from a respondent says:
>
> > > Some example questions: should cookies for file:///c:/foo/ be shared with
> > > file:///c:/bar/? what about cookies for file://otherhost/baz? should

> > > cookies fromftp://example.combeshared withhttp://example.com?what

[Eric Shulman]

> My wish is that such a thing would not be required. And that a new user can
> configure TiddlyWiki in an intuitive way.

http://www.TiddlyTools.com/#CookieManagerPlugin
provides a very simple, easy-to-use form for viewing, changing or
removing individual cookies, as well as providing the "bake cookies"
and "bake options" buttons. Just one click and the current settings
are preserved in a [[CookieJar]] tiddler that is tagged with
'systemConfig' so it is processed during document startup, the same as
any other plugin. What could be simpler?

In addition, I am working on an update to CookieManager that will
automatically bake the cookie values each time a cookie is set (by
hijacking the core's saveOptionCookie() function), so that the
settings will simply be saved in a [[CookieJar]] tiddler without you
having to do anything at all (except for remembering to save the file
at the end, so the changed settings are preserved).

Of course, the CookieManager interface is not the only way to present
the various settings that the user can configure...

The TW core uses the <<options>> macro to render a table of TW
settings (displayed in the [[AdvancedOptions]] shadow tiddler) to
which plugins can programmatically add their own options. However,
many plugins simply display a self-contained set of option checkboxes
and input fields directly within the documentation of the plugin
tiddler itself, often in a section labeled "Configuration" (or
something similar).

To make it easier to access these individual plugin settings, you can
use
http://www.TiddlyTools.com/#AdvancedOptionsPlugin
which automatically gathers all the plugin-defined options together
and assembles a single set of tabs (one for each plugin) that is then
appended to the regular [[AdvancedOptions]] shadow tiddler content
(just below the TW standard <<options>> table). In addition,
http://www.TiddlyTools.com/#CookieManagerPlugin
also automatically transcludes its control panel form and generated
CookieJar output into [[AdvancedOptions]] so that all settings,
whether defined by the TW core, individual plugins, or browser-based
cookies, are collected together in one place for easier review and
management.

To see this in action, just view:
http://www.TiddlyTools.com/#AdvancedOptions

Lastly, it should be noted that there are some values for which
browser-based cookies are totally appropriate. For example, various
options that modify core behaviors (e.g., animations, autosave,
backups, key-by-key search, etc.) are generally supposed to be
associated with the personal preferences of the *reader*, rather than
the particular document they happen to be viewing at the time.

In addition, TW keeps track of certain ephemeral, transient 'state'
information, such as the open/closed state of sliders and the current
selected tabs in tabsets. These would seem to be a perfect use for
cookies, as these bits of information shouldn't really require any
kind of active, deliberate management by the end user and can easily
and quickly change values many times during the TW document session.

thoughts?

[Eric Shulman]

> Perhaps if Eric's cookie baking operation could be made automatic and
> transparent to the user to the point no secondary actions at all are
> required for setting or resetting options we could have the best of
> both worlds.

I'm working on an update to CookieManagerPlugin that will provide
exactly that ability.

-e

[Dave Gifford - http://www.giffmex.org/]

Awesome! Chrome is just a heartbeat away, then! I can't wait!

Dave

[Dave Gifford - http://www.giffmex.org/]

The perfect cartoon for this thread:

http://www.yemiipics.com/images/delete-cookies.jpg

Dave

[HansWobbe]

On Sep 7, 10:21 am, Eric Shulman <elsdes...@gmail.com> wrote:

>
> thoughts?
>
> -e
> Eric Shulman
> TiddlyTools / ELS Design Studios

Eric...

I don't yet know enough to judge the possible effect of the existence
of a mass-produced (distro?) disc that includes TW and ...

... a comprehensive library of all of its plugins, as well as pre-
assembled user-generated MicroContent modules, and some supporting
Trust-worthy data source files, and copies of all of the major
browsers, etc...

might affect this "architectural" discussion.

However, I thought I'd at least mention that this is something I am
planning to test relatively soon, just so see if this comment is on
interest within the community.

Regards, (and thanks again for TiddlyTools)
Hans Wobbe

[Scott Elcomb]

LOL. That's awesome. :-)

--
Scott Elcomb
http://www.psema4.com/
http://www.psema4.com/blog/
http://www.google.com/reader/shared/14892828400785741937

[Ryan]

I don't know if you noticed this but on the google bug page they give
a workaround:

"You can, however, enable them with the command line flag --enable-
file-cookies."

This works for me.

[FND]

> "You can, however, enable them with the command line flag --enable-
> file-cookies."

I know - however, experience shows that not all users are comfortable
setting startup flags like that.

Either way, we're currently looking into options to rid TiddlyWiki of
these cookie issues altogether.

-- F.

[YGG-]

I don't understand what I should do or where to use this?
YGG

[FND]

> I don't understand what I should do or where to use this?

Modify the target location of your Google Chrome shortcut, e.g.
"C:\Programs\Google Chrome\chrome.exe" --enable-file-cookies
(It's been a while since I've done this on Windows, so the placement of
the quotation marks might be off.)

-- F.

PS: q.e.d. ;)

[Rex]

Hmmm. This switch doesn't work for me. Am I the only one? Is there
something else I should be doing?

[Simon Baird]

I didn't look it up but maybe it's in the latest chrome nightly only.

--
simon...@gmail.com

[YGG-]

Thanks!
YGG