Andrew Leahey
www.andrew.legal
architecture-1081912_1920.jpg

andrew.legal

India Tax Overhaul and Cryptocurrency

It seems as part of the tax overhaul, the Modi government is looking in to taxing bitcoin and other cryptocurrency. Some time ago the Indian government announced the creation of an interdisciplinary committee to prepare a report and recommend policies for cryptocurrency. 

The impact of the GST on cryptocurrency remains to be seen. The main question will be whether it is deemed a currency -- which would mean indirect taxes don't apply -- or essentially assets being used for bartering. 

The attraction of the latter option appears to be the relative simplicity. Rather than integrating and regulating bitcoin, it would merely be taxed under the new goods and services tax schema. Cryptocurrencies would be traded like gold, on registered exchanges monitored for illegal activity. The line that is being walked appears to be between blanket legalization with the preservation of the anonymity of distributed ledger cryptocurrencies and blanket illegalization, an unpopular option. 

The list of countries in which cryptocurrencies are illegal is not a long one: Bangladesh, Kyrgyzstan, Ecuador, Bolivia, and a few others. If India opted to illegalize cryptocurrencies, it would be the largest market to do so. 

The Benefits Of The New Indian Goods And Services Tax (GST) For Startups

As previously discussed, the Modi government of India is overhauling the country's tax code -- replacing taxes levied on businesses by the central government as well as the individual states with one unified GST.

The GST is a massive tax reform, indeed likely the largest since India gained independent in 1947. India is comprised of 29 states and 7 union territories. Previous to the GST, each state and union territory had an independent tax schema that any would-be national startup would have to contend with. So, placing yourself in the shoes of a national Indian startup, you would need to consider how to pay:

  • Union Government Sales Tax
  • State Government Sales Tax
  • Service Tax
  • Value Added Tax
  • Custom duty & Octroi
  • Excise Duty
  • Anti Dumping Duty
  • Professional Tax
  • Municipal Tax
  • Entertainment Tax
  • Stamp Duty, Transfer Tax
  • Education Cess Surcharge
  • Gift Tax
  • Wealth Tax
  • Toll Tax
  • Swachh Bharat Cess (Service tax)
  • Krishi Kalyan Cess (Service tax)
  • Infrastructure Cess
  • Entry Tax

Under the GST, there is one consolidated tax for state and national governments, akin to that found in France, which would subsume most of the above. The GST will be payable at the point of consumption (point of sale, essentially) and, as previously mentioned, falls along a schedule with brackets ranging from 5% to 28%. 

The GST will assist startups in that it will permit entrepreneurs transacting with multiple states to calculate one tax rate for the State-GST and the Central-GST. The transaction costs for a startup in expanding from a single state to multiple, at least at the tax level, are thus substantially reduced. Additionally, unifying the tax system will permit India to explore new technologies, such as blockchain

India Tax Overhaul

"Now, [the Modi government] is instituting the country’s biggest tax overhaul since independence. On Saturday, a nationwide sales tax replaces the current hodgepodge of business taxes that vary from state to state and are seen as an impediment to growth. It is expected to unify in a single market 1.3 billion people spread over 29 states and seven union territories in India’s $2 trillion economy."

NYTimes

The new tax system, the Goods & Services Tax (GST) is intended to simplify business taxes and spur growth, replacing taxes levied on businesses by the central government as well as the individual states. The GST will be divided in to Central Goods & Services Tax, State Goods & Services Tax and Integrated Goods & Services Tax. A constitutional amendment has already been passed by Parliament and approvals have been ascertained by India's 29 states. The current rate schedule includes 5, 12, 18 and 28% and a host of exceptions, subsuming dozens of brackets in to four. 

Ahead of the roll out, the Indian government developed a technology portal, the GST Network, which is intended to allow business owners to register their companies and pay their taxes online. While the system and the portal is not without its detractors, it does appear to have had at least some positive economic effect. Hyundai and Nissan have announced a decrease in automobile prices to pass on savings under the GST -- 5.9% and 3%, respectively. 

