Thursday, January 30, 2014

Network Solutions Is Most Likely Not Phishing

You may have read my rant earlier this week about Network Solutions trying to trick me into allowing them to send me spam. As part of that dark pattern, Network Solutions asks me to verify my contact information, and then tries to up-sell me, and then suggests that I need to verify my contact information (but which is really a spam opt-in).

You can imagine I am primed against being asked to confirm my information by Network Solutions.

For a little extra context, since I receive a few emails a week from Network Solutions (such as this one to auto-renew, or this one for SEO, or this one to obfuscate my WHOIS info), which jumps to daily after I partake in any activity on the Network Solutions site, I typically filter them into dev/null/i-mean-it.

So I was wary when I received the following email once yesterday (the day after I renewed my domain) and once again today:

Screen shot of the offending email.
I block Outlook from downloading embedded images to prevent spammers tracking when I have opened their emails, hence the missing images.

The message within:

Dear Customer,

New Regulations now require that domain account holders confirm their email information otherwise their domain will be deactivated. If your domain is deactivated you will still own the domain but you will not be able to have a live website until you verify your contact information.

To ensure your domain(s) remain active, please click the CONFIRM button below to confirm the email address we have for you is accurate.

Note the explicit threat. Note the lack of a link to the new regulations, let alone the source of those regulations. Note the shiny red all-caps CONFIRM.

I think we've all spent enough time as family tech support to know that you aren't supposed to click links in emails. My bank tells me this, the government tells me this, it's on general support sites, and even Network Solutions has had to tell people not to click links in emails (not to mention recent news of a GoDaddy hack). Heck, robots know this — f you type don't click into the Google search box, it will auto-complete with on links in email:

Image of Google's auto-complete search box.
I know this is anecdotal, but it's a great image to make my point.

Because I am a child of the internet age, and because the support phone number in the email could point to anyone, I contacted Network Solutions on Twitter to see if this was for real:

It's like I'm texting with a 13-year-old.

