Pfft, I'm getting 1.1mbps over DSL on a good day where I am. And my 4g phone, when I can get a signal, pulls maybe 600kbps. A 1/4 mile down the road our neighbor has cable at 30mbps, but he pays roughly 4 times as much as we do. Even with that price tag though, they end their line at the corner he's on, there is no service for us.

-Rick

Sorry, I should specify that the -government- is currently monitoring traffic via those methods.

Private industry has access to things that elements of the government does not, like your cell phone's position and speed (assuming you have Google's positioning system enabled).

Now, the NSA/FBI/Police may have some way of hacking in to get that, or put up stingers to catch it, but for all of the state DOTs out there, individuals' cell phones are not available. And the systems we have available to measure traffic volume, speed, and primary routes are limited.

-Rick

They're beating us in this one.

Current traffic monitoring systems use either CC video analysis, ramp meters, magnetic loop, or blue tooth detection. I've heard of systems to pick up tire pressure indicator signals also, but I haven't seen them first hand.

With all of that, we get ~5-7% of the vehicle speed data on select routes.

In 2017 new requirements go into effect to require all vehicles produced for use in the US to include V2V communications systems. Most of these systems also include V2I communications. Even if they don't, I'd expect detecting that a specific V2V entity just drove past is going to be trivial.

So by the end of 2017, we're going to be on parity with all of our current assorted solutions for penetration. By the end of 2018, we'll have double the penetration. By 2020, roughly 20-25% of all vehicles will contain V2V and/or V2I communications.

So what does that mean? It means we could generate optimum route data and re-route traffic based on travel time recommendations before they get onto a major road with limited access and a traffic issue on the desired route.

It also means we can identify true bottlenecks and take completely new approaches to road engineering and project prioritization. This alone is a multi-billion dollar a year industry, funded largely by tax payers. If we can find more efficient ways of taking on these projects, it means less expenditures (or more projects).

But it comes with down sides. A policing agency could in theory query the system to see where you currently are, or where your vehicle was at a specific time. It also makes it possible for the mile traveled road tax, where you can be taxed by mile driven, and those taxes can vary and be distributed by municipalities that own those roads. And of course there is a security concern that a hacker or malicious user could determine your driving habits and use the information to their advantage. I did even hear a member of the law enforcement community asking about such a system's ability to disable vehicles remotely in the case of excessive speed, chases, etc...

Basically, there's a huge shift coming in the US and how we (and the government) interact with our vehicles.

-Rick

The full quote was "people whose opinions I respect and who are experts in math and economics." Whether or not I respect their opinions, surely you don't think everyone on Slashdot is an expert in math and economics.

Well, what percent of sexually explicit pictures sent by text message, are still present on the recipient's phone the next day? Almost all of them.

What percent of sexually explicit pictures sent by snapchat, are still present on the recipient's phone the next day? Probably not the majority.

Snapchat is not perfect, it's just better. Seat belts don't prevent all injuries, but you wear them anyway, don't you?

Slashdot isn't the only place I share these arguments with people; I also share them with people whose opinions I respect and who are experts in math and economics, and their feedback tends to be much more positive than the commenters on Slashdot. So I assume the proportion of such people among Slashdot readers, is not zero. (Occasionally, there are comments and posts from people who did get the point of the article and argue it on its own terms, those posts just get drowned out by people saying that the article was too long.)

Yes, Slashdot used to be only summaries followed by links. Now it's mostly summaries followed by links, and the occasional long-form post. That's still not an argument against it.

Good points. Addressing separately:

1) On a phone that hasn't been jailbroken or rooted, I believe Snapchat notifies the sender if the recipient takes a screen capture of their message. This doesn't prevent it from happening, but it may at least make people think twice about it. If you're having a fling with a girl, and the girl sends you an explicit Snapchat picture which is intended to disappear after you view it, and the girl gets notified that you took a screen capture of it, she might go "What the fuck?" and you might not get any more nookie from that girl; for some guys, this might not be worth the risk.

More generally, of course you're right -- some pics will get screen captured. But Snapchat doesn't have to work perfectly for this purpose, it just has to work better than what people are doing now (sending texts which stay on your phone forever). What percent of explicit pictures sent by text message get deleted right after they get sent? Probably very few. What percent of similar pictures sent via Snapchat get deleted right after they're sent? Probably most of them. It's just an improvement, not a panacea.