Update 2:43PM: There is a video session in which the Revenue Secretary, Ministry of Finance, Government of India answers questions regarding the GST roll out. 

Andrew LeaheyComment
Delaware Senate Advances Distributed Ledger Bill

The Delaware Senate has voted Senate Bill 69 out of Committee, moving a step closer to permitting the use of networks of electronic databases ("distributed ledgers") for the creation and maintenance of corporate records.

We have previously discussed the concept of distributed ledgers. The Senate bill would permit corporations to authorize, issue, transfer and redeem shares through distributed ledgers. This would ensure that, in the eyes of the state of Delaware, corporations issuing shares through blockchain are not breaching their fiduciary duty by doing so. 

Software as a Service - Crucial Contract Terms

As we have discussed previously, drafting software as a service ("SaaS") contracts brings with it numerous contractual complexities that in many ways mirror the complexity of the underlying technology. Providers give customers access to software and cloud services, allowing remote access and off-site data storage and shifting the risk of downtime and data corruption or loss to the provider. Of course, the amount of risk the provider wishes to assume in the arrangement is entirely up to the parties to the contract -- but both parties must take care to avoid assuming risk through ambiguous drafting and ensure what is in the contract truly reflects the bargain struck.

Just as lines of code cannot be cut and pasted reflexively from one project to another, so too is the case with contract language. Boilerplate should be used a heuristic - a quick way to see a list of provisions and clauses that you may want to consider negotiating for your current transaction. This post can be considered a boilerplate of the heuristic variety: some common SaaS provisions that you may want to consider. It is neither complete nor exhaustive and the entire list will likely be neither necessary nor sufficient for any individual transaction. They are provided merely as a list of provisions to get you thinking. 

Virtual Point of Demarcation

When goods are shipped internationally, parties to a sale agreement need to negotiate when title to the goods transfers from the seller to the purchaser. If Amazon sells you a box of crystal juggling pins and they are dropped on the warehouse floor, we have a pretty good understanding of who will bear the cost of replacement. Perhaps the answer remains clear if the pins are lost in transit. But what if Amazon sees them safely all the way to your doorstep where they are trampled and broken? Intuitively we have an understanding that the title and the risk of loss for those pins has now shifted to you - they were delivered safely to your door and were broken while in your possession. 

In the digital world, as is so often the case, the situation becomes murkier. Take for instance a voice over internet protocol ("VOIP") provider that sells a telephone service to a mid-sized business that has its own existing telephony infrastructure. If the VOIP service goes down on the provider's end, we understand that the outage is their responsibility. What if, however, an outage occurs and it becomes clear that it was owing to a misconfigured piece of equipment owned by the business? Without a virtual point of demarcation, the answer may need to be provided through litigation. 

Virtual points of demarcation make clear where a service provider's obligations end and the customer's begin. They are, conceptually, linked to the service level agreement -- they draw thick lines around the boundaries of the service level warranties. In essence, the service provider promises that X, Y and Z will not happen, but makes no additionally unenumerated assurances. 

Adjustments

Most businesses' needs are in flux. When a customer first signs a service agreement they can only do so based on their requirements (users, devices, licenses, etc.) at the time of signing. While it seems obvious, care should be taken to ensure that there is a transactionally cost effective way for a customer to expand or contract the number of users, devices or licenses that they are licensing. Placing undue transactional costs here, such as requiring them to renegotiate a new license, may cost the provider a customer when it comes time to expand - the cost effectiveness of staying with an existing provider is wiped out if new terms will need to be renegotiated as though they were a new customer. Make the path to expansion or contraction clear and as painless as possible. 

Ownership

A number of years ago, cloud photo hosting service Flickr, now owned by Yahoo, ran in to some issues regarding the ownership of user photos uploaded to their service. Their Terms of Service, ambiguously worded, gave some users pause and caused them to wonder if Flickr was attempting to retain copyright ownership of all photos hosted on their service. Flickr responded, clarified their Terms of Service, reassured their users, and the furor died down. However, it really is impossible to say how much the debacle effected their growth, customer satisfaction, and even valuation. 

