We're heading Straight for AOL 2.0 | Hacker News Reader

We're heading Straight for AOL 2.0

jacquesmattheij.com

90 pointsRondom24 comments

Previously: https://news.ycombinator.com/item?id=10008769 (and https://news.ycombinator.com/item?id=10160133 with no comments)

It seems the recentness of that discussion was enough for many people to warrant flagging this one--it's been sent to page 6.

Not sure what you're ranting about here. What closed protocols / technologies are vendors creating that pose a risk?

On the contrary over the last few years we've seen vendors start to converge on web standards (HTML, CSS, JS) [2].

We've seen the development of crucial technologies for rich multimedia / interactivity on web apps like websockets (RFC 6455 [3]) and WebRTC [4]. Things like an open browser automation protocol is helping devs build cross-browser apps [5].

Also, 1) we're up to RFC 7639 in the official list [1], so that's about 2000 RFCs since the one you mentioned in your article. 2) RSS is not a protocol 3) vendors are building completely open source tools (e.g. Facebook & Google with React & Angular.js) 4) "companies now deliver one half of their application and some custom protocol over HTTP and never mind inter-operability with other services or playing nice", really confused about this, do you have any examples? 5) Are you suggesting that HTTP is transport layer? Because it's not [6]

   [1] http://www.ietf.org/download/rfc-index.txt
   [2] http://caniuse.com/
   [3] https://tools.ietf.org/html/rfc6455
   [4] http://www.w3.org/TR/2015/WD-webrtc-20150210/
   [5] http://www.w3.org/TR/webdriver/
   [6] https://en.wikipedia.org/wiki/Internet_protocol_suite

It's also the walled garden aspect. Restrictive APIs [twitter], and blocking 3rd party developer projects [craigslist/padmapper].

You're missing the point if you're holding up HTML/CSS/JS as a counter-example.

In the past, we had a more robust network software ecosystem in which high-level protocol semantics were standardized across vendors, ensuring that:

- Multiple server implementations existed, and

- Multiple client implementations existed, and

- Data (the bits owned by users) were portable across those implementations.

This creates a healthy, more resilient ecosystem, within which there does not exist a single point of failure, and competition for clients, servers, and services providing the same is robust.

HTML/CSS/JS do standardize semantics, but they're application platform semantics -- we get interoperability and choice across browsers and web servers, but we're losing network interoperability between the applications being built on top of them.

This isn't limited to the web, either: closed protocols and DRM on mobile (e.g. Apple's iMessage, Facetime) have produced a similar result. Apple controls the messaging clients, the OS, the network protocol, and the servers. If you want to leave, you lose access to everyone else using the protocol. Resiliency is also lost -- a single party controls the entire infrastructure, including the client software.

> RSS is not a protocol

I don't agree with this, but I can see reasonable arguments on either side of the argument.

> vendors are building completely open source tools [like] React & Angular.js

It's good that folks are open-sourcing their GUI toolkits. The problem isn't the lack of open-source GUI toolkits. The problem is the lack of interoperability between various Bigcos' services due to the lack of open protocols. Sure, you can reverse engineer the protos, but protocol design and BigCo cantankerousness has come a long way since OSCAR.

> Are you suggesting that HTTP is transport layer? Because it's not

It totally is. It's the Universal Firewall Bypass transport layer. (There are ways to categorize sections of the networking stack that aren't the OSI seven-layer model. :) )

The difference here is that while AOL was a completely walled garden, many of the various players here have APIs that you can connect to. Then you have intermediary companies like IFTTT and Zapier that are glue between those various services.

Not that I don't agree with the main point - moving from completely open to little fiefdoms, but I think it's an imperfect analogy given the push towards everything having APIs for connectivity between them.

Your mention of "little fiefdoms" reminded me of a piece that Bruce Schneier wrote called "Feudal Security": https://www.schneier.com/blog/archives/2012/12/feudal_sec.ht....

Previous discussion: https://news.ycombinator.com/item?id=10008769

Somewhat related Sandstorm.io is also a pretty cool concept that might help avoid an AOL 2.0.

https://sandstorm.io/

I love a good rant (and I respect Jacques a lot!), but this one falls apart between the 3rd and 4th paragraphs:

>...instead of delivering software to the end users which then implemented this protocol using executables for the various platforms[,] HTTP allowed to deliver both the visual part of the application (the user interface) and (eventually) the rest of the client portion of the application in one go. (comma added)

>The end result of all that is that we’re rapidly moving from an internet where computers are ‘peers’ (equals) to one where there are consumers and ‘data owners’, silos of end user data that work as hard as they can to stop you from communicating with other, similar silos.

