"If a user wants to have certain 3rd-party sites to be able to set
cookies, they can create an exception"
So you are arguing that based upon the syntax of the language in the
option ... the new behavior more accurately matches what the option
says it will do. Why is this deemed necessary? It doesn't provide
improved security to the end user... in practice it does just the
opposite.
The option's language still doesn't match the resulting change in
behavior ... as it is blocking all HTML5 storage mechanisms ... not
just cookies. If the goal is to exactly match the language of the
option's description, you guys are still failing to do that.
This to me seems incredibly arbitrary ... and seems like the result of
some end user noticing that the option doesn't do *exactly* what it
says ... and the developer changing the behavior without a thought as
to why it behaved like that in the first place.
It's not as if it was an accident that 5 browsers had exactly the same
option ... and behaved in exactly the same way with regards to iFramed
cookies. It was intentional ... because POST'ed iFrames, aren't
really 3rd parties.
This doesn't benefit the end-user in reality ... and does a great deal
to limit applications that *should* have 1st-party status.
An iFrame should be considered a 1st party ... especially in the
context of something like a Facebook application. The user has
navigated to the app, they even are prompted for permission to access
their private information. It is not obvious, to the user that these
applications are third parties ...
The first issue, is that *every* other browser on the market behaves
differently. Not only do other browsers behave differently, but
Chrome behaved correctly up until 2 releases ago. There's also no
indication to the end-user of a *major* change in functionality.
If Chrome wants to have an additional feature that blocks iFrame
POST'ed cookies, that should be an additional parameter ... and the
existing one should continue to behave as it did, and as all other
browsers currently do.
The bigger issue here, is that in an attempt to provide "improved"
security ... Chrome has effectively removed the primary mechanism for
securely logging in users in iframe applications.
Any Facebook application, that utilizes cookies to authenticate a
user ... will no longer work when this setting is enabled.
http://apps.facebook.com/mousehunt/?ref=bookmarks&count=0&fb_source=b...
http://apps.facebook.com/stick_run/
As a developer of a major Facebook game, I am now faced with the
options of either passing the authentication token around in the URL
(not secure) ... or simply ignoring the 5% of users that have this
option enabled.
Though I'm all for suggestions on how to circumvent this, and still
retain a secure mechanism to authenticate users.
-noah
On Feb 13, 2:31 am, Jochen Eisinger <joc...@chromium.org> wrote:
> (resending so it gets through to the group)
> On Mon, Feb 13, 2012 at 11:29 AM, Jochen Eisinger <joc...@chromium.org>wrote:
> > Hey,
> > If a user wants to have certain 3rd-party sites to be able to set cookies,
> > they can create an exception (either to always allow them, or to allow
> > those cookies for the current session only). If they want all third-party
> > sites to be able to set cookies, they can just stick with the recommended
> > default to accept all cookies.
> > hth
> > -jochen
> > On Sun, Feb 12, 2012 at 8:21 AM, noah howerton <noah.hower...@gmail.com>wrote:
> >> Hello guys.
> >> Chome 16 had an undocumented functional change in how iFrames worked
> >> with regards to the "Block 3rd Party Cookies" feature. In FF, Safari,
> >> and up until Chrome 16 you could set a cookie in an iFrame POST. So
> >> if you had needed to authenticate an application (say a Facebook app),
> >> you could set your session cookie in the response from the initial
> >> iFrame POST request.
> >> Chrome 16 changed things and diverged from the functionality available
> >> in all other browsers. You could still read cookies within the
> >> iFrame, but writing a cookie on the POST no longer worked. This was
> >> annoying, but not a show-stopper ... as you could do a redirect loop
> >> to force the cookie onto the browser.
> >> In chrome-16 there was an option in about:flags, that additionally
> >> stopped reads of cookies from within iFrames ... though with only
> >> advanced users likely figuring this out ... the fall-out wasn't a big
> >> deal so I didn't complain.
> >> Chrome 17 changed things again. Now cookies, can't be read from
> >> within an iFrame .. nor can they be set under any circumstance. This
> >> causes issues for Facebook apps. Likely a number of other things on
> >> the internet break, but I develop Facebook applications ... so that's
> >> what I know is broken.
> >> I would be ecstatic, if you guys reverted the behavior to match that
> >> of Safari. Which is POST's can set cookies ... and i-frames can read
> >> cookies from the domain of the original POST request.
> >> Without cookies though, there isn't really any secure way to reliably
> >> authenticate users in things like Facebook apps. If there is a better
> >> way to do this, by all means enlighten me. Though, Facebook apps and
> >> similar shouldn't be 3rd class internet citizens. An iframe should
> >> have all the features of an application that has the full-frame.
> >> It's my understanding that, not only are cookies blocked with this
> >> "security" feature but all HTML5 storage mechanisms ... which is bad
> >> news for app-developers.
> >> I also don't really see the logic in implementing this "security"
> >> feature in the first place... wouldn't it be better for the end user
> >> to just have the option to clear local storage after they leave the
> >> page? If the goal is to prevent tracking cookies and such from
> >> working, that would be the obvious way to achieve it. Blocking all
> >> iframe storage though, is like using an axe to snap a tooth-pick in
> >> half.
> >> --
> >> Chromium Discussion mailing list: chromium-disc...@chromium.org
> >> View archives, change email options, or unsubscribe:
> >> http://groups.google.com/a/chromium.org/group/chromium-discuss
