[00:56:54] perennial complaint about user-hostile cookie banners [00:57:09] anyone aware of movement on disabling them? [00:57:16] or fixing the bug that makes the display for non-EU users? [00:58:24] https://github.blog/2020-12-17-no-cookie-for-you/ [00:58:24] [url] No cookie for you | The GitHub Blog | github.blog [00:59:29] I stopped pointing people to my miraheze wiki when I realized last summer it had this hostile feature [01:02:45] bleb: [01:02:48] er [01:03:08] pinged without a message but yes, we're working to fix that and disable it for non-EU users [01:05:43] the banner isn't even gdpr compliant [01:06:09] someone should tell that to whoever decided it should stay up for the past 6 months [01:06:41] well that's something we'd have to raise up to WMF devs [01:07:09] https://gdpr.eu/cookies/ "Receive users’ consent before you use any cookies except strictly necessary cookies." [01:07:10] [url] Cookies, the GDPR, and the ePrivacy Directive - GDPR.eu | gdpr.eu [01:07:17] "Allow users to access your service even if they refuse to allow the use of certain cookies" [01:07:32] there is no option to hide the banner without consenting [01:09:05] Agent: sure that would be nice, but it doesn't preclude miraheze from using its own discretion [01:10:00] miraheze is not forced to expose itself to potential legal liability through a coercive method of obtaining consent [01:14:28] https://www.privacy-regulation.eu/en/recital-32-GDPR.htm [01:14:29] [url] Recital 32 EU General Data Protection Regulation (EU-GDPR). Privacy/Privazy according to plan. | www.privacy-regulation.eu [01:14:37] " [01:14:40] "If the data subject's consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided." [01:15:02] "Silence, pre-ticked boxes or inactivity should not therefore constitute consent." [01:15:20] "Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject's agreement to the processing of personal data relating to him or her" [01:15:45] this is not fulfilled by a banner reading "By using our services, you agree to our use of cookies." [01:15:47] Perhaps @Owen can shed more light into Miraheze's GDPR compliance with cookies [02:08:24] Hello blau! If you have any questions, feel free to ask and someone should answer soon. [05:14:44] Positive consent is required for non essential and non-exempt cookies, the positive consent is given by account registration and login. No ‘non essential’ cookies are set prior to this stage, the banner is purely information that cookies meeting the essential criteria as defined by the UK’s Information Commissioners Office is set. UK law also requires cookie notices are showed to British and EU citizens where processing occurs [05:14:45] with the UK or EEA, as we are unable to determine who is and is not a citizen by area alone without further collecting unnecessary personal information, we show the banner to every for compliance - this will not change. [05:34:31] What is the current policy on matomo?, since it's autoloaded and it's expansion on configurations/views are pending. I guess the same as Fandom ad's policy, that you cant disable it wiki side? [05:37:59] We're not so oppressive :P [05:38:00] You can opt a wiki out of it by assigning the noanalytics right to the * group on your wiki. [05:39:12] oh, nice, good to be allowed having that option. thanks i will keep it in mind. [05:58:16] what about an option to disable the cookie banner if analytics are disabled [05:59:28] or at least put the banner at the top and make it possible to scroll past it [06:00:06] That'd require an upstream change I'm guessing [06:03:33] or at least revise the banner text to make it less misleading [06:04:05] continuing to browse the site does NOT amount to agreement to the use of cookies [06:05:28] perhaps something like "Cookies help us deliver our services. By creating an account or logging in, you agree to our use of cookies." [06:05:37] and change the button from OK to Dismiss or similar, so that it can't be construed as consent when it shouldn't be [06:06:13] Agent: based on what owen said, it sounds like the banner is needed to notify people that cookies are in use whether or not they agree to it [06:06:28] due to some UK law [06:07:02] The cookie notice is not for agreement, but informational. Required under something else I think, but Owen is the expert here, so I can't be certain. But I think changing it to "Dismiss" would work also but we don't control the code for it, so we can't modify what it says. (Maybe we actually can with the same message overrides we use elsewhere though) something to be considered. [06:08:42] where is the code for it [06:09:41] bleb: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CookieWarning/+/refs/heads/REL1_37 [06:09:42] [url] refs/heads/REL1_37 - mediawiki/extensions/CookieWarning - Gitiles | gerrit.wikimedia.org [06:11:57] the message and button can both be configured: https://www.mediawiki.org/wiki/Extension:CookieWarning#System_messages [06:11:58] [url] Extension:CookieWarning - MediaWiki | www.mediawiki.org [06:12:10] Bleb: per wiki [06:12:46] But we can probably overwrite the messages globally using our system we use for other system messages sometimes. [06:13:56] well it's a legal problem if users can change them per wiki without disabling analytics [06:14:17] they could make it say something nonsensical, such that it no longer meets the requirements of the UK law [06:15:00] so might as well make it possible to disable per wiki huh [06:15:15] Oh now that's a very good point...... [06:15:29] or, we can be radical and revoke the ability to edit the interface :P [06:15:34] @Owen: ^ thoughts? [06:16:05] (Not on disabling the ability to edit the interface, but on what bleb said) [06:20:31] my suggestion would be to remove analytics and cookie banners, and if someone wants analytics they can request it, then they also get the cookie banner [06:21:37] that way you avoid the possibility of wikis with analytics and an invalid cookie banner which is apparently illegal [06:22:08] only way I can think to avoid that without changing code [06:22:35] Bleb: analytics don't use cookies. [06:24:38] "Miraheze uses cookies for... Gathering Usage Information for statistical purposes." [06:24:53] so that type of information gathering is not analytics, and cannot be disabled? [06:25:14] https://meta.miraheze.org/wiki/Privacy_Policy#4._Cookies [06:25:16] [url] Privacy Policy - Miraheze Meta | meta.miraheze.org [06:25:41] that seems to be the bullet that requires the cookie banner under UK law [06:26:09] Nope, analytics don't use cookies [06:27:00] for some reason I thought by disabling analytics my visitors would not have usage information collected about them [06:27:02] bleb: MatomoAnalytics does not use cookies from what I can see, I honestly don't know what does then...... as it looks to me like MatomoAnalytics cookies are disabled. https://github.com/miraheze/MatomoAnalytics/blob/7bb72ad61979eeb7325af4c3afb6451b5afc106d/includes/MatomoAnalyticsHooks.php#L65 [06:27:03] [url] MatomoAnalytics/MatomoAnalyticsHooks.php at 7bb72ad61979eeb7325af4c3afb6451b5afc106d · miraheze/MatomoAnalytics · GitHub | github.com [06:28:34] I will try and find out what does use cookies, as I could be wrong. [06:29:29] Owen: perhaps you can shed some light on this. would also like to clarify that these cookies used for information gathering are considered "essential" under UK law? [06:29:50] what cookies could be "essential" for a non registered visitor? [06:59:47] <城市酸儒文人挖坑> Quanzhou City in mainland China is currently implementing a whitelist system for websites, at least two of the four network operators have access to the whitelist (China Telecom and China Unicom), unauthenticated domain names will automatically jump to the "National Anti-Fraud Center" when browsing, can not be normal browsing, I hope Miraheze can pay attention to this incident I hope Miraheze can pay attention to [06:59:47] this incident and provide a solution to the users in mainland China. （I hope Miraheze can pay attention to this incident and provide a solution for mainland China users. (IP can browse normally, but the VPN connected with the domain name may not be able to connect) It would be great if Miraheze can try to whitelist authentication. (Need to register a branch in mainland China and then apply for a service license with the necessary network [06:59:48] review) [07:14:20] @城市酸儒文人挖坑 Unfortunately, I don't see how Miraheze would be able to register in China with our resources [07:19:58] <城市酸儒文人挖坑> I sent them in the general in Discord [07:20:24] <城市酸儒文人挖坑> I also sent something to Agent [07:21:19] <城市酸儒文人挖坑> You can register a branch in China (preferably not an NGO, but the nature of the company can be non-profit) [07:21:20] I don't have much hopes on this happening, but something must be done [07:22:12] <城市酸儒文人挖坑> The Chinese wikipedians are discussing about this in WMC's QQ group [08:06:26] bleb: I will conduct a review later today and advise SRE on the best way forward regarding text content for compliance [15:17:25] https://ico.org.uk/for-organisations/guide-to-pecr/cookies-and-similar-technologies/ [15:17:26] [url] Cookies and similar technologies | ICO | ico.org.uk [15:17:32] "You must tell people if you set cookies, and clearly explain what the cookies do and why. You must also get the user’s consent. Consent must be actively and clearly given." [15:17:42] "There is an exception for cookies that are essential to provide an online service at someone’s request (eg to remember what’s in their online basket, or to ensure security in online banking)." [15:22:30] "you are unlikely to need consent for... load-balancing cookies that ensure the content of your page loads quickly and effectively by distributing the workload across several computers." [15:23:07] bleb What do you mean? [15:23:27] Maybe that's what Miraheze uses? But where is the requirement to notify users of such exempt/essential cookie use? [15:24:20] ... UK law also requires cookie notices are showed to British and EU citizens where processing occurs [15:25:35] Haven't been able to confirm this yet, only that consent is required for non-essential cookies, but we have established that the CookieWarning does not obtain consent. [15:25:41] cookies convo started earlier today @ Dark [15:28:13] I was trying to figure out why the cookie banner is required, or if it is based on a misconception and we can stop pestering visitors with them. [15:30:34] Maybe analytics did use cookies when the privacy policy was written, including the statement that cookies are used for "Gathering Usage Information for statistical purposes." [15:32:49] Whatever, I'll let Owen conduct his review. [15:53:34] I have taken a look, and we do not routinely use non-essential cookies on our main/default wikis. This is not to guarantee other wikis do not use extensions or other software that might set cookies that fall under the criteria which requires consent. However, my preference remains that we keep the informational notice for all users to inform them proactively around our use of essential cookies. [16:28:06] Owen: if certain extensions require consent, that is irrelevant to the CookieWarning because it does not obtain consent [16:29:48] It is indeed, because CookieWarning is informational, which is the purpose I want it to fulfil. Any additional non-consenting cookies are for individual wikis that are utilising then to ensure sufficient consent mechanisms are in place, such as positive consent on registration/login and only being activated in these situations. [16:31:10] that leaves two questions regarding the informational notice: (a) is there any obligation to inform users of the use of essential cookies / cookies that do not require consent, and if so where does it come from? [16:31:39] (b) Does Miraheze use non-essential cookies for unregistered users? If so, for what purpose? [16:32:47] sorry I mean essential [16:33:06] (b) Does Miraheze use essential cookies for unregistered users? If so for what purpose? [16:33:31] a) there is no obligation, but the purposes of GDPR is to make people more aware of their data protection rights and to prevent organisations being obtrusive in hiding information and preventing people accessing their rights. Therefore, I like an open and forward facing approach in making people aware of their data rights and what information/technologies may be used to store information. [16:34:30] b) Yes, for session tracking and other things like persisting blocks to users who are logged out/associated with certain IP (ranges). Not everyone has them, but some can have them [16:37:59] the latter seems legally dubious based on what I've read [16:38:14] but what's an example of session tracking? [16:39:12] Unique session IDs, it is necessary for providing a login functionality, especially one persisting across numerous domains and for threat detection for user logins [16:39:46] for unregistered users though? [16:40:11] For anonymous users, those who are not logged in. Sessions persist if logged out [16:40:46] so they need to have logged in previously? [16:41:36] Yes, but given numerous domains are used, they may not have associated it with Miraheze, or may not be aware another domain is serviced by us [16:42:29] Although even a user who has not logged in, will have a session associated if they have done another action such as edit [16:49:00] what functionality does that enable e.g. for an unregistered user who makes an edit? [16:51:00] I am not sure that it generates a session currently, but it will in the future as there is a move to anonymous IDs in the software core over disclosing IPs public, the necessity there would then be correct action attribution [16:58:27] thats quite reasonable [16:58:52] anonymous edits should be disabled everywhere imo, just saying [17:00:19] though the anonymous IDs thing is quite worrisome for privacy [17:01:12] if anonymous ID cookies are "essential" then they can be used to track people without their consent [17:01:51] Unlike their public exposed IP that can be used to track them even further? [17:02:21] The consent would be given by editing, which is already the case for their IP address [17:03:55] yes, I would want to see explicit consent for that, though it does not seem to be required by existing regulations since the cookies are considered essential [17:04:29] so it's a worrisome loophole that could be exploited by unscrupulous webmasters, not miraheze [17:05:41] It’s required to be shown essential for providing a service the user wants - a user editing from an IP address and not a registered account is an intentional act the user wishes to do and has explicitly and positively agreed and consented to do. The cookies are thus a necessity to execute a service they have requested [17:06:02] yes, that's why they are essential [17:06:16] but once those cookies are in place, I don't think anything prevents them from being used for tracking [17:06:59] yes IP addresses are already there, but they aren't targeted or persistent the way cookies are [17:07:01] There isn’t, because that is the purpose of them - they are there to track a users editing activity so it can be correctly associated to their persona which is required for licensing reasons [17:07:10] on the other hand they can be cleared by the user so that's a plus [17:11:22] there are tradeoffs; if you wanted to protect IP addresses without increasing the capacity for tracking you could maintain an association between IP and some randomly generated token on the server side [17:12:28] they probably need to keep track of which IPs go with which anonymous IDs anyway, to prevent people from circumventing bans by clearing their cookies [17:15:48] on the other hand some users may want anonymous edits from the same computer to be traceable to a single anonymous ID [17:16:20] no problem there as long as it is explained clearly and concisely when they make the edit [17:22:22] Owen: to return to the original issue, I generally agree with the goals you laid out above in a), but since there is no legal obligation to have the CookieWarning, would you consider making it possible to disable? [17:22:42] or whoever is in charge of that [17:24:06] SRE would be the ones in charge of making the decision of how it is implemented, my advice to them as a Director would be to maintain it as is. They would be free to make up their own minds however, as I am only giving advice on the matter, not mandating it. [17:24:52] I could also enumerate the ways in which the current cookie warning and linked wiki page fall short of the goals you laid out, to the point that it is more obfuscatory than illuminating [17:27:45] but even if the button were changed to "dismiss" and the text in the banner and the privacy policy were corrected, I would still strongly prefer to remove the banner and allow users to learn about their rights when they want to [17:29:03] part of the appeal of miraheze is being able to make your own site that looks and works just like wikipedia, and one of the nice things about wikipedia is that they resist a lot of the annoying trends in modern web design including cookie banners [17:30:58] doesn't seem reasonable to force wikis to conform to your particular preferences about how people should be notified of information they may or may not care about [17:32:29] I also suspect that many people have the mistaken impression that the cookie banner _does_ shield miraheze from some legal liability, not least because the current text is misleading [17:35:46] am I off base here? [17:38:36] You are free to ask SRE to reconsider implementation based on your comments if you wish [17:40:05] how would I contact them [17:40:45] let me guess I need a github acount [17:41:00] Well, here. Most of the people voiced on the channel are members of SRE [17:41:10] Or you can email sre@miraheze.org [17:41:12] https://phabricator.miraheze.org/, with your comments written down, if they ask me for advice, I’ll weigh up what you have said against my reasons for my previous recommendation and then provide new advice [17:41:13] [url] Main Page | phabricator.miraheze.org [17:41:58] As I agree things have perhaps changed, and it should be re-reviewed [17:56:12] ok, maybe next week if I have time [17:58:10] or maybe the SRE members will be convinced if they read the backlog [20:31:59] https://usercontent.irccloud-cdn.com/file/HeRWXDNw/image.png [20:32:04] I instantly regret approving this [20:32:48] Oh [20:32:53] Their request finally got aproved [20:59:48] Oh dear [21:00:00] I should have communicated the wish to put a freeze on their requests, full stop [21:00:05] you should have seen the one he started with [21:25:39] If only @Reception123 were here to see him running around with his bullshit within the span of 24 hours. [21:27:33] Naleksuh This is why I didn't trust Octahedron foundation in the first place. They were being abusive towards YellowFrogger on the Public Test Wiki, then resorting to bugging us over their wiki requests being declined, then being warned multiple times by people like me, @Agent and @YellowFrogger. [21:29:12] Not to mention RhinosF1 had to do what had to be done, which was to block him. [21:31:44] some people need to be contained in their own wiki farms, it seems :ThinkerMH: [21:53:25] I declined their other request [21:53:33] I only approved one of their two [21:53:44] So at least it's only half as bad as it could have been