Providers: don't be like Flickr, make it clear from the start. For many modern businesses, their most valuable asset is their data. While service uptime and data security and privacy provisions may go over the heads of everyone save for the nerds in the basement in IT, the concept of who "owns" the data that is stored with your service will be crystal clear to techies and Luddites alike. Make clear who owns the data, who can use the data, if the data can be used or sold in the aggregate by the provider. If you were leasing warehouse space and the leasing agreement left who would own the items kept in the warehouse ambiguous, wouldn't you want to make sure it was cleared up before pen met paper? 

Indemnification and Insurance

Consideration should always be given on either side of a SaaS contract as to whether one or both parties should be compelled to carry insurance. Most obviously, a provider should carry insurance to cover data and privacy breaches, data loss, and service downtime. Less obviously, however, is the insurance carriage requirements of the customer. If the customer will be indemnifying the provider for any liability, the provider will want to ensure the customer carries sufficient insurance to cover the cost of liability. 

Downtime Allotments for Updates and Maintenance

99.9%, 99.999%, the minimum acceptable level of uptime is getting more 9s after the period every year. Owing to virtual servers and data redundancy, the need for downtime for updates or maintenance is becoming less and less common. However, there remain some technologies that still may require data or services to be unavailable for a period of time - and there is always the dreaded DNS issue. If required downtime may be a factor that needs to be considered by a provider in a SaaS agreement, care should be taken to also consider whether that downtime needs to be provided for separate and apart from the service level provision. In other words, a provider may want to guarantee 99.999% uptime as pertains to nonscheduled maintenance outages, but provide for a certain amount of downtime for upgrades an maintenance. 

Closing Thoughts

A solid understanding of the underlying technology, if not a technical mastery, is really a prerequisite for properly negotiating a SaaS agreement. As is the case with any contract, the drafter needs to be able to imagine all the potential scenarios that might present in the course of performance and account for them. If you were drafting a service agreement for the provision of transportation services for nuclear waste, you would engage experts to help ensure you were considering all of the potential risks - you wouldn't rely on your own reckoning just because you have seen Atomic Train. The same should be true for SaaS contracts: engage technical personnel and be realistic about your own understanding of the technology. Posting a meme on Facebook may not be sufficient technical savvy to negotiate the terms alone!

Delaware - Distributed Ledger or Blockchain Transactions in the Delaware General Corporation Law (DGCL)

If you haven't already heard of the Delaware Blockchain Initiative, you soon will. A proposed amendment to the Delaware General Corporation Law (DGCL) could revolutionize the way corporate finance is handled in Delaware and, as Delaware is the state of incorporation for more than three-quarters of the Fortune 500, the country at large.

What is a Blockchain?

A blockchain, in its use in finance, is essentially a decentralized and distributed ledger. In systems where physical pieces of currency aren't being handed back and forth like gold doubloons, the most pressing problem is keeping track of transactions. As digital currency is, at base, an electronic file that can be replicated without limit, the issue of double-spending becomes a concern. Double-spending occurs when one unit of currency is both spent and retained by the spender. With physical currency, this is not a significant problem – if there are 100 pennies in a system and, at the end of the day after all trading has completed, everyone counts their pennies, there will only be 100 pennies distributed amongst the traders. Individual traders may feel that they should have more pennies than they do, and indeed some thievery may have occurred between them, but the system itself will not be fooled. Thus digital currency must first tackle the problem of ensuring an accurate accounting of not only individual participant holdings, but the amount of currency in the system as a whole.

A blockchain can be most accurately described as a distributed or decentralized ledger. Digital currency that utilize blockchain systems take advantage of the same technologies as peer-to-peer file sharing systems. A peer-to-peer file sharing system has no centralized server that houses all of the data that is being shared. Instead, the data on the individual users' systems is shared with all of the other users of the system. For file sharing, this makes it difficult for law enforcement to crack down on copyright infringement. For digital currency, this ensures that there is no one source of data that, first, needs to be maintained by some oversight entity and, second, can be compromised.

