LinkedIn Appeals Important CFAA Ruling Regarding Scraping Public Info Just As Concerns Raised About Clearview

from the this-could-get-interesting dept

Last fall we were happy to see the 9th Circuit rule against LinkedIn in its CFAA case against HiQ. If you don't recall, the CFAA is the "anti-hacking" law that has been widely abused over the years to try to shut down perfectly reasonable activity. At issue is whether "scraping" information violates a terms of service, and thus, the CFAA. A few years back, the same court ruled in favor of Facebook against Power Ventures, saying that even though Power's users gave permission to Power and handed over their login credentials, Power was violating the CFAA in scraping Facebook, because the information was behind a registration wall -- and because Facebook had sent a cease-and-desist.

In the HiQ case, despite what seemed to be a similar fact pattern, the court ruled against LinkedIn, saying it could not block HiQ's scraping via a CFAA claim, with the main "difference" being that LinkedIn information was publicly viewable, and therefore should be open to scraping. I still don't quite see the difference between the cases -- because in the Facebook situation, once you have a login, the information is effectively available in the same manner, but that is how the courts ruled. After first asking (and not getting) an en banc review (and then asking for more time), LinkedIn has now asked the Supreme Court to weigh in on this issue (hat tip to Media Post). I worry that the court might make things much worse if it does take the case, and block all kinds of scraping.

Of course, one thing that's notable since the 9th Circuit ruling came down -- all of the attention that Clearview AI has received over the last few months, for its frightening facial recognition app, built of of scraping "public" social media images and profiles. This use of scraping has convinced some -- even some who seemed to support the HiQ ruling -- that perhaps there should be limits on scraping. I think that's a kneejerk reaction, and focusing in too narrowly on the wrong issue. The issue there is not with scraping, but with the specific use of the data as an attack on privacy going well beyond the internet itself (i.e., tracking and identifying people out in the real world). It's one thing to focus on that issue, as opposed to saying that's an argument against free scraping.

At a time when we're so worried about competition, the ability to scrape is incredibly important. It's how competitors can be built in a world with network effects. If other companies can build compatible services, without having to do a deal with Facebook or Linkedin or YouTube or Twitter, that enables more competition much more easily. And yet, too many efforts are being made to cut off that kind of interoperability. The LinkedIn case is just one example. If the Supreme Court does take it up, let's hope they recognize just how important this kind of adversarial interoperability can be, rather than buying into some nonsense about how scraping must be blocked and not allowed.

As for the petition itself, the question LinkedIn is asking the Court to review is whether or not bots can scrape websites, even after receiving a cease-and-desist letter:

Whether a company that deploys anonymous computer “bots” to circumvent technical barriers and harvest millions of individuals’ personal data from computer servers that host public-facing websites—even after the computer servers’ owner has expressly denied permission to access the data—“intentionally accesses a computer without authorization” in violation of the Computer Fraud and Abuse Act.

While I can understand the Clearview-like horror stories some may put forth about this activity, to allow companies to block all scraping like this would create huge problems for both a functioning internet (hello search...) as well as competition.

Filed Under: cfaa, interoperability, scotus, scraping, supreme court
Companies: hiq, linkedin

Defeating Tech Giants With Open Protocols, Interoperability, And Shared Stewardship

from the alternative-approaches dept

Across the ideological spectrum, there seems to be a consensus that something must be done about the biggest tech companies — that the legal mechanisms we currently have to address monopolization in the United States are inadequate to deal with the realities of the digital market. While recognizing how powerless our institutions have become in the face of Big Tech's massive lobbying power, there's an idea that's gaining traction as a viable approach to curb the societal and economic impacts of tech monopolies. The idea is to restore the core of a healthy internet ecosystem: interoperability and the revival of open protocols.

Lawmakers, policy experts, and even Twitter, are advocating for tech companies to open up their platforms to enable other services and start-ups to enter the playing field. There are different approaches to doing so and varying layers of interoperability that are possible. The overarching goal, however, would be to get rid of the worst aspects of tech monopolization and bring about a new era of competition and innovation.

As a writer and nonprofit tech entrepreneur who has focused on projects promoting digital justice and community networks, I became interested in these ideas. Why do we need to extend interoperability into the application layer? How do we create new Internet standards that open up our networks and platforms in ways that invite new features and applications that better respect our individual and collective rights online? As I examined the three most likely scenarios being discussed, I realized that we had much to learn from the past. We need to revive the power of standards bodies, and ensure that they stay relevant and effective by observing known principles about how to successfully govern a commons.

A Brief Overview of Interoperability and Competition

What made the early Internet so exciting was how quickly it changed. Different services like bulletin board systems (BBS), email, and Internet relay chat (IRC) came about and allowed people to communicate in ways that were impossible before. That rich ecosystem of tools and services were enabled by downstream innovation. New applications and features could be built with existing technologies with or without permission from the prevailing tech companies. Yes, there were plenty of lawsuits against these start-ups back then. But people were still willing to take the risk, and there were investors that wanted to back them up. There were less onerous laws hindering experimental technologies.

Perhaps most importantly, much of the Internet ran on open protocols and standards. The academics and others who initially designed the protocols wanted to build a relatively free ecosystem, so they made it possible for services to interoperate with each other. Standards bodies like the World Wide Web Consortium (W3C) established shared protocols in the name of the collective interest. These institutions have helped companies and organizations come together and set rules based on agreed upon needs, making them transparent and representative of the interests of more than one stakeholder. At standards bodies, companies sit alongside non-profit organizations, educational institutions, policy experts, and academics.

But standards bodies have grown increasingly inefficient and exploitable. Not only were they always slow and under-resourced, tech companies grew powerful enough to bend them to their will or ignore them altogether by building walled gardens with no interoperability built into their platform (besides providing some public APIs with varying levels of consistency). In the era of Move Fast and Break Things, there was little patience for the kind of multi-stakeholder dialogue and decision-making that is required to build and conform to shared technical standards.

There has been little incentive for tech companies to play well with others. Not only that, it's become the norm for tech monopolies to destroy any competition. Laws that regulate the internet such as the Digital Millennium Copyright Act (DMCA) and the Computer Fraud and Abuse Act (CFAA) have had a chilling effect on the types of innovation that was characteristic of the early internet. These regulations can be weaponized by big players to crush new start-ups over even the most trivial violations. If they don’t sue them, tech companies can easily buy them out or throw all their resources into imitating the services of their smaller competitors until they crush them.

Now most people communicate, get news, and publish their work through closed platforms run as web services. When people think of the Internet, they think about the platforms, not the protocols that run beneath them and make them work. To many, email is Gmail, chat is Slack, and discussion forums are Facebook.

Of course the underlying protocols are still core to the Internet’s functionality. But these closed platforms severely lack the traits of interoperability. As we’ve become dependent on them, our digital lives have been left at the mercy of companies whose primary goal is to enclose as much of the Internet’s infrastructure as they can get away with. Especially when it comes to social networks, their ability to mediate every aspect of our relationships and interactions online has come at an immense cost to our right to free expression, privacy, and access to knowledge.

