Submission + - U.S. Cyber Data Base Lags Chinese Counterpart: Machine Translation Can Help 1

david.cowhig writes: U.S. computer vulnerability database reporting lag of two weeks compared to its Chinese counterpart adds to U.S. vulnerabilities according to the Recorded Future Blog research report at :

"The U.S. National Vulnerability Database (NVD) trails China’s National Vulnerability Database (CNNVD) in average time between initial disclosure and database inclusion (33 days versus 13 days) — China isn’t directly integrated in managing CVEs, but are still able to report vulnerabilities more rapidly than the U.S.”

You can see for yourself at the U.S. and Chinese database (with the help of Google Translate). For example, here is the Google machine translation of the top page of the Chinese database :

Machine translation may be able to help companies get early warning from China.

  For more details see my Chinese translation blog at

Submission + - When should a person start thinking about getting a VPN? 1

Hasaf writes: On of my students sent me this letter. I have a good idea how I will answer: but I wanted to put it before the Slashdot community.

Right now I am 14 years old, I was wondering when I should get a VPN I’ve been looking for good VPNs and the one I want to get is PIA I was thinking about getting the yearly deal. But right now I really have no need for a VPN at the moment, I was thinking of getting a VPN when I’m in 11th grade or maybe in college. What do you think?

Submission + - The Oceanic Pole Of Inaccessibility - The Place Spacecraft Go To Die (

dryriver writes: Whether you launch a satellite into space or an entire space station like the Russian Mir, the Chinese Tiangong-1 or the International Space Station, what goes up must eventually come down — re-enter earth's atmosphere. The greater the mass of what is in space — Mir weighed 120 tons, the ISS weighs 450 tons and will be decommissioned in a decade — the greater the likelihood that larger parts will not burn up completely during re-entry and crash to earth at high velocity. So there is a need for a place on earth where things falling back from space are least likely to cause damage or human casualties. The Oceanic Pole Of Inaccessibility is one of 2 such places. The place furthest away from land — it lies in the South Pacific some 2,700km (1,680 miles) south of the Pitcairn Islands — somewhere in the no-man's land, or rather no-man's-sea, between Australia, New Zealand and South America, it has become a favorite crash site for returning space equipment. Scattered over an area of approximately 1,500 sq km (580 sq miles) on the ocean floor of this region is a graveyard of satellites. At last count there were more than 260 of them, mostly Russian. The wreckage of the Space Station Mir also lies there. Many times a year the supply module that goes to the International Space Station burns up in this region incinerating the station's waste. The International Space Station will also be carefully brought down in this region when its mission ends. No one is in any danger because of this controlled re-entry into our atmosphere. The region is not fished because oceanic currents avoid the area and do not bring nutrients to it, making marine life scarce.

Submission + - Software Engineers -- Don't EVER store SSN or Password

An anonymous reader writes: I can't think of any legitimate business need for a company like Equifax to ever store an individual's SSN. Yes, you might like a unique identifier for an individual. You may also have a need to have that identifier validated by a third party requesting data such as a credit application. However, why can't they use a hashed (essentially unique quasi random data) value for that identifier?

The same thing goes for passwords, driver's license numbers, and a variety of other identifying information. Why would any company ever have a need to store a plain text password when they can at a minimum store a hashed value for that data? If you store a hashed value then that stored password or SSN is essentially useless outside of the company's database.

Storing plain text information like this is criminal neglect, not to mention pitifully bad software engineering practice even if you think that the overall database itself is encrypted and access is restricted.

THINK before storing plain text information. If you need to retrieve it, encrypt it separately based on a key unique to the data record. If you can't prove that you need the information back (you only need to validate it or use it to look something up) then hash it. This prevents even the malicious insider from revealing information since the underlying information is never actually stored.

Submission + - Does the US Need A Infrastructure Czar? (

mikeebbbd writes: Writing in CityLab, Kriston Capps argues that we need a better way to pick infrastructure projects for public funding. While it's unlikely that the real bill (over $1 trillion) will be covered, ever, he argues that even if it were to be covered we need a different way to pick WHAT gets funded and when. For instance, Flint needs clean water right now; Kansas City probably can wait a bit for an improved streetcar.

This ignores, of course, the fact that the feds don't fund all public infrastructure. When some place uses its own or its state's money rather than federal, they can be excused for placing their own interest first. And there's always Trump's desire to privatize it all. Still, the author has some good points, and it's clear that federal infrastructure funding is kind of fractured by type (with transportation getting a very large cut). Would a cabinet-level post or other "czar" to coordinate it all be worthwhile, as suggested in the story?

Submission + - Beating the bookie with data science and how the online betting market is rigged

austro writes: A new paper featuring in New Scientist and the MIT Technology Review shows how a trio of data scientists developed a betting strategy to beat bookmakers at football games.

The researchers posted a paper explaining the methodology on arxiv last week. They also made the dataset and source code available on github. And best of all, they made an online publicly available dashboard that shows a live list of bet recommendations on football matches based on their strategy here or here for anyone to try.

From the New Scientist article: "The chances of making a profit by betting on football matches are extremely low, but a trio of researchers has managed to beat the odds with a simple formula. The team studied 10 years’ worth of data on nearly half a million football matches and the associated odds offered by 32 bookmakers between January 2005 and June 2015. When they applied their strategy in a simulation, they made a return of 3.5 per cent. Making bets randomly resulted in a loss of 3.32 per cent. Then the team decided to try betting for real. They developed an online tool that would apply their odds-averaging formula to upcoming football matches. When a favorable opportunity arose, a member of the team would email Kaunitz and his wife, one of whom then placed a bet. They kept this up for five months, placing $50 bets around 30 times a week. And they were winning. After five months the team had made a profit of $957.50 – a return of 8.5 per cent. But their streak was cut short. Following a series of several small wins, the trio were surprised to find that their accounts had been limited, restricting how much they could bet to as little as $1.25. The gambling industry has long restricted players who appear to show an edge over the house, says Mark Griffiths at Nottingham Trent University, UK. A classic example is card-counting, which can help players win at blackjack. Casinos are quick to expel those who try it and it is sometimes flagged as cheating. But it’s not illegal in the US or the UK."

The paper illustrates how the sports gambling industry compensates market inefficiencies with discriminatory practices against successful clients.

Slashdot Top Deals