Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Bad Faith Names

    Bad Faith Names

    One of the things about Open Source is we can name things whatever we want. This comes with a great amount of responsibility though, since we have to both come up with unique, memorable names that make sense and respect everyone else.

    Respect is a funny thing with names. For example, in order to respect my friend Tracy, I wouldn’t name my company LYKES Inc, because that would be very similar to her company of YIKES Inc. But also I know she’s trademarked the domain, which is a smart choice, and that means I have to respect her trademark as well.

    Speaking of Trademarks

    When it comes to trademarks, everything’s a little messier too. 

    This isn’t about not naming your plugin “Google Analytics.”

    This is about when you own a trademark and people are infringing on it, and how you can chose (or nor) to behave.

    This is about being cocky.

    There’s no other way to explain this, but a romance novelist trademarked the word ‘cocky.’

    No, this isn’t a joke. Since 2015, for a number of reasons, the word ‘cocky’ has been super popular with romance authors, and one of them decided to trademark the word. In 2018 she applied for, and got, a trademark on the word. Not just the word mark (which is like Pepsi’s trademark on the word and the font), but also the actual word cocky, as used in romance novels.

    And then she did exact what you’re thinking, and she decided to sue everyone else who was using it.

    Trademark Bullying

    Fallen Hopkins said her reasoning was her users. “I receive letters from readers who lost money thinking they bought my series. I’m protecting them and that’s what trademarks are meant for.”

    When you hear it that way, it does sound a little sensible, doesn’t it? She wanted to help her readers be less confused that “The Cocky Cowboy” isn’t a book in her series “The Cocky Series” (in which there is a book called “Cocky Cowboy”). She kicked the author of “The Cocky Cowboy,” who renamed her book “The Cockiest Cowboy To Have Ever Cocked” and now I’m a little in love.

    Now most of the time you can’t actually do that! I mean, I could name a book “Catcher in the Rye” if I wanted to, because you can’t copyright book or story titles. What you can do is the title of the book as it pertains to non-book goods and services, as long as the goods aren’t the book. With a trademark, if I have a book series, I can trademark the series name (see “Harry Potter and …”), but not a single individual title. Until I make a movie.

    But more to the point here, Hopkins was being a damn bully by deciding she was going act in bad faith.

    Yes. It’s legal, but it’s bad faith.

    Bad faith is simply you doing something that is legal but you know it’s the bad thing to do.

    That’s not a legal definition, by the way. If you look it up in a law dictionary, it involves the intent to deceive, which is a weirder thing. The real question is why is this legal? Right? Why would someone possibly be able to trademark cocky!?

    Turns out, it’s actually not hard to trademark a common word if you do it right. Take Apple, for example. You know, Macintosh the company? apple.com? Right, they trademarked Apple, but only as it relates to computers. I can name my car company Apple Cars if I wanted, but I better keep away from self-driving cars, eh?

    There’s a catch to all this. If you’re in the USA, you may be aware of the First Amendment. You know the one? Well there’s a doctrine about all this that basically exists to stop trademark law from stomping all over our rights. People build careers on this stuff, so the short version for you is that folks who are chapped about this have a damn good case against her doing this maliciously, and getting the trademark overturned.

    The problem is they need lots of money, which they don’t have. We’re talking about a bunch of indie e-book authors, after all. They may not have money but they have the internet, and they’ve been using it to savagely take down Hopkin’s reputation.

    You really should never piss off people who are good with words.

    Cockygate Doesn’t Hold Up

    The good news in all this is the trademark’s being canceled. The bad news is that someone else with deeper pockets probably has a great idea now and is going to be an even bigger problem for people later on.

    People will get confused. People can’t even tell differently named web hosts apart, so of course someone will think “Joe’s Google Analytics for Sports Sites” is an official Google plugin on WordPress.org (seriously someone did). They just don’t read and think, and all the trademark protection in the world isn’t going to help them out.

    But think about how you’re approaching this. Ask people to change the display name of things, and ask them to make sure it’s clear they’re not related to you. And when someone gets confused, point out “That plugin/app doesn’t have my trademark’d logo, so you can see it’s not mine. Sorry about the confusion, here’s mine.”

    If you’re interested, read Vox’s explanation on cockygate and please, don’t be a cock when you’re protecting your trademark.

  • A Case Sensitive Headache

    A Case Sensitive Headache

    Like most people, I pull my site down to develop locally. After all, it’s safer. But also like most people, my live machine is a linux box and my personal machine is not. In fact, it’s a Mac, running whatever the latest OS X is. But don’t worry, today’s drama happens on Windows as well.

    You see, I downloaded my local data, imported my database, changed my URLs to local, and stared at a page that had the wrong data. Or rather, the right data and the wrong image. The page for “Sam” was showing me a photo for another character named “Sam.” But on my live site it was fine.

    Commence the Debugging

    The first thing I did was copy the image to a new folder to try and re-upload it. Only that didn’t work out the way I thought it would. You see, I knew the filename was Sam.jpg so I tried to copy that over:

    cp ~/sites/example.com/wp-content/uploads/2018/05/Sam.jpg ~/Downloads

    Only when I went to look, it was again the bad image. In fact, when I looked at all the files in the folder, there was only one file named ‘sam’ when there should be two

    A list of files in local and live sites. The one of the left is local, and it's missing a bunch of files.
    Local site is on the left, live is on the right

    Things were starting to become clear. Next I copied it and renamed it sam.jpg and got an error:

    Error: The name "sam" with extension ".jpg" is already taken. Please choose a different name.

    I’ve got it now. Mac doesn’t understand the different between upper and lower case. It’s not case sensitive.

    Bad News: No Easy Fix

    I’m really sorry about this. There isn’t an easy fix.

    First of all, if you wanted to fix your main hard drive, you would have to reformat it. That’s a pain in the ass. Second? Your Mac will not be happy and things will break. For example, the Steam app doesn’t like it if your Mac is case sensitive. Seriously, I have no idea why. But it’s what it expects.

    This means the ‘fix’ is to partition your hard drive. Since I’m using AFPS, I opted to make a volume instead of a partition, which feels pretty much the same but it’s not. I opted for AFPS with case sensitive and encrypted because I’m generally a neurotic. Making a volume is very fast, and once I was done, I copied everything in my ~/Sites/ folder over to /Volumes/websites/ (where websites is the name of my new volume).

    And now it looks great!

    Mac OS screenshot showing the files are now case sensitive! Yay!

    Except… I still only see one in terminal. I freaked out for a moment and then I realized that while the GUI is smart enough to know that Sam and sam are both S’s, terminal put the capital letters above the lowercase. So all the S’s came before all the s’s.

    Miss Piggy bashing her head into a table. Which is how I felt about now.

    The last step was to move my copy of Chassis over to the new websites volume, spin it back up, and finally it was working properly.

    The Moral?

    Don’t use case-sensitive filenames. Or filenames with special characters like á or í because operating systems are stupid.

    No seriously, that’s it. Haven’t you wondered why people advocate we all use all lower-case for filenames in our code repositories? Because different operating systems are stupid. They don’t always talk properly to each other, they have different ideas of right and wrong, and they’re never going to agree. If you work with multiple operating systems, aim at the lowest common denominator, pick a style, and stick the hell to it.

    That’s your moral.

  • Data Deletion May Not Be What You Think

    Data Deletion May Not Be What You Think

    So you’re handling GDPR and you have a privacy doc and policy and a plan for people requesting data and, yes, deleting it.

    Eventually someone is going to ask you to delete their content from your site. This is the scary part for most people. Remember, you get 30 days to reply, so don’t panic. Next, figure out what they’re asking for, and if you can say no.

    This is the fun part. You can say no. Sometimes.

    When You Can Say No

    In general, yes, you should delete people’s information if they ask. But if your website stores complicated information this is not actually as black and white as all that. The right to erasure does not apply if retaining is necessary for one of the following reasons:

    • exercising your right of freedom of expression and information
    • meeting any legal obligations
    • performing a task for and in the public interest or in your legal authority
    • archiving information of public interest or for research where deletion would impair the work significantly
    • related to and legal claims you have (or may have)

    This helps you balance out the problem of being told to delete things you need to keep for tax reasons. It also keeps sites that may collect public data for the general public (like wikipedia or a website that tracks queer characters on TV) from losing everything. It won’t protect you from other lawsuits, of course.

    It’s that last one I feel is really important to everyone. That’s the one that means if I block you, I may not have to delete your data, even if you ask, because I may need it for the establishment of legal claims. But that has to be a legit claim.

    You can also just say no for any reason you feel is justified. Now again, do not use this flagrantly. You still have to turn around and tell someone that you’re not deleting their data, so you need to be serious about this.

    Self Protection

    And speaking of being serious, you can actually say no to protect yourself. You see, people can only ask for deletion if the data is no longer needed for the reason it was collected. So if they want to delete their account but keep shopping at your store, you can say no since the information is needed to keep shopping!

    So remember why you track the data in the first place. When people leave a comment, for example, you track their username, email, and IP (and web address if they provide it) in order to know who they are and prevent spam, but also abuse.

    Here’s an excerpt from one of my privacy policies:

    Comments: When visitors leave comments on the website, the collected data shown in the comments form, as well as the visitor’s IP address and browser user agent string are saved in order to help spam detection and abuse.

    Since I retain data to prevent abuse, that is serial internet harassers, you can ask me all you want for me to delete any data I save about you, but I can say no to protect myself.

    When You Say No

    If you decide to tell someone no to a deletion request, you must:

    • provide the reason
    • inform them of their rights to make a complaint
    • inform them of their right to a ‘judicial remedy’

    That last one means yes, they can sue you to delete the data. If they’re abusing you (harassing etc) and you’ve saved all that, you’ll probably win. Which is one reason you should actually save and document people’s actions. I hate having a whole folder on my laptop that documents a bunch of people hating on me, but I need it.

    Basically if you’re going to say no, have a damn good reason, document it, and be prepared for a fight.

    Say Yes If You Can

    Most of the time, it’s no skin off your ear to delete a comment or edit a post. But sometimes it’s going to be a huge deal. And in fact, you can turn around and tell people “If I delete all your data, I will retain information required to identify you in order to prevent you from returning to this site. Deletion requests means you will not be welcome back.”

    If that sounded harsh, well, it can be. Because for most small blogs, consider what they’re asking. When someone asks to delete the content of a personal blog, it’s most likely going to be for a pretty petty reason. Unless they’re asking you to remove information that shouldn’t be public (like their phone or email – and yes, someone’s asked me to delete that before), it’s probably going to be someone asking you to remove a comment that makes them look foolish. Or at least it has been in my experience.

    Make Your Life Easier

    Keep this in mind too. Make your life easier. If you don’t need comments on your site, don’t have them. Turn off that contact form too. But there’s no law that says you need to let people talk to you on your blog. 

    This won’t be true for all situations, but do as much as you can and save yourself that GDPR headache.

  • CMB2: Conditional Meta Fields

    CMB2: Conditional Meta Fields

    Even though Gutenberg is on the rise, and every day gets us closer to using a whole new editor, we still use the ‘classic’ editor and we’re still beholden to it’s space limitations. I have strong feelings about how to properly utilize space when using CMB2, but not included in that specific post is this.

    Fields You Don’t (Always) Need

    There are three types of fields for CMB2.

    1. Fields you always need to use
    2. Fields that are optional
    3. Fields that are needed only in specific situations

    Most of the time we use option 2. Option 3 is the tricky one, though, since most of the time we end up having things show based on actions. That is, I save a post, and new options show up. When it comes to CMB2, we really don’t want to have to save and then edit and save and edit.

    Yuck!

    Thankfully this is all possible.

    Practical Example: Affiliates

    Today we’re making a box to handle affiliate links. There are three types of links: Amazon, Genric, and ‘Unique.’

    The Amazon one will link directly to a signup link and the generic one links to the same thing only on Click Junction. Both of those links will have affiliate details backed in so I don’t have to look them up later. This also means any partners I have on the site don’t need to know all the gory details. Bazinga.

    The last one, though ‘Unique’ is tricky. You see, when someone picks that, I want them to be able to put in a specific URL that may be affiliate linking somewhere else. But let’s start out with how it normally works.

    Make Your Fields

    function my_site_cmb2_metaboxes() {
	// prefix for all custom fields
	$prefix = 'my_sites_';

	// Metabox Group: Must See
	$cmb_affiliate = new_cmb2_box( array(
		'id'           => 'affiliate_metabox',
		'title'        => __( 'Affiliate Details', 'my-domain' ),
		'object_types' => array( 'post_type_shows' ),
		'show_in_rest' => true,
	) );

	// Field Box: Affiliate Type
	$field_affiliatetype = $cmb_affiliate->add_field( array(
		'name'             => __( 'Type', 'my-domain' ),
		'id'               => $prefix . 'affiliate',
		'type'             => 'select',
		'options'          => array( 
			'amazon'  => 'Amazon',
			'generic' => 'Generic',
			'url'     => 'Unique Link',
		);
		'show_option_none' => true,
	) );
	// Field Box: Affiliate Links
	$field_affiliateurl = $cmb_affiliate->add_field( array(
		'name'    => __( 'Link', 'my-domain' ),
		'id'      => $prefix . 'affiliateurl',
		'type'    => 'text_url',
	) );
);

    That’s pretty normal for CMB2 and looks like this:

    CMB2: Affiliate Details

    Normal, but … I want to hide that Link field unless a specific option is selected. Enter javascript.

    Hide That Field (Conditionally)

    Make a file for your javascript. I’ve called mine cmb2.js and put it in the same folder as my file that will enqueue the scripts.

    // Either create a new empty object, or work with the existing one.