Reassured the phone number in the email is a true Network Solutions number, I called and navigated the menu system. After I explained the situation and why I don't want to click the link, the representative explained that my domain will be shut down if I don't do it. He could not offer a time frame (but he hadn't seen anyone shut down because no one has waited more than two weeks). He also said he cannot do this over the phone and that I must click the link.

When I pressed for the regulation, he said it's an ICANN regulation but could not tell me where to find it. He explained that if I don't respond, eventually my domain will point to a parked page (my word), though he didn't know if it's an advertisement-laden Network Solutions page or an ICANN page.

When I got off the phone, I looked around for an ICANN regulation. The closest thing I found was in a PDF dated June 27, 2013 (page 43, under WHOIS Accuracy Program Specification):

Registrar shall implement and comply with the requirements set forth in this Specification […]

  1. […] within fifteen (15) days of (1) the registration of a Registered Name sponsored by Registrar, (2) the transfer of the sponsorship of a Registered Name to Registrar, or (3) any change in the Registered Name Holder […]
    1. Verify:
      1. the email address of the Registered Name Holder (and, if different, the Account Holder) by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar, or
      2. the telephone number of the Registered Name Holder […]
      In either case, if Registrar does not receive an affirmative response from the Registered Name Holder, Registrar shall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information.

Having registered and renewed domains since July, and given that this was a renewal, the fact that I just got this for the first time does seem like the implementation has been delayed.

So by that language, yes, Network Solutions can do exactly what it is doing. Given Network Solutions' constant spam, constant final notice of deactivation messages that are not, in fact, final, and folded in with its dark patterns on the web site, I don't trust anything I get from Network Solutions as far as I can spit it. It doesn't help that I saw no notifications of this (unlinked) nameless regulation when I was in my account two days ago, so I also wasn't primed for it after I had just verified my contact information.

So what's the takeaway here? Don't do what Network Solutions does and you will have taken a big step to avoid being viewed as a spammer or phisher by your own customers.


Update: February 7, 2014

The day after I posted this, Network Solutions offered some explanation on its blog: "Domain Verification Emails from Network Solutions Related to New ICANN Security Regulations." I found out about it today when Network Solutions responded to my latest related tweet:

Update: February 19, 2014

As you can see in the comments below, one user commented on the Network Solutions blog post, was acknowledged, and then Network Solutions removed the commenting feature altogether. He was able to provide me with a screen capture of the comments (and reply) from Disqus:

Screen shot of the Disqus discussion.
Screen shot of the Disqus discussion. Transcript now available.

Update: April 10, 2014

Meanwhile, after telling me to click the link in the email (see above), NetSol is telling other users not to click links in email, "to be safe." This certainly doesn't help reduce confusion.

Tuesday, January 28, 2014

Network Solutions and Yet More Dark Patterns

In late 2012 I related my extreme displeasure of trying to register a domain through the intentionally confusing Network Solutions ecommerce flow. In my post, Network Solutions and Dark Patterns, I used a whole lot of screen captures to show the convoluted flow that I believe Network Solutions uses to trick its customers into agreeing to add-on services (and cost).

I noticed a fresh one today as I had to go in and renew a personal domain and quickly recognized that it behooves you as the customer to read every piece of text Network Solutions puts on the screen, else you'll agree to things you did not intend. I walk through the process below (in far fewer screens than last time).

Upon Signing In

Screenshot of Network Solutions login flow.
The screen immediately after logging in, with a form asking for contact verification.

As soon as I sign in, Network Solutions wants me to verify my contact information. This makes sense to me. After all, it's hard to notify someone that his/her domain name is about to expire when he/she has changed email addresses and not updated it here.

The text is straightforward:

To ensure that you receive essential information about your account and services, please confirm the contact information that we have on record for you.

Now the First Pitch

Screenshot of Network Solutions login flow.
This screen is trying to get me to add the Private Registration service. Note the red italic style in the graphic for the word exposed.

Unsurprisingly, I am asked to buy into Network Solutions' obfuscation service. Using scary language, this is the first pitch to try to get me to add some services:

Your name, phone number, and address are listed in the public WHOIS database for your domain(s).

Apply Private Registration to your domain(s) to safeguard your personal information.

The phone book, among many other public databases, has had my information on file for years. I can skip this and its undisclosed costs.

Check Your Contact Information

This is where it goes all wrong.

Screenshot of Network Solutions login flow.
This screen is ostensibly asking me to verify my email and phone number, but a careful read shows that's not the case.

Now I am presented with a screen asking me to Check [My] Contact Information. On my first visit to this page I was just about to click the submit button when I remembered that I had already confirmed my contact information when I logged into the site. So I opted to read the opening sentence:

Please confirm the contact information for Adrian Roselli to ensure that you receive important communications about your account.

Yep, this sounds like what I already did. Time to read the small print at the bottom:

* By submitting the contact information above, you expressly consent to and its affiliates contacting you regarding your services and offering new services via the contact information you provide (including your mobile number), via an automatic telephone dialing system or pre-recorded call. You are not required to give consent in order to make a purchase with us or our affiliates and you can find additional information in our Privacy Policy. Click here to remove your consent.

I emphasized the hyperlinks above. Affiliates. Privacy Policy. Click here. That last one is key. You have to click here to remove your consent. It's carefully hidden (note the red arrow in the screen shot above) behind the awful link text click here and suggests that I am already opted in.

Screenshot of Network Solutions login flow.
I reproduce the small text on this screen below.

As I dutifully click there, the content expands to show me the following checkbox — which is unchecked:

I do not consent to and its affiliates contacting me through automated telephone dialing systems, pre-recorded calls or text messages on my mobile phone, or through pre-recorded calls on my residential line.

As I read that text I realize I am giving Network Solutions, and anyone it and deem worthy, the right to send me text messages. I note that because many people have to pay for their text messages. The robo-calls are just as annoying, of course, but I personally take umbrage with the text message approach.

Screenshot of Network Solutions login flow.
Apparently I cannot not submit information.

I check the box and, just to be on the safe side, clear my phone number before I submit the form. I get this seemingly offshore-call-center-poorly-localized error message:

Please, fill the empty fields.

Once I enter a number again I am allowed to continue and am thanked with this absurd message:

Screenshot of Network Solutions login flow.

To be fair, that's not a dark pattern. However, waiting an additional 5-6 seconds after wasting a few minutes with this stupid process of trickery just to see an animated GIF imply that whatever is happening in the background must be so important to also affect my ability to spend my money warrants some mocking. Deep breath.


Network Solutions may be less evil than some other registrars (sideways glance at the despicable GoDaddy), but by all means read every piece of text and every button before you sign away your text message limits or, as in my previous post, end up paying for services you cannot cancel.

By the way, if I do accidentally give my permission, I challenge you to find where in the interface I can revoke that permission.

Sunday, January 19, 2014

Comparing Opera Mini and Chrome Compression

Depending on how much you spend staying up on web browsers, you've probably heard the cry of Opera did it first more than once (though the low-hanging fruit, browser tabs, wasn't technically Opera first). When Google announced that Chrome would offer a data compression mode, you may have figured you'd hear it again owing to Opera Mini.