Possible Paths Towards an Interoperable Internet

There are those who are calling for a revival of antitrust enforcement to break up the tech monopolies. But federal agencies in the U.S. such as the Federal Trade Commission (FTC) move too slowly and are under-resourced. And then there are others who say that breaking up the tech companies is entirely the wrong approach — that we need to build protocols to again make the Internet more interoperable as it was in the early days.

The European Commission, the Electronic Frontier Foundation, the University of Chicago Booth School of Business, Mozilla, Twitter CEO Jack Dorsey, and others are calling for a revival of interoperability as means to address Big Tech's dominance over the Internet. Among them they present three possible ways this could come about, with or without state intervention.

1) State Antitrust Enforcement

Through litigation or legislative action, the state could require companies to make their platforms more open and interoperable. Mozilla's Chris Riley asserts that the agency best suited to take this on would be the FTC, which has the explicit mandate to protect consumer protection and enforce U.S. antitrust laws. Harold Feld of Public Knowledge calls for an entirely new agency empowered to oversee any implementation of any proposed law enforcing digital platform competition, given the specific technical complexities of enforcing such a law.

There is precedence for this in Europe. The European Commission brought a case against Microsoft in the early 2000's that resulted in the company being required to release information enabling competing software to interoperate with Windows desktops. The U.S. and Europe have their own approaches to antitrust, of course. Interoperability enforcement would look very different depending on which state(s) had the mandate to move forward with this type of action.

2) Established Platform Companies Seek Standardization

One of the big players could willingly embark on a path to build open protocols. In December, Twitter CEO Jack Dorsey announced Blue Sky, an initiative to help develop an open and decentralized standard for social media. In his Twitter thread about the project, Dorsey says that Twitter would fund further development of an existing decentralized standard or as he says, "create one from scratch".

Many responded to him asking about ActivityPub — the protocol behind Mastodon, the federated alternative to Twitter. Why wouldn't Twitter invest its resources into that? Dorsey responded that it might be possible, but that it's up to the Blue Sky team to decide whether that protocol would be best. It's worth pointing out that ActivityPub has already gone through discussions at the W3C and is officially a recommended standard.

It makes sense that a major platform would want to decentralize their platform, the most obvious reason being to relieve themselves of the responsibility over content moderation. The second reason is to fortify itself against even bigger competitors, like Facebook, that threaten to enclose even more of the Internet.

3) Building Open Protocols from Scratch

Within the last seven years there's been an explosion of decentralized protocols, dealing with everything ranging from currency and commerce to social media and decision-making. We are way beyond the proof of concept stage. There are all kinds of ways to build decentralized protocols — based on gossip, distributed files, blockchains, or federated databases. The issue isn't whether decentralization is technically feasible. The issue is that there are so many ways to do it and how each protocol is appropriate for different use cases.

Developer and writer Jay Graber compared a few of the most well-known decentralized social network protocols. She explains the pros and cons of each protocol and how they operate. Protocols that put users in full control over their data and identity in a network can be too technically challenging for the average user. Protocols that rely on append-only logs, such as secure scuttlebutt, make it impossible to edit or delete posts. Federated networks can carry many of the same user-friendly features as centralized networks, but still leave the server administrators hosting the network with the same challenges — such as overseeing content moderation and platform security. So while protocols can be more neutral than platforms they still contain biases.

This Is a Human Problem, Not a Technical One

If we're talking about interoperability, we're talking about public Internet infrastructure. Open protocols and standards are part of a digital commons, and a commons thrives when people use and maintain it together.

As economist Elinor Ostrom declared in her Nobel Prize winning work, commoning is a social practice. What Ostrom asserted was that the success or failure of a commons, or what she called a "common-pool resource", rested on "how a group of principals who are in an interdependent situation can organize and govern themselves to obtain continuing joint benefits when all face temptations to free-ride, shirk or otherwise act opportunistically." For any type of commons, it's the relationships between those governing and relying on shared resources together that's central to its success.

Standards bodies were in many ways an implementation of Ostrom's eight principles for a commons — what she found were the basic elements needed for a commons to be governed sustainability and equitably. Thus Dorsey's call to build an "open community" around a new social media protocol is encouraging. It suggests the need to build organizations that keep various stakeholders engaged in an open dialogue about how we make social networks open and interoperable. This is the promise of a functional standards body. When they’re robust and effective, they can play a critical role in ensuring that the Internet remains free, open, and equitable.

Overcoming the Challenges

It's exciting to see this resurgence of energy for greater interoperability. But I'm not going to let myself get too hopeful. Anyone involved in this project needs to prove that this is going to be done right. Whether due to state-driven antitrust enforcement, tech companies' self-motivation, or from the bottom up with a new decentralized protocol, the manner in which protocols come about will be critical.

There are foreseeable issues with all three paths towards interoperability. Even if the government were to regulate companies, the state is feeble in the face of overpowering influence from corporate lobbyists. The revolving door that exists between private industry and public oversight bodies nearly guarantees a compromised process. Companies can't be trusted either. Independent developers have been continually burned by companies being unpredictable and negligent regarding the availability of public APIs — not to mention the hundreds of other ways they've violated public trust. Finally, nearly all of the decentralized web protocols were built by lone geniuses who collectively represent one demographic. If new protocols are to address the needs of diverse online communities, more types of people will need to be involved in their development.

Internet interoperability cannot be a project embarked on for the sake of profit, power, or someone's ego. Who is or is not in the room when critical decisions are being made about the protocol will make or break whether it will succeed in bringing about a more interoperable internet. We ought to learn from experts who know what it takes to govern shared resources together. If we’re serious about re-building the Internet as public infrastructure, we need to be prudent enough to assemble the types of organizations that can steward the Internet protocols of the future.

—

Further Reading

• European Commission, "Competition Policy for the Digital Era" (April 2019)   

• Mozilla's "A framework for forward-looking tech competition policy" (September    2019)

• Jack Dorsey, a twitter thread on Twitter's bluesky project

• George J. Stigler, Center for the Study of the Economy and the State "Committee    for the Study of Digital Platforms: Market Structure and Antitrust Subcommittee" (May    2019)

• Harold Feld, Public Knowledge "The    Case for the Digital Platform Act"

• Mike Masnick, Knight Foundation "Protocols, Not Platforms: A Technological Approach to Free Speech" (August 2019)

• Cory Doctorow, Electronic Frontier Foundation "Adversarial Interoperability: Reviving an Elegant Weapon From a More Civilized Age to Slay Today's Monopolies"    (June 2019)

• Chinmayi Sharma, University of Virginia School of Law “Concentrated Digital Markets, Restrictive APIs, and the Fight For Internet Interoperability” (January 2020)

• Irina Bolychevsky, Redecentralize "Instead of breaking up big tech, let’s break them open" (October 2019)

