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.
But will I still be able to xmpp through google with other xmpp users?
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?
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 recently built a decoder for EAS/SAME messages. You can read about the protocol it uses at the National Weather Service. Forget about cryptographic signatures; SAME has absolutely no concept of message integrity. There is no CRC or checksum—not even a lowly parity bit.
Of course, it's difficult to use a checksum when you can't figure out when the message ends. Most systems use some kind of flag byte to tell the decoder where the end of the frame is, but SAME doesn't even have that. The decoder has to figure out where the end of the message is by parsing it and lopping off the garbage from the end. Messages are "redundant" in that they are repeated three times, but this doesn't improve redundancy very much. SAME also depends on a voice message to convey the content of the alert, which is hardly ideal in today's environment.
But SAME does have one thing going for it: You can actually get the messages. Its heir-apparent, IPAWS, seems more heavily focused on making sure people can't get the alerts. There are no public distribution hubs—you have to have a certificate from FEMA to get any data. Even with a certificate, there is, reportedly, no data to be had. I hope they make a SAME 2.0, even if it's only for end delivery to the general public via weather radios.
I've built the EAS decoder into a new version of multimon, which is available here. It can't generate messages; it only decodes them. From the YouTube video, here is what the zombie apocalypse man had to say:
While exercising your right to protest is admirable, there are other more effective methods to consider. While the VIPR teams may be authorized and financed by the federal government, they are not law enforcement. As such, they require the active cooperation of your transit police, your municipal police, and your state police to carry out their warrant-less searches. (The FBI and federal marshals have better things to do, really.) Without the authority to stand around in a fake badge and remove naysayers from the premises, just how effective can VIPR be?
So talk to your city council representative. Be polite, presentable, and logical. If you're lucky, you might be able to make a presentation or get a sponsor on some legislation. If you can get even a small group of people together, your chances of success will improve. Your state or city may give you some additional tools with which to affect change: Initiative and Recall. Use them.
While the 4th amendment is nice, in principle, that's not what is going to get the attention of your city government. Focus on the fiscal impact of the TSA's presence. How much time does the MBTA police spend assisting the VIPR teams? Does the city need to hire any staff to support them? If just one staffer has to spend ten minutes of their day dealing with this stuff, the TSA's presence is not revenue-neutral. Even if you can't get these numbers, bring it up. It will get them thinking, if nothing else.
Focus also on the impact on commerce. Does the TSA delay trains, or make people late for work? Does the TSA significantly reduce the number of riders on the subway and put them on already-congested roads? Point out the potential for theft and harassment—there have been a number of news articles about this very topic. Once that is finished, all you need to do is prove that the TSA does not actually increase security. Bring in expert testimony, if you can get it.
Once you have proved that VIPR is unpopular, decreases city revenue, negatively impacts commercial interests, and is disruptive to the public order (i.e., "don't grope me"), you will have lots of momentum behind a city ordinance. The goal of the ordinance should be to (1) prevent any municipal law enforcement from cooperating with these searches, and (2) actively remove anyone conducting such searches from the transit system. In the absence of any overriding law, city ordinance prevails and—good news—it's an election year.
VIPR will, having been removed from the city, need to spend time, effort, and money passing overriding legislation. If you're lucky, they'll just go away and find someone else to tyrannize. Even if they don't go quietly, the REAL ID Act is a great example of what states can do to a federal program if they refuse to support it. So go ahead, take back your city.
Sure, but how many Wikipedia users—not editors or regular contributors, but users—actually check the revision logs or old versions of the page? Even writers who are using Wikipedia as a primary source don't do that much fact checking. Users don't always have the greatest attention span in the world, and burying stuff on another page is a sure-fire way to get people to ignore it. If you put revision information three or more clicks away, or sequester it in a registration-required (or paywall-required) page, how many people will follow it? News-gathering organizations have a reputation to maintain, and they have every incentive not to admit that they are (or ever were) wrong.
I think that wikis should have a visualization tool for paragraphs, highlighting text like a spell-checker in a word processor or a syntax-checker in an IDE. The visualization tool should represent how new, and how frequently-revised, a particular section of text is. This will allow casual readers to easily spot points of contention and text that may require further validation.
I seem to recall another civilization where news stories were subject to constant, behind-the-scenes revisions. I read about it in a book. One must always take care to interpret the past correctly, through the darkly-tinted lenses of our current social and political mindset. After all, it would simply be unsettling if there were anything at all in our history that happened to be politically insensitive or inconvenient for our current religious, economic, or secular leadership. Simply revising or "reinterpreting" key facts and events go a long way towards removing all of that troubling cognitive dissonance; such dissonance could cause people to question the way things are right now. Sadly, I can't really remember any more details about this civilization, because my e-books retailer erased every copy of it.
I have tried faxing via Google Voice over a POTS connection. I can connect to the remote fax machine, but it fails to send even one page. GV states in its FAQs that it cannot be used as a fax number. Either they are explicitly blocking it or (more likely) they are using an LPC/model-based speech codec like speex that simply eats the analog modulation for lunch. With the death of Gizmo5, it is now impossible to connect via SIP except via services that give you a PSTN connection and a phone number—and at that point, why use GV at all, since you're already paying someone else for a phone number? sipgate claims the ability to send faxes, but this is a function of sipgate and not Google, and I have not tried them at all.
Have you actually gotten fax over Google Voice to work?
I am profoundly disappointed by Google's profound lack of commitment to open standards (i.e. SIP).
Fax may never die, but its current implementation is tied to a piece of technology that people keep claiming will be on the chopping block before long: the analog dial-up line. At my university, VoIP phones are the norm—and are relatively trivial for IT to hand out—but getting an analog line provisioned is difficult and expensive. Have you ever tried to send a fax from Google Voice or a similar IP-based telephony network? I have, and it doesn't work: the codecs are specifically designed for speech, and the channel does not have enough effective bandwidth to support even a 14.4kbps fax. There are stopgap solutions, of course; Analog Telephone Adapters (ATAs) and/or centralized fax servers save the day. But what about the future, when companies decide to forsake their ISDN/T1-type phone lines altogether and go "all-internet" for their phone connections?
Fax is, for businesses, currently an irreplaceable service. No other service gives them the same traceability, accountability, and legal protections as fax does. Digital signatures do exist, but defending said signatures in court later could get expensive, and I'm not certain if they have ever been interpreted as legally binding. (Anyone, please feel free to refute this.) Trusted timestamps also exist, but the market for them is abysmal. Authentidate, which is marketed by the USPS as an "electronic postmark," costs more than postage and charges for each validation. So, what will happen to fax as the phone network depreciates?
I predict that soon, organizations will be outsourcing their faxing capabilities to third-party providers, which will provide them with an email (or other internet) gateway for faxes. Maybe they'll even connect a printer to keep that same-old fax feel. Eventually, the fax gateways will become popular and numerous enough that they will all realize just how much they're paying for PSTN lines and long distance charges. Then, they'll start peering with one another over encrypted internet links, forsaking the entire phone network and the associated analog transmission protocols altogether. The end result: companies will pay good money to emulate an old, low-resolution raster image transmission protocol, the purpose of which—to squeeze images down a phone line with simplistic compression—having been entirely forgotten.
These are just my totally-uneducated musings, and you should not take them for investment advice. As an interesting side-note, fax (or fax-like protocols) are also used to send weather charts to ships at sea, and these radiofaxes could possibly outlast their phone counterparts.
We use MineOS, but it is not something I'd recommend. It is based on a thumb drive/CD-R linux distro, and as such getting it to save system changes to the hard drive is like pulling teeth. It has RAM disk functionality for the world files, but we're not using it—that is most certainly asking for trouble. If it were my box (I just admin it), I would have installed a real, actively-maintained OS like Debian or Ubuntu Server long ago.
They theoretically have a new version, MineOS CRUX, that is less full of fail, but I haven't tried it.
I really do enjoy Minecraft, but my enjoyment of the game is tempered somewhat by the hair-pulling, teeth-gnashing, life-sucking hassle of administering an SMP server. When I first installed it, the server was so unreliable that I needed to write a bunch of custom "glue" just to keep it online. The server would crash constantly, so I wrote a shell script to restart it if it exited. But this proved insufficient, as sometimes it would simply hang unresponsively, so I wrote a more sophisticated watchdog timer for it. These crashes were the least of my problems, however.
The world files, which are a monument to our thousands of man-hours of lost productivity, are precious, precious data, but the server treats them with less care than the contents of/dev/random. In just six months, I have had to restore from backups three times due to irrecoverable server faults. There is no write-ahead-logging, so any power failures can corrupt the world. The all-important level.dat file has been destroyed at least twice, changing the random seed—and all of the world's climate—in the process. After fixing the seed, I had to use a level editor to melt all the ice. Saves are also not atomic, so crashes will usually result in lost items and inconsistent states. I must have spent hours just giving people back lost items. If Notch would just use an ACID-compliant DBMS, none of this would happen. I back up the world four times a day, and I sometimes question whether this is often enough.
The server chews up a truly ludicrous amount of bandwidth—just having four or five people connected at once will saturate a typical residential connection—but there is no reason for this. The world doesn't really change much over time, since players can only affect little bits of it at once, so why not have clients cache the world and pull only versioned updates over the network? If it's good enough for Mozilla, it should be good enough for Mojang. Surely, with the well-known "chunk error" problems, this couldn't possibly make the data transfers any less reliable.
While there have been numerous fixes for gameplay-related issues, or things Notch believes are gameplay issues, no attempt has been made to address the architectural deficiencies which make administering an SMP server a complete pain in the posterior. But that's okay, because it's supposed to be "fun," right?
Believe it or not it is entirely possible for the Internet to be used over terrestrial radio... in fact... it can be done by 'amateurs'! In fact... it already is!
While true, amateur radio connections cannot even begin to replace existing internet infrastructure, even in a low-bandwidth, emergency context. You could conceivably link a bunch of wireless hot spots together over 2 meter/VHF, and since VHF has a maximum propagation distance of about 100 miles, everything would work perfectly, right?
Except it wouldn't.
Since VHF is (more or less) line-of-sight, you'll need lots of power and/or a highly directional antenna on a tower. The former will splatter RF energy everywhere, making those frequencies unavailable to everyone else nearby, and the latter requires big, obvious infrastructure on both ends. Infrastructure, as you have pointed out, puts someone in control—even if it is just "that guy who runs the local digipeater." If he doesn't like you, he might not let you connect his VHF radio tower to yours.
There is also the problem of access control: not who can transmit on the 'net, but when. If everyone transmits at the same time, the end result is just unintelligible static. Ad-hoc wireless networks work for small networks, with nodes that are all "within earshot" of one another, but the hidden node problem quickly takes over as the range increases. If you gave everyone in the city of New York a VHF transmitter, and just told them to use it whenever, the interference they'd produce while trying to use it would probably rival military jamming technology. Cellular networks achieve efficient communications by precisely interleaving the signal from each and every phone, in either the space, frequency, time, or code domains. This requires planning, and engineering expertise, which again puts someone in control.
There is a reason why the Amateur Radio Service is intended as a secondary communications system, for use only when no other link will suffice. It is the best way to communicate when all the other networks are inoperative, but it simply cannot scale to a project of this magnitude.
Mythbusters successfully demonstrated that a SCUBA tank, which have pressures up to 30 MPa (4400 psi) and internal volumes up to 18 liters, will turn itself into a missile if its regulator catastrophically fails. The tank proposed in TFA would have a pressure of 34 MPa and a volume of 54 liters, meaning that it will store even more energy.
An over-pressurized liquid nitrogen tank caused major damage to a Texas A&M building when it failed (read: exploded). According to the engineer's report (pdf):
The blast cracked the floor but due to the presence of the supporting beam, which shattered, the floor held. Since the floor held the force of the explosion was directed upward and propelled the cylinder, sans bottom, through the concrete ceiling of the lab into the mechanical room above. It struck two 3 inch water mains and drove them and the electrical wiring above them into the concrete roof of the building, cracking it. The cylinder came to rest on the third floor leaving a neat 20" diameter hole in its wake. The entrance door and wall of the lab were blown out into the hallway, all of the remaining walls of the lab were blown 4–8" off of their foundations.
Pictures of the devastation are included in the report. This tank, like all compressed gas cylinders, had both a safety relief valve and an emergency blowout disc. The explosion only occurred when both of these safety features were compromised due to improper maintenance.
While the hybrid's gaseous nitrogen tank is substantially different than the liquid nitrogen tank described above, it is safe to say that compressed gas cylinders are dangerous beasts. Unless you're planning on participating in the Hybrid Space Program, I would suggest steering away from vehicles like this.
Spawn-killing isn't as much of a problem in UrT, since players spawn fully armed and armored. Each player spawns with one primary weapon, one sidearm, and three or four other things; players can adjust their load-out in between deaths. Some (maybe all?) servers use spawn protection to further limit this problem. There are still people who try, but they generally don't live for very long. You are more likely to see enemies occupying territory just outside spawning grounds, and it can be very, very difficult to flush those enemies out.
As for maturity of spirit: it varies. The clanners tend to take things seriously, but there are plenty of others who just like being obnoxious on comms. The real problem in UrT is hacking. It's an open-source game, making it easy to hack and modify, but most hackers hack poorly enough that it's immediately obvious. Most of these problems can be mitigated by playing on a server that is actively administered—the admins will kick the 'tards off when they can.
UrT is distributed as a ZIP package with statically-linked i386 and x86_64 linux executables, so it should work in most linux environments. You could also get a package for ioquake3 and try adding in Urban Terror, but I've never tried doing that.
Slashdot Mirror
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
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:
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.
But will I still be able to xmpp through google with other xmpp users?
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?
Pretty soon they'll drop HTML support
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.
It will be open
I believe this post refers to the old Google+ Hangouts, which was the multi-party video conferencing service that launched with Google+.
I recently built a decoder for EAS/SAME messages. You can read about the protocol it uses at the National Weather Service. Forget about cryptographic signatures; SAME has absolutely no concept of message integrity. There is no CRC or checksum—not even a lowly parity bit.
Of course, it's difficult to use a checksum when you can't figure out when the message ends. Most systems use some kind of flag byte to tell the decoder where the end of the frame is, but SAME doesn't even have that. The decoder has to figure out where the end of the message is by parsing it and lopping off the garbage from the end. Messages are "redundant" in that they are repeated three times, but this doesn't improve redundancy very much. SAME also depends on a voice message to convey the content of the alert, which is hardly ideal in today's environment.
But SAME does have one thing going for it: You can actually get the messages. Its heir-apparent, IPAWS, seems more heavily focused on making sure people can't get the alerts. There are no public distribution hubs—you have to have a certificate from FEMA to get any data. Even with a certificate, there is, reportedly, no data to be had. I hope they make a SAME 2.0, even if it's only for end delivery to the general public via weather radios.
I've built the EAS decoder into a new version of multimon, which is available here. It can't generate messages; it only decodes them. From the YouTube video, here is what the zombie apocalypse man had to say:
Please don't spoof EAS messages. The system is fragile enough without you messing with it.
While exercising your right to protest is admirable, there are other more effective methods to consider. While the VIPR teams may be authorized and financed by the federal government, they are not law enforcement. As such, they require the active cooperation of your transit police, your municipal police, and your state police to carry out their warrant-less searches. (The FBI and federal marshals have better things to do, really.) Without the authority to stand around in a fake badge and remove naysayers from the premises, just how effective can VIPR be?
So talk to your city council representative. Be polite, presentable, and logical. If you're lucky, you might be able to make a presentation or get a sponsor on some legislation. If you can get even a small group of people together, your chances of success will improve. Your state or city may give you some additional tools with which to affect change: Initiative and Recall. Use them.
While the 4th amendment is nice, in principle, that's not what is going to get the attention of your city government. Focus on the fiscal impact of the TSA's presence. How much time does the MBTA police spend assisting the VIPR teams? Does the city need to hire any staff to support them? If just one staffer has to spend ten minutes of their day dealing with this stuff, the TSA's presence is not revenue-neutral. Even if you can't get these numbers, bring it up. It will get them thinking, if nothing else.
Focus also on the impact on commerce. Does the TSA delay trains, or make people late for work? Does the TSA significantly reduce the number of riders on the subway and put them on already-congested roads? Point out the potential for theft and harassment—there have been a number of news articles about this very topic. Once that is finished, all you need to do is prove that the TSA does not actually increase security. Bring in expert testimony, if you can get it.
Once you have proved that VIPR is unpopular, decreases city revenue, negatively impacts commercial interests, and is disruptive to the public order (i.e., "don't grope me"), you will have lots of momentum behind a city ordinance. The goal of the ordinance should be to (1) prevent any municipal law enforcement from cooperating with these searches, and (2) actively remove anyone conducting such searches from the transit system. In the absence of any overriding law, city ordinance prevails and—good news—it's an election year.
VIPR will, having been removed from the city, need to spend time, effort, and money passing overriding legislation. If you're lucky, they'll just go away and find someone else to tyrannize. Even if they don't go quietly, the REAL ID Act is a great example of what states can do to a federal program if they refuse to support it. So go ahead, take back your city.
Sure, but how many Wikipedia users—not editors or regular contributors, but users—actually check the revision logs or old versions of the page? Even writers who are using Wikipedia as a primary source don't do that much fact checking. Users don't always have the greatest attention span in the world, and burying stuff on another page is a sure-fire way to get people to ignore it. If you put revision information three or more clicks away, or sequester it in a registration-required (or paywall-required) page, how many people will follow it? News-gathering organizations have a reputation to maintain, and they have every incentive not to admit that they are (or ever were) wrong.
I think that wikis should have a visualization tool for paragraphs, highlighting text like a spell-checker in a word processor or a syntax-checker in an IDE. The visualization tool should represent how new, and how frequently-revised, a particular section of text is. This will allow casual readers to easily spot points of contention and text that may require further validation.
I seem to recall another civilization where news stories were subject to constant, behind-the-scenes revisions. I read about it in a book. One must always take care to interpret the past correctly, through the darkly-tinted lenses of our current social and political mindset. After all, it would simply be unsettling if there were anything at all in our history that happened to be politically insensitive or inconvenient for our current religious, economic, or secular leadership. Simply revising or "reinterpreting" key facts and events go a long way towards removing all of that troubling cognitive dissonance; such dissonance could cause people to question the way things are right now. Sadly, I can't really remember any more details about this civilization, because my e-books retailer erased every copy of it.
News via Wiki? I don't think so.
I have tried faxing via Google Voice over a POTS connection. I can connect to the remote fax machine, but it fails to send even one page. GV states in its FAQs that it cannot be used as a fax number. Either they are explicitly blocking it or (more likely) they are using an LPC/model-based speech codec like speex that simply eats the analog modulation for lunch. With the death of Gizmo5, it is now impossible to connect via SIP except via services that give you a PSTN connection and a phone number—and at that point, why use GV at all, since you're already paying someone else for a phone number? sipgate claims the ability to send faxes, but this is a function of sipgate and not Google, and I have not tried them at all.
Have you actually gotten fax over Google Voice to work?
I am profoundly disappointed by Google's profound lack of commitment to open standards (i.e. SIP).
Fax may never die, but its current implementation is tied to a piece of technology that people keep claiming will be on the chopping block before long: the analog dial-up line. At my university, VoIP phones are the norm—and are relatively trivial for IT to hand out—but getting an analog line provisioned is difficult and expensive. Have you ever tried to send a fax from Google Voice or a similar IP-based telephony network? I have, and it doesn't work: the codecs are specifically designed for speech, and the channel does not have enough effective bandwidth to support even a 14.4kbps fax. There are stopgap solutions, of course; Analog Telephone Adapters (ATAs) and/or centralized fax servers save the day. But what about the future, when companies decide to forsake their ISDN/T1-type phone lines altogether and go "all-internet" for their phone connections?
Fax is, for businesses, currently an irreplaceable service. No other service gives them the same traceability, accountability, and legal protections as fax does. Digital signatures do exist, but defending said signatures in court later could get expensive, and I'm not certain if they have ever been interpreted as legally binding. (Anyone, please feel free to refute this.) Trusted timestamps also exist, but the market for them is abysmal. Authentidate, which is marketed by the USPS as an "electronic postmark," costs more than postage and charges for each validation. So, what will happen to fax as the phone network depreciates?
I predict that soon, organizations will be outsourcing their faxing capabilities to third-party providers, which will provide them with an email (or other internet) gateway for faxes. Maybe they'll even connect a printer to keep that same-old fax feel. Eventually, the fax gateways will become popular and numerous enough that they will all realize just how much they're paying for PSTN lines and long distance charges. Then, they'll start peering with one another over encrypted internet links, forsaking the entire phone network and the associated analog transmission protocols altogether. The end result: companies will pay good money to emulate an old, low-resolution raster image transmission protocol, the purpose of which—to squeeze images down a phone line with simplistic compression—having been entirely forgotten.
These are just my totally-uneducated musings, and you should not take them for investment advice. As an interesting side-note, fax (or fax-like protocols) are also used to send weather charts to ships at sea, and these radiofaxes could possibly outlast their phone counterparts.
We use MineOS, but it is not something I'd recommend. It is based on a thumb drive/CD-R linux distro, and as such getting it to save system changes to the hard drive is like pulling teeth. It has RAM disk functionality for the world files, but we're not using it—that is most certainly asking for trouble. If it were my box (I just admin it), I would have installed a real, actively-maintained OS like Debian or Ubuntu Server long ago.
They theoretically have a new version, MineOS CRUX, that is less full of fail, but I haven't tried it.
I really do enjoy Minecraft, but my enjoyment of the game is tempered somewhat by the hair-pulling, teeth-gnashing, life-sucking hassle of administering an SMP server. When I first installed it, the server was so unreliable that I needed to write a bunch of custom "glue" just to keep it online. The server would crash constantly, so I wrote a shell script to restart it if it exited. But this proved insufficient, as sometimes it would simply hang unresponsively, so I wrote a more sophisticated watchdog timer for it. These crashes were the least of my problems, however.
The world files, which are a monument to our thousands of man-hours of lost productivity, are precious, precious data, but the server treats them with less care than the contents of /dev/random. In just six months, I have had to restore from backups three times due to irrecoverable server faults. There is no write-ahead-logging, so any power failures can corrupt the world. The all-important level.dat file has been destroyed at least twice, changing the random seed—and all of the world's climate—in the process. After fixing the seed, I had to use a level editor to melt all the ice. Saves are also not atomic, so crashes will usually result in lost items and inconsistent states. I must have spent hours just giving people back lost items. If Notch would just use an ACID-compliant DBMS, none of this would happen. I back up the world four times a day, and I sometimes question whether this is often enough.
The server chews up a truly ludicrous amount of bandwidth—just having four or five people connected at once will saturate a typical residential connection—but there is no reason for this. The world doesn't really change much over time, since players can only affect little bits of it at once, so why not have clients cache the world and pull only versioned updates over the network? If it's good enough for Mozilla, it should be good enough for Mojang. Surely, with the well-known "chunk error" problems, this couldn't possibly make the data transfers any less reliable.
While there have been numerous fixes for gameplay-related issues, or things Notch believes are gameplay issues, no attempt has been made to address the architectural deficiencies which make administering an SMP server a complete pain in the posterior. But that's okay, because it's supposed to be "fun," right?
Believe it or not it is entirely possible for the Internet to be used over terrestrial radio ... in fact ... it can be done by 'amateurs'! In fact ... it already is!
While true, amateur radio connections cannot even begin to replace existing internet infrastructure, even in a low-bandwidth, emergency context. You could conceivably link a bunch of wireless hot spots together over 2 meter/VHF, and since VHF has a maximum propagation distance of about 100 miles, everything would work perfectly, right?
Except it wouldn't.
Since VHF is (more or less) line-of-sight, you'll need lots of power and/or a highly directional antenna on a tower. The former will splatter RF energy everywhere, making those frequencies unavailable to everyone else nearby, and the latter requires big, obvious infrastructure on both ends. Infrastructure, as you have pointed out, puts someone in control—even if it is just "that guy who runs the local digipeater." If he doesn't like you, he might not let you connect his VHF radio tower to yours.
There is also the problem of access control: not who can transmit on the 'net, but when. If everyone transmits at the same time, the end result is just unintelligible static. Ad-hoc wireless networks work for small networks, with nodes that are all "within earshot" of one another, but the hidden node problem quickly takes over as the range increases. If you gave everyone in the city of New York a VHF transmitter, and just told them to use it whenever, the interference they'd produce while trying to use it would probably rival military jamming technology. Cellular networks achieve efficient communications by precisely interleaving the signal from each and every phone, in either the space, frequency, time, or code domains. This requires planning, and engineering expertise, which again puts someone in control.
There is a reason why the Amateur Radio Service is intended as a secondary communications system, for use only when no other link will suffice. It is the best way to communicate when all the other networks are inoperative, but it simply cannot scale to a project of this magnitude.
Mythbusters successfully demonstrated that a SCUBA tank, which have pressures up to 30 MPa (4400 psi) and internal volumes up to 18 liters, will turn itself into a missile if its regulator catastrophically fails. The tank proposed in TFA would have a pressure of 34 MPa and a volume of 54 liters, meaning that it will store even more energy.
An over-pressurized liquid nitrogen tank caused major damage to a Texas A&M building when it failed (read: exploded). According to the engineer's report (pdf):
Pictures of the devastation are included in the report. This tank, like all compressed gas cylinders, had both a safety relief valve and an emergency blowout disc. The explosion only occurred when both of these safety features were compromised due to improper maintenance.
While the hybrid's gaseous nitrogen tank is substantially different than the liquid nitrogen tank described above, it is safe to say that compressed gas cylinders are dangerous beasts. Unless you're planning on participating in the Hybrid Space Program, I would suggest steering away from vehicles like this.
from 1900 Things Mr. Welch can no longer do during an RPG.
Spawn-killing isn't as much of a problem in UrT, since players spawn fully armed and armored. Each player spawns with one primary weapon, one sidearm, and three or four other things; players can adjust their load-out in between deaths. Some (maybe all?) servers use spawn protection to further limit this problem. There are still people who try, but they generally don't live for very long. You are more likely to see enemies occupying territory just outside spawning grounds, and it can be very, very difficult to flush those enemies out.
As for maturity of spirit: it varies. The clanners tend to take things seriously, but there are plenty of others who just like being obnoxious on comms. The real problem in UrT is hacking. It's an open-source game, making it easy to hack and modify, but most hackers hack poorly enough that it's immediately obvious. Most of these problems can be mitigated by playing on a server that is actively administered—the admins will kick the 'tards off when they can.
UrT is distributed as a ZIP package with statically-linked i386 and x86_64 linux executables, so it should work in most linux environments. You could also get a package for ioquake3 and try adding in Urban Terror, but I've never tried doing that.