In 2004, Opera developed Mini as a browser backed by proxies to help reduce data use and speed up the overall experience. In 2006 Opera Mini went worldwide. Sadly, StatCounter doesn't break Opera Mini out from regular Opera Mobile, so it's hard to get a sense of Mini's market share. Opera's own numbers, however, report 241 million Mini users worldwide in November of 2013, with an annual increase of 21%.

Chrome for mobile devices has been climbing in use, partly because Android devices have started to move away from the default Android browser (though this doesn't affect all the Android 2.x devices and many of the 4.x devices that will be out there for a while). By adding support for data compression, Chrome is that much more appealing to users who have bandwidth caps, poor connections, or any other factor that limits how well they can see fat pages. Interestingly, some of the data compression comes from converting all the images to WebP (ol' Gil has finally found a way to make that format work). Chrome also automatically puts you into Safe Browsing mode as part of its compression process.

So I fired up both browsers, chose a list of web pages/sites that I haven't surfed using either of them, dropped into 3G and started my compressed surfing. These are the results:

Screenshot of Google Chrome bandwidth savings screen.
Chrome requested 18.70Mb of data and compressed it to 4.83Mb, for a compression rate of 74%.
Screenshot of Google Chrome bandwidth savings screen.
Mini requested 12.9Mb of data and compressed it to 3.7Mb, for a compression rate of 72%.

This test was by no means rigorous or scientific. While Chrome compressed just a bit better overall, I felt like the experience was slower than on Mini. Chrome was also served much more data, perhaps owing to browser detection scripts offering more "features" to Chrome, or Mini's rendering engine just ignoring some of the elements it didn't know.

For those who have decided that Google is the great new evil, you may want to consider that Google proxies are between you and the web for every request when using Chrome's compression. For Mini users the same is true of Opera's servers, but far fewer people seem to be concerned about demonizing Opera Software. How much stock you put into Google's Safe Browsing technology behaving as some sort of censor is up to you and your own paranoia. I don't much care either way, but some folks might. As someone who's used Opera Mini for years when I travel outside the U.S., I'm very comfortable with it and doubt I'll switch — it's easier for me to just fire up Mini than it is to navigate Chrome's menus to enable compression.

By the way, the pages I used for my test:


Wednesday, January 15, 2014

Net Neutrality News

If you're spitting-mad about the W3C's perceived position on DRM, we would all be better served if you re-pointed that anger at what is happening to net neutrality.

If you aren't familiar with the net neutrality concept, here's a snippet from Wikipedia:

Net neutrality (also network neutrality or Internet neutrality) is the principle that Internet service providers and governments should treat all data on the Internet equally, not discriminating or charging differentially by user, content, site, platform, application, type of attached equipment, and modes of communication.

Think of it this way: If Time Warner wants to prioritize its own movie-on-demand services for home cable internet subscribers, it could make traffic slower for users of Netflix, or for video gamers, or for families looking up cancer information on WebMD. Think if Verizon signs a deal with Sony to prioritize for Sony devices or movies for its FiOS customers.

