Internet Standards Around the World and How They Affect Developers
Many countries set rules to govern how people use the internet. Here’s how they influence the way teams build digital products.
Last year, my team was tasked with building and testing a product that would allow users to customize their own maps by applying different visual styles to areas they chose on Google Maps.
One of QA’s responsibilities was to ensure we’d be able to pull in individual map layers for any area in the world so that the outcome would contain all of the features and details of a distinct area (roads, water features, country borders, etc). If the Google Maps API couldn’t provide location details, the product’s output would look less like a map and more like a solid color block.
Because it would be impossible to test literally every location in the world, we chose a set of latitude and longitude points at a variety zoom levels, giving us a representative sample of places from which we might ask the Maps API to pull. We also paid special attention to areas that might be problematic due to restricted map data, like military bases. Everything was going fine until we began testing maps of South Korea, where we found that we couldn’t style any area of the country past a certain zoom level.
Once developers confirmed there wasn’t a problem on our end, we learned that South Korea currently enforces laws that forbid the export of South Korean map data. The law prevents the Google Map API from releasing any information that isn’t available in basic Google Maps tiles, and it also makes it impossible to use Google Maps for driving directions in the country.
This discovery led to a larger curiosity about how different governments are creating and enforcing laws that govern web content and how it is served. Countries like Australia, Italy, and Germany have paid close attention to factors like accessibility and security, and though some laws have fallen short of actually penalizing violators, each rule that’s put in place affects the job of the team of developers tasked with building or maintaining web products. These are a few instances of how web standards set by governments affect both the users and developers of websites around the world.
Map Data in South Korea
National-security laws in South Korea designed to fend off attacks (especially from neighboring North Korea) specify where certain physical maps can be stored and how maps can be shared with other nations. As web-based map services emerged, South Korea decided that these longstanding laws also apply to digital data.
Today, South Korean digital map information can only be stored on servers within the country. By forbidding applications like Google Maps from storing map data internationally, South Korea has effectively limited the map functions available to consumers outside of South Korea.
This forces mapping applications to either serve all international requests from their servers within the country, or limit what services they provide to consumers hoping to use that map information. If a traveler is planning a trip to South Korea and searches for driving, cycling, or walking directions on Google Maps beforehand, they’ll instead see an error message that the directions could not be calculated. Google blocks most functionality from Maps requests that involve South Korean information. International users are able to zoom and scroll maps of South Korea, but that’s where functionality stops. Additionally, almost any request to the styled Google Maps API that includes South Korean information will be unsuccessful.
How This Affects Developers
The Google Maps API is one of the most used APIs on the web. Developers working on applications that involve the styled Google Maps API have to make a choice. They can either write code that specifically determines if a request involves a location in South Korea and surfaces an error message to the user. Or, they can allow users attempting to use the application with South Korean map information to be confused as to why the application is not working. Google is working toward convincing South Korea to change the law, but as of last November, their requests are still being denied.
Cookie Permissions in the UK
Cookies—files that websites leave on users’ computers to store a variety of information—have become nearly ubiquitous on the modern web. In 2011, in an effort to protect the online privacy of its citizens, the EU adopted a rule that allowed European citizens to bar websites from storing cookies on their computers. Following this directive, each country in the EU was responsible for its interpretation and implementation. The UK took things a step further by requiring all sites that store cookies on users’ computers display a warning. The sites must also explicitly give users an opportunity to opt out of having cookies stored.
It’s worth noting that certain cookie uses are exempt from the law. Those that are “strictly necessary to provide a service requested by the subscriber or user” are not required to display a warning. For instance, a retail site would not need permission to use cookies to store the items a user has placed in their online cart, since it’s necessary for the service requested by the user. However, websites have come to use cookies for a wide variety of applications, like preserving login information, serving relevant ad content, and monitoring user behavior. As a result, almost any site on the internet using cookies for a function that is technically exempt from the law is also going to use cookies for a variety of reasons that are not exempt, and will need to obtain user permission.
How This Affects Developers
The UK cookie law means that developers need to incorporate cookie usage notifications into any site. In addition, the notifications need to appear on any page of the site, and must be visible on any device used to view the page. The notifications must display (or link to a display) of all the ways cookies are used on a site. If a user opts out of having cookies stored on their computer, a website must either remember that preference using a storage method other than cookies, or store no information about the user and default to displaying the cookie notification on every page that user visits. Some sites have gone the route of “implied consent,” notifying the user that the site uses cookies, and that by further using the site they consent to having cookies stored on their computer. While this simplifies development, websites built as such entirely exclude users who do not consent to have cookies stored on their machines.
Since organizations are not required to obtain consent from users outside the UK, many sites will only display the notification message if a user is determined to be in-country. This approach creates more work for developers, as it necessitates they build and maintain the systems for determining user location.
Accessibility in Canada
“Accessibility” in the context of the internet refers to a person’s right to interact with web content, regardless of disability. These laws cover factors like ensuring color choices don’t limit the color blind, offering descriptive alternate text for the visually impaired, and ensuring website interactions can be performed with a keyboard for those who are unable to use a mouse.
The Web Accessibility Initiative, an effort of the World Wide Web Consortium, has published the Web Content Accessibility Guidelines (WCAG), a living set of standards (with multiple levels of compliance) to help web organizations improve the accessibility of their websites. To encourage a more accessible web, many governments, including Spain, Sweden, and Japan, have developed their own official accessibility web standards that exist as guidelines with no penalty for violation. In 2005, Canada became the first country to require organizations follow a set of accessibility guidelines, and provide specific punishment if they fail to do so.
The Accessibility for Ontarians with Disabilities Act (AODA) requires that all government and private websites based in Ontario belonging to an organization with more than 50 employees, and launched (or significantly updated) after January 1, 2014, comply with accessibility standards. All archived or existing content must be made accessible by 2021. The penalty for noncompliance varies based on the type of organization, the severity of the infraction, and the organization’s infraction history, but can be as severe as $100,000 per day.
How This Affects Developers
The government’s comprehensive set of accessibility standards covers everything from color contrast between text and background to keyboard navigation to alt text for images. Complying with the accessibility standards requires that developers know and understand them, as well as constantly ensuring the pages they are building meet them. Additionally, the requirement to update existing pages can require complete redesigns complicated by the need to work with code that nobody has touched in years.
One-Click Email Unsubscribe in the United States
In response to mounting problems with email marketing spam in the early 2000s, the U.S. government enacted the cleverly named CAN-SPAM (Controlling the Assault of Non-Solicited Pornography and Marketing) act. The act established rules for how marketing emails can be sent and the content they can contain. In the time since the act passed, some have argued that it’s been ineffective, as it legitimizes certain forms of spam and supersedes some state laws that were even more harsh on spam practices. However, the act did mandate one key change to how spam messages are built: All marketing emails must contain a visible and operable unsubscribe mechanism. This has generally been interpreted to mean those emails must contain a one-click unsubscribe link.
How This Affects Developers
Simply, developers have to write unsubscribe links into whatever marketing emails they build. This generally means generating a unique “signed” link for each email that includes parameters in the URL to pair the email with the address of its specific recipient. As part of the unsubscribe mechanism, developers must also build the landing page these links point to, with the necessary functionality that can pair the unique parameters in the incoming URL with the user who was originally sent the email. When an email recipient clicks the unsubscribe link in a message they’ve received, they are taken right to the unsubscribe landing page, which has already captured the unique parameters in that link URL, paired them with the recipient’s email address, and sent a change to the company’s database indicating to no longer send email to that address.
If you use an email service to send marketing emails and are panicking, don’t fret: Any U.S.-based newsletter provider (Mailchimp, Sparkpost, etc) has already built this functionality into their platform.
