ClassicFarris

It looks like the page it was supposed to link to is no-longer there (which was a google app-engine app if I recall correctly) but maybe someone with some better google-cache fu can pull it up.

The login would change as you bring up and down servers. You get a new fresh install of the service on an instance each time you start a new one up. (Although the option to start and stop could be easily implemented.)

You can choose between all of the AWS Cities/Countries that AWS offers which is 9 across Asia, Australia, Europe, The USA and South America. Which hopefully would provide a good mix for a while.

As for expense, this is where the different use cases come in. If you want to secure a coffeeshop connection for a few hours then you'd just pay a few cents for the protection, which I think is reasonable. But if you want a more permanent connection then I may need to think more about the costs, or starting and stoping servers automagically to save costs.

I'd like to think that people would want to "run" their own, but I'm wondering if most even would care.

Just spin up $10K worth of AWS instances for a few hours to handle all of the connections, and done.

The solution: Carry-on Valet. Have 3-10 airplane employees (indoor luggage handlers) load the carry-on's to the bin above the seat number the person will be sitting in then leave the plane from the back. (For more speed have people start loading as the bins are filled from front to back)

I think large international flights could be excluded.

The airline would need to only have a few more luggage handlers to do this; as they are already at the gate, just outside, right?

Do you have plans to incorporate full meals on the site, such as a meat dish with two sides and how to cook them all together, to come out at the same time?

Can I do a pull request to make this change, or is this page so 1.0?

An articulated and advocated instance, where it just might work.

Do you have a source to back up the stats in this section?

> This would be an ineffective way to accomplish that. They'd first have to make a list of all the phones in the target area, and then they'd have to send the lock commands to them, one by one.

This doesn't seem to hard, if you have all of the phones connecting to one or two towers (Or you set up your own "Stingray" tower).

Now the standard line before a protest speech will be, "Please turn your phones to silent, and turn off the kill switch please..."

http://en.wikipedia.org/wiki/Motion_picture_rating_system

However, this got me thinking that across cultural lines there are a lot of shades to what is "safe". So a website based in Austria might want to restrict different content than a website based in Australia, and who knows where the "browser" is based.

Of course your comments about the site actually implementing anything/correctly still apply.

"parental-control:enabled" header would make more sense, right?

1. Google has "trends" when things happen, and "Earthquake" was most certainly googled near/at the time it happened. 2. The phone company has records, which many people texted/called near/at the time it happened. 3. 911 has records and calls were made near/at the time it happened.

and so on…

So there are private entities and government that have data around the event that can correlate behavior and situations, so it shouldn't seem scary to me… it's just should I have better access to the data? And if I do, what can I tell from the correlation?

If there is a good tests infrastructure re-writes can be done with a heck of a lot of confidence. Plus there is the benefit of breaking the re-write project up along test lines which helps in not creating the pressure for a, "huge one-time switchover".

For browser to Machine, I'm not sure we need that. The reason is, for example, we can use JSON which is very easily consumable by a machine over HTTP. HTTP provides all of the transport niceties like headers, verbs (which translate fairly well to CRUD), etc. So the combination of a fairly well featured transport layer combined with fairly well machine consumable data document format makes a pretty good protocol.

Which parts can change for the better in specific relationship to a machine-centric API protocol.

Now about those winters...