When a transaction occurs, a transmission is made from the sending and receiving parties' currency system of choice, to the rest of the nodes, or users, on the system. It essentially transmits a message stating "Party A has paid Party B X amount." Individual nodes then confirm that this data is accurate – at base, that Party A has the funds to transfer to Party B and confirms the new amounts held by each party. Once confirmed, groups of these transactions are bundled together in to "blockchains" and distributed to the nodes of the system. In essence, imagine a blockchain as a notebook in which transactions are continually scrawled. When a notebook is filled, millions of copies of it are instantly made and distributed to all of the users of the currency. This ensures that, if someone tampers with a transaction in their notebook, the tampering comes out the next time the notebook is compared with all of the copied notebooks – the next time there is a transaction.

In addition to this distribution system, the innovation inherent in many digital currencies that use a blockchain system is that the units of currency exist only in the blockchains. In other words, whereas in a traditional ledger you would be writing down Party X gave $10 to Party Y and, after that writing, there would exist both the ledger and the $10 in Party Y's pocket, in most digital currency systems there is no currency that exists separate from the blockchain. Rather than opening your wallet to retrieve $10 to hand over to a seller for an item, with these digital currency systems you merely indicate to the distributed and decentralized ledger, the blockchain, that the 10 units that were attributed to you are now attributed to the seller.

How Can Blockchain Technology Impact Business?

In addition to the obvious potential for a shift in the way currency is handled, two exciting potential avenues for blockchain technology are distributed ledger shares and smart contracts.

Distributed ledger shares operate in much the same way that blockchain currency does. All participants in a particular market for shares share a single, decentralized database. Trades can be executed instantly and at any time, as there is no third party oversight. The added security and operational efficiency can substantially reduce transaction costs and, as a result, change the entire face of investment.

Smart contracts are contracts that can autonomously update, delete or otherwise be interfaced with when a specific condition is met, like an expiration or payout date. In essence, they are digital transaction protocols that can automatically execute the terms of a contract. The thought is that common contractual obligations can be handled automatically, without the need for human intervention, and thus substantially lower transaction costs. If an ordinary contract defines the rules of the road and outlines the penalties of violating them, a smart contract does the same but also automatically enforces the rules and reduces the likelihood of needing to pay penalties. Enforcement is decentralized through a blockchain in the same way that digital currency is: it is February 31, millions of people agree that it is February 31, and millions of people agree that our contract states you will pay me $50 on February 31; so on February 31, $50 is taken from your account and transferred to mine.

What is the Delaware Blockchain Initiative?

The Delaware Blockchain Initiative (DBI) is an attempt by the state to become more friendly to blockchain businesses and adapt its regulatory state to emerging technology. Then-Governor Markell launched the DBI in May of 2016, aiming to create a regulatory and legal environment for the development of blockchain technology and embrace its ability to reduce transaction costs. The Governor highlighted four facets of the state intiative.

First, to ensure that Delaware's regulatory environment is welcoming and enabling by observing the industry as it develops. The key here will be to walk the line between codifying an evolving and nascent industry at a point in time where it hasn't fully developed and failing to support an emerging technology. Best practices will need to be determined with the fully input of the community, industry, and consumer groups.

Second, to ensure that an appropriate legal infrastructure is in place for the oversight of a distributed ledger share system. Too much interference and innovation is stifled, too little interference and investors and companies are hesitant to get involved as they feel unprotected.

Third, an Ombudsperson, Andrea Tinianow, was named as the State Director of Corporate and International Development. A member of the Global Delaware Concierge Team, Ms. Tinianow is tasked with working with investors, entrepreneurs and executives to help ensure the DBI is a success.

Fourth, the Governor committed the state government to using blockchain technology, and announced that the Public Archives project would be the first entity on board. The Delaware Public Archives will use blockchain technology to archive and encrypt government archives. This will help not only ensure their security, but double as a backup and disaster recovery system.

Conclusions

Blockchain technology is promising, there is no doubt. All indications appear to be that it is gaining increased acceptance and adoption, and the important of Delaware throwing its weight behind the technology cannot be overstated. However, blockchain technology and the digital currency systems that use it are not without their detractors and black eyes. Bitcoin, the most famous digital currency, is viewed by many as the currency of the black market. Technology advances quickly, and it remains to be seen if blockchain technology can overcome its stigmas and gain widespread adoption before the next revolution in payment and ledger systems is developed. In either case, however, it appears Delaware is situating itself to be ready to cash in. 

