2012-05-21, 09:51 PM
2012-05-21, 09:52 PM
(2012-05-21, 06:58 PM)anori Wrote: [ -> ](2012-05-21, 06:54 PM)raubin Wrote: [ -> ](2012-05-21, 06:19 PM)anori Wrote: [ -> ]Honestly the easiesway to get that done all within changing incredibly much. Since guest also have a cookie stored (which with the new lawys without consent is not allowed anymore).
Would make a new landing page (splash page thing) as temporary fix. Add all the information about the cookies on there, and somewhere on the site. Also make this page add a new cookie that lets users decide the landing page where ther are going to go the next time they visit your site. For example to the forums or portal upon going too your site.
Wouldnt know any real other way to get all done that is required before the 26th otherwise.
Or just a script that blocks cookies on entry except "strictly necessary" cookies which are vital for the website to function. Session cookies, cookies for remember which page you have come from and where you are going to are deemed as "strictly necessary", however once you start signing up and logging in the cookies become more intrusive hence the reason you are going to need something in place to gain consent or notify the user that if they wish to continue that they consent to cookies from the website as they are requesting a service by using the forum?
But yes, 26th is only a few days away - my forum isn't one of my main sites so I sort of left it until last! I assumed (shouldn't, but did!) that most of the forum, blog and CMS platforms would have had a solution by now!
Agree just a few days to sort out, but i dont think the EU cares if its stricly necessary or not. And if this is the case i rather stop the users from entering the site completely before letting them agree to every single cookie i use.
Nevermind:
For those types of cookies that are strictly necessary, no consent is required.
Would be MyBB cookies be seen as strickly necessary is now more the question.
Some would be yes, others may not be if you go by level of intrusiveness?
2012-05-21, 09:57 PM
(2012-05-21, 09:52 PM)raubin Wrote: [ -> ]Some would be yes, others may not be if you go by level of intrusiveness?
The biggest problem i have with this all, the dutch rules are far stricter then the EU version. And each and every country can adjust them to their liking. Apparently everything needs to be defined in the netherlands:
http://ictrecht.nl/factsheets/hoe-om-te-...kieregels/
or for english people use chrome or:
http://translate.google.com/translate?sl...2F&act=url
Quote:The Dutch legislator involves much more than is intended by the European regulator. In particular, the word "permission" is strictly construed in the Netherlands: that must be given in advance, explicit and unambiguous consent. Implied consent can not!
2012-05-21, 10:52 PM
The last time I checked this the research found that all cookies were found to be strictly necessary to provide functionality expected by the user. The objectionable cookies were the persistent ones; tracking guests that read threads, inline moderation et al.
2012-05-22, 12:46 AM
I can't see any default MyBB cookie as not being strictly necessary as they all relate to the expected functionality of the forum.
The only one even remotely intrusive would be the remember me option, which if your theme has the remember me check box, you are covered as the user is giving explicit consent.
Can't use a plugin since by that time cookies are in place. I would think that an edit to global.php before init.php is called would be required that will check for a consent cookie and if found continue as normal and if not then redirect to a consent page.
that consent page would list all cookies used by the mybb portion of the site and have three options
1) guest view, no cookies: but is much more involved and would require code changed to init.php to look for a consent cookie and if not found, skip $mybb->parse_cookies(); as well as in the my_setcookie, my_getcookie functions and the general.js to ignore Cookie class
2) guest view, accept all cookies as described: this would put a consent cookie (with a timestamp of accept) and then redirect to rest of site.
3) registered user view, accept all cookies as described: this would update users table with timestamp of accept and site would work as normal. explain here that not consenting is equivalent to guest/no cookie viewing and some functionality may no longer work.
the test for the consent cookie would return a timestamp, so if you modify your site to use different cookies, you can test the timestamp of the accept cookie (or the timestamp int eh users table) to see if you need to prompt the user again.
how to store and access this would be more difficult, perhaps a cookietime.php file that holds a date/time that the site owner could easily edit with the latest cookie change time (as cookie consent has to happen first cookie is placed and thus you never get to the mybb settings/cache, etc.
The only one even remotely intrusive would be the remember me option, which if your theme has the remember me check box, you are covered as the user is giving explicit consent.
Can't use a plugin since by that time cookies are in place. I would think that an edit to global.php before init.php is called would be required that will check for a consent cookie and if found continue as normal and if not then redirect to a consent page.
that consent page would list all cookies used by the mybb portion of the site and have three options
1) guest view, no cookies: but is much more involved and would require code changed to init.php to look for a consent cookie and if not found, skip $mybb->parse_cookies(); as well as in the my_setcookie, my_getcookie functions and the general.js to ignore Cookie class
2) guest view, accept all cookies as described: this would put a consent cookie (with a timestamp of accept) and then redirect to rest of site.
3) registered user view, accept all cookies as described: this would update users table with timestamp of accept and site would work as normal. explain here that not consenting is equivalent to guest/no cookie viewing and some functionality may no longer work.
the test for the consent cookie would return a timestamp, so if you modify your site to use different cookies, you can test the timestamp of the accept cookie (or the timestamp int eh users table) to see if you need to prompt the user again.
how to store and access this would be more difficult, perhaps a cookietime.php file that holds a date/time that the site owner could easily edit with the latest cookie change time (as cookie consent has to happen first cookie is placed and thus you never get to the mybb settings/cache, etc.
2012-05-22, 01:12 AM
(2012-05-22, 12:46 AM)pavemen Wrote: [ -> ]Can't use a plugin since by that time cookies are in place. I would think that an edit to global.php before init.php is called would be required that will check for a consent cookie and if found continue as normal and if not then redirect to a consent page.
that consent page would list all cookies used by the mybb portion of the site and have three options
And here lies the root of the problem. You cant do that atleast if you want to keep any form of SEO ranking. And thinking taking the short root giving google / any other search bot an exception to this will get you blacklisted as soon as they find about this. That you treat the search engine differently.
You would have to get a different landing page, just to be able to let google crawl your whole site. Because yes its not hard to add a splashpage infront of the landing domain just do something like:
if(!isset($_COOKIE['NAME'])) {
header('Location:http://url/cookieconfirm.php');
// Redirect code above
} else {
// But... if they do have the cookie show page normally
//.... normal PhP below (place } on the bottom just above ?> )
}
Simply add that at the top of portal.php/index.php would send users back to a different part of the site for confirmation.
But doing that will kill any SEO ranking.
The only option for something like that would be:
if (!isset($_COOKIE['(SplashName)']) && !(strpos($_SERVER['HTTP_USER_AGENT'], 'Googlebot') !== false)) {
But thats not allowed so..
Honestly it wouldnt be a problem if there werent any Guest Cookies if those could be turned off the problem could be fixed easily. Only would need a huge update to the help document about cookies. And a update to the registration text.
2012-05-22, 03:59 AM
From http://www.ico.gov.uk/for_organisations/...tions.ashx
So it seems that MyBB could use a plugin to prompt existing users and guests that have not already consented via registration agreement.
Then the consent form can remove cookies if consent is not provided.
A simple solution is to, at the start of global.php, remove all MyBB cookies except the consent cookie.
If the consent cookie is not present, prompt user with a consent form with something like
and a prompt to remove all cookies and redirect them to the another cite, ICO maybe??? or continue as a guest or login to your existing account and indicating "BY CONTINUING YOU ARE GRANTING EXPLICIT ACCESS TO XXXXXXXX TO PLACE COOKIES ON YOUR DEVICE"
For a guest selection, store a cookie called mybb_consent with IP and timestamp stored in it, with NO expiration date and then save the same in a mybb_consent table for permanent record keeping.
For a login situation, place the consent cookie (to avoid the consent prompt again), then redirect to the login page. After login, update the mybb_consent table with IP, timetamp and user id.
Also From http://www.ico.gov.uk/for_organisations/...tions.ashx
why would that not be allowed? a search engine is not a "person" nor an "individual"
Quote:The Information Commissioner does however recognise that currently many websites set cookies as soon as a user accesses the site. This makes it difficult to obtain consent before the cookie is set. Wherever possible the setting of cookies should be delayed until users have had the opportunity to understand what cookies are being used and make their choice. Where this is not possible at present websites should be able to demonstrate that they are doing as much as possible to reduce the amount of time before the user receives information about cookies and is provided with options. A key point here is ensuring that the information you
So it seems that MyBB could use a plugin to prompt existing users and guests that have not already consented via registration agreement.
Then the consent form can remove cookies if consent is not provided.
A simple solution is to, at the start of global.php, remove all MyBB cookies except the consent cookie.
If the consent cookie is not present, prompt user with a consent form with something like
The Way PavementSucks Uses Information:
When you choose to create a public profile on PavementSucks, you will post, at your option, certain personal information that will be publicly displayed to other Members on PavementSucks.
PavementSucks uses the information that we collect to operate, maintain, enhance, and provide to you all of the features and services found on PavementSucks. We will use your email address, without further consent, for administrative purposes such as sending you account activation and "welcome" emails, notifying you of major PavementSucks updates, for customer service purposes, to address copyright infringement issues, or to contact you regarding any PavementSucks activities in which you are presently participating.
PavementSucks uses your email address to send to you activity emails, newsletters, and, from time to time, notices about special activities, features, or items available on PavementSucks. You may opt-out of receiving such notices by indicating your preferences in the User CP section of PavementSucks.
PavementSucks uses all of the information that we collect to understand the usage trends and preferences of our Members, to improve the way PavementSucks works and looks, and to create new features and functionality.
PavementSucks uses "automatically collected" information and "cookies" information to: (a) remember your information so that you will not have to re-enter it during your visit or the next time you visit PavementSucks; (b) provide customized third-party advertisements, content, and information; © monitor the effectiveness of third-party marketing campaigns; (d) monitor aggregate site usage metrics such as total number of visitors and pages viewed; and (e) track your entries, submissions, and status in any games, sweepstakes, and contests.
When PavementSucks Discloses Information:
PavementSucks does not share your personally identifiable information with other organizations for their marketing or promotional uses without your express consent.
PavementSucks may disclose Automatically Collected and other aggregate non-personally-identifiable information with interested third parties to assist such parties in understanding the usage and demographic patterns for certain programs, content, services, advertisements, promotions, and/or other functionality on PavementSucks.
PavementSucks may disclose some types of Member Information to certain affiliated companies or other businesses or persons who provide web site hosting, maintenance and security services, fulfill orders, offer certain functionality, help improve our site and create new site features. We require that these parties process such information in compliance with this Privacy Notice, we authorize only a limited use of such information, and we require these parties to use appropriate confidentiality measures.
PavementSucks may disclose Member Information if required to do so by law or in the good-faith belief that such action is necessary to comply with state and federal laws (such as U.S. Copyright law) or respond to a court order, judicial or other government subpoena, or warrant. We may make such disclosures, in some cases, without providing Members notice.
PavementSucks also reserves the right to disclose Member Information that we believe, in good faith, is appropriate or necessary to take precautions against liability; protect PavementSucks from fraudulent, abusive, or unlawful uses; to investigate and defend ourselves against any third-party claims or allegations; to assist government enforcement agencies; to protect the security or integrity of PavementSucks; and to protect the rights, property, or personal safety of our Members or other persons.
Your Choices:
You may, of course, decline to share your personally-identifiable information with PavementSucks, in which case you will not be able to participate in many PavementSucks activities. You may update, correct, or delete your Member account information and email subscription preferences at any time by going to the Edit Profile section of PavementSucks; provided, however, that upon deletion of your account or profile, please note that some of your personal information, including billing and contact information, may remain in PavementSucks's systems for some limited period of time.
To protect your privacy and security, we take reasonable steps to verify your identity before granting you account access or making corrections. HOWEVER, You are responsible for maintaining the secrecy of your unique password and account information at all times.
Third-party Advertisers, Links to Other Sites:
PavementSucks allows other companies, called third-party ad servers or ad networks, to serve advertisements within PavementSucks. These third-party ad servers or ad networks use technology to send, directly to your browser, the advertisements that appear within PavementSucks and they automatically receive your IP Address when this happens. Such third-party ad servers may also use other technologies (such as cookies, javascript, or web beacons) to measure the effectiveness of their advertisements and to personalize their advertising content.
PavementSucks does not provide any personally identifiable information to these third-party ad servers or ad networks without your consent or except as part of a specific program or feature for which you will have the ability to opt-in. However, please note that if an advertiser asks PavementSucks to show an advertisement to a certain audience (for example, males age 18 to 25) or audience segment (for example, males age 18 to 25 who have participated in certain community forums) and you respond to that advertisement, the advertiser or ad-server may conclude that you fit the description of the audience that they were trying to reach.
You should consult the respective privacy policies of these third-party ad servers or ad networks. PavementSucks's Privacy Notice does not apply to, and we cannot control the activities of, such other advertisers or web sites. PavementSucks reserves the right the add or remove third-party ad networks or ad servers in its discretion and PavementSucks may not at all times list such updated ad network or ad server partners in this Privacy Notice.
Currently, PavementSucks has relationships with the following third-party ad servers or ad networks:
Google - http://www.google.com/privacy.html
Outdoor Hub Media - http://www.outdoorhubmedia.com/index.php/privacypolicy
AdBrite - http://www.adbrite.com/mb/privacy.php
VigLink - http://www.viglink.com/policies/privacy (Opt-out option: http://www.viglink.com/support/optout )
You have the option to opt-out of one or more third-party ad networks at http://www.networkadvertising.org/managing/opt_out.aspand a prompt to remove all cookies and redirect them to the another cite, ICO maybe??? or continue as a guest or login to your existing account and indicating "BY CONTINUING YOU ARE GRANTING EXPLICIT ACCESS TO XXXXXXXX TO PLACE COOKIES ON YOUR DEVICE"
For a guest selection, store a cookie called mybb_consent with IP and timestamp stored in it, with NO expiration date and then save the same in a mybb_consent table for permanent record keeping.
For a login situation, place the consent cookie (to avoid the consent prompt again), then redirect to the login page. After login, update the mybb_consent table with IP, timetamp and user id.
Also From http://www.ico.gov.uk/for_organisations/...tions.ashx
Subscriber
This means a person who is a party to a contract with a provider of public electronic communications services for the supply of such services - in this context, the person who pays the bill for the internet connection (that is, the person legally responsible for the charges).
User
This means any individual using a public electronic communications service. In this context a user would be the person sat at a computer or using a mobile device to browse the internet.
(2012-05-22, 01:12 AM)anori Wrote: [ -> ]The only option for something like that would be:
if (!isset($_COOKIE['(SplashName)']) && !(strpos($_SERVER['HTTP_USER_AGENT'], 'Googlebot') !== false)) {
But thats not allowed so..
why would that not be allowed? a search engine is not a "person" nor an "individual"
2012-05-22, 11:06 AM
(2012-05-22, 03:59 AM)pavemen Wrote: [ -> ]Quote:if (!isset($_COOKIE['(SplashName)']) && !(strpos($_SERVER['HTTP_USER_AGENT'], 'Googlebot') !== false)) {
But thats not allowed so..
why would that not be allowed? a search engine is not a "person" nor an "individual"
I asked it at the google groups for SEO listing (webmaster central). And its not allowed, you are not allowed to treat the search engine any differently then a normal person. Only through the means of a robot.txt file. BUt you cant let it enter areas where others also cant like skipping a splash page.
The reply i got their was something like.
Quote:...
Yes, you if they find out about it can get into trouble by treating the googlebot differently. Based on anything from IP/Referrer or User-Agent.
...
And if you want to ask yourself...
https://productforums.google.com/forum/#...g--ranking
thats the place to ask it.
2012-05-22, 02:15 PM
(2012-05-22, 11:06 AM)anori Wrote: [ -> ](2012-05-22, 03:59 AM)pavemen Wrote: [ -> ]Quote:if (!isset($_COOKIE['(SplashName)']) && !(strpos($_SERVER['HTTP_USER_AGENT'], 'Googlebot') !== false)) {
But thats not allowed so..
why would that not be allowed? a search engine is not a "person" nor an "individual"
I asked it at the google groups for SEO listing (webmaster central). And its not allowed, you are not allowed to treat the search engine any differently then a normal person. Only through the means of a robot.txt file. BUt you cant let it enter areas where others also cant like skipping a splash page.
The reply i got their was something like.
Quote:...
Yes, you if they find out about it can get into trouble by treating the googlebot differently. Based on anything from IP/Referrer or User-Agent.
...
And if you want to ask yourself...
https://productforums.google.com/forum/#...g--ranking
thats the place to ask it.
but that is a Google rule for treating the bot different than a regular user in terms of content access, it is not related to the new cookie law at all. they just dont want you to allow the bot access to content that a regular guest can not see so it gets indexed and then becomes a teaser to those who search
2012-05-22, 02:34 PM
If I just put in the user agreement, the text block you get in the signup process that the site will place cookies and by registering you accept this, think that would suffice ?