window.MySite_CMB2 = window.MySite_CMB2 || {};

(function( window, document, $, app, undefined ) {
	'use strict';

	app.cache = function() {
		app.$ = {};
		app.$.select = $( document.getElementById( 'my_sites_affiliate' ) );
		app.$.field = $( document.getElementById( 'my_sites_affiliateurl' ) );
		app.$.field_container = app.$.field.closest( '.cmb-row');
	};

	app.init = function() {
		app.cache();
		app.$.select.on( 'change', function( event ) {
			if ( 'url' === $(this).val() ) {
				app.$.field_container.show();
			} else {
				app.$.field_container.hide();
			}
		} ).trigger( 'change' );
	};

	$( document ).ready( app.init );
})( window, document, jQuery, MySite_CMB2 );

    And then call the enqueue, but only when appropriate (because we want to keep the load low):

    add_action( ‘admin_enqueue_scripts’, ‘my_site_admin_enqueue_scripts’ );

    function my_site_admin_enqueue_scripts( ) {
    $screen = get_current_screen();
    if ( ! isset( $screen->post_type ) || ‘post_type_shows’ !== $screen->post_type ) return;

    wp_enqueue_script( 'custom-js', plugins_url( '/cmb2.js' , __FILE__ ), array( 'jquery' ) );

    }

    And that works like this:

    GIF of how it shows and hides things

    A Word of Warning

    While all this is great for the sighted people, hiding things is not actually all that great for those who use screen-readers. For that you’d want to toggle the field to be disabled.

  • Consent and Awareness

    Consent and Awareness

    GDPR.

    It’s the bane of many headaches for many web developers, web admins, and in general anyone who uses the internet.  If you’re reading this, it’s probably a headache for you too. So let’s have a real, non-lawyer talk about what’s going on and why you need to care.

    Notice: I’m not a lawyer. This post is not legal advice. Please read the EU GDPR Information Portal and research your specific situation.

    Everyone Needs to Care

    If you thought this only has to do with people who use eCommerce products, think again. The centre of the GDPR is data privacy. That is, the right to have your data removed from websites, when you want. The point to all this is if you have a website, and people visit, you need to care because the following reasons:

    • You have ads on your site
    • You allow comments
    • You use custom avatars (Gravatar)
    • You track visitors (Jetpack, Google, etc)
    • You embed content (Twitter, YouTube, etc)

    Does any of that sounds like you? It sounds like pretty much every public website in existence. And congratulations you need to care about GDPR.

    What You Need

    There are a lot of moving parts here, but the pared down version is this:

    • Know what 3rd party services you use
    • Know what your CMS tool tracks
    • Have a privacy policy
    • Have a way for people to request data deletion

    The first two are surprisingly complicated because, in the case of WordPress,  you might be tracking a lot more than you think. Remember all those things I mentioned above? They all are common situations where your CMS might be tracking people. But what if I told you that a lot of plugins you use also add on tracking? Or record more data than WordPress knows about?

    Like. I wrote a plugin that adds in the IP address used to register an account to the user meta. This means WordPress now records more data. Thankfully that gets deleted when you delete a user account, and it’s generally covered under the broad disclosure that you track users IPs (which every website does). But I have to make sure people who use the plugin know that, and communicate to others.

    That’s a very simple example. Take a plugin that logs user activity for, oh, let’s say security. Now you have to tell everyone about exactly what it tracks (browser information etc) and what you use it for. And you get to figure that out for every single plugin you use.

    This won’t be easy. Unless you read every single plugin you use, you’re going to be at the behest of developers who may not be aware of exactly what they need to disclose.

    Privacy Policies Are a Must

    Every site should have a privacy policy. While for most smaller blogs, the odds are low that anything will happen, you should have one anyway. The problem is that no one can tell you exactly what yours needs to have. I try to cover the four basics:

    • Terms of Use: all the things you agree to by using this site
    • Data Collection: what situations result in my tracking your data, including details on 3rd party services regularly used
    • Data Usage: what I do with data and how long I keep it – also how to request it
    • Policy Changes: a CYA that they’ll likely change

    There are a lot of details in those four sections, especially the Terms, which exculpate me if I get information wrong, allow me time to handle a DMCA, and a whole lot of things. And yes, it’s super daunting, I know. I mean, the privacy policy here isn’t half as robust as some of my other sites.

    The Bottom Line

    You can distill all this into consent and awareness. People need to know what they’re getting into on your site (or at least be able to know – you can’t help people who refuse to read). And you need to understand exactly what your site does. You need to be aware, as a website owner and a user.

    All those terms you ignored when signing up for Google Adsense and Analytics? Now is the time to knuckle down and read, because you need to cover that. All those extensions (plugins and themes) you added? Read up on them too. If they don’t explain what they do with data, ask the developers.

    Developers? Step up. Document exactly what data you save. If you allow for the saving of different kinds of data, based on what the user picks, explain that. But you have to tell people what’s being saved and how to delete it. Most CMS apps now have tools to hook into to aid deletion, so research.

    GDPR kicked in four days ago, but it’s not to late to fix things.