resipsa.social - Microblogging (Read: Twitter) for Legal Professionals

As is the case in many non-technology professions, legal professionals often struggle to remain engaged in social networks. You are either shouting into the void on Twitter, sharing a Law360 article with your Great Aunt on Facebook, or tossing a post in to the fan that is LinkedIn, to be "liked" by your colleagues while they are looking for a new job. 

Well there is now another somewhat more palatable option -- Mastodon. There have been a number of articles floating around the ether in the last few weeks that do a much better job explaining what Mastodon is and how to get started on it. Suffice to say that it is, for the end user, essentially a service comparable to Twitter, with a few tweaks.

First, it is decentralized, which means you don't just sign up at mastodon.com and start sharing Ice-T memes. You need to choose an "instance" -- essentially, a community. Generic instances were the first to gain real traction, mastodon.social and mastodon.network are both instances geared towards general interest use. Second, and perhaps most importantly, it has much more granular control over who sees what you post where; each individual "toot" (not a Tweet) can have its own privacy settings. Third, Mastodon, at least in its pure form, is free from ads, trackers, and (so far) brands. It is open source software, which means the code is freely available for use, modification and redistribution, and anyone can launch an instance.

So I have.

Mostly for me, but it is my hope that in time it may interest other legal professionals that are looking for a place to speak with others of their own kind and share news and information that may not be as well suited for a general audience -- or Great Aunts. 

Should this interest you, head on over to resipsa.social and sign up for an account. You can find me @Andrew.

 

Anatomy of a Software as a Service Contract - Hosted Services Provision

In the old days of software, deployment for a software company to a client entailed mailing a stack of floppy disks with a end user license agreement ("EULA") seal; the client broke the seal and the license agreement was agreed to. Maybe there was a prompt during the installation process for good measure. Internet connectivity was anything but ubiquitous and the idea of shipping software that heavily leaned on an internet connection, much less relied on connectivity, was anathema. The physical product being shipped was the software, true, but digital rights management ("DRM") was in its infancy, and making copies of the software was trivial. What was really being granted to the end user was a license to use that particular piece of intellectual property. 

Most work at the intersection of software and law revolved around the issuance of licenses and the formation of license agreements. Now, as internet connectivity has become all but a prerequisite for business (and, perhaps even more so, personal) life, there has been a rise in the use of software as a service at the enterprise level. Software as a service is an umbrella term for the concept of remotely hosted software, maintained and hosted by the software provider, licensed to users on a subscription basis.

Software as a service ("SaaS") brings unique challenges to the legal sphere. Chiefly, there is a shift from mostly license-driven agreements to what are in essence technology service agreements. (There are tax implications, as well -- but a topic for another day). Notwithstanding this shift of primacy, there are still elements in a SaaS agreement that call for relatively standard software license agreement language -- the license to use the hosted services, the permission to or restriction on sub-licensing, etc. In a series of posts, I am going to explore some of the main provisions and standard language in a SaaS contract, and outline some of the things to look out for and issues to consider. 

Hosted Services

The hosted services provision of a SaaS contract is, at its core, a grant of the right of the user to access the hosted software, a license to use the hosted software and all of the limitations therein, a service level agreement or promise of security and availability on the part of the software provider, and an agreement to an acceptable use policy on the part of the user. 

Grant of Access

"Software Co. shall create an Account for the End User and shall furnish the End User with the login username and password for that account on the Effective Date."

A license to use the hosted software platform without the actual technical instructions and ability to access the same would not be of much use to the end user -- leaving this provision out would be like shipping the EULA without an disks. In drafting, consideration must be given to the software platform: does the platform require someone to manually register a username and password for the new account? Is it done automatically as a process of the end user's agreeing to the contract? Being specific about the method by which the Account will be created lends more clarity to the contract and ensures all parties are aware of what to expect and what is expected of them.

