No protocol survives first contact with its userbase. The needs of your users tend to change over time. Security wasn't a huge overriding concern when SMTP and POP3 first became popular. If your organization was bitten by the recent Exchange bug, you might find yourself asking, "why doesn't email support an easy, universal, cross-organizational E2E encryption?" When protocols can't be extended, they can't grow to meet new needs. It is a foolhardy endeavor to release a spec that can't easily be extended.

We should take a step back here and decide what the problem really is with the web.

If the problem is that pages are too large, we should find ways to make them smaller and more responsive. It is possible, even in 2021, to make JavaScript-less pages that are highly portable, are fast to render, and are still usable even with CSS disabled. We don't need an entirely new protocol to serve them. The original browser had very simple pages. If browser makers stopped catering to bigger and badder JavaScript usage and started making "use more CPU time than X" an optional permission, we might see some downward pressure on document complexity. If browser makers built a Markdown renderer into their products, it might be easier for people to write simple documents.

If the problem is rampant, exploitative commerce: such activity can fester in almost any environment, regardless of whether or not the protocol favors it. We humans are clever and are very good at figuring out how to make a quick buck—even or especially at someone else's expense. If you find this activity objectionable, you might find some refuge in aggressively declaring your space to be non-commercial, like the original ARPANET, AMPRNet, or the modern-day Wikipedia. You'd have to police it, of course. You could also encourage commerce to take place in a less exploitative manner. These things might better be addressed through policy than protocol design. I like my protocols to be neutral carriers, thankyouverymuch.

If the problem is centralization, which leads to overwhelming control and/or surveillance by either non-state or state entities... we'll need to be very clever and inventive. Your average "home server on a DSL line" simply cannot meet the uptime, latency, and throughput demands of a Slashdotting. The average connection owner simply cannot compete with cloud services here, and your protocol will end up getting all cloud-ified if it becomes popular. Rather than fight the centralization, we could embrace it. What if datacenters sold "shares," such that the public could become an owner-operator with voting rights and a true say in that datacenter's operations? What if infrastructure was operated for the public good in the public trust? We could have centralized infrastructure with decentralized ownership. We should also invest in technologies which keep sensitive plaintext data off of the cloud and in our hands, where it belongs.

These ideas might not all be good ideas, but they have a common theme. Poor design, commercialization, and centralization are all human-factors issues. Technological solutions to human behaviors—like that alarm clock you keep ignoring—are generally doomed to failure. A Code of Conduct is a much better way to police bad contributors than a profanity filter.

Sometimes protocols are a necessary adaptation. Onion-routing is probably the best technological solution to mass surveillance we've been able to devise thus far. TLS helps keep some of the prying eyes at bay. But neither of these protocols really address bad behavior by actors who are operating inside the protocol. Onion-routing won't prevent illegal commerce. TLS won't prevent Cloudflare from stealing all your secrets off the other end of the wire. As developers, we must understand that our ability to fix human problems with bigger and badder technology is fundamentally limited. We need human solutions for our human problems.

This may well work for OnStar devices. For Fiat Chrysler vehicles which use the "UConnect" system, the process is much more difficult. Old forum threads suggest that the radio's "head unit" itself is a self-contained spy device.

The head unit has a cellular modem which is physically soldered to the rest of the system. This makes it difficult to remove non-destructively. One can't simply remove the SIM—there is none—and the modem has an on-chip antenna which similarly cannot be unplugged. It might be possible to replace the "radio" with an aftermarket part, but said part would also need to manage the climate control and other passenger comfort systems.

I can understand how having fewer boxes and plugs can streamline the assembly process and improve reliability. In this case, however, I can't help but wonder this is a deliberate, anti-consumer design choice. At the very least, these systems ought to include some type of "RFKILL" switch or functionality.

If this sort of thing is important to you, research carefully before you buy.

The summary probably wasn't written with a technical audience in mind, and it leaves much to be desired.

The main contribution here is the concept of linked data: that the relationship between media objects should be exposed through a standards-based interface. This is an old idea, but it is seldom practiced. Linked data is a natural extension of Sir Berners-Lee's original hypertext protocol, which provided for hyperlinking between documents.

