Secure the News is a project that was created by the Freedom of the Press Foundation in 2016 to track HTTPS encryption across major news organizations’ websites. It lists the publications and automatically scores them on a scale of 0-100, based on HTTPS implementation according to best practices, as defined by General Services Administration (GSA) Pulse’s current criteria for modern and secure HTTPS deployment. The score is converted to an A-F letter grade.
The primary benefits of news organizations adopting HTTPS include reader privacy and website security, but there are also other positive byproducts, such as protecting sources and preventing censorship. Secure the News provides some interesting data in its campaign to encourage more broad HTTPS adoption.
In 2018, after one year of collecting data on HTTPS encryption at more than 130 major world news sites, the project found that HTTPS was available on 2/3 of the sites it monitors (89 of 131), up from 1/3 in 2016. Approximately 60% of news organizations offered HTTPS encryption by default in 2018 and that number is up to 93% today.
Most of the WordPress-powered major news sites, such as Ars Technica, Time and the New York Post, get a B ranking, with the exception of TechCrunch and Quartz, which both scored an A.
The most recent addition to the project is the ability to sort publications by region on the homepage. Publications based in North America and Europe lead the world in having the most secure HTTPS implementations. Asia has a smaller percentage of major news sites with a score of A- or higher. Some smaller regions, such as the Middle East and North Africa, Oceana, and South America, list just a handful of news organizations but they all have a score of B or higher. Secure the News is just getting started with this feature and is accepting feedback on the project’s GitHub account.
In addition to promoting HTTPS adoption, the team behind Secure the News is also considering broadening its coverage to measure other ways that news sites are delivering secure content, such as whether the site has an onion service, is Tor project friendly, or has a confidential tip line. The project also has more news sites to add and a long list of improvements they want to make to the metrics used to rank sites.
The code for Secure the News is open source (licensed under the GNU AGPL) and available on GitHub for anyone who wants to contribute or fork it for use with other site categories where browsing might be sensitive, such as libraries, adult sites, educational institutes, or medical facilities.
Seclore, a company working to unify data-centric security solutions, announces the addition of the Seclore Endpoint Auto-Protector SDK to their Data Centric-Security Platform.
The Seclore Endpoint Auto-Protector SDK, a configurable cross-platform tool, enables rapid integration of data-centric security with applications that run on end-users' devices including Endpoint DLP, eDiscovery, Data Classification, and Data Governance solutions.
The typical journey for a person browsing a website: view a page, click a link, browser loads new page. That's assuming no funny business like a Single Page App, which still follows that journey, but the browser doesn't load a new page — the client fakes it for the sake of a snappier transition.
What if you could load that new page before the person clicks the link so that, when they do, the loading of that next page is much faster? There are two notable projects that try to help with that:
quicklink: detects visible links, waits for the browser to be idle and if it isn't on slow connection, it prefetches those links.
instant.page: if you hover over a link for 65ms, it preloads that link. The new Version 2 allows you to configure of the time delay or whether to wait for a click or press before preloading.
Combine those things with technological improvements like paint holding, and building a SPA architecture just for the speed benefits may become unnecessary (though it may still be desirable for other reasons, like code-splitting, putting the onus of routing onto front-end developers, etc.).
I began using WordPress in 2005. I’d already been learning HTML and CSS for a couple of years. I even had a home-brewed blog that pulled posts from plain text files at one point. I knew enough JavaScript to do pop-up alerts and other annoying things that served no purpose and made for a poor user experience, even if they were fun for me.
This was my second attempt at using WordPress. This time it was after a botched go of making PHP Nuke behave how I wanted. I had big dreams for my website but lacked the coding skills to make them happen. WordPress was simple enough to hack for a novice like me at the time. Sure, I broke my site more times than I could count, but I managed to put together my first real theme.
I popped open Photoshop; grabbed a few images from Angel, my favorite TV show at the time; and began my work. I’d recently watched Soul Purpose, an episode that explored whether the titular character was truly the hero mentioned in an ancient prophecy. It was foretold that the vampire with a soul would shed his demon half and live as a human. It explored themes of the character’s place in the world. At 21 years old, it’s the sort of episode that resonated with a young man who was also looking for his place. I thought it fitting to work that into my theme’s design and began hacking away at a header for my theme.
Screenshot of my first WordPress theme header.
At that time, there was this loosely-connected underground of themers and hobbyists who were building WordPress themes based on their favorite TV series, movies, comic books, and more. That was my first real introduction to WordPress. These people were not building themes for profit. They were searching for their place in this small corner of the internet. At most, some were looking for validation from like-minded people who might enjoy their art. It was about creation for the sake of creation. Anyone could be an artist with a simple lesson in CSS, an image manipulation program, and enough grit to pour their soul into the project for a few hours.
If there were ever a time that WordPress themes died, it was when the hobbyists who built for pure passion were overshadowed by business interests.
Don’t get me wrong; business interests played a crucial role in propelling WordPress to become the most dominant CMS in the world. However, the balance has clearly shifted in favor of building WordPress themes for business and ecommerce rather than for the enthusiasts who just want to create. Other platforms have better catered to these users and filled in the gaps left open by WordPress. Tumblr became a safe-haven for popular culture fans. DeviantArt a home for artists. Wattpad for aspiring writers and fanfic lovers.
Somewhere along the way, we lost the innocence and artistry of building WordPress themes for the pure fun of it. WordPress grew up and WordPress themes along with it.
Today’s Themes Are Not Tomorrow’s
In his post, The End of WordPress Themes is in Sight, Ben Gillbanks said, “Themes as we know them will no longer be made.” It is a bleak look at the future of WordPress theming. He notes that he doesn’t believe that he’ll be able to make a living building WordPress themes in the next couple of years.
His worries are warranted. They have been shared by several theme authors over the past couple of years as the block editor (Gutenberg) was making its way into core WordPress. The official theme review team has discussed the team’s future role surrounding the coming changes.
Gillbanks’ post comes on the heels of a post written by Matias Ventura on defining content block areas. Essentially, the idea is for WordPress to allow users to edit areas outside of the post content via the block editor. Anything from the header, footer, sidebar, or otherwise would likely be fair game.
In such a system, themes would be relegated to defining block areas, providing base styles, and designing block output. In many ways, this is what WordPress themes should be. Some might say that WordPress is putting themes back into their proper place of simply styling content. With the behemoth themes with hundreds or thousands of features we’ve seen over the past few years, this could be a welcome change.
There’s huge potential for designers to step up and make their mark. I, for one, wouldn’t mind seeing CSS artists unleashed in the WordPress theme ecosystem.
Gillbanks went on to say:
There are definite benefits to doing this from a user’s perspective – they will have full control of their site – but it’s going to result in some very boring website layouts.
This is the point where I’ll respectfully disagree. Putting control in the hands of non-designers will be anything but boring.
Do we all so easily forget the days of GeoCities? The websites built from it may have been horribly inaccessible. They may have blared midi files as soon as you opened a webpage. They may have even had a flashing, scrolling marquee zipping across the header. Boring is not the word I’d use to describe them.
As much as many of us want to put those days behind us (Come on, you had one of those sites at one point, right? Tell the truth.), there was something fascinating about it all. Real people built these sites because they were fun. The sites told you something about that person. It was a deeply personal look into this stranger’s world. Sometimes it was just a bunch of junk spewed onto the screen, but most sites were a reflection of the site owners at that point in time.
It was ugly and beautiful all the same.
Web developers and designers joke about those dark days of the web. It’s easy to look back at sites from the ’90s and cringe at the silliness (It makes you wonder what designers of 2050 will think about today’s designs, doesn’t it?). I choose to look fondly upon those days. It was a time before I became a “designer” with rules to follow.
But, here’s the important point. We are not the arbiters of the web. It’s all about the user. If someone wants a blinking Justin Bieber GIF in their site header, more power to them. It’s the developer’s job to enable the user to do this in an easy-to-configure way.
Wait? So Geocities is your argument for full-site editing in WordPress?
Understanding why WordPress should become a full-site editor means understanding the average user. Developers are more apt to view things in a structured manner. I spent over a decade honing my development skills. Logic and order are old friends.
With end-users, things may seem a bit more chaotic. A teenager might want to plaster a picture of her favorite band anywhere she wants on her site. A soccer mom might want to show her kid slamming home the winning goal. A poet may want to showcase one of his poems as a background image on his blog. Humans are creative beings. While our unique brand of artistry might not appeal to others, it’s still something we crave to share.
It’s also important to understand that building WordPress themes is nowhere near as simple in 2019 as it was in 2005 when I started hacking away. The code is much more complex. It’s not quite as easy for a new user to piece together something fun as it once was. Unless you have a theme or plugin that allows you to do this with simple drag-and-drop or similar tools, users have little control over their own sites. And, that’s why the Gutenberg project is so revolutionary. Its mission is to put the power back in the hands of the people.
Theme authors need to evolve. They will need to find a way to balance good design principles with the insane amount of freedom users will have. There’s nothing stopping designers from making sure the Bieber screengrab looks more presentable.
Are WordPress Themes Dead?
No. But, the theme landscape will certainly change and not for the first time. We need not look at that as a bad thing.
Those hobbyists who like to tinker with their site, they will once again have power that was so long ago lost to more advanced code.
There will also be sub-communities within the WordPress landscape. Some people will want something more akin to classic WordPress. Others will want a simple blog handled with Markdown (side note: I’m one of those people, and Gutenberg actually handles pasting from Markdown well). Plugins will be built to cater to every user’s needs. Themes will exist for different types of users. Client builds and enterprise solutions that look nothing like core WordPress aren’t going anywhere.
There’s still a long road ahead. Theme authors need to be more involved with the development of Gutenberg as these features make their way into the plugin and eventually into WordPress. Otherwise, they’ll risk losing the opportunity to help shape the future theme landscape.
Truth be told, I’m not sure what themes will look like in a few years. I have a horrible track record with predictions. However, I think it’s safe to say that there’ll be a place for designers.
I’m excited because I feel like it will bring back the potential for users to have the control they once had and more.
After tracking exploits of a zero day XSS vulnerability in the Rich Reviews plugin for WordPress, Wordfence is recommending that users remove it from their websites. The company estimates that there are 16,000 active installations vulnerable to unauthenticated plugin option updates:
Attackers are currently abusing this exploit chain to inject malvertising code into target websites. The malvertising code creates redirects and popup ads. Our team has been tracking this attack campaign since April of this year.
Rich Reviews was removed from the WordPress.org Plugin Directory on March 11, 2019, due to a security issue.
One week ago, a Rich Reviews plugin user reported 3 out of 4 of her sites using the plugin were infected with redirect scripts and that removing the plugin fixed the issue. A digital marketing agency called Nuanced Media, the author of the plugin, responded to the post indicating that a new version would be released within two weeks:
We’ve been working on an overall rewrite of this plugin for a while now, but someone out there apparently wanted us to work faster on it, and decided to exploit our plugin to get some malware out there. We’re now going double-quick on it, and hope to have it back up (and newly cozy and secure) within the next two weeks.
Oddly, there seemed to be no rush to patch the issue that is currently being exploited. Yesterday, less than a week after assuring users that a new version is coming, the company behind the plugin announced that it is discontinuing active support and development on Rich Reviews.
Nuanced Media CEO Ryan Flannagan cited Google’s recent changes to its business review guidelines as the reason for discontinuing its development.
“As part of this update, in the organic search results, Google has decided to remove all merchant review star ratings that businesses display on their own URL,” Flannagan said.
“Based on this information, we have discontinued all active development and support on Rich Reviews. We apologize for any inconvenience.”
The announcement does not include any information about the vulnerability or the recent exploits. Users should assume that no patch is coming to the plugin, since it has been officially discontinued. It’s already not available to potential new users on WordPress.org, but those who have Rich Reviews active on their sites should deactivate it and remove the plugin as soon as possible to avoid getting hacked.
For developers planning to incorporate route optimization in applications they're creating, it's helpful to know the top tips for choosing a routing API. When developers integrate the right routing API, they provide critical functionality for their application. However, choosing the wrong routing API can result in limited functionality and unforeseen costs.
The document signing process plays a crucial role, as it guarantees the creation of binding obligations between the signing parties.
The sales contract looks legalized, have all the parties signed it? Is it the reviewed and latest version? Can it be proved that the document has not been altered before you signed? Is it possible to prove the document you received is identical to the one you viewed earlier?
The Health Insurance Portability and Accountability Act (HIPAA) is a landmark piece of US legislation that was introduced in 1996, in order to safeguard and secure patient information and transmittal. Covered entities (CE) and Business Associates (BA) should comply with HIPAA regulations. Healthcare providers, health insurance plans and healthcare clearinghouses fall under CE whereas Business Associates can be a person or an entity that provides third party services and activities for covered entities, which involve accessing protected health information (PHI). Any information about the health status, provision of healthcare or payment of healthcare services that is created, collected or transmitted by a covered entity and linked with individually identifiable information is considered PHI under US law.
Healthcare organizations have been embracing cloud to cut costs and improve the quality of care. While cloud adoption is a crucial stride for a healthcare entity, it is equally significant to adhere to HIPAA regulations. Ensuring valuable benefits for caregivers and consumers alike, HIPAA establishes standards for the secure handling of PHI.
The terms "memory leak" and ".NET application" are not used together very often. However, we recently had a spate of out of memory exceptions in one of our .NET Core web applications. The issue turned out to be caused by a change in behavior in Entity Framework Core, and whilst the eventual solution was incredibly simple, the journey to get there was both challenging and interesting.
The system itself is hosted in Azure and is comprised of an Angular SPA front-end and a .NET Core API on the back-end, using Entity Framework Core to talk to an Azure SQL Database. As a software consultancy specializing in .NET development, we've written many similar applications before.
Memory management is a key factor when we develop apps. If a program is using a lot of memory, it can make apps run slowly or even cause crashes. To handle this in Swift, you can work with Automatic Reference Counting (ARC) to keep your apps memory usage minimal. This doesn’t mean you can completely forget about the memory in your app, but it does take care of most things for you.
It’s important to note that ARC only works when working with classes. Structs and enums are value types and therefore are stored differently in memory than classes, which are stored and passed by reference.
A lot of people want to start programming apps for Android, but they prefer not to use Android Studio and/or Java. Why? Because it's an overkill. "I just wanna create Snake and nothing more!"
SmashingConf 2020 – San Francisco, Freiburg, New York And Austin
SmashingConf 2020 – San Francisco, Freiburg, New York And Austin
Rachel Andrew
We’ve been running SmashingConf since 2012, when we held our very first conference in Freiburg, Germany. Since then, we’ve continued to experiment and improve on our conference experience. Our aim is that you enjoy your time with us, but also return to work with new insights and knowledge. Each time we hope to leave you with practical takeaways that will help you in your own work and want to share with your team.
What is a SmashingConf like? It’s hard to explain until you have been there, however ,this video compilation from Toronto might just give you an idea!
Experimenting With Presentation Formats
Back in 2018, we began to experiment with the live-coding format. While not every presentation at SmashingConf was live-coded, many presenters brought a live element to their talk. Some speakers opted to present without slides completely, and these interactive sessions have been incredibly popular with audiences. Being able to watch an expert doing their work, seeing the tools they use and the choices they make in real time, brought many subjects to life.
“I love the fact that this talk format also kind of rid me of the expectation that it needed to be flawless.”
Many of our speakers enjoyed the chance to try something different on stage; some have gone so far as to decide to make live-coding part of how they present in the future.
“I didn’t expect this, but I’m now seriously considering this format as a way I do talks at other conferences.”
Not every talk fits a live-coding format, of course. Throughout 2019, we feel that we’ve found a great balance of practical live-coded (or live-designed) sessions, more traditional presentations with slides, and some which have mixed the two approaches. SmashingConf audiences are a mixture of designers and developers, of visual thinkers and those who learn best from seeing a lot of code.
“A few designers felt validated in their processes by seeing mine [...]
“A few developers said design felt less intimidating now, both to understand as well as to try.”
In mixing up the formats as well as the subjects being discussed, we hope to bring parts of the industry to life — even for those who don’t normally work in that area.
Talks are usually followed by an interview. (Photo credit: Drew McLellan)
In addition to playing with the format of presentations, we encourage audiences to engage with the speakers and each other. Talks are followed by an interview on stage — with the emcee posing questions asked by the audience. We publish a live Google Doc, so everyone can share their thoughts and ideas with the speakers as well as each other. Most of our speakers will attend the entire event, and enjoy the chance to chat with attendees. We believe everyone has useful knowledge to share — whether on stage or from the comfort of your seat!
Looking Forward To 2020
SmashingConf has always taken a holistic approach to the web. We believe that we all do better work when we work together and understand something of the roles of other team members. In 2020, we hope to build on the successes of 2019 by continuing to bring you some of the best live sessions — mixed with case studies, opportunities for networking, and surfacing some topics that are sometimes forgotten when focusing on design and development! We’ll cover topics such as HTML email, internationalization and localization, how to provide more accurate estimates, privacy, security, refactoring, debugging and the way designers and developers think as they work through their tasks and challenges.
We’re currently working hard on curating the line-up for all of the events next year. So, the big question is… where will you join us?
San Francisco, Freiburg, New York Or Austin!
The Smashing Cat will soon be on its way to Austin for the first time. We’re really excited about heading to Texas and about our events in cities we already know and love. Over the next few months, we’ll be announcing speakers and schedules for all of the events, but early-bird tickets are already available for San Francisco, Austin, and Freiburg 2020.
This year’s events have all been sold out well in advance of the conference dates, so mark the following dates in your calendars, have a chat with your boss, and work out where you will be heading to spend a fun and educational few days with the Smashing crew!
San Francisco, USA
SmashingConf SF will be taking place on April 21–22 where we’ll be bringing back two full days packed with front-end, UX and all that jazz! Live sessions on performance, accessibility, security, interface design, debugging and fancy CSS/JS techniques — and a few surprises along the way, of course! 🎸
Austin, USA
SmashingConf Austin will be taking place in the wonderful ZACH Theatre on June 9–10, 2020. Tacos, cats, and a friendly community — see ya in Austin, I reckon? 🌮
Freiburg, Germany
We will be returning to our hometown for SmashingConf Freiburg on the 7-8 September 2020. We pour our hearts into creating friendly, inclusive events that are focused on real-world problems and solutions. Our focus is on front-end and UX, but we cover all things web — be it UI design or machine learning. The Freiburg edition is, of course, no exception!
New York, USA
Join us for SmashingConf NYC on the 20-21 October 2020. This event is always a popular one, so watch out for tickets going on sale very soon!
A director is the chief person, who is responsible for the creative aspects of the project. He/she is in charge of bringing a story to life. Being a film director is a fulfilling career path. But just like any other career, it is filled with challenges. If you’ve been wanting to direct your own movie, […]
I woke up one morning and realized that I had it all wrong. I discovered that code and design are unable to solve every problem on a design systems team, even if many problems can be solved by coding and designing in a dark room all day. Wait, huh? How on earth does that make any sense? Well, that’s because good design systems work is about hiring, too.
Let me explain.
First, let’s take a look at some common design systems issues. One might be that your components are a thick div soup which is causing issues for users and is all-round bad for accessibility. Another issue might be that you have a large number of custom components that are fragile and extremely difficult to use. Or maybe you have eight different illustration styles and four different modal components. Maybe you have a thousand different color values that are used inconsistently.
Everyone in an organization can typically feel these problems but they’re really hard to describe. Folks can see that it takes way longer to build things than it should and miscommunication is rampant. Our web app might have bad web performance, major accessibility issues and wildly inconsistent design. But why is this? What’s the root cause of all these dang problems?
The strange thing about design systems is it’s difficult to see what the root cause of all these inconsistencies and issues might be. And even the answer isn’t always entirely obvious once you see the problem.
A design systems team can write component documentation to fix these issues, or perhaps refactor things, audit patterns, refactor even more things, redesign components, and provide training and guidance. But when apps get to a certain size then one person (or even a whole team of people) tackling these problems isn’t enough to solve them.
Sure a design systems team can spend a whole bunch of time helping fix an issue but is that really the best use of their time? What if they convinced another team in the company to instead hire a dedicated front-end engineer to build a sustainable working environment? What if they hired an illustrator to make things consistent and ensure high quality across the entire app?
This is why design systems work is also about hiring.
A design systems team is in the perfect place to provide guidance around hiring because they’ll be the first to spot issues across an organization. They’ll see how components are being hacked together or where there’s too many unnecessary custom components that are not part of a library or style guide. The design systems team will see weaknesses in the codebase that no one else can see and they can show which teams are missing which particular skill sets — and fix that issue by hiring folks with skills in those specific areas.
If you're in management and don’t see all those inconsistencies every day, then it’s likely nothing will get done about it. We're unlikely to fix the issues we cannot see.
So as design systems folks, we ultimately need to care about hiring because of this: a codebase is a neighborhood and a community.
And the only way we can fix the codebase is by fixing the community.
Interesting research from Jonathan Sampson, where he watches the network requests a browser makes the very first time you launch it on a fresh install, and otherwise do nothing. This gives you a little insight into what kind of information that browser wants to collect and disseminate.
This was all shared as tweets, but I'm linking to an unrolled thread if there's one available:
Do you ever feel like you are failing or wasting time? There are primarily two situations in this realm that I think need an alternative point of view; a more extended investigation that has led to nothing and getting rid of past work.
Microservices are getting increasingly popular for the development of new applications or modernizing existing legacy applications. Here, I would focus on how easy it is to develop microservice using Visual Studio IDE in .NET Core 2.2 framework.