Grant of License

"Software Co. grants to the End User a personal, limited, nontransferable, non-exclusive license to use the Services, through the use of their own Internet Access, for the Purposes outlined herein, for the duration of the Term. Software Co. retains all others rights to the Services, including those provided by copyright, trade secret and other intellectual property laws. You are only granted the right to use the Services for the Purposes for the duration of the Term."

A grant of a license to the hosted services is the flip side to the grant of access -- the grant of access provides the end user with the physical ability to access the software, and the grant of license outlines their permission to do so. 

An argument can be made that certain SaaS suites do not require a grant of a license to the software. A license grant to software is really only necessary when there is a copying or duplicating of the software. Thus, if a SaaS suite has some offline components (in other words it installs anything on the end user machine) it might still be wise to include a license grant. If, however, the software is entirely cloud-based, with no installation or "copying" for copyright purposes on the end user machine, then the omission of a license provision may be warranted. In such cases, it might be said that the software, housed and running on "Software Co." machines, is merely providing a service to the end user. In which case, just as an inventor of a special kind of wood splitter wouldn't need to grant a license to the customers he uses the chipper to split wood for, the SaaS company wouldn't need to grant a license to the software to the end user. Instead, the frame that the license should be viewed from is that it is a license to the service that the software provides

Scope of the Grant of License

"The license granted by Software Co. to End User in this section is subject to the following limitations: ..."

If a license is to be granted for the software, care will need to be taken to outline the scope of the license. Some things that need to be considered include: 1) is the license granted just to an individual user, or the employees of the user? 2) how many concurrent connections to the SaaS are permissible? are there technical reasons why one may want to limit the total number of users online at a given time? 3) will there be a schedule of permitted users, as in cases where there may be confidentiality concerns? 

Service Level Agreement

Service level agreements ("SLAs") outline the minimum service standards that are being guaranteed to the end user. Generally speaking, these include uptime guarantees (99.9%?), latency guarantees, and remedies available to end users should these standards not be met, or what sorts of force majeure events excuse all parties from performance. In addition, they may contain information regarding security and privacy, and time frames for service requests. 

Specific uptimes can be difficult to guarantee, and present their own challenges in drafting. For instance, will a third party service be used to monitor uptimes and report outages? What will constitute a loss of uptime? Complete software outage? Substantial? If 100% uptime and software availability is not something that can be guaranteed, it should be disclaimed. 

Latency is an even thornier subject, as the latency between any two servers on the internet can vary greatly based on regional issues and outages, network congestion, and other factors. Thus, having latency monitored by a third party may not be acceptable for an end user that isn't concerned with whether or not some neutral third party can reach the service. 

Perhaps most importantly, an SLA will typically contain a provision outlining the mean time to repair and the mean time to respond. In other words, how quickly Software Co. will respond to an issue, and how quickly they can guarantee and issue causing an outage will be remedied. Often time to repair and time to respond will be further sliced and distinguished according to issue severity -- so, for instance, a mean time to respond and repair to a complete outage might be substantially less than the time to respond to minor bugs and defects. Further still, enterprise SaaS SLAs will often contain another set of response times for certain specific users. The VP of Operations having an issue reading her email, then, may take precedence over the Associate Counsel whose calendar won't sync.

Finally, Saas SLAs will generally contain an outline of how service issues will be escalated. In other words, the name, number, and email address of someone on Software Co.'s side that will answer the phone when an issue presents itself that warrants more action than an ordinary support ticket system can muster.  

End User Policies

Finally, a Hosted Services provision will frequently contain an outline of what is and is not acceptable use for the end user. This often includes using reasonable methods and taking reasonable precautions to protect account details, not permit unauthorized access, and the like. This is a provision that will vary widely in length, complexity, and importance, based on the sort of software service being contemplated. The level of restriction can run the gamut from end users agreeing to only use the SaaS for the specific uses outlined in the agreement, to a simple "reasonable methods" boilerplate clause that holds the end user responsible for things done on the software using their access credentials.

Conclusion