Yesterday the U.S. Court of Appeals for the District of Columbia effectively ruled that the Federal Communications Commission (FCC) doesn't have the authority to make internet service providers (ISPs) treat all internet traffic equally. You can read the full decision in this unfortunate PDF at the United States Court of Appeals, District of Columbia Circuit web site.

I think this is bad.

There are lots of bits of news popping up to cover this, most of them explaining why this is bad and linking to resources. I'll link some below, but as soon as I publish this post it will be out of date as more articles, blog posts, and general rants are bound to come. So you should keep your ear to the ground.

Remember, it's just a matter of time before that thing you like to do on the Internet is throttled down to painfully slow in favor of that other thing you don't like on the Internet.

  1. Court Strikes Down FCC Open Internet Order at Free Press.
  2. The Fight to Save Net Neutrality also at Free Press and links to some resources and history.
  3. Court strikes down FCC’s net neutrality rules, agency may appeal at Gigaom.
  4. What you need to know about the court decision that just struck down net neutrality also at Gigaom.
  5. Verizon Victory on Net-Neutrality Rules Seen as Loss for Netflix at Bloomberg Technology.
  6. Court Tosses Rules of Road for Internet at The Wall Street Journal.
  7. Feds Can't Enforce Net Neutrality: What This Means For You at NPR.
  8. FCC guide to The Open Internet.
  9. Does This Ruling Mean The End of the Internet? Maybe. at The Daily Beast.

Almost exactly two years ago, the Internet managed to coalesce around a goal of defeating SOPA (I wrote about it not just once, but again and again), and it worked. Now we're in the same boat and people need to speak up.

Update (1:42pm)

This graphic does a good job of capturing what might happen once net neutrality is swept away.

Image showing the base price of a fake company's DSL connection, with add-on pricing for access to groups of web sites, such as streaming sites, news sites, shopping sites, etc.
Found this on the Twitters in @CypherTheDane's tweet.

Update: January 29, 2014

I have my own opinion on the value of online petitions, but it still doesn't hurt to try. This one has gotten a lot of traffic from the go-to web pundits: Tell the FCC to protect the open internet.

Tuesday, January 14, 2014

W3C EME is not DRM (nor other fear-mongering TLAs)

Photo of hippie, text: Thinks EME and DRM are unethical. Uses Chrome. Plenty has been written about the W3C and DRM. Sadly, most of it has been written in the form of attacks against the W3C, with very few laying out the facts.

Note: I am a participant in the W3C HTML Working Group (as an invited expert). Encrypted Media Extensions (EME) are part of the scope of the HTML Working Group. You can decide if my opinion is tainted, but I owe nothing to the W3C to warrant arguing either way. I also don't speak for the W3C.

In Doctorow's latest post on Boing Boing, Requirements for DRM in HTML5 are a secret, he cherry-picks an email from the W3C's Restricted Media Community Group where someone wants to dive into DRM requirements but is rebuffed simply because the W3C isn't making DRM, just the APIs to access content protected by DRM (via the EME spec):

[…] what we are trying to do with EME is provide a clean API to integrate these solutions with the HTML Media Element.

And that's the crux of what the W3C is doing with DRM — developing a standard API so browsers can access content that will be locked down with or without their participation anyway.

The more W3C-savvy among you may recognize that W3C community groups don't publish specifications, they provide a way for the general public to weigh in on topics and generate wider discussion. As stated on the Restricted Media Community Group page, [T]his group will not publish specifications. In fact, if you are reading this and care about it, you should join. You may note that the people attacking the W3C haven't.

If you still aren't sure what the Encrypted Media Extensions (EME) spec has to do with DRM, then just read the abstract:

This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems.

This is why Tim Berners-Lee declared it as in scope for the W3C. DRM exists and has existed for a long time. DRM requires plug-ins or third-party applications right now. By creating an API that all DRM systems use, playback in the browser will be possible (via Content Decryption Modules), thus helping to support an open web (just use your browser) instead of continued silos (Hulu app, Netflix app, Silverlight plug-in, etc).

