[ad_1] In July, Termly announced its acquisition of the GDPR/CCPA Cookie Consent Banner plugin. The new direction was an overhaul of the WordPress extension, turning what was once a free offering into, essentially, a commercial SaaS product. Users could run the service for up to 100 visitors. After that, the cheapest tier would cost $180 per year. Despite multiple notices that changes were coming and making sure auto-updates were disable so that users would find no surprises, the move has not sat well with many people. Since the plugin update, users have taken to the WordPress.org review system. Across the board, they have left nothing but one-star ratings in the past month and a half. The free tier limit of 100 monthly visitors did not feel free at all to many. By the middle of August, the Termly team had responded after listening to this feedback and making some changes. The company bumped the limit to 10,000 unique visitors, making it a free solution for far more users. Termly is also dedicating more team members to responding to questions on the WordPress forums. “Termly has offered a consent management solution for years, and our pricing structure has been this way for 1,000s of existing customers,” said Raffaele Riconosciuto, Director of Marketing at Termly, when asked whether the 100-visitor limit came up in discussions before launch. “In all honesty, we simply did not consider it since our new customers view our pricing structure favorably. In hindsight, the structure is less favorable for people who are currently getting something for free, and thus why we made the changes as quickly as we could.” A 10,000 visitor limit on the free tier is likely to be a much more reasonable limit for the average website. Beyond that, site owners will need to account for a monthly or yearly fee. Some users may still have issues with the plugin being rolled into a SaaS offering, needing to sign up for a third-party service. However, Riconosciuto said Termly needed to go in this direction. “The SaaS structure we’ve adopted is ubiquitous for most consent management platforms (CMPs) today,” he said. “Given that data privacy laws are constantly evolving, as are mechanisms for tracking users on the web, CMPs require a high degree of maintenance and upkeep just to keep their users meeting base legal requirements. We are also continuing to develop new functionality to make the process more painless and robust. Hence why we charge a recurring subscription cost to our more advanced users, who subsidize the always-free tier.” Termly already had a robust platform in place that serves customers inside and outside of the WordPress ecosystem. It did not make sense to rebuild the entire platform within the plugin and maintain them separately. It would have created duplicate development work without a need to do so. Users can still install the cookie consent banner without leaving the WordPress admin panel, but further customizations happen via the Termly dashboard. Riconosciuto said the team may extend the UI integration between the plugin and service in the future if that is where user feedback leads them, pulling more functionality into WordPress. The other side of this is that previous plugin versions were not compliant with several data privacy laws, including the GDPR and ePrivacy Directive. “The GDPR and ePrivacy Directive are the main EU legislation governing the use of cookies and similar tracking technologies,” said Riconosciuto. “In the context of cookie consent management and cookie banners, the most important takeaway is that a business must obtain consent from an end-user before they serve them non-essential cookies. Consent must be free, specific, informed, and unambiguous. The old banner does not block cookies or contain the information required to ensure when an individual interacts with the banner, they have provided consent to the satisfaction of these legal requirements.” Of the legal mazes businesses must navigate, Riconosciuto said that each EU member state had “transposed the ePrivacy Directive into local cookie laws.” Termly looks at the guidance issued from each of these member state regulators when determining how to implement the cookie banner. “Why does following the law and related guidance matter?” asked Riconosciuto. “Recently, we have seen regulators in these regions taking enforcement action against entities that fail to comply with the guidance they have provided for how to comply with the cookie laws. Unlike the GDPR, ePrivacy directive, and France’s cookie law, guidance, and recommendations from an EU regulator is considered ‘soft law’ and not binding. However, the guidance typically explains how a regulator will determine if a business is violating a local cookie law (i.e., how they will enforce the cookie law). That means if your business’s cookie practices fail to satisfy the requirements laid out in regulator guidance, you are likely violating cookie law and may be subject to enforcement action. Even more, organizations in the EU like NYOB are relying on these laws and soft guidance to determine whether they will file draft complaints with regulators against businesses in violation of these laws.” Riconosciuto mentioned several areas where the older versions of the plugin did not comply with the laws. However, the updated plugin and service take care of these issues. The following is a non-exhaustive list: The solution must actually block cookies and tracking. Cookie consent banners must honor user choices. The language must adequately notify users of what they are agreeing to before consenting. Consent banners must allow the granular selection of cookies by category (e.g., performance and functionality, advertising, analytics, social networking, etc.). Provide clean and easily accessible information and options for accepting or rejecting at the first level without being deceptive (e.g., all buttons should be the same size and format). The banner must generate and save an audit log of consent interactions. These may need to be presented to regulators. While users may continue using an older version of the plugin, Termly does not recommend it because it is non-compliant. The company has no plans to restore any parts
Continue readingTag Archives: Feedback
WordPress Contributors Actually Do Listen to Feedback and Engage With the Community – WP Tavern
[ad_1] I am a writer. That gives me a license — not to be overused — to steer into hyperbole once in a while. I get to be critical, sometimes overly, because I can come back the next day and shower the WordPress project with praise. Perhaps, at times, I forget to be as fair or kind as I should be. Maybe I miss the mark when pointing out faults once in a while. I am sometimes simply wrong (as one reader recently pointed out, that was the case with 90% of what I wrote). And, for those times that I do step out of bounds, I am sorry. However, it always comes from a genuine love of our community and loyalty to the WordPress mission. I had planned on writing about an upcoming feature change for WordPress today, but something more pressing came up. As I was working through that article, a new comment landed in my inbox for approval. It was on the borderline, that gray area where I had to determine whether it added enough value to the discussion. I felt like it needed a thoughtful reply and not the knee-jerk reaction I had initially written. It was gnawing at me because I knew few things could be further from the truth: When Matias and Justin respond to comments and ask the commenters to supply more details about the problems they mentioned, I doubt many will do that, since many of us already know that the WordPress developers don’t listen to us. They maybe pretend to listen, but the evidence shows that they do not. As one other commenter mentioned, we are suffering the tyranny of the minority. Christian Nelson It is disheartening when I see comments that state that the core contributors do not listen to users. However, I do understand where some of that sentiment may come from. There have been many pet features I have been passionate about that have never gotten the green light. Tickets that seemingly die out from lack of interest. Unresolved disagreements. It can become easy to think that you are shouting into the void. However, it is not because developers are not listening. That is not a fair statement to make. In my line of work, I follow nearly every aspect of the WordPress project. From Trac tickets to GitHub pull requests, from business acquisitions to theme development, I tend to dabble in a bit of it all. More often than not, I see others who care as deeply about the project as I do. I watch the core/inner developers — the folks who do the bulk of the work — gather and act upon as much feedback as possible. I see the same from people who are less in the public spotlight but just as vital to the community. Everything I see stands as overwhelming evidence that they listen. There is so much engagement on GitHub, Slack, and the Make blogs that I cannot keep up with it all. Matías Ventura, the Gutenberg project lead, has always been approachable and seems to care deeply about the project’s success. I cannot recall ever reaching out to anyone working on WordPress who did not respond, even when I approached them outside of my role as a writer for WP Tavern. I am amazed at how much time and energy Anne McCarthy puts into the FSE Outreach Program. Mostly, it is because I do not think I could do that job. For every complaint, criticism, or issue I have mentioned, she has dug up an existing ticket or filed a new one. She routinely does this for everyone who provides feedback on FSE. I could list name after name after name of others who do the same, going above and beyond their typical roles. Today, I was reminded that we all — including myself — sometimes need to step back and evaluate how we view this project and the people who are working on it. Thousands of people contribute code, documentation, design mockups, translations, and much more. There are plugin authors who see a problem they want to solve. Developers who figure out how to do something and write a tutorial. This, still, is barely scratching the surface. Contributing directly to the core project or being involved with the Make WordPress teams is often a thankless job. But, I am happy that so many are willing to bear the brunt of the criticism and continue working. Not everything we want will be implemented how or when we want it. Developers must balance each new feature or change against different, often conflicting, feedback. They do not always make the “right” call, but the best thing about software is that you can iterate upon it, bettering the platform from feedback on the earlier implementation. Sometimes, WordPress simply needs more folks contributing to create a new feature or implement a change. Developers are only human. We are all riding this ship together. We should strive to be kind and fair, avoiding blanket statements of the people who pour their hearts and souls into the project. If nothing else, let’s take folks at their word when they ask for more details about a problem. That could very well be the first step in actually finding a solution. Before stepping off my soapbox, I want to simply say one thing to those who contribute in any capacity to the WordPress project: thank you. Like this: Like Loading… [ad_2] Source link
Continue readingOpen Meeting and Call for Feedback – WP Tavern
[ad_1] The WordPress.org Themes Team announced an open discussion and date for a Zoom meeting with theme authors. The team is proposing a new set of guidelines that reduces and simplifies what is currently in place. Comments on the proposal are open through July 26, and the meeting is set for July 28, 2 pm CET. This is the next step in an ongoing plan to revamp the review system and make it easier for the WordPress community to submit themes. It comes after months of waiting to see the results of earlier discussions unfold. In January, the state of the theme review system seemed to have reached a crossroads. The Themes Team, a group of gatekeepers that oversees submissions to the official WordPress.org theme directory, had been making strides in the previous couple of years. Its members had cleaned up most of the submissions backlog, but they still had a lot of work ahead to smooth out the review process. On the whole, a series of incremental improvements seemed to be working at the time, albeit slowly. Then, WordPress project lead Matt Mullenweg dropped a bombshell via the Post Status Slack: The .org theme directory is particularly bad when you compare it to any half-decent commercial theme marketing page, or the designs available on other site building services or Themeforest directories. The .org theme directory rules and update mechanism have driven out creative contributions, it’s largely crowded out by upsell motived contributions. It was an age-old discussion of whether the theme review guidelines were too high of a barrier for entry into the directory. Were WordPress users missing out on the best themes because the most innovative theme authors were not playing in the .ORG sandbox? If so, were the rules driving them away? No one can know if a more lenient, free-for-all atmosphere would have unleashed a mountain of creativity paralleling or besting commercial theme producers. But, perhaps if the team opened things up, it would test the theory. That initial post led to a series of discussions and a decision to overhaul the system. However, the Themes Team would need some help from the Meta Team to implement more automation of its grunt work, such as security and other code checks. Behind the scenes, pieces of that system have been put into place in the months since. Guidelines Proposal and Questions Themes Team representative Carolina Nymark listed a set of 13 overarching guidelines, each with sub-guidelines of their own. The proposal significantly simplifies the current rules for submission into the directory. She asks that theme authors review the proposal and answer the following questions in the comments ahead of the meeting: Will the updated requirements make it easier for you to submit themes?– If no, what is making it difficult for you to submit themes? Will the updated requirements make it easier for you to review submitted themes?– If no, what is making it difficult for you to review themes? Are there requirements that need to be removed, and why? Is there anything in the list of requirements that is unclear? Describe the issue. Can the formatting of the page be improved to make it easier to read? The current proposal is more expansive than the shortlist of guardrails WordPress executive director Josepha Haden Chomphosy mentioned in a post that laid out the next steps. Most of these were not meant as blockers for submission. “Rather we should use the list to flag themes that have/don’t have each thing and show them in results accordingly,” she wrote. “Likely exceptions to this would be proper licensing, adherence to fair use of the trademark, and a ban on child pornography or other images of anyone unable to provide consent.” The goal was to put more responsibility into the hands of users, granting them privileges to say whether a theme was working or not. This would take a lot of the work off the shoulders of the review team. Another part of the original proposal was to mark themes with “quality tags” that went above and beyond the baseline for approval. For example, internationalization (i18n) and accessibility (A11Y) are items that do not stop a theme from technically working. Instead of making these requirements, themes would merely be tagged if they met those standards. Presumably, there would be incentives for taking those extra steps for theme authors, such as higher search rankings, the ability to be featured, and more. It is not that i18n and A11Y standards are unimportant, but they are sometimes hindrances to first-time authors. And, they definitely fall within the range of things that end-users can dock themes for in the ratings. Many will take a hard stance on i18n and A11Y, but they are merely examples. A less controversial guideline might be the one that proposes that themes can only recommend plugins directly hosted on WordPress.org. Why should that be a blocker for inclusion in the directory? Some will say there is no good reason for it since themes are disallowed from installing plugins anyway. There are no technical issues with allowing such recommendations. It is these sorts of rules that have plagued the theme review process over the years. Often, it moves discussions into ideological territory that most users do not care about. They just want themes that work. Under the new proposal, moving to 100% blocks would further reduce requirements for developers. Currently, classic themes have a more extensive list of rules they must adhere to. Many of these are unnecessary for block themes, essentially cutting everything back to including a few required files. Most of this can and should be automated in the long term since they are necessary for a functioning theme. Right now, the 13 guidelines (and their sub-guidelines) are only a proposal. Theme authors have a voice, but they must use it. As is so often the case, decisions are made by those who show up. Far too often, the team is shouting into the void, awaiting a response
Continue readingGoogle Concludes FLoC Origin Trial, Does Not Intend to Share Feedback from Participants – WP Tavern
[ad_1] Google quietly concluded its FLoC (Federated Learning of Cohorts) origin trial this week. The trial was part of Google’s Privacy Sandbox initiative, a suite of new technologies designed to replace third-party cookies, fingerprinting, and other commonly-used tracking mechanisms. This particular experiment groups people together based on browsing habits and labels them using machine learning. FLoC’s trial was scheduled to end Jul 13, 2021, and Google has decided to remove the project from the testing phase while analyzing feedback. “We’ve decided not to extend this initial Origin Trial,” Google senior software engineer Josh Karlin said in thread on Chromium’s Blink Developers group forum. “Instead, we’re hard at work on improving FLoC to incorporate the feedback we’ve heard from the community before advancing to further ecosystem testing.” The controversial experiment has been met with opposition from privacy advocates like makers of the Brave browser and EFF who do not perceive FLoC to be a compelling alternative to the surveillance business model currently used by the advertising industry. Amazon, GitHub, Firefox, Vivaldi, Drupal, Joomla, DuckDuckGo, and other major tech companies and open source projects have already opted to block FLoC by default. So far, Twitter has been the first major online platform that appears to be on board with FLoC after references to it were recently discovered in the app’s source code. Google’s initial efforts in presenting FLoC failed to gain broad support, which may have contributed to the company putting the brakes on its plan to phase out third-party cookies in Chrome by 2022. As the advertising industry yields to pressure from the last few years of privacy legislation, third-party cookies will be on their way out in what is colloquially known as the “Cookie Apocalypse.” Google has postponed this milestone for Chrome to begin in mid-2023 and end in late 2023. “We need to move at a responsible pace,” Chrome Privacy Engineering Director Vinay Goel said. “This will allow sufficient time for public discussion on the right solutions, continued engagement with regulators, and for publishers and the advertising industry to migrate their services. This is important to avoid jeopardizing the business models of many web publishers which support freely available content.” Discussion on a proposal for WordPress to block FLoC has stalled in Trac but may have been premature in the first place if FLoC doesn’t end making it to further testing. Proponents of blocking FLoC saw WordPress’ support or opposition as critical to the success or failure of FLoC adoption on the web. A recent article on the WordPress.com VIP blog titled “Goodbye, Third-Party Cookies, Hello Google’s FloC,” indicates that Automattic may be straddling the fence on the controversial new technology: FLoC has its plus points. But it isn’t as privacy-focused as we would like, and can lead to discriminatory practices, as described above. Then there’s the concern of letting Google dominate yet another aspect of tech. Google also plans to charge any third-party tracking company for use of any of the data it has collected. For the time being, it looks like major tech platforms are off the hook for taking an active position on FLoC since it has been sent back for major modifications. In the most recently updated timeline for Privacy Sandbox milestones, Vinay Goel said Google received “substantial feedback from the web community during the origin trial for the first version of FLoC.” At the conclusion of its origin trial, FLoC seems far from ready for adoption, having failed to gain a foothold in the industry. The concern is that Google may ram FLoC through anyway using the weight of Chrome’s market share, despite the web community’s chilly reception. Although these proposed changes to ad tech will impact the entire industry, as well as regular internet users, Google does not intend to disclose any of the private feedback the company received during FLoC’s origin trial. “The main summary of that feedback will be the next version, and you can surmise based on what features (and the reasoning for these changes) are available in the next version,” Google mathematician Michael Kleber said during a recent Web Commerce Interest Group (WCIG) meeting. Privacy advocates want to see more transparency incorporated into this process so that major concerns are not left unaddressed, instead of leaving it to stakeholders across the web to try to deduce what Google has solved in the next version of FLoC. Overhauling the advertising industry with new technologies should be done in the open if these changes are truly intended to protect people’s privacy. Like this: Like Loading… [ad_2] Source link
Continue reading