In sum, the Hosted Services provision is among the most recognizable provisions in a SaaS agreement -- a holdover from days of yore. In future posts, I will go over provisions outlining support service, maintenance and updating, the licensing of the data put in to the SaaS by the end user to Software Co., and other considerations for data privacy and security. 

Note this post is for informational purposes only and nothing contained within should be construed or relied upon as legal advice. 

Telephone Consumer Protection Act (TCPA) -- New Decisions, Changes on the Horizon

The Telephone Consumer Protection Act 47 U.S.C. 227 (TCPA) has, for some time, been steadily increasing in inscrutability. In 2017 it appears set to continue this trend with new case law, even as FCC chairman and expansive-TCPA-interpreter Tom Wheeler cedes the agency's reins on January 20th, leaving the future of the act in new hands.

On the case law front, wasting no time in the new year, the Northern District of Ohio rendered a decision on January 3rd that, in effect, ensures manufacturers of products are not held liable for unsolicited (in this case, faxes) sent by third party entities, merely because the advertisement, if heeded by a consumer, would benefit the manufacturer's bottom line. To hold otherwise, the court was concerned, would give rise to "sabotage liability."

"By way of illustration, it would allow a rabid Tampa Bay Buccaneers fan – with a rhino helmet, red face paint, and an undying devotion to the organization – to trigger per se liability for the organization under the TCPA by gratuitously, and without directive from or notice to the organization, promoting season ticket sales via fax.  The same could be true of a random individual in Boston, mind brewing with scienter, who works to implicate the New York Yankees by advertising their season tickets.  Universal liability for complete inaction was not contemplated by Congress in passing the TCPA and does not appear to have been contemplated by the FCC in crafting and interpreting its regulations."

Thus, the pendulum that is the TCPA swings back, the definition of "sender" contracts -- if only in Ohio, if only for now. 

Andrew Leaheytcpa, ohio
Privacy Policies for the Modern Web

Traditionally privacy policies have answered three general questions: (1) what user data is collected, (2) how that data is collected and (3) how that data is stored or used; generally, how that data is treated.  A privacy policy is a simple enough thing to draft when the entity directing the drafting is the sole party acting to collect and store data. In the case of the modern web, however, that is never the case. For the most part even the most basic of websites will utilize some content delivery network (CDN) to serve images and other larger files and embed code to track usage data. CDNs and analytics companies will, then, have access to non-personally identifiable information: internet protocol (IP) addresses, browser, operating system information, and display information, and in the latter case, referrer universal resource locators (URLs). More and more ecommerce sites are taking advantage of third party payment processors, rather than taking payments on-site and taking on the burden of security maintenance and all of the accompanying risk. In short, as more and more services are outsourced, the number of entities gaining access to some form of user information is directly correlated to the complexity of the website. Indeed, with the advent of third-party authentication services such as Facebook Authentication, Google OAuth and LinkedIn OAuth, user data is only becoming more removed from the control of the entity owning and operating even a relatively simple website.[1] This raises questions as to how one can best disclose the answers to the above three questions. 

What User Data is Collected

There are known-knowns, known-unknowns, and unknown-unknowns[2]. The data that is collected by the website owner is a known-known – you either do or do not offer a "Contact Us" form that collects and stores a user's name, email address and their comment. Without further investigation, the information obtained from a user choosing to use Facebook Authentication is a known-unknown – you are aware that user registration and login information is collected by a third party, but you don't know how that information is being stored. Unknown-unknown information is all of that information[3], potentially collected by a third party, that it is difficult or impossible to ascertain the storage and use of. For example, an analytics company that offers free user analytics services may be using the aggregated information in order to improve their other offerings. Their own privacy policies may only obliquely reference what aggregated information is used for and, as such, a privacy policy cannot in good conscience be drafted in a way that makes representations or warranties as to what information is collected by that third party.

How Data is Collected