The linked data protocol encourages the development of distributed applications. For example, one can host a photo on one server, but comments about that photo could be distributed among many others. Linked data is used to describe what refers to what. In this model, contributors are expected to retain more control over their contributions. This will likely scale OK for small groups... but if you attract hundreds of comments, you might be in trouble.

Is this useful? Maybe. It appears to fill much the same space as existing "social networking" websites, which provide both identity and methods for "limited sharing." It does not appear to address the needs of

• Very personal data like healthcare information, which must be stored only in highly secure, trusted environments; OR
• Very public data, which one might wish to store immutably, indefinitely, and have it be highly discoverable

Worse, where are we going to put these "Solid PODS?" On our home PCs? Most homes are not blessed with high uplink speeds, 99.9%+ SLAs, uninterruptible power, or redundant data centers. The answer for most people is likely going to be "in the cloud." Economies of scale dictate that low-cost cloud computing resources will be concentrated into the hands of relatively few organizations with both the capital and the experience to provide them.

All will be well and good until the cloud service providers realize that they can simply peer into these PODS and extract all the data that they ever wanted.

Does anyone remember back when Microsoft decided to unceremoniously remove A/V support from the linux version? Calls stopped working without any notice, and a fix took at least four months.

No thanks. I will never rely on Skype ever again. The good news is that in 2017, there are many alternatives which work just as well, if not better. Pick one and help it grow.

At the risk of saying, "me too," I can also confirm that Equifax security freeze PINs are a timestamp.

PINs do not necessarily need to be "random" in order to be secure. They need only be unpredictable by an outside attacker. Right away, we can see that some digits are predictable. Years are limited by the age of the submitter. Hours are generally limited to those during which the submitter is awake. I'm not sure why they bothered with ten digits when the PIN actually has much less entropy than that.

The security freeze process also generates events which are observable to an outside attacker. The process may result in either credit card transactions or validation/receipt emails. These things might easily be logged with sub-minute time resolution. If attackers breached Equifax's credit card processing database, then all PINs are compromised. Stop.

But even if PINs are purely random and are stored hashed—which is the accepted way to do things—then they would still be compromised in the event of a data breach. Ten numeric digits isn't going to be particularly difficult to brute-force, even with a very expensive salted hash. In 2017, it is easy to purchase massive amounts of compute time... for cheap. The only safe way to store such a short string would be a well-designed Hardware Security Module. That's assuming they care. They don't, of course.

At this point, there has been no indication that the integrity of Equifax's data has been compromised... only its confidentiality. This is a problem for us consumers, as it means that credit issuers can still continue to rely on them to verify creditworthiness.

I would recommend placing a "fraud alert" and keeping it up-to-date every 90 days. It costs nothing, and it provides a little extra security.

If the airlines really want to streamline their check-in process, they should focus on creating terminals with a fast, responsive UX. Any time I've used an airport kiosk, I've had to click through anywhere from five to eight screens of information. Each screen is separated by a lengthy "loading" modal dialog box which takes anywhere from two to five seconds to process.

No, I don't want to pay the at-airport price for a first-class upgrade. No, I don't want to change my seat---there are no more seats to be had! No, I don't want a mileage multiplier. To check bags, I have to swipe a credit card they already have on file and wait for it to authorize. At the end of the process, I have to wait another fifteen to twenty seconds for my boarding documents to re-print---regardless of whether or not I need them. All the while, I'm using a touchscreen which has the responsiveness characteristics of a physical keyboard: a physical keyboard that has been dipped in molasses and then coated in gelatin.

As it stands, I suspect that the airlines really have no interest in streamline check-ins. They seem to use it mostly as another opportunity to sell you things.

I have attempted to use Walkscore for this very task: moving to an area, sight unseen. I have found it incredibly lacking. It computes "nearby" locations using either as-the-crow-flies distance or an automobile driving map; I'm not sure which. While this might be acceptable in a gridded downtown area, which has ample sidewalks and pedestrian signals, it does not work everywhere.

Here in the deep South, we tend to place multi-lane, high-speed highways everywhere and anywhere we can. These roadways are nearly impossible to cross on foot. The result is that many places listed in Walkscore will not be reachable without exposing yourself to considerable danger.