Filed Under: big tech, communities, competition, infrastructure, interoperability, platforms, protocols
Companies: facebook, google

The Good And The Bad Of The ACCESS Act To Force Open APIs On Big Social Media

from the one-step-forward,-two-steps-back dept

As people here will probably know, I am a huge proponent of a "protocols, not platforms" approach to handling questions around big tech and competition (as well as privacy, content moderation and more). I even wrote a pretty long paper about it for the Knight 1st Amendment Institute at Columbia University entitled Protocols, Not Platforms: A Technological Approach to Free Speech. So, I was definitely curious to see what Senators Warner, Hawley and Blumenthal had cooked up with their new ACCESS Act [Augmenting Compatibility and Competition by Enabling Service Switching Act] since it's being pitched as pressuring big social media companies to open up their platforms to competitors.

I've been a pretty big critic of past proposals from Senator Warner, Senator Blumenthal and especially Senator Hawley, but given that the topic of this particular bill sounded like it might be in line with my suggestions about creating competition through interoperable protocols and open APIs, I thought that maybe, just maybe, these Senators might have gotten it right.

Unfortunately, that does not look to be the case. To be fair, this bill is not nearly as bad as previous efforts by (especially) Hawley and Blumenthal to regulate internet companies. Indeed, I'd almost be convinced that, unlike some of their previous bills, this one actually is legitimately trying to solve the issues associated with some internet platforms becoming too dominant, and creating a path towards more actual competition. Also, this does, at the very least, take a different approach compared to the usual tools of governments (fines, breakups, etc) and recognizes the value of interoperability and actually enabling competition.

The problem, though, is that this bill won't actually accomplish what it hopes to do so. Because -- and this is a hallmark of Hawley's various tech bills -- it seeks to regulate a dynamic and rapidly evolving market as if it's stagnant and set in stone with little likelihood of ever changing. It also takes a very heavy handed approach, and reminds me, yet again, that Hawley seems to think he should be appointed the product manager for the internet. Also, there are much, much easier ways to accomplish what this bill seeks to accomplish -- by fixing other laws, rather than by piling on new rules.

The crux of this bill is that very large internet platforms (over 100 million monthly active US-based users, which would limit it to a very small number of platforms, perhaps just Facebook, YouTube, WhatsApp, Instagram, Twitter, LinkedIn, Snapchat and Pinterest) would have to offer up an open API and data portability for others, such as smaller competitors, to access the data on the platform.

A large communications platform provider shall, for each large communications platform it operates, maintain a set of transparent, third-party-accessible interfaces (including application programming interfaces) to initiate the secure transfer of user data to a user, or to a competing communications provider acting at the direction of a user, in a structured, commonly used, and machine-readable format.

One other interesting element here is that it would set up a new class of middlemen, that users could designate to manage their privacy. I envisioned something like this both in my Columbia paper and in one of my fiction stories in the Working Futures anthology, but mandating it by law just seems weird and nonsensical. This is the type of thing that you shouldn't need to mandate if everything else is designed properly.

The other crazy thing about this bill is that it seems to exist in a world where it doesn't recognize how this setup conflicts with all of the other complaints -- often put forth by the likes of Senators Warner, Hawley and Blumenthal -- that these companies don't do enough to protect user privacy. Yes, it hand waves at the privacy issue, by basically saying "make all your data available via an API... but make sure you keep it private." And that's about it. How to accomplish this without it creating a massive privacy nightmare is left unstated. Honestly, the description of the API they're asking for sounds an awful lot like the setup Facebook used to have, which was abused by Cambridge Analytica, leading to Facebook getting hit with a $5 billion fine. And now these Senators -- who I'm sure supported the FTC's fine (or even perhaps wanted more) -- are basically demanding that Facebook recreate the same open access plan?

Among the many bizarre and unworkable aspects of this bill is that it requires NIST -- the National Institute of Standards and Technology -- to come up with "standards" to make online messaging, social networking, and multimedia sharing standardized and "interoperable" within 180 days. This just goes to show that Warner, Hawley and Blumenthal (1) have never, ever been involved in the process of setting a technical standard, and (2) have no clue how many different variations there are on those three categories, which would make them fairly difficult to standardize (which is one of the many reasons attempts in the past to standardize each of those categories has failed miserably).

Finally, it's unclear why this particular approach is needed in the first place. As we've discussed, the big internet companies launched the Data Transfer Project last year that already accomplishes the core aspects that this bill wants to enable, but in a more privacy-protective manner, and that's been improving a lot.

So, yes, I actually appreciate that this is a slightly smarter approach to trying to create more interoperability -- which I do think is important -- but it goes about it in perhaps the least useful way possible. There are a whole bunch of better approaches, many of which we've discussed before:

• Have Congress clarify that APIs are not covered by copyright (before the Supreme Court even has a chance to weigh in). Overturn the CAFC's awful decision and you'll get more APIs and more interoperability. This is a low-hanging fruit type of option.
• Get rid of Section 1201 (the anti-circumvention or DRM clause) of the DMCA. This would allow for much more reverse engineering to get access to platforms, allowing more competitors to create their own interoperable systems.
• Fix the CFAA such to overturn the Power ruling that said that a third party company couldn't scrape Facebook's data even with permission from the user.
• Get rid of software patents, which can and are used to block interoperability and similar features within services.

Do those things and you'll get your interoperability, transportabiliy, and competition without having to "mandate" it.

Filed Under: access act, apis, competition, interoperability, josh hawley, mark warner, platforms, privacy, protocols, richard blumenthal, social media, transportability
Companies: facebook, google, linkedin, twitter, youtube

If You Think Google Is Too Dominant And Needs More Competition... You Should Actually Support Its Petition Concerning API Copyrights

from the interoperability-depends-on-it dept