Both of these may be true, but one doesn't follow from the other. There are a complex blend of forces that conspire to silo data and separate it from users - not the least of which is the desire to a) keep it safe, and b) make it accessible on all devices. If disposable web software follows from anything it's from the vulnerability of client devices - we give you both the reader and the data every time because we know you're going to drop your phone and need a reinstall anyway.

The web is still maturing and I think WebRTC and WebSockets are particularly interesting, because they are analogs to lower level things that came before, but they work in that disposable web environment.

Yep. I think a big point that has not been addressed is how we got into this situation. Most internet users are locked behind home or corporate networks, without a real addressable IP and every port but 80 and 443 blocked. A lot of this was done in the name of security (exactly how does blocking a port or ignoring a ping response make you secure? I've never heard a valid technical reason for this being more secure, beyond tradition-says-so answers.), but is really due to cargo-cult sysadmin behavior and bad default settings on hardware.

Now we've basically ruined IPv4, peer to peer communication doesn't work for enough users to make it useless, forcing the centralized server-client model. It's not just hardware with bad defaults - try accessing a (non-localhost) website hosted on a port 6666 in Chrome. You can't, Chrome has a blacklist of "insecure" ports. I am baffled such a concept even exists, ports aren't secure or insecure, they are a channel for data. Then I look at websockets and laugh, We rebuilt udp over http over tcp, just so web developers can send arbitrary data again...

I get very upset when I see the same sort of ideas taking hold in IPv6, we have another chance not to ruin this, and yet we seem to want to force the broken IPv4 model, with firewalled NATs, blocked ports, and more broken default settings.

Ping of death has happened before. You do not serve any purpose by opening ports that you do not intend to use. Closing all unneeded port is called minimizing attack surface.

Ports may not be inherently secure or insecure, but the history of their usage give them bias towards likely being secure or insecure. Chrome does the right thing by blocking these ports as an overwhelmingly large percentage of their users will probably hit this port under "insecure" situations. Those who need to use these ports can and will find alternate ways to do it.

What "attack surface"? Almost all your ports, no applications listen to. Closing them serves no useful purpose.

If an application has problems accepting input on a port it is listening to, that is an application bug. Closing your ports doesn't solve this, it just hides the problem under the rug, and breaks the Internet in the process.

> Closing your ports doesn't solve this, it just hides the problem under the rug, and breaks the Internet in the process.

To be fair, if you don't listen to tin-foil-hatters like GRC and configure your firewalls to REJECT non-invalid [0] traffic, rather than DROP, the only thing you'll break is the ability for others outside your network to connect to services on those ports.

[0] In the iptables CONNTRACK sense of "invalid".

The firewalls you mentioned were NAT/Enterprise level. They do not generally have absolute control of what programs are running on one of their internal computers. May be that port left open is used by a C&C client installed on one of the user's computer inside LAN, hereby possibly compromising the whole internal network. There is a reason why DMZs exist.

Corporate security is a different sort of beast from almost every other security environment. What's acceptable in that arena is almost always an unacceptable management practice for someone who is designing and operating what is supposed to be a network of peers.

> ...try accessing a (non-localhost) website hosted on a port 6666 in Chrome. You can't, Chrome has a blacklist of "insecure" ports.

The reasoning for that is -apparently- as follows: "So, why does Chrome refuse to connect to some ports? Because the Google engineers has gone through the list of well known ports, and worked out how tolerant the protocols that use these ports are to being sent HTTP requests, and if they are tolerant, they've marked it as unsafe and so blocked it, to prevent Google Chrome from being an open proxy to a secured network." [0]

I'm not sure how I feel about that reasoning.

[0] https://jazzy.id.au/2012/08/23/why_does_chrome_consider_some...

Open protocol, HTTP, email:

http://jmap.io/

It's not peer-to-peer, but at least it is open. We see the same issue, which is why we're doing it.

> Please open up your protocols, commit to keeping them open and publish a specification. And please never do what twitter did (start open, then close as soon as you gain traction).

If you want to make money, I'm not sure how sound this advice is. Anyone know an example of a company that has kept protocols open and made any significant money?

The question is: is it a case of "because", or "despite"? Is there any proof that using open protocols and making money are mutually exclusive?

I think the people that have been making proprietary protocols just moved from making them directly on top of TCP to HTTP. Saying that if HTTP didn't exist Facebook would have proposed an interopable status protocol seems incredibly naive to me.

I actually expected to see a rant about Facebook. That said, I don't think that the general issue is so bad regarding protocol development. For the most part, people are building on the back of HTTP.

From the article:

> And please never do what twitter did (start open, then close as soon as you gain traction).

Charging for access is hardly "closing itself". Is the author faulting them for moving to a more sustainable model?

Somewhat, but not completely, along the same lines:

https://news.ycombinator.com/item?id=10188667

Reply on news.ycombinator.com