Methods of collecting data is another area by which the complexity of a website significantly impacts the scope of the privacy concerns. The obvious first level collection schemes are all of those user-driven and user-chosen methods: contact forms, user registration, payment processing, email listserv subscriptions, etc. Second level collection schemes are those that can be ascertained by examining the website and its source – analytics and tracking scripts, calls to offsite-hosted images, cookies, etc. Third level collection schemes, which are the most difficult to know and thus disclose in a policy, are all those methods that are not either user driven or evident in the source of a website. For instance, an examination of the source of a website may indicate that a call is being made to a third party for a tracking script, but the source cannot and will not give guidance as to whether that third party is using data analytics on their own server logs to form a more complete picture of a user, or tracking the user across multiple websites.[4] How information is collected is more difficult to disclose, then, as the owner of the website can realistically only indicate how they think information is collected, what information is collected that they are privy to, and the identities of some of the entities that they have chosen to collect information.   

How Data is Stored or Used  

So-called "Right to be Forgotten" European Union laws aside, if there is one immutable fact about the internet, it is that anything that is on it, remains on it. In the early days of the web, a privacy policy could give users an accurate picture of how long information that is collected about them will remain – a quick call down to IT would be all that was required. In the modern web, a visit to a website is more akin to tossing a stone in to a pond. A rudimentary privacy policy can describe the splash, a well-drafted policy can predict some of the ripples, but no policy will be able to describe the effect on the shoreline. To abandon the metaphor, a privacy policy can be drafted to outline how long the website owner intends to hold on to user information and how long third-party services tied to the website claim to retain user information, but it can never tell a user with an accuracy how long it will be before their visit or use of the site is "forgotten." 

Solutions

1. To the extent that you can, disclose.

The above may serve to discourage an individual from bothering to draft a policy at all, but this is not the intent. Information privacy was hardly in the public discourse twenty years ago. The first discussions of privacy mostly centered around personal healthy information, later turning to contact information, with the advent of do not call registries, and financial information, as identity theft has become more common. Moving forward, the trend line would appear to point squarely in the direction of privacy becoming more important and more relevant -- the European Union and the State of California have already adopted laws mandating as much.

As such, not surprisingly, the solution to privacy policies lagging behind the increasing complexity of the web is … increased disclosure. To the extent that you know what information is collected, stored and used, disclose it. To the extent that you know what information MIGHT be collected, store and used, disclose it. Where you aren't certain of anything, disclose the entities that you have contracted with to provide services that might be collecting information and link to their privacy policies. Don't work with entities that do not provide privacy policies that at least give some modicum of explanation as to how information is collected, stored and used. 

2. Offer an up to date list.

In your privacy policy, elect a Data Controller and allow users to reach out to them to obtain an updated list of all the companies (third party service providers, mail carriers, hosting services, IT companies, communications companies, analytics companies, advertisers, etc.) that may be processing user data. Maintain the list and, where possible, post it and link to it in your privacy policy.

3. Update your policy frequently.

The privacy policy of a website cannot be thought of as a set-it and forget-it static page -- just as the rest of your website is evolving, so too must your policy. At regular intervals have your policy reviewed and updated to reflect features added or removed from your site, third parties contracted with or released, and changes to third party's policies.

4. Demand more.

Think of yourself as a steward of your user's information. When you choose a new product, contract with a new party, or implement a new feature, call on the entity you are working with to provide you with answers to the aforementioned three questions: what information is collected, how that information is collected, and how that information is used. It is more than just a nice thing to do for your users, it helps ensure that, as privacy becomes more and more of a hot button issue, you remain ahead of the curve and needn't fear having to fix a problem that could have been prevented through good management.

 

[1] Indeed, to want to make use of a third-party authentication service the website owner need only wish to save user preferences with slightly more granularity and permanence than a traditional "cookie" can provide. The availability of free authentication services through Facebook, Google and LinkedIn, among others, creates a situation where the entities that are seeking the most cost effective and simple method to permit users to have an account on their website are the ones that need to draft the more sophisticated privacy policy.

[2] https://en.wikipedia.org/wiki/There_are_known_knowns

[3] Generally speaking this will be non-personally identifiable information – IP addresses, regional location data and the like.

[4] The concern being, at some point, a certain order of magnitude of non-personally identifiable information is personally identifiable information – enough individual data points and the number of individuals that fit all of those points eventually drops to one.