Last week, we wrote about the confusion of both the US's Solicitor General and Oracle's lead litigator, Annette Hurst, in insisting that APIs are no different than software (and even that they're executable, which they are not). But, what's kind of incredible in this case is that, even as Oracle is so obsessively focused on bringing down Google, if it actually wanted to help bring it down, it should want to lose this case.

That may sound backwards, but let me explain. I've been talking a lot lately about the concept of protocols over platforms as a way to limit the dominance of giant platforms -- indeed, it's the only reasonable way I can see of leading to real competition in a world of network effects. Any traditional "break up" plan doesn't work, because you can't "break up" a global network in the same way you could break up many historical companies. But, what you can do is get them to open up their APIs or to make it easier to get data out of their systems in a way that is interoperable with other platforms.

But that's much, much harder if APIs are locked down with copyright, as Oracle is pushing for. To be fair, Google itself has always been much more open than lots of other companies in similar situations, but if we want true adversarial interoperability, as Cory Doctorow has highlighted, one way to help that along is to make sure that APIs can't be locked down, and that reverse engineering compatibility is free for anyone. That's how you build true competition -- and Oracle's case might shut down that important avenue.

Filed Under: adversarial interoperability, apis, competition, copyright, interoperability
Companies: google, oracle

There Are Lots Of Ways To Punish Big Tech Companies, But Only A Few Will Actually Help Improve The Internet

from the this-is-important dept

There are many reasonable complaints making the rounds these days about the big internet companies, and many questions about what should be done. Unfortunately, too much of the thinking around this can be summarized as "these companies are bad, we should punish them, any punishment therefore is good." This is dangerous thinking. I tend to agree with Benedict Evans who noted that there's a similarity between calls to break up big tech companies and Brexit in the UK:

I've pointed out a few times now that most calls to break up or regulate these companies fail to explain how these plansactually solve the problems people highlight. Companies are callous about our privacy? Will regulating them or breaking them up actually stop that? The GDPR has proven otherwise already. The companies algorithms recommend bad things? How will breaking them up stop that?

Too much of the thinking seems to just be focused on "company bad, must punish" and don't get much beyond that.

And that's a pretty big problem, because many of the ideas being passed around could ultimately end up harming the wider internet much more than they end up damaging the few big companies anyway. We've already seen that with the GDPR, which has served to further entrench the giants. The same will almost certainly be true when the EU Copyright Directive goes into effect, since the entire plan is designed to entrench the giants so that the big entertainment companies can negotiate new licensing deals with them.

In a new piece for the Economist, Cory Doctorow warns that many of these attempts to "harm" the big internet companies through regulation will actually do much more harm to the wider internet, while making the biggest companies stronger.

The past 12 months have seen a blizzard of new internet regulations that, ironically, have done more to enshrine Big Tech’s dominance than the decades of lax antitrust enforcement that preceded them. This will have grave consequences for privacy, free expression and safety.

He talks about the GDPR, FOSTA, the EU Copyright Directive and various "terrorist" and "online harms" regulatory proposals -- all of which end up making the big internet companies more powerful in the name of "regulating/punishing" them. It's worth reading Cory's take on all those laws, but he summarizes the key point here:

Creating state-like duties for the big tech platforms imposes short-term pain on their shareholders in exchange for long-term gain. Shaving a few hundred million dollars off a company's quarterly earnings to pay for compliance is a bargain in exchange for a world in which they need not fear a rival growing large enough to compete with them. Google can stop looking over its shoulder for the next company that will do to it what it did to Yahoo, and Facebook can stop watching for someone ready to cast it in the role of MySpace, in the next social media upheaval.

These duties can only be performed by the biggest companies, which all-but forecloses on the possibility of breaking up Big Tech. Once it has been knighted to serve as an arm of the state, Big Tech cannot be cut down to size if it is to perform those duties.

Cory is much more engaged in the idea of breaking up the big tech companies than I am (we recently debated the topic on the Techdirt podcast), but his point here is valid. So much of the "punish big tech" movement is at odds with other parts of the "punish big tech" movement. That's because there is no coherent strategy here -- it's just "punish big tech."

Cory's article suggests that any move towards antitrust should include mandating interoperability in an effort to build up competition:

One exciting possibility is to create an absolute legal defence for companies that make "interoperable" products that plug into the dominant companies' offerings, from third-party printer ink to unauthorised Facebook readers that slurp up all the messages waiting for you there and filter them to your specifications, not Mark Zuckerberg's. This interoperability defence would have to shield digital toolsmiths from all manner of claims: tortious interference, bypassing copyright locks, patent infringement and, of course, violating terms of service.

Interoperability is a competitive lever that is crying to be used, hard. After all, the problem with YouTube isn't that it makes a lot of interesting videos available—it is that it uses search and suggestion filters that lead viewers into hateful, extreme bubbles. The problem with Facebook isn't that they have made a place where all your friends can be found—it is that it tries to "maximise engagement" by poisoning your interactions with inflammatory or hoax material.

This actually reminds me of another similar piece, written last month by Josh Constine at TechCrunch, arguing that the FTC should force Facebook to mandate "friend portability" for Facebook:

I don’t expect the FTC to launch its own “Fedbook” social network. But what it can do is pave an escape route from Facebook so worthy alternatives become viable options. That’s why the FTC must require Facebook to offer truly interoperable data portability for the social graph.

In other words, the government should pass regulations forcing Facebook to let you export your friend list to other social networks in a privacy-safe way. This would allow you to connect with or follow those people elsewhere so you could leave Facebook without losing touch with your friends. The increased threat of people ditching Facebook for competitors would create a much stronger incentive to protect users and society.

Both Cory and Josh are making an important point: part of the reason why these platforms have become so big and so powerful is because there is real friction in leaving -- not because it's hard to just start using another platform, but because if all the other users are still on that other platform, it's meaningless if just you switch. Of course, history shows us that over time, many people will migrate over to new platforms. And you know this if you've been on the internet for the past two decades. Remember the 2000s when you used AIM to communicate with your friends while chatting with folks on MySpace? Over time, folks moved.

But making platforms more open -- forcing "interoperability" -- is certainly one way forward. I'd actually argue it does not go far enough. I've argued an even better solution is not just about forced interoperability, but moving to a world of protocols instead of platforms. In such a world, interoperability would be standard, but would also be just one piece of the puzzle for making the world more dynamic and competitive. If we relied on more open platforms, then third parties could build all sorts of new services, from better front ends, to better features and tools, and users could choose which implementation(s) they wanted to use, making switching from any particular service provider much easier -- especially if that provider did anything to hurt user trust. Interoperability would be one step in that direction, but only one step.

It's quite reasonable that people are concerned about big tech these days, but if we're going to have a reasonable solution that doesn't create wider negative consequences for the internet, we should be thinking much more carefully about the various proposals on the table. A simple "punish big tech because big tech is bad" may get people riled up, but the chances for negative consequences are too great to ignore.

Filed Under: antitrust, big tech, competition, copyright, gdpr, interoperability, punishment, regulations
Companies: facebook, google

How To Actually Break Up Big Tech

from the protocols,-not-platforms dept

Last week, I wrote about Elizabeth Warren's big plan to break up big tech and why I thought her plan (a) would not work and (b) was based on a fairly shocking number of factual errors. Not everyone agreed (indeed, many people have disagreed). Many of those who disagreed, though, seemed to only do so because they hate the big internet companies, and thus they seemed happy about any attack on them, no matter how pointless. Others attacked me personally, insisting that my detailed explanation of why I found Warren's plan laughably naive was really just because I "love big tech." Finally, some demanded to know what my plan would be. And while I think it's somewhat silly to imply that you cannot critique a bad plan if you can't come up with another plan (sometimes, doing nothing is the best plan), I've been meaning to write some more about this anyway, and here's a good opportunity.

Contrary to the strawman beliefs some insist I have, I am quite worried about the market power of many large companies these days, and how that might be stifling competition. As I've argued for over twenty years on this site, the single biggest driver of innovation is competition. And I want to see more competition to get more innovation. My issue is that doing so through regulatory means is fraught with significant risks -- ones that could very much do the opposite. Highly regulated industries are not known for being competitive and innovative for the most part. They tend to enable only big entities -- who can deal with the regulations -- to exist and crowd out startups. On top of that, thanks to regulatory capture and the crony nature of our political system these days, you also end up with just a few big companies who now focus on what we've referred to in the past as political innovation rather than technological or entrepreneurial innovation. It's a recipe for stagnation, not innovation and competition.

My second big concern with the plans people have been floating is that they ignore the reality of why some of the tech companies have gotten so big and so successful. For the most part, they're in highly networked industries, where it's not just "winner takes all" but in many ways size and dominance of the network is fundamental to their operation. Network effects can lead to dominant positions, for the fairly obvious reason that the bigger they are, the better they are for everyone involved. For all of Warren's talk of breaking up companies, note that she was only talking about chipping off a few of their peripheral acquisitions: not taking an axe to their core business.

And that's because she recognizes that as much as people scream to "break up big tech," there's no reasonable way to do that without making the overall offerings a lot less useful for the public. How do you break up Facebook's social network? Do you say half the world can't use it and have to use the BookFace spinoff instead? You could, of course, cleave off Instagram and Whatsapp, but that doesn't really change Facebook's overall global dominance. The reason Facebook is so powerful is that it connects the entire globe. There is no place to make a reasonable cut to split that up. Google is powerful because of its search engine. How do you break that up? Do you say for searches on topic X you use Google, but for searches on topic Y you have to use Elgoog? You could cut off Doubleclick from Google, but then you still have a massive search engine and a massive internet ads company. And while I guess you could cut off Amazon's web services piece from it store, that doesn't change the main "competition" complaint most people have about Amazon, which is the size of its footprint in e-commerce. But again, it got there not through predatory practices, but because it's so convenient and easy for most people that they actually get tremendous benefit from it.

But, that presents a dilemma. And while lots of people seem to think there are easy answers to this (just like they think there are easy answers to "content moderation") there are not. This is a really complex issue, and like nearly all super complex issues, the easy solutions tend to look appealing, while actually making everything a hell of a lot worse.

So I will make a suggestion for how I'd like to "break up" big tech, while admitting that since this is a complex topic with no easy answer, I could be wrong. But so could everyone else. And I've been digging through the details on this stuff for many years now, and I do think my plan makes the most sense. Later this year, I have a big academic paper on this topic coming out with a lot more details, so in the meantime expect a bunch more posts on this topic leading up to that.

The idea goes back to one I raised back in 2015 in the context of content moderation: that we need to move to a world of protocols, not platforms. This is the world of the earlier internet, dominated by open protocols with a variety of competitive apps built on top. Instead of Twitter, there was IRC. Instead of Reddit, there was Usenet. And you had a choice of clients and servers and could move around if you didn't like the policies of one or the other.

In the world of protocols, you still get the global connectivity benefit, but without the lockdown control and silos (and, potentially, the questionable privacy practices). In a world of protocols, there may be a global network, but you get competition at every other level. You can have competitive servers, competitive apps and user interfaces, competitive filters, competitive business models, and competitive forms of data management. If you don't like how one app provider handles privacy, you move to another -- but because you're using the same protocol, you don't lose everything you're doing with it, you're just entering through a new door that you like better. If you don't like the way one provider handles content moderation, you change it or move to another.

And, yes, I noted competition at the business model level as well -- because that's important. We could see lots of interesting attempts at creating different services with different business models that go beyond the limited options (pay with your data, freemium, advertising, etc.) today. One option might be in the form of cryptocurrency or token tied to the protocol. While I can already hear half of you rolling your eyes, this is a model that is at least worth exploring. A cryptocurreny or token tied to a protocol takes away much of the incentive for the really terrible business models everyone complains about. You don't need to spy on everyone if just getting more usage in general increases the value of the currency. And encouraging business models that don't require collecting data on everyone is something we should celebrate, not mock. But, cryptocurrency isn't the only such solution either. I've been playing around with a few attempts at new protocol-based systems these days that purposely eschew the cryptocurrency/token model, and are exploring other models instead. The point is that there are other ways of making this work, and more options is better.

However, if we were in a world where the major services and functions we used online were protocols instead of platforms, it would move the power and control out to the ends of the network, rather than centralizing it on the servers of a few giant companies. We'd still get the benefits of the network effects of the systems, but without the centralized control. We'd still be able to get innovation at various levels, but without relying on a single entity to determine what's best. We'd still get the convenience of powerful services, but without the opaque decision making of a single entity. It's an approach that could actually work.

That still leaves the question of how do we get there from here. And there are a lot of challenges in that. But I don't think declaring large platforms as "platform utilities" gets us any closer to that vision -- and if anything seems to drive us away from it. I'll be writing some more posts on how we get towards a world of protocols instead of platforms, and the many hurdles in the way, in the coming weeks and months. However, there are two key approaches to making it happen: either bottom up or top down. And both could work -- but both could be difficult.

The bottom up approach is people designing new protocols from scratch and building a new userbase. That presents a huge number of challenges in terms of building up the userbase, but it's not impossible. New startups pop on the scene all the time, and some of them even succeed. And I already know of at least 6 or 7 attempts at building these kinds of protocols from scratch. And while they're all fairly small, some are building up at least some traction and are interesting to follow and experiment with. The benefit to this approach is you have no legacy to deal with, making things easier to design and the entire setup more nimble. The cons, obviously, are the lack of a userbase and the basic "empty room" problem: how do you get someone to use a social application when there's nothing to do there and no one to connect with?

The "top down" approach would be to convince an existing internet giant to move towards such a world. It's unlikely that any company today would agree to flip the switch entirely and open up their platform into an open protocol. But I would argue that it's not as far out and unrealistic an idea as many assume. In the last six months, I've had in-depth conversations with four large internet companies about this approach, and they were surprisingly more open to at least considering what it would mean than I initially expected. And while I may go into more detail in later posts, I'll give three quick reasons why the big tech firms may actually decide it makes sense to give up their silos in the long run:

1. It gets them away from proposals like Warren's to "break up" their business, which they know would create a giant mess. By opening up their core code for anyone to use and pushing the power out to the ends of the network, the companies are effectively "breaking themselves up.
2. It takes them off the hook for all of the platform liability that is getting dumped on them these days. There are all sorts of competing and impossible demands on these platforms concerning how they moderate content, with tons of people being upset no matter what decision is made, and various people and (especially) politicians now looking to dump massive liability on the platforms themselves. If they turn their system into a protocol, they actually get rid of much of that headache. There will still be questions about content moderation, but it becomes a very different problem -- one to where there can be many different approaches, with competition at the filter level. We didn't used to blame email providers for spam, but thanks to the open protocols of email, it allowed all sorts of innovative spam filtering services to spring up. Given how much of a headache content moderation and platform liability has become of late -- and the fact it's likely to become an even bigger headache over time -- at some point, companies are going to realize an open protocols approach is a solution to that problem.
3. The possibility of new business models. This is important. Lots of people insist that no giant platform would willingly give up so much control, because it's entirely antithetical to business models built off of collecting all the data. And that's true. But, that's why I'm eager to see how new business models shake out in this space, because it might lessen the "we collect all your data" business model reliance and open up new opportunities that could even be more lucrative (especially if they create opportunities where people start abandoning services that don't respect their privacy).

There still are plenty of reasons why the big platforms are unlikely to do this in the near future (and I'm pretty sure a clueless Wall St. would punish any company that tried), but as various trends continue to move along, it may become more and more appealing.

Notice that all of that could very well happen without a massive policy intervention from the government. However, there are certainly policy ideas that could help move this along a lot faster. Of course, moving these policy proposals forward would require a more detailed understanding of how technology and technology innovation really works, because the key isn't enforcing breakups or trying to codify "fairness" guidelines with new rules -- it's taking away some of the existing legal and regulatory tools that make it easy and appealing to build vertically-integrated walled gardens, which aren't always obvious to people who aren't immersed in the tech policy space since they are presented as having other purposes:

1. Get rid of most patents (if we're talking real antitrust, we'd start by getting rid of these government-granted monopolies). Perhaps you could start with "software" ones, though defining what is a "software" patent is hard enough. Patents hinder competition and would create huge problematic thickets in a world of protocols where we want widespread competition at every other level. Without patent thickets and patent trolls, we'd see a lot more competition, especially in taking different approaches to providing interfaces and filters for the same kinds of content.
2. Dump the ridiculous CAFC ruling on API copyrights and make it clear that there is not copyright on interfaces, meaning that you could actually have much more interoperability and people building new systems to connect to third party products.
3. Get rid of Section 1201 of the DMCA and its anti-circumvention rules. Again, this blocks competition and interoperability. Indeed, Section 1201 is a huge barrier to this kind of future, in that it would allow companies to effectively block out competitive third party services through "technological protection measures." Without 1201, it would make it much easier for almost anyone to create a new competitive interface for an existing protocol-based service.
4. Make sure that full encryption is supported as a fundamental right of end users. This becomes important, as a protocol-based system should also lead to a booming new market for databanks that will store your encrypted data, giving you total control over it and who it is shared with (and for what purposes). But if there are mandated backdoors or some other crap, you completely destroy such a market. Encryption makes this possible.
5. Get the SEC to stop thinking of cryptocurrency as just a financial tool and to recognize it's something entirely different. Sure, you need them to deal with the out-and-out scams, but as it stands right now, the SEC is talking about crazy ideas like how any crypto system should need to go through "clinical trials" like drugs. Ideas like that would simply snuff out any possibility of the above ever happening. People don't realize how much of this future may be held back by a myopic SEC who is viewing all of this through a single lens.

There's more, but those steps would open up a lot of opportunity for a protocols-based system to take hold. And when it really happens, no one's going to worry about "breaking up" big tech anymore, because it won't even be necessary.

Filed Under: big tech, competition, copyright, elizabeth warren, encryption, end users, filters, innovation, interoperability, patents, platforms, protocols
Companies: facebook, google

Insanity Wins As Appeals Court Overturns Google's Fair Use Victory For Java APIs

from the this-is-bad dept

Oh, CAFC. The Court of Appeals for the Federal Circuit has spent decades fucking up patent law, and now they're doing their damndest to fuck up copyright law as well. In case you'd forgotten, the big case between Oracle and Google over whether or not Google infringed on Oracle's copyrights is still going on -- and it appears it will still be going on for quite a while longer, as CAFC this morning came down with a laughably stupid opinion, overturning the district court's jury verdict, which had said that Google's use of a few parts of Java's API was protected by fair use. That jury verdict was kind of silly in the first place, because the whole trial (the second one in the case) made little sense, as basically everyone outside of Oracle and the CAFC had previously understood (correctly) that APIs are simply not covered by copyright.

Section 102(b) of the Copyright Act says quite clearly:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

And an API is pretty clearly a procedure, process, system or method of operation -- it's just instructions on how to access certain elements, similar to a recipe. But, CAFC (who shouldn't be hearing this case in the first place) simply couldn't be bothered to comprehend what an API is, and insisted that because to the judges non-technical brains, an API looks the same as software, it must be copyrightable as software. That was after Judge Alsup in the district court (following trial #1) had spent quite a lot of time explaining to CAFC why APIs are not copyrightable.

Thus, we had the second trial, which was weird, because all of the arguments about fair use, were couched in this weird "um, well, it's not really copyrightable at all, but CAFC says it's copyrightable, so let's just say it's fair use" argument. And the jury then said, yes, it's fair use.

But CAFC has now rejected that and sent the case back to the lower court for a third trial for damages. And, while we normally expect bad reasoning from CAFC decisions, this one is particularly stupid. In short, CAFC's reasoning is basically "we think this is infringement, and thus we're going to handwave around the law to make sure that it's infringement." It's bad. And, again, CAFC shouldn't even be hearing the case. CAFC hears appeals on patent cases, and originally there were a few patent claims in this case, but they all got dumped at a very early stage. So this case should have gone to the 9th Circuit (who also might have messed it up, but it has at least a marginally better record than CAFC).

Anyway, the CAFC does an awful lot of handwaving around historical precedent to justify its decision to basically start from scratch in going through the fair use four factors. As we've discussed multiple times, one of the problems with the four factors test is that it allows a court to choose who it likes better, and then twist the four factors to give it the outcome it wants. That appears to be what is happening here. On the first factor (nature of the use), CAFC basically says "we think the jury is stupid, this is obviously commercial use, and thus it goes against Google." Google had argued (and the jury had implicitly agreed) that because Google doesn't charge for Android, and interoperability and progress of innovation enabled by using similar API setups are not inherently commercial motives, that this was fair use. The court basically says "but Google has so much money!" which is not how a fair use argument works. But... CAFC.

That Google might also have non-commercial motives is irrelevant as a matter of law. As the Supreme Court made clear when The Nation magazine published excerpts from Harper & Row’s book, partly for the purpose of providing the public newsworthy information, the question “is not whether the sole motive of the use is monetary gain but whether the user stands to profit from exploitation of the copyrighted material without paying the customary price.” Harper & Row, 471 U.S. at 562. Second, although Google maintains that its revenue flows from advertisements, not from Android, commerciality does not depend on how Google earns its money. Indeed, “[d]irect economic benefit is not required to demonstrate a commercial use.” A&M Records, 239 F.3d at 1015. We find, therefore, that, to the extent we must assume the jury found Google’s use of the API packages to be anything other than overwhelmingly commercial, that conclusion finds no substantial evidentiary support in the record. Accordingly, Google’s commercial use of the API packages weighs against a finding of fair use.

On the question of transformative use, the lower court had suggested that using the APIs in a "fresh context" (such as for smartphones) could be seen as transformative. But, again CAFC says "nope."

Google’s arguments are without merit. As explained below, Google’s use of the API packages is not transformative as a matter of law because: (1) it does not fit within the uses listed in the preamble to § 107; (2) the purpose of the API packages in Android is the same as the purpose of the packages in the Java platform; (3) Google made no alteration to the expressive content or message of the copyrighted material; and (4) smartphones were not a new context.

CAFC also, once again, shows that it still doesn't understand why APIs and code are not the same thing:

That Google wrote its own implementing code is irrelevant to the question of whether use of the APIs was transformative. As we noted in the prior appeal, “no plagiarist can excuse the wrong by showing how much of his work he did not pirate.” Oracle, 750 F.3d at 1375 (quoting Harper & Row, 471 U.S. at 565). The relevant question is whether Google altered “the expressive content or message of the original work” that it copied—not whether it rewrote the portions it did not copy.

But that's not the relevant question. The relevant question is how the copied text is being used, and in Google's case it's in a completely different context, which is why it had to write its own implementing code. Again, this is fallout from CAFC's earlier wrong decision in that it still does not understand that API instructions are not the same as implementing code itself.

The court also more or less laughs at the idea that Google had "good faith" reasons for doing what it did:

Ultimately, we find that, even assuming the jury was unpersuaded that Google acted in bad faith, the highly commercial and non-transformative nature of the use strongly support the conclusion that the first factor weighs against a finding of fair use.

On factor two of the four factors analysis -- the nature of the work -- CAFC again actually gives that one to Google and says that the jury could have found that weighed towards fair use, but immediately points out that it's going to give this factor less weight, because... it still doesn't understand the difference between APIs and software, and insists that if it gave this factor any weight, it would destroy the idea of copyright for software. Of course, that's only true if you can't tell the difference between an API and software.

We note, moreover, that allowing this one factor to dictate a conclusion of fair use in all cases involving copying of software could effectively negate Congress’s express declaration—continuing unchanged for some forty years—that software is copyrightable. Accordingly, though the jury’s assumed view of the nature of the copyrighted work weighs in favor of finding fair use, it has less significance to the overall analysis.

On factor three, concerning the amount use, the court again is so incredibly confused it's frustrating. Google has long held (and the jury and the lower court appeared to agree) that it used the bare minimum of the Java API to enable basic interoperability in building apps for Android. But CAFC is so tied up in its own made up reality, that it insists no reasonable jury could agree with this:

Even assuming the jury accepted Google’s argument that it copied only a small portion of Java, no reasonable jury could conclude that what was copied was qualitatively insignificant, particularly when the material copied was important to the creation of the Android platform.

Eventually, though CAFC says factor 3 could be either "neutral" or "arguably weighs against" fair use.

On to factor four -- the impact on the market. Factors one and four tend to be the ones that courts focus on the most. And, here, Oracle has spent plenty of time whining that its own total failure to capitalize on Java in the mobile market should be blamed on Google's copying piece of its API as opposed to the reality, which is that Oracle completely botched its own efforts in the space, because it's Oracle. The court more or less ignores various points about how Oracle wasn't really in the mobile market and more or less says "Google was super successful, so clearly it was at the expense of Oracle."

Given the record evidence of actual and potential harm, we conclude that “unrestricted and widespread conduct of the sort engaged in by” Google would result in “a substantially adverse impact on the potential market for the original” and its derivatives.

And, thus, the court then weighs factors one and four most heavily, and says it's not fair use, and back to Northern California we go for trial number three, specifically on the damages question. I imagine Google will appeal this, either asking for an en banc rehearing or to the Supreme Court. The Supreme Court refused to hear the previous request on the question of copyrightability of APIs, so this is probably a long shot. However, there are a few oddities within the ruling that maybe will catch someone's attention at the Supreme Court (and the Supreme Court has spent years dunking on CAFC and mocking its dumb decisions, so maybe they'd like to do that again).

Honestly, the most concerning part of the whole thing is how much of a mess CAFC has made of the whole process. The court ruled correctly originally that APIs are not subject to copyright. CAFC threw that out and ordered the court to have a jury determine the fair use question. The jury found it to be fair use, and even though CAFC had ordered the issue be heard by a jury, it now says "meh, we disagree with the jury." That's... bizarre.

Anyway, considering the importance of interoperability in software, this case is yet another potential disaster, limited only by the fact that CAFC doesn't cover any particular region and most copyright cases aren't influenced by CAFC precedent since those cases would flow up through the other appeals courts. However, you can see how someone wishing to go after others for API infringement might just throw in a silly patent claim just get it into CAFC. Hopefully the Supreme Court steps in and fixes this, but if not, it would be nice (I know, I know...) if Congress actually stepped up and pointed out that APIs are not covered by copyright at all. And while they're at it, they should burn CAFC to the ground. It was a dumb idea in the first place and should be shut down.

Filed Under: api, apis, cafc, copyright, fair use, interfaces, interoperability, programming
Companies: google, oracle

How Microsoft Delayed A Wildly Popular Xbox Feature To Clean Up Its Wildly Unpopular Always Online Plans

from the facepalm dept

The Xbox One has been back in the news recently as Microsoft has rolled out an update that makes the system backwards compatible with some original Xbox games. Much as with the backwards compatibility roll out for Xbox 360 games that Microsoft performed in 2015, fans of the system have been cheering this on. It's something a no-brainer, with this functionality making the system all the more appealing and increasing brand loyalty for the console as gamers will be conditioned to expect that the investments they've made in gaming titles won't go to waste once the shelf-life of a particular generation of systems runs its course.

Which raises the obvious question: why in the world did Microsoft wait until 2015 to put backwards compatibility in place? The answer, it seems, is that Microsoft suddenly became too busy cleaning up after the backlash to its always-online plans for the Xbox One to roll it out.

That nugget comes from a wide-ranging behind-the-scenes look at Microsoft's backward compatibility efforts posted on IGN this morning. Amid quotes from an array of Microsoft employees involved in the backward-compatibility development and rollout, writer Ryan McCaffrey includes this tidbit (emphasis added):

The fan-first feature has evolved from an experiment conducted by two separate Microsoft Research teams into a service planned for Xbox One's launch—complete with hardware hooks baked into the Durango silicon—until the well-publicized changes to the Xbox One policies (namely, stripping out the always-online requirement for the console) forced it to be pushed to the back burner.

Another way to put this would be: Microsoft had to spend so much time disabling a "feature" in its console that it should have known pretty much everyone would hate that it delayed enabling a feature it knew everyone would love. If that isn't a lesson in why companies should put their customer desires first and foremost in their minds, I don't what is.

If you don't remember what the console wars of 2013 were like, they were pure pandemonium for the Xbox. The always-online requirement was the headliner for this whole fiasco, but there were also questions about whether or not the Xbox One would allow used games to be played on it at all. Sony, meanwhile, took happy delight in reminding the public that its Playstation console had none of these questions attached to it. The result was a predictable loss for Xbox from a sales perspective, even as Microsoft then had to spend time and money to remove the always-online requirement.

And earlier this year, former Xbox Chief Marketing Officer Yusuf Mehdi reflected in a LinkedIn posthow "it required great technical work" to change course and reverse "a few key decisions regarding connectivity requirements and how games would be purchased that didn't land well with fans."

That kind of "great technical work" isn't free in terms of time or worker attention, and IGN's reporting suggests that Xbox 360 backward compatibility was an initial victim of that change in focus.

Maybe next time give your customers what they want rather than telling them what they want?

Filed Under: always on, drm, interoperability, xbox
Companies: microsoft

Oculus Reverses DRM Course After Public Backlash

from the power-to-the-vr-people dept

Weeks back, Karl Bode wrote about the curious position Oculus Rift had taken in updating its software to include system-checking DRM. VR headset technology and game development, experiencing the first serious attempt at maturity in years, needs an open ecosystem in which to develop. What this DRM essentially did was remove the ability for games designed to run on the Rift from running on any other VR headset, with a specific targeting of community-built workarounds like Revive, which allowed HTC Vive owners to get Rift games running on that headset. Oculus, it should be noted, didn't announce the DRM aspect of the update; it just spit out the update and the public suddenly learned that programs like Revive no longer worked.

The backlash, to put it mildly, was swift and severe. Oculus having been acquired by Facebook likely didn't help what were already negative perceptions, supercharging the outcry with allegations of the kind of protectionism and the lack of care for the public that Facebook has enjoyed for roughly ever. Still, many saw the whole thing as peons screaming at a feudal lord: Oculus would simply ignore the whole thing. Just weeks ago, in fact, Oculus was working journalists at E3 in defense of the DRM.

The problem, [Oculus Head of Content Jason] Rubin said, comes with the wholesale distribution of a hack like Revive to the whole community, rather than to a few individuals. "[A personal hack] is a far cry difference from an institutional tool made and distributed to a mass number of people to [support other headsets], strip out DRM, strip out platform features and the like. For an individual to do that for themselves, that would be all right. Mass distribution is an entirely different situation."

No explanation on why the level of access to the workaround makes all the difference appears to have been offered, but it seems likely that the company didn't want to appear to be going after gamers and tinkerers, only larger development outfits. If so, the attempt didn't work, because software like Revive was in high demand. This is to be expected, as VR is just now starting to sprout from the seeds laid long ago, with impressive but limited options for both hardware and games to run on that hardware. Those limitations mean that any attempt at exclusivity being tied to hardware that is relatively expensive walls off each of the gardens and limits access and interest. For a technology still in its early stages, this would only stifle growth. Hence, the anger from the public.

Anger which appears to have worked, contrary to what some had thought. As silently as Oculus rolled out the DRM, it has now spit out an update which rolls it back. The world found out about it not from Oculus itself, which curiously didn't want to capitalize on some good press for once, but from Revive's development team.

The Oculus team has reversed course on one of its most unpopular decisions since launching the Rift VR headset in April: headset-specific DRM. After weeks of playing cat-and-mouse to block the "Revive" workaround, which translated the VR calls of Oculus games to work smoothly and seamlessly inside of the rival HTC Vive, Oculus quietly updated its hardware-specific runtime on Friday and removed all traces of that controversial DRM.

What's more, Oculus didn't mention the change in its runtime update notes, which are curiously future-dated one day forward on Saturday, June 25. The news instead broke when Revive's head developer posted a note on the project's Github download page. "I've only just tested this and I'm still in disbelief," the unnamed LibreVR developer wrote. Accordingly, the Revive team has since removed the patch's DRM-disabling feature, which had later been implemented as an extreme measure to make Oculus games play on the HTC Vive.

It appears that even when Oculus chooses to listen to its fans and potential customers, it can't be bothered to do so publicly. This strips its ability to claim credit for the move, credit which it desperately needs after several negative news cycles. Still, the company's PR ineptitude aside, it's a nice lesson in what public backlash and shaming can do to pressure a company to be a little more open.

Filed Under: drm, interoperability, oculus rift, revive, vr
Companies: facebook, oculus

After Spending A Day As The Internet's Punching Bag, Philips Walks Back Firmware Update That Locked Out Third-Party Products

from the hue-and-cry dept

Philips apparently wants more people to be "friends of Hue."

Philips pissed off its customer base by pushing out a firmware update that made non-"friends of Hue" light bulbs suddenly incompatible with its hubs (despite utilizing an open standard -- ZigBee). It claimed this stripping of functionality was in purchasers' best interests.

While the Philips Hue system is based on open technologies we are not able to ensure all products from other brands are tested and fully interoperable with all of our software updates. For guaranteed compatibility you need to use Philips Hue or certified Friends of Hue products.

Much to nobody's surprise, customers weren't happy when their compatible bulbs were instantly (and artificially) made incompatible by Philips. The only "guaranteed compatibility," according to Philips, was the use of Philips' products in Philps' fixtures. And just like that, the company turned an open standard (ZigBee) into a walled garden.

Multiple posts detailed customers' complaints about Philip's backhanded, self-serving firmware update. Philip's Hue Twitter account was flooded with angry tweets from former customers, current customers and people swearing to never purchase a Philips product ever again in the future.

Philips -- to its credit -- has apparently realized that putting profitability ahead of flexibility makes no one but Philips happy. And even then, it doesn't make Philips happy for long. It is now rolling back the light bulb-bricking firmware update and restoring support for third-party bulbs.

We recently upgraded the software for Philips Hue to ensure the best seamless connected lighting experience for our customers. This change was made in good faith. However, we under estimated the impact this would have on a small number of customers who use lights from other brands which could not be controlled by the Philips Hue software. In view of the sentiment expressed by our customers, we have decided to reverse the software upgrade so that lights from other brands continue to work as they did before with the Philips Hue system.

We are working on the reversal of the upgrade and will shortly confirm when this will be available.

Sure, there's some dodgy corporatespeak that attempts to portray this as an honest mistake made with the best of intentions, rather than what it appeared to be: a chance to cut competitors out of the market. But underneath all the deflection, there's an actual update on the way that will return the functionality the last firmware update removed. Unfortunately, it does appear that Philips will continue to use its own, more-"closed" version of ZigBee's open standard, meaning there will be compatibility issues in the future -- all of them related to Philips continuing to wall off its products.

The turnaround on this was surprisingly quick, but the sad fact is that it never needed to happen in the first place. The best course of action is one far too many companies seem only able to recognize in hindsight: don't screw over your customers -- especially your early adopters, who often act as evangelists for unproven tech and create lucrative markets for niche products. The additional income gained in the short term is rarely worth the loss of future sales and the accompanying damage to your reputation.

Filed Under: interoperability, smart lightbulbs, smartbulbs, zigbee
Companies: philips