2) It would be better if Snapchat let users set up end-to-end encryption so even Snapchat wouldn't be able to eavesdrop on people, and we wouldn't have to "trust" them. For now, all we can say is that it's better than using text messaging.

You're right, that would have made it more readable, sorry.

On the mitigating side, most of the frequent commenters take great pride on not being able to read that far.

Oh ok, good point. But he never made that argument either. (And the same response applies - he'd have to show why the unavoidable costs of skipping one's eyeballs two inches, are higher than the benefits.)

You're very articulate. But you never made an actual argument as to why the long-form posts are bad. (More precisely, why the benefits are outweighed by the unavoidable costs -- where the benefits include giving some people an argument to think about, and the unavoidable costs are that if someone doesn't want to read the article, they can move their eyeballs two inches down the page to skip it.)

I think this is confusing "protection and safety" in the sense used by politicians and moralists (e.g. "protecting" kids from porn) with "protection and safety" in the normal English meaning of the words (protecting a person from some kind of measurable harm). Just because workshops use language like "safety" does not mean that they're actually increasing anyone's safety in the literal sense.

Most psychologists believe -- correctly -- that teenagers are not harmed (in the correct English meaning of the word) by seeing other teenagers naked (otherwise, wouldn't they be leading the charge against teenage sex?).

If you want to argue that such workshops are there for students' "safety" then you'd have to make an argument as to why you think the behavior in question is actually dangerous.

The reasons you've given have come up many times, but they sound like the kind of reasons that people invent after the fact, in order to rationalize conclusions that they've already reached. If blocking students from getting on Facebook were really about "focus", then schools would let students get on Facebook who could demonstrate that they're already doing good work and know how to manage their time properly. If blocking students from getting on Facebook were about "managing finite resources", then they'd let students get on Facebook during non-peak hours, or when less than 50% of lab machines were in use, etc. But nobody ever even gets into these discussions, because I think deep down everybody knows these are not the real reasons.

I think that's a great reference. However, it doesn't have a column for "Are your past communications deleted by default by the client software, so that they will be unavailable even if your client machine is stolen by an adversary?", which is the feature of Snapchat that I'm focusing on here.

In fact, in a case where you want the clients to delete the messages by default, there's an argument that it's better not to have the client code and the protocol be completely "open". Because an open protocol makes it easier for third parties to write knockoff clients that speak the same protocol but that don't delete the received messages by default, thus increasing the risk to the sender. (Yes, people write third-party Snapchat knockoffs that do that anyway, but Snapchat can make it more difficult by changing their codebase and their protocol frequently.)

Technically it's "security through obscurity" to have your code be closed, but there's no real "security" here anyway, only a best effort. All you can aim for is that most of the time when you send a message, it will be deleted on the client side (and that they didn't take a picture of it first with another phone!).

My property taxes went up a couple years ago because the local residents decided to pay $2 million to have a flowage dredged and stocked with fish.

My property taxes are going up next year because the local residents decided to pay $25 million for a new sports complex at the high school.

Now, it may cost a couple mil to get a city wide fiber rollout, but after the initial build out, the monthly fees should cover peering and maintenance. So I get a 1 year bump in my taxes, and a life time of cheaper and faster internet access?

Now that's something I can get behind!

-Rick

"It turns out that there are zillions of little apps that make businesses run. Some of them are no more robust than an excel workbook on a well known file share. Some are Access applications. Lots of VB6 apps are still keeping businesses running."

I hear ya. Been right there in the trenches for almost 20 years now doing line of business application development/management. The organization I just started with has a product catalog that has over 1000 entries, with tons of additional excel/access solutions that remain undocumented.

But this is a problem. Each of these applications involve risks, maintenance, and support. The more of them there are (and some places have mountains of them) the more maintenance and support cost, the more often those risks present themselves.

The reason these apps exist is because of a business process, and that process was likely designed in a vacuum being held over a fire. It's not that the app is flawed, but the business process itself may be the source of the issue. Working with the business units to identify processes that have multiple IT needs and finding ways to streamline the process, not the apps, will save the company vastly more than sinking time into developing yet another application.

And that's where we get to the rub. There are already hundreds of POS suites, contract managers, document management, BRMs, ERPs, HR tools, taxes and accounting apps, etc... Any core business function that a company may have has likely already been solved with a tool that is vastly cheaper than what it would cost for us to build, with refined business processes built in, and with a significantly lower TCO including maintenance and support.

The world is full of giants. Stand on their shoulders so that your IT department can spend their time on projects that take your business where others can't.

-Rick