In a perfect world, everything you needed to know about housing would be on the internet. Unfortunately, not everyone lists their rentals on Zillow et. al., and I've had a hard time dealing with realtors over the phone. Other factors like noise, crime, and general ambiance are very difficult to judge. If you have access to just one person who knows the area quite well, suddenly these things become much easier.

While data fusion techniques might help, any results need to be very rigorously cross-checked, by hand, using Street View, aerial photography, online comments, and as many other sources as you can find.

Craigslist can get you a great deal on a used car: if you're going to buy one as-is, there's no need to pay the dealership markup. With that said, in my area the Craigslist listings for vehicles is packed mostly with unlicensed dealers who are masquerading as private parties. Some of them are even blatant enough to line up several cars they have for sale and photograph them all at once.

I would be wary of this sort of activity, since there's no telling where these people get their cars. For all I know, they could be buying junkers, putting a coat of paint on them, and flipping them. The best way to avoid these dealers is to:

• Run a search on the phone number / email address and see if it appears in any other for-sale listings
• Look for listings with similar wording
• Check an NVMTIS provider to see how long they have owned the vehicle
• When you call, inquire about "the car" they have for sale—if they ask, "which one?" walk away.

With that said, the existing dealership industry has every incentive to try and block smaller competitors. A major campaign to eliminate these unlicensed dealers is backed by a group which "manages access" to wholesale auctions to shut out buyers who aren't licensed car dealers. Presumably, if a smaller outfit could buy cars from one of these auctions, they'd be just as good as the ones a car dealership would sell.

When you get down to it, a car is a major purchase which carries with it an amount of financial risk that is difficult to quantify, or know, before you buy. They're typically sold by scum of all flavor who don't really care what you get stuck with. After all, why would someone sell a perfectly good car? If I was given a choice, I would rather not own a car.

Of course, they have to compete with the brighter headlights of today.

It would be nice if the emergency strobes used some type of beamforming to cast most of the light directly behind (and in front) of them. That way, it would be very bright when you are far away and the incident angle is small, but would be dimmer when you are up close. None of the existing lights seem to do this either, of course.

+1. In recent years, I have noticed a distinct upward trend in the headlight output of new vehicles produced here in the States. The worst offenders are high-profile SUVs and trucks, which have headlights that are set very high, but even late-model sedans have very bright lights. It has gotten to the point where oncoming traffic, on the other side of divided highways, is annoyingly bright in my windshield—to say nothing of the ones that are behind me. When I drive my '02 wagon on the interstate, I cannot see my own headlights' beam pattern: the vehicles behind me drown it out.

I fear that automakers are engaging in an arms race to build the brightest lights: clearly, you can see the best when your headlights overwhelm any other source. I don't believe this is particularly safe, since you have more to worry about from a vehicle that can't see clearly around you than you do from any unlit object you are likely to encounter. For all the carnage they can cause, a deer poses much less of a threat and carries much less momentum than a car going 70 mph. In urban settings, having the brightest lights prevents you from seeing anything not in your main beams. Pedestrians don't have headlights.

There are times when high-powered lights are useful, such as in daytime running lights or for driving on unpopulated back roads. But this is why we invented the "high beam" switch. These "laser headlights" will be nothing more than a fancy selling point and a nuisance to other drivers. A real improvement would be an IR illuminator or a collision avoidance sensor.

There is one added benefit to these new lights, however. Drivers with those high-intensity, high-set lights are surprisingly unwilling to tailgate me. I suspect that whenever they get dangerously close, my mirrors reflect their own headlights right back into their faces.

Maybe, maybe not. But I imagine that most GTalk users connect via GMail, Android, or can use Chrome. When they've all jumped ship for Hangouts—and on these platforms it is no more complicated than pushing a button—will there be anyone left on XMPP?

A public, federated XMPP server is probably the way to go. There are lots to choose from, and they all interoperate. Does ichat support such servers?

In all seriousness, I think IMAP is next on the chopping block.

I would think that having access to real-time presence information (at keys versus not at keys), status messages, and personal communication would be a marketing winner for Google. All of this is information that can be used to direct targeted ads to you contextually, anywhere on the internet. There's no need to present ads in the client itself for the service to have a good ROI.

I believe this post refers to the old Google+ Hangouts, which was the multi-party video conferencing service that launched with Google+.