Tim Berners-Lee provided further context in response to community outcry. Those who are bashing the W3C for DRM should read it, or perhaps just these salient points:

[I]f content protection of some kind has to be used for videos, it is better for it to be discussed in the open at W3C, better for everyone to use an interoperable open standard as much as possible, and better for it to be framed in a browser which can be open source, and available on a general purpose computer rather than a special purpose box. Those are key arguments for the decision that this topic is in scope.

This clearly doesn't jive with the false headline Doctorow used in October, W3C green-lights adding DRM to the Web's standards, says it's OK for your browser to say "I can't let you do that, Dave".

It also doesn't suggest the kind of future that Doctorow outlines in his personal post, We are Huxleying ourselves into the full Orwell, where he says I’m not kidding about any of this. I can’t sleep anymore. I think it may be game over. Of all the things to lose sleep over, this really shouldn't rank. I'm not kidding.

Cory Doctorow is fear-mongering. At this point I believe he is mis-representing the facts to further his agenda of stopping all forms of DRM, as there is more than enough evidence to suggest the opposite of what he claims (though he never links it, so perhaps he's terrible at Google?). This may be because he genuinely doesn't understand what EME is intended to address, or it may be to drive ad revenue on Boing Boing by hitting a volatile topic, but I'd like to think it's the former.

People far smarter than I, and closer to the issues, have written about this. If you find my arguments lacking then you should read these before deciding the W3C is evil.

  1. DRM in HTML5 is a victory for the open Web, not a defeat, at Ars Technica, May 10, 2013.
  2. Dear EFF: please don't pick the wrong fight, by Chris Adams, October 4, 2013.
  3. The Bridge of Khazad-DRM, by Brendan Eich (Mozilla CTO), October 22, 2013.
  4. (Austening ourselves to the full Brontë) Please Bring Me More Of That Yummy DRM Discussion, by Robin Berjon, January 10, 2014.

If you want to comment, I do not moderate but I don't allow anonymous posts (strictly spam issues). If you want to post without linking to a social media account, contact me on Twitter and I'll temporarily remove the restriction.

My rant that got me started...

Update: January 15, 2014

Well, here's a nugget that suggests this conversation is unlikely to be calm:

Update: January 21, 2014

HTML5 Rocks published an article on the 16th titled EME WTF? An introduction to Encrypted Media Extensions. For those interested in seeing some code examples, take a look.

Update: February 14, 2014

Some of the members of the W3C TAG are hammering out a document about EME. They outline the goals here:

Over the web's 25 years there have been several technologies and architectures which have had the effect of restricting access for some people to portions of the web. This document explores how these work and the effect they had on the web, with the ultimate goal of aiming to inform the debate about the inclusion of Encrypted Media Extensions (EME) in HTML.

In it they cite authentication and the object element as current examples of restricted content on the web.

Tuesday, January 7, 2014

The HTML Star Is Ignored (and Shouldn't Be)

On Friday Jeff Croft posted a piece titled Web Standards Killed the HTML Star where he makes the argument that just knowing HTML and CSS is no longer enough to get a job. He states that the web standards movement has effectively rendered the need for specialized knowledge of browser quirks meaningless, something he feels an HTML/CSS author used to bring to the table. In short, he maintains that the HTML/CSS dev needs to develop new skills.

And So I Ramble Through a Response

It's a compelling argument. With the advent of frameworks and pre-built templates, most web developers don't necessarily feel the need to write HTML or CSS anymore. With WYSIWYG editors built into CMSes, word processors that output to HTML, and all manner of other output-for-web features in traditional software, non-web developers never even need to see HTML if they don't want to.

Jeff's post is addressing standards from the perspective of what skills get you hired. Sadly, it's hiring practices that continue to perpetuate the lack of standards and a need for truly talented HTML/CSS coders. There are plenty of reasons why we still need skilled HTML/CSS coders.

Hip Technologies

Too many developer job requirements do in fact treat HTML/CSS as a given. It is assumed you have those skills if you apply for a software developer or graphic designer job, so prospects list HTML and CSS alongside MS Word and Excel on resumes. Instead, job listings look for the hip language or tool du jour (ActionScript Node, Dreamweaver Twitter Bootstrap, etc.).

In the last decade, many cool technologies have come and gone. Few people are asking for Flash features on their sites, for example. HTML and CSS, however, are still there. They are the bedrock on which all these new tools are built. Staying abreast of everything going on in HTML is perhaps the best way to understand and evaluate the latest JavaScript library or CSS pre-processor. Except that skill-set has been commoditized.

Bad Advice

There are many tech outlets on the web, and they all want to get eyeballs to feed the ad banners paying their salaries. As such, some of the advice on how to properly code HTML and CSS is dubious at best. It doesn't help that some of the people reviewing these resources are also not HTML/CSS experts and so cannot identify when advice is outright wrong.

Let's not forget that the HTML specification is a fluid thing. HTML 5 is not final, HTML 5.1 is coming on its heels, and browser support is still a thing we have to consider. As such, you can't really casually know HTML or CSS


Remember the adage that everyone is surfing without JavaScript until the JS file is downloaded and processed. This is particularly important over slow or bad connections. It's what drives the "offline first" trend.

Perhaps you are smarter than generating nothing but a body and letting the JS fill in the HTML. If so, then knowing proper HTML is even more important, as that is what the browser will be displaying until your script is parsed.

Starting Assumptions and Pre-Built Platforms

A few weeks back I attended a local WordPress meet-up targeted at developers. As I shared my own development practices someone asked what framework I use for responsive design. I explained I use none. The reaction was bafflement. The idea of starting a responsive site with nothing but a blank Notepad window was completely foreign. The same discussion happened regarding my preferred CSS reset (none) or CSS pre-processor (also none).

Now we live in a time when many developers don't know the fundamental HTML and CSS behind their own pages. They are aware there are resets and frameworks, that they need to muddle through some markup or styles to customize it, that a module or add-on will unlock more features. They all have their choice of shiny hammer, so every problem is just a nail. They are limited by their tools.

These tools are often wrong. Their application of HTML and CSS is against best practices, a barrier to accessibility, or generally inconsistent. These tools were developed by people who also take HTML and CSS for granted, and it shows. When web developers use these tools and themselves don't know HTML or CSS, they simply carry bad habits forward, encoding it across the web.


Let's not forget accessibility in general. The short-sighted may roll their eyes, but only because they forget that they, too, will continue to age and will benefit from accessibility features.

It's my experience that just trying to get developers who "know HTML" to create a simple heading structure on a page is a painful process, but fold ARIA into the mix and you've blown someone's buffer. Even if we keep it simple, I challenge you to find someone who can adequately explain the difference between article and section, let alone what the accessibility implications are.

There tutorials and frameworks dedicated to styling a button to look like a link, or a link to look like a button. These make it into frameworks, software products, and even best practice guides. The specialists without HTML or CSS knowledge are making the web harder to use for those with disabilities.

My Advice

Jeff's advice is to diversify. That is quite good advice. Ideally the more you know about assorted technologies the more quickly you can pivot when they are replaced.

My advice is a bit different. Learn the fundamentals. Learn HTML and CSS and how to best apply it. If it interests you enough to specialize, then be prepared to make your case when looking for a job.

Be the person who validates what everyone else on your team is building so they can stick with their preferred language and you can make sure it renders clean, valid HTML. Be the person who reviews frameworks and tools and can best guide decisions and what needs to be done to fix these third-party codebases.

Another Take

Rewind to Jeffrey Zeldmans' article, To Hell With Bad Browsers, from February 2001. That article pretty much kicked off the web standards push, the core of the standards movement. A few days after that post, I wrote a quasi-response piece, To Hell With Bad Editors, where I took web developers and WYSIWYG editors to task.

As you can see from my rant above and my position thirteen (13!) years ago, I still don't think the web standards movement has achieved its goals. In that regard, I think Jeff Croft's piece already starts from a false assumption.

Others' Thoughts

Others have stated their opinions in the comments of the original piece, and yet others in their own posts: